19 ms·

How to get C like performance in Java

67 points by Garbage 15y ago

gaius 15y ago
If you have to fight the language like this, would you not be better off with a different language? Scala maybe.
- jshen 15y ago
  for most of his points you'd have to do the same things in scala, right? How do you do arbitrary memory access in scala? How do you use space efficient strings in scala? etc, etc.
  - gaius 15y ago
    OK, C++ then, or my own favourite, OCaml, for GC.
  - lucian1900 15y ago
    While the parent is generally wrong, it has been shown that Scala programs have the tendency to generate slightly (5-10%) less garbage. This is especially interesting on Dalvik.
- sehugg 15y ago
  Given that Scala targets the JVM, you are going to have to use the same tricks and probably a few others.
- uriel 15y ago
  You would be better off with a language that gives you much more control over memory layout, for example Go.
astine 15y ago
"Note: Most of these suggestions only work for standalone applications rather than applets." Whoa! That made me double-take. Applets have been an effectively abandoned technology (by the browser makers, not necessarily Sun,) for what, almost 10 years now? It's amazing this guy would feel the need to specify this. Then again, had applets ever taken off... we might be coding client-side code in Lisp now, (or your favorite JVM language :)) Crazy.
- tomjen3 15y ago
  All Danish online banks and all government services relies on a common login system which uses Java Applets. So no, they are most certainly not dead.
- gruseom 15y ago
  You can code client-side in Lisp now (or your favorite JS-targeted language). I do it every day.
  - astine 15y ago
    Parenscript isn't quite the same thing.
    - gruseom 15y ago
      That's true. You're not encapsulated from JS, so you have to be aware of JS issues like null-undefined-false-0 and all the rest of them. So it feels like you're writing in two languages at once. On the other hand, that has some benefits too.
- hello_moto 15y ago
  Facebook photo batch upload uses Applet if I'm not mistaken.
Roboprog 15y ago
Most of these tips seem to be variations of the "flyweight" design pattern (http://en.wikipedia.org/wiki/Flyweight_pattern http://en.wikipedia.org/wiki/Flyweight_pattern), to avoid around having many objects for the GC to keep checking, as well as all the other overhead for each individual object.
smcl 15y ago
The title is a little misleading, there's only a few techniques and it seems that one of the more interesting ones ("Unsafe" class) is only available in some JVMs, one doesn't help with speed in many cases (compressed strings) and a couple of the others boil down to "use DirectByteBuffers".
- peter_lawrey 15y ago
  Does your comment suggest that it can't be that simple?
jshen 15y ago
"Most systems can handle 1K-10K threads efficiently. If you need more connections than that, buy another server, a cheap one cost about $500." Shouldn't the title be, How to NOT get C like performance in Java ;)
- peter_lawrey 15y ago
  I would be very interested if you could explain what you mean. ;)
  - jshen 15y ago
    it's mostly a joke, but I think the author is ... making a bad argument. C doesn't require you to buy another server to handle more than 10k concurrent connections. So that contradicts the title, right? But, you can of course handle more than 10k concurrent on the jvm using the NIO stuff.
    - pkl 15y ago
      No business or web site which has 10K concurrent users will be using just one server. Scalability beyond 10K users/server doesn't buy you anything.
      - jshen 15y ago
        surely you jest
        peter_lawrey 15y ago
        In your experience, have you ever seen or heard of a business or web site with more than 10K concurrent users who thought it was a good idea to place all those users on just one server?
        jshen 15y ago
        connections and users are not the same thing. Accomplishing a task with fewer resources is better, so when you say " Scalability beyond 10K users/server doesn't buy you anything", you are wrong. Imagine if you have a giant datacenter like google, and heat and power are a serious problem. Accomplishing a task with fewer servers is a serious win.
