std.uuid: Update 4

[Dmitry Olshansky]

On 17.06.2012 12:36, Alex Rønne Petersen wrote:
> On 17-06-2012 10:22, Johannes Pfau wrote:
>> Am Sun, 17 Jun 2012 12:15:00 +0400
>> schrieb Dmitry Olshansky<dmitry.olsh at gmail.com>:
>>
>>> On 17.06.2012 12:04, Johannes Pfau wrote:
>>>> Am Sat, 16 Jun 2012 21:11:51 +0400
>>>> schrieb Dmitry Olshansky<dmitry.olsh at gmail.com>:
>>>>>
>>>>> Ah and another way to go about it is:
>>>>> union {
>>>>> ubyte[16] uuid;
>>>>> size_t[16/size_t.sizeof] by_word;
>>>>> }
>>>>>
>>>>
>>>> Isn't that an optimization which should really be done by the
>>>> compiler? It already knows that it's supposed to compare two
>>>> ubyte[16]...
>>>
>>> It knows that you compare two ubyte[16] that it.
>>> It easily might miss the fact that one of them is always 0 in all 16
>>> cells.
>>>
>>>>
>>>> Also how could the union solution be used without having to copy the
>>>> data?
>>>
>>> There is no copy it union, aka overlapped storage. In other words as
>>> these 16 bytes represented as (on 32bit) 4 size_t. They share memory
>>> location. It doesn't play nice with CTFE though, as it thinks unions
>>> to be plain struct last time I checked.
>>>
>>
>> Yes, I thought about using the union nested in the empty function, so a
>> copy would have been needed:
>>
>> bool empty()
>> {
>> union
>> {
>> ubyte[16] uuid;
>> ....
>> }
>> uuid = data; //copy
>> }
>>
>> I didn't know that it's possible to make members of a union private
>> though, so I could use this in the UUID struct:
>> union
>> {
>> ubyte[16] data;
>> private size_t[16/size_t.sizeof] by_word;
>> }
>>
>> which indeed wouldn't require copying. However, with this code added
>> std.uuid fails some unrelated ctfe UUID comparison unittests...
>
Then I suggest to just go with local performance hack:
bool empty() nothrow @safe ...
{
	if(__ctfe)
		return find!"a!=0"(data).empty; //simple

	size_t* p = cast(size_t*)data.ptr;
	static if(size_t.szieof == 4)
		return p[0] == 0 && p[1] == 0 && p[2] == 0 && p[3] == 0;
	else static if(size_t.sizeof == 8)
		return p[0] == 0 && [1] == 0;
	else
		static assert(false, "nonsense, it's not 32 or 64 bit");
}
> I wouldn't expect unions to be CTFE-safe at all. They allow
> reinterpreting anything as anything, which could screw everything up in
> a managed environment like the CTFE interpreter.
>
> Anyway, isn't this optimizing something that really doesn't need
> optimization? I'd be very surprised if this shows up in any profiling
> results at all.
>

The "pleasure" of writing standard library is that you'll never know 
what is bottleneck. All depends on users. And the more you have them the 
greater impact of things that have "one in a million" probability.

-- 
Dmitry Olshansky