Re: [boost] [uuids] On boost::uuids::uuid operator == performance.

Subject: Re: [boost] [uuids] On boost::uuids::uuid operator == performance.
From: Michael Kochetkov (michael.kv_at_[hidden])
Date: 2012-04-16 11:41:23

> even though uuid::data is uint8_t[16]. I see an assembly listing that is
virtually
> identical to the one you posted for _Equal, which is also just a memcmp
call:
You may probably want to make sure the Oi switch is present.

> inline bool __CLRCALL_OR_CDECL _Equal(const unsigned char *_First1,
>     const unsigned char *_Last1, const unsigned char *_First2,
>     random_access_iterator_tag, _Range_checked_iterator_tag)
>     {    // compare [_First1, _Last1) to [First2, ...), for unsigned chars
> #if _HAS_ITERATOR_DEBUGGING
>     _DEBUG_RANGE(_First1, _Last1);
>     if (_First1 != _Last1)
>         _DEBUG_POINTER(_First2);
> #endif /* _HAS_ITERATOR_DEBUGGING */
> 
>     return (::memcmp(_First1, _First2, _Last1 - _First1) == 0);
>     }
You have an indirection here and the original code has two indirections --
iterators plus _Equal call. As you may see this is too complex for MS
optimizer -- it looks like the optimizer loses the data size and alignment
information and gives up.

> I'm using VC++2005 though.
I do remember that at least memcpy intrinsic worked pretty smart in that
compiler. Though the optimizers of the subsequent versions are no doubt
better.

> Although in both cases, the loop that is actually executed is identical to
the
> one you give above.
You are right. And I was unable to make the VC to unroll it. That is why I
do believe the library that is intended to be used in commercial
applications shall do its best in manual optimization of evident cases. And
I believe the uint8_t data[16] is crystal evident case in all respects
including alignment issues.

--
Michael Kochetkov