Thread overview | |||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
June 20, 2014 Perlin noise benchmark speed | ||||
---|---|---|---|---|
| ||||
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. |
June 20, 2014 Re: Perlin noise benchmark speed | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Treleaven | 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 |
June 20, 2014 Re: Perlin noise benchmark speed | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Treleaven | 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
|
June 20, 2014 Re: Perlin noise benchmark speed | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Treleaven | 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...
|
June 20, 2014 Re: Perlin noise benchmark speed | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Nadlinger | 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
|
June 20, 2014 Re: Perlin noise benchmark speed | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Treleaven | 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
|
June 20, 2014 Re: Perlin noise benchmark speed | ||||
---|---|---|---|---|
| ||||
Posted in reply to dennis luehring | 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?
|
June 20, 2014 Re: Perlin noise benchmark speed | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Nadlinger | 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
|
June 20, 2014 Re: Perlin noise benchmark speed | ||||
---|---|---|---|---|
| ||||
Posted in reply to dennis luehring | 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.
|
June 20, 2014 Re: Perlin noise benchmark speed | ||||
---|---|---|---|---|
| ||||
Posted in reply to Robert Schadek | 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
|
Copyright © 1999-2021 by the D Language Foundation