Memcmp is the most efficient way to compare large chunks of data

Re:Memcmp is the most efficient way to compare large chunks ... by rurban on Friday May 04, 2018 @11:15PM (#17000137)

Op implemented a poor version of timingsafe_memcmp, which is of course slow. His other HN post today is also full of such errors.

I even don't agree with the major premise that the libc version should be always preferred. In fact memcmp and memcpy can be made much faster.

At http://blogs.perl.org/users/rurban/2014/08/perfect-hashes-an... I wrote a jit like memcmp with switching on wordsized chunks which is 200x faster than memcmp.

And I benchmarked my safelibc implementation of memcpy_s with a good compiler, clang >4, beating the handoptimized and unsafe glibc assembler version by ~5%. gcc stinks there. https://github.com/rurban/safeclib/blob/master/tests/perf_me... Let the compiler optimize it.

But I saw much faster memcpy than this.

[ Parent | on HN ]

Re:Memcmp is the most efficient way to compare large chunks ... by eesmith on Saturday May 05, 2018 @01:50AM (#17000544)

Sure, they can be made faster.

I'm not going to spend my life on those sorts of optimizations unless there are good reasons.

[ Parent | on HN ]

Re:Memcmp is the most efficient way to compare large chunks ... by rurban on Tuesday May 08, 2018 @01:44AM (#17019072)

You don't see the point. The point is to write proper loops in C which the compiler can optimize. This the fastest way and benefits all platforms. Special cases which are actually slower should be removed. Compilers which are not able to optimize proper loop patterns should be fixed and documented as such. Haven't checked gcc-8 yet, but older versions should not be used for such core functions. libc should be compiled with clang.

[ Parent | on HN ]