yes there are many implementations of MT. The C++11 standard specifies the interface, the required O() of operators, and the exact numerical results (the 10.000th draw must be X). So all MT need to implement the exact same algorithm, but like any C++ aspect each compiler vendor is free to implement things the way they want.

OK, clear. Different implementations. hehe

Yes,.. that goed for *anything*, even the baseline "allocating a std::vector" or sin(x) will be implemented differently by different vendors. If it wasn't there wouldn't be much point in having different compilers. 

Boost MT > C++11 MT.

So, what would your advice be to a QuantLib developer who want to move from Boost  Random to C++ <random>?

They are not the same, it seems. After migration, performance degrades by a factor of 2 unless we have overlooked sumfing really important.

.. but the exact same numbers coming out of the rng!

I haven't looked too much, not really my interest nor area. I am assuming RNG stuff is accurate. It is up to RNG folk to tell the rest of us why!
A few quants found speed differences as well.

hmm. you said "seems less accurate", I though you would have looked a little before saying something like that, and I assumed it could not boil down to observing sample noise. .. so to recoup: MT in boost and C++ give the exact same numbers.
Your assumption is right, the quality of MT has been tested by a lot of peope, thre are frameworks people use. I tested MT with the dieharder test suite which is a typical benchmark you see in papers, just out of curiosity to see how RNG qualities relate.
About the speed difference: it's quite common that different implementations perform differently. Boost also had its versions in the past, I remember some distribution algorithms were upgraded for speed reasons.
The link you gave tested boost MT against gcc 4.8 MT -which is an old compiler- (I've seen gcc 7.1).  As C++11 support matures (some compiler are still not compliant) you can expect the speed differences to go away,.. ..or not,..  some compiler have better generic optimizers than other compilers, making better use of het intstruction set, caches etc etc

OK, clear. Different implementations. hehe

Yes,.. that goed for *anything*, even the baseline "allocating a std::vector" or sin(x) will be implemented differently by different vendors. If it wasn't there wouldn't be much point in having different compilers. 

Boost MT > C++11 MT.

So, what would your advice be to a QuantLib developer who want to move from Boost  Random to C++ <random>?

They are not the same, it seems. After migration, performance degrades by a factor of 2 unless we have overlooked sumfing really important.

I would advice then to test it. It might be an issue on some compilers but not theirs. But in any case, only use the C++11 interface (and not legacy boost extension) when you can so that your code can easily switch between implementation.

I agree. But it is a bit shocking?

It's like buying  heating oil; each brand has its own efficiency.

I agree. But it is a bit shocking?

It's like buying  heating oil; each brand has its own efficiency.

Hahaha,
what I would expect is that at some point one open source compiler (and maybe MS too) will copy-paste the best implentation from other open source compilers/libraries?
When C++11 was still a draft some "reference libraries" were made to test the ideas that were going to be added to the standard. At the same time those reference libraries help vendors test their versions. Those reference libraries were strick w.r.t. to C++ language requirements (the interfaces, const correctness, copyconstructable or not, etc etc etc whatever)  but not so much aiming for optimal perfromance. I think boost math is very good in that respect, a lot of time was spent on optimizing algorithms. It also had many years to mature. At the same time boost math always puts precision and correct handeling of corner cases above performance, (it wants to be usable and correct, not fast) so I'm a bit surprised it's fast?

Boost 1.62 mt19937_64 is ~ 3 times faster than C++11 mt19937_64 using VS2015, Release+64bit mode.

So, is C++ really based on Boost?

The C++11 <random> *interface* is based on boost, most of the member functions are the same, most engines and distributions that were in boost are now in C++11. Boost predated C++11.

However, when you measure speed, you are looking at what MS decided to use for the implementation (or GCC) to write and ship. The C++11 standard doesn't provide an implementation, only requirements.

I don't think MS could have just copied the boost code because of the licenses?

Don't know much about this, but a 3-fold difference in performance because of different compiler implementations on something as widely used as rng seems unlikely to me.

Don't know much about this, but a 3-fold difference in performance because of different compiler implementations on something as widely used as rng seems unlikely to me.

You'll never know unless you try it  
And if you look at the links, there is evidence. So. PROVE THEM WRONG.

I'm busy with other things. Do the links suggest this happens with VS only or other compilers as well? If it's only VS then that's pretty bad by MS...

No, the link compare boost vs GCC 4.8 (which could be as old as 2013).

I can give it a try on OSX xcode compiler if I have boost already installed (I hate installing boost, I'd rather clean the bathroom)

lol

lol

Seems I'm the only one here with data on this. 

No, the link compare boost vs GCC 4.8 (which could be as old as 2013).

So, gcc 4.8 was no good? will 5.x be any better??? Wishful thinking IMHO

lol

Seems I'm the only one here with data on this. 

Have you guys ideas on this instead of installing  Boost (which BTW is a piece of cake on VS2017). A stint down the mines. This is guesswork.