nvarsj 15y ago
"One way to get C-like performance is to use C via JNI for key sections of code. If you want to avoid using C or JNI there are still ways you can get the performance you want." JNI has huge latency. Write code in Java to get "C-like" performance. "One area Java can be slower is array access. This is because it implicitly does bounds checking." Which gets optimized away by hotspot. "However this doesn't mean you can't pre-allocate your objects, use Direct ByteBuffers and Object recycling techniques to minimise your object creation." Please don't write your own object pools, this isn't 1995.
- srean 15y ago
  > Which gets optimized away by hotspot. I believe it would do so automatically only when it can prove that the bound will not be violated. That wouldnt be very often in a program written in an imperative style. Lest it be mistaken for a swipe at imperative style, functional languages don't have it much easier either. I think the problem is that for the most part, array use patterns are not very amenable to this kind of analysis. So even in functional languages you have to explicitly ask the runtime or the compiler to avoid bound-checks. If I remember correctly, there were a few languages designed to handle this case, i.e. use compile time type-checking to ensure that all the arrays are of the right shape and that none are accessed un-safely. Fish I think is what it was called. Dont know what happened to it or the idea. Seemed pretty handy to have. I think the first place to check now would be SAC (single assignment C). But I have digressed far from the topic of this thread ! > Please don't write your own object pools, this isn't 1995. The snark was unnecessary. It is frowned upon here.
  - krakensden 15y ago
    > > Please don't write your own object pools, this isn't 1995. > The snark was unnecessary. It is frowned upon here. Plus he's wrong, especially for all the people writing GUI applications who want to avoid GC pauses (for Dalvik, not the JVM, but still).
  - davidtgoldblatt 15y ago
    On the contrary, for almost all types of common array code the compiler is really good at optimizing away the bounds checks (see http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.86.9658 http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.86.96... ). Things only get tricky when you have, for instance, arrays of indices into other arrays, or when the next array position to examine depends on the contents of the one being examined. Even there though (and even in array-heavy code), bounds checks don't typically take up a ton of program execution time.
sehugg 15y ago
For servers, memory is usually the long tent pole. For me it boils down to: * Use less memory. * Don't use a lot of threads. * Use fewer objects. Worst-case GC is a big issue. For just a 2 GB heap you are looking at up to 7 second GC pauses with the Java 6 collector. You can use concurrent GC but it adds significant CPU and memory overhead. Direct buffers don't live in the heap so they don't contribute to GC time. Threads in Java are extremely heavyweight in memory, if not in CPU. A rule of thumb is about 1 MB per thread. You can make it better by decreasing the stack size and/or using 32-bit addresses.
- uriel 15y ago
  This is one of the greatest efficiency advantages of Go over Java, for the same task, Go code uses only a tiny fraction of the memory of what Java uses. http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=go&lang2=java http://shootout.alioth.debian.org/u64/benchmark.php?test=all...
- gaius 15y ago
  So use JRockit with deterministic GC on.
- peter_lawrey 15y ago
  If you create low enough garbage and your eden size is large enough, you can avoid having any minor collections at all. I have a full GC which is triggered once per night as maintainence.
jyperion 15y ago
where does one find a 16 gb server for 1k?
- krakensden 15y ago
  I don't know, but I believe it- Fry's has an ad out now for 16GB for $100 (after $50 mail-in-rebate). Sure you might want ECC, or a brand name, but the floor is pretty damn low.
- daeken 15y ago
  I just put an additional 12GB of DDR3 in my laptop (for a total of 16GB). That 12GB cost me $100 total. For ECC server RAM, you can get by with $50/4GB, so $200: http://www.newegg.com/Product/Product.aspx?Item=N82E16820139390 http://www.newegg.com/Product/Product.aspx?Item=N82E16820139...
- cultureulterior 15y ago
  http://www.abmx.com/1u-xeon-e3-server http://www.abmx.com/1u-xeon-e3-server Click 16gb. $1,008.99 (ed:no endorsement, never tried this website before)
- peter_lawrey 15y ago
  Dell sell one. However for £1K which is about $1.5k you can buy a PC with 24 GB, a 3.8 GHz i7, 120 GB SSD, two screens. ;)
