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.

On 20/06/2014 13:32, Nick Treleaven wrote:
> It apparently shows the 3 main D compilers producing slower code than
> Go, Rust, gcc, clang, Nimrod:

Also, it does appear to be using the correct compiler flags (at least for dmd):
https://github.com/nsf/pnoise/blob/master/compile.bash

On Friday, 20 June 2014 at 12:34:55 UTC, Nick Treleaven wrote:
> On 20/06/2014 13:32, Nick Treleaven wrote:
>> It apparently shows the 3 main D compilers producing slower code than
>> Go, Rust, gcc, clang, Nimrod:
>
> Also, it does appear to be using the correct compiler flags (at least for dmd):
> https://github.com/nsf/pnoise/blob/master/compile.bash

-release is missing, although that probably isn't playing a big role here.

Another minor issues is that Noise2DContext isn't final, making the calls to get virtual.

This should cause such a big difference though. Hopefully somebody can investigate this more closely.

David

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...

On Friday, 20 June 2014 at 12:56:46 UTC, David Nadlinger wrote:
> On Friday, 20 June 2014 at 12:34:55 UTC, Nick Treleaven wrote:
>> On 20/06/2014 13:32, Nick Treleaven wrote:
>>> It apparently shows the 3 main D compilers producing slower code than
>>> Go, Rust, gcc, clang, Nimrod:
>>
>> Also, it does appear to be using the correct compiler flags (at least for dmd):
>> https://github.com/nsf/pnoise/blob/master/compile.bash
>
> -release is missing, although that probably isn't playing a big role here.
>
> Another minor issues is that Noise2DContext isn't final, making the calls to get virtual.
>
> This should cause such a big difference though. Hopefully somebody can investigate this more closely.
>
> David

struct can be used instead of class

On 06/20/2014 02:34 PM, Nick Treleaven via Digitalmars-d wrote:
> On 20/06/2014 13:32, Nick Treleaven wrote:
>> It apparently shows the 3 main D compilers producing slower code than Go, Rust, gcc, clang, Nimrod:
>
> Also, it does appear to be using the correct compiler flags (at least
> for dmd):
> https://github.com/nsf/pnoise/blob/master/compile.bash
I added some final pure @safe stuff

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?

On 06/20/2014 02:56 PM, David Nadlinger via Digitalmars-d wrote:
> On Friday, 20 June 2014 at 12:34:55 UTC, Nick Treleaven wrote:
>> On 20/06/2014 13:32, Nick Treleaven wrote:
>>> It apparently shows the 3 main D compilers producing slower code than Go, Rust, gcc, clang, Nimrod:
>>
>> Also, it does appear to be using the correct compiler flags (at least
>> for dmd):
>> https://github.com/nsf/pnoise/blob/master/compile.bash
>
> -release is missing, although that probably isn't playing a big role here.
>
> Another minor issues is that Noise2DContext isn't final, making the calls to get virtual.
>
> This should cause such a big difference though. Hopefully somebody can investigate this more closely.
>
> David
I converted Noise2DContext into a struct, I gone add some more to my patch

On Friday, 20 June 2014 at 13:14:04 UTC, dennis luehring wrote:
> write, printf etc. performance is benchmarked also - so not clear
> if pnoise is super-fast but write is super-slow etc...

Indeed and using Windows (At least 8), the size of command-window (CMD) interferes in the result drastically... for example: running this test with console maximized will take: 2.58s while the same test but in small window: 2.11s!

Matheus.

On Friday, 20 June 2014 at 13:20:16 UTC, Robert Schadek via Digitalmars-d wrote:
> I added some final pure @safe stuff

Thanks. As a general comment, I'd be careful with suggesting the use of pure/@safe/… for performance improvements in microbenchmarks. While it is certainly good D style to use them wherever possible, it might lead people less familiar with D to believe that fast D code needs a lot of annotations.

David