I have written automated systems in all three languages. First C++ is WAY WAY WAY overrated as a superior language. I am an old guy here and I remember when the Fortran people used to say, "oh that C++ will never be as fast as Fortran". Lo and behold it was and now the C++ people are saying the same thing. With all that being said, the reality is as follows. C++ is faster if you chuck the "safety" features of programming languages and avoid things like STL, and Boost. In raw bytes to bytes C++ is faster, but then again so is C. The moment you add the baggage of STL, and Boost you are slower than well written C# code. The advantage that the C# JIT and Java jit have is that those safety features are well optimized. C++ safety features rely on the optimization of the compiler. Thus if you are not careful with your STL, and Boost code you will have a lame duck of an application. If you are not careful with your object references in C# or Java then you will also have lame duck applications. Let me illustrate... We all know about OHLC (Open High Low Close) The classical object approach is to define the OHLC as individual classes and put it into a List<OHLC>. THAT IS MEGA SLOW... In C# you need to define the OHLC as a struct and then create an array like the following OHLC[]. That simple step in itself has a massive speed up factor. I personally would never touch C++ again. I would rather tweak and optimize my C# or Java code. My development with C# or Java is 100 times more productive than farting around with a dangling C++ pointer that causes a core dump. If you plan on using C# or Java make sure to invest into a profiler like the one from Jet Brains. A profile will quantify what is slow code, and not be reliant on what you think is slow.
Programmer productivity is almost always the more important factor, and so the best language is usually the one you already know (unless it's Fortran or Cobol ). Also, upgrading to more powerful hardware is often cheaper than re-optimizing software unless you've done something really dumb.
I did not want to say that as an argument... But yeah I agree with you. I am so much more productive with C#, or Java.
I think one of the largest Java platform's is ThinkorSwim's desktop application. It's gotta be 1/2 million lines of code....at least.....and it uses multithreading to-the-max.
Or Interactive Brokers... Think or Swim is considered a dog by some. However I always thought IB's TWS was pretty quick.
In my humble opinion higher abstract level languages like Java, C#, Scala, etc is to bloated for any low latency work. Abstraction add overhead, object orientation add overhead. Bad design add overhead. I use C and Assembler for my HF and algo stuff as it's what I'm used to and is a little bit faster than C++. Some stuff of concern to me: - Most efficient L1/L2/L3 cache utilization. Use as small data types as possible to pack as much data as possible into the caches. - Context switching and maximum best thread design, keep all cores saturated at full speed at lowest overhead. - Most efficient transfer and utilization of the memory bus between the main memory and CPU/Caches, here size of the used data types play an role. - Lowest size footprint, you want your code and variables to reside in the caches to the most so you do not get to much slow memory access.
I am not going to debate that abstraction, object orientation, and bad design add's overhead. It does. However to say that Java, C#, and Scala (which is Java) are bloated is actually incorrect. The problem with the typical compilers is that they only do a generic optimization. Even with special flags the optimization is still generic. From the perspective of C# and .NET the JIT compiler dynamically analyses the code behavior and then optimizes. This is why if you are careful with how your write your C# code it can be darn fast. Additionally with C# you have access to low level C type constructs. These constructs can be used to speed up the application. All of what you are talking about can be done with C#. And I have the additional advantage that I will not shoot myself in the foot via a core dump. I also go by the theory that the slowest link is still and will always be the network connection. Sure you can speed up the link, and make your code the fastest that you can. HOWEVER, all you are doing is running is an arms race. I know because the folks I dealt with wanted to create code in hardware via programmable circuits. Other folks I know create algo's that jump the gun and do probabilities. Unless you happen to be one of the big institutional players you are going to be outgunned and picking up scraps. Not saying that it can't be done. However if you were starting out and trying to get going using the assembly, C or C++ route is just going to give you a heartache.
the misconception java is slow is mostly due to the fact its garbage collection is not manual and bad programmers. Modern day java can handle anything comparable to c and c++. The ease of programming and build once run anywhere far outweighs the tiny tradeoff of running the additional jvm. The only reason ibanks still use a lot of c++ in their front office is because of the legacy systems built many years back and as a result a lot of their developers are c experts not java. Many are switching over to java now after the migration from solaris to linux, and the clusterfuck mess trying to port over legacy c++ codes. I worked on the api with quite a few of those teams to hook up to our system. I think java has long been proven as the right choice.
This is a good post but no conclusion between Java and C# yet. It is 2013 now and look like Java is winning the battle at the moment.