speckledjim 15y ago
"Most systems can handle 1K-10K threads efficiently. If you need more connections than that, buy another server, a cheap one cost about $500." Terrible advice. Use NIO and do it properly. Creating 1 thread per connection is for unskilled programmers. In my experience once you get up to about 1k threads in Java you'll be wasting most of the CPU up switching between them. For comparison, it's trivial for any skilled programmer to use NIO to get up 100k+ connections without any real CPU usage.
- sehugg 15y ago
  Fer sure. Netty (http://www.jboss.org/netty http://www.jboss.org/netty) is your friend for handling massive numbers of NIO connections.
- papaf 15y ago
  Creating 1 thread per connection is for unskilled programmers. Its not as clear cut or obvious as it first seems: http://mailinator.blogspot.com/2008/02/kill-myth-please-nio-is-not-faster-than.html http://mailinator.blogspot.com/2008/02/kill-myth-please-nio-... Edit: The original presentation is more interesting: http://www.mailinator.com/tymaPaulMultithreaded.pdf http://www.mailinator.com/tymaPaulMultithreaded.pdf
  - speckledjim 15y ago
    The article is from back in 2008 so I'd firstly dispute its accuracy with modern JVMs. It's not just speed (The speed obviously changes as you change number of connections - 100k threads isn't going to beat 100k NIO connections). It's also that it's more scalable, better code, more maintainable, less prone to bugs, and you don't have to worry as much about concurrency issues. I'd argue that the lines of code is likely to be less also. And memory usage is likely to be less.
    - spullara 15y ago
      And performance suffers terribly when you don't need to scale the number of connections. Like anything, use it when it is needed.
fauigerzigerk 15y ago
I've been working very hard to make Java use less memory using techniques like these and others more. The problem is, if you really want to specify exactly how non-trivial structured objects are packed into memory, you end up writing your own garbage collector and memory allocator, which is a rather large project all by itself. Also, I have found that cutting down on memory usage like that hurts performance a lot. At the end of the day, going down that road makes you less productive than working in C++ and the result will still be subpar compared to a C or C++ solution. So I'm back with C++ right now even though I'm painfully aware of its weaknesses.
- sliverstorm 15y ago
  So what you're saying is, if you want C-like performance in Java, switch to C?
  - fauigerzigerk 15y ago
    Exactly, because otherwise you get assembler-like productivity. Specifying memory layouts in Java is much more low level than C or C++ programming.
  - rudiger 15y ago
    If you truly need C-like performance in Java, use C++.
- srean 15y ago
  If you are coming back to C++ after a stint with Java, I would highly recommend D. I think it hits the sweetspot between C++ and Java. The not so nice thing about D is that its libraries are not as pervasive and mature. The Phobos and Tango split is currently being addressed. I think all of Tango's functionality will be incorporated into Phobos. With D you get a simpler C++ with optional automatic memory management, and some functional idioms and nice support for parallelism. @down-voter: If you could explain what you found down-vote worthy that would be nice.
  - fauigerzigerk 15y ago
deleted 15y ago
[deleted]
known 15y ago
no pointers = no speed
- peter_lawrey 15y ago
  Can you provide any benchmarks which support this as I can provide plenty which don't?
  - known 15y ago
    http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=all&box=1 http://shootout.alioth.debian.org/u32/benchmark.php?test=all...
    - peter_lawrey 15y ago
      That's a good link. The n-body and spectral-norm benchmarks were fastest in Fortran. The fannkuch benchmark was fastest in Ada. The Mandlebrot benchmark was fastest in ATS. In each case, the language has pointers, however they were not used in the core part of the benchmark. i.e. they didn't get their speed advantage from pointers. Haskell was the fastest for the thread-ring benchmark, it doesn't have pointers. If Java had pointers as it does in the sun.misc.Unsafe utility class some code would be faster, but I don't believe this explains why Java is not the fastest in each benchmark. ;) Object orientated programming is used in a significant portion of all programs, it would be interesting how C/C++ performs in such benchmarks. ;)
      - igouy 15y ago
        >>That's a good link.<< Those measurements for programs forced to use just one core on a quad-core machine, you may also be interested in the measurements made when the programs are allowed to use all the cores - http://shootout.alioth.debian.org/u32q/which-programming-languages-are-fastest.php http://shootout.alioth.debian.org/u32q/which-programming-lan... and also measurements made on x64 http://shootout.alioth.debian.org/u64q/which-programming-languages-are-fastest.php http://shootout.alioth.debian.org/u64q/which-programming-lan... >>The n-body and spectral-norm benchmarks were fastest in Fortran.<< Maybe we should wonder if the Intel C++ compiler would produce programs comparable to those from the Intel Fortran compiler ;-) >>Object orientated programming is used in a significant portion of all programs, it would be interesting how C/C++ performs in such benchmarks.<< Maybe you're suggesting that OO C++ programs wouldn't perform as well as Java programs? But doesn't that highlight the advantage of being able to write programs in different styles?
peter_lawrey 15y ago
The answer to why would you still use Java is here "Java makes high level programming simpler and easier at the cost of making low level programming much harder. Fortunately most applications follow the rule of thumb that you spend 90% of your time in 10% of the code. This implies you are better off 90% of the time, worse off 10% of the time. ;)" Why would you develop mroe than a small portion of your application in a low level language unless every part of your application is performance critcal?

