August 16, 2019
On Friday, 16 August 2019 at 09:20:58 UTC, Atila Neves wrote:

> Nobody is good at multi tasking (there are studies). A lot of people are really good at believing they are, though.
So true.

> CPUs have nothing on the brain when it comes to context switching.
No, even they do nowadays. This is called cache, which tend to be garbled by frequent context switches (at least if more threads are running than available cores, which indeed is usually the case - but hopefully most of them take only a very small time slice)

August 16, 2019
On Thursday, 8 August 2019 at 10:10:30 UTC, Russel Winder wrote:
> So if C++ has this dependency problem why doesn't D, Go, or Rust?

Walter derailed the topic with parsing stuff. That dependency is not the lexical order dependency, it's build sequence dependency: one module depends on compilation output of another module, and it's not a problem of C++, it's a problem of this particular module design. D has no such dependency problem (except for idgen), you can compile D files in any order.
August 16, 2019
On Thursday, 15 August 2019 at 15:00:43 UTC, Atila Neves wrote:
> I can take waiting 40s once a day. I can't take waiting >1s every time I build though.

I just spent two weeks doing a biggish refactoring, I didn't safe files until the end. If I know it's not ready and won't work, and know what's left to do, why bother, it's just a waste of entropy.
August 16, 2019
On Friday, 16 August 2019 at 09:20:58 UTC, Atila Neves wrote:
> Nobody is good at multi tasking (there are studies). A lot of people are really good at believing they are, though. CPUs have nothing on the brain when it comes to context switching.

I think this is tricky!

I know people who can sing and play guitar at the same time, while there are others whom just can't.

You can search "How can I sing and p..." the rest will be auto completed by this problem.

People who can do this, usually can timing the song and do these 2 actions nicely.

I can't do these 2 things, but on the other hand while at the gym I can think and solve problems better while doing some push ups, I think this is called Synapse or something like that.

