3 ms·

> 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

> 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.

CyberDildonics 6mo ago
Basic coding knowledge and an assumption of competency. This is just saying "I just know", but what specific function and basic timings are you going off of? If you don't know, why are you so sure of the numbers? 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! They were saying it's rare to need IPC lock for video games and I don't think that's true, then I gave a scenario where you would use one.
- Dylan16807 6mo ago
  If you're not actually using it between processes, the overhead could be as small as an extra conditional. For an upper bound I think a couple wasted syscalls makes sense. Why would it be significantly slower than that? But whatever, let's focus on the actual point: > They were saying it's rare to need IPC lock for video games and I don't think that's true, then I gave a scenario where you would use one. And I was pointing out that a voice IPC lock is still "rare" when we use the most appropriate definition of "rare" for this context. In this context of worrying that using the wrong kind of lock will slow the game down, how often we're using the lock matters. If we go 50 million CPU cycles between uses, it's "rare".
  - CyberDildonics 6mo ago
    how often we're using the lock matters. No, latency is what matters. And I was pointing out that a voice IPC lock is still "rare" when we use the most appropriate definition of "rare" This isn't really a point with explanation, it's just you saying 'nu uh', even though that was just a single example.
    - Dylan16807 6mo ago
      The post you originally responded to was comparing the general idea of locks that can work between processes and ones that can't. And it was criticizing the efficiency of the former, which is a measure of throughput. There's no reason for an upgraded lock to significantly change in latency. That's not what they were worried about when criticizing the idea of using the former lock as the main lock type in a game. Your most used locks need throughput. So no, latency is not what matters. And I've explained why I say that in multiple ways, while you haven't given any explanation for why you're focusing on latency. When they asked "how often" in the middle of that criticism, they're not looking for an example that sprinkles in a couple calls, they're looking for something that puts serious load onto the lock. Any answer that is once per frame or less is not properly addressing the question.
      - CyberDildonics 6mo ago
        So no, latency is not what matters. And I've explained why I say that in multiple ways, No you haven't, you keep talking about doing something 100 times, but if you have a lock between processes, getting those processes to wake up and know the unlock happened with low latency is what matters. After the unlock whatever happens is going to be fast anyway, which in IPC is probably going to be copying memory. What specific function call are you thinking of that would have high overhead but not latency and the latency wouldn't matter? you originally responded to I replied to someone saying "how often do you use a shared lock in games" and I said there are obvious uses.
        Dylan16807 6mo ago

CyberDildonics 6mo ago

Basic coding knowledge and an assumption of competency. This is just saying "I just know", but what specific function and basic timings are you going off of? If you don't know, why are you so sure of the numbers? 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! They were saying it's rare to need IPC lock for video games and I don't think that's true, then I gave a scenario where you would use one.

Dylan16807 6mo ago
If you're not actually using it between processes, the overhead could be as small as an extra conditional. For an upper bound I think a couple wasted syscalls makes sense. Why would it be significantly slower than that? But whatever, let's focus on the actual point: > They were saying it's rare to need IPC lock for video games and I don't think that's true, then I gave a scenario where you would use one. And I was pointing out that a voice IPC lock is still "rare" when we use the most appropriate definition of "rare" for this context. In this context of worrying that using the wrong kind of lock will slow the game down, how often we're using the lock matters. If we go 50 million CPU cycles between uses, it's "rare".
- CyberDildonics 6mo ago
  how often we're using the lock matters. No, latency is what matters. And I was pointing out that a voice IPC lock is still "rare" when we use the most appropriate definition of "rare" This isn't really a point with explanation, it's just you saying 'nu uh', even though that was just a single example.
  - Dylan16807 6mo ago
    The post you originally responded to was comparing the general idea of locks that can work between processes and ones that can't. And it was criticizing the efficiency of the former, which is a measure of throughput. There's no reason for an upgraded lock to significantly change in latency. That's not what they were worried about when criticizing the idea of using the former lock as the main lock type in a game. Your most used locks need throughput. So no, latency is not what matters. And I've explained why I say that in multiple ways, while you haven't given any explanation for why you're focusing on latency. When they asked "how often" in the middle of that criticism, they're not looking for an example that sprinkles in a couple calls, they're looking for something that puts serious load onto the lock. Any answer that is once per frame or less is not properly addressing the question.
    - CyberDildonics 6mo ago
      So no, latency is not what matters. And I've explained why I say that in multiple ways, No you haven't, you keep talking about doing something 100 times, but if you have a lock between processes, getting those processes to wake up and know the unlock happened with low latency is what matters. After the unlock whatever happens is going to be fast anyway, which in IPC is probably going to be copying memory. What specific function call are you thinking of that would have high overhead but not latency and the latency wouldn't matter? you originally responded to I replied to someone saying "how often do you use a shared lock in games" and I said there are obvious uses.
      - Dylan16807 6mo ago