OSNews

Agreed, but speed is not one of the problems.



The important subsystem is the Matching Engine. It inserts incoming orders, and matches them to other orders. Then the matched deal is sent further to other subsystems to handle the administration. But the important thing is the Matcher, it needs to be fast with ultra low latency and extreme throughput. If not, then the stock exchange will be slow and the HFT firms and Algotrading firms will prefer to trade on another exchange.

The Matcher in NASDAQ is written in Java. There are many other subsystems, the clearing subsystems, the database, etc. But the critical part is the matcher. Much of NASDAQs critical parts is written in Java, but some parts are not. For instance the database.



It varies from system to system, but my point is:


Well, all the fastest stock exchange systems have a matcher that uses UDP, not TCP/IP. You can only achieve sub 100 microseconds with UDP. If you know how to do in another way, tell me, and I will introduce you to one of the largest exchanges in the world, and we will hire you, and you will become rich.

The algorithm to match orders are similar. Basically they are doing the same thing. It is like sorting numbers. In how many ways can you sort numbers? All exchanges are doing the same thing and therefore can be compared. If C++ gives lower latency than Java, then everybody switches to C++. If Mainframes give lower latency, then everybody switches to Mainframes.




No, they are not doing hot swaps and upgrades. In the Evening, the exchange closes and that is when you do upgrades, but that takes lot of testing. The exchanges are slowly going to continuous trading 24/7, but in the evening they are closed where back office and clearing work can take place.

Of course the latency varies. Typically the exchanges say something like: "95% of all incoming orders are matched in 100 microseconds, and 3% are matched in 150 microseconds, etc". But that number is from the gateway to the matcher and back again, thus this number is interesting for co-location (where the trader has the server in the same building as the Matcher). For which we charge a lot.



No, Fortran and Assembler are of course faster. My point is: Java has not performance problems. Theoretically, Java can be faster than compiling once like C++ does.