67 points by Garbage 15y ago

gaius 15y ago

If you have to fight the language like this, would you not be better off with a different language? Scala maybe.

jshen 15y ago
for most of his points you'd have to do the same things in scala, right? How do you do arbitrary memory access in scala? How do you use space efficient strings in scala? etc, etc.
- gaius 15y ago
  OK, C++ then, or my own favourite, OCaml, for GC.
- lucian1900 15y ago
  While the parent is generally wrong, it has been shown that Scala programs have the tendency to generate slightly (5-10%) less garbage. This is especially interesting on Dalvik.
sehugg 15y ago
Given that Scala targets the JVM, you are going to have to use the same tricks and probably a few others.
uriel 15y ago
You would be better off with a language that gives you much more control over memory layout, for example Go.

astine 15y ago

"Note: Most of these suggestions only work for standalone applications rather than applets." Whoa! That made me double-take. Applets have been an effectively abandoned technology (by the browser makers, not necessarily Sun,) for what, almost 10 years now? It's amazing this guy would feel the need to specify this. Then again, had applets ever taken off... we might be coding client-side code in Lisp now, (or your favorite JVM language :)) Crazy.

tomjen3 15y ago
All Danish online banks and all government services relies on a common login system which uses Java Applets. So no, they are most certainly not dead.
gruseom 15y ago
You can code client-side in Lisp now (or your favorite JS-targeted language). I do it every day.
- astine 15y ago
  Parenscript isn't quite the same thing.
  - gruseom 15y ago
    That's true. You're not encapsulated from JS, so you have to be aware of JS issues like null-undefined-false-0 and all the rest of them. So it feels like you're writing in two languages at once. On the other hand, that has some benefits too.
hello_moto 15y ago
Facebook photo batch upload uses Applet if I'm not mistaken.

Roboprog 15y ago

Most of these tips seem to be variations of the "flyweight" design pattern (http://en.wikipedia.org/wiki/Flyweight_pattern http://en.wikipedia.org/wiki/Flyweight_pattern), to avoid around having many objects for the GC to keep checking, as well as all the other overhead for each individual object.

smcl 15y ago

The title is a little misleading, there's only a few techniques and it seems that one of the more interesting ones ("Unsafe" class) is only available in some JVMs, one doesn't help with speed in many cases (compressed strings) and a couple of the others boil down to "use DirectByteBuffers".

peter_lawrey 15y ago
Does your comment suggest that it can't be that simple?

jshen 15y ago

"Most systems can handle 1K-10K threads efficiently. If you need more connections than that, buy another server, a cheap one cost about $500." Shouldn't the title be, How to NOT get C like performance in Java ;)

peter_lawrey 15y ago
I would be very interested if you could explain what you mean. ;)
- jshen 15y ago
  it's mostly a joke, but I think the author is ... making a bad argument. C doesn't require you to buy another server to handle more than 10k concurrent connections. So that contradicts the title, right? But, you can of course handle more than 10k concurrent on the jvm using the NIO stuff.
  - pkl 15y ago
    No business or web site which has 10K concurrent users will be using just one server. Scalability beyond 10K users/server doesn't buy you anything.
    - jshen 15y ago
      surely you jest
      - peter_lawrey 15y ago
        In your experience, have you ever seen or heard of a business or web site with more than 10K concurrent users who thought it was a good idea to place all those users on just one server?
        jshen 15y ago
        connections and users are not the same thing. Accomplishing a task with fewer resources is better, so when you say " Scalability beyond 10K users/server doesn't buy you anything", you are wrong. Imagine if you have a giant datacenter like google, and heat and power are a serious problem. Accomplishing a task with fewer servers is a serious win.

nvarsj 15y ago

"One way to get C-like performance is to use C via JNI for key sections of code. If you want to avoid using C or JNI there are still ways you can get the performance you want." JNI has huge latency. Write code in Java to get "C-like" performance. "One area Java can be slower is array access. This is because it implicitly does bounds checking." Which gets optimized away by hotspot. "However this doesn't mean you can't pre-allocate your objects, use Direct ByteBuffers and Object recycling techniques to minimise your object creation." Please don't write your own object pools, this isn't 1995.

