Forgot your password?
typodupeerror
Java Programming

Using Java In Low Latency Environments 371

Posted by Soulskill
from the shaving-milliseconds dept.
twofishy writes "Something I've noticed amongst financial service companies in London is a growing use of Java in preference to C/C++ for exchange systems, High Frequency Trading and over low-latency work. InfoQ has a good written panel discussion with Peter Lawrey, Martin Thompson, Todd L. Montgomery and Andy Piper. From the article: 'Often the faster an algorithm can be put into the market, the more advantage it has. Many algorithms have a shelf life and quicker time to market is key in taking advantage of that. With the community around Java and the options available, it can definitely be a competitive advantage, as opposed to C or C++ where the options may not be as broad for the use case. Sometimes, though, pure low latency can rule out other concerns. I think currently, the difference in performance between Java and C++ is so close that it's not a black and white decision based solely on speed. Improvements in GC techniques, JIT optimizations, and managed runtimes have made traditional Java weaknesses with respect to performance into some very compelling strengths that are not easy to ignore.'"
This discussion has been archived. No new comments can be posted.

Using Java In Low Latency Environments

Comments Filter:
  • Re:Huh? (Score:5, Informative)

    by bunratty (545641) on Friday August 02, 2013 @10:22AM (#44456071)
    Programs written in some languages run more quickly than those written in other languages. Some languages allow you to write programs more quickly than other languages. Therefore, the choice of language is always a tradeoff. There is no perfect programming language, and no, not all programming languages are alike as you seem to believe. If I want to write a program quickly, I write it in Python even though I know the program will run quite slowly.
  • by Anonymous Coward on Friday August 02, 2013 @10:28AM (#44456125)

    Java can be compiled to native code.
    C and C++ can be interpreted.

  • by tonywestonuk (261622) on Friday August 02, 2013 @10:28AM (#44456127)

    You do know that Java is compiled to native, don't you?

    The only reason Java is slower than C, is because C can have unchecked arrays, or low level access to CPU registers or vector SIMD.

    Given the same code written in both C and Java, and including C range bounds checking (to make it as safe as Java), the speed will be the same. Or, quite possibly Java would be quicker once the JVM starts stripping away the checks once it realises there is no possibilities of bounds been breached.

  • Re:Yes (Score:4, Informative)

    by bunratty (545641) on Friday August 02, 2013 @10:29AM (#44456143)
    Java is far, far safer than C++. C++ does not enforce type safety at all. For example, in Java you cannot possibly have a buffer overrun or access freed memory as you can in C++. I think most of the security notices are about C and C++ programs, not Java programs. I think you're referring to the Java runtime, which is written in, you guessed it, C.
  • by I'm New Around Here (1154723) on Friday August 02, 2013 @10:35AM (#44456209)

    So now the polls are allowed to have comments, they are for data mining only, not discussion.

    Why?

    What is the reason we can't talk about the subject of the polls anymore?

  • by TemporalBeing (803363) <bm_witness.yahoo@com> on Friday August 02, 2013 @10:36AM (#44456213) Homepage Journal

    You do know that Java is compiled to native, don't you?

    Yes, Java can be compiled. It can also be run interpretted. Either way, it runs in a Virtual Machine, which in and of itself adds another layer in the stack and slows the software down, however small the difference may be it will be there.

    The only reason Java is slower than C, is because C can have unchecked arrays, or low level access to CPU registers or vector SIMD.

    Given the same code written in both C and Java, and including C range bounds checking (to make it as safe as Java), the speed will be the same. Or, quite possibly Java would be quicker once the JVM starts stripping away the checks once it realises there is no possibilities of bounds been breached.

    And yet in embedded environments the advise when using Java is do to write in software in such a way that the GC is never invoked because it causes major performance penalties at unexpected times.

  • by Anonymous Coward on Friday August 02, 2013 @10:37AM (#44456225)

    I used to work for a company that provided high frequency trading software. We once competed with 4 other companies for a sale to a rather large client, one of them were written in C one was written in C++, the other was unknown. We beat them by 10% (performance was the time a price update was received on the the LAN to the time an order went back out on the wire, as measured from network sniffing device, all tested by them on their hardware). Our software would run 1k-2 warmup/test updates through the system after startup before it went into live trading mode, by then all the critical paths had been fully optimized and compiled to CPU specific instructions. We even tried commercial Java to binary compilers and the standard jvm beat them (after the warmup period). When you compile C/C++ program you usually dont do it for a specific cpu to take advantage of specific instructions, when the JVM JIT kicks in on fully optimized code it is optimized for the specific chip in the computer (again, this is after a warmup period, but in these cases or the case of a web server those are fine). Memory allocation in java is faster than C/C++ and has a higher natural rate of locality of reference, the trade off of course is the gc phase, but using parallel mark and sweep algo's the lock time is relatively small, our customers (your banks) were willing to risk 1 in 1000 transactions being delayed by gc in order to get a 10% boost on over their competitors on the other 999 transactions.

    In the end we were acquired by a multinational corp, I gave them the finger, now I work for a start-up.

  • by serviscope_minor (664417) on Friday August 02, 2013 @10:39AM (#44456259) Journal

    The only reason Java is slower than C, is because C can have unchecked arrays, or low level access to CPU registers or vector SIMD.

    That and C and C++ have faster allocation and deallocation of temporaries. And they have no runtime specification of what's going on, so the optimizer is allowed to do more.

    Specifically, C/C++ (one of the few times where such a phrase is meaningful) require the programmer to specify stack allocation or heap allocation. Stack allocated objects are completely free. At the point of function call and return, it simply uses a different size for the increment/decrement.

    Java has an excellent heap allocator (very fast) and can do good escape analysis, but very fast is aloways slower than free and escape analysis is never as good as by-hand specification.

    In terms of the optimizer, java specifies all sorts of things about how stack traces from exceptions must be accessed and so on. C/C++ don't specify anything about those. As a result, the optimizer is free to remove more stuff than in C/C++ than Java. If you compile with -O3, it's not uncommon to find the debugger thinks you're in a completely different place than seems to make sense.

    Or, quite possibly Java would be quicker once the JVM starts stripping away the checks

    The thing is, java trades some safety and tighter specification for some performance loss. C and C++ allow the programmer to specify more. While the JVM is very good at removing a lot of stuff, it's always fighting an uphill battle to remove stuff that simply isn't there in C and C++.

  • Java vs. C/C++ (Score:3, Informative)

    by Anonymous Coward on Friday August 02, 2013 @10:42AM (#44456285)

    For simple applications that don't deal with a lot of dynamic memory, Java is almost as fast as C/C++. Unfortunately, trading systems are not such - I know because I worked in that domain for some time, in the 1980's and again in the 2000's. Java's biggest issue is garbage collection - it is decidedly non-deterministic. IE, it can have SERIOUS impacts upon performance, and at times that cannot be pre-determined. In my experience (30+ years), if you need consistency and speed, then you do not select Java for your environment - and I do a LOT of Java development. I just don't use it when I need the software to have a small footprint, be fast, and stay out of the way of other system processes.

  • by Anonymous Coward on Friday August 02, 2013 @10:51AM (#44456369)

    Ram is cheap, and you have control over the max heap size on your java call, so I don't know why you think disk swapping is a problem. Not only that, but garbage collection can actually speed you up in some cases: if you can defer memory management from a time when it would slow you down to a time when you're sitting on free time anyway (waiting for io, etc), you are actually sometimes better off.

  • Re:Huh? (Score:5, Informative)

    by LostMyBeaver (1226054) on Friday August 02, 2013 @10:52AM (#44456379)
    Some people also work on multi-million line projects which compile in a minute or less. It's a trade-off. Most compiler issues are related to obscene (and generally unnecessary) amounts of header dependencies. 1000 lines takes an almost immeasurably small period of time to compile, but a 2 line file can take a minute if it includes the wrong headers. The ISO C/C++ library or boost is pure evil in these regards.

    A well formed program can compile extremely rapidly. A poorly formed program can often compile extremely quickly with enough CPUs working in parallel across a fast enough network. However a decent program will take time for the initial compile but take almost no time for each consecutive compile when only a file here or there changes.

    Also, to make things politically incorrect on Slashdot, good tools like Visual C++ 2012 can even take poor code and make it compile quickly if the projects files are designed well. Do your coding there and compile it later on GCC.
  • Re:Huh? (Score:5, Informative)

    by darkHanzz (2579493) on Friday August 02, 2013 @11:21AM (#44456693) Journal
    Use RAII consistently, and use containers (from stl or otherwise) which have asserts() on bounds-checking. Bonus points for a tiny unit-test (which can therefore run at the end of every compilation). You'll be amazed at how stable, maintainable, easy to debug and performant your code will be.
    Do the hardcore pointer handling only where the profiler tells you that it matters and there's no way java even gets close in performance
  • Re:Huh? (Score:5, Informative)

    by bws111 (1216812) on Friday August 02, 2013 @11:44AM (#44456961)

    Any JVM that would run this code will be tunable, including the ability to tune the GC so it becomes more deterministic. The fact that your desktop app runs in 'use all memory then GC' does not mean that is the only way the JVM can work.

  • Re:Huh? (Score:5, Informative)

    by Infiniti2000 (1720222) on Friday August 02, 2013 @11:50AM (#44457025)
  • Re:Blah blah blah (Score:4, Informative)

    by tlambert (566799) on Friday August 02, 2013 @01:17PM (#44458267)

    This struck me as well. In the original article, they put a bound of 100 milliseconds as counting as "low latency" in their book, but Wikipedia's article on algorithmic stock trading puts it in the microseconds instead:

    "Low-latency traders depend on ultra-low latency networks. They profit by providing information, such as competing bids and offers, to their algorithms microseconds faster than their competitors."

    https://en.wikipedia.org/wiki/Algorithmic_trading#Low-latency_trading [wikipedia.org]

    100 milliseconds is about 10,000 times too slow, even if we are talking in the neighborhood of "tens of microseconds faster", rather than just "microseconds faster".

    Here's an article from 2011 where they justified spending $300M ($0.3B) on a new transatlantic cable to eke out an extra 6 milliseconds: http://www.telegraph.co.uk/technology/news/8753784/The-300m-cable-that-will-save-traders-milliseconds.html [telegraph.co.uk] That's just 6% of the 100 milliseconds that these Java guys are willing to waste running Java instead of C code.

For every bloke who makes his mark, there's half a dozen waiting to rub it out. -- Andy Capp

Working...