4 ms·

Main memory is cheap but slow. Having a frequently called function in a shared library vs. statically linked code could mean the difference of the code executi

by yongjik 10y ago

Main memory is cheap but slow. Having a frequently called function in a shared library vs. statically linked code could mean the difference of the code executing from CPU's cache or from main memory. Even latest desktop processors have a L3 cache of only a few MB.

tatterdemalion 10y ago
But static linking could mean that function will be inlined.
- adrianratnapala 10y ago
  It means that function might be inlined. And sufficiently aggressive inlining will increase the program size further. This might or might not be compensated for by the increase in instruction-pointer locality.
- angry_octet 10y ago
  Inlining saves time lost due to jumping about, but it can cost time if it causes code replication (same as loop unrolling), because it can bloat the hot code to larger than the smallest cache. So the arguments against inlining apply even more strongly when talking about every program being statically linked, the same code (standard library) will exist in memory in many places, and will get dumped and reloaded to L2/L3 every process swap. Nothing slower than having to wait for something to be faulted in.
  - majewsky 10y ago
    > Nothing slower than having to wait for something to be faulted in. There is something slower. When your executables are so large that you have to hit the swap drive on process swaps.
netheril96 10y ago
> Having a frequently called function in a shared library vs. statically linked code could mean the difference of the code executing from CPU's cache or from main memory. I am under the impression that when process switches the CPU caches are flushed.
- nimrody 10y ago
  No. Only TLBs are flushed (and probably only partially). TLBs are used to associated virtual addresses with physical addresses and memory maps are different per processes. (That's one reason why it's beneficial to schedule a process on the same CPU if possible - the data is still in the cache)

by yongjik 10y ago

tatterdemalion 10y ago

But static linking could mean that function will be inlined.

adrianratnapala 10y ago
It means that function might be inlined. And sufficiently aggressive inlining will increase the program size further. This might or might not be compensated for by the increase in instruction-pointer locality.
angry_octet 10y ago
Inlining saves time lost due to jumping about, but it can cost time if it causes code replication (same as loop unrolling), because it can bloat the hot code to larger than the smallest cache. So the arguments against inlining apply even more strongly when talking about every program being statically linked, the same code (standard library) will exist in memory in many places, and will get dumped and reloaded to L2/L3 every process swap. Nothing slower than having to wait for something to be faulted in.
- majewsky 10y ago
  > Nothing slower than having to wait for something to be faulted in. There is something slower. When your executables are so large that you have to hit the swap drive on process swaps.

netheril96 10y ago

> Having a frequently called function in a shared library vs. statically linked code could mean the difference of the code executing from CPU's cache or from main memory. I am under the impression that when process switches the CPU caches are flushed.

nimrody 10y ago
No. Only TLBs are flushed (and probably only partially). TLBs are used to associated virtual addresses with physical addresses and memory maps are different per processes. (That's one reason why it's beneficial to schedule a process on the same CPU if possible - the data is still in the cache)