Linked by Thom Holwerda on Mon 30th Apr 2012 19:17 UTC, submitted by bowkota
Legal Java creator James Gosling: "Just because Sun didn't have patent suits in our genetic code doesn't mean we didn't feel wronged. While I have differences with Oracle, in this case they are in the right. Google totally slimed Sun. We were all really disturbed, even Jonathan: he just decided to put on a happy face and tried to turn lemons into lemonade, which annoyed a lot of folks at Sun." Ouch. Also, doesn't jive with Schwartz' comments - might be illustrative of how bad things really were at the once great Sun.
Thread beginning with comment 516711
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: C++ forever
by kwan_e on Wed 2nd May 2012 12:46 UTC in reply to "RE[3]: C++ forever"
kwan_e
Member since:
2007-02-18

My point is that Java can be fast, if you know how to do it. Have I proved my point? Java can be very fast, and rival C++. So, how is Java bad and slow? It is the fastest in the world.


Please point to where I said anything about Java's speed.

Java is bad in many other ways than speed.

I work in this business and NASDAQ is completely built in Java. LSE is built in C++. If you dont believe me, confirm this with guys that work at NASDAQ or LSE.


Right. I believe you. Every single line of code in NASDAQ is Java, while every single line of code in LSE is C++. I'm also to believe that NASDAQ Java does not use any JNI or farms out to non-Java systems. So I assume, then, that the databases and backup solutions for NASDAQ are also written in 100% Java.

Also, these stock exchanges use commodity x86 servers. No special hardware, no risc cpus, no mainframes, or whatever. Just ordinary x86 servers. Typically with 32GB RAM and dual hexcore cpus, or so. Nothing special. Confirm this with guys working in the exchange business if you dont believe me.


Yes, but how many? What is the parallel set up? What is the NETWORK hardware? What is the total setup?

The flaw in your argument is that you expect us to believe NASDAQ and the LSE are implemented in exactly the same way using the exact same algorithms, the only difference between the two being the language used.

If I'm not mistaken, the NASDAQ and LSE would be making upgrades and hot-swaps all the time. Do you really expect people to believe that these latency figures are static and directly reflects the languages being used?

Still my point is; if you know what you are doing, then Java can be fastest in the world, and Java exchanges rival or surpass C++ exchanges. So, Java is fast. But that requires knowledge. For instance, how do cope with the garbage collector in Java? I know how to do that.


Java can be fastest in the world? So you're saying Java has surpassed Fortran in supercomputing? Not even I go so far as to say C++ is better than Fortran for speed.

Reply Parent Score: 2

RE[5]: C++ forever
by Kebabbert on Thu 3rd May 2012 08:22 in reply to "RE[4]: C++ forever"
Kebabbert Member since:
2007-07-27

Java is bad in many other ways than speed.

Agreed, but speed is not one of the problems.


Right. I believe you. Every single line of code in NASDAQ is Java, while every single line of code in LSE is C++. I'm also to believe that NASDAQ Java does not use any JNI or farms out to non-Java systems. So I assume, then, that the databases and backup solutions for NASDAQ are also written in 100% Java.

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.


Yes, but how many? What is the parallel set up? What is the NETWORK hardware? What is the total setup

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

The flaw in your argument is that you expect us to believe NASDAQ and the LSE are implemented in exactly the same way using the exact same algorithms, the only difference between the two being the language used.

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.



If I'm not mistaken, the NASDAQ and LSE would be making upgrades and hot-swaps all the time. Do you really expect people to believe that these latency figures are static and directly reflects the languages being used?

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. ;)


Java can be fastest in the world? So you're saying Java has surpassed Fortran in supercomputing? Not even I go so far as to say C++ is better than Fortran for speed.

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.

Reply Parent Score: 2

RE[6]: C++ forever
by kwan_e on Thu 3rd May 2012 12:11 in reply to "RE[5]: C++ forever"
kwan_e Member since:
2007-02-18

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.


Yes, and my point is that your point is completely irrelevant because it comes down to implementation of the language itself, which is not, in any logical sense, a part of the DEFINITION of a language.

C++ is not defined to be compiled to machine code once only. Neither is Java defined to be compiled to a JVM.

You may as well be arguing that a PostgreSQL server is faster than C++. It's a completely meaningless comparison.

Reply Parent Score: 2