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 516704
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: C++ forever
by Kebabbert on Wed 2nd May 2012 12:25 UTC in reply to "RE[2]: C++ forever"
Kebabbert
Member since:
2007-07-27

Because, as we all know, C++, being a compiled language, can never ever ever be written to compile into bytecode to be JITed at a later stage. That is why, due to your argument, the whole LLVM project ceases to exist from this very moment!

Sure, if C++ is compiled into bytecode and run on adaptively JIT, then C++ can also achieve Java performance. Never mind.

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.



What a completely scientific comparison. Because, as we all know, NASDAQ and LSE run the exact same hardware and middleware and the volume of data they receive is exactly the same. Not to mention that their management is also exactly the same, with exactly the same amount of money being spent on the hardware infrastructure at the exact same time. Not to mention that we are absolutely sure that the NASDAQ is written in 100% Java with no JNI or processing being distributed to compiled language subprocessors. By that same token, we thus know absolutely that LSE is written in 100% C++ with no processing being distributed to subprocessors written in Java or Python etc.

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.

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.



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.

Reply Parent Score: 2

RE[4]: C++ forever
by kwan_e on Wed 2nd May 2012 12:46 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