6 ms·

Java is not slow in practice. Many top trading systems have been written in it, including the excellent and widely licensed nasdaq architecture (omx, singapore,

by cturner 10y ago

Java is not slow in practice. Many top trading systems have been written in it, including the excellent and widely licensed nasdaq architecture (omx, singapore, asx, swx, etc) and the independently designed Lmax Disruptor. You do not have to use any library you don't want to. there is nothing stopping you from building everything in preallocated byte arrays, and never triggering gc. Nio2 is fast. Jvm is a leading foundation of fast, complex distributed systems, particularly if you need multiple programmers working on a single source tree.

rusk 10y ago
Yes Java is as quick as anything else once it is up and running; the point GP was making was getting to this warmed up state is what makes people perceive java as slow.
- pjmlp 10y ago
  A situation that only occurs if one doesn't make use of JVM that cache JIT code like IBM J9, or willing to pay for an optimizing AOT compiler like Excelsior JET. Also another example is those that perceive the JVM as slow due to using it with Clojure, when the slowness in this case is caused by the Clojure implementation itself.
  - matwood 10y ago
    Even without special compilers, most people are using java on the server. Startup time happens once on deploy.
    - akvadrako 10y ago
      ...and much more frequently during development.
  - rusk 10y ago
    True but these approaches have never been marketed as part of the java experience
    - pjmlp 10y ago
      Only by those that aren't doing Java programming. I use Java since the very early days, and am well aware of them, as are my fellow Java developers, when I work in Java projects.
      - rusk 10y ago
        Aren't you great. As a java developer I am well aware of them too. For most people java == java applets; or "hello world" with `javac Hello.java` and then `java -cp. Hello` followed by some interminable wait while all the apparatus of the JVM is marshalled for the sole purpose of emitting a static string and then exiting. And by interminable I mean 2 or 3 second but still. Even in more enlightened scenarios a REPL on jruby is just eye-wateringly painful unless you've all the "secret speedups" enabled. In many more modern development cultures such secrets are generally looked upon as "Yak Shaving".
- cturner 10y ago
  You wrote about preceptions in another part of the thread. But that's not what I replied to. The words are above, and it wasn't about perceptions. But on perceptions: naive perceptions don't justify a false statement. So why draw focus to them, why excuse them? Facts trump perceptions.
  - rusk 10y ago
    Really? I see perceptions Trump fact all the time …
ycombobreaker 10y ago
In my experience NASDAQ's system is both a stellar example of law-latency Java and, due to its rarity, a demonstration of the apparent difficulty. Every other trading system I have seen implemented in Java has suffered noticably from poor memory management (too much GC-related variance). I would expect that Nasdaq approaches their trading software much more like an embedded system, at which point the engineering discipline and mastery of the playform matters much more than the language. Also as mentioned elsewhere in the thread, trading systems don't suffer from frequent cold restarts, so hotspot work amortizes extremely well. So Java is much more optimal there than e.g. a command line tool.

by cturner 10y ago

rusk 10y ago

Yes Java is as quick as anything else once it is up and running; the point GP was making was getting to this warmed up state is what makes people perceive java as slow.

pjmlp 10y ago
A situation that only occurs if one doesn't make use of JVM that cache JIT code like IBM J9, or willing to pay for an optimizing AOT compiler like Excelsior JET. Also another example is those that perceive the JVM as slow due to using it with Clojure, when the slowness in this case is caused by the Clojure implementation itself.
- matwood 10y ago
  Even without special compilers, most people are using java on the server. Startup time happens once on deploy.
  - akvadrako 10y ago
    ...and much more frequently during development.
- rusk 10y ago
  True but these approaches have never been marketed as part of the java experience
  - pjmlp 10y ago
    Only by those that aren't doing Java programming. I use Java since the very early days, and am well aware of them, as are my fellow Java developers, when I work in Java projects.
    - rusk 10y ago
      Aren't you great. As a java developer I am well aware of them too. For most people java == java applets; or "hello world" with `javac Hello.java` and then `java -cp. Hello` followed by some interminable wait while all the apparatus of the JVM is marshalled for the sole purpose of emitting a static string and then exiting. And by interminable I mean 2 or 3 second but still. Even in more enlightened scenarios a REPL on jruby is just eye-wateringly painful unless you've all the "secret speedups" enabled. In many more modern development cultures such secrets are generally looked upon as "Yak Shaving".
cturner 10y ago
You wrote about preceptions in another part of the thread. But that's not what I replied to. The words are above, and it wasn't about perceptions. But on perceptions: naive perceptions don't justify a false statement. So why draw focus to them, why excuse them? Facts trump perceptions.
- rusk 10y ago
  Really? I see perceptions Trump fact all the time …

ycombobreaker 10y ago

In my experience NASDAQ's system is both a stellar example of law-latency Java and, due to its rarity, a demonstration of the apparent difficulty. Every other trading system I have seen implemented in Java has suffered noticably from poor memory management (too much GC-related variance). I would expect that Nasdaq approaches their trading software much more like an embedded system, at which point the engineering discipline and mastery of the playform matters much more than the language. Also as mentioned elsewhere in the thread, trading systems don't suffer from frequent cold restarts, so hotspot work amortizes extremely well. So Java is much more optimal there than e.g. a command line tool.