I agree! Having worked with both C++ and Java top HFT firms, I know that both languages are capable of doing the job with the latencies requirements of a prop-trading firm. *However I must give credit to the OP for actually taking the time to put up a scientific experiment to clearly and unambiguously state his/her point.* What I see the most out there is people from both sides making bold statements backed up by zero empirical proof. It is like two chess players both claiming they are the best, but they are never seen playing against each other. Each is so sure about their own superiority that they don't even bother scheduling a match. I'm just better than you, accept and move on.
> And it also demonstrates the dearth of benchmarking skills out there. I could nitpick a lot of things in this SO entry Would you mind fixing his C++ code to address the many problems you've detected on it? *With code, not with words.* I would love to see a faster version that would beat the Java one. > There ain't a whole lot of bubble sorting in financial applications - at least not at any trading firms where *I've* worked. I think the OP did that because writing two equivalent trading strategies in C++ and Java, or two full-blown trading platforms, one in C++ and one in Java, and then comparing is an unrealistic (if not an impossible) undertaking. One would expect that for simple and concise operations, like moving memory around for a sorting algorithm, the language's performance strengths can be accessed and compared. Of course testing all possible algorithms and logic combinations is not possible. Maybe one day with quantum computers :) As my adventures with GraalVM have shown me, *the point is not Java x C++, but JIT vs AOT.* Cheers, -RB On Sun, Jun 26, 2022 at 6:44 PM Mark Dawson <medawso...@gmail.com> wrote: > I agree. This is a silly battle. > > And it also demonstrates the dearth of benchmarking skill out there. I > could nitpick a lot of things in this SO entry, but for the purpose of the > OP's question I'll just leave you with this: > > There ain't a whole lot of bubble sorting in financial applications - at > least not at any trading firms where *I've* worked. At the very least, you > wanna make sure the workload you're observing is representative of what you > expect to use in reality before basing any decisions on it. > > I could go on but this benchmark is so poorly conceived & the Java vs. C++ > debate so well-worn that I'll just leave it at that. > > On Sun, Jun 26, 2022, 4:31 PM Kirk Pepperdine <k...@kodewerk.com> wrote: > >> Silly battle… in years past I’ve hand rolled assembler for bits of hot >> code paths in C apps after profiling to see if it was necessary… >> >> >> —- Kirk >> >> On Sun, Jun 26, 2022 at 00:15 Roger Bergerin <roger.c.berge...@gmail.com> >> wrote: >> >>> Hello, >>> >>> I've come across this SO post: >>> https://stackoverflow.com/questions/72744401/why-java-turns-out-to-be-faster-than-c-in-this-simple-bubblesort-benchmark-exa >>> >>> The OP coded two versions of a BubbleSort application and was able to >>> show that C++ is consistently slower than Java. Some of the arguments in >>> favor of C++ was that: >>> >>> *"C++ is not always faster than Java but it can always be made faster >>> than Java"* >>> >>> Considering a zero-gc Java application properly warmed up I think that >>> this argument is flawed or at least very unrealistic for a real-life >>> application development project. The OP went ahead to say: >>> >>> *I've tried clang++ and g++ with a variety of optimization options (-O2, >>> -O3, -Os, -march=native, etc) and they all have produced slower results >>> than Java. I think at this point to make C++ faster I have to dive into the >>> generated assembly code and do some assembly programming. I'm wondering how >>> practical is this approach (assembly programming and assembly debugging) >>> when coding a large real-life application.* >>> >>> I must agree with the OP when he/she says that assembly programming is >>> not practical and debugging assembly code generated by the C++ compiler is >>> a pain in the butt. I can only imagine the time-to-market of a financial >>> application developed that way. >>> >>> My observations have found that C++ is often slower than Java, as >>> his/her simple BubbleSort benchmark demonstrates. It turns out that the >>> HotSpot is able to do a fantastic job generating ultra-optimized assembly >>> code with real-time application profiling information. >>> >>> Another point worth mentioning is that ahead-of-time compilation is very >>> often much slower than just-in-time compilation. I've recently used the >>> GraalVM to compile my entire Java application ahead-of-time to native code. >>> When I've benchmarked my native Java application it was consistently much >>> slower than my HotSpot one. >>> >>> Anyway, I was wondering your opinion about C++ vs Java when it comes to >>> performance for finance applications. >>> >>> Cheers, >>> >>> -RB >>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "mechanical-sympathy" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to mechanical-sympathy+unsubscr...@googlegroups.com. >>> To view this discussion on the web, visit >>> https://groups.google.com/d/msgid/mechanical-sympathy/fbdd6869-66f9-455a-90ab-dd3838aec694n%40googlegroups.com >>> <https://groups.google.com/d/msgid/mechanical-sympathy/fbdd6869-66f9-455a-90ab-dd3838aec694n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "mechanical-sympathy" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to mechanical-sympathy+unsubscr...@googlegroups.com. >> To view this discussion on the web, visit >> https://groups.google.com/d/msgid/mechanical-sympathy/CAD5RQ-BOGD3sX394yqCKm1fsqrwRohV5DWx6KfCRhgtE%3DAHjyQ%40mail.gmail.com >> <https://groups.google.com/d/msgid/mechanical-sympathy/CAD5RQ-BOGD3sX394yqCKm1fsqrwRohV5DWx6KfCRhgtE%3DAHjyQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > You received this message because you are subscribed to the Google Groups > "mechanical-sympathy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to mechanical-sympathy+unsubscr...@googlegroups.com. > To view this discussion on the web, visit > https://groups.google.com/d/msgid/mechanical-sympathy/CAFvqqVeSyvi45-MPoOXOPY3H3OQ9hRC8ryae42%3DX44uHkB_ZpQ%40mail.gmail.com > <https://groups.google.com/d/msgid/mechanical-sympathy/CAFvqqVeSyvi45-MPoOXOPY3H3OQ9hRC8ryae42%3DX44uHkB_ZpQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/mechanical-sympathy/CAH8B-Z0zAGqbmKbko6kh37%2BKa17TPe3wg9tuD6yJtrRMNLqZnw%40mail.gmail.com.
