|
From: Philippe W. <phi...@sk...> - 2011-03-03 22:39:47
|
I do not understand why the comparison function below is
done like that. It looks very sophisticated compared to the
simpler comparison which is given after.
Is there a reason to have the sophisticated version ?
static Word cmp_WordVecs_for_FM ( UWord wv1W, UWord wv2W )
{
UWord i;
WordVec* wv1 = (WordVec*)wv1W;
WordVec* wv2 = (WordVec*)wv2W;
UWord common = wv1->size < wv2->size ? wv1->size : wv2->size;
for (i = 0; i < common; i++) {
if (wv1->words[i] == wv2->words[i])
continue;
if (wv1->words[i] < wv2->words[i])
return -1;
if (wv1->words[i] > wv2->words[i])
return 1;
tl_assert(0);
}
/* Ok, the common sections are identical. So now consider the
tails. Both sets are considered to finish in an implied
sequence of -infinity. */
if (wv1->size < wv2->size) {
tl_assert(common == wv1->size);
return -1; /* impliedly, wv1 contains some -infinitys in places
where wv2 doesn't. */
}
if (wv1->size > wv2->size) {
tl_assert(common == wv2->size);
return 1;
}
tl_assert(common == wv1->size);
return 0; /* identical */
}
The below looks simpler and I believe more efficient. The order will
be different than of the above, but I have not seen where the specific
order implemented by the above cmp is significant.
At least the helgrind tests give the same results with the below.
static Word cmp_WordVecs_for_FM ( UWord wv1W, UWord wv2W )
{
UWord i;
WordVec* wv1 = (WordVec*)wv1W;
WordVec* wv2 = (WordVec*)wv2W;
// WordVecs with smaller size are smaller.
if (wv1->size < wv2->size) {
return -1;
}
if (wv1->size > wv2->size) {
return 1;
}
// Sizes are equal => order based on content.
for (i = 0; i < wv1->size; i++) {
if (wv1->words[i] == wv2->words[i])
continue;
if (wv1->words[i] < wv2->words[i])
return -1;
if (wv1->words[i] > wv2->words[i])
return 1;
tl_assert(0);
}
return 0; /* identical */
}
|
|
From: Julian S. <js...@ac...> - 2011-03-04 23:51:27
|
> Is there a reason to have the sophisticated version ? Er .. I can't think of one :-) > The below looks simpler and I believe more efficient. The order will > be different than of the above, but I have not seen where the specific > order implemented by the above cmp is significant. Looks good to me. I'll commit it in the morning. I think the general inefficiency of the laog mechanism (I am amazed that it takes 1.4GB in your tests) is partly because you are really the first person to seriously try to tune/optimize it. So you are seeing a lot of stupidity in my initial implementation. J |
|
From: Julian S. <js...@ac...> - 2011-03-07 19:16:45
|
On Thursday, March 03, 2011, Philippe Waroquiers wrote: > The below looks simpler and I believe more efficient. I agree! Committed, r11609. Thanks. J |