It will be hard to make a final conclusion. It is more of a research exercise to learn. All we can say is that as the code stands right now Java JIT is faster than C++ clang AOT for this simple map implementation. And all the code, compilation scripts, executions scripts, details, etc. are available in our GitHub so that other people can execute and play with these benchmarks in their own environment, to draw their own conclusions.
It's not about a "final conclusion", just about a summary of the measurement results at hand. Instead of letting the user to trawl through a lot of documents and figures and make geomean and factors calculations him/herself, the author who publishes measurement results should do this. Here is an example how this could look: https://github.com/rochus-keller/Oberon/blob/master/testcase.... It is immediately recognizable how much less time on average the C++ implementation used compared to the reference (LuaJIT in this case).
I agree it would be interesting and a fun project! Correct me if I'm wrong, but the problem with PGO is that every time the code changes the PGO needs to be updated as well. Also, my past experience with PGO (for the GraalVM native-image) is that it improves a bit, but not much. Maybe 50% at best. But again, the only way to know for sure is to do it and measure it. That's something we should definitely dig deeper to see what kind of difference (in practice) it can make.
According to CPUBenchmark.net the M3 Max 16 Core is the fastest single thread cpu with a score of 4,785, followed by the M3 Max 14 Core with a score of 4,771.
Although the numbers above are close, it does not make much sense to me that a chip with more CPUs will be faster on single thread performance than the same chip with less CPUs. But I can be wrong.
Also, according to their list, even the M3 8 Core beats the M4 chips (Pro and Max included). Again on single thread performance. Am I missing something?
Am I missing something or the M3 for single thread performance is faster than the M4?
I can't emphasize enough that I'm only talking about single thread performance here.
That's far from the only number that looks weird. If this site is legit - a point I'm not conceding - it could be that these numbers are the average of some large number of systems, and the tests are not properly controlled for any of the other factors that might affect performance. Amount of memory, memory speed, single vs dual channel, overclocking, CPU cooler, even ambient temperature could all be having an impact on the score, and certain types of CPU could be more likely to be biased in a particular direction.
It's also possible for some of the CPUs that their sample size is really small - so one or two overclocked or hotboxed systems could completely throw off the result.
Agree! But how about the M3 8 Core (4754) beating the M4 Max 14 Core (4614)? I thought the M4s were faster than the M3s (single core / single thread), but it looks like they will only be faster on multi core / multi thread benchmarks. I would think that the sheer speed of a CPU is the single core / single thread performance number.
You're still only talking about a 3% difference. Outside the margin of error for a properly-controlled test - which I don't think this is - to be sure. But small enough that if I went into the BIOS of your PC while you weren't looking and down-clocked the RAM to achieve the same effect you wouldn't notice unless you ran a benchmark.
The number of cores is irrelevant to the measure of single core performance. It is entirely possible that single core performance is less for many reasons up to and including silicon lottery.
Raw performance is also not the only relevant metric. Given that these results are within run to run variance there are other factors to consider such as power consumption.
So yes, this is not at all a shocking revelation to me.
According to PassMark CPU Benchmarks, a trusted source, updated frequently, the M3 Max 16 Core is the fastest single thread cpu with a score of 4,785, followed by the M3 Max 14 Core with a score of 4,771.
Although the numbers above are close, it does not make much sense to me that a chip with more CPUs will be faster on single thread performance than the same chip with less CPUs. But I can be wrong.
Also, according to this list, even the M3 8 Core beats the M4 chips (Pro and Max included). Again on single thread performance.
Am I missing something or the M3 for single thread performance is faster than the M4?
I can't emphasize enough that I'm only talking about single thread performance here.
It's in the thing I linked, which you should read when you get a chance. On HN, you can't put your comment in the title - use the original title unless the original title is misleading or clickbait.
That's still cherrypicking what you think is important and putting it in the title. Lists of benchmark results (with or without made-up titles) in general don't make good HN posts. You can use the search feature to find lots of M-related threads that can probably answer your specific question, though
CoralRing does not produce garbage, but it cannot control what other parts of your application choose to do. It will hand to your application a message without producing any garbage, now if you go ahead and produce garbage yourself then there is nothing CoralRing can do about that. Ultra-low-latency applications in Java are designed so that nothing in the critical path produces garbage.
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.
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.
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
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.
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.
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.
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...
