foreach thoughts

Manu turkeyman at gmail.com
Wed Jan 15 14:53:22 PST 2014


On 16 January 2014 05:56, Marco Leise <Marco.Leise at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140116/3c6c9ff8/attachment-0001.html>


More information about the Digitalmars-d mailing list