Hexdump Alternatives

hexdump reviews and mentions

• Why LuaJIT's interpreter is written in assembly
  4 projects | news.ycombinator.com | 11 Feb 2021

  It's not just as fast, but the difference is much less. For example, my hexdump (https://github.com/wahern/hexdump) clone compiles format specifications to bytecode for a tiny built-in VM. If I compile with VM_FASTER=1 (the default if __GNUC__ is defined), I still get an ~10% speed-up on Intel Core i9 (2019 MacBook Pro over compiling with VM_FASTER=0. Interestingly, I only get an ~5% speed-up on M1 (2020 MacBook Air), and on my AMD EPYC 3251 an ~2% slow-down unless I compile with -march=native, in which cases there indeed is no appreciable difference.

  Note that I'm rounding speed-up percentages down. Using Apple clang version 12.0.0 on the i9 and M1, and GCC 9.3.0 on the EPYC. Running `LC_ALL=C time ./hexdump -C /dev/null`. Switching between -O2 and -O3 doesn't seem to change relative gains. Ditto for using using -march=native except on EPYC.

  I don't have a pre-Haswell box around to test, but IIRC the difference used to be 30% or greater.

  Also, AFAIU GCC and clang have improved their switch statement support. For many years GCC and clang didn't actually optimize switch statements as well as the literature or what students were taught. Aggressive switch statement optimizations resulted in too many performance regressions in real-world applications. It seems only in the past few years have GCC and clang figured out how to apply those optimizations more aggressively while avoiding performance regressions.