Slashdot Mirror
Using Java In Low Latency Environments
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 Slashvertisement brought to you by: Dice.com
I find java helps me with my latency :)
Why would the language of choice matter terribly much if the programmer has skills with the language?
Wouldn't a C++ programmer generate an applicable program effectively as quickly as a Java programmer? It's not like compiling is the time-consuming part anymore...
Do not look into laser with remaining eye.
You forgot to mention that Java programs don't even compare to C/C++ in terms of memory usage. Past 10 years didn't change that.
I think currently, the difference in performance between Java and C++ is so close that...
Okay, clearly the new batch of slashdot editors have absolutely no programming ability whatsoever. They also must have missed that slashdot story about how Facebook undertook a massive campaign to translate their PHP code into C/C++ executable to speed up performance. Java is a lightweight language. It cannot, and will not ever be as fast as C/C++ because it is an run time interpreted language that additionally runs in a virtual machine.
I am forced to conclude that the slashdot editors are trolling us by approving such a patently absurd and idiotic article.
#fuckbeta #iamslashdot #dicemustdie
Those people who have moved from Java to JavaScript by way of Ruby say that Java is slow, even slower than JavaScript. It must be true. They wouldn't be lying or misinformed, would they?
if you take two software engineers, one for java one for C, which both are the best experts in their language inthe world... C will be faster.
Using Java is just a trend, because the lack of C knowledge.
... is that you get to rewrite your applications in 2 years? Or less?
Thats exactly what I would do. I'd take the most insecure, badly run, malware and virus vector based language and embed deeply in sensitive and financial systems.
Why not? What can possibly go wrong.
I wonder when Java will be able to be updated by an admin account via a standard user account on Windows. But then I wonder when Oracle will wake up and smell the coffee.
We`re all equal
old: HFT
new: MFT
Go Solaris : Erlang ;-)
Challenge Accepted!
The chest beating about Java vs C is kinda sad. Look, I've spent the past 20 years hating java with the fire of a 1000 suns, but having been kinda forced to use it lately I've realised its actually not a bad language, in fact its quite neat and well thought out (But god help me, somehow its date handling is even more broken than javascript)
The problem is all the verbose cruft that goes with it. The giant overly complicated frameworks that require configuring 50 different XML files fed through a labrynith undocumented build process that allows you to write terse and insane pattern-madness code ....or alternatively just fire up JDBC and write a bloody SQL query instead.
I think JAVA could shine if people just threw out about 15 years of insane and overly complicated frameworks and took some tips from the python and perl people and replace them with some simple but effective libraries that do one thing and do it well.
But hey, at least its not bloody javascript!
Excuse the Unicode crap in my posts. That's an apostrophe, and slashdot is busted.
Java does NOT perform anywhere close to as efficiently as C/C++. You might be able to get message transmissions to take the same time, but the Java environment will undoubtedly take more system resources. The same happens with any through the kitchen sink of libraries at it interpreted language. .Net, Java, Ruby. In my experience Perl runs faster than those 3 but managers have been led to believe that Perl has a slower time to market, thus is slipping from the mainstream. The closer you get to stripped down, just what you need, compiled language, the faster and less system resources the code will take to execute.
The big issue with language decisions these days is that they tend to be driven by perceived market value. People are the most expensive cost to most businesses these days. So the marketing battle between languages focuses less on performance and more on how experienced and expensive your developers need to be. What I see being missed with this marketing is that by lowering the people quality and marginalizing your language and code quality, you are setting yourself up for maintenance, improvement, and performance costs down the road.
There is or can be built a machine that can simulate any physical object. -Church-Turing principle
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?
If you think I voted for Trump because of this post, you're wrong. I voted for Dr. Jill Stein of the Green Party. Again.
A run time interpreted language that in real life JVM implementations is a run time profiled, optimised and compiled language. That can create better optimised code than any compile time optimiser could because it's optimising against the actual workload instead of guessing what it might be and compromising against many possibilities.
Java is a shitty language with many nasty aspects, you managed to pick the one thing it can get very right. Not much of a programmer then.
Can you use GCJ to compile to native? I never tried it, but I have this impression you can write in Java and compile to native with GCJ instead of bytecode, and you should be on par with C++.
Why is there a new poll on the front page but it's already archived so we can't post comments?!
And what the hell is "A tough tighter" ?!
Java runs in a virtual machine, and is compiled "just in time".
For "real time" applications, that need guarenteed latency, this is a no no.
Java's garbage collection, running is also a no no.
Real time applications need hard deadlines, that are deterministic. A function must always return X mSec, regardless of any other things like GC, etc.
Just imagine if say a pacemaker ran Java.
"I detected an unusual event, but I have to run GC first, then process the event..oh, what the patient is dead?"
Why don't we have for ultimate speed, a java interpreter written in java, running on a java interpreter written in java running on... ad nauseaum?
I don't want a 15 min boot time for my embedded system. there is a reason most Android tablets have huuuge lag at unexpected times. Give me access to the bare metal any day. I'll figure out memory management myself, thank you very much!
Then again, I come from the embedded days, when memory was and sometimes still is, measued in Kb, not Gb.
Java is great for student programmers and others of limited skill that need to produce *something* ,at limited cost. They can't really harm the underlying system, and don't need to lean any hard concepts like memory management and real-time deadlines.
Step 1) Don't.
Step 2) See step 1.
C developers often get accused of trying to use their particular hammer to drive in every screw they see. This very much counts as the other side of that equation.
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.
I suppose as long as the programmers are ACTUALLY equally skilled it would be fine, but from what I've actually experienced in the real programming world, the C++ programmers are generally all fairly experienced skilled programmers who write effective efficient code. With Java programmers, I have seen quite the opposite, sure there are those experienced skilled programmers who could compete, but a LOT of Java programmers even ones with equal 10-12 years of experience, suck monkey balls at actually writing efficient code. Instead they write code that's JUUUST good enough. That said I know a number of people in the HFT market and the programming languages are ALL over the place, sure some of them are in Java and some are in C++, but there's not any one dominating language: there's plenty of Python, Scala, Perl, Groovy, and probably every language you can image. I believe Perl is actually still the biggest language because a lot of the financial analysts can actually write it directly and so do stuff that the front end systems don't normally allow.
I've noticed that financial software jobs often look for C#, I'm guessing it's because Visual Studio and its debugger gives the engineering leads (who typically have domain expertise in financial systems) a warm fuzzy feeling.
Then maybe some of them decided to move to commodity x86_64 Linux servers, so they needed a replacement for C#. Java is the obvious bet, along with Eclipse I guess (but they'd better have LOTS of RAM or they'll be crying over "out of heap memory" errors).
Low latency is not measured in the millisecond, but in the microsecond. I'm so tired of hearing about how special the HFT think they are.
Really I'm not trying to troll here
12 years ago I started in the backing sector in London, and over the last 5-7 years I have been working/involved in the Algo trading arena
I have always used Java to write the Algos
If Java ever ran Garbage Collection properly, it would collect the whole spec and lanaguage, destorying itself, or sending it neatly packaged up to the curb.
I am tired of input lag.
I am tired of 15 million different versions of the interpreter, all with conflicting libraries, specs , etc.
I am tired of having to install hundreds of Mb of crapware for some crapplet.
I am tired of unpredictable runtimes, poor debugging messages, poor quality manuals, poor quality docs, etc.
Good Lord what a load of uninformed CRAP
Uh since around 1.3 the JIT optimization for java has led to blindly fast code containing optimizations which are not even available to C++ . Dynamic compiling allows for branch prediction to be more accurately, unlike malloc, the GC knows where to look for free memory and returns it from the last bit of memory you just requested, if you know where pointers are pointing at compile time, you can put them in registers. C++ and other statically compile languages don't have this information, so it stores them in cache, but the JIT can acquire this information and store it in a register. It's the difference between a register to register test and reading from disk.
There are tons of other stuff like this. I don't have it committed to memory, and compiler technology is not my thing but if you look around you'll see that actually GC and JIT are theoretical advantages in terms of speed and those advantages are being realized. It can even figure out what chip it's being run on at runtime and optimize the code for that chip.
The Java is Slow Meme is left over from 1995 before there was even HotSpot.
Not bashing any other language here. C# could also avail itself of these advantages.
Leaving aside my political beliefs that high speed trading needs to be banned, let me say this.
Switching to Java should yield similar results to C++. What matters is whether the programmer understands the memory architecture of the run-time environment well enough to not have issues. Generally, you'll find that even the best programmers in either language will overlook things like garbage collectors and memory fragmentation issues. It's a time-to-market thing. When working with large dynamic data sets, it doesn't matter if you're using Java or C++, the developer needs to be able to adapt their code to perform well on the system.
Code written without considering the processing time of memory management will probably work much better in C++ than Java. That said for huge data sets, Java could perform better since the memory itself is location independent and it is highly probable that you're gain a great deal of performance from being able to defragment memory. Consider however that the garbage collector and the defragmenter will have unpredictable times which can cause multi-millisecond hiccoughs during processing.
I recommend if you take this route, you hire a compiler geek to work on staff optimizing the memory operations.
First I am not saying that Java has no place.
To me this is not a case of Java being fast enough as good enough. Keep in mind these are people who are building their own microwave towers from one exchange to another to shave microseconds. But also keep in mind that this is is also the era of big data. So you now have a situation where you have to process insanely large amounts of data in near as is possible to real time in order to make trades "Now!"
So if I write a test program in Java that connects to a database and adds up a few columns and then compare it to the same program written in C++ I doubt that there will be a big difference. And if you trading algorithm is small then Java is probably best as your time to market will be shorter.
But if you have 5 Gigs of data coming in every 10 minutes that needs to be sifted, sorted, and processed, then again time to market might be better with Java and the processing time might not be that different. But now if you start to get cool and are using crazy Algorithms to squeeze your data dry then you might be pushing up against the limits of the hardware itself. Now you must be in C++ land or you needn't bother. The processing time difference between C++ and Java will be great enough that the market will move faster than your computers can.
Now this last case might seem like the weird case so a person could say well Java covers 95% of our needs. The problem is that if you have no C++ development at all then starting C++ just for this extreme case will not be easy to support. Thus a nice mix of Java and C++ is probably better than just one or the other.
A great example of this sort of experience for us programmers would be Eclipse and Sublime Text 2. Eclipse is mostly Java and for years drove me mad as it would start grinding away at whatever. Or I would start typing code and Eclipse would sit for 10 seconds before a bunch of my typing showed up. It took forever to start and so on. Sublime text starts in a flash, runs at warp speed, and has extra cpu cycles left over for things like the mini-side-view. Again this is not a perfect comparison as Eclipse is much more of an IDE and does 1 billion other things but I find they both are reflective of the Java and C++ philosophies. Java programmers love creating an object for damn near every thought that pops into their heads. They love multiple levels of abstraction. Whereas many C++ programmers are 70% C programmer and 30% C++ programmer which is a near endless war within the C++ world. So C++ programmers tend to head for the simplest possible solution, not the most flexible solution, not even the most maintainable solution.
So in the trading world if I were laying out the staff and the architecture for a large zillion user trading system that will be created and maintained by a large team(s) of programmers then I would stick with Java. If I had a small crack team who are to build a system for implementing an ML system that looks at traffic patterns to predict spot corn prices in the next 5 minutes then C++ all the way baby!
Networking is far from low latency, it will always be the bottleneck, even if you use QBASIC.
I'm not a Java user, so I've never directly tuned for things like GC, nor do I interact with it directly. Warm up is a different story.
I interact with quite a few exchanges (over all kinds of protocols). Most are, unsurprisingly, written in Java. Almost all of them perform terribly at the beginning of the week. The issue is a standard one: the JVM hasn't JITted important code paths, and it won't until several thousand requests come in. For a standard throughput-oriented program, this doesn't matter -- the total time wasted running interpreted code is small. For a low-latency network service, it's a different story entirely: all of this wasted time happens exactly when it matters.
The standard fix seems to be to write apps to exercise their own critical paths at startup. This is *hard* when dealing with front-end code on the edge of the system you control. Even when it's easy, it's still something you have to do in Java that is entirely irrelevant in compiled languages.
If JVMs some day allow you to export a profile of what code is hot and re-import it at startup, this problem may be solved. Until then, low-latency programmers should weigh the faster development time of Java with the time spent trying to solve annoying problems like warm-up.
I have worked on a number of trading systems and other real time data acquisition solutions.
In low latency environments going native is the only way to go. In some super low latency environments the code is written in Assembler aka machine code. The compiled code (exe's) are reviewed for excess code introduced during the compiling in hex. The application run thru a number of stress tests to analyze IO, cpu, memory and network utilization. A strong developer understands at a very low level how these resources get used and their costs to speed.
I built a real-time interface to some hardware in Smalltalk 20-years ago! (Yikes!) Since Java and Smalltalk have the same GC theory (at least, simplistically), some of my experiences would translate. I also spent 5-years running high-performance, low(ish) latency stuff in Java too. The simple rules of low-latency Java (or Smalltalk) are: - Create less garbage. Don't tell me that the GC is an issue when you are creating huge garbage. If your application is running in a tight loop (small amount of code being run a LOT of times), spend time on understanding the GC generational model... create only small temporary objects, and really focus on understanding where every object goes. If you can avoid the stop-the-world gc from kicking in (and you can), then most of the issues go away. - Force a GC before you go into low-latency land. This was something I could do in Smalltalk 20-years ago... I would force a GC right before I went into time-sensitive stuff. - Define what you mean by low-latency. I've worked on major systems (100s of millions of financial transactions per day with strict latency requirements) where there was a team dedicated to it, and frankly, Java wasn't nor never would be an option. (In fact, we worked with mainframe operating systems people can't even name anymore!) However, most people don't mean that when they say low-latency. - Finally, if what you really mean is low-latency measured in 100s of milliseconds, that isn't really hard and Java application servers do that in their sleep now. (I've build business transactional applications that do 100,000 transaction with 700,000 SQL calls per second on some standard software and some beefy hardware) Just work inside the best practices space of these products. It is very easy to say "Java doesn't perform" when your code is crap.
Being a big "C" booster these days, most of my hate is reserved for C++. It is a language with no home. Overly complicated, not as lightweight as C, and not as easy to use as Java or .NET. I could speak at length about its problems. But this post is about Java :)
I've done Java for many years, and also C and C++, so I feel I'm qualified to comment. When we're talking performance the answer really is, "it depends". It depends on how your program is written and where the bottlenecks are. Java is actually amazingly fast at certain operations. For example, memory allocations and deallocations. That is because it is mostly allocated up-front. It can actually beat C/C++ programs here because, let's face it, malloc, new, and friends are not really speed fiends. So if memory allocations are your bottleneck, Java's your thing. Also, let's not forget that a better algorithm written in a so-called "slow" language will beat a poorer algorithm written in a faster language. So you have to make sure you're comparing apples to apples.
If your program does a lot of disk or network I/O, the whole performance question is a wash and it comes down to hard drive or network card performance.
If your program is CPU bound, C/C++ is the best, however Java has made improvements here over the years and it's not as bad as everyone thinks.
Having said that, a lot of Java's features come at the expense of massive memory requirements. That in itself can slow down the machine and cause it to thrash, or swap a lot more than is strictly necessary. I believe this is where a lot of people have the impression that Java is "slow". For example, on windows the kernel has a tendency to swap out Java programs aggressively and take forever to swap them back in. So your Java UI is sitting there, unresponsive, for several seconds after an un-minimize. That's not really a problem with traditional "performance" per se. Just latency issues and memory hogs.
In conclusion, C is still the best :) However if your users have a hojillion jiggabits of teh ramz, then feel free to write everything in Java.
i would applaud the proverbial footshooing by a company whose business model is competing with others to rig a market.
Those people who have moved from Java to JavaScript by way of Ruby say that Java is slow, even slower than JavaScript. It must be true. They wouldn't be lying or misinformed, would they?
Nobody has ever said JavaScript or Ruby was faster than Java in the history of human language, until your incredibly stupid comment denigrating those that you believed had. Congratulations.
The argument has always been that Java is slow compared to languages such as C and C++. And back in the day, it was by a lot. Today, it technically still is, but not enough that it matters at all as this article is pointing out, and in some cases it's actually faster.
You can write very slow programs in C++. You can have awful performance from a Java program. At the end of the day, it depends on what you want to build, and what your constraints are: for some things, it may indeed be "easier" to write a low-latency system in Java, but how predictable do you need the performance to be? What kind of frameworks are you allowed to use in your "comparable" C++ program? They're very, very different beasts and make vastly different promises about performance and use of resources. In particular, C++ lets you control exactly what happens to resources in a deterministic way, and this can have many advantages. It's already been pointed out that the core of JVMs are typically written in C++, so what makes anyone think that C++ is /unsuitable/ for this? One of the interviewees thoughtfully mentioned teams "...of mixed ability": if you have programmers who aren't that good with C++, perhaps Java's the quicker route from A to B. But, a competent C++ developer will hopefully suggest that you measure the results.
Where's the actual data?
VHDL and/or Verilog on a Virtex chip, algorithms in C run SLOW compared to FPGAs.
If you prefer Java, you could take a look at Scala.
It doesn't matter how much you tweak the JIT or the GC, Java remains a lousy choice for numerical algorithms and statistical modeling. And the Java community in those areas is pretty weak too. Even if it weren't faster, it still is easier to write and debug those kinds of algorithms in C++, and there are tons more libraries available too.
http://javolution.org/
"Javolution real-time goals are simple: To make your application faster and more time predictable!
That being accomplished through:
* High performance and time-deterministic (real-time) classes such as fractal-based collections supporting extended views, closure-based iterations, map-reduce paradigm, parallel computations, etc. Performance of fractal structures (e.g. worst case execution time) is comparable to standard structures for small sizes, but significantly improved for larger size (e.g. FastTable random insertion/deletion in O(Log(n))).
* Most parallelizable classes (including collections) are either mutex-free or using extremely short locking time in order not to impact the worst case execution time of high priority threads (works well only if the VM supports priority inheritance).
* Context programming in order to achieve true separation of concerns (logging, performance, etc).
* Straightforward and low-level parallel computing capabilities with ConcurrentContext.
* Struct and Union base classes for direct interfacing with native applications (e.g. C/C++).
World's fastest and first hard real-time XML marshalling/unmarshalling facility.
* Simple yet flexible configuration management of your application.
* Javolution makes it easy to port any Java application to C++ for native compilation (maven based) or to write Java-Like code directly in C++ (see Javolution C++ Overview)."
Javolution is written and maintained by Jean-Marie Dautelle.
So far Javolution has worked fairly well on a big project with soft real-time needs (although used mainly for the struct and union classes, which is what I originally suggested using it for). Perhaps these sorts of classes should become part of the Java standard library somehow?
A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.
If I want to write a program quickly, I write it in Python even though I know the program will run quite slowly.
Which is what I do too knowing that if I need to speed up the code I can rewrite parts in C/C++ and compile them and then call them from Python. This, as far as I understand, is simply not possibly in Java. So if you code in Java there is no way to compile parts of it to get a needed speed boost.
In addition, while anecdotal, by experience with Java apps is that they are incredibly slow, rather unresponsive and crash often. No clue whether that is the programmers fault or Java's but it seems a common 'feature' of many java apps I've seen on the web. So I really am completely amazed that anyone would consider this for a low latency system given the speed and reliability issues that seem to abound with apps written in the language. The last time I coded a low latency system (in C++) we disabled timer interrupts to the Linux OS to prevent the process getting swapped out - somehow I cannot imagine there is a way to do this in Java!
I've seen trading platforms in Java (Island) and was surprised at the number if transactions per second. I don't see Java jobs in London that much but lots of C#. Maybe that's UI work. Bloomberg are very C++ orientated and they're known for their trading platform. Lots of Boost in there AFAIK.
Guess what? A skilled programmer can write code (in any language) that would not require GC (or delete) of a single object during the entire execution of a process. And that execution can be measured in months or even years.
And it is as simple as designing a class to be fully REUSABLE without having to delete it.
Here's something wild. I use Java JNA with Jack Audio (jackd) on Linux which allows me to have the C/C++ based Jack Audio to perform callbacks (including the one that feeds wav data into a Jack channel) using JNA.. I never expected that Java could handle it that fast but it's really nice.
So for performance sensitive portions one can use C/C++ and Java for the window dressing *IF* those portions don't "pop" fast enough...
Java can have relative low latency but can never match C or ASM. If you have a soft real time system that doesn't need pin point real time control then I would say Java is fine and a great choice, however if you need tight real time control and you are making a hard real time system then I would say Java and C++ don't work, C and ASM are still the best choices you have great embedded language. C and ASM can do everything that you need and more. I'm not saying Java doesn't have a place in the embedded world but I think it gets to highly valued.
10+ years on one of the big 2. I can tell you for a fact. Matching Engines run on C. java is used in customer gateways. pre-acquisition my previous exchange had java ME's. it was very unpredictable we had to run the servers under %20 load (200 or so ME's). After that we could see slow downs.
It takes a loooooong time.
I don't understand why people find Java faster than C++ to write code in. Any program large enough to require lengthy compiles is large enough that Java is unlikely to be a suitable candidate language, and even if you did write that triple-A game in Java it would take longer to code because of dealing with memory/performance issues.
Directly addressing memory/handling your own de-allocation of memory answers more problems than it creates unless I am writing trivial programs and have access to some magic libraries that I don't have access to in C++. All things being equal, I can code a better program faster in C++. Now, If I was a programmer who never learned/practiced coding with pointers then sure, my Java programming would be faster, but since I am comfortable with pointers/memory allocation schemes etc I find C++ faster. I am suspicious that people who find Java faster for coding large projects are just unfamiliar with C++ and managing your own memory, or are using libraries to do all the work and just don't know of an equivalent set of C++ libraries.
Wow, I can use "Real Time Java", but only if I totally rethink my code, and do lots of painful analysis, or I can just code it and C/C++ and have it "just work".
Java, write once, profile, write again, write again, and again, and again, and the finally do it right in C++.
Face it, real time apps do not have time for garbage collection and all that other nonsense. Use the correct tool for the job. Then again, when most code monkeys only know java, everything does look like a nail.
People are the most expensive cost to most businesses these days. So the marketing battle between languages focuses less on performance and more on how experienced and expensive your developers need to be. What I see being missed with this marketing is that by lowering the people quality and marginalizing your language and code quality, you are setting yourself up for maintenance, improvement, and performance costs down the road.
Also for catastrophic failures, when a relatively inexperienced programmer does something that someone more seasoned would know to avoid and it makes it through QA to deployment before being triggered.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
I am using this opportunity to promote a langauge of mine called Sappeur.
This language aims to combine the strengths of Java (memory/type safety) with all the useful C++ mechanisms such as
+ Synchronous Destructors
+ Deterministic Memory Management
+ Value Arrays
+ Almost All Objects can be allocated on the stack or the heap
+ Special type support for thread-shared data types
Here is a presentation and the manual.
Regarding the claims "Java is already good enough", this might be true for some special cases, where memory consumption (typically at least 3 times as much as the equivalent C++ program) does not matter and the problem itself is rather primitive. My own informal benchmarking with a CSV-parser/hashtable type of program suggests that.
But as soon as you manipulate lots of highly complex data sets, the strengths of C++ will make themselves be visible in performance, too.
It is not a coincidence Steve Jobs (peace be upon this great perfectionist asshole) insisted on the use of a C-style language (Objective C) for Apple products. Perfection requires soft-realtime capability which you cannot get from a GC language. And probably never will, as memory management must be tailored to the problem instead of using a "one size fits all" approach (automatic Garbage Collection).
Dipl.-Ing. Informationstechnik (BA) Frank Gerlach
Gäufelden
Germany
PS: Yeah, now that I grew a little older I do think a proper CS degree matters in the I.T. world. That's why I am listing mine here.
People doing something stupid doesn't make that thing not stupid.
Wrong.
There is no way an intelligent programmer, optimising her code, and using a static compiler to generate optimised machine code is going to be outperformed by an unoptimised program running in an interpreter that selectively recompiles parts of the program into pseudo-optimised machine code. Firstly all that runtime profiling and optimisation is itself a performance penalty, secondly the code generator of Sun JRE and Open JRE is worse than GCC or IntelCC, or clang, thirdly the C programmer has already made all the optimisations and more that the JRE could possibly make.
If your argument had any merit whatsoever, HPC folk would be programming in Java by now instead of C and Fortran with OpenMP. Games would be written in Java.
And I write engine code for games, I build profiling test harnesses which perform convex optimisation to select good kernels, this generates selection matrices which allow my engine to select which kernel to use based on input parameters, which is similar to how JRE's profiler works, except here I have the advantage that all the tests are run in the build process, so the profiling has already been done when it hits the users machine.
Also if you think statistical methods can outperform rational optimisation, expect to be disappointed. Compare the BLAS implementation ATLAS, which is the highest performing statistically optimised BLAS package to any of the hand-tuned BLAS implementation: AMKL, Intel MKL, GOTO-BLAS, they all outperform ATLAS by significant amounts.
Optimisation through understanding will always beat optimisation by statistics.
Can you backup those claims ? Optimizing Fortran Compilers still blow anything out of the water in scientific/engineering codes.
Really don't get the point of these articles. Trying to spin everyone into a orgy dispute.
At the end of the day, the only thing that will decrease latency is your programming skill.
Your ability to write efficient, logical code is more important than what language you use to do it.
People who use C++ will say C++ is better, those who use Java will say Java is better.
The only way to test this is to write a simple program in each language (using the same logic) and test it.
Instead of having these stupid "hearsay" Java articles, why not do some benchmarks?
Azul Zing and their Pauseless and C4 collector algorithms are leading the pack of pause-free JVM GC options at the moment..
http://paperhub.s3.amazonaws.com/d14661878f7811e5ee9c43de88414e86.pdf
http://www.azulsystems.com/
The execution of C/C++ is faster than Java almost always. The development time of Java is faster than C/C++ almost always.
HFT is now evolving. It's no longer about microseconds but it's more about smarter algorithms. Instead of making 1 penny on a hundred million trades per hour, it's about making $1.00 per million trades per hour. Coding an algorithm sitting next to the Math Ph.D. who came up with it is more important to get it out to market in hours rather than days. You only have a small time period until your algorithm is discovered and opposing HFT machines can re-code their systems to guard against it. Sure, Java will use tons more memory but buying 1TB of ECC RAM is pocket change for these HFT shops. The code will execute slightly slower, but these shops can now deploy their own custom algorithms, going from concept to code to production in a matter of hours. It's much harder to do that with C/C++ because the code is so verbose and it simply takes longer to write equivalent code. In addition, all of the good low level C/C++ devs are paid mid 6-digits or better ($400-600k). It's cheaper and easier to get an expert level Java guy from the internal IT dept for $150k and sit him between an algorithms guy and a trader on the desk than trying to lure a good C++ guy from another shop and dealing with the slimy recruiters and the fraud candidates. You also have the JVM benefits (memory management, type safety,etc.)
Lastly, everybody here is missing the point talking about Java performance. This isn't your stereotypical enterprise data center running a line-of-business app to process invoices. These guys lay out hundreds of millions of dollars just for their hardware/infrastructure budget. Most of these HFT shops have their own custom JVM implementations, made for pauseless GC in low-latency situations along with their own customized Linux kernels or hardware-assisted JVMs. The better shops have their own custom networking stack and protocols. The best of the best run on their own hardware that was designed with customized CPUs for their servers. The future is using these custom fabs to produce RISC-based chips with the customized JVM integrated onto a chip in the form of an ASIC. Throw in gigantic L1 and L2 CPU caches so the instruction code itself is always executed on the chip itself. It's not something commercially viable and has failed in the past, but for a very specific market (HFT for example) you can make Java code scream. Yes, with enough money you can make an ultra-optimized Java implementation run faster than stock C/C++. Source: my career in finance
To all the posters here who seem to have no real idea about Java http://martinfowler.com/articles/lmax.html I work in the City of London and although it is only a recent development many low latency systems are being written in Java, due to the faster time to market, the G1 GC and deterministic garbage collectors. You may be interested to know that the world's largest investment banks have most of their trading, risk and flow systems in Java so all these comments about Java being unstable, crap or slow just aren't true.
Dum spiro spero
I've written trading systems in Java because management insisted. Every experienced trading systems developer screamed NO.
I wouldn't recommend it.
It turned out that because a method is only JIT compiled after 10000 calls, we had to put 10000 orders through our system to "warm it up" every morning to get decent performance.
Kind-of-like a valve amplifier.
This is the kind of sh*t you have to resort to when you try to write trading apps in Java.
Avoid.