Am 24.07.2013 09:39, schrieb dennis luehring:
> for an pure code-generation test he should implement the stdc random
> in pure D, go, Haskell whatever and get rid of the printf stuff - that
> would give better results

he could use this glibc like but simplified implementation of random
as a base for pure language generators

http://www.mathstat.dal.ca/~selinger/random/

On Wednesday, 24 July 2013 at 07:20:16 UTC, Peter Alexander wrote:
> This comment is worrying:
>
> "Can you try D version without std.random, and use srand and rand from std.c.stdlib? I think it should be almost same speed as C version ;-)"
>
> "Wow! Just tried that, and this brings the running time of the DMD-compiled version to 0.770s from 1.290, the GDC-compiled version from 1.060 to 0.680s, and the LDC version to 0.580s from 0.710s. Meaning the LDC version is on par with the Clang-compiled C version and just slightly beats the GCC-compiled C one! There really should be a warning note in the std.random library documentation that for performance-critical code the C stdlib random generator is a better choice."
>
>
> Is this just because RNGs are value types? It's literally causing bad press for D, so this needs to be high on the priority list.

RNGs should be passed by ref so if that isn't happening, there might be a speed hit (there will also be noticeable statistical problems). But the posted code just used rndGen and didn't pass anything.

C stdlib rand() is fast but has terrible statistical performance. Mersenne Twister is fast relative to its (high) statistical quality, but will still be slower than something designed purely for speed without concern for quality.

It'd be interesting to see how the speeds go if Xorshift was used in place of Mersenne Twister, that should give a big speed boost while still having high statistical quality.

On Wednesday, 24 July 2013 at 07:20:16 UTC, Peter Alexander wrote:
> This comment is worrying:
>
> "Can you try D version without std.random, and use srand and rand from std.c.stdlib? I think it should be almost same speed as C version ;-)"
>
> "Wow! Just tried that, and this brings the running time of the DMD-compiled version to 0.770s from 1.290, the GDC-compiled version from 1.060 to 0.680s, and the LDC version to 0.580s from 0.710s. Meaning the LDC version is on par with the Clang-compiled C version and just slightly beats the GCC-compiled C one! There really should be a warning note in the std.random library documentation that for performance-critical code the C stdlib random generator is a better choice."
>
>
> Is this just because RNGs are value types? It's literally causing bad press for D, so this needs to be high on the priority list.

The whole of std.random is nothing but problems and pitfalls, biting us and our users on a regular basis :/

Designing a new "std.random2" or "std.rand" should be high on our todo list. That, and I think "std.random" should go the way of "std.xml": A big fat warning telling users it is doomed for replacement, and, perhaps, a brief explanation of the problems, and their potential workarounds.

On Wednesday, 24 July 2013 at 09:43:12 UTC, monarch_dodra wrote:
> Designing a new "std.random2" or "std.rand" should be high on our todo list. That, and I think "std.random" should go the way of "std.xml": A big fat warning telling users it is doomed for replacement, and, perhaps, a brief explanation of the problems, and their potential workarounds.


It's on my list. As you know I've in the short term been trying to fix all the issues that can be fixed without breaking the API. I will try and follow up next month with a more concrete random2 spec and sample code.

Joseph Rushton Wakeling:

> It'd be interesting to see how the speeds go if Xorshift was used in place of Mersenne Twister, that should give a big speed boost while still having high statistical quality.

There is a version with xorshift:
http://codepad.org/ecw8aPFu

Bye,
bearophile

On Wednesday, 24 July 2013 at 07:20:16 UTC, Peter Alexander wrote:
> This comment is worrying:
>
> "Can you try D version without std.random, and use srand and rand from std.c.stdlib? I think it should be almost same speed as C version ;-)"
>
> "Wow! Just tried that, and this brings the running time of the DMD-compiled version to 0.770s from 1.290, the GDC-compiled version from 1.060 to 0.680s, and the LDC version to 0.580s from 0.710s. Meaning the LDC version is on par with the Clang-compiled C version and just slightly beats the GCC-compiled C one! There really should be a warning note in the std.random library documentation that for performance-critical code the C stdlib random generator is a better choice."
>
>
> Is this just because RNGs are value types? It's literally causing bad press for D, so this needs to be high on the priority list.

The c stdlib random number generation isn't very random.

There should be a note in std.random docs warning that it's slower but better than the c stdlib version.

John Colvin:

> There should be a note in std.random docs warning that it's slower but better than the c stdlib version.

Compiling with LDC2 I have found Xorshift about as fast as C rand :-)

So I suggested to make Xorshift the default one, but people rightly answered the standard one should be the safe (this means good) generator. On the other hand a note in the Phobos docs is a good idea.

Bye,
bearophile

CJS:

> reddit link:

As suggested by Walter I think all D compilers could add a switch like "-Of" that equals "-O -release -inline -noboundscheck". (It's better to not call it "-O3" because ldc2 has already a -O3 switch with different semantics.)

Bye,
bearophile

On Wednesday, 24 July 2013 at 12:46:26 UTC, bearophile wrote:
> As suggested by Walter I think all D compilers could add a switch like "-Of" that equals "-O -release -inline -noboundscheck".

I'm not comfortable with the recommendations for -noboundscheck because I see the bounds check as a good thing and use it in all my real world code. Getting used to turning it off regularly kinda torpedoes the whole memory safety thing D offers.

Though perhaps you could turn it off for one module - I think with separate compilitation you could make one with -inline -noboundscheck then link it in to the rest of the app compiled normally. That might be worth it.

On Wednesday, 24 July 2013 at 15:11:40 UTC, Adam D. Ruppe wrote:
> On Wednesday, 24 July 2013 at 12:46:26 UTC, bearophile wrote:
>> As suggested by Walter I think all D compilers could add a switch like "-Of" that equals "-O -release -inline -noboundscheck".
>
> I'm not comfortable with the recommendations for -noboundscheck because I see the bounds check as a good thing and use it in all my real world code. Getting used to turning it off regularly kinda torpedoes the whole memory safety thing D offers.
>

Yes, especially since we have arr.ptr[index] that access array without bound check. This is @system, as it should be.

> Though perhaps you could turn it off for one module - I think with separate compilitation you could make one with -inline -noboundscheck then link it in to the rest of the app compiled normally. That might be worth it.