×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Using Java In Low Latency Environments

Soulskill posted about 9 months ago | from the shaving-milliseconds dept.

Java 371

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.'"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

371 comments

Thanks Dice!! (2, Insightful)

Anonymous Coward | about 9 months ago | (#44455981)

This Slashvertisement brought to you by: Dice.com

Poll's knackered (0)

Anonymous Coward | about 9 months ago | (#44456257)

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 and Latency (3, Funny)

Anonymous Coward | about 9 months ago | (#44456017)

I find java helps me with my latency :)

Re:Java and Latency (0)

Anonymous Coward | about 9 months ago | (#44456117)

Have you tried JA or LA? Both are anonymous and can really help. Of course then meetings are very large and you'll have to wait your turn to "share" but you're already used to that.

Re: Java and Latency (0)

Anonymous Coward | about 9 months ago | (#44456361)

HFT, yeah use it and lose it..

Huh? (1, Insightful)

TWX (665546) | about 9 months ago | (#44456021)

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...

Re:Huh? (4, Informative)

bunratty (545641) | about 9 months ago | (#44456071)

Programs written in some languages run more quickly than those written in other languages. Some languages allow you to write programs more quickly than other languages. Therefore, the choice of language is always a tradeoff. There is no perfect programming language, and no, not all programming languages are alike as you seem to believe. If I want to write a program quickly, I write it in Python even though I know the program will run quite slowly.

Re:Huh? (0)

Anonymous Coward | about 9 months ago | (#44456223)

Indeed, in grad school I came face=to-face with this. I had to write a shot-gun gen sequencing algorithm*, and I had been doing work in Python primarily for a while. I wrote up a quick solution, hit run... several minutes later, I stopped it, added some comments so I could track the progress, hit run.... several minutes later it became obvious that I would need something faster. Ported the code over to C++, I think it finished in about 90s.**

* given a set of dna strands sequenced from random parts of the chromosome, with errors, rebuild the original sequence.
** for the version that assumed we only sequenced one strand of the chromosome (an impossibility), the algorithm modification I made to get rid of that assumption filled my 4Gb of memory and core dumped.

Re:Huh? (1)

Anonymous Coward | about 9 months ago | (#44456521)

Run it or compile it to native C code with PyPy! http://pypy.org/

Re:Huh? (1)

medv4380 (1604309) | about 9 months ago | (#44456177)

Their referring to the lag you get in launching a Java App. There are ways around those issues, but not ways that are native to the language or the platform. Up until the hotspots are found and compiled a Java App is pretty slow. I'm not sure if this should be an issue with HFT though. The Algorithm should be persistent in memory for the trading day. The host spots should be found and compiled within a few minutes. Unless they are repeatedly launching it there shouldn't be a problem.

Re:Huh? (0)

Anonymous Coward | about 9 months ago | (#44456405)

They are talking about two kinds of latency, but not about startup latency: First, There are more Java developers, so shorter time-to-market. Second, the Java runtime isn't realtime capable, i.e. it does not guarantee an upper bound to latency. Many times the cause is the garbage collector, which needs to run occasionally to free memory that is no longer occupied by active objects. Depending on the implementation of the GC, this can halt execution for a short time, and this causes a latency spike from the point of view of the application.

Re:Huh? (1)

MatthewNewberg (519685) | about 9 months ago | (#44456239)

"It's not like compiling is the time-consuming part anymore" needs a sarcasm tag attached to it. Some people still deal with large compile times.

Re:Huh? (4, Informative)

LostMyBeaver (1226054) | about 9 months ago | (#44456379)

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

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

Also, to make things politically incorrect on Slashdot, good tools like Visual C++ 2012 can even take poor code and make it compile quickly if the projects files are designed well. Do your coding there and compile it later on GCC.

Re:Huh? (4, Interesting)

elfprince13 (1521333) | about 9 months ago | (#44456295)

Manual memory management is a whole class of bugs that Java doesn't have to deal with. A good C/C++ programmer shouldn't have *that* much difficulty, but it does add to debugging costs and detracts from mental focus on the algorithmic aspects of the problem.

Re:Huh? (5, Insightful)

Xest (935314) | about 9 months ago | (#44456329)

"Wouldn't a C++ programmer generate an applicable program effectively as quickly as a Java programmer?"

No, some languages simply are slower to develop with and debug. The problem is also made worse depending on the frameworks and IDEs available. As an example, you're going to get your work done way quicker writing an application manipulating dates and times using C# and Visual Studio than you are Java and Eclipse because until Java 8 Java's date time functionality is shit and Eclipse is a dog slow IDE. With Java 8 and say NetBeans or JDeveloper though things will be pretty similar.

At the end of the day with C/C++ you have to deal with memory management and that's just one additional piece of work that you don't have to be so concerned with with Java. C/C++ give you more scope for optimisation and more control over memory management as a benefit of that though. It's about trade-offs and figuring out what matters.

But it's possible to be great at both C++ and Java without having to descend into petty arguments as to which is better and know when to use each in response to a specific task, and that's the sort of great programmer these institutions will be looking for and this is really what they're talking about - both have their place but in some cases getting a trading application to market a day earlier than the competition even at slight latency trade-off may be enough to net your company a few million dollars advantage. In other cases, the latency improvements of a highly optimised C++ application may instead be the key to scooping up those extra millions.

Re:Huh? (-1)

Anonymous Coward | about 9 months ago | (#44456377)

Nice try, Microsoft Shill.

Re:Huh? (1, Insightful)

Xest (935314) | about 9 months ago | (#44456525)

Yes, I'm a Microsoft shill, that's why I praised an Open Source IDE (NetBeans), a competitors proprietary IDE (JDeveloper) as well as the Java language and in another thread only about half an hour ago said good things about Sony, and Nintendo. Two days ago I was apparently a Samsung shill too.

Has it really come to this? If you dare praise any company or one of it's products for absolutely anything then you're a shill?

The worst part is because I'm not a fanboy and I praise any company that does something good and criticise any that doesn't I must be a shill for every tech company on earth because even those I least like such as Apple I've praised sometimes (i.e. for shaking up the smartphone market and forcing innovation) and Facebook though I have a mostly negative view of it produced a nice clean site relative to the social networks that came before it (MySpace) crushing them as a result.

If only I really was collecting all those paycheques from the entire who's who list of wealthy silicon valley firms...

Re:Huh? (1)

gl4ss (559668) | about 9 months ago | (#44456335)

for this kind of scenario I would say to write and tweak it in java.. once it's been stable in what it actually does, then rewrite it in java, then do it in c++ or c.

though I suspect part of the problem with doing these battle algos is the need to evolve them constantly.

Re:Huh? (-1)

binarylarry (1338699) | about 9 months ago | (#44456337)

No, C++ is much, much more error prone and slow to develop with than Java.

Java has much nicer debugging capabilities, you typically don't have to deal with hard crashes, preprocessor mistakes, architecture problems, etc.

That said, you ultimately get more control over the software with C++, there's no blackbox JIT runtime optimizing your code.

Re:Huh? (0)

Anonymous Coward | about 9 months ago | (#44456345)

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...

Well it depends. If you're talking about an algorithm that needs to be thought up in the shower in the morning and in deployment by mid-day, than a lot of the "idiotproofing" and "syntactic sugar" that are commonly derided as unnecessary become a bigger deal.

C++ in particular has a lot of "gotchas" that could cost you precious hours to work around. Java probably would not have been my first choice, but I'm not an HFT programmer so I don't know what the hard parts of that problem set are.

Re:Huh? (0)

Anonymous Coward | about 9 months ago | (#44456383)

Try saying that for Malbolge [99-bottles-of-beer.net]. ;)

I'm a Haskell programmer, and to me, using C/C++ is like using Malbolge. It...just...hurts...so...much...

memory monster (0, Interesting)

Anonymous Coward | about 9 months ago | (#44456041)

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.

Re:memory monster (2)

bunratty (545641) | about 9 months ago | (#44456095)

It's a good thing that these days computers have plenty of memory. It's not quite yet true on smaller devices such as smartphones, but it will be soon. With each year, memory use is becoming less of a problem and how to take advantage of parallel processing is becoming more of a problem.

Re:memory monster (4, Insightful)

Minwee (522556) | about 9 months ago | (#44456169)

Traders are typically working with monster servers outfitted with over a hundred gigabytes of RAM, not tiny desktop workstations that need to swap just to move the mouse. I won't say that memory usage is no object, but there is almost no reason not to throw extra memory at a process if it wants it.

Your trading engine runs in Java and leaks four gigabytes an hour? No problem. Just give it 64G of stack and do half an hour of garbage collection after the market closes. Is that not enough? Okay, give it more. Don't have that much available? Get more. Can't afford it? Now you're just pulling my leg. Buying extra memory is cheaper than debugging a live system where any slip-up could cost you thousands of dollars in missed trades or penalties.

It's a weird world, but somehow it works that way.

Troll much, slashdot? (-1, Troll)

girlintraining (1395911) | about 9 months ago | (#44456047)

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.

Re:Troll much, slashdot? (3, Informative)

Anonymous Coward | about 9 months ago | (#44456125)

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

Re:Troll much, slashdot? (1)

smitty_one_each (243267) | about 9 months ago | (#44456353)

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?

Re:Troll much, slashdot? (4, Informative)

tonywestonuk (261622) | about 9 months ago | (#44456127)

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

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

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

Re:Troll much, slashdot? (3, Insightful)

satuon (1822492) | about 9 months ago | (#44456211)

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.

Re:Troll much, slashdot? (5, Informative)

Anonymous Coward | about 9 months ago | (#44456369)

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

Re:Troll much, slashdot? (2)

h4rr4r (612664) | about 9 months ago | (#44456401)

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.

Re:Troll much, slashdot? (3, Funny)

wonkey_monkey (2592601) | about 9 months ago | (#44456465)

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.

Re:Troll much, slashdot? (1, Informative)

TemporalBeing (803363) | about 9 months ago | (#44456213)

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.

Re:Troll much, slashdot? (1)

Trepidity (597) | about 9 months ago | (#44456281)

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.

Re:Troll much, slashdot? (5, Informative)

serviscope_minor (664417) | about 9 months ago | (#44456259)

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++.

Re:Troll much, slashdot? (2)

elfprince13 (1521333) | about 9 months ago | (#44456261)

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.

Re:Troll much, slashdot? (0)

Anonymous Coward | about 9 months ago | (#44456139)

> it is an run time interpreted language

It isn't, check it out.

Re:Troll much, slashdot? (0)

Anonymous Coward | about 9 months ago | (#44456161)

btw, java/c# nowadays are almost as fast / faster than c++ programs.

http://stackoverflow.com/questions/145110/c-performance-vs-java-c

Re:Troll much, slashdot? (1)

bunratty (545641) | about 9 months ago | (#44456171)

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.

Re:Troll much, slashdot? (1)

rockmuelle (575982) | about 9 months ago | (#44456319)

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.

Re:Troll much, slashdot? (1, Informative)

Anonymous Coward | about 9 months ago | (#44456225)

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

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

Re:Troll much, slashdot? (2)

elfprince13 (1521333) | about 9 months ago | (#44456229)

because it is an run time interpreted language

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 [scribblethink.org].

Re:Troll much, slashdot? (3, Insightful)

serviscope_minor (664417) | about 9 months ago | (#44456399)

Really.

Meh.

http://benchmarksgame.alioth.debian.org/u64/java.php [debian.org]

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.

Re:Troll much, slashdot? (0)

Anonymous Coward | about 9 months ago | (#44456243)

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

U just read about programming instead of doing it? (1)

Jerry Atrick (2461566) | about 9 months ago | (#44456247)

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.

Re:Troll much, slashdot? (0)

Anonymous Coward | about 9 months ago | (#44456273)

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.

Re:Troll much, slashdot? (1, Insightful)

UnknownSoldier (67820) | about 9 months ago | (#44456279)

> 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

Re: Troll much, slashdot? (2)

immakiku (777365) | about 9 months ago | (#44456349)

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.

Re:Troll much, slashdot? (-1)

Anonymous Coward | about 9 months ago | (#44456363)

Nice troll... moron. Maybe you don't know as much about programming as you think you do, tranny. Although this appears to be the same for just about all of your opinionated, noisy posts.

Who the fuck modded YOU up? (0)

Anonymous Coward | about 9 months ago | (#44456403)

Good Lord what a load of uninformed CRAP

No! It can't be! Java is slow, I tell you! Slow! (0)

Anonymous Coward | about 9 months ago | (#44456057)

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?

Erm... (0)

Anonymous Coward | about 9 months ago | (#44456069)

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.

The advantage of Java -tm (0)

Anonymous Coward | about 9 months ago | (#44456103)

... is that you get to rewrite your applications in 2 years? Or less?

Re:The advantage of Java -tm (1)

RabidReindeer (2625839) | about 9 months ago | (#44456373)

... is that you get to rewrite your applications in 2 years? Or less?

You're thinking of Microsoft.

Java is the only programming language I have run across in common usage that incorporates a deprecation mechanism.

When code becomes obsolete, you can tag it as deprecated. It will produce warnings when compiled, IDEs and javadocs will highlight it as deprecated, but it continues to be usable. That means that you can delete the code at your leisure instead of being forced to confront - and fix/bypass broken code when you're doing a completely unrelated emergency repair the way that I had to do far too many times using Microsoft C.

Sun has been extremely conservative about pulling deprecated functions. The Date(month, day, year) constructor has been deprecated for more than a decade, having been pulled because of its inflexibility in regard to timezones and other locale sensitivities. But applications that were coded to use it continue to compile and run to this very day.

Microsoft, on the other hand, yanked an entire SOAP library out from under me while I was still Beta-testing once.

Re:The advantage of Java -tm (0)

Anonymous Coward | about 9 months ago | (#44456477)

M$ may be the "Godwin example" of developer friendly practices, not a great comparison for teasing value out of the juxtaposition.

Yes (0, Troll)

AdmV0rl0n (98366) | about 9 months ago | (#44456107)

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.

Re:Yes (3, Informative)

bunratty (545641) | about 9 months ago | (#44456143)

Java is far, far safer than C++. C++ does not enforce type safety at all. For example, in Java you cannot possibly have a buffer overrun or access freed memory as you can in C++. I think most of the security notices are about C and C++ programs, not Java programs. I think you're referring to the Java runtime, which is written in, you guessed it, C.

Re:Yes (0)

TemporalBeing (803363) | about 9 months ago | (#44456183)

Java is far, far safer than C++. C++ does not enforce type safety at all. For example, in Java you cannot possibly have a buffer overrun or access freed memory as you can in C++. I think most of the security notices are about C and C++ programs, not Java programs. I think you're referring to the Java runtime, which is written in, you guessed it, C.

Yet it is Java that has had its run-time environments pulled for security concerns.

Re:Yes (1)

Anonymous Coward | about 9 months ago | (#44456275)

Well, let's think about the equivalent of pulling the Java run-time environment for C/C++. That's right, you'd have to pull your operating system. Do you see how that's not even close to a reasonable comparison?

Not only that, but you're not even talking about related types of safety. The Java runtime keeps getting in trouble for poorly handling malicious third party code. If you are writing a java program yourself, it is immensely safer for the reasons GP listed, and you probably aren't in the business of attacking yourself with malware.

Re:Yes (1)

RabidReindeer (2625839) | about 9 months ago | (#44456451)

Java is far, far safer than C++. C++ does not enforce type safety at all. For example, in Java you cannot possibly have a buffer overrun or access freed memory as you can in C++. I think most of the security notices are about C and C++ programs, not Java programs. I think you're referring to the Java runtime, which is written in, you guessed it, C.

Yet it is Java that has had its run-time environments pulled for security concerns.

In perspective, the RTEs have been pulled because they had flaws that enabled exploit code to be run. In C, the RTE lets ANY code be run, including exploits, so what's really happening is that Java is falling back to something closer to C levels of runtime security.

The reason for the concern about Java exploitability is that while most sane people have long since given up on download-and-run C code (ActiveX), Java applets (while comparatively rare) have not had exploit concerns until fairly recently. Because until recently, Java's sandbox was considered trustworthy. C/C++ doesn't have a sandbox.

Re:Yes (0)

Anonymous Coward | about 9 months ago | (#44456309)

The security problems of Java have absolutely NOTHING to do with the language itself and EVERYTHING to do with the fact that at some point in history some people thought it would be a useful feature to allow programs distributed over the internet to run automatically on people's computers, leaving all security on the flimsy trust that this "perfectly clean, secure and defect-free sandbox" would be possible to write in reality.

Would you claim C++ as an "insecure" language if I asked you to set up a web browser that ran some kind of minimal virtualized environment where embedded conventional, compiled c program binaries could be run in? Or when this virtual enviroment leaked because no one was smart enough to not leave bugs in there that let the security be breached?

The new resume buzzword (0)

Anonymous Coward | about 9 months ago | (#44456121)

old: HFT
new: MFT

LOL! (0)

Anonymous Coward | about 9 months ago | (#44456159)

Go Solaris : Erlang ;-)

Java's strengths are "not easy to ignore" (5, Funny)

carou (88501) | about 9 months ago | (#44456185)

Challenge Accepted!

Re:Java's strengths are "not easy to ignore" (1)

iggymanz (596061) | about 9 months ago | (#44456473)

Java benchmarks always avoid the thing that makes java slower, mandatory use of heap and all the indirection for reference-semantics for user types. In other words, as soon as you start using many objects, java's performance goes into the crapper, especially using the standard EE libraries of the major vendors,

JAVA could be great if it lost weighrt. (4, Interesting)

sg_oneill (159032) | about 9 months ago | (#44456193)

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!

Re:JAVA could be great if it lost weighrt. (0)

Anonymous Coward | about 9 months ago | (#44456385)

You should try Dropwizard with a sprinkle of Guice (if you need Dependency Injection).

If you are sick and tired of the behemoth that is Java EE or Spring, the simplicity of Dropwizard is just refreshing.

http://dropwizard.codahale.com/

Re:JAVA could be great if it lost weighrt. (0)

Anonymous Coward | about 9 months ago | (#44456519)

Make sure your comparisons are correct. Using spring-core strictly for DI (with the options of annotations or XML or convention) is actually pretty lightweight and comparable to Guice.

All of the bolt-on features of the Spring Framework are variably useful in an enterprise environment. @Transactional and the JMS bridges, for example, are extremely useful; some of the other bridges (like JMX bolt-ons), not so much. It's these other bolt-on features that Guice lacks.

Re:JAVA could be great if it lost weighrt. (0)

Anonymous Coward | about 9 months ago | (#44456397)

The solution to your date handling madness: http://joda-time.sourceforge.net/

Re:JAVA could be great if it lost weighrt. (0)

Anonymous Coward | about 9 months ago | (#44456513)

Also have a look at Project Lombok http://projectlombok.org/features/index.html. Did wonders for me.

Re:JAVA could be great if it lost weighrt. (0)

Anonymous Coward | about 9 months ago | (#44456529)

Yeah, people always hate that the most, which they understand the least...

Like JavaScript. I'm a Haskell programmer, and I with the post-ECMAScript5 language extensions I like it more than the abominations that are C/C++.
I consider C to be a utterly verbose ridiculously insecure boilerplate language for those that want or have to re-invent the wheel every damn time, and C++ a hellish nightmare that is just as insecure, even more verbose, a lot more ugly, with OOP force-sewed to the sow like it's freaking Frankenstein.
And let's not even talk about the build systems. There's a special place in hell for those.
People actually think JS is getting more like Python now. But actually Python just got more like Haskell. As did JS. And Ruby faps to Haskell every night anyway. ;)

About Java, the language: I only dislike it because of its similarly to C/C++.
About Java, programming in it: Yeah, it suffers from major enterpriseyness. Frameworks over frameworks... (a concept that itself by definition is deeply wrong and goes against the core programming principles in so many ways) ... "blueprints" full of "design patterns"... and... well, it seems like the whole ecosystem is designed by "enterprise" consultants. The worst kind. But that's not Java's fault.

From a sys admin's perspective (1)

shuz (706678) | about 9 months ago | (#44456199)

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.

Re:From a sys admin's perspective (1)

RabidReindeer (2625839) | about 9 months ago | (#44456481)

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.

Never trust the assertions of people who say "undoubtedly", "obviously", "just plain common sense", etc.

A lot of "undoubtable" things are wrong. Especially when they're based on how things "should" be. Doubt. Measure.

Re:From a sys admin's perspective (1)

bws111 (1216812) | about 9 months ago | (#44456599)

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.

Which is exactly why modern, JIT-compiled Java can, and often does, outperform C.

Question about the polls. (1, Informative)

I'm New Around Here (1154723) | about 9 months ago | (#44456209)

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

Why?

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

Speed up (0)

Anonymous Coward | about 9 months ago | (#44456251)

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++.

Latency != Determinism != Speed (2, Insightful)

Anonymous Coward | about 9 months ago | (#44456267)

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.

Easy-peasy! (1)

pla (258480) | about 9 months ago | (#44456277)

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.

Java vs. C/C++ (3, Informative)

Anonymous Coward | about 9 months ago | (#44456285)

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

Re:Java vs. C/C++ (2)

K. S. Kyosuke (729550) | about 9 months ago | (#44456491)

In my experience (30+ years), if you need consistency and speed, then you do not select Java for your environment

You have 30+ years of Java experience? Wow. BTW, if you do have a lot of Java development under your belt, how does Zing compare to other solutions in your application domain? Still inconsistent and slow? (I mean, the GC implementations started converging to what can be described as "good performance" only in the last few years, so unless you focus solely on the last few years, of course your experience is going to be horrible on the average.)

Lots of Different Languages are Used (1)

keltor (99721) | about 9 months ago | (#44456299)

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.

C# might be the missing link (0)

Anonymous Coward | about 9 months ago | (#44456339)

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).

Blah blah blah (2)

sunking2 (521698) | about 9 months ago | (#44456371)

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.

What's the news here? (1)

Anonymous Coward | about 9 months ago | (#44456375)

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

Collect the Garbage Collection (0)

Anonymous Coward | about 9 months ago | (#44456395)

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.

Uh , since around 1998? (4, Insightful)

WOOFYGOOFY (1334993) | about 9 months ago | (#44456425)

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.

The programmer, not the langauge (3, Insightful)

LostMyBeaver (1226054) | about 9 months ago | (#44456437)

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.

C++ can operate at the very limits (1)

EmperorOfCanada (1332175) | about 9 months ago | (#44456449)

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!

Sorry but... (0)

Anonymous Coward | about 9 months ago | (#44456471)

Networking is far from low latency, it will always be the bottleneck, even if you use QBASIC.

Warm up is a big deal (3, Interesting)

johndoe42 (179131) | about 9 months ago | (#44456563)

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.

The need for speed (0)

Anonymous Coward | about 9 months ago | (#44456573)

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.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...