Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

61–70 of 76 posts

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

#61

Post by blibble »

speed_spread wrote: post #44
sylware wrote: post #35

ultra-low-latency and java in the same sentence... masochists?

Not at all. The constraints for ultra low latency are the same whether you use C++ or Java: No blocking IO, no dynamic memory allocation. Using the right libraries such as this one, Java can do a surprisingly decent job while keeping the code more accessible to a layman developer than if it was C++. You still need C++ for applications where maximum mechanical sympathy is required (cache alignment guarantees, etc.) bu…

dynamic allocation is fine as long as it is under control, as it's just a pointer bump

what you never want is to trigger the GC at a bad time

(you can do cache alignment too relatively easily)

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

#62

Post by blibble »

joas_coder wrote: post #46
speed_spread wrote: post #44

Earlier quoted context omitted.

Not at all. The constraints for ultra low latency are the same whether you use C++ or Java: No blocking IO, no dynamic memory allocation. Using the right libraries such as this one, Java can do a surprisingly decent job while keeping the code more accessible to a layman developer than if it was C++. You still need C++ for applications where maximum mechanical sympathy is required (cache alignment guarantees, etc.) bu…

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'm certain that it is trivial for a C++ programmer to code in Java.

as someone that knows both, I've made this assumption before too

it has turned out to be not true on almost all occasions

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

#63

Post by joas_coder »

blibble wrote: post #62
joas_coder wrote: post #46

Earlier quoted context omitted.

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'm certain that it is trivial for a C++ programmer to code in Java. as someone that knows both, I've made this assumption before too it has turned out to be not true on almost all occasions

That's fair! I would assume that was due to your comfort zone and muscle memory. Not because you found Java to be harder than C++. Usually a higher level language is easier to grasp, handle and manage than a lower level one.

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

#64

Post by joas_coder »

knome wrote: post #56
joas_coder wrote: post #53

Earlier quoted context omitted.

Not a language difference, but a design difference. By calling availableToPoll before polling you can poll a batch of messages without blocking or locking on each message. This design decision allows the ring to perform batching naturally. And batching is very important for perfomance. java.util.concurrent.ConcurrentLinkedQueue does not support batching.

I don't think anyone is questioning the strategy, just the naming. Polling, as a term, already generally means asking if there is anything ready. The library might instead have had a poll() to indicate readiness and an unsafeTakeReadyBatch()/releaseBatch() or similar to handle the low level receipt primitives. Or you could even have had a checkForReady() and left poll() to implement a generic version of your busy wai…

This change is now released. Thanks knome and gpderetta for your suggestions and clarifications.

availableToPoll() is now availableToFetch()

poll() is now fetch()

peek() is now fetch(false)

Note that fetch() == fetch(true)

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

#65

Post by blibble »

joas_coder wrote: post #63
blibble wrote: post #62

Earlier quoted context omitted.

> I'm certain that it is trivial for a C++ programmer to code in Java. as someone that knows both, I've made this assumption before too it has turned out to be not true on almost all occasions

That's fair! I would assume that was due to your comfort zone and muscle memory. Not because you found Java to be harder than C++. Usually a higher level language is easier to grasp, handle and manage than a lower level one.

I think their complexity is very different

C++ the language is exceptionally complicated, but the ecosystem is relatively simple

Java is the opposite, the language itself is simple enough but the ecosystem is humongous (spring/J2EE, maven/gradle, n^2 logging frameworks/adapters, application servers, anything involving classloaders/annotation processing/dynamic bytecode manipulation, ...)

syntactically they look similar, but other than that there's not much in the way of transferable skills between the two

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

#66

Post by touisteur »

pebal wrote: post #55
dikei wrote: post #33

Earlier quoted context omitted.

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

One millisecond is not a short pause.

Modern low-latency GCs never reach 1ms on all the workloads I've put them through. Mind you I don't GC terabytes of RAM so who knows what happens there.

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

#67

Post by speed_spread »

blibble wrote: post #61
speed_spread wrote: post #44

Earlier quoted context omitted.

Not at all. The constraints for ultra low latency are the same whether you use C++ or Java: No blocking IO, no dynamic memory allocation. Using the right libraries such as this one, Java can do a surprisingly decent job while keeping the code more accessible to a layman developer than if it was C++. You still need C++ for applications where maximum mechanical sympathy is required (cache alignment guarantees, etc.) bu…

dynamic allocation is fine as long as it is under control, as it's just a pointer bump what you never want is to trigger the GC at a bad time (you can do cache alignment too relatively easily)

Doesn't dynamic allocation expose you to memory fragmentation or other non-deterministic phenomenons?

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

#68

Post by joas_coder »

blibble wrote: post #65
joas_coder wrote: post #63

Earlier quoted context omitted.

That's fair! I would assume that was due to your comfort zone and muscle memory. Not because you found Java to be harder than C++. Usually a higher level language is easier to grasp, handle and manage than a lower level one.

I think their complexity is very different C++ the language is exceptionally complicated, but the ecosystem is relatively simple Java is the opposite, the language itself is simple enough but the ecosystem is humongous (spring/J2EE, maven/gradle, n^2 logging frameworks/adapters, application servers, anything involving classloaders/annotation processing/dynamic bytecode manipulation, ...) syntactically they look simil…

Totally agree! Because of the zero-garbage and no-gc requirement we don't even use the JDK. We use Java as syntax language and write everything from scratch, even the data structures (java.util.HashMap produces garbage). So the bloated Java ecosystem does not affect us too much.

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

#69

Post by blibble »

joas_coder wrote: post #68
blibble wrote: post #65

Earlier quoted context omitted.

I think their complexity is very different C++ the language is exceptionally complicated, but the ecosystem is relatively simple Java is the opposite, the language itself is simple enough but the ecosystem is humongous (spring/J2EE, maven/gradle, n^2 logging frameworks/adapters, application servers, anything involving classloaders/annotation processing/dynamic bytecode manipulation, ...) syntactically they look simil…

Totally agree! Because of the zero-garbage and no-gc requirement we don't even use the JDK. We use Java as syntax language and write everything from scratch, even the data structures (java.util.HashMap produces garbage). So the bloated Java ecosystem does not affect us too much.

yeah we're the same, our java looks very much like C

unfortunately all the data from outside our strange world still needs to be brought in and cleaned up :)

Post reply on HN