Re: ideal interface for Random Number Generators?
On 2010-06-10 20:54:27 -1000, orz said:
On Jun 10, 12:33?pm, Pete Becker <p...@versatilecoding.com> wrote:
On 2010-06-10 07:52:21 -1000, Keith H Duggar said:
On Jun 10, 1:22 pm, Pete Becker <p...@versatilecoding.com> wrote:
On 2010-06-09 19:52:14 -1000, orz said:
On Jun 9, 1:50 pm, Pete Becker <p...@versatilecoding.com> wrote:
The design of RNG serialization for TR1 includes use on non-homogeneous
systems. Binary representations just don't work for that.
If you're talking about endianness, I was presuming that endianness
would be taken care of in the serialization code. If you're talking
about floating point formats that's a bit harder but it could
certainly be taken care of more efficiently than conversion from and
to text. Why would binary RNG state serialization be harder?
Because text transfer already deals with all the issues that you're
going to have to ferret out and manage with your hypothetical binary
protocol.
So it seems more a choice to utilize an existing subsystem (ie
using the text serialization code rather than designing second
(binary) format serialization code) rather than a "binary just
doesn't work" situation?
After all, text is just binary with a certain format.
Shrug. Underneath it's all bits, too.
?And text
is designed not only to be portable but notably to be readable
to humans. Surely if one removes the human readable constraint
one can design a more efficient format that is still portable
across modes, machines, etc.
Maybe, but why do you want to do this? Have you shown that text has
inherent inefficiencies that produce significant bottlenecks for your
application? For the design goals of TR1 and C++0x, text is sufficient
and simple.
Text does have major bottlenecks for both state size and runtime
speed.
Non-answer. Again: have you shown that text has inherent inefficiencies
that produce significant bottlenecks for your application? Hint: you
need to establish that text is significantly slower than your
unspecified binary approach, then analyze how often your program has to
do this and compare that with how often it does other things. One good
tool for this is a profiler.
On the rare occasions when you wouldn't otherwise be linked
with string handling code it also forces that.
Shrug. On the rare occasions when you wouldn't otherwise be linked with
the code for handling your presently unspecified binary protocol it
also forces that.
I've seen code for a
few applications that needed to do fast serialization of RNG states
(on commercial game engine, one amateur game engine, and one research
project), though those are admittedly quite rare. It's also my
understanding that some scientific simulation projects like to
instantiate large numbers of RNGs and do periodic state saves on all
of them as well, potentially running in to issues with the total
serialized state size or serialization time, though I've never
actually seen code for such a project and am not really sure if that
could be an issue or not.
The folks at Fermilab do massive simulations on non-homogeneous
distributed systems. They're the ones who wanted serialization in the
TR1 RNGs. And they're responsible for the text specification for that.
So, again, have you made measurements that show that any application
gets a significant performance hit from the use of text? Note that the
key word here is "application", not "operation that an application
sometimes does".
--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)