srean 15y ago
> Which gets optimized away by hotspot. I believe it would do so automatically only when it can prove that the bound will not be violated. That wouldnt be very often in a program written in an imperative style. Lest it be mistaken for a swipe at imperative style, functional languages don't have it much easier either. I think the problem is that for the most part, array use patterns are not very amenable to this kind of analysis. So even in functional languages you have to explicitly ask the runtime or the compiler to avoid bound-checks. If I remember correctly, there were a few languages designed to handle this case, i.e. use compile time type-checking to ensure that all the arrays are of the right shape and that none are accessed un-safely. Fish I think is what it was called. Dont know what happened to it or the idea. Seemed pretty handy to have. I think the first place to check now would be SAC (single assignment C). But I have digressed far from the topic of this thread ! > Please don't write your own object pools, this isn't 1995. The snark was unnecessary. It is frowned upon here.
- krakensden 15y ago
  > > Please don't write your own object pools, this isn't 1995. > The snark was unnecessary. It is frowned upon here. Plus he's wrong, especially for all the people writing GUI applications who want to avoid GC pauses (for Dalvik, not the JVM, but still).
- davidtgoldblatt 15y ago
  On the contrary, for almost all types of common array code the compiler is really good at optimizing away the bounds checks (see http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.86.9658 http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.86.96... ). Things only get tricky when you have, for instance, arrays of indices into other arrays, or when the next array position to examine depends on the contents of the one being examined. Even there though (and even in array-heavy code), bounds checks don't typically take up a ton of program execution time.

sehugg 15y ago

For servers, memory is usually the long tent pole. For me it boils down to: * Use less memory. * Don't use a lot of threads. * Use fewer objects. Worst-case GC is a big issue. For just a 2 GB heap you are looking at up to 7 second GC pauses with the Java 6 collector. You can use concurrent GC but it adds significant CPU and memory overhead. Direct buffers don't live in the heap so they don't contribute to GC time. Threads in Java are extremely heavyweight in memory, if not in CPU. A rule of thumb is about 1 MB per thread. You can make it better by decreasing the stack size and/or using 32-bit addresses.

uriel 15y ago
This is one of the greatest efficiency advantages of Go over Java, for the same task, Go code uses only a tiny fraction of the memory of what Java uses. http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=go&lang2=java http://shootout.alioth.debian.org/u64/benchmark.php?test=all...
gaius 15y ago
So use JRockit with deterministic GC on.
peter_lawrey 15y ago
If you create low enough garbage and your eden size is large enough, you can avoid having any minor collections at all. I have a full GC which is triggered once per night as maintainence.

jyperion 15y ago

where does one find a 16 gb server for 1k?

krakensden 15y ago
I don't know, but I believe it- Fry's has an ad out now for 16GB for $100 (after $50 mail-in-rebate). Sure you might want ECC, or a brand name, but the floor is pretty damn low.
daeken 15y ago
I just put an additional 12GB of DDR3 in my laptop (for a total of 16GB). That 12GB cost me $100 total. For ECC server RAM, you can get by with $50/4GB, so $200: http://www.newegg.com/Product/Product.aspx?Item=N82E16820139390 http://www.newegg.com/Product/Product.aspx?Item=N82E16820139...
cultureulterior 15y ago
http://www.abmx.com/1u-xeon-e3-server http://www.abmx.com/1u-xeon-e3-server Click 16gb. $1,008.99 (ed:no endorsement, never tried this website before)
peter_lawrey 15y ago
Dell sell one. However for £1K which is about $1.5k you can buy a PC with 24 GB, a 3.8 GHz i7, 120 GB SSD, two screens. ;)

speckledjim 15y ago

"Most systems can handle 1K-10K threads efficiently. If you need more connections than that, buy another server, a cheap one cost about $500." Terrible advice. Use NIO and do it properly. Creating 1 thread per connection is for unskilled programmers. In my experience once you get up to about 1k threads in Java you'll be wasting most of the CPU up switching between them. For comparison, it's trivial for any skilled programmer to use NIO to get up 100k+ connections without any real CPU usage.

