libc: Optimise memcpy() #10

Sirraide commented 2022年10月28日 19:40:03 +02:00

This pr fixes some bugs in libc and adds an optimised memcpy() implementation.

Below is a benchmark comparing this implementation (‘intrin’) to glibc (‘glibc’).

I have also attached a C++ program using libbenchmark that can be used to reproduce the benchmark (compile and run w/ gcc -std=c++23 -O3 -march=native test.cc -lstdc++ -lbenchmark -lfmt -o test && ./test).

-----------------------------------------------------------------------
Benchmark Time CPU Iterations
-----------------------------------------------------------------------
glibc (16 bytes) 0.207 ns 0.207 ns 1000000000
intrin (16 bytes) 0.204 ns 0.204 ns 1000000000
glibc (128 bytes) 1.62 ns 1.62 ns 429990997
intrin (128 bytes) 0.203 ns 0.203 ns 1000000000
glibc (1,024 bytes) 7.08 ns 7.08 ns 95637792
intrin (1,024 bytes) 0.616 ns 0.616 ns 1000000000
glibc (3,175 bytes) 30.2 ns 30.2 ns 23306688
intrin (3,175 bytes) 1.83 ns 1.83 ns 381575116
glibc (4,096 bytes) 33.0 ns 33.0 ns 21048745
intrin (4,096 bytes) 26.4 ns 26.4 ns 26498355
glibc (16,384 bytes) 114 ns 114 ns 6106968
intrin (16,384 bytes) 106 ns 106 ns 6605032
glibc (1,048,576 bytes) 17045 ns 17038 ns 41071
intrin (1,048,576 bytes) 15788 ns 15781 ns 44592
glibc (1,000,000,000 bytes) 58602936 ns 58570277 ns 12
intrin (1,000,000,000 bytes) 52938424 ns 52901710 ns 13

This pr fixes some bugs in libc and adds an optimised `memcpy()` implementation. Below is a benchmark comparing this implementation (‘intrin’) to glibc (‘glibc’). I have also attached a C++ program using libbenchmark that can be used to reproduce the benchmark (compile and run w/ `gcc -std=c++23 -O3 -march=native test.cc -lstdc++ -lbenchmark -lfmt -o test && ./test`). ``` ----------------------------------------------------------------------- Benchmark Time CPU Iterations ----------------------------------------------------------------------- glibc (16 bytes) 0.207 ns 0.207 ns 1000000000 intrin (16 bytes) 0.204 ns 0.204 ns 1000000000 glibc (128 bytes) 1.62 ns 1.62 ns 429990997 intrin (128 bytes) 0.203 ns 0.203 ns 1000000000 glibc (1,024 bytes) 7.08 ns 7.08 ns 95637792 intrin (1,024 bytes) 0.616 ns 0.616 ns 1000000000 glibc (3,175 bytes) 30.2 ns 30.2 ns 23306688 intrin (3,175 bytes) 1.83 ns 1.83 ns 381575116 glibc (4,096 bytes) 33.0 ns 33.0 ns 21048745 intrin (4,096 bytes) 26.4 ns 26.4 ns 26498355 glibc (16,384 bytes) 114 ns 114 ns 6106968 intrin (16,384 bytes) 106 ns 106 ns 6605032 glibc (1,048,576 bytes) 17045 ns 17038 ns 41071 intrin (1,048,576 bytes) 15788 ns 15781 ns 44592 glibc (1,000,000,000 bytes) 58602936 ns 58570277 ns 12 intrin (1,000,000,000 bytes) 52938424 ns 52901710 ns 13 ```

LensPlaysGames commented 2022年10月28日 20:02:15 +02:00

Just wondering here, letting my thoughts meander: would it be worth it to have memcpy be a function pointer that is set based on runtime CPU data gathered during libc initialization? Basically, use a syscall to LensorOS to figure out CPU capabilities that are enabled, then set memcpy function pointer to the appropriate function? Just a thought; could be horribly broken and not actually work, just seems like it may solve this confusing compile-time CPU capabilities (which are hard to think about for cross compilation)

Just wondering here, letting my thoughts meander: would it be worth it to have memcpy be a function pointer that is set based on runtime CPU data gathered during libc initialization? Basically, use a syscall to LensorOS to figure out CPU capabilities that are enabled, then set memcpy function pointer to the appropriate function? Just a thought; could be horribly broken and not actually work, just seems like it may solve this confusing compile-time CPU capabilities (which are hard to think about for cross compilation)

Sirraide commented 2022年10月28日 20:05:11 +02:00

You'd have to benchmark whether 1. there's any performance benefit to be gained by doing that, and 2. whether it'd be worth the extra overhead incurred by the indirect call.

Also, doing this would mean that the compiler wouldn't be able to inline it anymore, which if you check the benchmark can be the difference between 30ns and 1.8ns in some cases.

You'd have to benchmark whether 1. there's any performance benefit to be gained by doing that, and 2. whether it'd be worth the extra overhead incurred by the indirect call. Also, doing this would mean that the compiler wouldn't be able to inline it anymore, which if you check the benchmark can be the difference between 30ns and 1.8ns in some cases.