Subject: Re: [boost] [uuids] On boost::uuids::uuid operator == performance.
From: Michael Kochetkov (michael.kv_at_[hidden])
Date: 2012-04-16 12:35:55
> That's not really a fair test since it's all in one compilation scope. I
try to just
> make an obj which has function which takes the stuff as a parameters like:
> void foo(boost::uuids::uuid&, boost::uuids::uuid&)
> Then the compiler cann't know where it aligned the thing on the stack or
> any other quick optimizations (beyond the alignment of the type).
It is fair as far as the data type is aligned regardless where it is placed:
in the heap or on the stack. If you do really want to foil the case you need
to get rid of data type information (as it was proposed with the conversion
to the pointer to char) and information about the data size.
> The fastest thing on x86 to do this might be an MMX instruction. I
> gcc doing MOVDQA to memset() a 16 byte structure. Though I remember it
> because it falsely assumed 16 byte alignment and crashed.
> Is your beef with the compiler?
> Looking at the code the performance would probably be better if a larger
> integer type were used and alignment>1.
I have no doubt that one can spoil any the most brilliant idea. And that is
what I see in boost: with iterators and intermediate Feng shui call it
leaves the stupid MS compiler no chances to deduce the original data type,
its size and alignment. Being the person who is called when a program
crashes or works very slow I am pretty happy with the current situation. But
while hacking another sami-failed project I was asked to join a company and
start a completely new project. So I just decide now if the boost is
suitable for early prototyping only or it may be used in the production too.
And I do not care much about the defects like this one -- they are trivial
to find and fix. I am more interested in people attitude on the problems
like this one because the modern C++ approach "a compiler will take care of
it" does not work for me. And as you may see I can prove my words.
-- Michael Kochetkov
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk