Dynamic array comparison optimization: check for equal pointers?

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Wed Jun 3 13:46:00 UTC 2020


On 6/3/20 1:48 AM, Patrick Schluter wrote:
> On Tuesday, 2 June 2020 at 19:38:04 UTC, Johan wrote:
>> Hi all,
>>   I thought that we optimized dynamic array comparison with a check to 
>> see if the pointers are equal, but I don't see it in our array 
>> comparison implementation in druntime. Quick checking of glibc memcmp 
>> also showed that there is no short circuit for when the pointers of 
>> the slices are equal.
>>
>> I was expecting something like:
>> ```
>>   if ( sizes are not equal )
>>      return false;
>>   if ( pointers are equal  )
>>      return true;
>>   return memcmp;
>> ```
>>
>> I am surprised that memcmp itself does not implement the pointers are 
>> equal check. Is there a big impact of adding the shortcircuit check to 
>> prevent scanning memory?
> 
> memcmp() doesn't implement the check to avoid memcmp(NULL, NULL, length) 
> returning with 0 instead of segfaulting as it does if any of the 2 
> pointers in NULL.
> It's a case of consistant behaviour, either you tolerate NULL pointers 
> in all cases or you segfault in all cases.

Affirmative:

https://code.woboq.org/userspace/glibc/string/memcmp.c.html#301

My take on the original matter is - adding an easily-predictable branch 
is unlikely to affect speed in the most naive speculative execution 
hardware. However, prediction does take resources that would be 
otherwise available for other branches, and the branch adds to code 
size. Both of these are important in large applications. So inserting a 
test will look good in microbenchmarks but may be actually a negative in 
real-world use.


More information about the Digitalmars-d mailing list