On 16 January 2014 05:56, Marco Leise <Marco.Leise@gmx.de> wrote:

>
> For a moment, I thought the performance crew lost you. :)
>

Haha, don't worry, that'll never happen! ;)

I'm just trying to be more open minded in this code I'm writing.
I bring a lot of C/C++ baggage to my D code, so I'm trying to write it in
the most idiomatic D way I can, and then I'll do a thorough performance
analysis later, and see how far south it went (and what the optimisers we
able to do in practise)...
Experience from C/C++ makes me over-cautious wrt performance these days.
Modern optimisers are more reliable than the ones I've spent a decade
trying to wrestle to do what I want them to.

That said though, I still believe there's value in writing explicitly fast code. If you're quite direct, then it doesn't rely so much on an optimiser, and more importantly, it will continue to run well-ish in non-optimised builds. I'm really wrestling with that; it's not a property I'm comfortable to give up, and all these little templates everywhere that do trivial little things are probably going to interfere with non-optimised performance in a way that exceeds my worst nightmares in C++.

D's foreach is awesome. Remember this benchmark?
>
> http://togototo.wordpress.com/2013/08/23/benchmarks-round-two-parallel-go-rust-d-scala-and-nimrod/
> The top entry's performance is due to how well LDC2 optimized
> the foreach, otherwise the code is quite the same as the C++
> version.
>

Indeed, and I had just presumed that LDC would properly optimise these little functions we're discussing. Rather surprised to learn it doesn't. Hopefully it's not so hard to improve with some time.

On Wednesday, 15 January 2014 at 01:28:26 UTC, Manu wrote:
> You can't step a -O build, or inspect the value of most variables. So you
> can't really debug.

The problem with optimizations is that code mutates a lot. Can you expect the debugger to step through inlined functions? Loop merging can be even more evil in this regard.