search

rofl0r / memcpy-test

testing speed of memcpy implementations
9 stars 1 forks source link

Can you post benchmarks between the different versions? #1

Open firasuke opened 2 years ago

firasuke commented 2 years ago

As the title says, can you post the results of the benchmarks between the different versions?

Also what architectures are supported by these versions?

firasuke commented 2 years ago

Also, did you check cosmopolitan's memcpy and strcpy implementations? They claim they have the fastest out of available C libraries.

Another thing is this and this from clear linux.

rofl0r commented 2 years ago

i reverse-engineered the cosmopolitan memcpy, it's in this repo.

just run compare.py cosmopolitan.s amd.s

firasuke commented 2 years ago

I did, here's what I got.

./compare.py cosmopolitan.s amd.s
warning: CC or OPTS not set, which is probably not what you want
In file included from /usr/include/bits/libc-header-start.h:33,
                 from /usr/include/stdio.h:27,
                 from memcpy_test.c:1:
/usr/include/features.h:194:3: warning: #warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp]
  194 | # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE"
      |   ^~~~~~~
cosmopolitan.s: Assembler messages:
cosmopolitan.s:326: Warning: no instruction mnemonic suffix given and no register operands; using default for `btr'
cosmopolitan.s:327: Warning: no instruction mnemonic suffix given and no register operands; using default for `btr'
/usr/bin/ld: mymemcpy.o: relocation R_X86_64_32S against `.piro.bss.init.2.300._init_memcpy' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld: failed to set dynamic section sizes: bad value
collect2: error: ld returned 1 exit status
rofl0r commented 2 years ago

try OPTS=-fno-pie ./compare.py ...

it seems your toolchains defaults to PIE

firasuke commented 2 years ago

try OPTS=-fno-pie ./compare.py ...

OPTS="-fno-pie" ./compare.py cosmopolitan.s amd.s
warning: CC or OPTS not set, which is probably not what you want
In file included from /usr/include/bits/libc-header-start.h:33,
from /usr/include/stdio.h:27,
from memcpy_test.c:1:
/usr/include/features.h:194:3: warning: #warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp]
194 | # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE"
|   ^~~~~~~
cosmopolitan.s: Assembler messages:
cosmopolitan.s:326: Warning: no instruction mnemonic suffix given and no register operands; using default for `btr'
cosmopolitan.s:327: Warning: no instruction mnemonic suffix given and no register operands; using default for `btr'
/usr/bin/ld: mymemcpy.o: relocation R_X86_64_32S against `.piro.bss.init.2.300._init_memcpy' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld: failed to set dynamic section sizes: bad value
collect2: error: ld returned 1 exit status

it seems your toolchains defaults to PIE

I'm using arch's default toolchain which is glibc based, should I be using my own musl based toolchain?

rofl0r commented 2 years ago

should I be using my own musl based toolchain?

after some thought it seems the real issue here is that the toolchain doesn't use init-fini arrays by default, which musl based toolchains (at least the ones following musl-crors-make) do. the init/fini stuff is needed to emulate the table initializiation cosmopolitan does in its hackish startup code. so yeah, try that toolchain instead.

firasuke commented 2 years ago

So running:

CC=/home/firasuke/glaucus/toolchain/bin/x86_64-glaucus-linux-musl-gcc ./compare.py amd.s cosmopolitan.s
warning: CC or OPTS not set, which is probably not what you want
sh: line 1: ./test: No such file or directory

Upon checking ./test:

file test
test: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-x86_64.so.1, BuildID[sha1]=8d3466edef691aa74ef1f36e8ccfb49116c8c1be, with debug_info, not stripped

and:

/home/firasuke/glaucus/cross/usr/bin/ldd test
        /lib/ld-musl-x86_64.so.1 (0x7f7ecc83a000)
        libc.so => /lib/ld-musl-x86_64.so.1 (0x7f7ecc83a000)
rofl0r commented 2 years ago

OPTS=-static CC=/home/firasuke/glaucus/toolchain/bin/x86_64-glaucus-linux-musl-gcc ./compare.py amd.s cosmopolitan.s you need to statically link since your interpreter isn't in the expected path

firasuke commented 2 years ago

Yeah I forgot to mention that I'm using a cross compilation toolchain, and that I've already tried changing LD_LIBRARY_PATH to no avail.

Lemme try again.

rofl0r commented 2 years ago

thus OPTS=-static

firasuke commented 2 years ago

This:

OPTS=-static CC=/home/firasuke/glaucus/toolchain/bin/x86_64-glaucus-linux-musl-gcc ./compare.py amd.s cosmopolitan.s
sh: line 1: ./test: No such file or directory

