5 ms·
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 librar
by speed_spread 2y ago
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.) but if you have low latency / medium volume Java often does the trick.
- joas_coder 2y agoWell 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.
- blibble 2y ago> 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
- joas_coder 2y agoThat'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.
- blibble 2y agoI 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
- joas_coder 2y agoTotally 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.
- blibble 2y agoyeah 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 :)
- blibble 2y agodynamic 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)
- speed_spread 2y agoDoesn't dynamic allocation expose you to memory fragmentation or other non-deterministic phenomenons?
- sylware 2y agoWith semantic and fine-grained control of your allocations, and with a memory paging system on top of that, getting fragmentation is tough...
- sylware 2y agoI do it better, I free myself from as much as I can of toxic SDK (c++ and java SDKs are filthy toxic). Assembly, worst case scenario plain and simple C99+.