Earlier quoted context omitted.
Interesting. But how do you ensure a worker that picks up a task does not pause on gc as well?
Maybe they run a small heap with a zero-pause JVM like Zing, as pause-less GC generally has lower throughput than normal GC.
Ultra-low-latency, batching and concurrent queue for IPC in Java
31–40 of 76 posts
Re: Ultra-low-latency, batching and concurrent queue for IPC in Java
#32Weird to see this here! I've used CoralBlocks in the low-latency trading domain previously. Highly recommend. The API is kind, they're very responsive, and the latency is exceptional (and comes with all the basics like thread pinning built-in for convenience)
> CoralBlocks in the low-latency trading domain previously. Yeah, modern JVM is a true miracle and you can be x5 productive (and safe!) compared to C/C++ Do you have any recommendations for a low latency work queue (with in a jvm)? I want to spawn millions of micro-second-tasks per second, to worker cores.. I am on a massive cache CPU so memory latency hasnt raised its ugly head yet EDIT: not LMAX please...
Re: Ultra-low-latency, batching and concurrent queue for IPC in Java
#33Re: Ultra-low-latency, batching and concurrent queue for IPC in Java
#34I don’t get it. How is this advantageous as it’s limited to one machine? Why wouldn’t you just have one jvm running multiple threads? What is the point of having multiple jvm processes interacting through this ring? Can someone enlighten me?
A few potential reasons for this design coming to mind: - Resource allocation; you might want to give just specific amount of memory, CPU, network I/O to specific modules of a system, which is not really feasible within a single JVM - Resource isolation; e.g. a memory leak in one module of the system will affect just that specific JVM instance but not others (similar to why browsers run tabs in multiple processes); -…
Re: Ultra-low-latency, batching and concurrent queue for IPC in Java
#35Re: Ultra-low-latency, batching and concurrent queue for IPC in Java
#36https://github.com/coralblocks/CoralRing/blob/1168b047e0183c... Am I missing something here or does the BlockingRingConsumer not actually block? And worse doesn't it just return garbage if poll is called without first checking availableToPoll? The example sure looks like it... https://github.com/coralblocks/CoralRing/blob/main/src/main/... Which if so isn't this like 1/4th a library for doing IPC? It doesn't seem to…
And given these are designed for "ultra-low-latency" systems, I don't think that's a big problem because the best blocking strategy is probably just to spin.
It would be nice if the docs were nicer though, considering this is a paid product...
Re: Ultra-low-latency, batching and concurrent queue for IPC in Java
#37Re: Ultra-low-latency, batching and concurrent queue for IPC in Java
#38https://github.com/coralblocks/CoralRing/blob/1168b047e0183c... Am I missing something here or does the BlockingRingConsumer not actually block? And worse doesn't it just return garbage if poll is called without first checking availableToPoll? The example sure looks like it... https://github.com/coralblocks/CoralRing/blob/main/src/main/... Which if so isn't this like 1/4th a library for doing IPC? It doesn't seem to…
You are never supposed to call poll() without first calling availableToPoll(). How can you poll something if you don't know if there is something available to poll? This is very different than a ConcurrentLinkedQueue where you can call poll() on an empty queue and get a null to indicate that the queue is empty. Also because the ring is a circular queue, you have to know what you can safely poll before polling. That's all done through availableToPoll().
NOTE: By garbage here I don't think you are talking about GC garbage.
Re: Ultra-low-latency, batching and concurrent queue for IPC in Java
#39https://github.com/coralblocks/CoralRing/blob/1168b047e0183c... Am I missing something here or does the BlockingRingConsumer not actually block? And worse doesn't it just return garbage if poll is called without first checking availableToPoll? The example sure looks like it... https://github.com/coralblocks/CoralRing/blob/main/src/main/... Which if so isn't this like 1/4th a library for doing IPC? It doesn't seem to…
It looks like these are more lower level libraries so clients are supposed to block, but they are responsible for doing the blocking themselves. And given these are designed for "ultra-low-latency" systems, I don't think that's a big problem because the best blocking strategy is probably just to spin. It would be nice if the docs were nicer though, considering this is a paid product...
You busy spin when blocking (fastest) or you can use a WaitStrategy from https://www.github.com/coralblocks/CoralQueue. You can see an example here: https://github.com/coralblocks/CoralQueue/blob/main/src/main...
> And given these are designed for "ultra-low-latency" systems, I don't think that's a big problem because the best blocking strategy is probably just to spin.
If you have an isolated and dedicated CPU core for your thread, that's correct. Busy-spinning is the fastest/best strategy.
> It would be nice if the docs were nicer though, considering this is a paid product...
CoralRing and CoralQueue are open-source and free at GitHub. There are also a lot of documentation and explanations on the GitHub README.me page (front page). The code has also a lot of comments.
Re: Ultra-low-latency, batching and concurrent queue for IPC in Java
#40Weird to see this here! I've used CoralBlocks in the low-latency trading domain previously. Highly recommend. The API is kind, they're very responsive, and the latency is exceptional (and comes with all the basics like thread pinning built-in for convenience)
> CoralBlocks in the low-latency trading domain previously. Yeah, modern JVM is a true miracle and you can be x5 productive (and safe!) compared to C/C++ Do you have any recommendations for a low latency work queue (with in a jvm)? I want to spawn millions of micro-second-tasks per second, to worker cores.. I am on a massive cache CPU so memory latency hasnt raised its ugly head yet EDIT: not LMAX please...
The DiamondQueue should be soon available for free at the CoralQueue project on GitHub.