and this (expected because host's env is trying to use the LD_LIBRARY_PATH as well):

OPTS=-static LD_LIBRARY_PATH=/home/firasuke/glaucus/cross/usr/lib CC=/home/firasuke/glaucus/toolchain/bin/x86_64-glaucus-linux-musl-gcc ./compare.py amd.s cosmopolitan.s
/usr/bin/env: /home/firasuke/glaucus/cross/usr/lib/libc.so.6: no version information available (required by /usr/bin/env)
/usr/bin/env: /home/firasuke/glaucus/cross/usr/lib/libc.so.6: no version information available (required by /usr/bin/env)
/usr/bin/env: /home/firasuke/glaucus/cross/usr/lib/libc.so.6: no version information available (required by /usr/bin/env)
/usr/bin/env: /home/firasuke/glaucus/cross/usr/lib/libc.so.6: no version information available (required by /usr/bin/env)
/usr/bin/env: /home/firasuke/glaucus/cross/usr/lib/libc.so.6: no version information available (required by /usr/bin/env)
/usr/bin/env: /home/firasuke/glaucus/cross/usr/lib/libc.so.6: no version information available (required by /usr/bin/env)
/usr/bin/env: /home/firasuke/glaucus/cross/usr/lib/libc.so.6: no version information available (required by /usr/bin/env)
Inconsistency detected by ld.so: dl-lookup.c: 106: check_match: Assertion `version->filename == NULL || ! _dl_name_match_p (version->filename, map)' failed!
rofl0r commented 2 years ago

sh: line 1: ./test: No such file or directory

ah, i just pushed a fix. OPTS wasn't passed to linking stage in build.sh, so the -static didnt have any effect.

firasuke commented 2 years ago

Ok it ran successfully, but what am I expecting here? Numbers? A graph?

rofl0r commented 2 years ago

numbers. you see to the left block sizes, and in the columns clock cycles for each implementation tested.

firasuke commented 2 years ago

So I should just run ./test?

rofl0r commented 2 years ago

OPTS=-static CC=/home/firasuke/glaucus/toolchain/bin/x86_64-glaucus-linux-musl-gcc ./compare.py amd.s cosmopolitan.s

and wait

firasuke commented 2 years ago

Updated:

OPTS=-static CC=/home/firasuke/glaucus/toolchain/bin/x86_64-glaucus-linux-musl-gcc ./compare.py amd.s cosmopolitan.s
/home/firasuke/glaucus/toolchain/lib/gcc/x86_64-glaucus-linux-musl/12.1.0/../../../../x86_64-glaucus-linux-musl/bin/ld: cannot find -lc: No such file or directory
collect2: error: ld returned 1 exit status
rofl0r commented 2 years ago

seems your musl toolchain is broken, if it doesn't find -lc. didn't you report successful build earlier ?

firasuke commented 2 years ago

seems your musl toolchain is broken, if it doesn't find -lc. didn't you report successful build earlier ?

Not really, it's a cross compilation toolchain, I wonder if I can pass LDFLAGS=-L/home/firasuke/glaucus/cross/usr/lib to get it to work.

didn't you report successful build earlier ?

Sorry for not clarifying, this was using the host's native glibc based toolchain.

rofl0r commented 2 years ago

Not really, it's a cross compilation toolchain

a crosstoolchain should always default to its own libdir, and you shouldnt have to specify its library path explicitly

I wonder if I can pass LDFLAGS=-L/home/firasuke/glaucus/cross/usr/lib to get it to work.

you can hack it into build.sh or pass it in OPTS, i.e. OPTS="-static -Lwhatever"

firasuke commented 2 years ago

a crosstoolchain should always default to its own libdir, and you shouldnt have to specify its library path explicitly

It's a cross compilation toolchain that has some expectations on what the target system should be.

Also:

echo "main(){}" > a.c &&  /home/firasuke/glaucus/toolchain/bin/x86_64-glaucus-linux-musl-gcc a.c

Then:

file a.out
a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-x86_64.so.1, BuildID[sha1]=b94ecccc17c960936d2ccee919459abc8e7f7a23, not stripped

And:

/home/firasuke/glaucus/cross/usr/bin/ldd a.out
        /lib/ld-musl-x86_64.so.1 (0x7ff18a10a000)
        libc.so => /lib/ld-musl-x86_64.so.1 (0x7ff18a10a000)

I'm not doubting my toolchain here, I've built countless systems with it.

you can hack it into build.sh or pass it in OPTS, i.e. OPTS="-static -Lwhatever"

 OPTS="-static -L/home/firasuke/glaucus/cross/usr/lib" CC=/home/firasuke/glaucus/toolchain/bin/x86_64-glaucus-linux-musl-gcc ./compare.py amd.s cosmopolitan.s

Also doesn't work...