Live data from Hacker News

Ultra-low-latency, batching and concurrent queue for IPC in Java

github.com

31–40 of 76 posts

Re: Ultra-low-latency, batching and concurrent queue for IPC in Java

#31
post #29

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.

Java doesn't have real pause-less GC.

Re: Ultra-low-latency, batching and concurrent queue for IPC in Java

#32

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

You may find https://jctools.github.io/JCTools/ interesting

Re: Ultra-low-latency, batching and concurrent queue for IPC in Java

#33
post #31
post #29

Earlier quoted context omitted.

Maybe they run a small heap with a zero-pause JVM like Zing, as pause-less GC generally has lower throughput than normal GC.

Java doesn't have real pause-less GC.

Well, "pause too short to matter" just doesn't have the same ring to it.

Re: Ultra-low-latency, batching and concurrent queue for IPC in Java

#34

I 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); -…

Yeah, I think the HFT guys use CPU pinning a lot: 1 process - 1 CPU, so you'd need multiple processes to take advantage of multicores server.

Re: Ultra-low-latency, batching and concurrent queue for IPC in Java

#36

https://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...

Re: Ultra-low-latency, batching and concurrent queue for IPC in Java

#38

https://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…

availableToPoll() is the method that blocks, because it can return 0 on an empty ring. When that happens you have to block, by for example busy spinning around availableToPoll() until it returns something to poll.

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

#39
post #36

https://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...

> It looks like these are more lower level libraries so clients are supposed to block, but they are responsible for doing the blocking themselves.

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

#40

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

I think you can take a look at the DiamondQueue, which is a Demultiplexer and a Multiplexer combined so that thread A dispatches a bunch of tasks to a fixed set of worker threads (W1, W2, W3, etc.) and then these worker threads use a Multiplexer to deliver the results to another thread B. Thread A and Thread B can also be the same thread. There is an example here => https://www.coralblocks.com/index.php/the-diamond-queue-demu...

The DiamondQueue should be soon available for free at the CoralQueue project on GitHub.

Post reply on HN