How about a PowerPC enhanced for Java?
Apple has said they want to become "the best platform for Java development." Become... maybe. They aren't there yet, and always lagging behind the latest version of Java available for Windows certainly doesn't help. (For years, Apple had be stuck at Java 1.1, while Windows went to 1.2 and 1.3. OS 9 is forever frozen at 1.1. Now that you can get Java 1.3 in OS X, Windows has 1.4.)
What if Apple decided to develop (have Motorola/IBM/someone develop for them) a new processor in the PowerPC family that had a Java byte-code mode for native execution of Java byte codes? Let's call it a G5+J. As a Java developer, I'd be thrilled. But, not being a chip guru, I have no idea how practical, difficult, or expensive such an undertaking would be.
Any thoughts or opinions on this idea?
What if Apple decided to develop (have Motorola/IBM/someone develop for them) a new processor in the PowerPC family that had a Java byte-code mode for native execution of Java byte codes? Let's call it a G5+J. As a Java developer, I'd be thrilled. But, not being a chip guru, I have no idea how practical, difficult, or expensive such an undertaking would be.
Any thoughts or opinions on this idea?
Comments
<strong>i don't know too much about processors, but (to me) it seems unusually ineffecient to engineer a proc to a specific programming language. I don't think most programs for macs are written in java. There are some, of course, but I don't think as many as in c, or c++. To build a chip to a language seems ridiculous to me. It doesn't seem practical.</strong><hr></blockquote>
It helps to understand what Java byte code is: It's an machine language for a (so far) virtual machine. Java programs get compiled into so-called byte code rather than directly into platform-specific machine language. When a Java program executes, this byte code has either has to be interpreted, or has to be compiled at run-time (with something called a JITC -- Just-In-Time Compiler). Interpreting byte code is very slow, so a JITC is typically used nowadays, but the JITC slows down first-time execution of all code, and JITCs in general don't produce particularly efficient native code.
Java byte code is well designed for object-oriented design and dynamic garbage collection. It's conceivable it might have some utility beyond running Java code.
Also, even if C and C++ are the leading languages, Apple is trying to encourage the use of Java, and what better way to do it than to have the fastest Java platform around?
In terms of design, I'm hoping that making a chip like this wouldn't be too much different than making a CPU that has a compatibility mode for an earlier generation chip -- one chip capable of executing two different instruction sets.
Apple will always be a bit behind Windows because Sun does all the Windows Java development themselves. Apple starts with Sun's UNIX code and tweaks it. This is good: It means you get Aqua, and the bridges to Cocoa and AppleScript and other goodies, as well as careful optimization for the platform. But that all takes time. Jaguar should boast an improved 1.3.1 version, in addition to an all-around performance boost.
If you're using AWT, that invokes a major speed hit on Macs. Sun is deprecating it, so Apple didn't lift a finger to optimize it. Just a thought.
[ 07-08-2002: Message edited by: Amorph ]</p>
Amorph, are you sure about 1.3.1 in Jaguar? I was under the impression that 1.4 would be around then. Apple had previously promised a 1.4 developer preview at WWDC 2002, which obviously didn't happen, but I was hopeing that 1.4 might ship with Jaguar.
Once that update is in place, and assuming that there will be no major fires to put out, I think it's safe to assume that Apple's Java team will turn their attention to 1.4.
[ 07-08-2002: Message edited by: Amorph ]</p>
[ 07-08-2002: Message edited by: Animaniac ]
[ 07-08-2002: Message edited by: Animaniac ]</p>
<strong>Java, in the enterprise world, is on it's way out.
</strong><hr></blockquote>
As you already said, there are many people to disagree with you.
<strong> [quote]Java is horrible for any real developer to work with.
</strong><hr></blockquote>
It depends on what you are doing. Swing isn't really the best thing since sliced bread, but on a server you don't need Swing. And now there's coming an alternative for those who want/need it (SWT, see eclipse.org)
<strong> [quote]
Java is dying. It's simple as that. I know there will be plenty of people to disagree with me, as I know there are many people in the software world that support Java blindly; however, only time will tell that I am right.
</strong><hr></blockquote>
Everything will die eventually. The question is: When will it die?
<strong>You don't want a PC CPU to be optimized for a particular language, especially when there are at least two other prominent - and utterly different - languages on the platform it's running. There are a lot of software/design approaches that should be taken before anyone starts looking to hardware.]</strong><hr></blockquote>
I'm considering Java byte code as an entity somewhat independent of the Java language itself. Any language, including C and C++, could be compiled into byte code.
Nor would I propose any particular optimization of the processor that would change how PowerPC code is handled in anyway. The only optimization, if you want to call it that, would be that the processor would support an alternate instruction set that corresponds to Java byte code.
<strong>Jaguar should boast an improved 1.3.1 version, in addition to an all-around performance boost.</strong>
I'm eager to see this
<strong>If you're using AWT, that invokes a major speed hit on Macs. Sun is deprecating it, so Apple didn't lift a finger to optimize it. Just a thought.
That could explain a few things
In my professional work, I use Swing. For my free web-based Java astronomy applet ( <a href="http://www.skyviewcafe.com"; target="_blank">http://www.skyviewcafe.com</A>; ), I'm still using AWT because I want to be compatible with the broadest range of web browsers, without the user having to download any plug-ins. For one thing, leaving out Swing and sticking to JDK 1.1 allowed my applet to run on OS 9 (may it rest in peace).
I'm slowly working in my spare time to create a new Swing version with JDK 1.3 as a minimum requirement, but it will take some time to complete. It will be interesting to see if Swing in and of itself makes a noticeable difference in performance on OS X. Typically Swing is slower that AWT. I'll lock the feature set of the older version of the applet, and keep it around for those who might need it.
<strong>With my experience with (all flavors of) Java, I have come to the conclusion that it's the most inefficient and incompatabile language.</strong><hr></blockquote>
Depends what sort of efficiency you're talking about. As a developer, I find working in Java much for efficient for getting my work done than working in C++. I worked in C++ for nearly seven years, and I was good at it. I had a reputation that my in development code was more stable than a lot of commercially released software. Nevertheless, even though I was skilled and very thorough about handling dynamic memory and pointers, I'd rather not have to. I can work much, much faster in Java not having to worry about such things.
As for execution efficiency... yes, in most cases Java is slower than, say, compiled C or C++. Some of that inefficiency could be addressed by better optimization by Java compilers, without touching the language itself. Another major factor is interpretation or runtime-compilation of byte code. The idea I'm proposing would eliminate that inefficiency by making Java byte code a native machine language, directly executable by the CPU.
For a great deal of software, execution is so fast on modern hardware that the efficiency of C and C++ vs. Java doesn't really matter. Where efficiency does matter, especially if cross-platform execution is not important, you can use JNI to speed up key processing-intensive routines.
<strong>It would be horrible for Apple to support Java more than they are right now. Apple will only waste resources in trying to satisfy a very small minority of the development community.</strong>
"Very small minority"? Ever hear about something called the Web? You'll find one or two Java programmers out there if you look
<strong>Microsoft wants to kill Java, and has pretty much accomplished that on the Windows platform.</strong>
Microsoft may be trying, but I wouldn't write the obituary yet. Besides, Microsoft must think the concept of Java is pretty damned good, or they wouldn't be trying to make their own Microsoft-controlled clone called C#. I don't think we should always automatically roll over and let the 800 lb. gorilla get its way.
<strong>Java is horrible for any real developer to work with.</strong>
Hmmm... I must have failed to notice that my torment was unbearable.
<strong>It's a good language for beginners wanting to learn to program (especially in OOP)...</strong>
Well, we can't all achieve your unassailable level of programming prowess. Please forgive the rest of us if we leave the training wheels on.
[/QB]...but it fails to come close in performance and versitility of other languages. Java is dying. It's simple as that.[/QB]
(Pressing my ear against my computer to listen for Java's death rattle.)
<strong>I know there will be plenty of people to disagree with me...</strong>
Hey, now there's something I can agree with!
[QB]
I'm considering Java byte code as an entity somewhat independent of the Java language itself. Any language, including C and C++, could be compiled into byte code.
[qb]<hr></blockquote>
SmallEiffel(http://smalleiffel.loria.fr) already does this. It's compiler can either produce C code(which is then compiled by the user's C compiler of choice) or Java byte code.
Also, the Java virtual machine is rather simple, with lots of very basic instructions that are used together to do more complex tasks. In a virtual machine this causes a performance hit, since complex tasks can't have optimized instructions. The up and coming Parrot VM takes the opposite approach, and manages some pretty darn respectable performance compared to other VMs.
If you could optimize the Java byte code instructions in hardware, rather than having to translate them to native machine code on the fly(at the very least removing that overhead), you could gain quite a performance boost.
I don't remember where I read this, but I believe someone else was already working on this for the embedded market(cellphones, PDAs, etc.)
Perhaps, if Motorola doesn't get cut out of the PPC alliance, they could be so nice as to provide such a processor.
<strong>What would happen to this Java chip once the JVM gets reved to 1.5, or an updated 1.4? Wouldn't this specialized processor be useless for future versions of Java, or would the byte-code all remain forward-compatible? That seems highly unlikely to me.</strong><hr></blockquote>
Actually, Java byte code is a very stable set of instructions. You can update Java without updating the byte code instructions set, just like you can update the C++ language without needing a new microprocessor to run the compiled C++ code.
I've searched, but so far I've failed to locate a definitive history of the byte code instruction set to see when and if it has ever been modified since the first release of Java. Anyone out there have this info?
Here's the bytecode spec; it has changed a little over time but not much:
<a href="http://java.sun.com/docs/books/vmspec/"; target="_blank">http://java.sun.com/docs/books/vmspec/</a>;
Unless you want Apple to port all of OS X to java?
or do you mean in some sort of co-processor functionality? even so, too much cost for a gain that most people would not see. Java is NOT a big issue for most people, save LimeWire.
<strong>With my experience with (all flavors of) Java is supported on OS X more than it is on Windowsl; supporting it any more would be futile, since the hardcore Java developers will stick with their Sun boxes.
</strong>
<hr></blockquote>
huh? windows has 1.4. sun supports windows. sun doesnt support osx.
[quote]
<strong>
Java, in the enterprise world, is on it's way out. The only people that truely support it now are Sun
</strong>
<hr></blockquote>
huh? have you heard of IBM, BEA, etc. what evidence to you have that's its on the way out? what will replace it?
[quote]
<strong>
...and the only OS that is able to handle Java like any other language is the SunOS (a derrivative of UNIX, nevertheless).
</strong>
<hr></blockquote>
huh? like any other language? what language features are you talking about?
[quote]
<strong>
Microsoft wants to kill Java, and has pretty much accomplished that on the Windows platform.
</strong>
<hr></blockquote>
yes, java will always be a third party on any windows system. big deal...
[quote]
<strong>
Sun is trying to keep life in Java by developing new uses for it such as JSP (a reincarnation of the horrible Servlets) and the like.
</strong>
<hr></blockquote>
JSP is by no means *new* java technology...and if you want something *less horrible* then there are many other forms of web-based interaction to choose from.
[quote]
<strong>
Java is horrible for any real developer to work with.
</strong>
<hr></blockquote>
huh? i'd love to here your definition of a *real developer*.
[quote]
<strong>
but it fails to come close in performance and versitility of other languages.
</strong>
<hr></blockquote>
java may have a restricted application set due to its obvious dependencies, but its versatility within various sets such as app servers, etc is second to none.
am i blind?
<strong>i'm sorry, but a PPC enhanced for Java is the dumbest thing i've ever heard.</strong><hr></blockquote>
If you're really a moderator here on AI, I absolutely refuse to believe that!
[quote]<strong>Unless you want Apple to port all of OS X to java?</strong><hr></blockquote>
No. Making OS X a better platform for Java apps, Java/Cocoa apps, and web services would be more than sufficient.
[quote]<strong>or do you mean in some sort of co-processor functionality? even so, too much cost for a gain that most people would not see. Java is NOT a big issue for most people, save LimeWire.</strong><hr></blockquote>
Consider this from <a href="http://java.sun.com/features/2002/03/mac.osx.html"; target="_blank">Sun's web site</a>:
[quote]<strong>At the 2000 JavaOneSM Developers Conference, Steve Jobs, CEO of Apple Computer, declared the company's intention of making the Macintosh platform "the best Java delivery platform on the planet." And since that time, Apple has been hard at work toward that goal.</strong><hr></blockquote>
I think Apple would really like to see Java take off on the Mac. Maybe for good business reasons. Maybe because Steve knows it would piss Bill off.
Java doesn't have to be "a big issue" to people now to become an important technology for Apple's future. Besides, if the details of how code works are hidden from users as they should be, Java would never be a big issue in users' eyes as long as it kept quietly doing its job, working behind the scenes.
No, I don't know whether or not the idea of a Java-enhanced PowerPC could ever be cost effective. Maybe it can't be... but maybe it can. Like Welcome to Darwin said, Java byte code hardware is already being considered for embedded devices. Why not for a desktop or laptop CPU then?
I know that a D&D character generator known as PCGen runs in Java *and crashes my old P200 if I try and run it* and they make tweaked versions of the program to run better in different operating systems, including X. If they can tweak the program to run better on a specific OS for something, Java, that is supposed to be used on any platform, why not something like what is getting proposed in this thread? Steve obviously wants to advance the language for whatever reason, so why wouldn't he include Java specific features?
Here's a thought for ya. The G5 has been touted in SO many threads on AI as being very modular and you can add specific bits here and not include that, etc so different companies can get the exact chip they want. Why wouldn't Apple be able to produce their own co-proc that gets wrapped up with the rest of the components in the main chip, since everything in the G5 is supposedly modular anyway. Granted, this idea is nearly worthless until we actually HAVE a G5, but hey, I like ideas
<strong>If your problem is the AWT, then all the native CPUs in the world won't help you: it's a design problem (i.e., naïve, expensive event handling system), not a problem of the bytecode interpreter being sluggish. Java that does not use the AWT flies along quite satisfactorily in OS X.</strong><hr></blockquote>
Do you mean all UI, including Swing/JFC?
On a separate note does anyone know how the Cocoa libs compare to the JDK? Does Cocoa include much of the functionality found in java's api's (util/io/xml/i8ln/etc)? After seeing one of WWDC sessions I was a little concerned that Apple is concentrating more on C'based apis than Cocoa. Is there any sense in this fear?
<strong>Here's a thought for ya. The G5 has been touted in SO many threads on AI as being very modular and you can add specific bits here and not include that, etc so different companies can get the exact chip they want. Why wouldn't Apple be able to produce their own co-proc that gets wrapped up with the rest of the components in the main chip, since everything in the G5 is supposedly modular anyway.</strong><hr></blockquote>
I've seen this basic argument thrown around a lot recently and completely ignoring technical issues for a moment there is another important one to face, cost.
What you can do given the funds is really quite amazing. What chip manufacturers have to do though is get their chips out at a reasonable price too.
I believe you would find most chip designers would prefer to spend their budget elsewhere (as would many of the consumers for that matter) and have someone work out a more cost effective solution.
Additional hardware solutions really are meant as last resort or when something is severely taxing and used often (graphics are the obvious example although there are a few others) as they generally don't come too cheap.
[quote]Originally posted by Hagen Kirk:
<strong>Granted, this idea is nearly worthless until we actually HAVE a G5, but hey, I like ideas
Part of any engineering design process is sitting around thinking up ideas of what you'd like to do in the future and can't do already. Often if you are just improving something you already have a lot of the areas of necessary improvement covered.
Still it is easy to overlook good ideas and fall behind if you assume improving what you already do is enough. Always aim to see if you can come up with something you may not have thought up. Something that may have once been tossed out as unfeasible but could now work, something new, anything. Radical improvements are important and they are more often than not born from the thinking up of a great many worthless ideas and what ifs.
Anyway the idea doesn't really do much good once you have finished the project and started to move on. While you are in design stages at least you have something consider. The idea is really worth a lot less once you have the completed product rather than before
[ 07-09-2002: Message edited by: Telomar ]</p>
OK, now you can return to discussing things I don't understand. <img src="confused.gif" border="0">