5 ms·

How often does a video game really need a lock that can be shared between processes, That seems hugely useful for interprocess communication and I can immediat

How often does a video game really need a lock that can be shared between processes, That seems hugely useful for interprocess communication and I can immediately think of reasons to use IPC in a game. Having a separate voice process for one.

Dylan16807 5mo ago
But that goes back to "how often". Not how many games use it, but how many times per second they use it. You might touch your voice process lock once per frame? That's negligible in terms of CPU time. Any half-reasonable overhead makes no difference in that lock, but might have a big impact in a more common lock.
- CyberDildonics 5mo ago
  It absolutely can make a difference because if you have locks that are supposed to sync or wake up other processes you care about latency not cpu usage.
  - Dylan16807 5mo ago
    What specifically are you saying can make a difference? I'm saying that extra overhead from making your lock work across processes should be very tiny. That overhead shouldn't add much more than a microsecond in either latency or CPU usage, compared to an in-process lock.
    - CyberDildonics 5mo ago
      You were saying "reasonable overhead" makes no difference because something "isn't called much". This is not only ambiguous but also not true because latency is important. What calls specifically are you talking about between windows and linux? This was started by someone talking about WaitForMultipleObjects.
      - Dylan16807 5mo ago
        I wasn't excusing all overhead, I was excusing the difference in overhead caused by making the lock more flexible. Because that's what the discussion is about, a lock that can be shared between processes versus a lock that can't be. The penalty for being "too flexible". But assuming reasonable implementations, the difference between those two lock styles shouldn't be more than about a microsecond, should it? So that's fine for a lock that's only used 100 times a second. I'm not comparing windows and linux anywhere.
        CyberDildonics 5mo ago
        I was excusing the difference in overhead caused by making the lock more flexible What are the two functions you're comparing and what is the actual difference in overhead that you're talking about? a lock that can be shared between processes versus a lock that can't be. This is a dramatic black and white difference, these would be used for two different things. In that case it's apple and oranges, one would be for interprocess communication and one wouldn't. the difference between those two lock styles shouldn't be more than about a microsecond, What are you basing this on? Do you have an examples or benchmarks of the actual calls and their timings? fine for a lock that's only used 100 times a second. Again, latency isn't about how many times something is called per second. That would matter for throughput.
        Dylan16807 5mo ago
        > What are the two functions you're comparing Go ask this comment, because I'm continuing their comparison: https://news.ycombinator.com/item?id=48125795 https://news.ycombinator.com/item?id=48125795 > In that case it's apple and oranges, one would be for interprocess communication and one wouldn't. The whole point of the complaint was wtallis claiming the inter-process-capable lock was being used for locks that don't need it! That's the foundation of this conversation! > What are you basing this on? Basic coding knowledge and an assumption of competency. There's no good reason for it to slow down more than that when it's used the same way. If you have a reason go ahead and tell me. > Again, latency isn't about how many times something is called per second. That would matter for throughput. I addressed both. The extra latency for using an overly capable lock should be negligible. That's not the problem anyone is worried about.

Dylan16807 5mo ago

But that goes back to "how often". Not how many games use it, but how many times per second they use it. You might touch your voice process lock once per frame? That's negligible in terms of CPU time. Any half-reasonable overhead makes no difference in that lock, but might have a big impact in a more common lock.

CyberDildonics 5mo ago
It absolutely can make a difference because if you have locks that are supposed to sync or wake up other processes you care about latency not cpu usage.
- Dylan16807 5mo ago
  What specifically are you saying can make a difference? I'm saying that extra overhead from making your lock work across processes should be very tiny. That overhead shouldn't add much more than a microsecond in either latency or CPU usage, compared to an in-process lock.
  - CyberDildonics 5mo ago
    You were saying "reasonable overhead" makes no difference because something "isn't called much". This is not only ambiguous but also not true because latency is important. What calls specifically are you talking about between windows and linux? This was started by someone talking about WaitForMultipleObjects.
    - Dylan16807 5mo ago
      I wasn't excusing all overhead, I was excusing the difference in overhead caused by making the lock more flexible. Because that's what the discussion is about, a lock that can be shared between processes versus a lock that can't be. The penalty for being "too flexible". But assuming reasonable implementations, the difference between those two lock styles shouldn't be more than about a microsecond, should it? So that's fine for a lock that's only used 100 times a second. I'm not comparing windows and linux anywhere.
      - CyberDildonics 5mo ago
        I was excusing the difference in overhead caused by making the lock more flexible What are the two functions you're comparing and what is the actual difference in overhead that you're talking about? a lock that can be shared between processes versus a lock that can't be. This is a dramatic black and white difference, these would be used for two different things. In that case it's apple and oranges, one would be for interprocess communication and one wouldn't. the difference between those two lock styles shouldn't be more than about a microsecond, What are you basing this on? Do you have an examples or benchmarks of the actual calls and their timings? fine for a lock that's only used 100 times a second. Again, latency isn't about how many times something is called per second. That would matter for throughput.
        Dylan16807 5mo ago
        > What are the two functions you're comparing Go ask this comment, because I'm continuing their comparison: https://news.ycombinator.com/item?id=48125795 https://news.ycombinator.com/item?id=48125795 > In that case it's apple and oranges, one would be for interprocess communication and one wouldn't. The whole point of the complaint was wtallis claiming the inter-process-capable lock was being used for locks that don't need it! That's the foundation of this conversation! > What are you basing this on? Basic coding knowledge and an assumption of competency. There's no good reason for it to slow down more than that when it's used the same way. If you have a reason go ahead and tell me. > Again, latency isn't about how many times something is called per second. That would matter for throughput. I addressed both. The extra latency for using an overly capable lock should be negligible. That's not the problem anyone is worried about.