13 ms·

I've always been surprised that memset is usually just a nonmagical for loop. I used to expect that the OS does things to magically make it faster (running lazi

• caf 10y ago
  CPUs are pretty great at running nonmagical for loops, so you'd have be zeroing a pretty giant block of memory before it made sense to get the OS involved at all.
  • Manishearth 10y ago
    Of course :) But the OS could get involved for larger blocks of memory. Also, I wonder if zeroing large chunks of memory would be faster to do in kernel space using real addresses. You can avoid the multiple real memory lookups involved in a single virtual write. (Of course, we already avoid those often, but it could be useful to avoid entirely. Not sure what the tradeoffs are here)
    • caf 10y ago
      Paging is still enabled in kernel mode, the kernel uses virtual addresses. (The kernel's linear mapping of physical memory can take advantage of huge pages though, which means that there might be one or two less levels of page tables involved with those addresses). TLB misses aren't significant if you're bulk-writing to a block of memory anyway, you'll max out the bandwidth of the memory without that being an issue.
    • adrianN 10y ago
      For linear access patterns the TLB does its job perfectly. The overhead is negligible.
• chei0iaV 10y ago
  Which implementations use a nonmagical for loop? glibc's is all in assembly full of SIMD instructions, which seem very much magical... https://sourceware.org/git/?p=glibc.git;a=tree;f=sysdeps/x86_64;hb=HEAD https://sourceware.org/git/?p=glibc.git;a=tree;f=sysdeps/x86... http://stackoverflow.com/questions/8858778/why-are-complicated-memcpy-memset-superior http://stackoverflow.com/questions/8858778/why-are-complicat...