5 ms·

I hadn't considered someone would use polling like this. Profoundly wasteful of the CPU unless you have a ridiculous throughput.

by dicroce 11y ago

kasey_junk 11y ago
Or low latency requirements.
- ma2rten 11y ago
  Maybe in that case you should use a single thread and avoid ipc altogether?
  - kasey_junk 11y ago
    For sure if you can avoid it. But sometimes you can't. In those cases you need inter-thread communication to be as fast as possible. A reason inter-process communication is interesting, especially in java, is that there is a reasonably common pattern of isolating low latency code in 1 JVM and less sensitive code in another to prevent system wide pauses from bleeding across. This can be super painful for development iteration though so one thing that is interesting about this library is that it seems to make that configuration time concern.
    - vitalyd 11y ago
      It may also be beneficial to move some processing to a different core (perhaps even different socket) to avoid execution resource contention (e.g. d/i-cache, execution ports, etc).
jberryman 11y ago
Or your thread has something else it could be doing while messages are unavailable. It sounds like you haven't thought much about message passing at all and could probably be a little more humble.
- dicroce 11y ago
  I have written a number of message queue's. None of which had near the number of events required to justify polling like this. All of the message queue's I've written would be using tons of extra CPU if I had used a polling solution... I realize that there probably are use cases out there that justify this, but I have not been tasked with one...
sitkack 11y ago
High speed polling and/or the disabling of interrupts is totally a valid solution, esp when given such a high throughput that you will always have messages waiting there is actually no reason to be interrupt driven. No sleeping, no waiting, no waste. Polling is not necessarily evil or wasteful.

I hadn't considered someone would use polling like this. Profoundly wasteful of the CPU unless you have a ridiculous throughput.

by dicroce 11y ago

I hadn't considered someone would use polling like this. Profoundly wasteful of the CPU unless you have a ridiculous throughput.

kasey_junk 11y ago

Or low latency requirements.

ma2rten 11y ago
Maybe in that case you should use a single thread and avoid ipc altogether?
- kasey_junk 11y ago
  For sure if you can avoid it. But sometimes you can't. In those cases you need inter-thread communication to be as fast as possible. A reason inter-process communication is interesting, especially in java, is that there is a reasonably common pattern of isolating low latency code in 1 JVM and less sensitive code in another to prevent system wide pauses from bleeding across. This can be super painful for development iteration though so one thing that is interesting about this library is that it seems to make that configuration time concern.
  - vitalyd 11y ago
    It may also be beneficial to move some processing to a different core (perhaps even different socket) to avoid execution resource contention (e.g. d/i-cache, execution ports, etc).

jberryman 11y ago

Or your thread has something else it could be doing while messages are unavailable. It sounds like you haven't thought much about message passing at all and could probably be a little more humble.

dicroce 11y ago
I have written a number of message queue's. None of which had near the number of events required to justify polling like this. All of the message queue's I've written would be using tons of extra CPU if I had used a polling solution... I realize that there probably are use cases out there that justify this, but I have not been tasked with one...

sitkack 11y ago

High speed polling and/or the disabling of interrupts is totally a valid solution, esp when given such a high throughput that you will always have messages waiting there is actually no reason to be interrupt driven. No sleeping, no waiting, no waste. Polling is not necessarily evil or wasteful.