Sasha.
August 16, 2019
On Thursday, 15 August 2019 at 22:37:16 UTC, H. S. Teoh wrote:
> On Thu, Aug 15, 2019 at 08:09:33PM +0000, Exil via Digitalmars-d wrote: [...]
>> See my experience with D is that it still takes over a minute to compile my relatively small program.
>
> I've seen that before.  The cause is usually one or more of:
>
> (1) Using dub.  Dub is, sorry to say, dog-slow.  I do not bother with dub because of that (plus a variety of other reasons).  I use a saner build system that invokes dmd directly, and it's a lot faster than using dub.
>
> (2) Using too many templates / CTFE.  CTFE is known to be dog-slow (Diet templates are a leading cause of dog-slow compilation in vibe.d projects, because they try to do too much at compile-time. I haven't gotten around to it yet, but in my own vibe.d project the goal is to move away from Diet templates and use a faster, home-brew HTML generation solution instead.)  NewCTFE is supposed to improve this, but at the rate things are going, I'm not holding my breath for it.
>
> Templates are also known to be slow when you get into recursive templates or just careless, wanton use of compile-time arguments where runtime arguments do just fine.  If you reduce your use of templates, and use runtime code where it's not important to stuff everything into compile-time, your compile times will improve a lot.
>
> (3) Using certain Phobos modules that are known to be very slow to compile, such as std.regex.  The underlying cause is essentially the same as (2), but I thought I'd point it out because sometimes it's not obvious that that's the problem when all you did was to import Phobos.
>
>
>> A minute isn't really fast.
>
> If my D project is taking a minute to compile, I'd seriously look into eliminating needless templates/CTFE and/or replacing dog-slow Phobos modules with custom code.
>

Already don't use Phobos and I can't eliminate needless CTFE cause it isn't needless. D's fast except if you use this this this and that. Well then it isn't fast. Especially when the whole point of using it are for those features. Then I'm wasting time trying to make my code fast for the compiler instead of using that time to making the code actually better.

>> Even worse if you use -O with DMD (I stopped it after 20 mins).
>
> IMNSHO, using -O with DMD is a waste of time.  It increases compilation time, and has a higher probability of running into a compiler (usu. backend) bug, yet the resulting executable is still woefully suboptimal compared to, say, gdc or ldc.  Just not worth it.  If performance was important to me (and it is, in some of my projects), I'd just use ldc2 outright and forget about DMD.


 Yah I don't really use DMD anymore, too many bugs and I have to build it myself.


>
>> D really isn't a fast language, or rather the only frontend is really really slow especially for CTFE.
>
> I understand the sentiment, but I think it's an unfair comparison.  If I were to implement in C++ the equivalent of the some CTFE functionality that's making my compilation slow, I'm almost certain the resulting C++ compile times will make dmd look like lightning speed by comparison. CTFE *is* known to be slow, no question about that, but I suspect it's still a lot faster than what it would have taken to accomplish the same thing in C++.

Its a C++ project I converted, and it actually compiled faster in C++. I was using my own program to do what I am doing on CTFE now. As a result I was able to optimize it myself.

>
> [...]
>> > Compile errors that appear instantly means you're still focused and can immediately get on the task of identifying the problem code. Compile errors that appear after X seconds means you spend an additional Y seconds refocusing your brain on the programming problem at hand, and *then* get on the task of identifying the problem code, thus slowing you down by (X+Y+Z) seconds rather than just spending the Z seconds finding the problem.
>> 
>> Now you have to read and interpret something else entirely. Your not waiting 200 ms to continue your line of thought, your wasting minutes if not more if you continue to get compiler errors. Especially one of those template errors that are difficult to interpret. It's the same problem but x10 worse.
>
> But you have to spend that time *anyway*, eventually if not right then, when you have to fix the bug in your code.  Why make the total time even longer by being forced to wait for long compilation times?


Point being, someone is willing to punch a wall for 100ms, I wonder why they aren't getting angree at other things equally. Especially with how horrible some error messages can be.
>
>> Your not the person I was replying to, so sure
>> maybe its something else to you, but the person I was replying to made
>> it pretty clear what it was for them.
>> 
>> Just curious, how fast do you type? If it's about wasting time for you I imagine you must type pretty quickly then :P.
> [...]
>
> I type relatively fast -- not super-fast, mind you, but the point is that long compilation times are *on top* of my typing times.  If I'm already typing not super-fast, then I really don't want compilation times to make the total time even longer.
>
>
> T

That's my point, what are you doing to improve how fast you type? What WPM? One persons fast is another persons too slow, relatively.


August 16, 2019
On Friday, 16 August 2019 at 13:46:01 UTC, Kagamin wrote:
> On Thursday, 15 August 2019 at 15:00:43 UTC, Atila Neves wrote:
>> I can take waiting 40s once a day. I can't take waiting >1s every time I build though.
>
> I just spent two weeks doing a biggish refactoring, I didn't safe files until the end. If I know it's not ready and won't work, and know what's left to do, why bother, it's just a waste of entropy.

There are people who work the way you do, and for them fast iteration cycles aren't important. I'm not one of them.
August 16, 2019
On Fri, Aug 16, 2019 at 02:05:54PM +0000, Exil via Digitalmars-d wrote:
> On Thursday, 15 August 2019 at 22:37:16 UTC, H. S. Teoh wrote:
> > On Thu, Aug 15, 2019 at 08:09:33PM +0000, Exil via Digitalmars-d wrote:
[...]
> > > D really isn't a fast language, or rather the only frontend is really really slow especially for CTFE.
> > 
> > I understand the sentiment, but I think it's an unfair comparison. If I were to implement in C++ the equivalent of the some CTFE functionality that's making my compilation slow, I'm almost certain the resulting C++ compile times will make dmd look like lightning speed by comparison.  CTFE *is* known to be slow, no question about that, but I suspect it's still a lot faster than what it would have taken to accomplish the same thing in C++.
> 
> Its a C++ project I converted, and it actually compiled faster in C++.

That's curious.  Is there any code you could share that demonstrates this?  I'm wondering if your implementation choices could be suboptimal as far as compile times are concerned.  But it's possible that CTFE is just that slow. :-/  (So much for that fast-fast-fast slogan. It's been making me cringe ever since it was introduced, and nobody else seems to think it's a problem. *shrug*)


> I was using my own program to do what I am doing on CTFE now. As a result I was able to optimize it myself.
[...]

Hold on, if you were using an external program to do what you're doing in CTFE now, that would explain the speed difference.  CTFE is currently an interpreter, and not a very good one at that (in terms of speed).

In my own D projects, I have no qualms about writing utility programs that generate D code that then gets compiled as part of the target executable.  In fact, some of the generated code I have involves pretty heavy-duty data processing from external data files. Running it in CTFE would be several orders of magnitude slower than just writing a code generator utility.  If compile times are important to you, I'd recommend taking this approach instead.


T

-- 
If lightning were to ever strike an orchestra, it'd always hit the conductor first.
August 16, 2019
On Friday, 16 August 2019 at 13:46:01 UTC, Kagamin wrote:
> On Thursday, 15 August 2019 at 15:00:43 UTC, Atila Neves wrote:
>> I can take waiting 40s once a day. I can't take waiting >1s every time I build though.
>
> I just spent two weeks doing a biggish refactoring, I didn't safe files until the end. If I know it's not ready and won't work, and know what's left to do, why bother, it's just a waste of entropy.

I was watching Jonathan Blow refactoring some code yesterday (https://www.youtube.com/watch?v=ndRrSGttlus), the process he used involves compiling through changes.

It takes some time doing this way, and of course running test cases together.

But in the end it's safer and I usually do this too.

Matheus.
August 18, 2019
On 2019-08-15 20:53, Exil wrote:

> Don't know any compiler that's that fast, definitely not D and not even Jai.

It highly depends on what kind of code you write. A simple application using DWT [1] takes 7.5 seconds to compile on my machine, using Docker and inside a virtual machine. DWT is around 400k lines of code and comments. But DWT is a port of the Java library SWT, so it contains very few templates and other compile time features.

[1] https://github.com/d-widget-toolkit/dwt

-- 
/Jacob Carlborg
1 2 3 4 5 6
Next ›   Last »