sehugg 15y ago
Fer sure. Netty (http://www.jboss.org/netty http://www.jboss.org/netty) is your friend for handling massive numbers of NIO connections.
papaf 15y ago
Creating 1 thread per connection is for unskilled programmers. Its not as clear cut or obvious as it first seems: http://mailinator.blogspot.com/2008/02/kill-myth-please-nio-is-not-faster-than.html http://mailinator.blogspot.com/2008/02/kill-myth-please-nio-... Edit: The original presentation is more interesting: http://www.mailinator.com/tymaPaulMultithreaded.pdf http://www.mailinator.com/tymaPaulMultithreaded.pdf
- speckledjim 15y ago
  The article is from back in 2008 so I'd firstly dispute its accuracy with modern JVMs. It's not just speed (The speed obviously changes as you change number of connections - 100k threads isn't going to beat 100k NIO connections). It's also that it's more scalable, better code, more maintainable, less prone to bugs, and you don't have to worry as much about concurrency issues. I'd argue that the lines of code is likely to be less also. And memory usage is likely to be less.
  - spullara 15y ago
    And performance suffers terribly when you don't need to scale the number of connections. Like anything, use it when it is needed.

fauigerzigerk 15y ago

I've been working very hard to make Java use less memory using techniques like these and others more. The problem is, if you really want to specify exactly how non-trivial structured objects are packed into memory, you end up writing your own garbage collector and memory allocator, which is a rather large project all by itself. Also, I have found that cutting down on memory usage like that hurts performance a lot. At the end of the day, going down that road makes you less productive than working in C++ and the result will still be subpar compared to a C or C++ solution. So I'm back with C++ right now even though I'm painfully aware of its weaknesses.

sliverstorm 15y ago
So what you're saying is, if you want C-like performance in Java, switch to C?
- fauigerzigerk 15y ago
  Exactly, because otherwise you get assembler-like productivity. Specifying memory layouts in Java is much more low level than C or C++ programming.
- rudiger 15y ago
  If you truly need C-like performance in Java, use C++.
srean 15y ago
If you are coming back to C++ after a stint with Java, I would highly recommend D. I think it hits the sweetspot between C++ and Java. The not so nice thing about D is that its libraries are not as pervasive and mature. The Phobos and Tango split is currently being addressed. I think all of Tango's functionality will be incorporated into Phobos. With D you get a simpler C++ with optional automatic memory management, and some functional idioms and nice support for parallelism. @down-voter: If you could explain what you found down-vote worthy that would be nice.
- fauigerzigerk 15y ago

deleted 15y ago

[deleted]

known 15y ago

no pointers = no speed

peter_lawrey 15y ago
Can you provide any benchmarks which support this as I can provide plenty which don't?
- known 15y ago
  http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=all&box=1 http://shootout.alioth.debian.org/u32/benchmark.php?test=all...
  - peter_lawrey 15y ago
    That's a good link. The n-body and spectral-norm benchmarks were fastest in Fortran. The fannkuch benchmark was fastest in Ada. The Mandlebrot benchmark was fastest in ATS. In each case, the language has pointers, however they were not used in the core part of the benchmark. i.e. they didn't get their speed advantage from pointers. Haskell was the fastest for the thread-ring benchmark, it doesn't have pointers. If Java had pointers as it does in the sun.misc.Unsafe utility class some code would be faster, but I don't believe this explains why Java is not the fastest in each benchmark. ;) Object orientated programming is used in a significant portion of all programs, it would be interesting how C/C++ performs in such benchmarks. ;)
    - igouy 15y ago
      >>That's a good link.<< Those measurements for programs forced to use just one core on a quad-core machine, you may also be interested in the measurements made when the programs are allowed to use all the cores - http://shootout.alioth.debian.org/u32q/which-programming-languages-are-fastest.php http://shootout.alioth.debian.org/u32q/which-programming-lan... and also measurements made on x64 http://shootout.alioth.debian.org/u64q/which-programming-languages-are-fastest.php http://shootout.alioth.debian.org/u64q/which-programming-lan... >>The n-body and spectral-norm benchmarks were fastest in Fortran.<< Maybe we should wonder if the Intel C++ compiler would produce programs comparable to those from the Intel Fortran compiler ;-) >>Object orientated programming is used in a significant portion of all programs, it would be interesting how C/C++ performs in such benchmarks.<< Maybe you're suggesting that OO C++ programs wouldn't perform as well as Java programs? But doesn't that highlight the advantage of being able to write programs in different styles?

peter_lawrey 15y ago

The answer to why would you still use Java is here "Java makes high level programming simpler and easier at the cost of making low level programming much harder. Fortunately most applications follow the rule of thumb that you spend 90% of your time in 10% of the code. This implies you are better off 90% of the time, worse off 10% of the time. ;)" Why would you develop mroe than a small portion of your application in a low level language unless every part of your application is performance critcal?