5 ms·

...And why would you want that? All your applications share the same virtual memory space. So you have a much higher hit rate in your TLB, then without. It gre

...And why would you want that? All your applications share the same virtual memory space. So you have a much higher hit rate in your TLB, then without. It greatly lowers the chance that shared memory will leave L3 cache. Cache hit rates are very important... The advantage for fork(2) over clone is that you CAN'T share those datastructures, making it harder to write code resulting a deadlock Dead locking has nothing to do with how RAM is accessed or how virtual memory is partitioned, it has to do with how you are managing your locking. Modern memory/instruction re-ordering is stupidly fast. If you are locking memory/data structure locations you are likely doing something wrong. Concurrent Memory fences are around 3 orders of magnitude faster then locks. As for the kernel resources for the process, you'd be surprised how large RAM has gotten these days... TLB/L2/L3 cache is still premium real-estate. RAM size is awesome! I love waiting 100,000cycles to get the page I requested.

qwertyuiop924 10y ago
Cache hit rates aren't as important as you seem to think. If you're not google, and your app doesn't have hard/soft realtime constraints (videogames, flight control systems, etc.) your app will probably be fast enough. You'd be surprised how fast computers are nowadays... >If you are locking memory/data structure locations you are likely doing something wrong. Oh, concurrent memory fences! Well, that solves all my problems. Let's see. All I have to do is give up all hope of my code ever being portable to mutiple architectures, and than dig around in asm to add support for them to my environment, which can range from mildly annoying (C), to near-impossible (JVM). Or I can use fork(2), and do what programmers have been doing for decades: trading performance for simplicity, and productivity. That'll be a really hard decision.
- valarauca1 10y ago
  All I have to do is give up all hope of my code ever being portable to multiple architectures You know nothing about modern compiler atomics. Post 2011 compilers (LLVM, GCC, MSVC, ICC) standardized generic memory fences for C++ and C. These are fully portable as the compiler itself determines how the layout of Acquire/Releases needs to be changed on platform you are compiling too. Atomics are supported on ARM, x64, MIPS64, SPARC64, POWER8, POWER9... So they're very portable. The compiler even manages removing unneeded fences. Like if you add an acquire fence after a CAS load. The CAS load is an acquire fence on x64, but not on POWER8.
  - qwertyuiop924 10y ago
    Okay, what about HLLs? Memory fences don't work if you aren't writing C. And as I've said, forks are an easier way to get these guarantees, albeit at a moderate perf cost.
    - valarauca1 10y ago
      Seeing as this a conversation thread about raw system calls I assume we were working C not a HLL. Are you just a professional contrarian? Why are you concerned about system calls in a HLL? Why are you concerned with concurrency guarantees in a HLL? You care about none of these, you care about your run time. This is why you are working in a HLL.
      - deleted 10y ago
        [deleted]
      - qwertyuiop924 10y ago
        Are you just a professional contrarian? No. Why are you concerned about system calls in a HLL? Because in many HLLs, fork(2) is the best (or sometimes the only) option for concurrency. As in C, it is certainly the simplest. Many things written in HLLs use fork. Unicorn is perhaps the most famous example. Why are you concerned with concurrency guarantees in a HLL? Because if I have multiple threads of execution, I want them to run in parallel if possible, and I want to minimize the risk of deadlocks. fork(2) does both. You care about none of these, you care about your run time. This is why you are working in a HLL. No. I care about them, as demonstrated above. And I don't know what you mean by care about my runtime. I would go so far as to claim that the above is an insult to me and everybody else who uses an HLL. I care about getting stuff done. If C is the right tool for that, I'll use it. If an HLL is the right tool, I'll use it. And if syscalls are the right tool for the job, I'll use them, too.

qwertyuiop924 10y ago

Cache hit rates aren't as important as you seem to think. If you're not google, and your app doesn't have hard/soft realtime constraints (videogames, flight control systems, etc.) your app will probably be fast enough. You'd be surprised how fast computers are nowadays... >If you are locking memory/data structure locations you are likely doing something wrong. Oh, concurrent memory fences! Well, that solves all my problems. Let's see. All I have to do is give up all hope of my code ever being portable to mutiple architectures, and than dig around in asm to add support for them to my environment, which can range from mildly annoying (C), to near-impossible (JVM). Or I can use fork(2), and do what programmers have been doing for decades: trading performance for simplicity, and productivity. That'll be a really hard decision.

valarauca1 10y ago
All I have to do is give up all hope of my code ever being portable to multiple architectures You know nothing about modern compiler atomics. Post 2011 compilers (LLVM, GCC, MSVC, ICC) standardized generic memory fences for C++ and C. These are fully portable as the compiler itself determines how the layout of Acquire/Releases needs to be changed on platform you are compiling too. Atomics are supported on ARM, x64, MIPS64, SPARC64, POWER8, POWER9... So they're very portable. The compiler even manages removing unneeded fences. Like if you add an acquire fence after a CAS load. The CAS load is an acquire fence on x64, but not on POWER8.
- qwertyuiop924 10y ago
  Okay, what about HLLs? Memory fences don't work if you aren't writing C. And as I've said, forks are an easier way to get these guarantees, albeit at a moderate perf cost.
  - valarauca1 10y ago
    Seeing as this a conversation thread about raw system calls I assume we were working C not a HLL. Are you just a professional contrarian? Why are you concerned about system calls in a HLL? Why are you concerned with concurrency guarantees in a HLL? You care about none of these, you care about your run time. This is why you are working in a HLL.
    - deleted 10y ago
      [deleted]
    - qwertyuiop924 10y ago
      Are you just a professional contrarian? No. Why are you concerned about system calls in a HLL? Because in many HLLs, fork(2) is the best (or sometimes the only) option for concurrency. As in C, it is certainly the simplest. Many things written in HLLs use fork. Unicorn is perhaps the most famous example. Why are you concerned with concurrency guarantees in a HLL? Because if I have multiple threads of execution, I want them to run in parallel if possible, and I want to minimize the risk of deadlocks. fork(2) does both. You care about none of these, you care about your run time. This is why you are working in a HLL. No. I care about them, as demonstrated above. And I don't know what you mean by care about my runtime. I would go so far as to claim that the above is an insult to me and everybody else who uses an HLL. I care about getting stuff done. If C is the right tool for that, I'll use it. If an HLL is the right tool, I'll use it. And if syscalls are the right tool for the job, I'll use them, too.