The example graphs don't look so pleasant though. The (default?) colour scheme is excellent for a semi-lit astronomical dome (doesn't ruin your night vision) but I put those in front a business board without a fair bit of work on the aesthetics - wouldn't want the company directors to start throwing chairs, would ya?.
So you have a value between 0.5 and 1 (assuming non-negative integers).
How many times do you compute this in your program and what accuracy do you need?
You might receive a large speed boost using the tried and tested look-up table if you only need 6 digits of precision rather than 15. You could compute your function for a million values of x for example and do a look up at runtime. Games do these kinds of look-up all the time to get good performance (even in C).
If speed of this function is *really* important you could do the computation in your GPU (I used Java JoGL with a shader to do fast single-precision floating point).
Note: If you are raising numbers to an integer power you will almost certainly get better performance doing
y = x*x*x than y = pow(x, 3.0)
in any language.
That's got to make a lot of physicists and quantum chemists very happy.
If only that were true. Unfortunately there is a lot of out-of-date information being given to these guys, which is why they still labour developing with less-productive languages.
FYI, I'm an IT consultant to government using Java, C++, and C, have a PhD in Astrophysics and still write image analysis and hardware interface code (C++ and Java JNI) for my old research project. So I feel somewhat qualified in my statements.
If Java Hotspot is outperforming the "best" C Compilers it's due to those compiler companies spending very few, if any, cycles on getting more performance out of their compiler.
That could be true but I find it hard to believe. The point is moot though, what matters is which program runs faster for a particular application and how much effort is required to develop the application (time/cost is often prohibitive for many projects).
The overall Java performance is lower than the performance of the same C++ program though, due to the following reasons:
1) excessive run-time casting. C++ templates are a great win over Java generics.
You may be right. I need to cast very rarely in my programs by choosing my types judiciously. The performance bottlenecks in my programs are never casting, instead they are doing matrix and image processing operations.
2) calling a method on an interface is an order of magnitude slower than vtable calls.
Incorrect. The Hotspot compiler can inline many calls including interface calls, since the runtime can determine how the call is *actually* used rather than how the method *might* be used. Here runtime compilation beats compile-time optimisation.
3) Java consumes way more memory (the simplest widget, for example, consumes over 1K).
True with the Sun runtime, not really true if you use gcj. Memory usage in Java is definitely an issue for memory constrained devices. However almost all desktops and servers these days have multi-gigabyte RAM. The in-memory size of the Java runtime library is insignificant to the user's data structures in large programs and generally insignificant to the amount of RAM available on most user's systems (and the memory footprint of a single Java program is pretty small compared to the memory consumed by XP or Vista itself).
But why do we need a whole industry and a lot of research to patch a language to make it fast ? Instead of using something that is already fast in it's own right ?
Good question. I would answer that it is because the development time (that is, cost of developing a large system) of C++ outweighs its benefits. Many (commercial) software projects succeed or fail at the proposal stage based on development time and estimated cost. With C++ the benefits are often not compelling enough. For you own little programs either C++ or Java are viable options, but Java is arguably easier to get going and get working correctly for developers starting the craft.
Plus, Java has several advantages over Standard C++: more support for multithreaded programming, a larger set of standard libraries, better source code portability between platforms and different compilers, etc.
You're a funny guy but obviously have zero idea about what you are talking about. It's a bit aggravating that ignorant folk still come out with the same old 'slow' mantra and unfortunately even more ignorant folk buy into it. That keeps people writing crappy software on C++ or C when quite often Java would be a good fit for them and the performance is mostly a non-issue these days (unless you write very inefficient programs).
I used to eschew Java for the speed of C++ but now I've completely switched to Java for most development tasks (apart from some C glue-code [JNI] when I need to integrate some scientific instrument or another). I'm doing instrument control, image processing and analysis and I need both reasonable latency, multithreading support, and every performance cycle I can get, and yet Java is plenty fast enough for me (and even embedded devices these days have relatively large amounts of RAM this is far less of an issue than it used to be).
Seriously Java is very fast these days. Graphics2D is all done in Direct3D or OpenGL shaders, the VM is very optimised and quite often approaches FORTRAN (which is faster than C). Don't believe me? check out the links below.
So please, next time stop with the FUD (that used to be marginally true 5 years ago) and start with an open mind.
From http://en.wikipedia.org/wiki/Java_performance#Use_for_High_Performance_Computing
"However, High Performance Computing applications written in Java have recently won benchmark competitions. In 2008, Apache Hadoop, an open source High Performance Computing project written in Java was able to sort a terabyte of integers the fastest.[46]"
INRIA (French scientifc Institution) report on High Performance Computing with Java [Summary: Java approaching FORTRAN for speed, although some network intensive speed bumps still remaining] http://hal.inria.fr/inria-00312039/en
At the last JavaOne I did a walk-on talk during the AMD keynote where I talked about how incredible HotSpot's performance had become - beating the best C compilers. I ended my talk with a joking comment that "the next target is Fortran". Afterwards, Denis Caromel of Inria came up to me and said "you're already there". He and some colleges had been working on some comparisons between Java and Fortran for HPC. Their final report Current State of Java for HPC has been made available as a Tech Report and makes pretty interesting reading. There are a lot of HPC micro benchmarks in it which look great. Thanks! Permalink Comments [3]
Netbeans got an overhaul of the editor in version 6 and the whole thing is significantly faster (I find editing and completion is now faster in Netbeans than Eclipse). In general Eclipse can often do more complicated things than Netbeans but I find that it is so much simpler to do equivalent things in Netbeans (as in the things you do many times per day rather than the complex things you do once every couple of projects).
You mentioned OpenGL development. Netbeans has a nice (free) plugin for this that also helps designing shaders.
Unless you're writing telephone network software I'd say jumping to Java is probably a good move (rather than.Net which is only fully implemented on one architecture on one O/S). With Java your productivity will end up higher than C++ and you're equipped from embedded to supercomputer and (almost) all operating systems.
You are correct regarding finalisation of the specification but completely incorrect regarding the implementation.
The Firewire specification was *created* in 1986 and used in 1987 according to:
http://www.1394ta.org/Technology/index.htm
The IEEE standard wasn't released until 1995 but devices had been on the market for years before that.
IEEE-1394b (a revision of 'FireWire') is used in the F-22 and F-35 fighters. This is because it is far superior to USB in real-time applications (isochronous modes).
FireWire also uses far less CPU than USB, and has better transfer rates in practice (despite the 'theoretical' peak USB speed being faster [480 vs 400 Mbps] than 1394a).
The real reason USB was invented was so that IBM and Microsoft wouldn't have to pay Apple for FireWire royalties. USB is the result of a business decision, not because it was superior technology to FireWire.
In combat flight sims (for example, the excellent Lock On Modern Air Combat/Flaming Cliffs) you need every pixel you can get. 1920x1200 is excellent for visually acquiring targets far away. Lower resolutions make it hard to see bandits until they've already launched a missile at you.
They say, "Lose sight, lose the fight". That doesn't only apply to dogfighting. It means if you spot first you get to set up the initial conditions of the engagement (if you can approach from someone's flank their radar can't spot you).
Sure, you don't need high resolution for FPS where opponents are within cat-swinging range, but for games like flight sims it is invaluable.
Slashdot Mirror
s/but I put/but I wouldn't put/
The example graphs don't look so pleasant though. The (default?) colour scheme is excellent for a semi-lit astronomical dome (doesn't ruin your night vision) but I put those in front a business board without a fair bit of work on the aesthetics - wouldn't want the company directors to start throwing chairs, would ya?.
How many times do you compute this in your program and what accuracy do you need?
You might receive a large speed boost using the tried and tested look-up table if you only need 6 digits of precision rather than 15. You could compute your function for a million values of x for example and do a look up at runtime. Games do these kinds of look-up all the time to get good performance (even in C).
If speed of this function is *really* important you could do the computation in your GPU (I used Java JoGL with a shader to do fast single-precision floating point).
Here is are interesting benchmarks comparing floating point performance:
1) http://www.fourmilab.ch/fourmilog/archives/2005-08/000567.html
Java is 12% slower than C and Visual Basic.NET is 13% faster. This is based on the usage of an optical design ray tracing programme.
2) http://kano.net/javabench/
Note: If you are raising numbers to an integer power you will almost certainly get better performance doing y = x*x*x than y = pow(x, 3.0) in any language.
That's got to make a lot of physicists and quantum chemists very happy.
If only that were true. Unfortunately there is a lot of out-of-date information being given to these guys, which is why they still labour developing with less-productive languages.
FYI, I'm an IT consultant to government using Java, C++, and C, have a PhD in Astrophysics and still write image analysis and hardware interface code (C++ and Java JNI) for my old research project. So I feel somewhat qualified in my statements.
If Java Hotspot is outperforming the "best" C Compilers it's due to those compiler companies spending very few, if any, cycles on getting more performance out of their compiler.
That could be true but I find it hard to believe. The point is moot though, what matters is which program runs faster for a particular application and how much effort is required to develop the application (time/cost is often prohibitive for many projects).
The overall Java performance is lower than the performance of the same C++ program though, due to the following reasons:
1) excessive run-time casting. C++ templates are a great win over Java generics.
You may be right. I need to cast very rarely in my programs by choosing my types judiciously. The performance bottlenecks in my programs are never casting, instead they are doing matrix and image processing operations.
2) calling a method on an interface is an order of magnitude slower than vtable calls. Incorrect. The Hotspot compiler can inline many calls including interface calls, since the runtime can determine how the call is *actually* used rather than how the method *might* be used. Here runtime compilation beats compile-time optimisation. 3) Java consumes way more memory (the simplest widget, for example, consumes over 1K).
True with the Sun runtime, not really true if you use gcj. Memory usage in Java is definitely an issue for memory constrained devices. However almost all desktops and servers these days have multi-gigabyte RAM. The in-memory size of the Java runtime library is insignificant to the user's data structures in large programs and generally insignificant to the amount of RAM available on most user's systems (and the memory footprint of a single Java program is pretty small compared to the memory consumed by XP or Vista itself).
But why do we need a whole industry and a lot of research to patch a language to make it fast ? Instead of using something that is already fast in it's own right ?
Good question. I would answer that it is because the development time (that is, cost of developing a large system) of C++ outweighs its benefits. Many (commercial) software projects succeed or fail at the proposal stage based on development time and estimated cost. With C++ the benefits are often not compelling enough. For you own little programs either C++ or Java are viable options, but Java is arguably easier to get going and get working correctly for developers starting the craft. Plus, Java has several advantages over Standard C++: more support for multithreaded programming, a larger set of standard libraries, better source code portability between platforms and different compilers, etc.
You're a funny guy but obviously have zero idea about what you are talking about. It's a bit aggravating that ignorant folk still come out with the same old 'slow' mantra and unfortunately even more ignorant folk buy into it. That keeps people writing crappy software on C++ or C when quite often Java would be a good fit for them and the performance is mostly a non-issue these days (unless you write very inefficient programs).
I used to eschew Java for the speed of C++ but now I've completely switched to Java for most development tasks (apart from some C glue-code [JNI] when I need to integrate some scientific instrument or another). I'm doing instrument control, image processing and analysis and I need both reasonable latency, multithreading support, and every performance cycle I can get, and yet Java is plenty fast enough for me (and even embedded devices these days have relatively large amounts of RAM this is far less of an issue than it used to be).
Seriously Java is very fast these days. Graphics2D is all done in Direct3D or OpenGL shaders, the VM is very optimised and quite often approaches FORTRAN (which is faster than C). Don't believe me? check out the links below.
So please, next time stop with the FUD (that used to be marginally true 5 years ago) and start with an open mind.
"However, High Performance Computing applications written in Java have recently won benchmark competitions. In 2008, Apache Hadoop, an open source High Performance Computing project written in Java was able to sort a terabyte of integers the fastest.[46]"
http://hal.inria.fr/inria-00312039/en
Current State of Java for HPC
At the last JavaOne I did a walk-on talk during the AMD keynote where I talked about how incredible HotSpot's performance had become - beating the best C compilers. I ended my talk with a joking comment that "the next target is Fortran". Afterwards, Denis Caromel of Inria came up to me and said "you're already there". He and some colleges had been working on some comparisons between Java and Fortran for HPC. Their final report Current State of Java for HPC has been made available as a Tech Report and makes pretty interesting reading. There are a lot of HPC micro benchmarks in it which look great. Thanks! Permalink Comments [3]
Netbeans got an overhaul of the editor in version 6 and the whole thing is significantly faster (I find editing and completion is now faster in Netbeans than Eclipse). In general Eclipse can often do more complicated things than Netbeans but I find that it is so much simpler to do equivalent things in Netbeans (as in the things you do many times per day rather than the complex things you do once every couple of projects). You mentioned OpenGL development. Netbeans has a nice (free) plugin for this that also helps designing shaders. Unless you're writing telephone network software I'd say jumping to Java is probably a good move (rather than .Net which is only fully implemented on one architecture on one O/S). With Java your productivity will end up higher than C++ and you're equipped from embedded to supercomputer and (almost) all operating systems.
That Lambrusco stuff is brilliant pantie remover.
That's great news. You wouldn't believe the number of stubborn panties I've had on my carpet and Friend just wouldn't shift them.
You are correct regarding finalisation of the specification but completely incorrect regarding the implementation. The Firewire specification was *created* in 1986 and used in 1987 according to: http://www.1394ta.org/Technology/index.htm The IEEE standard wasn't released until 1995 but devices had been on the market for years before that.
IEEE-1394b (a revision of 'FireWire') is used in the F-22 and F-35 fighters. This is because it is far superior to USB in real-time applications (isochronous modes). FireWire also uses far less CPU than USB, and has better transfer rates in practice (despite the 'theoretical' peak USB speed being faster [480 vs 400 Mbps] than 1394a). The real reason USB was invented was so that IBM and Microsoft wouldn't have to pay Apple for FireWire royalties. USB is the result of a business decision, not because it was superior technology to FireWire.
In combat flight sims (for example, the excellent Lock On Modern Air Combat/Flaming Cliffs) you need every pixel you can get. 1920x1200 is excellent for visually acquiring targets far away. Lower resolutions make it hard to see bandits until they've already launched a missile at you.
They say, "Lose sight, lose the fight". That doesn't only apply to dogfighting. It means if you spot first you get to set up the initial conditions of the engagement (if you can approach from someone's flank their radar can't spot you).
Sure, you don't need high resolution for FPS where opponents are within cat-swinging range, but for games like flight sims it is invaluable.