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.o...@gmail.com>:
On 17.06.2012 12:04, Johannes Pfau wrote:
Am Sat, 16 Jun 2012 21:11:51 +0400
schrieb Dmitry Olshansky<dmitry.o...@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
