Re: ideal interface for Random Number Generators?
On 2010-06-11 21:01:42 -1000, orz said:
There are a number of applications where serialization speed and/or
size is a major bottleneck, and if you really want me to find
profiling numbers on such an application I probably could, though
there are better uses for my time. Applications where serialization
speed is a bottleneck and RNGs make up a large fraction of what gets
serialized are MUCH more rare (but I could probably find performance
numbers for such an application too), and probably not worth worrying
about for the standard library. Still, I'm getting the impression
that the standard library (and you, Pete Becker) considers text based
serialization the only serious serialization,
Not at all. The standard library uses text because it's sufficient for
the library's design goals. Anything more is overdesign, and
inefficient use of programmer time.
which I find rather
disturbing. Binary serialization in general is not new, unproven,
hypothetical, or anything else like that.
Nobody said it was.
It applies to RNGs in
pretty much exactly the same way it applies to other simple data
structures. That is, it's significantly more efficient than text
serialization in terms of run-time speed, output size, and code
complexity,
Text has been portable in standard C for forty years. Binary has not
and is not.
though for simple data-structures it's usually much harder
for a human to interpret the output. That has all been well known and
thoroughly tested for the last 25 years if not longer. The helper
functions needed for binary serialization on unknown platforms are
already present in standards (frexp, ldexp, htonl, etc), though it's
more efficient if the serializing code knows what platform it's on at
compile time.
Funny thing: when you use text for serialization, the target platform
is known at compile time. The details are handled in the standard
library; you don't have to write any platform-specific code.
For binary serialization the standard would have to specify details of
the protocol, and, perhaps, helper functions that are not standard C or
C++ (e.g. htonl), and implement the translation layer. That's far more
complex than specifying and writing a text interface that sits on top
of the text conversion functions that have been around for forty years.
--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)