Especially after Carlo's comment from earlier that attention is paid to not inlining unnecessarily it is surprising that the random_device code is inlined even though it is not a template class.
How about not doing this and moving the definition into the library? This is done in the attached patch. It's rather ugly because of the business with the TR1 support. Is this really still needed? Can't we remove that? It really makes not much sense for a random_device to be predictable. Also, very important, with the current definition the size and layout of the random_device objects depends on the _GLIBCXX_USE_RANDOM_TR1 macro. The patch fixes this. The data elements must be in a union or all available all the time. Still, I'd prefer to just remove the code that uses mt19937... This would also mean the object size won't change. Anyway, another change in the patch is support for a less expensive implementation on Ivy Bridge processors. That processor has the rdrand instruction. The code uses it if the instruction is usable. Has been tested on real hardware. This is not the type of arch-specific code I meant earlier. Will get to that tomorrow. There are other architectures with similar instructions. Adding support for those will be simple.
PP1
Description: Binary data
