July 24, 2013
Adam D. Ruppe:

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

I understand. I think D should introduce simple optimizations to remove some array bound tests safely.

Recently one of my enhancement requests on this was implemented and merged, it will be present in 2.064.

And I have other simple suggestions:
http://d.puremagic.com/issues/show_bug.cgi?id=10685

There are some more refined ideas here, that need more implementation efforts:
http://ssw.jku.at/Research/Papers/Wuerthinger07/Wuerthinger07.pdf

More info:
https://wikis.oracle.com/display/HotSpotInternals/RangeCheckElimination

Bye,
bearophile
July 24, 2013
On Jul 24, 2013 4:16 PM, "Adam D. Ruppe" <destructionator@gmail.com> 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.
>
> 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.

Incase someone hasn't already pointed out.  Bounds checking is *always* done in @safe code.  :)

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';


July 24, 2013
On Wednesday, 24 July 2013 at 11:32:17 UTC, bearophile wrote:
> Compiling with LDC2 I have found Xorshift about as fast as C rand :-)

Excellent! I'm away from computer for a week so couldn't check myself.

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

The bug with Xorshift that was the real blocker here has been fixed. As far as defaults go, though, Mersenne Twister still has overall better statistical quality (though Xorshift is good -- it fails only the strictest tests of randomness). MT is also something of an "industry standard" for quality random number generation.

If I recall right there was a suggestion that the default RNG type Random should be target-dependent, so e.g. for a low-powered device it might be better to make Xorshift the default.

There have also been some other RNGs developed recently that match Xorshift for speed but have better statistical properties. I have the papers and it's probably worth looking into adding these to Phobos.
July 24, 2013
On 7/24/13 2:43 AM, monarch_dodra wrote:
> 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 :/

What are the other problems aside from value semantics?

Andrei
July 24, 2013
On Wed, Jul 24, 2013 at 12:54:19PM -0700, Andrei Alexandrescu wrote:
> On 7/24/13 2:43 AM, monarch_dodra wrote:
[...]
> >The whole of std.random is nothing but problems and pitfalls, biting us and our users on a regular basis :/
> 
> What are the other problems aside from value semantics?
[...]

Value semantics for RNGs are a *gigantic* pitfall.  Joseph Rushton Wakeling has pointed out some side-effects such as producing sequences with bad randomness properties (e.g. first element of two RNGs identical, the rest not; or first element of two RNGs different but the rest identical, etc.).

We need to get rid of value semantics for RNGs, and we need to get rid of it *now*.


T

-- 
Truth, Sir, is a cow which will give [skeptics] no more milk, and so they are gone to milk the bull. -- Sam. Johnson
July 24, 2013
On Wednesday, 24 July 2013 at 20:05:42 UTC, H. S. Teoh wrote:
> On Wed, Jul 24, 2013 at 12:54:19PM -0700, Andrei Alexandrescu wrote:
>> On 7/24/13 2:43 AM, monarch_dodra wrote:
> [...]
>> >The whole of std.random is nothing but problems and pitfalls, biting
>> >us and our users on a regular basis :/
>> 
>> What are the other problems aside from value semantics?
> [...]
>
> Value semantics for RNGs are a *gigantic* pitfall.  Joseph Rushton
> Wakeling has pointed out some side-effects such as producing sequences
> with bad randomness properties (e.g. first element of two RNGs
> identical, the rest not; or first element of two RNGs different but the
> rest identical, etc.).
>
> We need to get rid of value semantics for RNGs, and we need to get rid
> of it *now*.
>
>
> T

We need auto ref.
SCNR
July 24, 2013
On Wednesday, 24 July 2013 at 19:54:19 UTC, Andrei Alexandrescu wrote:
> What are the other problems aside from value semantics?

The serious problems mostly derive _from_ the value semantics. They include the annoying (if you forget to add "ref" when passing to a function, the source RNG won't get updated and your program will have unwanted correlations) and the critical (you can't safely store a copy of an RNG inside another object without it being a copy, which again means the source RNG won't be updated); this latter means that the design of ranges that "wrap" an RNG, like RandomCover and RandomSample, can't be given an arbitrary RNG to use without generating unwanted correlations.

In short, having them as value types makes it impossible to design tools like RandomCover etc. to be correct, safe and straightforward.

There are other issues there, but they are mainly implementation errors that can be fixed (I've fixed several of them recently and will carry on doing so). All the fundamental problems stem from the value semantics.
July 24, 2013
On Wednesday, 24 July 2013 at 20:46:00 UTC, Joseph Rushton Wakeling wrote:
> There are other issues there, but they are mainly implementation errors that can be fixed (I've fixed several of them recently and will carry on doing so). All the fundamental problems stem from the value semantics.


I'm not sure my previous post was entirely clear or easy to understand, but I've given extensive descriptions of the problems in past threads. Difficult to write more clearly or at length now as I'm writing from phone not computer :-)
July 24, 2013
On Wednesday, 24 July 2013 at 18:28:55 UTC, Iain Buclaw wrote:
> On Jul 24, 2013 4:16 PM, "Adam D. Ruppe" <destructionator@gmail.com> 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.
>>
>> 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.
>
> Incase someone hasn't already pointed out.  Bounds checking is *always*
> done in @safe code.  :)
>
> Regards

And @safe is automatically inferred (on templates only still?) when possible? I don't like where this is going...
July 25, 2013
On Thursday, July 25, 2013 01:29:04 John Colvin wrote:
> And @safe is automatically inferred (on templates only still?) when possible? I don't like where this is going...

If you have code that you want to be explictly @system, then mark it with @system. That will override any attribute inference for @safe.

- Jonathan m Davis