Sun announced yesterday that a native Java version for the AMD 64 bit processor will be available on Linux and Windows platforms, allowing companies to migrate their current Java applications from a 32-bit to 64-bit computing platform.
Sun announced yesterday that a native Java version for the AMD 64 bit processor will be available on Linux and Windows platforms, allowing companies to migrate their current Java applications from a 32-bit to 64-bit computing platform.
Yeah I’m going to move MY Java apps to make the extremely slow ones less slow, but still slower than Jesus.
1) Does this double the size of an int? Or is there anything else that’s new?
2) This will only work on an x86-64, not on an ia-64, will it?
3) If I can’t run it on an ia-64, is this a performance benefit since I could run it also in compat mode?
1) I doubt it changes the size of int (or any other Number) since that is standard across versions. It might help in speed/precision with Doubles and Longs though.
2) No, though I believe Java has been compiled for IA-64. don’t hold me to that though..
As to what advantages there would be, you should see performance improvements in Java in the same places where you would see performance improvements in a native app compiled for 64bit versus 32bit, which is an article in and if itself.
This is great news.
Quadu: Obviously this isn’t good news for you. Do you even use Java? Because if you did, especially on the server side, you’d like this news but it sounds like you have nothing to do with Java other than to say it’s slow.
Ebner: Sun has provided Itanium support for some time on windows and linux. Look at http://java.sun.com/j2se/1.4.2/download.html.
Why do you need to migrate apps? This implies you have to change the source code. This is wrong! It should be write once, run anywhere!
Yeah I don’t have anything to do with Java. I learned a little of it last year, but that’s it. I just saw that there were no comments on this topic and so I just decided to post some crap I knew nothing about.
I appreciate your honesty.
And I’m pretty sure you don’t have to change any source code,
people want to migrate to 64bits platfor for greater speed and
scalability. That’s pretty useless if the javavm runs in 32 bit mode.
Don’t use Java, use Objective C, it’s easily the best OOP programming language I’ve ever used.
1) Does this double the size of an int? Or is there anything else that’s new?
No, but currently longs are implemented as two separate ints on most of the platforms such as x86. Moving to a 64-bit platform lets us to have real longs.
…and an Itanium version is already released…
Simple solution for what? To move to a 64-bit platform? Joking?
And believe me that Objective-C is not the best OOP language. It’s a native compiled programming language that’s much slower than Java in many aspects. I read this in an Objective-C forum. But it’s dynamic typed nature that makes it quite like Smalltalk makes software development much easier and flexible.
The ability to put long values in a register is an advantage, though probably not too groundbreaking for most programs (which mainly use plain ints).
The main advantage of the AMD64 is that it has more registers (16?), so compiled and JITed code can allow the CPU to use more instruction level parallelism and reduce memory traffic.
It would be interesting to know the speed of Java-JIT on x86 and, say, PowerPC (32 registers) related to clock speed.
“Why do you need to migrate apps? This implies you have to change the source code. This is wrong! It should be write once, run anywhere!”
Unless you were not coding “Pure Java” apps, no changes to source will be required. The port they are refering to is only the platform specific stuff such as the Java Virtual Machine itself, and low-level AWT related stuff. This basically means that the JVM will be able to make use of the 64 bit memory addressing and math functions.
Java virtual machines are meant to be entirely platform independent. An int in java is 32 bit regardless of hardware, and doubles and longs are 64 bit regardless of hardware. Of course, a 64 bit value has to be done through software since a 32 bit system’s registers are only 32 bit. However, on a 64 bit system, it’d be done via the hardware.
On Alpha, int’s are 32 bit but longs are 64 bit.
Java’s a great language, and if Sun can get some more performance from an x86-64 port of it, more power to them.
However, to correct a misimpression: Java is not horribly slow, and it’s not nearly as bad now as it was at release. And, for quite a few tasks, the speed hit is secondary compared to the development time you save. Java’s a very elegant language to write in (although I must profess some affinity for Prolog and Lisp, too).
-Erwos
What’s so interesting about this? Java has been running on 64 bit platforms for centuries (slowaris, vms, tru64, hp-ux, etc)
It’s still a god damned slow pig when it comes to gui relative to native applications.
I don’t think the write once run anywhere paradigm really means squat, all the freaking jvm’s are ported to all the platforms, so there’s a lot of work there. True that user code is the same, but all the shit under the hood…
I think it’s easier to write native c or c++ code and deal with the porting issues to other platforms as opposed to writing in java.
The java language does support some pretty cool shit, like garbage collecting and a better oo paradigm than c++’s multiple inheritance shit. but to suffer the penalty in run time interpretation, ugh…
I saw some software that converts java to c++ and vice versa. That shit might be cool. I think m$ has the right idea by using various languages with ultimately the same backend code. you like basic, write it in basic, you prefer java, write it in java, you like c#, write it in c#, they’ll take care of the backend shit, the machine code.
I think we need a new native, object-oriented language. Too bad objective-c is losing out to java, I kind of liked that shite.
There are other issues besides portability when comparing Native to managed applications. For example, security issues which plague the C++/C world such as Buffer overflows are a thing of the past.
The balance an rational is this; I can write an application quickly and more secure, the only downside is that it is only a fraction slower than a native one. That is the rational.
Write once, run anywhere was the original concept for Java because the original purpose of Java was for embedded devices, not the use which we see today.
“There are other issues besides portability when comparing Native to managed applications. For example, security issues which plague the C++/C world such as Buffer overflows are a thing of the past.”
Not exactly. Buffer overflows are still possible in the JVM (or in .NET’s case the CLR) itself, which can (and as Microsoft’s poorly implemented JVM constantly reminds us do) adversely affect the security of the Java software running on top of it.
As long as there is unmannaged, unsafe code, there will always be security issues.
OT: I hate to admit it, but something akin to the now defunct TCPA or the “new” TCG hardware security subsystem is also likely a requirement for a secure system in addition to well written, mannaged code. These subsystems basically prevent anything cryptographically protected by it from being attacked by software, as the keys are not accessible to untrusted code.
While it’s true that such a thing will not fix poorly written or unsafe code, it can and will help to mitigate the dammage done by such an attack.
Now if only mannaged code could fix my horrible spelling and grammar
And believe me that Objective-C is not the best OOP language.
although I don’t see much relation between the article (Java 64bit) and Objective-C, imho Objective-C is one of the best *practical* OOP language. It’s simple yet powerful. It’s really C + OOP… plus, I largelly prefers the SmallTalk paradigm over the C++ one.
It’s a native compiled programming language that’s much slower than Java in many aspects. I read this in an Objective-C forum.
References ? Java is quite fast now, but frankly, you still have much penalities. There are cases where Java could be quite fast indeed. But Objective-C is fast too… In fact, Objective-C is “slow” on method invocation (not THAT slow, but slower than C++ for example), because that’s dynamic. You gain much with that dynamicity, you pay a little in indirection. But what is great with Objective-C is that, if you NEED to be fast for a specifica method invocation, it’s easy to simply cache the method address and reuse it — voila, no more indirection, as fast as C. And anyway you’re still able to call a standard C function…
But it’s dynamic typed nature that makes it quite like Smalltalk makes software development much easier and flexible.
Oh yes. In fact, Java too has some flexibility (there are many similarities between Java/java libs and Objective-C/OpenStep), but often people uses Java as C++, as a braind-dead static OOP language. It could be more !
But I prefers anyway Objective-C. It’s not the perfect language, but it’s the less bad in many aspects. A good combination of good design, simplicity, and pragmatism.
Not exactly. Buffer overflows are still possible in the JVM (or in .NET’s case the CLR) itself, which can (and as Microsoft’s poorly implemented JVM constantly reminds us do) adversely affect the security of the Java software running on top of it.
Buffer overflows resulting from specially crafted bytecodes can be possible. But buffer overflows from user input are pretty much impossible since all array boundaries are checked at run time. It’s the latter type that Java programmers care about and which they are protected against.
Check out GCJ if you want to run native java…
Or Jet, and a few others.
I saw some software that converts java to c++ and vice versa. . I think m$ has the right idea by using various languages with ultimately the same backend code.
You can also get apps that compile C++ to btye code.
I think it’s easier to write native c or c++ code and deal with the porting issues to other platforms as opposed to writing in java.
Why is this, with Java you write once, and leave it to the JRE implementators.
First off, a full blown Java application like Jbuilder9,
isn’t slow any more. That was the old days.
Secondly, C & C++ are only faster because almost all C programmers don’t:
– Bounds check their arrays
– Don’t save their strings as Unicode
( Don’t even Use a String library )
– Don’t put in code that cleans up their dirty objects during a system crash.
– And during LOAD times, don’t verify that the exe hasn’t been modified.
– Also, their app’s are not built to run faster on a dual or better machines.
So, Java isn’t optimized, to run on the cheapest hardware available, so that it can run much better on 72 processor machines. For example, building a GUI app with Jbuilder now produces an application with 5 threads. Of course, that app will run a bit slower on a single processor machine, pointing to the reason java is popular on Dual’s.
By the way, Sun tests java on 72 processor machines.
Most people, who pontificate on Java and speed, have never loaded their jars on the server hotspot JVM, which profiles and optimizes the code in real time as it runs.
The massive heavily-nested class libraries of Java reduce Java OOP to nothing more than millions of implicit GOTO statements.
Java applications are for the most part tightly-coupled monstrosities. They have all the characteristics of low-quality codebases.
There will be better models for programming soon and the world will move on, leaving the Java Jar-Heads behind.
Dr. P.
Just because you can write your own scripts doesn’t mean you should.
I hope you get help soon.
Sure, Java’s language sucks. But it’s all about sucking less than C++. After all, there are a few niceties that are easy to forget, like being in between compiled and interpreted, builtin garbage collection, almost opensource-ish (with 80% less freedom!).
I have now total 5 enterprise application written in java written in J2EE server side programming with stateless EJB’s they take close to 5 million hits a day each . In load runner then can run 600 VUSER in just one weblogic app server running in redhatAE . I have them clustered and 3 applications run in 3 server cluster. It is nice to hear that 64 bit is going to running native.
The only thing that so scalable and robust like Java in enterprise is cobol running Tandem or OS390 or AS400.
Java and C++ are about on equal terms when it comes to complexity. Both languages produce code with millions of implicit GOTO’s and all sorts of nasty dependencies and hidden coupling.
However, C++ is more open and flexible than Java, giving the developer some chance of avoiding hypercomplexity.
Java with J2EE and other gargantuian class frameworks rapidly drive the entire application architecture into madness. For some apparently simple operations, hundreds of thousands of little objects get built in Java. And then those very same hundreds of thousands of little objects need to be garbage collected. It is not a model of efficiency.
One has to remember, Java is the language of the mindless IT hordes. At least to program in C++, the developer does require a brain. And usually when it comes to writing good software, having a brain wins out vs. not having a brain.
Well, in the original whitepaper, it was considered to be a language for average programmers, so if it doesn’t require a brain, it’s fulfilled its design goals. It never attempted to be an LFSP, but an LFM. http://www.ai.mit.edu/~gregs/ll1-discuss-archive-html/msg03338.html
Do you dislike Jython?
One has to remember, Java is the language of the mindless IT hordes. At least to program in C++, the developer does require a brain. And usually when it comes to writing good software, having a brain wins out vs. not having a brain.
So imagine what you could do with Java AND a brain !!
C++ isn’t a language for Smart people.
It’s the language for people who insist on recreating and writing their own 1 off implementations of the standard classes that have been written and debugged for years.
Also, from the Projects I’ve seen written by “Smart People”, they also seem to be Lazy people.
Continuing to insist on using Char arrays to hold strings.
Continuing to insist that they don’t need to bounds check arrays, and insisting that the app. will only accept ASCII strings.
Smart people have actually Moved to Java.
I’ve done development in both C++ (5 years) and Java (1 year). I’m kinda surprised by the mindless drivel I’ve seen here. No language is the right solution for every problem.
Java and C++ are inherently different languages. There is certainly overlap between C++ and Java (sets of applications that could be done well in either), but it really depends on what your priorities are.
Java IS easier to develop in. Though this does allow you to hire script kiddies, it doesn’t mean you should. It will generally take a good developer longer to code a solution in C++ than in Java (assuming equivalent competency). Due to garbage collection, a HUGE class of errors in C++ are largely eliminated. Also, there are a lot more gotchas in C++ than in Java that can produce problems for inexperienced (and sometimes even experienced) developers. However, all of this comes with a cost. A C++ program will generally run faster and require fewer resources to run than an equivalent Java application. Java has gotten a LOT better over the years in this respect (especially server side), but it will always be slower than C++.
I prefer C++ because I enjoy the challenge of it, but the whole idea that a language like Java is for idiots is complete crap. In the real world, things like development cost and time to market are often more important than application speed.
I am amazed at how still phenomenonally misunderstood Java is in groups like these.
1. Fallacy: Java is slow because it is interpreted.
Fact. Industrial strength JavaVM’s for desktop machines dynamically profile, compile, and optimize Java bytecodes into native code on the fly. Dynamic compilation allows a suite of techniques to be employed that are impractical or infeasible to perform in a static compiler: guarded inlining, value specific optimizations, polymorphic inline caching, loop unrolling, improved instruction scheduling. Runtime information about the program can allow the dynamic compiler to concentrate its efforts on a much much smaller portion of the program, and thus have better overall execution time by highly optimizing only the small portions of a program that take the majority of execution time. Agressive inlining strategies can lead to performance wins begin enough to be EVEN FASTER than natively compiled code. Numerous performance studies that you too can find on google bear this out. Modern VMs are DAMN FAST. And they get faster all the time: along with EVERY SINGLE PROGRAM THEY WOULD EVER RUN, WITHOUT ANY OF THOSE PROGRAMS EVER BEING RECOMPILED.
2. Fallacy: Java is slow because it is garbage collected.
Fact. Garbage collection overheads are generally not a significant portion of execution time for any but the piggiest of applications. Properly designed programs that minimize allocation and reuse can turn garbage collection into a non-issue. That said, the current crop of garbage collectors are extremely advanced. Some garbage collection strategies can actually make the program run appreciably faster by dynamically reorganizing the heap for better cache and virtual memory performance. See the blue book on garbage collection for details, or read any of the dozens of technical papers written by garbage collection researchers at many places including UMASS, IBM, and Sun.
3. Fallacy: Java is slow because of all the security checks.
Fact. Nearly all industrial VMs for desktop machines use the hardware protection facilities already used by desktop operating systems to implement null checks. Null checks do not impact the performance of field reading/writing IN ANY WAY. The exact same code emitted by a C compiler to fetch a field from a struct is generated by a Java JIT to read a field from an object.
Fact. Array bounds checks can often be optimized away. Numerous researchers over the past ten years have described practical techniques to reduce the amount of bounds checks performed on arrays at runtime. Typical results are that 60-80% of runtime checks can be eliminated. Many VMs employ some of these techniques.
Fact. Array bounds checks almost never account for a significant portion of execution time for any reasonable application. Even in the most pathologic non-numeric cases, 1% would be high. IT REALLY IS ABOUT 1 INSTRUCTION PER ACCESS! We are talking tens of millions of accesses to increase execution times by milliseconds.
4. Fallacy: Java is for stupid people.
This is like saying Macs are for stupid people. Are they?
5. Argument: Java GUI applications are bit, fat and slow.
Honestly, AWT is a mess. But it is getting better. SWT is available from IBM. Even so, more and more large desktop applications are written in Java with good performance. See IntelliJ IDEA as a good example. Quite impressive.
6. Blah blah blah, moving to 64 bits is easy/hard/good/bad/dumb/useless, blah blah blah.
All of it nonsense. As was mentioned, Java has been running on 64 bit machines for some time. Running it on SparcV9 and the HotSpot server compiler, Java powers some of the fastest webservers and application servers ANYWHERE…without ANY platform specific code…without even thinking about it!