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.
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
Java can be compiled to native code.
C and C++ can be interpreted.
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.
> it is an run time interpreted language
It isn't, check it out.
Go Solaris : Erlang ;-)
btw, java/c# nowadays are almost as fast / faster than c++ programs.
http://stackoverflow.com/questions/145110/c-performance-vs-java-c
Languages are not interpreted or compiled. Implementations are compilers or interpreters. These days Java is typically compiled at runtime, instead of ahead of time. Your comment is bogus.
What a fool believes, he sees, no wise man has the power to reason away.
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.
Java is slow because it is Garbage-Collected, not because it runs in a Virtual Machine.
Memory usage is more important than the virtual machine for performance for anything more complex than calculating Fibonacci numbers, as it affects hard drive swapping and cache misses. That's what is making Java programs **feel** slow. The hard disk is the bottleneck, not the CPU.
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.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
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.
Wrong. This hasn't been true for more than 15 years 1996. It's a JIT-compiled language, which means it has a slow startup time, but once the VM is warm, it can actually outperform C on numerical code. Really.
He runs all java apps with the -Xint
Interpreter only mode is awesome.
Once Java byte code is loaded, it's compiled into something native by the JIT compiler. The start-up is slower than C++, but many of the low level functions are just as fast once they've started.
Besides, there are some things that C/C++ compilers can't optimize on that Java compilers can. See http://en.wikipedia.org/wiki/Comparison_of_Java_and_C%2B%2B#Performance
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" ?!
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++.
SJW n. One who posts facts.
Many JVM implementations can make use of SIMD at run time because they know what they're running on. Additionally, in many algorithms, the pointer indirection cost in C is higher than the bounds checking cost in Java (because pointers make life hard on optimizing compilers, and HotSpot doesn't have that disadvantage). Cache coherency also plays a big role. See the link in my reply to parent comment.
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.
Not runtime interpreted, but it is in a virtual machine.
Personally I have never figured out how people find Java usable. Back when I was programming Java I always found myself in situations where there were a gazillion ways to solve a problem and the documentation never hinted on the performance issues one could run into with different approaches.
Also, garbage collecting must be horrible in low latency applications. Instead of getting extra delays at a time that you have determined, usually directly after you are done with your task, you get the garbage collection work at random times that may or may not occur at appropriate times.
If you really want maximum performance you should manually free resources you don't need. If you need better control of when the freeing process happens you could pool the freed resources and flush them out at a time that you know is appropriate.
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.
> I think currently, the difference in performance between Java and C++ is so close that...
Additionally the problem is this blowhard is talking out of their ass (SWAG / opinion) instead of showing us cold, hard, facts.
Open Source + Open Data = let the results speak for themselves instead of some opinion that no one gives a fuck about.
Mod Article: -1 Troll
When it's compiled, e.g. by gcj, Java doesn't run in a virtual machine. It's compiled to native code.
The reason it's not done much is that this is actually slower for many tasks than the optimizing JIT is.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
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.
More important than the actual runtime environment is that fact that in any networked application that processes lots of data, _latency_ is the bottleneck, not the actual performance of a well implemented* algorithm. The latency between servers, between RAM and the CPU, and even between L3 and L1 (hell, even from L1 to the registers) will have a larger impact on the overall performance than the actual language used. Round trips to and from memory (either local or remote) are what kills performance for most code**. Good programmers know this and optimize for these latencies when implementing an algorithm, regardless of the language.
Even in a low latency environment, well implemented algorithms in scripting languages can outperform poorly written C/C++ and Java. In the financial world, those guys are laughing all the way to the bank (true story).
-Chris
*assume for the sake of discussion that both the Java and C++ implementations are done by good programmers who know how to optimize in their target language.
**remember, round trips occur every time you call a function/method and the stack has to be saved... it's not just data access that triggers this.
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).
FYI the author of that quote is the chief engineer of a C system on which enterprise, low latency trading systems are built. So when he says it, I would tend to give that more than the passing thought.
Those items quoted have indeed been recently shown to bring performance close to similarly developed C++ systems. Though you are right that the layer of indirection will always mean overhead, if you are working low level enough and real time is not your goal, that indirection is what allows your code to be run time optimized and compensate for the cost of the overhead.
And really, until code developed in either reaches the stage of being re-done as an Emacs major mode, how seriously can it be taken?
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
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.
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
Wrong exemple, Facebook has since replaced their C/C++ compiler (HipHop) with the use of a virtual machine and they have gained in performance in the process. http://www.javaworld.com/javaworld/jw-07-2013/130726-facebook-invents-php-virtual-machine.html
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.
Really.
Meh.
http://benchmarksgame.alioth.debian.org/u64/java.php
Or not. Benchmarks are a game and everyone likes to play, except the users of brainfuck for whom creating a program which completes is essentially winning.
The thing is people have been trumpeting "blah is as fast as C/C++/Fortran" since nearly the inception of C and C++ and probably shortly after the inception of FORTRAN.
I think there is a kernel of truth in that the reason C, C++ and FORTRAN/Fortran are always the targets is because they are almost always either the fastest or with a few percent of the fastest.
When people start comparing execution speeds of Haskell, Python, C#, C++, $NEWLANGUAGE etc consistently against Java then I'll believe that Java is indeed king of the hill.
SJW n. One who posts facts.
These are HFT folks, they have essentially unlimited money. Take a TB of RAM, use half for a tmpfs and you no longer worry about IO. A safer route and more expensive would be to just use PCIe SSDs.
Unlimited money solves a lot of problems.
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!
These are HFT folks, they have essentially unlimited money.
Unlimited money solves a lot of problems.
But not, apparently, the problem of an ongoing obsession with making even more money.
systemd is Roko's Basilisk.
Networking is far from low latency, it will always be the bottleneck, even if you use QBASIC.
mod parent troll, or just -1 ignorant.
Website Hosting
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.
This. I've actually personally witnessed a case where a java test application outperformed a (roughly) equivalent C++ application by a startling amount. The two applications were more of a benchmark program than a real app, since it was only testing the timing characteristics of allocating many thousands of objects on the heap, discarding some of them, allocating more, then discarding more, and so on.... The C++ version used the default new and delete operators, while the java version just used the normal new keyword and left the discarding of memory of old objects to the GC. The Java version outperformed the C++ version by more than a factor of 10. Altering the C++ version so that it used custom new and delete operators for the objects, pooling unused objects instead of always just returning them to the heap as the default delete operator did, the C++ version of the application sped up considerably, outperforming the Java version only slightly over a period of about one billion allocations. In consideration of this experience, I think that one is left with answering the question for themselves of whether spending the extra time to specifically optimize a C++ program is truly worth the marginally improved performance. Sometimes it might be... but sometimes it won't.
File under 'M' for 'Manic ranting'
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.
Note:
I'm not bashing java. It's an OK language (not my favourite, not my least favourite) and there are many others including much more fun ones for the VM. It does decent stuff and I often use Java programs (minecraft and ImageJ are particularly high on the list).
SJW n. One who posts facts.
Java is slow because it is Garbage-Collected, not because it runs in a Virtual Machine.
Allocating and deallocating memory takes time too.
With C/C++ you can choose to allocate a huge amount of memory and skip all the allocation and deallocation. With Java you can also allocate a huge amount of memory, don't do too many object create/dispose and don't garbage collect at all.
You need to realize this is HFT. You don't trade 24/7. Doesn't matter if you end up using 256GB of memory at the end of the day. You can start again the next day.
So why would Java be slower in this case?
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.
including C range bounds checking (to make it as safe as Java),
Those extra cycles to make the code safer will cost an HFT firm tens of thousands of dollars. C is a better choice for these people *because* it allows them to cut corners. I mean, who cares if a bug in your program crashes the exchange when the exchange will just let you reverse the trades?
Give me Classic Slashdot or give me death!
And you'll notice even on your linked counterexample there are 5/11 examples where Java is within the margin of error on CPU time. Take the time to go back and read the link I posted. "Java vs C" goes back and forth depending on the algorithm in question and the cache characteristics of the target platform.
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?
And you'll notice even on your linked counterexample there are 5/11 examples where Java is within the margin of error on CPU time.
Yeah and in the rest C++ is quite definitively faster. In other words as I claimed, C++ is either the fastest or within a small percentage, across the board. There are precious few examples where C or C++ is substantially outperformed by another language (and in almost all of those precious few examples, it's Fortran) and plenty of examples against just about any other languages where it is a clear winner.
Take the time to go back and read the link I posted. "Java vs C" goes back and forth depending on the algorithm in question and the cache characteristics of the target platform.
I did though the one I posted has much more recent results and no dead links. All the benchmarks are similar. In some cases C++ is slightly otuperformed by Java, in other cases C++ substantially outperforms Java.
Mostly it doesn't matter.
But when people routinely benchmark against Java rather than C++, then I'll accept Java as the faster language.
SJW n. One who posts facts.
VHDL and/or Verilog on a Virtex chip, algorithms in C run SLOW compared to FPGAs.
Oh god, not this again, this isn't the first time you've made this sort of comment about Java vs. C/C++ and had it pointed out to you how wrong you are.
Then you go on as usual and complain about how unfair it is that you can't get a software development job and claim it's about the unfairness of H1-B and how bad your country is and whatever other excuses you come up with. If you can't even get right what even a bottom of the pile H1-B hire would then what do you expect?
Please read the responses others have given you, they're examples of the few times Slashdot's comment system is great because they're full of people who know what they're on about explaining why you're wrong. Unless you're willing to learn from this sort of thing you're going to forever struggle to find that software engineering job and yes, H1-Bs are going to get them instead of you.
It's an interesting topic as to why Java performs so well now and well worth a read. If you really want to be a developer then you'll find it interesting educating yourself on this. If you don't then maybe software isn't really where your heart is at anyway?
If you prefer Java, you could take a look at Scala.
Yes, Java can be compiled. It can also be run interpretted. Either way, it runs in a Virtual Machine
Wrong. You should learn to look things up before you post. e.g. Google: Java native compile
Clueless moderators modding you informative on a topic they know nothing about.
In consideration of this experience, I think that one is left with answering the question for themselves of whether spending the extra time to specifically optimize a C++ program is truly worth the marginally improved performance.
Probably not in general if the performance gain is marginal, though you've missed one very large aspect of C++ that idiomatically, small temporary objects are allocated on the stack, not the heap, and that's completely free.
In other words, C++ has a worse heap allocator and the properties of C++ make it harder to write a fast one compared to Java, but by default C++ doesn't use it nearly as much as Java anyway.
If you use a library such as Eigen for small, fixed sized matrices and vectors, it's particularly noticable as for even really complex stuff, no heap allocations are preformed. Also, C++ can easily pack unboxed objectes into arrays which makes a substantial difference in locality and number of allocations.
SJW n. One who posts facts.
Well sort of. Conversely there are a bunch of optimisations that the JVM can do which are more-or-less impossible to do in c/c++. It is certainly the case that writing very performant Java is quite tricky and there are a bunch of things you need to understand (why warming up the JVM is a good idea, getting all your classes into permgen to avoid IO, how to avoid cache misses, how GC works on so on).
I'm aware that no-one commenting on /. reads the article, but did you even read the summary? The quote (actually from Todd Montgomery) quite clearly says that Java is a bit slower than c/c++. The point is that the difference is small enough the advantages Java has in terms of time to market out way the disadvantages.
Hate to say it, but I'm forced to conclude that you are an idiot.
round trips occur every time you call a function/method and the stack has to be saved..
Is this always true? Can't the compiler unroll that, or the CPU store the stack info somewhere fast?
I personally find it weird that many systems still push parameters onto the stack and then call the function. That's mixing code and data. Very unhygienic. Security problems and potentially poorer performance.
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.
You mention Java's heap allocator as "excellent" and "very fast"; one reason why is because, for most allocations, it's essentially equivalent to that stack pointer bump you touted as an advantage of C/C++.
One of the positive impacts of garbage collection is that it allows you to coalesce the deallocation phase, which means you don't pay it at all on function exit. Java can also be very aggressive about inlining function bodies (even non-private/"virtual" methods can be inlined in many cases), while you need to be more careful in C/C++ to ensure that the optimizer is allowed to do this, and for virtual methods, it's simply not possible because the optimizer can only do static analysis (at least, not without a much fancier C++ runtime than I've ever seen a compiler use).
Now, I program in all three languages, and I'm not saying Java is a superior language in every respect, particularly when it comes to performance (I would think garbage collection pauses would kill any low latency use, but there are workarounds for that), but it does have interesting performance advantages as well as performance disadvantages. It's not just a simple matter of "more safety" = "less performance" in every case.
Everyone is forgetting two of the most important aspects: training and cost. It takes a lot more time and money to train a C++ developer to outperform a Java developer. With equal training, I'd assume the Java developer will develop faster and produce more maintainable code. But I'm not a C++ master so I'm not 100% sure.
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.
Writes are asynchronous on most CPUs, so as long as you don't do too many of them and overload the bandwidth for writes it's not necessarily a big deal to write to your own stack. The stack tends to be in cache, so that helps. Sometimes compilers can do inter-procedural optimization to have functions use different sets of registers so that nothing needs to be written to the stack, but that is only going to work close to the leaves of the call graph and you can't depend on your compiler being able to figure such stuff out. Inlining is the most powerful compiler tool for eliminating function call overhead, but too much inlining has bad consequences as well. At the end of the day, calling functions requires storing some data and that date has to go somewhere. Since registers are limited and you can call many functions recursively, the data has to go somewhere and that somewhere is the stack. There is no way around that in the general case.
In C and C++ you can usually set things up so that allocation and deallocation almost never happens, so the cost for that in C and C++ can easily be about zero after a wam-up phase. This usually involves a higher memory use than you'd otherwise need, but not as much higher as what you need to get reasonable performance out of a GC. You can of course do the same thing in Java, but then you're no longer taking advantage of having a GC at which point you might as well be writing in C or C++ anyway.
In C and C++ you can also layout the memory in just the right way. The Java allocator is more likely to make the right guess about how to layout your memory than the native allocator is, that's true, but neither of those can beat an optimal manual layout.
It's true that generally native programs aren't compiled for a specific CPU. Nothing prevents you from doing that, though, so that's not a fault of native languages.
Your program was faster because you wrote it better, not because it was written in Java. Which is usually a sign of what this story is about: resources were limited either because of time constraints or because the companies involved didn't want to spend the large amount of money required to make a native app as fast as it can be. Java wins if you haven't got sufficient time and lots of money.
C also uses memory management. malloc/free are blocking operations that take CPU cycles on the calling thread! Allocation in the JVM is extremely cheap (a single memory write in the best case) at the cost of more overhead for freeing it. But GC runs in parallel on a different thread and does not block the application code. Look at the modern GC algorithms! They are really amazing and very well suited for multi-core machines.
Java transaction performance is bounded by transaction duration and memory use per transaction. Seriously, if your machine swaps get more RAM. We run all our servers without swap.
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!
Read the benchmarks at http://www.techempower.com/benchmarks/ and http://benchmarksgame.alioth.debian.org/
Well-written Java code running on the JVM long enough for the Hotspot Just-In-Time (JIT) to optimize it consistently runs within 2x of the speed of well-written C++ code. The JVM uses more memory, in some cases as much as 40 times more. But for speed, Java is awfully close to C++ and positively demolishes PHP.
If you don't believe it, find counter-benchmarks.
Cheap RAM means you can run bigger and faster C++ apps too you know, not just Java. C++/C will beat java in almost every test that counts because skilled C/C++ developers can write code that handles memory better than most GCs.
All those moments will be lost in time, like tears in rain.
There's a potential that your benchmark program had errors - the JVM Hotspot JIT optimizer can detect and eliminate dead code. e.g.
for (int i = 0; i
It looks like you're checking how fast Java can do some simple math operations, but the JVM might determine that the value of j never escapes the loop and optimize the complete loop out of existence. I read about this kind of frequent problem benchmarking Java in Java Performance by Charlie Hunt.
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.
I'll give a concrete example.
Many years ago I had to write code to pull documents across an HTTP link using XML. The docs could be up to 10MB is size, though most were much smaller. I could grab several at a time each polling of the upstream server - up to 20.
Now, in C# or Java you might create a document class that could store the docs, and dispose of it after finishing. This could lead to heap exhaustion / GC / management as large amounts of memory were allocated and deallocated.
In C++ I simply made a buffer as large as the biggest document I wanted to deal with, and kept it in RAM the whole time. The buffer was overwritten many times a second as needed. Since it was always the same memory, there was no heap juggling required. The program ran so fast and smoothly that some financials accused us of cheating since we moved the data far faster then they did.
Sure, you could have written it in Java, but the GC would have taken a thrashing.
All those moments will be lost in time, like tears in rain.
. Since registers are limited and you can call many functions recursively, the data has to go somewhere and that somewhere is the stack. There is no way around that in the general case.
No way? Why not two stacks? One for addresses and one for data. That way even if there is an error you don't end up returning to an "attacker" supplied address (via data). The program might still crash, but it is less likely to "execute arbitrary machine code of the attackers choice" which seems to happen too often.
And also arguably if you keep the data and address stacks separate so that the address stack only ever contains addresses it might be easier to do optimization tricks.
I program in many languages, and I'm not saying Java is inferior.
one reason why is because, for most allocations, it's essentially equivalent to that stack pointer bump you touted as an advantage of C/C++.
Many, not most. For short lived objects, it bumps the pointer for each allocation and every so often scans the new object pool and decides to move them to a larger pool (generational collection).
In C++ the compiler knows the size of the stack frame, so when the function is entered, there is already exactly as much space as needed. The C++ one is still cheaper because it is completely free.
One of the positive impacts of garbage collection is that it allows you to coalesce the deallocation phase, which means you don't pay it at all on function exit.
With the standard allocator, you pay for large objects only on function allocator. For small ones, they dimply disappear as the stack pointer is ajusted to point back to the callee.
Java can also be very aggressive about inlining function bodies (even non-private/"virtual" methods can be inlined in many cases), while you need to be more careful in C/C++ to ensure that the optimizer is allowed to do this,
I disagree: in C++, all methods are non virtual by default, so almost everything is a candidate for inlining. The C++ compiler inlines a lot and actually with its heavy use of functors/lambdas, modern idiomatic C++ code relies on that.
and for virtual methods, it's simply not possible because the optimizer can only do static analysis (at least, not without a much fancier C++ runtime than I've ever seen a compiler use).
GCC does a fair bit of static devirtualisation. I suspect it is not as good as the JVM though, because the JVM can recompile long functions statically.
There are techniques to mitigate this in C++, for example writing loops with function calls using the curiously recurring template pattern, and putting that lot in a virtual function. The end result is much the same as what the JVM does: you get one compiled devirtualised function for each class.
The java solution is much easier to use (all done for you) where as the C++ one is guaranteed to work in all edge cases since you manually specify the devirtualisation.
That said, I personally use very few virtual functions in my C++ code.
SJW n. One who posts facts.
dammit, the code got eaten because of the less than / greater than. Let me try again:
for (int i = 0; i < Integer.MAX_INT; i++) { int j = i; j--; j-= j/3; }
I tend to agree in general. However, for the employers in question, the cost difference between top-notch Java vs. C++ developers is a pittance compared to the potential earnings from the algorithms. Also, they can afford to buy fully trained developers (more to the point, they can't afford not to), so the inequity in training time to get to excellent competency isn't a problem for them. This is somewhat tangential to the point of TFA, though.
- T
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...
http://benchmarksgame.alioth.debian.org/u64q/java.php
If you switch from single-core to multi-core, Java's worst performance against C++ goes from 4x the C++ speed to 2x, and in some cases it's equal. That's still behind, I don't dispute that. But it's damn close. If C, C++, and Fortran are the consistent three kings of performance, then Java (when running warmed up) is probably second and in a similar category to Go and Ocaml - close enough behind the kings that many high performance applications might benefit from the enhanced developer productivity more than the extra speedup.
Other people - not you - have tried to group Java performance in line with PHP, Perl, Python, Ruby, etc... that's clearly inaccurate.
... or you could have written it in Java the exact same way and kept recycling a large buffer over and over without any garbage collection whatsoever..
Agreed.
I run my primary server (which includes my mail and DNS and static http servers, as well as a largeish Java app) on a swapless system. So swapping is never an issue.
And indeed not being forced to free synchronously as the stack unwinds can make Java faster than C++ for example, I second that.
And this "Java is slow because (insert assumption)" stuff is really really old. I can write good or bad code in Java, C, C++, C#, even asm, and I do write regularly in all of those, including real-time code, with cycles being counted where necessary, on hosts with CPU speeds and memory sizes ranging over several orders of magnitude.
Rgds
Damon
http://m.earth.org.uk/
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.
In addition to what the other AC wrote, some C++ compilers, including GCC, support built-in PGO.
Also, while the other AC mentioned that compilers typically support targeting a particular CPU, that is usually at the rather coarse level of CPU model/family. However, if you know the specific CPU characteristics of the target systems, you may be able to organize the data structures to improve the usage of on-die memory. This can often be implemented so that adjusting for a different specific CPU architecture is almost as simple as a recompilation.
- T
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.
You can do exactly the same in Java with ByteBuffers and direct memory if you really want to, for example, and never GC.
On the other hand, for the non-critical 99% of the code you can write it simply and safely and quickly and let GC clean up occasionally if need be.
Rgds
Damon
http://m.earth.org.uk/
Now, in C# or Java you might create a document class that could store the docs, and dispose of it after finishing.
You could do that in C++, too. You can also destructively modify objects in place in java. Maybe you should come up with a concrete example that actually compares like algorithms.
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.
Good points. It annoys me when people claim that Java is faster than C++ because they tested one of the few things where Java really shines performance wise. Basically they're writing a Java program, with its endless allocation/deallocation, in C++, and saying look, Java programs run faster on Java than they do on C++!
Hint folks: you write C++ programs differently. Even in Java constant massive allocation/deallocation is bad form, especially when speed is important. RTFA: one of the tricks they use to speed up Java is to avoid creating a lot of garbage to be collected. Allocation/deallocation is free in any language if you don't do any of it.
Well, I must say it's still somewhat remarkable how Fortran compilers generally manage to beat C/C++ compilers their collective behinds when it comes to processing large quantities of data. Then again, Fortran tends to be aimed at big data and high performance computing these days.
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.
As of Java 7, Java also can allocate objects on the stack automatically with escape analysis.. So in theory C++ and Java are the same in this respect. (It also removes unnecessary synchronized calls in these cases for these objects)
As for other objects Java uses copy collectors for short lived objects that makes cleaning them up essentially free as well. In fact, it is much less expensive than C++ delete calls. C++ still has to run any destructors that are there. In Java finalizers are rare. So short lived objects are much cheaper in Java both on the stack and on the heap in terms of execution overhead related to memory allocation/deallocation.
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.
Newer JVMs also allocate objects which won't escape context to the stack.
Help I am stuck in a signature factory!
Java only does array range checking when it needs to, at the beginning/end of a loop or at any point where the array ends.
See: https://wikis.oracle.com/display/HotSpotInternals/RangeCheckElimination
Help I am stuck in a signature factory!
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.
In a proper language like C, C++ or Sappeur, you can have value arrays and you can access your cache in the most efficient manner one can think of.
Java is still a clunker when it comes to efficient memory allocation and layout.
For an apples-to-apples comparison, C++ may well be fastest. But those situations don't show up very often.
The real question is, "Given the ability level of developer I'm willing to pay for, what I want done, and the amount of time I can give the developer to do it, which language is the developer more likely to deliver an acceptable solution in?". This can depend on what people in the shop already know, it can depend on the performance requirements, etc.
Fast ENOUGH is what matters. There are very few things in the business world that Java isn't fast enough for, and fewer where it can't deliver if low latency pieces are written in C.
This constant blending of "C/C++" really bugs me. There is a world of difference in the performance of a non-class based language like C and one which requires hidden instance parameters and dynamic type checking like C++ does. While you can use a C++ compiler to write C code (all methods and variables declared static), the two languages really do not compare for performance nor for ease of use.
The big problem with C and C++ vs. Java is that it requires a lot of experience to write effective memory management with C and C++, and without effective memory management you end up leaking memory or thrashing the system allocator functions. Comparing these languages is like comparing a VW bug to a modern semi-tractor unit. They're just not equivalent in form, function, or intended market.
In the end you have to use the tools that are best suited to the requirements of the task at hand, and in the case of C and C++ code, that includes being aware of the operating system and it's memory management approach, which Java hides from your code.
I've seen no shortage of C and C++ code over the years whose performance sucked because some idiot directly used malloc/free for allocating small objects instead of writing proper allocators that would cache instance memory and reuse it. Conversely, I've seen Java code that tried to implement instance pools in order to override the garbage collector whose performance sucked as a result of the overhead.
The bottom line is an unskilled or inexperienced programmer with can shoehorn crappy performance concepts from other languages into the code at hand. Blame the coder, not the language.
I do not fail; I succeed at finding out what does not work.
Except that you could have used the exact same technique in java, recycling the same object.
Processor stacks are a near perfect candidate for caching. It's likely to exist in L1 cache for the bulk of run time, with close to no cache refills ever happening (typically you write before reading stack values). x86 CPUs are claimed to be optimised for L1 cache stack operands to be as fast as registers, essentially the stack then becomes a large set of extra registers, albeit funnelled through physical ones.
In architectures with large register files a lot of code may never actually touch RAM at all, with only the link pointers pushed to stack for many calls and living in a dedicated stack in some cases.
Stack frames only look like an ugly hack, they have great performance characteristics once you have good enough caching.
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.
Automatic memory management is better then manual memory management?
Lost his marbles?
I meant something different - Java programs use more memory as a whole - this causes more cache misses, and also more hard drive swapping. The GC algorithms don't matter - they affect CPU usage, not memory usage. The problem is that a Java program uses several times more memory than a comparable C or a C++ program. As I said, the problem is cache misses and hard drive swapping.
And I'm talking about my own experience running Java programs on my not very powerful laptop computer with 3 GB of RAM (no SSD) - I don't use a server at home, the only Java programs I care about are desktop applications, and I've been disappointed there. May be that's why I only hear about Java programs but never see them - because it's only used for server-side programming. I don't use servers.
Can you backup those claims ? Optimizing Fortran Compilers still blow anything out of the water in scientific/engineering codes.
Stack allocated objects are completely free.
Point of order: stack objects are not free, they're just very cheap. However, you still need to initialize (or were you going to use something without setting it to a known state?) and you need to bear in mind that stacks are generally considerably smaller than the heap. Yes, you can do things like resizing a stack or relocating it to another area of memory when you run out, but those are operations for the extremely brave. And they're expensive too. If I suspect that I even might need them, I just use the heap from the get go as that prevents my hair-loss (and I'll layer a few thread-bound pooled allocators in, which deal with most of the cost of heap usage when stack-based allocation was originally even a candidate in the first place).
"Little does he know, but there is no 'I' in 'Idiot'!"
I know about escape analysis.
It won't make java as fast as C++ for the same reason that alias analysis fails to make C++ as fast as FORTRAN and for exactly the same reason.
In both languages (Java and C++) if you create a local variable, you may well then pass it by reference to some other function. If that function is sufficiently complex, or through a virtual function call, the compiler can't tell if the reference is stored somewhere after that function returns.
In C++ it's up to the programmer not to do that: you're providing a personal guarantee to the compiler that you're not going to do that and woe betide you if you do. In Java, the extra safety means the programmer isn't allowed to offer a personal guarantee with bad consequenced is it's wrong.
It's much the same as restrict in C99: you promise the compiler that no aliasing is happening and it's allowed to give you bad results if it does alias.
Not being a fan of undefined behavior, Java never does that and so optimizations are harder.
Interestingly, though GCC does also do some sort of escape analysis on memory allocations with malloc()/free() (though not new, delete) and can in fact avoid some malloc/free pairs that don't end up doing anything.
C++ still has to run any destructors that are there. In Java finalizers are rare. So short lived objects are much cheaper in Java both on the stack and on the heap in terms of execution overhead related to memory allocation/deallocation.
In C++ can have lighter objects than Java. C++ has the concept of POD (Plain Old Data) which has even expanded in C++11. PODs (and in fact many classes which don't manage resources) have trivial destructors: those that have no code and do not need to be run.
If you make a lot of temporaries of that sort then there are no destructors to be run, and deallocation is completely free because it is included at no cost in the stack pointer bump when the function returns.
An excellent example is the Eigen library. If you work in things like 3D geometry, you end up working with many small, statically sized vectors and matrices, generally 2D, 3D and 4D. These are all basically PODs (certainly under the new rules) and as a result, despite being complex objects with interesting semantics, they are still free to allocate and deallocate on the heap.
I have actually analysed the asm code. Interestingly, GCC can reason about the memory allocation more easily since it's on the stack and therefore it can guarantee that two arrays do not alias. As a result it can perform the most amazing amount of optimization.
TL;DR escape analysis is great (and is equivalent to alias analysis for pointers in C and C++) and therefore I love it. It will yield performance improvements, but will never catch as many cases as stack allocation.
SJW n. One who posts facts.
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?
What do YOU know about programming? Java and PHP, in the normal use-cases, are BOTH compiled languages, though certain stages of compilation are performed on-demand. The comparison is meaningless anyway: PHP-hating aside, of course a dynamically-typed language (PHP) is outperformed by mature statically-typed languages (C/C++). And all of this tells us EXACTLY NOTHING about how the performance of another statically-typed language (Java) might rank.
Can you please stop with the meta comments ? Thank you. Fab.
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/
There are a few problems with PGO in respect to JIT. Like the wiki article says: "the sample of data fed to the program during the profiling stage must be statistically representative of the typical usage scenarios; otherwise, profile-guided feedback has the potential to harm the overall performance of the final build instead of improving it." PGO is also less able to make dangerous optimizations compared to a JIT compiler. One good example of said optimization is the removal of null checks by java's jit: http://aria.cs.vt.edu/refs/docs/kawahito-asplos00.pdf. The jit can try the optimization at runtime, and if it encounters an error condition due to the removal it can roll back the optimization. This all happens with your program seemingly running as it normally would. Trying to apply said optimization with PGO would introduce bugs into your code.
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
Yes, but Java programmers would never have this idea, unless they were former C or C++ programmers. They think in terms of objects, not in terms of byte buffers.
I've heard that often Java programs run slow, because there are allocations inside loops, when the same variable can be reused instead. That's because Java programmers are taught not to think about performance.
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
The big difference, however. is that the JVM can do escape analysis at runtime... and can possibly realize that further optimize is possible.
File under 'M' for 'Manic ranting'
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.