3 ms·
If you don't use a per-thread heap, then you won't get around synchronizing different threads for allocation. If that necessarily serial part of your code makes
by MauranKilom 6y ago
If you don't use a per-thread heap, then you won't get around synchronizing different threads for allocation. If that necessarily serial part of your code makes up even 1% of the time your program needs (before parallelization), then going from 100 threads to 1000 threads will only be a speedup of 81% (whereas you'd ideally expect 900%). That's not good for HPC.
See https://en.wikipedia.org/wiki/Amdahl%27s_law https://en.wikipedia.org/wiki/Amdahl%27s_law.
- deleted 6y ago[deleted]
- CyberDildonics 6y agoThere is a lot of truth to this and you are one of the few people I've seen mention amdahl's law in the correct context. There are multiple malloc implementations (gcc and maybe clang) that are supposedly multi-threaded now and multiple allocators are explicitly made for it like jemalloc, so I don't think the situation is quite as dire anymore. That being said, I agree that using per-thread heaps is a much better structure by default for a heavily multi-threaded program since allocations crossing threads probably should be handled explicitly and memory mapping from the OS will still block (as far as I know).
- chrisseaton 6y ago> If you don't use a per-thread heap Well why wouldn't you? > See https://en.wikipedia.org/wiki/Amdahl%27s_law https://en.wikipedia.org/wiki/Amdahl%27s_law Allocation should be embarrassingly parallel in the fast path.