Hacker News Reader

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

Totally agree! My understanding because of the use of the word "masochist" was that it was possible but difficult. Not that one language was better/worse than the other, in terms of performance.

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

Well said and I couldn't agree more. There are top market makers and banks using Java for a fact. And other C++ firms as well. Some of them are considering or have considered the move to Java. Some have already done this move. Some will never do. I'm certain that it is trivial for a C++ programmer to code in Java. The opposite of course is not true. The whole point of Java as a language is to be higher-level than C++. I don't know if people have realized, but with GraalVM it is now possible to compile Java code entirely to native code ahead-of-time, like it is done with C++. Even before GraalVM there was already the -Xcomp option to force JIT compilation in the very first pass. However that does not necessarily mean that AOT is always preferable over JIT. It is not. Runtime profiling information so you can determine the critical path (hot spots) is amazing for some optimizations, such as aggressive inlining.

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

LOL you have a point. But this is subjective. Someone could argue that a highly complex C++ system is masochism. The reality is: a lot of successful market makers, prop trading firms, banks, etc. use Java for ultra-low-latency financial systems. And of course some successful companies use C++ as well.

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

CoralRing and CoralQueue (available on GitHub) are completely garbage-free. You can send billions of messages without ever creating garbage for the GC, so no GC overhead. This is paramount for real-time ultra-low-latency systems developed in Java. You can read more about it here => https://www.coralblocks.com/index.php/java-development-witho...

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

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

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

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

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.

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

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

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

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.