Re: [boost] [UUID] PODness Revisited

Subject: Re: [boost] [UUID] PODness Revisited
From: Vladimir Batov (batov_at_[hidden])
Date: 2008-12-24 20:18:41

OK, I thought some more about those PODs and I admittedly do not see any 
magic in that Poor Old Dude. Scott, you are clearly excited about them, so 
pls help me out here. That's what *I* see (caveat: I admit not knowing much 
about Boost.MPI and Boost.Interprocess requirements and expectations).

1. Boost.MPI efficiency does not seem to rely on PODness. Rather it seem to 
be due to serialization (or rather ability to bypass it). I feel, that 
Andy's UUID class is well-suited to add no-serialization transmission 
functionality when needed (without the rest of us paying for that). That is, 
conceptually Andy's full-fledged UUID does not have that limitation. If it 
is a MPI implementation-specific restriction/limitation, I'd expect we'd 
look at addressing it in MPI rather than shaping other classes to match it. 
In fact, after glancing over I felt I could do it by specializing 
is_mpi_datatype or is_mpi_builtin_datatype. I might easily have gotten it 
wrong though.

2. Scott, you correctly mention that most often we "don't want to send UUIDs 
by themselves". The thing is that chances of that bigger class being a POD 
are diminishing dramatically (if not already infinitely close to 0).

3. As for deployment of an object in shared memory, it does not have to be a 
POD either. Any non-virtual object can be placed to and accessed in shared 
memory as-is (this statement is certainy an oversimplification but I won't 
be listing all ifs and buts). Even virtual classes can be "massaged" 
(vtbl-pointer adjusted/restored before usage) in shared memory (quite a 
hassle though). I was able to find something of that kind that I did in my 
previous life (http://adtmag.com/joop/carticle.aspx?ID=849).

Best,
V.

> On IRC today, Dodheim made an excellent point: A uuid should be a POD,
> because that way it interacts better with Boost.MPI and
> Boost.Interprocess.
>
> MPI seems like an absolutely perfect situation in which to use UUIDs.
> However, going through serialization can more than 10 times slower
> than using using datatypes[1].  For something to be a datatype, it
> needs to be a POD[2], and thanks to the portable binary format, uuids
> can always use the BOOST_IS_BITWISE_SERIALIZABLE[3][4] trait since a
> UUID's bit format is independent of endianness and word size.
>
> [1] http://www.boost.org/doc/libs/1_37_0/doc/html/mpi/performance.html
> [2] 
> http://www.boost.org/doc/libs/1_37_0/doc/html/boost/mpi/is_mpi_datatype.html
> [3] 
> http://www.boost.org/doc/libs/1_37_0/doc/html/mpi/tutorial.html#mpi.homogeneous_machines
> [4] 
> http://www.boost.org/doc/libs/1_37_0/libs/serialization/doc/traits.html#templates
>
> Of course, you don't want to send UUIDs by themselves.  This is even a
> bigger point, since if uuid isn't a POD, then sending composite types
> that include UUIDs pay the price of going through serialization too,
> even when they could have done the cheap way normally.
>
> Similarly, making uuid a POD allows it to be placed in
> Boost.Interprocess shared memory without the cost of going through
> serialization.  For example, "A message queue just copies raw bytes
> between processes and does not send objects"[5], which requires a POD
> without member pointers to be safe.
>
> [5] 
> http://www.boost.org/doc/libs/1_37_0/doc/html/interprocess/synchronization_mechanisms.html#interprocess.synchronization_mechanisms.message_queue
>
> I think that these are two good examples that POD is the
> quintessential form for a value type, not something "clearly dragged
> in due to backward compatibility with C"[6].  In addition, note that
> even Boost.Proto, one of the fancier libraries in Boost, uses
> aggregates extensively[7].
>
> [6] http://permalink.gmane.org/gmane.comp.lib.boost.devel/184223
> [7] 
> http://www.boost.org/doc/libs/1_37_0/doc/html/proto/appendices.html#boost_proto.appendices.rationale.static_initialization
>
> It's also trivial for someone to build a non-POD out of the pod should
> they desire:
>
> namespace vladimir {
>    struct uuid : boost::uuid {
>        uuid() : boost::uuid(boost::uuids::native_generator()()) {}
>        uuid(boost::uuid id) : boost::uuid(id) {}
>    };
> }
>
> ~ Scott
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost
>