On Thursday, 19 March 2015 at 17:40:46 UTC, weaselcat wrote:
On Thursday, 19 March 2015 at 16:59:36 UTC, Ola Fosheim Grøstad
If the code/compiler generates suboptimal code in the first
place then improvements can be somewhat random. But if you
write code with good cache locality, filling the pipeline
properly then there is no alternative to going low level.
Btw, take a look at this:
http://stackoverflow.com/questions/28922323/improving-line-wise-i-o-operations-in-d
That's really bad marketing...
[…]
ldc -O5 -inline -release -boundscheck=off wc.d
time ./wc enwiki-latest-pages-articles1.xml-p000000010p000010000
There are 1245473 lines.
./wc enwiki-latest-pages-articles1.xml-p000000010p000010000
0.04s user 0.08s system 98% cpu 0.125 total
ahem
I actually found that LDC does an _amazing_ job of optimizing
high level constructs and converting "low level" code to
I think you missed my point here. A simple loop like this should
result in similar execution times for all AoT languages with
decent library support and optimisation because it ought to be
bandwidth limited, not CPU limited. The issue here is that when
decent programmers end up asking for help on stackoverflow it
exposes underlying library/compiler/language issues that needs
addressing on way or another.
When it comes to more complicated algorithms then it usually
impossible for a high level construct to match a low level one
for several reasons, a major one being that you need to tailor
the algorithm to OS/caches/ALU/CPU. Pure high level code cannot
easily be reduced to high quality iterative algorithms that match
the hardware.
High level constructs may be cleaner if done right, and
sometimes saves programmer time, but it will never be as fast on
the standard CPU architectures we have today. The hardware
favours carefully planned iterative, imperative approaches. That
was true before SIMD and caching, and it is even more true now.
Try to do some signal processing and you'll quickly learn that
high level code is out of the question if you want high
performance.
