Perlin noise benchmark speed

[dennis luehring via Digitalmars-d]

Am 20.06.2014 15:14, schrieb dennis luehring:
> Am 20.06.2014 14:32, schrieb Nick Treleaven:
>> Hi,
>> A Perlin noise benchmark was quoted in this reddit thread:
>>
>> http://www.reddit.com/r/rust/comments/289enx/c0de517e_where_is_my_c_replacement/cibn6sr
>>
>> It apparently shows the 3 main D compilers producing slower code than
>> Go, Rust, gcc, clang, Nimrod:
>>
>> https://github.com/nsf/pnoise#readme
>>
>> I initially wondered about std.random, but got this response:
>>
>> "Yeah, but std.random is not used in that benchmark, it just initializes
>> 256 random vectors and permutates 256 sequential integers. What spins in
>> a loop is just plain FP math and array read/writes. I'm sure it can be
>> done faster, maybe D compilers are bad at automatic inlining or something. "
>>
>> Obviously this is only one person's benchmark, but I wondered if people
>> would like to check their code and suggest reasons for the speed deficit.
>>
>
> write, printf etc. performance is benchmarked also - so not clear
> if pnoise is super-fast but write is super-slow etc...
>

using perf with 10 is maybe too small to give good avarge result infos
and also runtime startup etc. is measured - it not clear what is slower

these benchmarks should be seperated into 3 parts

runtime-startup
pure pnoise
result output - needed only once for verification, return dummy output 
will fit better to test the pnoise speed

are array bounds checks active?