A few notes on choosing between Go and D for a quick project

[via Digitalmars-d]

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.