What is not faster then GLIBC ? ??
A 100LOC C impl of memset, that is faster than glibc's
11–20 of 110 posts
Re: A 100LOC C impl of memset, that is faster than glibc's
#12In 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.
It does. Each subdirectory of sysdeps/ can contain specific implementations per platform, arch, etc. eg: the aarch64 assembler memset is:
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/aar...
There's also the "ifunc" mechanism which can be used to make the choice at runtime, eg:
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/aar...
Re: A 100LOC C impl of memset, that is faster than glibc's
#13memset 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.
This would be a CPU command that works with the RAM controller rather than something you control yourself (kernels to my knowledge don’t talk directly to the controller beyond maybe some basic power management, if that).
There is a definite need to do hundreds of MB - the Linux kernel has a background thread that does nothing but zero out pages. What do you think happens to the GBs of RAM freed by closing Chrome? Once it’s made available in one spot, no reason others could use it (eg a hardened malloc implementation, etc).
Re: A 100LOC C impl of memset, that is faster than glibc's
#14Earlier quoted context omitted.
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.
This would be a CPU command that works with the RAM controller rather than something you control yourself (kernels to my knowledge don’t talk directly to the controller beyond maybe some basic power management, if that). There is a definite need to do hundreds of MB - the Linux kernel has a background thread that does nothing but zero out pages. What do you think happens to the GBs of RAM freed by closing Chrome? Onc…
Interesting that you mention linux, because Linus has very very strong opinions about this :)
Re: A 100LOC C impl of memset, that is faster than glibc's
#15Calls to memset outside of the benchmark may be of heterogenous sizes, which may heavily affect branch prediction since every branch relates to size.
I'm not saying it would go either way, just a big flaw to consider with the benchmarking method where it is doing only repeated calls of the same size only.
It is suprising the GCC version does an integer multiply, if I am reading right (several cycles, unless it is cheaper for uint32 * char).
Re: A 100LOC C impl of memset, that is faster than glibc's
#16I’m wonder how well this handles unaligned memory?
That used to be stable stakes for this kind of thing, but maybe it doesn’t matter much anymore?
Re: A 100LOC C impl of memset, that is faster than glibc's
#17Calls to memset outside of the benchmark may be of heterogenous sizes, which may heavily affect branch prediction since every branch relates to size. I'm not saying it would go either way, just a big flaw to consider with the benchmarking method where it is doing only repeated calls of the same size only. It is suprising the GCC version does an integer multiply, if I am reading right (several cycles, unless it is che…
Also repeatedly zeroing the same memory can have different performance characteristics than zeroing different memory each time. Haven't checked what the benchmark does though.
Re: A 100LOC C impl of memset, that is faster than glibc's
#18A long time ago, as I was working with the Nintendo SDK for the DS console I wondered if the provided memcpy implementation was optimal.
Turned out it was quite slow.
I replaced it with an Intel hand optimized version made for the StrongARM, and replaced the prefetch opcode by a simple load because this opcode was not supported by the arch of the CPU of this console.
50% faster, this is quite significant for such a low-level, already optimized routine, used extensively in many stages of a game engine.
I think that we should never assume that standard implementations are optimal, trust but verify.
Re: A 100LOC C impl of memset, that is faster than glibc's
#19memset 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.
>"Unless you are memsetting hundreds of MBs of memory"
Not hundreds but in one of my apps I do have 10th MB of continuous cache that has to be zeroed before use / reuse.
Re: A 100LOC C impl of memset, that is faster than glibc's
#20Earlier quoted context omitted.
This would be a CPU command that works with the RAM controller rather than something you control yourself (kernels to my knowledge don’t talk directly to the controller beyond maybe some basic power management, if that). There is a definite need to do hundreds of MB - the Linux kernel has a background thread that does nothing but zero out pages. What do you think happens to the GBs of RAM freed by closing Chrome? Onc…
Interesting that you mention linux, because Linus has very very strong opinions about this :)
What is his opinion about this?