Hacker News new | ask | show | jobs
by WeaselNo7 571 days ago
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)
3 comments

How does it compare to LMAX Disruptor if you have any experience with both?
They're both similar in design, the main difference is Coral Queue can be used for IPC between JVMs, using a mmap'd file.
See https://github.com/real-logic/aeron (also from the creator of the disruptor)
> 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.

You may find https://jctools.github.io/JCTools/ interesting
>any recommendations for a low latency work queue (with in a jvm)?

I toyed around the ring buffer pattern a decade ago, creating a unicast one (using CAS on entries, and eventually a logarithmic scan for next readable entry, not to brute-force-scan them all), but I'm not sure that its latency is much better than that of a regular ThreadPoolExecutor (the throughput could be better though).

Latency also depends on whether it spins or blocks when waiting for a slot to read or write.

If you want to give it a try: https://github.com/jeffhain/jodk/blob/master/src/net/jodk/th...

You were interested in the diamond queue, so just wanted to say that it is now released in our GitHub => https://github.com/coralblocks/CoralQueue?tab=readme-ov-file...
Given the documentation says that this is supposedly to be between JVMs, how do they handle the serialize/deserialize?
They punt on the actual serialization format: https://www.coralblocks.com/index.php/inter-process-communic...

In most applications like this you'll see direct byte manipulation to byte buffers because you want to pull as much performance as possible.

There are fast serialization formats like SBE that people leverage for this as well.

> Given the documentation says that this is supposedly to be between JVMs, how do they handle the serialize/deserialize?

Your transfer object needs to implement MemorySerializable. Below two examples from CoralRing's GitHub:

https://github.com/coralblocks/CoralRing/blob/main/src/main/...

https://github.com/coralblocks/CoralRing/blob/main/src/main/...

The second one effectively allows you to send anything you want (as bytes) through the ring, making CoralRing message agnostic.