A 100LOC C impl of memset, that is faster than glibc's
1–10 of 110 posts
Re: A 100LOC C impl of memset, that is faster than glibc's
#2> The implementation of memset in this repository is around 25% faster than the glibc implementation. This is the geometric mean for sizes 0..512.
Re: A 100LOC C impl of memset, that is faster than glibc's
#3I'm curious why the time is so much worse for sizes just slightly larger than 400, but then better again for sizes larger than this?
Re: A 100LOC C impl of memset, that is faster than glibc's
#4I think that Duff's device could be used on lines 65-86 ( https://github.com/nadavrot/memset_benchmark/blob/eac67b6205... )
Re: A 100LOC C impl of memset, that is faster than glibc's
#5In all fairness it needs to be said that the libc's implementation has to consider portability to more "exotic" architectures. For example, not every CPU allows to make unaligned 32-bit or 64-bit writes, or it takes a huge penalty for such writes.
Re: A 100LOC C impl of memset, that is faster than glibc's
#6Great! Now benchmark it with all compiler X architectures supported by glibc.
Re: A 100LOC C impl of memset, that is faster than glibc's
#7In all fairness it needs to be said that the libc's implementation has to consider portability to more "exotic" architectures. For example, not every CPU allows to make unaligned 32-bit or 64-bit writes, or it takes a huge penalty for such writes.
glibc has hand crafted assembler implementations of memcpy (often specialized for specific size ranges) for many architectures.
Re: A 100LOC C impl of memset, that is faster than glibc's
#8memset is something JEDEC SDRAM standard should of implemented on a hardware level back in 1993. Why even bother writing to ram byte by byte when we could of had dedicated command to fill up to whole row (8-16kbit per chip, 8-32KB per DIMM) at a time with _single command_. Safe zero fill memory allocation would be free and standard.
For background: https://faculty-web.msoe.edu/johnsontimoj/EE4980/files4980/m... Since 1993 ram chips have integrated state machines receiving and interpreting higher level commands. They also have wide sense amplifier banks being loaded/stored all at once.
Re: A 100LOC C impl of memset, that is faster than glibc's
#9memset is something JEDEC SDRAM standard should of implemented on a hardware level back in 1993. Why even bother writing to ram byte by byte when we could of had dedicated command to fill up to whole row (8-16kbit per chip, 8-32KB per DIMM) at a time with _single command_. Safe zero fill memory allocation would be free and standard. For background: https://faculty-web.msoe.edu/johnsontimoj/EE4980/files4980/m... Since…
What's the use of filling your ram with zeros when the data needs to be on L1, L2 or L3? Unless you are memsetting hundreds of MBs of memory, memset/memcpy in practice need to be handled by the cpu or something very close to it.
Zen has CLZERO which can clear a cacheline in one go, but not sure how good it is.
Re: A 100LOC C impl of memset, that is faster than glibc's
#10In all fairness it needs to be said that the libc's implementation has to consider portability to more "exotic" architectures. For example, not every CPU allows to make unaligned 32-bit or 64-bit writes, or it takes a huge penalty for such writes.
Does glibc not have feature detection and conditional compilation for cases like this? That is surprising to me.