src: improve base64 encoding performance

[mscdex]

Benchmark results on a Core i7-3770K:

                                                   confidence improvement accuracy (*)   (**)  (***)
buffers/buffer-base64-encode.js n=32 len=67108864        ***     15.94 %       ±0.11% ±0.14% ±0.18%

I was tempted to run the benchmark on ARM out of curiosity, but I don't have a machine with a new enough build environment or one that I can easily swap the OS at the moment and trying to cross compile node.js with a Linaro aarch64 toolchain is impossible.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/39506/

[benjamingr]

The improvement (sure you tested with -O3 in both cases right?) is somewhat surprising but sure.

[mscdex]

sure you tested with -O3 in both cases right?

-O3 is the default in node builds, which I did not touch.

is somewhat surprising

I'm not as surprised considering this is reading more bytes per loop iteration (and in one go) than before, which is not something I'm sure a compiler would necessarily know to do.

[benjamingr]

Yeah I of course believe you and assumed it's run with -O3 (otherwise I wouldn't have LGTMd) I'm just surprised about:

which is not something I'm sure a compiler would necessarily know to do.

It sounds like a pretty safe and straightforward form of loop unrolling which is a fairly simple/standard optimisation

[tniessen]

Some architectures don't support unaligned 64-bit access, so this could end up being somewhat slower on those. But still an optimization on most systems!

[mscdex]

That's why I was curious to check on ARM. However from what I'm seeing ARMv7 and newer support unaligned reads, with ARMv7 supposedly not supporting them for only 2 instructions?

[Flarna]

Have you tried to start reading 1/4 bytes until 8 byte alignment is reached?

[mscdex]

Alright, after more wrangling than I wanted, I managed to get some armv7 binaries compiled and ran the benchmarks on a Pi 2B before and after the changes in this PR:

                                                  confidence improvement accuracy (*)   (**)  (***)
buffers/buffer-base64-encode.js n=32 len=67108864        ***      2.20 %       ±0.39% ±0.52% ±0.68%

I don't have an armv8 board available to test on.

[Mesteery]

I can run the benchmark on a Pi 4B. Should I compare with master or 16.6.1?

[Mesteery]

compared with 16.6.1 :

                                                  confidence improvement accuracy (*)   (**)  (***)
buffers/buffer-base64-encode.js n=32 len=67108864        ***      5.12 %       ±0.22% ±0.30% ±0.39%

[fhinkel]

Can you link the issue where this is too slow in the real world? Not sure 15% perf improvement on a synthetic benchmark warrants this change.

[mscdex]

Not sure 15% perf improvement on a synthetic benchmark warrants this change.

"Synthetic" benchmarks are all we have at the moment, after the benchmarking WG was dechartered/decommissioned. IMO base64 encoding/decoding is not something that I'd exactly call an uncommon task, especially within the realm of web applications.

In general, any sensible changes that provide a measurable improvement should be welcomed, especially considering the number of performance hits we continue to take on over time as features get added and as V8 evolves. The improvements all add up.

Anyway, as far as base64 encoding goes, I also have an alternative PR here that you may be more interested in. 🤷‍♂️

[mscdex]

Closing in favor of #39775