Posted by
Hemos
on from the it's-new-it's-fast dept.
scode writes: "IBM's has finally
released
a preview of their JDK 1.3 for Linux, and it's just as fast as their 1.1.8!
This is great news for Java on Linux, because it's the first Java 2 compliant Linux JVM that's really fast. "
189 comments
I'm just a love machine...
by
deander2
·
· Score: 1
I think the best way to get java really doing well would be to have compilers ported to individual platforms, as you could get rid of the speed disadvantage. Until that point, java is too slow for anything i'm using it for.
Java as a compiled, system and arch dependant binary?? Fast, sure. But you're eliminating the main reason to use Java: System independance. If you want fast, use something else!
are you saying it's not enough of a language to stand for the merits of that? and besides, you don't need to eliminate the ability to run on multiple platforms to be able to compile it on specific ones
The ability to move a Java program from one platform to the other without having to recompile is overrated. It's not that big a deal to recompile, especially if you know that you don't have to do any system-dependent #defines like you do in C.
I would think that the main reasons to use Java are:
Simplicity
Built-in threading
Garbage collection
A great set of standard libraries
Bounds checking on arrays (really, avoiding the C/C++ pointer overrun problems)
The ability to print a stack trace from an exception (oh how I miss that when I do C++!)
Reflection
I don't see how a compiled, system and arch dependant binary would eliminate any of those reasons.
Of course when you do that, you you're stripping away "compile once run everywhere" and revealing Java for what it really is: a C++ wannabe.
Seriously, I think the idea of having platform independant VMs is cool, but why didn't they just write a VM and a C/C++ compiler for it? With stuff like Bochs out there, who needs Java? All it does is give you yet another codebase in yet another language. Feh!!!.
Sorry. Had to vent somewhere.
-- For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
One of the big advantages of Java now is that the code is truely mobile. Platforms such as Java/RMI and the more elaborate Java/Jini allow not only data but code to be sent over the wire. The 'recompile for every platform' model just doesn't work when you want to ship code as well as data.
Oh, that day is already here. JIT compiling VMs have been around for a while, and processor speeds are at least 4x if not 8x faster than they were when Java was introduced.
But remember Transmeta? Remember that their Crusoe chip, while currently targeted at the x86 market, was also demoed running Java byte code 'natively' (ie doing the code morph thing from Java bytecode to Crusoe internal instructions).
I like Java for apps because its cleaner and easier to debug than C++, and has a whopping great set of (cross platform!) APIs. And for many apps, the speed is already good enough. But I still use C for lower level stuff, and C or C++ if I need to tie in to an existing C library. (Why mess with JNI).
What I've always hoped would happen would be that a class->native code compiler would be shipped with the jdk. That way vendors could ship the platform independent code, and if it wasn't fast enough for you, you could natively compile it yourself. I know the gcj extension to the gcc has something like this, but it wasn't all that far along last I checked.
I really don't understand sun's stubbornness when it comes to the native compilation issue. For applets it makes sense to have that capability, but there really aren't many applications that I choose to use cross-platform anyway. If java could be natively compiled I'd choose it over c++ probably 95% of the time. As it is the startup time is simply too great for my tastes.
First of all, they should change the language syntax itself. I don't know about you, but I've never managed to get a Java program to compile cleanly, so after about 20 minutes I sort of gave up on actually getting anything compiled under Java. I'm not denying that it's powerful, I saw an X client written in Java a while ago - very impressive. However, if the syntax is too taxing for most users, I don't think it has a chance. There just doesn't seem to be any solid, comprehensible documentation available.
The ability to move a Java program from one platform to the other without having to recompile is overrated I humbly suggest that the reason you think this is that you have not seen the future of computers and networks. In the future, bytecode will be flying around from computer to computer - and it will have to run flawlessly wherever it ends up. You could send around source code, I suppose, but you'd still need a rock-solid standard to ensure that source code would compile and run everywhere.
-- First, make it work, then make it right, then make it fast, then, make it bloated!
What I've always hoped would happen would be that a class->native code compiler would be shipped with the jdk.
Um. There is. It's called a VM.:)
For applets it makes sense to have that capability, but there really aren't many applications that I choose to use cross-platform anyway.
Maybe not. I certainly find that I use a lot of applications on non-standard platforms, though. I've been using Argo/UML a lot under Linux recently, for example. Cross-platform binaries make a lot more sense to me than having to use Windows to run this sort of application just because everyone else does.
As it is the startup time is simply too great for my tastes.
<shrug> Compared to a lot of native applications it's not that bad, especially for applications that only load classes as required. Have you tried the newer releases of the Hotspot VM? They're meant to cut down on startup time, since the application is initially interpreted.
-- ++ Say to Elrond "Hello.".
Elrond says "No.". Elrond gives you some lunch.
it's java. if there's one buzzword you gotta know... okay, maybe java isn't it, but it's still pretty useful to know. i'm just glad linux is getting this support for java. it took sun long enough to make a jdk for it.
I haven't downloaded it yet, but I hope native threads can make it in this release. It hurts running my Java apps in Linux while the threads run like they're in Windows 3.1.
Re:Native threads?
by
Anonymous Coward
·
· Score: 2
blackdown's 1.2 uses --native threads. that cant be more than three or four months old.
> > blackdown's 1.2 uses --native threads. > > If you start java with the -native flag, it warns that native threads are not ? supported in this release. > > I haven't had any problems with it though.
That's Sun's JDK which has a very outdated version of our native threads implementation. Try the Blackdown JDK, it uses native threads by default.
No.. Java 2 = Java 1.2 IBM just released Java 1.3... so they're in step.
What about VAJ and Websphere
by
Anonymous Coward
·
· Score: 1
It's nice to have a fast java 2 jvm for linux. But what about VAJ 3.02 (enterprise edition) and websphere 3.02. I still used NT because of this two software:-(... I'm waiting for you IBM guys !
Re:What about VAJ and Websphere
by
sohp
·
· Score: 2
Huh? Keep up! http://www-4.ibm.com/software/ad/vajava/ "VisualAge for Java runs on AIX, Linux, OS/2, OS/390, Windows 95 & Windows 98 and Windows NT."
Re:What about VAJ and Websphere
by
SockPuppet_
·
· Score: 2
VisualAge for Java Professional edition is available for Linux, but not the Enterprise edition. The Professional edition lacks some of IBMs enterprise tools and the ability to connect to a team respository server. That makes it a pain in the ass to use if you're not working alone.
Just in time, i've got a java application to deploy on a new linux server i'm building on friday, and this'll be the JDK for me. Previously i would have used SUN/Blackdown 1.2 with the borland JIT compiler. Heres the servers spec (gloat), AMD Athlon 850 (last one with the pluto 2:5 cache), ABit KA7 motherboard, 4*256 PC100 ECC SDRAM (hey Its a server you got to go for reliable memory over fast memory.) IBM 30Gig 7200rpm ATA66 disk drive, 3Com Etherlink 3 100-Base-T networking card, Voodoo 3 3000 (just goes 3dfx does linux drivers). After testing we'll be using it as part of a server farm (with a lot of the same spec machines) for our search engines, at www.remotesearch.com P.S. Got any good keys for freenet.
Whadaymean off topic. I say what I going use JDK 1.3 for, and where it will be deployed and, you call it off topic. What mores on topic for an application than how and where its going to get used?
Actually, we've got an SUN E450 dual processor machine tith SUN Disk suite RAID 0+1. But for this application we need lots and lots of cheap ECC RAM. The SUN E450 will to all the disk work, while the farm of AMD linux boxes do the in memory and some integer compute work. Plus (and this is the on topic part) theirs no point in multiple processors for linux Java, because their isn't one JDK that supports SMP on linux, and thats with native or green threads.
Re:JDK 1.3
by
Anonymous Coward
·
· Score: 1
any JVM for linux that runs native threads will give each thread a CPU until you run out of CPUs. What did you think the difference between native and green threads was?
Green threads: run in one process. user-level simulated threads.
Native threads: uses pthreads, which on linux maps to clone. each thread is a process, but with the same page tables (shared address space). this will take advantage of multiple CPUs.
Non-x86 Linux users in the dust, as usual
by
Gepard
·
· Score: 4
Good job, IBM. It's wonderful that support is so forthcoming. Though naturally, when someone says ``available for Linux,'' they really mean ``available for Intel Linux.''
Users of all other Alpha Linux are screwed. PowerPC Linux. UltraSPARC Linux.
Oh well, that's the real world, isn't it? It'd be nice if there at least was some source code to play with on other architectures. But that, naturally, isn't forthcoming.
Re:Non-x86 Linux users in the dust, as usual
by
c_chimelis
·
· Score: 1
I agree. I use and develop for Debian's Alpha release of Linux and it's getting horribly irritating how many companies claim to support "Linux" when they really only support Intel-based Linux systems. I've even emailed a few to offer porting help, but to date, I've only received probably two responces (both of which were basically "not interested"). Just goes to show that even in their support of Linux, the almighty dollar and market share motivate these companies more than proliferation of their technology.
Re:Non-x86 Linux users in the dust, as usual
by
rwade
·
· Score: 1
Even though I'm an x86 user (486, more specificly) I'm inclined to agree with you. Can they not pull out a sparc or something and compile, or what?
of course, I'm sure there would be porting or something, I dunno, but anyway, I don't think that the majority should rule _all the time_, even when I'm a part of that majority.
Re:Non-x86 Linux users in the dust, as usual
by
Anonymous Coward
·
· Score: 1
Guys, I understand the sentiment, but releasing a product on ANY version of Linux costs $$$$. No matter how "cool" it would be to release a JDK for Linux/Alpha, I doubt the marketshare is there to make it worth their money. Market share and technology "proliferation" are tied to $$$, not the complaints of 5 or 6 people who may really want it on their cool, but relatively little used platform.
If you would be willing to put up the quarter million dollars it takes to port and test a major peice of code like the 1.3 JDK then I am sure a company like IBM would be pleased to do it for you. If you are not willing to put up this money... why should IBM?
Re:Non-x86 Linux users in the dust, as usual
by
BattyMan
·
· Score: 1
I can't sit still for this, anymore.
The answer goes something like: "Then give us the fscking SOURCE and let us play with porting it _ourselves_!"
IBM wants to make a lot of noise about Linux and supporting Linux : they (and those other guys out there distributing binaries and hurraying that they support Linux) need to understand that the ground rules here are OPEN SOURCE. If you can't give us the SOURCE, do not expect us to take you seriously, you're just another guy trying to rent us (a limited selection of) bits.
-- Exceeding the recommended torque is not recommended.
Re:Non-x86 Linux users in the dust, as usual
by
c_chimelis
·
· Score: 3
The argument about development and testing costs not being justified for little-used port platforms is easily rendered moot by one fact: they're giving this away. Sure, they may base a commercial product on it and, sure, that will cost money to develop and test on every platform/OS combination under the sun, so I could understand limited availability for commercial software. What I object to is that these "freely available" packages (especially JDKs, it seems) are really just a way for companies such as IBM, in this case, to tout their name as "supporting Linux". If they want to save a whole bunch of money on development and testing, give *US* the source and let us do the porting and tinkering that it takes. That's free labour! And would make the "lesser-used" port users happy as well. Also, bear in mind that some of the architectures, while technically in the minority as far as numbers go, are much more powerful and used more as larger scale servers than the often cheesy Intel machines that make up that "large market share". Let's face it, how many Intel-based desktops would it take to run some of the larger sites on the net?
Re:Non-x86 Linux users in the dust, as usual
by
Juergen+Kreileder
·
· Score: 1
They can't give you the source, except under the terms of the supposedly unacceptable Sun Community licence. If you are willing to sign up under Sun's requirements, feel free to join the Blackdown project and work on the Alpha port.
An Alpha guy would be very welcome on the team. Currently we have no Alpha porters, so we will provide Java2 v1.3 only on Intel, PPC, Sparc(64), ARM, MIPS, m68k.
GNU GCC currently ships with a pretty decent Java compiler, that can be used with libgcj in order to write native apps. I have no idea how complete libgcj currently is.
GCJ is slower than IBM's JDK. THis is because IBM's JDK is fucking fast. It depends on your application. gcj is faster for some code, but the IBM JDK is still faster for others (but gcj is improving quickly). There is allways less startup overhead with gcj because It is true that some optimizations can only be made at runtime by a dynamic compiler, however others (due to high computational cost) can only be reasonably be done in a traditional, ahead-of-time compiler. The solution to this and other problems with ahead-of-time java compilers (like TowerJ and gcj) lies in providing a mixed-mode environment, where application code is dynamically loaded and compiled against pre-compiled libraries. If the standard java libraries are precompiled, you avoid a large amount of application startup overhead. But with application code running on a JIT, the advantages of dynamic compilation and the platform-independent bytecode format are maintained.
Just curious: What optimizations can be done at runtime which cannot be done at compiletime? This would imply that the runtime compiler has additional knowledge which is not available at compiletime. I tried to think of some but found none (variable values for example cannot be used for optimization (after all they are _variables_:) and Java doesn't really know "const", "final" is weaker)
There are many of them. To give one for all imagine this:
if cond then some_code else some_code2 endif
Now, imagine that the some_code2 is executed in 99%. This can't be easily found out but it's relatively easy to do it at runtime. Analogously with types and type checking, loops, and garbage collection.
I have an alter-ego at Red Dwarf. Don't remind me that coward.
You've got to be kidding! GNU's Java compiler is completely worthless. Almost nothing except for tiny trivial bits of code will compile with it. It basically only supports language features in Java 1.0, which might be fine, except it doesn't support alot of the libraries that were also released with Java 1.0. So, its not even compliant with code that was written FIVE YEARS AGO!
Yeah, the Sun way of counting, like Solaris 2.7 followed by Solaris 8.
Any guesses what they'll come up with when they feel it's time to change numbering again? The logical next step would be shifting the significant digit further to the left, yielding Java 30 or Solaris 90, wouldn't it?
I have to agree. At the moment I go out of my way to avoid Java. I have a P166, but Java is just too slow by FAR. On a fast computer I think it has it's place, but for people who like to stay back from the technological curve, if only so everything they have is supported in Linux, Java is unusable right now. I regularly have to use a java program (the only one thankfully) and when you click on a button, it can take upward of ten seconds before the action actually does anything.
Of course Java does have the one benefit of being ostensibly platform independent. I mean you can't say everyone should move to C, C++, whatever, because there is nothing to currently compete with Java. Maybe if something appears in competition the way it works may be optimized.
Very cool, very cool... The Blackdown 1.2 JDK runs JBuilder3.5 ass slow (not that I don't appreciate it guys... it's far better then most Mac support I've seen) It will be good to have something all super-quick like IBMs 1.1.8 JDK. Right on, you guys rock!
The IBM JDK is an implementation of Java Platform 2 version 1.3. This is the absolute latest spec, and is so new that the SUN JDK hasn't been released in FCS format yet.
JDK 1.2 was re-named Java Platform 2 as part of the re-arrangement of the Enterprise, Standard and Micro editions. See SUN's Java site for more information on this, and the differences between the versions.
IBM are definitely at the head of the queue for this one !
I'm looking forward to being able to use some critical Java Platform 2 features, and remember this is the enabling technology for Enterprise Java Beans...
As a programmer, one thing Java is lacking is hardware acceleration of windowing widgets.
In any OS worth mentioning standard windowing calls (such as pulling down a menu or pushing a button) make specific calls to the video hardware. Sun's JVM, however, does not accelerate swing components, relying instead on your CPU to draw them.
There is no reason the VM cannot make calls to specific hardware, as we all know they're written for specific platforms. In fact, I am told that the VMs for Sun's OS ARE accelerated. This is either just plain lazyness on their part, or a ploy to increase the popularity of their OS.
"Hey, buddy. You like that Swing Office Suite? Well, it runs 30% faster on a Sun workstation..."
Re:Java as a user interface
by
Blue+Lang
·
· Score: 2
There is no reason the VM cannot make calls to specific hardware, as we all know they're written for specific platforms.
1) Do it and post the code.
2) No, not all VMs are written for a single platform. Most people, when writing a unix VM, would probably consider adding hw accelleration too much overheard, especially given the fact that java compliance is such a moving target.
3) Sun's optimizing the swing widget compilation for sun boxes is not laziness - are they really supposed to also support non-sun gfx adaptors? That's a massive undertaking.
4) I agree with you, non-optimized gui elements are one of my favorite things to taunt our java monkies with.
-- blue
-- i browse at -1 because they're funnier than you are.
Re:Java as a user interface
by
spotter
·
· Score: 1
ACtually, (at least in Windows) java is accelerated in the graphics dept. a bit as I remember reading that it's underlying implementation relied on DirectX calls.
Re:Java as a user interface
by
deander2
·
· Score: 2
To clarify: By hardware accelerated, I did not mean the gfx card knows what a widget is. However, it does know what a rectangle is, what alpha-transparancy is, how to write one graphic over another, how to copy a rectangle from one location to another, etc. It can do manipulations and transformations like these MUCH faster than your CPU, just like it can draw triangles faster too.
Noone has asked Sun to support non-Sun gfx adapters. All I'm asking is that they support standard APIs. When you write an app, you write to the standard APIs, not to the gfx card itself.
Swing is built on AWT, and in Sun's JVM AWT components are drawn without using any of the (much faster) windowing APIs.
If you want a demonstration of the differences hardware accelerated 2D can make (we have had it so long people forget it's there), change your resolution to 640x480 and play around. Then uninstall your video drivers and play around. Pay particular attention to standard window drawing, pulling down menus, etc. See the difference?
Re:Java as a user interface
by
blurred
·
· Score: 1
There is one flaw in your argumentation: make specific calls to the video hardware. Who could possibly write the code for every possible VGA adaptor in use?
Sun Workstations use a very limited set of video adaptors, so it is quite easy for Sun to program the SolarisVM to make maximum use of the available hardware.
I would say that even the VM for Solaris/Intel x86 does not use optimizations, they would face the same problem as the Linux or others.
Oops, right, so it was 2.6 -> 7, still a funny way of counting.
IBM Native Threads implementation inefficient
by
Leghk
·
· Score: 5
Although IBM's 1.1.8 JDK was by far the fasted VM available for linux [aside from native compiling towerJ] it's native threads' implementation was not nearly as efficient as Blackdown's. IBM uses a mixed-mode JIT, which ends up ( in my experience) considerably faster then even Inprise's JIT plugged into Blackdown's VM for single thread loads. However, under heavy multi-thread loads, IBM's VM acctually underperforms blackdown's vm considerably. You can tell their threads implementation is a bit "funny" because when a system running the IBM JRE is under heavy load, the entire system becomes unusable, --even if the load average is only nearing 2. The mouse becomes extreemly jerky in X, console commands take 3-5 seconds to execute, all this with 5 active threads. Verses with blackdown's VM I've had 40 active running threads, and the rest of the applications run just as responsivly as you would expect linux to. I suspect IBM did a bit of cheating, and toyed iwth the priority threads were being issued, such that IBM VM threads end up being the highest priority to run. This gives them a bit of an edge when it comes to single threaded benchmarking; but once the IBM VM threads start competing against eachother.. it all falls to bits. I wonder if they'll fix that in 1.3.
Here's a chart of the results I used to make my previous assertions. Although I don't have results for #'s of threads below 10, you can see the trend that as the number of threads goes down, IBM's VM gets faster.
I know from experience that IBM's VM wins beats Blackdown+Inprise JIT in single thread competitions. The chart is here and measures the number of milliseconds response time of a Java servlet.
For a good report on how different JVMs scale (the new IBM 1.3 JVM for Linux isn't included, as this report dates from the end of March, 2000), check out: http://www.volano.com/report.html.
The volano report does not include Sun or Blackdown's Native threads JVM. It includes their GREEN threads JVM. I've talked to the person who runs the volano benchmarks; and they don't include native threads on linux [IBM being the exception] because the linux kernel does not support >256 light weight processes.
They have several patches which they used for benchmarking the IBM VM to allow greater then 256 native threads on a linux kernel. Unfortunatly they don't do those patches with any other VM under linux. TowerJ, the highest performer on their benchmark, does not use native threads.
The volano report is not REALLY a good mark of how fast a JVM will perform. -Usually- you're not running 4000 concurrent threads idle threads. Usually you have a few worker threads, and a few idle ones.
It's also quite sad to see that the Microsoft VM whips Linux's JVM's up and down the street, and both sides [on that report]. TowerJ being the exception; but that's not exactly a JVM.
Just ran some benchmarks, looks like some solid progress on the IBM JVM under threadload. IBM's JVM is now runs just short of TowerJ's performance. If you're not familure with TowerJ, it's a commerical piece of software which given a set of java class files, turns them into C++ code. Then runs GCC over them, producing a native binary. TowerJ [specifically on Linux] is currently ranked in the top slot on the Volano Benchmark. TowerJ under linux even beats TowerJ under NT; apparently in the words of the TowerJ engineers, the linux libraries are just more efficient:)
You can view a JVM graph here of the various Linux JVMs under load. As you can see the old IBM JVM didn't fair very well under threadload, regardless that it generally ran faster for single threaded applications. Good work IBM!
Volano, the experts tell me, is also is really just a messaging benchmark. Thats accurate for some kinds of apps but hardly all or even necessarily a majority. In re TowerJ. Again, this is second hand, but I am told it has a huge number of tweaking knobs. I'd like to know if this is performance runnign "vanilla" or after intensive tweking for this particualr bench mark. If the latter you have to ask how much this really differs from benchmark 'spoofing", which most of us I think agree is out-of-bounds. Finally, and I repeat this often, in the end any synthetic benchmark tells you at best how that system runs that particular synthetic benchmark. A spread of benchamrks is better. A spread of benchamrks on a spread of ahrdware is better still. But the only REAL test of how your app will perform under a given VM or other execution environment is your app. "There are three kinds of lies: Lies, Damn Lies, and Benchmarks" --- me, paraphrasing Mark Twain, whenever I give talks
You may find this article interesting. IBM's run some tests on the Linux scheduler using their 1.1.8 JVM, and proposed some patches to the kernel so that performance under heavy loads would raise.
...yet there is method in it. Solaris 7 == Solaris 2.7 Java 2 == Java 1.2
Re:Though this be madness...
by
MayToo
·
· Score: 1
Yeah, and with all those numbers, it's so easy to forget one and have JDK 1.3, which still is Java 2. What a clever way to show us how meaningless numbers are.
no, I merely wanted to start a lively string and possibly get some karma.
I also wanted to see if I should think otherwise or if I wasn't alone in my thoughts about java.
Seemless integration of Java with native Linux GUI
by
Andy+Cole
·
· Score: 1
Does this release go any way as to bridge the gap between the native GUI and applets which are being run under the JVM? I'm not expecting full support for all the features KDE/Gnome/whatever provide, just the option of using the Widgets from the relavent toolkits, hence inheriting Theme support and the like.
I can only wish I could use this...
by
phlake
·
· Score: 1
...but Oracle lacks support for anything beyond Blackdown's 1.1.8. I've tried it and it breaks. Badly. Woe is me.
Still, it's great news for other Linux Java developers, I'm sure, and it makes me glad to know that Win/Solaris aren't the only ones anymore.
When will Apple catch up? They still don't have a Java 2 JVM yet. MacOS X will bring that, true, but have they even begun work on a 1.3 JDK?
Re:I can only wish I could use this...
by
Mad+Browser
·
· Score: 1
I've read that MacOS X may contain 1.3 from the get-go.
Re:I can only wish I could use this...
by
Kingpin
·
· Score: 1
Oracle? In what context? For installation, use the JVM Oracle ships with, for JDBC, just download the appropriate classes.
-- Unable to read configuration file '/bigassraid/htdig//conf/14229.conf'
Geocrawler error message.
Lightweight vs. Heavyweight components
by
Wesley+Felter
·
· Score: 3
This whole debate has been gone over again and again. If you want your components implemented in native code and hardware accelerated, use AWT. If you want really flexible components that look pixel-identical on every platform and have all kinds of cool features that your graphics card can't accelerate, use Swing.
And what's wrong with Sun making a fast VM for Solaris? There's nothing stopping you from joining the Blackdown project and doing the same for Linux.
Re:Lightweight vs. Heavyweight components
by
acroyear
·
· Score: 1
that look pixel-identical on every platform
Don't think they'll be "pixel identical". You've no idea how often I see code that hard-codes the layouts to fixed pixel sizes (rather than use layout managers) that look ugly as hell 'cause on a different platform the fonts are different sizes.
And what's "accelerated" in AWT? Nothing can be done in AWT that the hardware can really take advantage of. Graphics cards are unaware of "windows" (in the Windows or X sense) as far as I know. The only exception are 3D cards, and you need Java3D to get acceleration out of them.
As for basic drawing, well the "Graphics" object is the same, regardless of whether you're doing Swing or AWT (its an AWT object), and its a Graphics2D object. If the VM implementation uses hardware acceleration for that, cool. You'll get the benefits regardless. In fact, if it IS accelerated, Swing may be faster than AWT.
--
"But remember, most lynch mobs aren't this nice." (H.Simpson)
-- Joe
Re:Lightweight vs. Heavyweight components
by
acroyear
·
· Score: 1
Ok, I hadn't read the earlier comment (it was below my threashold) about In any OS worth mentioning standard windowing calls (such as pulling down a menu or pushing a button) make specific calls to the video hardware. Sun's JVM, however, does not accelerate swing components, relying instead on your CPU to draw them.
It can't accelerate Swing, since Swing is 100% java. Its translated to Graphics object calls, which translate to graphics primitives in Windows or Xlib.
And since when did hardware video cards actually become "Component aware" of things like menus, pushbuttons, etc. X has NEVER had that as far as I know (not in Solaris, not in SGI, certainly not in XFree). Widgets in Xt/Motif are 100% implemented in Xlib calls. The port of X to the platform can take some advantage of hardware for graphics and images, but beyond that, the hardware has no idea what "Xt" or "Motif" are. The X Server doesn't either. Go look at the X11 protocol.
Optimization of GUIs usually involves buffering, particularly of pixmaps and colormaps. Or, it involves improvements like Low Bandwidth X, the Shared Memory extension (where the network aspect of the X protocol is removed, and the client basically sends the protocol to the server through shared memory), or direct x (no relation to microsofts DirectX), where Xlib directly draws onto the screen rather than telling the server to draw.
If graphics cards for the PC platform actually have an awareness of "push button", i would be severely suprised. "Specific calls" for a push button are "fill this rectangle, now draw these 4 lines and this string in this color... ok, now fill the rectangle in a different color, draw these same 4 lines in a different color, and redraw the string." Oh, gee, that can really benefit from hardware acceleration?
--
"But remember, most lynch mobs aren't this nice." (H.Simpson)
-- Joe
Re:Lightweight vs. Heavyweight components
by
acroyear
·
· Score: 1
No, you have no idea what you're talking about. "Native" widgets in the X implementations are 100% "client" side (given X's ass-backwards client/server definitions). They are implemented (in Xt, and for that matter, in Gtk or Qt) 100% through Xlib (or X extension) calls. Xlib has optimizations for a lot of features like direct to screen drawing and/or non-network communication, but no X server (and no X graphics card) knows anything more than that. Those that do are often 3D aware, and get acceleration when doing 3D work (or using GL "widgets"), but that's GL, and no X server implementation uses GL for simple 2D primitives.
"Native" widgets in Windows? Like I said, if graphics cards are now so MS friendly as to do 70% of Windows' work for Microsoft, I'm getting out of the software business and will go take up modern dance. Name a graphics card that knows what a "pull down menu is". I really would like to see it...and see if its spec is open enough to use it.
If "component-aware" graphics cards have existed, then a new graphics system for Linux aught to be started to take advantage of it (with the first application built on it being an X server, so backwards compatability remains).
The most "component aware" graphics cards can get is hardware buffering (using the graphics cards memory to cache, which reduces the amount of screen redraws). But it still takes the application developer to choose to use it. MFC may be built in such a way as to do that, but that's MS doing the work, not the graphics card. Yes, that would make "native" faster, but not for the reasons you think. In X, its the double-buffering extension, though its never been stable enough for me to bother to use it, at least back in X11R5 days.
--
"But remember, most lynch mobs aren't this nice." (H.Simpson)
-- Joe
Re:Lightweight vs. Heavyweight components
by
spitzak
·
· Score: 1
AWT uses native widgets, so they ARE hardware accelerated, since windows video cards optimize for the common widgets.
I'm sorry, but it is you that have no clue. The widgets have been dissected down to rectangles and lines and characters long before they reach the hardware. This in on Win32 and X, and probably every other modern system in existence.
In fact it can be easily shown that a window drawn using simple Win32 GDI calls (like fill rectangle) that looks identical to one drawn with Win32 API widgets will update much faster.
Client side java isn't the only Java
by
ry4an
·
· Score: 1
Java on web pages was a stupid, stupid idea. Java as a non-GUI, server side solution is a viable idea. Just because org.lame.StupidApplet is slow in your browser is no reason to count out a nice language.
Re:Client side java isn't the only Java
by
Eric+Gibson
·
· Score: 1
Java on web pages was a stupid, stupid idea. Java as a non-GUI, server side solution is a viable idea. Just because org.lame.StupidApplet is slow in your browser is no reason to count out a nice language.
I've still noticed that sites using jsp are still slightly sluggish when compared to other types of server side (insert internet service here) applications. I know, I know it also depends on the programmer and the jre, but I'd say it's usually a good bet that it will suck...
I'm sure there are good java apps, I've just never seen one.
Re:Client side java isn't the only Java
by
spiro_killglance
·
· Score: 1
Well i wouldn't put quake in Java applet, but their is plenty your can do in one. I consider a Java applet as a program running on computer 5 years behind the state of the art. Put thats ok theirs still plenty of stuff you can do with that. The coolest java applet i've seen was a complete ZX Spectrum 48K emulator on a web page. I got quite a way with designing a gaunlet style game in Java, before giving it up for more serious stuff. Its still around at http://194.201.87.84/ if anyone wants a look. Ok the graphics were lame, i'm a programmer not a graphic designer.
Re:Client side java isn't the only Java
by
FalseConsciousness
·
· Score: 1
I've still noticed that sites using jsp are still slightly sluggish when compared to other types of server side (insert internet service here) applications. I know, I know it also depends on the programmer and the jre, but I'd say it's usually a good bet that it will suck
JSP/ASP/CFM/PHP - different implementations of a fundamentally flawed concept, embedding logic within presentation. However, putting that complaint away for a minute...
JSP can be slow, yes. This is mainly because of the two-step that happens when you access a JSP file: first the server compiles it as a servlet, then it serves the output of the servlet. Predictably, this tends to suck performance-wise, although the performance of the most popular JSP engines seems worlds better now than a year ago, and hopefully will continue to improve.
On the other hand, I have seen performance from compiled servlets (not jsp) both on big-ass proprietary app servers and on low-end servlet engines that is subjectively at least pretty impressive. I say subjectively because I don't have any benchmarks at hand.
Server-side Java is much wider than JSP, and has been around much longer. Just look at the commercial development/app-server products that use Java as the development language. Hopefully with Jserv, Tomcat, and other projects becoming more mature we will have a good set of options for server-side Java that don't involve paying server tax to a vendor who is trying to lock you in for the life of your project.
Besides performance, there is the benefit of better maintainability using Java, and the benefit of all of those CS/tech school grads who learned Java over the past couple of years. In a recent round of interviews, I was astonished to see no less than 100% of our candidates had learned Java _first_, before being taught C/C++/VB. I'm old - so very old...
Re:Client side java isn't the only Java
by
blue+trane
·
· Score: 1
JSP can be slow, yes. This is mainly because of the two-step that happens when you access a JSP file: first the server compiles it as a servlet, then it serves the output of the servlet. Predictably, this tends to suck performance-wise, although the performance of the most popular JSP engines seems worlds better now than a year ago, and hopefully will continue to improve.
The compilation of JSP into a servlet should only take place once, when the JSP script is called for the first time. Any subsequent calls use the already-compiled servlet (until the JSP script is modified, or the web server is rebooted...)
Re:Client side java isn't the only Java
by
JohnnyCannuk
·
· Score: 2
Properly designed JSP/ASP/CFM/PHP should not have program logic in the presentation. But this is a problem of the coder and designer not of the technology. The JSP/ASP/CFM/PHP hold the presentation logic and compoments like servlets/Beans/EJBs/COM components/CORBA Orbs etc do all the aplication specific work. I've done this with both JSP and ASP (I like JSP better). Down on the farm, we call this MVC or even n-tier achetecture. Perhaps you've heard of it?
BTW, JSP performacne hits you speak of only happen on the first instance. All subsequent requests go to the already compiled servlet. I believe in some application servers (IBM WebSphere for instance) you can configure the JSP to be compiled on start up, so the user will neer see the performance hit, even if they are the first to hit the page.
-- Never by hatred has hatred been appeased, only by kindness - the Buddha
Well, I'm glad to see they did release a 1.3 compiler, but whatever happened to a 1.2 compiler? I think IBM's getting version-skipping happy. Not that I'm complaining, just curious.
Thanks to IBM, it may one day be reasonable to run Java Servlets/JSP's for a web page;)
No IBM isn't doing any funny business. They actually did skip 1.2.x and have now released a 1.3, a version still officially in Early Release at Sun. Oh and a nit: it's not the compiler really, it's the jvm, associated libraries and the other tools (like javadoc). You can still use jikes (rocks!) with 1.2.x or 1.3 same was with 1.1.x because the byte codes are still the same.
Java for Mozilla?
by
Anonymous Coward
·
· Score: 1
This is cool and all, but what I want to know is when Mozilla for Linux will ever get Java support. Apparently nobody's come in with a JVM to drop in, and Sun's been pretty silent about whether they will provide one or not for Linux...
surak_at_my-deja.com, using Mozilla build 2000050308 without a clue about whether it will crash when he attempts to post this comment.
Hello.  .If you are looking for Java support for Mozilla, visit this page.
You can also check out the Mozilla home page for additional information and the rationale for the decision to only specify a Java interface for Mozilla.
--
-- "You're gonna need a bigger boat."
- Chief Brody
90 Day Trial License Agreement
by
Wedman
·
· Score: 1
From the License Agreement:
2. Term and Termination
This Agreement will terminate ninety (90) days after the date on which you receive the Software. Upon such termination you will delete or destroy all copies of the Software.
Darn. I'd better delete my copy on day 89... ...just to be safe
Or better yet - maybe I just won't download it at all.
I notice that you've failed to mention the obvious requirements of a _real_ server: - redundant disk drives (ie. RAID) - redundant power supplies - multiple network cards and adapter teaming - multiple processors - tape backup Also, if you're going to deploy this wonderful app of yours on a brand new JVM without testing, you are crazy. It doesn't sound to me like you've ever seen a real server...
How long before the flame wars start?
by
Pentagram
·
· Score: 1
By the time I've posted this, I bet there'll be half a dozen posts saying that Java is crap, Java is slow, moan, groan, Java can't be used for low-level system programming etc. Oh well, if you can't beat them, join them... Java is great, it'll replace C for all high level programs:)
Seriously, I wonder how much of the opposition to Java from many C programmers is due to the amount of experience they've accumulated in C? It's bound to make people resentful [disclaimer: I've spent the last 18 months learning Java in university]
Re:How long before the flame wars start?
by
SlashParadox
·
· Score: 1
Of course people are reluctant to change.
It would seem that now, with the rate at which things are changing, people would welcome change, but the fact is, no one wants to spend time learning how to do something just to find out that something new has come out which can replace the thing that they already know.
It makes them feel like they have wasted their time learning C. Personally, I would hate to have to start over and learn a new language when I was comfortably entrenched within my knowledge.
-- No time for.sig, Dr. Jones!
Re:How long before the flame wars start?
by
harmonica
·
· Score: 2
. "anywhere" is now defined as Windows and Solaris (note: Windows first!).
True, Sun only releases JDK's for Win32, Solaris and Linux. But there are tons of JDK's by other enterprises, e.g. for HP-UX, Digital's Unix, Irix etc., most of them 1.2. They get used but nobody makes a lot of noise about it.
As I said earlier, I like Java *as a language*. It would be nice if someone (*ghm* Sun?) released a Java-like language that actually compiles to native binaries (i.e. getting rid of this jvm junk). But Sun has a different agenda...
There are Java source/bytecode-to-native code compilers. You'll get the speed there. On JVM, it has other advantages as pointed out by others (dynamically creating machine code that is suitable for the CPU found at startup, the sandbox principle etc.).
So, if you're that much into CS, try doing some background research on what exists and why it exists. You're right about the Java/university thing, though.
Re:How long before the flame wars start?
by
catseye_95051
·
· Score: 1
The most funny/ironic thing about all of this is..... I've heard it all before.
I was one of the early adopters of C++ and the verbage was virtually identical, compelte with all the empty flame wars.
If you had told me 10 years ago that the time would come when people talked about C and C++ in the same breath when it came to performance I would have said you were at elast over-optimistic, if not outright nuts.
The problem in the beginning was that people didn't udnerstand C++ and were trying to write C code in it. The problem now is that people don't understand Java and try to write C++ code in it.
Having learned from the past, I know now with certainty that the time will come when people say, "But will NEVER be as fast as C++/Java!"
And they'll be wrong again. Thsoe who do not study history are doomed to repeat it.
Re:How long before the flame wars start?
by
catseye_95051
·
· Score: 1
Having come from the game industry, I'll defend a certain degree of conservatism (but only a certain degree.)
Game programers are very slow to adopt new technology. Thsi makes sense for them. They are generally on extremely (one might say rediculously) short schedules with minimal resources. They have barely enough time to apply what they do know to the problem and, shoudl the proejct fail, they generally get sacked -- no matter WHOSE fault or faults it was.
Game programmers need to be really sure that doing soemthing new is going to pay off immediately. They may not be the only oens in this position.
Now what is dumb, and shows a lesser enginner at work, is to say "it CAN'T be better then waht I already know." Being defensive just gaurantees you'll be otu of work eventually because all technolgoies age and are replaced. (I remember the fight over C... where are the pure assembly code game programmers now???)
My point is, as an engineer its perfectly reasonable to be cautious, its perosnally dangerous though to be willfully blind.
Re:How long before the flame wars start?
by
JohnnyCannuk
·
· Score: 2
Wow, somebody has a pickle up their ass about being in CS! (how snobbish).
I "learned" java in the real world by using it almost every day for applications. Your right - Java is not C nor is it C++. But have you ever heard of "the right tool for the right job"?
C/C++ is great for lower level code, device drivers or embedded systems. Java is excellent on the server as a replacement for CGI (ever heard of servlets/JSP? that's where all the action is these days - and its faster and less resource intensive than CGI). Any other software depends on what your creating and for whom.
Your right that Java is slow RIGHT NOW. But the same was said of C++ 10 years ago. I don't hear too many complaints about the speed of C++. Would I write a Word Processor in Java? Hell no, not until the JVM/JIT stuff gets way faster (although 1.3 is very quick, even with Swing). In C? Sure if I had a team of programmers and a couple of years...C++ would probably be a better choice.
Have you actually tried any 1.3 JDK implementations? I have and I find them way faster than anything previously created, almost as fast as C++ (even in GUI apps). Do you realize that written properly (eg NOT like a C/C++ program), with the proper patterns and optimizations, Java can be quite peppy?
Aparently not.
Before you slag a language or platform, try getting more knowledge than " 2 tutorials in the beginning of the semester that covered Java syntax and constructs" from an old CS prof would would rather write in Assembler or Fortran anyway. Follow your own advice and become informed by true experts in the field.
Does java have its problems? Sure..it nees better JVMs/JIT for better speed and STANDARDIZATION!(are you listening SUN?). That doesn't mean its not a viable development platform for the real world...and its getting better all the time.
BTW. In Java, multiple inheritance is done with little things known as interfaces...but I digress.
-- Never by hatred has hatred been appeased, only by kindness - the Buddha
Well, Java is a proprietary and Mozilla is fully open source and Sun is a bit antsy about opensourcing Java. I've heard about some projects to reverse engineer Java, but mozilla is a corp. entity and they tend to get a bit antsy with legal issues...so...:(
Well, Java is a proprietary and Mozilla is fully open source and Sun is a bit antsy about opensourcing Java. I've heard about some projects to reverse engineer Java, but mozilla is a corp. entity and they tend to get a bit antsy with legal issues...so...:(
Not an issue. Mozilla will (and does on Win32) support OJI, an API for hooking up JVMs; any free (or open source, ick) JVM could be modified to use plug right in. A JVM does not have to have source available for it to use OJI.
In fact, it would be to Sun's advantage for their JVM to support OJI on all platforms, as the presence of Mozilla on those same platform would give it an immediate application.
Re:Seemless integration of Java with native Linux
by
Wesley+Felter
·
· Score: 1
I this this would be useful, too, but I don't see many people working on Gtk+ or Qt lookalike PLAFs for Swing. A notable exception is the Skin Look & Feel, but it doesn't seem to be progressing very quickly.
JFC(Swing) does not use native peers.
by
Joseph+Vigneau
·
· Score: 1
The Java Foundation Classes, better known as Swing, are 'lightweight': They don't use the underlying GUIs' widgets.
Swing does however support 'look-n-feel' classes, and Sun ships looks and feels for Windows, Motif, and 'Metal' (which is the most aesthetically pleasing, IMNSHO). O've also seen a decent BeOS LnF. Theoretically, you can write a look-n-feel that knows how to use the same pixmap sources the KDE/Gnome/whatever themes. That exercise is left to the reader:^)
Re:JFC(Swing) does not use native peers.
by
acroyear
·
· Score: 1
Fred Lavigne (http://fred.lavigne.com/) has written a Swing Look And Feel class that uses gtk themes. Its not perfect, but it works.
He also has some code (independent of that) that implements some GTK/Gnome features in java.
Unfortunately, the site isn't coming up in my DNS right now...but look up SkinLF on freshmeat. I wrote some code on top of that which will look at the local.gtkrc file and load up the default gtk theme.
--
"But remember, most lynch mobs aren't this nice." (H.Simpson)
-- Joe
Kudos to IBM for providing this environment (even if it expires after 90 days). Note: also thanks to the Blackdown team who have done an excellent job in less than excellent conditions to provide excellent tools that I rely on now.
A note on Java: This is actually a huge boon for Linux. Look at it this way...Linux provides an excellent (cheap and stable) platform on which to develop Java applications. I'm not talking about applets here...I'm talking about large / distributed software systems. I'm building one in a research setting right now using CORBA that's up to 40 KLOC.
I develop entirely on Linux using XEmacs, CVS, and make. For everyone who argues that there isn't a good Java development environment for Linux (article seen recently on ZDNet), that talk is for the birds. These are perfectly good tools that have been proven in the trenches writing code for the guts of the internet, UNIX, C/C++, and thousands of other packages / programs. If you want an environment that handles drag & drop JavaBeans, servlets, etc, go buy a fast box with 256 MB memory and JBuilder. The tool works just fine...just put the horsepower behind it. This isn't to say that XEmacs could be useful for the average Joe programmer (VB developers-come-Java programmers). It does take some tinkering, but there are good develoment environments out there. Anyway, what does a good environment provide you that you can't accomplish with a shell, some scripts, and syntax highlighting. Nothing as far as I've seen except bulk, sluggishness, and programmers who don't understand the fundamentals of development and rely on the tools to find their problems (a poor way to program).
Linux provides a great platform for this kind of development, though, and the gains realized are immense. I can run my object servers spread across the network and virtually guarantee that my clients can run on Mac, Solaris, Linux, and even Microsoft as long as the appropriate Java runtime is installed. Remember, this is an application not an applet! The Swing toolkit is slow and has a huge memory footprint, granted, but there are also some fabulous Swing tools out there (NoMagic MagicDraw UML comes to mind).
I'm not getting religious here; I use Perl, Tcl/Tk, and C/C++ when appropriate. All I'm saying is that Java has its place, and a great toolkit like this one from IBM goes a long way to advancing the Java development capabilities of software developers who won't pay for SPARCs or Windows and want a customizable, robust, and fast environment.
So, knock off the hatred of Java, find some good development tools, and use it for what it's good for (use Flash for providing animations in web browsers), as a full featured applications development language with thorough APIs. It's not perfect, but it has its place in a development toolkit.
Yeah, that's a great extra for (X)Emacs. He's doing some great stuff to integrate Java and the shell, and I've got it installed on my box...
Sorry for forgetting to mention it...I highly recommend it for anyone that is interested in Java on UNIX. You'll also learn a ton about Emacs customization in the process (very useful).
I just started to use JDE a few days ago and so far I'm very happy with it. I was using JBuilder before, and it worked fine for projects with less than 20 java files. However, when I started to use it with a project that had 200+ java files, it got to be really slow and bloated. JBuilder would constantly swell to 100+ MB:(. If we could just get the bloat and performance issues of swing solved, we would have a really really good platform. I love the fact that the software that I write runs in windows and linux without recompiling (okay I'm kind of rambling here...) But anyway I agree that JDE is a really nice enviornment for Linux java development.
Let's hope that this IBM JDK is as good as (or better than) the previous!
caveat: whoever said HTML needs rant tags is indeed a wise man:
uh huh...
why is this moderated "funny"? frink's got some good points..
professor frink, he'll make you laugh, _he'll make you THINK_!
"Ha ha, he doesn't rule out any language other than Perl... HE'S FUNNY!!! I'm so narrow minded I think one language is the answer to all problems!"
My tolerance for Slashdot grows smaller by the second.
Where are the java applications?
by
richie123
·
· Score: 1
Is it just me, or are the only java applications are development tools. Where are the java applications that were supposed to tranform the computer industry it's been five years now.
Re:Where are the java applications?
by
yamla
·
· Score: 1
They exist, you just can't see the majority of them because they are servlets. And there are a fair number of them out there. I've used Perl and Java on the server side and much as I love Perl, I prefer Java for most tasks like hooking up to a database. Sure, Java is lacking the text parsing that Perl has but I only occasionally miss that.
As to where Java is for applets, that's a pretty sorry state. Java support in browsers is pitiful. On top of that, caching classes is a real pain in the ass, resulting in huge downloads (often over 100K, killer for 56k modems) for applets. This is not just Microsoft's fault, either. Netscape dropped the ball and Sun wasn't much better.
Anyone know if the Sun Java plug-in is usable now? I used it back in the 1.0 and 1.1 and it actually didn't work on over half the Windows boxes I tried it on.
--
Oceania has always been at war with Eastasia.
Re:Where are the java applications?
by
catseye_95051
·
· Score: 2
Lots, Im sure if you did a net search you'ld find them.
The "Who wants to be a millionare" computer game I am told is a pure Java application. This is a shipping full featured shrink-wrapped product-- not an applet.
Similarly I just came across a pure Java accounting program today. (Secure-somebody. I have the information at work.)
Ofcourse we have things like WebLogics EJB applciation serevr which is written in Java. In short there are a ton of em.
You just need to look for em. If you really want to fnd them, I'd start by lookign at the archives of the Java Lobby (www.javalobby.com)
Re:Where are the java applications?
by
macpeep
·
· Score: 1
They are in the same place as the hugely popular Perl applications.
Java = Language + RTL + VM / compiler
by
harmonica
·
· Score: 2
As some of the postings throw everything together, there is 1) Java the OOP language, there is 2) the huge runtime library of classes and 3) there is the virtual machine that interprets the byte code OR the compiler that creates a native executable from either bytecode or source code.
So, if speed is a problem, try compiling into a native executable. What's new (compared to C, as an example) is the fact that no platform-dependent problems will arise when programming, so you don't have to do a thousand ifdef checks to see how large an int variable is. If it wasn't for these nasty problems, C would also be a great platform-independent programming language (well, not great:-)).
The RTL is a huge plus IMHO - all basic stuff is already there and it works.
Re:Java = Language + RTL + VM / compiler
by
mikpos
·
· Score: 1
Your example of Java vs C is a poor one. If your code depends on a certain data type (e.g. int) being of a certain size, it is wrong. It is just plain wrong. There has never been and there never will be a situation where assuming the size of any data type is considered acceptable. Problems do arise when sending data across a network or disk, but these are easily overcome, especially when used in conjunction with an already written library. Even in this situation though, where problems with alignment, data type sizes, and endianness are large, there is never reason to assume anything. The problem can be overcome, and has been overcome uncountable times, using ISO C.
What Java does offer that C doesn't (besides garbage collection, dynamic type checking, syntactic sugar, etc.) is a standard graphics/toolkit library. The myriad of C graphics/toolkit libraries is annoying, and swing and awt and whatever else Java has simplifies that greatly. This has its drawback, though.
Relatively speaking, Java is horridly unportable. There are Java implementations for what, maybe a dozen platforms? Probably less. The added standards of pixel graphics capabilities make it more difficult to create new implementations, too. Try making a Java implementation for the PDP-8 or the ENIAC. It might not even be possible. The example may seem trivial, but this means that it would be pretty difficult to run a Java program using awt in an embedded system without a screen or any input devices whatsoever.
Java is fine for some things (or so I'm told), but it cannot be considered portable when considered to the majority of languages out there. C is arguably the most portable language on the planet, and it will probably remain that way for many decades. If there are any portability problems with a C program it is because the code is either wrong, or it is not standard C. Usually it's a mixture of both, but case number one is alarmingly common. It pains me to see "size of int... 4" in configure scripts. There is no excuse for that.
Re:Java = Language + RTL + VM / compiler
by
harmonica
·
· Score: 2
The problem can be overcome, and has been overcome uncountable times, using ISO C.
Of course these problems are avoidable, but practice shows that all errors that a language allows you to be done will be done by someone, even if every good book on software engineering tells you not to.
The example may have been a poor one, but it's something everybody probably has seen in some ugly code snippet.
On the portability issue, I'm not sure how difficult it is to create a new VM / compiler. I guess it depends on how much the new platform differs from the other ones. Is it easier to create a Unix XY port if you already have a VM for Unix YZ? I would say so, but I don't know exactly, maybe one of the Blackdown people can answer this (some of them are reading slashdot comments on Java IIRC).
Sun has defined three different Java editions, including a micro edition, to address the problem of embedded systems and handheld devices. The micro edition only includes a subset of the functionality of the standard or enterprise edition. A description can be found on Sun's website.
On the number of platforms for which there are compilers and virtual machines, there are many. Kaffe alone has more than 30 OS / processor combinations supported.
Also take a look at this list of compilers and virtual machines, there are VM's and compilers for all kinds of systems. But for the older and more exotic systems the porting of a VM / compiler may not be worth the effort. Maybe the Java part of the GNU compiler collection can do something for them -- I don't know much about the status of Java support there.
Re:Java = Language + RTL + VM / compiler
by
mikpos
·
· Score: 1
I must admit I've fallen behind in terms of Java (the last time I touched it was over a year ago at school). The Micro Edition VM looks interesting, I must say. Of course it wouldn't be able to handle Java programs that use all those whiz-bang APIs, but those aren't very likely to be run on embedded systems anyway.
As for the C portability thing, I maintain that a C implementation having a bit of slack is a good thing. The C standard gives you lower bounds (which are very necessary), but allows the implementation to decide what's most efficient where. It's true that it does lead to a lot of errors, but putting more restrictions on data sizes seems a bit short-sighted; teaching proper coding techniques would be a better solution. I say it's short-sighted because it appears as though eventually whatever numbers Sun assigned to the data types is going to have to change. Plus, it makes things quite difficult for some embedded systems most likely (though I'm just talking out of my ass on this one). The common example would be the Cray (or at least one of the Crays), in which the char, short, int and long (the long *could* be 64; I'm not sure) are all 32 bits in size. This is perfectly fine in C, but it seems like it could lead to performance problems in Java while trying to "emulate" unnatural integer sizes. It seems as though 128 bit integers are going to hit us eventually, too. If Java has their integer sizes set in stone, that could, again, lead to performance problems (not to mention the difficulty in implementing the VM and/or library).
Anyway I'm still skeptical about Java. Other than last year when I was taking Java at school (and apart from my web browsers, I guess), I've never had a Java implementation installed, mainly because I've never needed it. I'd like to say that Sun should have just released native compilers from the start, but I guess I could be proven wrong...Java could someday take over the world in an orgy of portability and it would be extremely cool. Right now source compatibility still looks more attractive than binary compatibility. If you don't have access to the source, well, there's always emulation, and Java VMs are essentially emulation anyway, right? Actually to be completely honest, I'm glad for Java because there is a pretty good Sokoban applet. If it weren't for the Java in my web-browser, I would have had to install Gnome in order to play one of the Gnome Sokoban games (which probably wouldn't be as good anyway).
Very few good C++ programmers out there...
by
rjh
·
· Score: 4
First, your points are spot-on when it comes to C versus Java. When comparing C++ to Java, though, many of your issues go away.
Simplicity: a well-architected C++ solution, which intelligently uses the appropriate features of the language, is just as simple as Java. In fact, Java borrowed most of its simplicity from C++ in the first place.
Threading: Okay, this one is granted.
Garbage collection: Contrary to popular belief, Java's GC isn't exactly the best thing since sliced bread. There's a fairly large industry providing third-party garbage collection tools for Java. Can't remember any of them off the top of my head, but I do know that some of them are wealthy enough to afford full-page ads in Communications of the ACM.
Bjarne Stroustrup has also said that GC will likely be implemented in the next ANSI draft of C++. While that doesn't balance C++ and Java, it does mean that you're comparing no GC in C++ to a somewhat broken GC in Java. Neither one is an optimal solution.
Standard libraries: Are you at all familiar with the STL and free (liberty) C++ libraries? The advantage of Java isn't that it has every function under the sun; it's that the collection which ships with the JDK is very comprehensive. C++'s body of free (liberty) libraries is far superior, but you have to search for them.
I also have a slight objection to your use of the word "standard". There is no Java standard; therefore, there can be no standard library. C++ has been standardized; Java isn't.
Bounds checking on arrays: C++ includes this. It's included this for quite some time. It's not possible to bounds-check a C array, but it's trivial to bounds-check a C++ container (list, vector, etc.).
Printing stack traces from exceptions: Look around the free (liberty) C++ libraries. I'd be extremely surprised if you couldn't find one.
Reflection: C++ includes this. It's called RTTI (run-time type identification).
... I am not trying to denigrate Java or elevate C++. I've used both, and I have no clear favorite between the two. Java borrows very heavily from C++, and it constantly surprises me at just how many Javagrinders say "well, C++ doesn't have features foo and bar!" without realizing that Java borrowed foo and bar from C++.
That said, it is incredibly difficult to become a good C++ programmer. The language is straightforward, but has extremely complex nuances which require years of exposure to fully comprehend. Java is a much more straightforward language, but occasionally the lack of nuance makes it difficult to achieve subtle hackery.
Re:Very few good C++ programmers out there...
by
The+Wookie
·
· Score: 3
I used C++ for many years, although not as much since Java has come out, and since then the standard was finally ratified. Like you, I don't want to get into a Java has foo, C++ has bar kind of argument, I can just state what has made me prefer Java to C++.
Simplicity:While I would agree that on a large scale, a well-designed C++ system can be just as simple, sometimes simpler than a Java system. In the small, though, I find that I can create useful Java classes faster. I don't have to worry about destructors, assignment operators, etc. I know they have their use, I just prefer not having to deal with them. And just from a Me-Whining-About-Something-Insignificant standpoint, I hate the template syntax.
Standard Libraries:Okay, so there's no standard. But look at STL compared to the libraries that come with J2SE. With STL you've got containers, algorithms, strings.. very system-independent things. With Java I can write database code for almost any database and it will work on Linux, Windows, Solaris, etc. Swing is kinda big and slow, but at least I know I can count on it being there. C++ doesn't address areas like this. Again, for good reason. If I had to get that kind of stuff by a standards committee, I'd punt, too.
Garbage Collection:Sure you can do it in C++, but who does? And is it thread-safe? I know it's not the fastest thing in the world, and in some respects indicates a kind of laziness, but at least all the libraries use it. I don't have to worry about which ones do and which ones don't.
Bounds Checking:It's really not bounds checking so much as the whole pointer deal. No one likes to look for bugs caused by invalid pointers or references. It's not just running off the end of an array, it's things like returning a reference to a stack-allocated object. It's not a smart thing to do, but people do it anyway.
Reflection:You need to try Java's reflection. RTTI doesn't come close. You can ask a class what methods and fields it has, get and set field values on the fly, dynamically invoke methods.
Every so often I go back and try to work with C++ and I just find myself missing the Java features I have grown to love. But that's just me.. I love vi, too, having used it for 16 years.:-)
Re:Very few good C++ programmers out there...
by
SuperKendall
·
· Score: 2
Simplicity: a well-architected C++ solution, which intelligently uses the appropriate features of the language, is just as simple as Java. In fact, Java borrowed most of its simplicity from C++ in the first place.
I think the simplicity of Java comes from taking interesting parts of lots of languages - C++, Lisp, Modula 3, and others which together create a simpler system. Packages to cleanly seperate out different modules (really more similar to Modula 3 than C++ namespaces), The "everything's an object [almost]" mentality of Lisp (somewhat diluted by primitive types!) and so on. I'd say that based on a bunch of scheme and elisp programming as well as a lot of C and C++, that Java is closer in nature to Lisp!
Standard libraries: Are you at all familiar with the STL and free (liberty) C++ libraries? The advantage of Java isn't that it has every function under the sun; it's that the collection which ships with the JDK is very comprehensive. C++'s body of free (liberty) libraries is far superior, but you have to search for them.
I would argue that you really couldn't easily consider a library superior if it requires hunting for! A lot of what Java has going for it are very good standard libraries that are also widely known and used, thus there is a lot of free information on how to use them and a lot of examples abound.
There's not only the fine Collections package, but also JDBC for easy database connectivity, a pretty good file IO system, the built in networking support, image handling, compression handling, and many other things. You might be able to find a number of packages that fulfil those needs in C++, but unless you buy a solution like RogueWave it's often tough to find good support materials to help you use them properly.
I've used the STL, and I personally don't like that approach to the kinds of simple, everyday collections you need most often. Sometimes you come across cases where the complexity of the collection needed is much more than a simple set of collections can provide - but the Java collections provide just enough functionality to be useful for 90% of your collection needs and provide easy enough extensibility to account for many of the other cases. In fact one of the greatest boons to Java is that the most commonly used collection by everyone - a collection of characters, or a String - is pretty much a part of the language in Java. No matter how many String support classes you gather for C++ they still are more cumbersome to use than a String in Java.
Bounds checking on arrays: C++ includes this. It's included this for quite some time. It's not possible to bounds-check a C array, but it's trivial to bounds-check a C++ container (list, vector, etc.).
Yes, it's pretty easy to bounds check a collection of any sort but it's the normal C style array checking of Java that's really useful - no memory overruns to corrupt data, just a nice exception with a stack trace if you go wrong. There are packages like Great Circle that can offer runtime protection against these things for C++, but again that's another thing you have to hunt down.
Reflection: C++ includes this. It's called RTTI (run-time type identification).
Please feel free to correct me if I'm wrong as it's been some time since I've used RTTI, but I seem to remember RTTI being very limited compared to Java Reflection. I think RTTI is really closer to the "instanceof" operator in Java than the full Reflection functionality...
For instance, in Java I can get the type of an object, and create a new one - if I can't find a default constructor I could rummage through the constructors that are availiable and create a new instance based on some type I know about (like a String type that I knew could be used to create an object I'm interested in).
Then when an object was constructed, I could compare settable properties of one object vs. the other object and if the types matched use one object's get method and the other object's set method to copy properties with the same name (where compatible in type) from one object to the next.
I think in C++ you would be stymied by being unable to create an instance of an object unless it had a default constructor. I'm not even sure you can obtain a list of methods for a class and call them at will without knowing the type at compile time to cast into a callable object type.
I personally used to be a C++ proponent but now only use C++ for the occasional need to access some native resource or library. I've fully swung over to the support of Java because it has renderd me and the people around me to develop systems of great complexity with ease and stability that remained often elusive in C++_projects - I agree with you that it is truly hard to master C++, and make no claim myself to any mastery of the language (especially now that I've not really used it for so long!).
I disagree though that you cannot achive subtle hackery in Java - I think that between the language features like Reflection and the many packages availiable that you can actually achive things at a higher level as you are not so often bogged down in the mechanics of whatever trickery you are trying to attempt!
-- "There is more worth loving than we have strength to love." - Brian Jay Stanley
Re:Very few good C++ programmers out there...
by
FigWig
·
· Score: 1
C++ includes this. It's included this for quite some time. It's not possible to bounds-check a C array, but it's trivial to bounds-check a C++ container (list, vector, etc.).
It's too bad that the SGI STL that comes with versions of g++ doesn't seem to support exceptions: you can't use the at() function for arrays.
-- Scuttlemonkey is a troll
Re:Very few good C++ programmers out there...
by
Turing+Machine
·
· Score: 1
Garbage collection: Contrary to popular belief, Java's GC isn't exactly the best thing since sliced bread. There's a fairly large industry providing third-party garbage collection tools for Java. Can't remember any of them off the top of my head, but I do know that some of them are wealthy enough to afford full-page ads in Communications of the ACM.
AFAIK, Java doesn't specify what kind of garbage collector is used, so saying that "Java's" garbage collection isn't all that great doesn't make much sense. M$, Sun, and Netscape all use different technologies, and it wouldn't surprise me to learn that IBM is using still another. There are many, many, garbage collection algorithms, all of which involve different tradeoffs and have different scenarios that make them shine. Which one works best depends on just how the objects are being created and what kind of objects they are (one that works well for a program that's creating tons of small, short-lived objects is unlikely to be the best choice for a program that's making a few huge, long-lived objects). Garbage collection is a very active research area, and I think Sun did the right thing by not tying Java to a specific garbage collection model.
Re:Very few good C++ programmers out there...
by
Foogle
·
· Score: 2
Doesn't support exceptions? I think you've either misspoken or misunderstand. G++ itself supports the throwing of exceptions as a part of the language. The C++ standard library just doesn't *use* exceptions as a general rule, because it's a tradeoff or speed versus safety. You're left to do your own checking, but it certainly "supports" exceptions.
-----------
"You can't shake the Devil's hand and say you're only kidding."
Re:Very few good C++ programmers out there...
by
sab39
·
· Score: 1
[[ There's not only the fine Collections package, but also JDBC for easy database connectivity, ]] ... [[ I disagree though that you cannot achive subtle hackery in Java - I think that between the language features like Reflection and the many packages availiable that you can actually achive things at a higher level as you are not so often bogged down in the mechanics of whatever trickery you are trying to attempt! ]]
Much as I love Java (I consider it my first language, closely followed by Perl) I do have to disagree and say that there are some situations where Java could *really* use some more syntactic sugar to do some "subtle hackery". Your example of JDBC gives me a very easy example to use here - this is a scenario that actually came up in a project I am working on at this minute.
If I want to use a stored procedure that has both in and out parameters, I have to do stuff like:
Now, this is obviously clumsy, so I wanted to wrap it in a nice simple-to-call function. Wrapping in the general case of >1 in parameter and >1 out parameter is clearly impossible (if you disagree, I challenge you to try it... and post code of both the implementation *and an example use of your API*). But it turns out that even wrapping a *single* case is hard if there are >1 out parameters, because it's all-but-impossible to return more than one value from a Java method (again, an exercise for the reader on how to do this; I have code which makes it only 3 lines for the caller, but the implementor has to work quite hard for *every* procedure call).
There are other cases like this. I love Java for its simplicity and elegance, but there are some cases I'd dearly love some extra syntactic sugar. The simple, elegant language seems to cover about 90-95% of what I want to do, and I have to jump through clumsy hoops for the other 5%.
Stuart.
Re:Very few good C++ programmers out there...
by
FigWig
·
· Score: 1
Hehe, now that I look at the stl_vector.h file in my Mandrake install, I see exceptions and all. The wierd thing is that when I look at my school's install, all the exception stuff is commented out, not just ifdef'd. I got the impression that g++ didn't fully support exceptions when I was reading my school's header files.
-- Scuttlemonkey is a troll
Re:Very few good C++ programmers out there...
by
Steve-o
·
· Score: 1
I used to be a C++ programmer, and a good one, I think. I always thought the claims that java was a simpler language were nonsense. I wasn't afraid of no steenking pointers, I knew how to delete my objects, I'd read and understood the Scott Meyers books. I'd used and loved working with the STL.
Then I got a job working in java. What I found, basically, was that I didn't miss not having to delete pointers and such one bit. Sure, I'm not writing the world's fastest code in java, but it's plenty fast enough for what we need to do with it. There's even an STL-like group of classes for java. (Check out JGL).
I have written, in the past year, more code that has actually been reused (never mind reusable) in one year of java progamming than in five years of C++ programming. By removing the need for concentrating all that stuff, you instead get to concentrate more on the problem domain.
Re:Very few good C++ programmers out there...
by
Blake
·
· Score: 1
Java is a much more straightforward language, but occasionally the lack of nuance makes it difficult to achieve subtle hackery.
You say this as if it's a bad thing.
I've reached the point in my life where the more obvious a program is, the better it is. Thus Java has an advantage over C++, and Python over Perl for the same reason. C++ and Perl contribute to subtle hackery, whereas with Java and Python, your intention is explicit in the code. I think this point in my life is called "Maintainer" by some, but I prefer "Software Engineer".;)
We did some speed comparisons between IBM's 1.1.8 JDK and the 1.2.2 JDK from Blackdown/Sun/Borland and found the 1.2.2 platform to be significantly faster. Now, our tests were centered around using JRun behind Apache, but using the Apache Servlet Killer program, the 1.2.2 JDK held up a lot longer under load than 1.1.8 did. (shrug) We haven't tried the 1.3 JDK yet as it's a flippin' HUGE download (~60 megs) but it'll be interesting to test it out in the same way.
Yes, I would expect *any* 1.2.x JVM to be faster because Sun added the JIT to the 1.2 specification. This is another of the quite large differences between JDK 1.1.x and JDK 1.2.x.
--
-- "You're gonna need a bigger boat."
- Chief Brody
not to mention C++ is the only standard cross-platform language.(I could be mistaken, maybe smalltalk or lisp are also standards. But Java is not.)
Java is good for designing end user systems, where the real work is done by the database. Java is good for doing websites, again, where the real work is done by the database. I'd like someone to show me an example of real software(i.e word processor, database, game, compiler, OS) that is written in Java. Silly Yahoo games don't count.
C and C++ on the other hand do that stuff well. I wouldn't want to use them for a website, however.
--
No, Thursday's out. How about never - is never good for you?
mini-benchmarks: not as fast as 1.1.8
by
caucho
·
· Score: 3
I just did a quick servlet benchmark and it looks like the new JDK is close, but not quite as fast as the 1.1.8 JDK. But it crushes the Blackdown JDK.
The numbers are ops per second for a P-266 running RedHat 6.2 and Resin 1.1 as a standalone HTTP/servlet engine and using 4 clients.
File JSP Loop DB
IBM 1.1.8 907 640 37 317 IBM 1.3 878 615 46 315 JDK 1.2 393 383 6 147
Apache 720
The Apache 1.3.12 number is just for comparison. Scott Ferguson
-- Scott Ferguson
Caucho Technology
Re:mini-benchmarks: not as fast as 1.1.8
by
Leghk
·
· Score: 1
Heads up, AFAIK the IBM JVM is a mixed-mode VM. That means it learns as it runs. You'll have to make sure you let it run long enough for it to compile the code on the fly. If you use a running average you can clearly see it's performance increase dramatically over time.
I've found the IBM JDK1.3 almost 40% faster under heavy servlet threadload then it's ibm1.1.8 predecessor. Almost as fast as TowerJ, --which is GCC compiled converted Java code.
This whole thread is built on a misconception. Modern Java VMs, such has Sun's HotSpot on Windows or IBM's 1.1.8, produce code that is as fast or faster then that produced by static compilers. Some things to understand: (1) Java code IS compiled. Its just compiled at run-time rather then build-time. The result is the same however-- machine code running on your machine. (2) JITs have a number of advantages over static compilers: (a) A static compiler must compile for a lowest common denominator platform (typicly Pentium). A JIT can determine the processor type at run-time and produce processor-tuned code. (b) A static compiler must "guess safe" in situations where code is ambiguous. A JIT can go ahead and take risky optimizations because it can un-optimize if the need arises. One place this occurs a lot is in in- lining. The static compiler can only safely in-line finals. The JIT can try to in-line anything and adjust by how the code actually gets used. (HotSpot calls this "agressive inlining" and you can read about it at the HotSpot section of java.sun.com) Simple fact. For raw computation that doesn't incurr array bounds checking, Java is as fast or faster today then C/C++. (And static compiling doesn't help you with the bounds checking penalty.) There are some actual experiemntal numbers and a chapter discussing this and other Java v. native code issues in "Java(tm) Platform performance: Strategies and tctics" coming out at JavaOne. (Its already up for pre-order at amazon...)
Also, for a more detailed and more easily read discussion of the HotSpot technology, you can look at Appendix B in the book I already mentioned that will be out next month.
("Java(tm) Platform Performance: Strategies and Tactics")
Maybe 50% incorrect. My point is that in-line cannot occur unless a method is final. Your quote says the same thing because if the optimizer "finds" a method that is used in a non-final way, it will be un-inlined. To me, this is just extra work for the optimizer. Yes, I read the rest of the white paper, but
I am not sold on Hot Spot because it degrades heavily under high loads. Check out JDJ article by Jeremy Lizt (p 66) for a fairly biased perspective. Notice how Hot Spot blows up with many concurrent users. We have observed similar degredation in performance on Solaris with Hot Spot. Food for thought.
later
--
-- "You're gonna need a bigger boat."
- Chief Brody
Modern Java VMs, such has Sun's HotSpot on Windows or IBM's 1.1.8, produce code that is as fast or faster then that produced by static compilers.
Some things to understand: (1) Java code IS compiled. Its just compiled at run-time rather then build-time. The result is the same however-- machine code running on your machine.
(2) JITs have a number of advantages over static compilers: (a) A static compiler must compile for a lowest common denominator platform (typicly Pentium). A JIT can determine the processor type at run-time and produce processor-tuned code.
(b) A static compiler must "guess safe" in situations where code is ambiguous. A JIT can go ahead and take risky optimizations because it can un-optimize if the need arises.
One place this occurs a lot is in in- lining. The static compiler can only safely in-line finals. The JIT can try to in-line anything and adjust by how the code actually gets used. (HotSpot calls this "agressive inlining" and you can read about it at the HotSpot section of java.sun.com)
Simple fact. For raw computation that doesn't incurr array bounds checking, Java is as fast or faster today then C/C++. (And static compiling doesn't help you with the bounds checking penalty.)
There are some actual experiemntal numbers and a chapter discussing this and other Java v. native code issues in "Java(tm) Platform performance: Strategies and tactics" coming out at JavaOne. (Its already up for pre-order at amazon...)
This is a previews of forthcoming commercial software. It's only free for noncommercial use, and can not be distributed freely.
While a good java kit is good news anyway, I think it's important to emphasize this in the article. We still don't have a good free java kit for linux!
Re:Java, C++ and other stories
by
catseye_95051
·
· Score: 1
> . The optimizations performed as not nearly as >aggressive as static compilers try, why ? >Because at runtime you cant afford the time >penalty This statement shwos a compelte lack of understanding about what HotSpot does. HotSpot focuses the compilation effort on the code that gets most used ( the "HotSpots") and thus has the time to do all the optimizatiosn it needs. The actualy optimizatiosn are actually MORE agressive because Hotspot can guess agressively in ambiguos optimization situations and back those optimizatiosn out later if they prove wrong. I gave a more complete, but still brief, explaination of this in the top thread -- look at the message titled "Misconceptions." More detailed theoretical information can be found in white papers at java.sun.com in the HotSpot section. A whole section on the real life costs/benefits of Java code v. native code (including real world measurements) is in the book "Java Platform Performance: Strategies and Tactics" which will be released at JavaOne next month. (
Bold assertion there... (Re:Misconceptions)
by
Troy+Baer
·
· Score: 2
(a) A static compiler must compile for a lowest common denominator platform (typicly Pentium). A JIT can determine the processor type at run-time and produce processor-tuned code.
That depends largely on your environment and how widely you plan to disseminate binaries. Where I work, we regularly compile codes where we need good performance with the highest possible optimization targeted to the specific CPU type on the machine, but we're hardly a typical shop.
Simple fact. For raw computation that doesn't incurr array bounds checking, Java is as fast or faster today then C/C++. (And static compiling doesn't help you with the bounds checking penalty.)
That's a pretty bold assertion. What kind of "raw computation" applications were these: number crunching, DB access, GUI desktop apps, what? Also, what architecture or architectures were these comparisons done on? If you're talking number crunching, will it outperform a good optimizing Fortran 77 or Fortran 90 compiler? (Note: Neither g77 nor the Sun Fortran compilers constitute a "good optimizing Fortran compiler". I'm talking about something like the Portland Group's Fortran compilers for IA32 or the SGI MIPSpro Fortran compilers for MIPS. Compaq's Visual Fortran may or may not qualify; I've never used it.)
The reason I ask is, I work in high performance computing, and I deal with trying to optimize codes all the time. I find it difficult to believe that JIT compiling is the panacea you describe it as, but if you've got numbers to back it up I'd love to see 'em, if for no other reason than to dissuade our physicist users from trying to program in C++...
--Troy
-- "My life's work has been to prompt others... and be
forgotten." --Cyrano de Bergerac
Re:Bold assertion there... (Re:Misconceptions)
by
catseye_95051
·
· Score: 1
Troy, The basic numbers are in the book I mentioned. They are somewhat annecdotal but based on real world problems (like calculating a Bresenham line.) If you want to email me at jeffpk@iname.com I can probably dig you up some "harder" test type numbers. I would have to be honest and say that I don't knwo enough about FORTRAN compilers to answer your second question. Its possible that FORTRAN creates such trivial linear code that a lot of the value of run-time analysis goes away. There is anoter issue with older languages though that is particularly obvious when benchamrking java v. hand crafted assembly. The REAL performance gains in any program of signifcant size can be found not in the byte crunching but in algorthim selection and tuning. This is very hard to do in lower level languages. The compelxity of the problem quickly becoems the dominant conrolling factor. An object oriented langauge like Java makes isolation of functional units clean and easy, resulting in a much more tunable program. So while I wouldn't say a modern JIT produces tiny amounts of code better then a processor espert could hand code (though its getting damn close to equal), and I don't knwo enough about FORTRAN to comment intelligently on its code generation, I AM confident in saying thawt Java today is as good or better then C/C++ and is more easily debugged and tuned. SO given a fixed amount of time to do a non-trivial program, I'd lay money I could get a faster runnin result in Java then any other language I know of.
At least they're numbering honestly
by
JamesKPolk
·
· Score: 1
Following Sun's lead would probably call it Java 3!
Good args, poor conclusions
by
Anonymous Coward
·
· Score: 1
While you're correct about some advanced compiling features for byte-compiled languages, there is one simple premise you're avoiding - garbage in, garbage out.
Java's libraries are so deeply nested and full of synchronization code that its unlikely that Java programs will ever in actuality match C code.
Re:Good args, poor conclusions
by
catseye_95051
·
· Score: 1
You've raised a different issue here-- the question of library efficiency.
Since you've accepted the premise that Java can be as fast or faster an execution environemnt as C/C++, we're really talking about quality of code.
There are a few answers to this: (1) Efficiency has been a focus for voer a year at Java Software (Sun). Sun has been doing intensive clean-up work on the libraries, making them faster and smaller. The gains so many have commented on in 1.3 on windows in both execution size and GUI performance derive in large part from library clean-up. This is an on-going effort at Sun with a group dedicated now to JDK perfromance issues.
(2) There is no reason third parties can't create their own high-efficiency implmentations.
(3) There are a small number of places where the APIs were missing critical functions for efficient coding. (Ex: Allowing a thread to listen() to more then one socket at a time.) These are being identified and fixed.
Re:Good args, poor conclusions
by
catseye_95051
·
· Score: 1
>>(2) There is no reason third parties can't >>create their own high-efficiency >>implmentations.
>Not when the inefficiencies are embedded in the >java.lang specifications. Like the moronic >decision to synchronize all over the place.
Hard exampels please? Very few things in the Java libs are specified as thread safe today.
Vector and Hashtable were originally implemented thread-safe. Java2 repalced them in with the entire collections set of classes, which are not by default thread safe. Collections provides you with wrappers if you want idiot-proof synchronization. In general this seems to be the trend of Java APIs.
(Sorry, I accdientally posted as HTML and silly slashdot wont let me delete and repost when that happens nor add another response beneath so I had to up here.)
Troy,
The basic numbers are in the book I mentioned. They are somewhat annecdotal but based on real world problems (like calculating a Bresenham line.) If you want to email me at jeffpk@iname.com I can probably dig you up some "harder" test type numbers.
I would have to be honest and say that I don't knwo enough about FORTRAN compilers to answer your second question. Its possible that FORTRAN creates such trivial linear code that a lot of the value of run-time analysis goes away.
There is anoter issue with older languages though that is particularly obvious when benchamrking java v. hand crafted assembly.
The REAL performance gains in any program of signifcant size can be found not in the byte crunching but in algorthim selection and tuning. This is very hard to do in lower level languages. The compelxity of the problem quickly becoems the dominant conrolling factor.
An object oriented langauge like Java makes isolation of functional units clean and easy, resulting in a much more tunable program.
So while I wouldn't say a modern JIT produces tiny amounts of code better then a processor espert could hand code (though its getting damn close to equal), and I don't knwo enough about FORTRAN to comment intelligently on its code generation, I AM confident in saying thawt Java today is as good or better then C/C++ and is more easily debugged and tuned.
SO given a fixed amount of time to do a non-trivial program, I'd lay money I could get a faster runnin result in Java then any other language I know of.
I just ran a CaffeineMark on my PC versus the jdk1.2.2 supplied by SUN versus the new jdk1.3 supplied by IBM. SUN's caffeinemark was 444, while the IBM JVM scored a whopping 6,309. This is an amazing performance difference.
--
-- Good judgement comes with experience.
-- Experience comes with bad judgement.
It's also a suspicious one. Are you sure you were running the 1.2 with the Inprise JIT and the JIT enabled? This doesn't seem to jibe with the real-world comparisions being posted on java lobby. I curious what your set up shows under SPEC. Ofcourse to paraphrase Mark Twain. There are 3 kinds of lies: lies, damn lies, and benchmarks.
I downloaded and retested with Inprise's javacomp JIT and my marks effectively doubled from 444 to 823 using CaffeineMark 3.0 as my benchmark. Looks like my initial test didn't incorporate a JIT, but still, the IBM benchmark results were far superior, especially on the logic section of the test which scored 495,997, more than an order of magnitude larger than any of the other tests in the CaffeineMark benchmark. As far as I can tell, my benchmark was legit.
--
-- Good judgement comes with experience.
-- Experience comes with bad judgement.
Well its odd given the annecdotal evidence of peopel running real apps-- they don't seem to be reporting an order of mangitude difference. In fact, early reports on Swing apps are that Sun jdk1.2.2 with the Inprise JITa re actually visibly faster.
When synthetic benchmarks don't reflect real world behavior there is usually something funky about the benchmark. Benchmarks don't act like real world apps. iIt is certainly possible to tune for a given benchmark, or even outright spoof it.
I wouldn't accuse IBM of spoofing, but I have some real skepticism that what you are seeing is anything more than an anomoly. Try running SPEC and some of the other more modern benchmarks and comapre notes with others doing the same. The best tests are always real-world apps, but certainly a range of benchamrkas (Caffine is rather old among other things) on a range of hardware will give you a better picture then one test on one configuration.
I give talks on this topic and I always tell people not to put too much faith in ANY synthetic benchmark numbers
Marketing BS [Re:Misconceptions]
by
Anonymous Coward
·
· Score: 1
I have been working on dynamic optimizers and I call your bluff.
Hotspot is not even as fast as decently written C/C++. Show me one such benchmark and I'll tell you how rigged it is.
Now I am not saying that the approach is wrong. JIT compilers indeed have a promising future. But Hotspot is not there today. Maybe next year, maybe in 5 years will a JIT compiler beat a good Java to native compiler with profile feedback.
And when this JIT appears, you can apply most of the same ideas to C and get it to run still faster than Java... (shipping an ANDF-like format)
Note that I am not dismissing Java. IMHO 95% of most applications should be written in Java or even higher-level languages (smalltalk, Dylan, etc.), 90% of the rest in C and a few lines in assembly (if needed).
Re:Marketing BS [Re:Misconceptions]
by
fmnsnnsm
·
· Score: 1
There is no reason that a hotspot-ish JVM can't store it's dynamically-optimized class files in some kind of repository and use those files instead of the original ones. The optimized class files could then "evolve" into efficient [byte]code. The JVM would maintain some state with each optimized class file indicating how "optimal" it is. Starting with 0%, the JVM then optimizes less-and-less aggresively until it reaches some threshold value (e.g. 95%), and then the optimizer just stops trying (so it doesn't steal cycles). If the JVM indexed the repositories on a per-main-method basis, it would even allow for shared libraries that are optimized seperately for specific programs. If your disk-space is cheap and your time is expensive, I would think that this is the way to go. Vendors of software implemented in Java could even give their users "static optimization profiles" based on their in-house testing to give these advanced JVM's a head start.
Re:Marketing BS [Re:Misconceptions]
by
catseye_95051
·
· Score: 1
There's nothing here to respond to. You are entitled to your opinion.
I'll call your bluff in return. Show me a static compiler that can run a reasonably real-world non-trivial purely numerical problem in a truely java fashion (which means safety, no dropping bounds checking or other cheats) against the Windows 1.3 Hotspot with appreciably better results.
This includes supplying me with access to the source and the compiler so I can double check it for "funny business."
I've been doing just Java performance work for over a year, including serious research into the whys and wherefores of why Java code does or doesnt perform under different situations and I haven't seen this.
Re:Marketing BS [Re:Misconceptions]
by
catseye_95051
·
· Score: 1
I just noticed this part of your statement...
"Maybe next year, maybe in 5 years will a JIT compiler beat a good Java to native compiler with profile feedback. "
What do you mean by "profile feedback". If your talking about profiling and tuning your code, no JIT CLAIMS to remove this step, nor should it. The biggest wins in profiling are not ON the code-generation level, they are on the algorithmic level.
You can and should do a write-profile-tune loop with code going into a JIT just as you do with code going into a static compiler.
In fact, since Java has the VM machinary there it has a great opportunity to give you plenty of profiling feedback (see JVMPI).
(In point of fact, the ONLY product I've seen claim to eliminate this step is a static compiler, and THATS marketing BS. A compiler CAN'T tell if your doing too much work in your algorithims for the results you need-- that requires a level of AI undertsanding of the entire purpose of the program and takes us into Start Trek-ville and the DWIM statement.)
Re:Marketing BS [Re:Misconceptions]
by
catseye_95051
·
· Score: 1
Yep, there's room for all KINDS of new ideas in JITs. It opens up all kinds of thinsg that haven't been possible before and I'm sure we're goign to see a lot of exciting things come out of the compiler-gurus at places like IBM and Sun in the coming year or two.
The idea of "evolving code" is already happening in the sense of the "agressively inlined" or "dynamicly deoptomized" code (two terms for the same thing.) There are some advances on this idea that I know of already in development at Sun adn I'm sure there are equally exciting things happening at Big Blue:)
So Bruce was trolling. But I get so sick of this crap every time there is a Java story on Slashdot...
I'd like someone to show me an example of real software(i.e word processor, database, game, compiler, OS) that is written in Java.
Yeah, except most lines of code aren't written for apps like that. Try buisiness systems in major companies. Have a look at IBM Websphere, BEA Weblogic or Oracle8i or any of several dozen other similar products. You know - stuff used by real businesses.
Just becuase Java isn't used by 20 dorks a day to write a CD player front end and put it on freshmeat doesn't mean it isn't used.
--
Do you even know anything about perl? -- AC Replying to Tom Christiansen post.
At my work, we're using java (quite successfully) in a system which generates over a million legacy system accesses a day, formatting the results through use JSP as well as DCL (a small perl-like language written in java). The system does millions of dollars of business a day in a mission critical atmosphere. Java delivers great performance for us and minimizes development time.
--
-- Good judgement comes with experience.
-- Experience comes with bad judgement.
Re:Non-x86 Linux users in the dust (of course!)
by
JohnZed
·
· Score: 3
IBM wants to sell more hardware. IBM doesn't sell Sparc or Alpha hardware, so those would clearly be silly ports (they'd just help Sun and Compaq, who are direct competitors). As for PowerPC, maybe IBM would consider a port if they saw a substantial number of serious, enterprise customers buying PPC hardware to run Linux. But, frankly, very few people are doing that right now. It is NOT just an issue of "grab a PPC and compile", because much of a good JVM's performance comes from a good JIT. JITs are, of course, highly architecture-specific. And, as for their failure to distribute source, remember that they license code from Sun (it's not a true "clean room" JVM). Thus, at best, they could consider a SCSL license. Remember how popular the SCSL was? But then Sun (public enemy #1 for IBM right now) would get the benefit of all their JVM enhancements (and IBM has PLENTY). Doesn't sound like a compelling business case. --JRZ
An example of one method for calling arb. proc.
by
SuperKendall
·
· Score: 2
I'll admit that is one of the more unpleasant cases, but I've made an attempt to outline a strategy I'd use - basically to get around your issue with multiple return values from a method call I'd either return a Map or pass in a Map ( or Object[] ) that I could fill with values. This could also be a list but I tend to like the named entries in a Map.
Below, I have some code and some pseudo code in comments outlining one way that you could do something like what you want to do - it relies on database metadata information to pull out parameter types and help map what you are sending into it.
It also takes a connection to build this object, I've found in general it's a pretty good idea to pass connections to JDBC helper objects of this sort as you can easily share one connection across multiple helper objects, you get to manage the commits, and you can close when it's the right time. You can also build up multiple helper objects connected to different data sources which is nice.
int myResult2 = ((Integer)resultMap.get( "Param3Result" )).intValue();
Admittedly, it does not look a lot prettier than the code you already had - it does let you do multiple calls through one wrapper object and I think the call itself is pretty clean [you could even go so far as to add callStatement(name, arg1), callStatement(name, arg1, arg2)... to ProcedureCaller though I don't like the look of it for some reason!] and it lets you get to the results pretty easily.
I think if I were writing this for myself I'd pass in a ordered Map instead of an Object[] so I could provide names for in and out paramaters to get them out of the result map in a more meaningful way.
You could also provide a bit more useful type of Map wrapper that helped in obtaining primitive values by automatically unwrapping primitives from the objects returned in the map. (like an [int getInt()] call in the map).
The code below at the end does not do the type translation bit much at the end - I was assuing calls to getObject() that would stuff the results back into the result map with essentially the same type as the database. One could provide a custom map as well, which might be nice to get back Timestamps instead of Date objects if you want to keep the whole value of your Date object!
I also assumed the use of JDBC 2.0, though I think you could do most of this with just a bit more work in a JDBC 1.1 driver...
Here's the code for the helper object (terribly unoptimized!! Assume a GPL license for the whole post)
public class ProcedureCaller {
public ProcedureCaller( Connection conn ) { // store connection }
public Map callProcedure( String procname, Object[] args ) { // ------- Build call string StringBuffer call = "{" + procname + "( "; // loop through args adding "?," for each arg listed
call.append(" }");
// ------- Register parameters
// Get out list of parameters for this call, this info could be cached String catalog = conn.getCatalog(); ResultSet dbFunction = conn.getMetaData().getProcedureColumns( catalog, ""// Schema procname, ""// Whatever "all" pattern is );
// Build the call to call CallableStatement cs = conn.prepareCall( call );
// Go through the meta info about each function parameter to set parameter // types and values short columnOutness; short columnDataType; int i = 1; while ( dbFunction.next() ) { // gets In, out, in/out, or returnVal columnOutness = dbFunction.getShort( "COLUMN_TYPE" ); columnDataType = dbFunction.getShort( "DATA_TYPE" );
// Based on the parameter flow, do what we need to. Probably remember // return type for out params and return value. switch ( columnOutness ) { case DatabaseMetaData.procedureColumnIn: cs.setObject( i++, params[i] ); break; case DatabaseMetaData.procedureColumnInOut: cs.registerOutParamter( i, columnDataType ); cs.setObject( i++, params[i] ); // add this parameter index to list of OUT params
case DatabaseMetaData.procedureColumnOut: cs.registerOutParamter( i++, columnDataType ); // add this parameter index to list of OUT params
} }
// now that all the parameters are set, call the procedure ResultSet procResults = cs.executeUpdate();
// go through result set adding any results to the map
// Go through each OUT paramater stored in our list of OUT paramindexes { // Add parameter to result map, perhaps by name "Param[i]Result"
// If you want to flow back through objects passed in the object array, //just get them out by index and either set values (if mutable object) or //create new object and put that into the passed Object[]. }
return// map full of results }
}
-- "There is more worth loving than we have strength to love." - Brian Jay Stanley
The main reason to use Java is NOT portability
by
jimfrost
·
· Score: 1
Sun marketing be damned, the main reason to use Java is not portability, it's development time. Versus C or C++ my productivity at least tripled and for certain kinds of applications (network servers in particular) it's way, way better than that. And that's been pretty much the same story for everyone else I know using it, too. Furthermore the bug counts are way, way down and the bugs tend to be irritating rather than debilitating (ie throw an exception and keep running rather than dumping core).
Swing and AWT could use a lot more maturity but if you don't need a GUI, or you only need a basic GUI, Java is awfully nice for building applications.
More speed I can definitely use but realistically speaking we're building some damn fast servers with Java, stuff that runs rings around the C++ competition, even using the Sun 1.1 JDKs. When you're building the code three times as fast you have a lot more time for optimization!
Its is possible you are running into the "on-stack replacement" issue in the JDK1.2 version of HotSpot. This is a problem that only affected micro-benchamrks, not real apps, but was fixed in 1.3 anyway because it was confusing people trying to mesaure things.
There's a discussion of it here:
http://java.sun.com/products/hotspot/1.0/Q+A.htm l
It's been mentioend a few tiems. (Okay its been mentioned a few times by me, and once or twice by others;) ) That niether Volano or Caffine are terribly realistic benchkmarks. I've suggested SPEC a few times. Here's where to get it: http://www.spec.org/osg/jvm98 All my cautions about not trusting ANY synthetic benchmark overly much still apply.
If you want better truetype fonts for this JDK
by
jancastermans
·
· Score: 1
JDK1.3: usable Java on the client! (at last).
by
renoX
·
· Score: 1
Hey, when the JDK1.3 will become stable, Java may become a real usable solution for both client and server!
From my POV, Java was a really poor solution: JDK1.0 was poor in many respects, 1.1 was better but still buggy and AWT is a braindead API (yes, I know that Swing could be used indepently of the JDK1.1.x), the JDK1.2 contains vastly improved APIs but they were quite buggy for a looong time (the bugParade was full of bitter complaints, Sun was constantly adding new API but bugs weren't corrected).
The JDK1.3 seems to correct many,many bugs from the bugParade:-):-) Good!
I've been burnt badly by Java in the past: for me it was hyped to death while still being very imature (from a client point of view anyway).
The Sun's JDK1.3 is still in the Release Candidate status (if I remember correctly, it was supposed to be released in January), and IBM's JDK is a beta release.
When they finally become stable release, I think that I will take another look at Java.
For anybody listening to this BS, I suggest you actually do some experiments yourself. Java and C++ are close enough that it's quite easy to compile virtually identical code in both. There are too many lies told by both sides and ymmv depending on what you're doing.
I typically find Java runs at 1/5th the speed of C++ (using latest compilers). My own results correlate closely with http://sprout.stanford.edu/uli/java_cpp.html
Listening to what Sun says about Java v C is like listening to what Microsoft says about W2k v Linux.
Your arguments are fine theoretically, they're just false in practise. HotSpot is not nearly that good yet.
>I suggest you actually do some experiments >yourself. Java and C++ are close enough that >it's quite easy to compile virtually identical >code in both
Your premise is compeltely off. To restate the above: "Java shouls run code tuned for C++ as fast as C++."
Thats nonsense. Many of the things we do in C++ to encourage it to perform HURT Java performance, and vice versa. Just taking a piece of C++ code and recompiling it is gaurranteed to have lousy results... and taking peice of well tuned Java code and simply recompiling it in C++ will have EQUALLY bad results.
Just a few sample issues: (1) Arrays
In C/C++, arrays are used extensively in high prformance programming. When one wants to speed up a recursive routine, one re-writes the routine with a lcoal arrwy asbed stack.
In Java, array access incurrs bounds check penalties. It is FASTER in tegh latest generation of VMs to recurse then build a lcoal stack.
(2) Virtual methods In high performance C++ one must code to avoid virtual methods because they cannot be inlined. In Java it is good practice TO use virtual methods (a non-virtual in Java is a final) because the latest VMs are very sophsiticated in determining for themselves if something is in-linable.
In general java today is MUCH better at in-lining then ANY C++ compiler.
(3) Tuning Time
It is at this point I believe an undisputed fact that a Java coder can write correct code faster then a C++ coder. (My own experience, and that of it seems many others, has been about an order of magnitude difference in speed.) In the REAL world, time is limited. Faster coding means more time to tune, therefor for the same period of time coding, an equally proficient Java coder will produce a better tuned application.
These, and many other factors, are totally absent from your "test".
The sad thing is, if you had been prgoramming C++ as long as I have, this would all sound familiar. These exact same dispersions were cast on C++ when it arrived on the scene. People had to learn how to use the tool before it payed off. Really learn Java, then make your comparisons.
Perhaps if they had a more understandable syntax, Java wouldn't be so bad. I downloaded the latest JDK a few weeks ago and tried in futility for 20 minutes to get a Java program compiled. It just didn't want to accept anything that I wrote. Unfortunately, I can't recommend Java to the Man in THe Street until they work on the syntax, because it's really finicky and unfriendly.
On the other hand, some standard libraries (like Swing) have performance problems that can't be fixed just by throwing in good code generation, and the JVM still fails to make use of hardware acceleration wherever possible -- a world-class JIT compiler will compete with a static compiler, but never with dedicated hardware (e.g. for 2D graphics). And there's a lot to do on platform-specific tuning (AWT, threads, memory mgmt, I/O).
This is only to make things clear, as I guess all the previous replies should originate from people thinking "duh, so why does it still look slow here".
But just to add another plus, array bounds checking is not a problem. Both Symantec's and IBM's latest JIT compilers seem to do a great job in avoiding these checks or moving them out of loops. In IBM, this is not even an issue anymore. And you still have full safety! Compare this to a C/C++ program that aims to be safe while doing lots of arrays -- it needs manual boundchecks (more likely, encapsulated by some array class's operator[]) and these checks can't be removed by an optimizing compiler as much as Java's can (hint for C fans: pointers). IBM has a ton of research to make Java *the* language for number crunching, and they have already shown very exciting results (up to 90% of FORTRAN performance).
People who like vi like java
by
twdorris
·
· Score: 4
Here's something I thought I'd throw out there. First, a bit of a disclaimer. I'm no MS VB weenie that likes Java because it's simple to use. I prefer coding in assembler and I do so quite often when appropriate (I reprogram the ECU in my car, for example). However, I also happen to really enjoy coding in Java. It's the most "pleasant" coding environment I've ever used in the past 15 years; period.
I'm a big fan of the "learn one thing well and become an expert on it" approach to life. I focus on something that I know is going to be powerful and/or popular in the future and I learn it well. Java is that thing when it comes to coding.
I learned about vi while in college (about 5 years ago). I thought it was weird and awkward to use, but because it was everywhere and because I could focus on honing my skills with that one editor and be proficient on so many different platforms with it all at once, I learned it. Now I know that editor very well and I happily co-develop under Linux, Solaris, HP, AIX, and even windows with it.
Java is the same type of thing. I learned Java, I learned it well, and now I code peacefully on all those same platforms (sans HP and AIX...I just haven't used those in a while). I've written a datalogger in Java using Swing for my car that works in conjunction with the aforementioned ECU reprogramming effort to provide me with real time data gathering while I'm powering around at the track. What's great is that I did ALL my development under Linux. When it was all done, I slapped the exact same jar file under Windows NT for a friend of mine with a similar car (didn't even have to recompile it!) and it ran flawlessly. He prefers Windows, I prefer Linux.
Why on earth would I have ever considered writing that application under anything but Java? If I had used MFC, I would not only still be pulling my hair out trying to figure out what the hell was wrong with it, but I also would be forced to use Windows when I was done. The same is true if I had coded it using Motif or GNOME/Gtk or most any other X-based environment. I could not have shared that application with friends that happen to like Windows.
That's one of the many benefits of Java; and it's one of the benefits of vi. Learn something that's powerful and flexible once, learn it really well, and you end up reaping benefits from it on a variety of different platforms. Java is quite powerful and I'm happy as hell to see IBM doing all the great work they're doing with Java under Linux!
Ridiculous. Garbage collection alone is enough to make Java slower than C/C++. Then, there's the penalty of translating (compiling?) Java byte code into machine code. No matter what you claim, this is an extra step that takes extra time. "Compiled at run-time" means time spent compiling at run-time.
Java is a good language with an incredible library. It's easier and faster to write code in Java than in C/C++ but the tradeoff is run-time performance. It's ideal for business applications that need to run on multiple platforms. But it is not appropriate for performance-critical tasks. You will not see Java used to write operating systems, device drivers, and high-end 3D games. It's just too slow.
This should be obvious stuff. I only write it down here for readers who might not know that the quote above is just flat wrong.
at least in a few simple tests I did. Hotspot on Win98 outperformed gcc-2.95.2 there, especially in memory management (object allocation/deallocation).
Arrays were a little slower than C (about 10%). Integer calculations the same speed.
And I cannot help people that still believe that Java is slower than Perl...
I'd like someone to show me an example of real software(i.e word processor, database, game, compiler, OS) that is written in Java.
Perhaps you should look for such examples yourself rather than assuming that if nobody comes and waves them under your nose they can't possibly exist. I've certainly seen databases, games and compilers written in Java. In fact, as someone has no doubt already pointed out, the java compiler that ships with the JDK is written in Java (the classes for it are in the tools.jar file - hence the requirement for this in the JSWDK classpath). http://www.jars.com is probably a good place to start looking.
-- ++ Say to Elrond "Hello.".
Elrond says "No.". Elrond gives you some lunch.
I wasn't trying to flame anybody, I just wanted to hear about some examples. I have nothing against Java. Honestly.
I've used Javascript, but my fear of slowness has kept me away from using Java for anything serious. However, I admire Java for its simplicity. I have Eckel's book "Thinking in Java" and the thing that attracts me most to it is his statement that Java would enable people to be "software craftsman" rather than operating system hacks. The language itself seems to have gotten rid of a lot of things that make C++ painful to program in.
So actually, I am interested in trying Java seriously. I just wanted some good examples of what it can do.
--
No, Thursday's out. How about never - is never good for you?
Re:Great job IBM -- acknowledged
by
catseye_95051
·
· Score: 1
Okay,
I've now seen a bunch of real-world benchmarks that more or less explain what everyone has seen. They're internal numbers that I can't release, but in general...
The 800: 6200 (approx 8x difference) v. jdk1.2 seems reasonable on purely computational things. This confused me until I remembered that Linux is the one place where the jdk1.2 ISN'T hotspot. This is a classic v. much more modern VM comparison. Hotspot can be expected to perform similarly when released on Linux.
The varying GUI numbers are explained by the fact that it performas somehwt differently on different GUI tasks. A few its very good at now, some it still needs some work on.
In general, on Linux IBM 1.1.8 is still beating JDK1.2.2 and IBM 1.3 respectably in most GUI things. IBM 1.3 is kicking repectable rear in non-gui tasks.
Others have already reported some scaling issues with 1.3 I don't have tests for those.
Libraries and Bounds checking
by
catseye_95051
·
· Score: 1
You're absoluely right that therr are library problems. Alot of them have to do with implementation details, which are being worked on. (Anoyone whose tried Swing under JDK1.2 v. the 1.3 thats currently out has seen the results, and there are better thinsg still in the works.)
A few of them have to do with the nature of the libraries as very high-level, idiot proof things. Lower level facillities are gradually appearign in java. I've been playing with java for games myself, and as part of that I've written JNI to talk to DX directly. Doing that, Java easily flips frames at the limit of my video-synch (70hz) on my PC.
There are a few key things missing from Java for real ultra-high performance stuff. A number of these are being added... I can't say much more now but I'll gladly post abotu them when they are public. (Actually, when one of them is public, I'll be able to finish and post my DirectJava library, which I intend to make open-source.)
Now I hate to disagree with someone whose on the same philisophical side... but I need to disagree with you on bounds checking. Unless you know of some approach I don't, AFAIK there is no way to eliminate it from random-access reading and writing of arrays.
What you mentioned about loops is called "hoisting" and yes this is happeneing, but an array implementation of a stack, for instance, must still check every access to make sure its within the memory area of the array proper. We have to be careful not over-sell hoisting and lead people the wrong way in their programming.
"AFAIK there is no way to eliminate it from random-access reading and writing of arrays."
This is "almost" true -- if you can proof that the index falls in the array's range trough other optimizations (maybe inlining the array code, so some index parameter benefits from the callee's analysis) you can eliminate the checks.
Another trick IBM is using is having the compiler to know about special libraries (like their Matrix and Complex libs) and doing many (otherwise unsafe) optimizations only in trusted sections of that code. And of course, VMs and static compilers might offer switches to do away with certain checks (maybe in a per-class or per-package base). I think at least TowerJ allows that. The risk is a good tradeoff for many programs -- if your action game crashes because you used unsafe optimizations, nobody is gonna lose a life or a million USD, so why not doing it.
Add the fact that most boundchecks happen inside tight loops that iterate arrays in a predictable way, and the unoptimizable random accesses that you can't optimize out become much less important (at least, for many apps).
"What you mentioned about loops is called "hoisting" and yes this is happeneing, but an array implementation of a stack, for instance, must still check every access to make sure its within the memory area of the array proper."
This is one case where inlining would sometimes enable the compiler to kill boundschecking. For example, a pop() immediately followed by a push()on the same stack would be easy to optimize, at least to have a single check instead of two.
"We have to be careful not over-sell hoisting and lead people the wrong way in their programming."
Amen brother. BTW, the IBM stuff mention is not public yet (some of their optimizations depend on fixes in the JLS to be compliant), I loved the papers but I will hold my breadth when I see it in the wild, so I can run my JavaQuak\b\b\bscientific software.:-)
Re:Libraries and Bounds checking
by
catseye_95051
·
· Score: 1
Great post, thanks:) The IBM unsafe stuff is aprticualrly inetresting ebcause I happen to knwo Sun is workign on something similar to solve a different problem. It would be great if we could get a standard mechanism that both Sun and IBM use, and that thrid parties could use as well. Yep, btw, games are a great example of where "unsafe" stuff like elimianting bounds checking or direct memory access could be very useful...
Simplicity: Java is considered simple precisely when compared to C++, not to C. A well-architected solution in C++ is possible, but considerably more painful to achieve than a well-architected equivalent in Java.
Garbage Collection: You are utterly wrong there. There's no such thing as "third party GC tools for Java". You might be extremely confused because different JVM implementors boast their own GC as a great feature. It's not even possible to plug a 3rd-party GC engine to ANY Java VM or compiler I know of. And safe GC in C++ depends on enforcing restrictions that break 99% of the legacy code and 3rd-party libs around, and performance will likely be inferior because C++ was not designed for that, and of course we will still live with manual memory mgmt (yet another hybrid situation to make things complex and risky).
Standard Libraries: Yes, there's a huge number of excellent, even multiplatform, libs for C++. And how good are they when they're not standards? How many C++ GUI libs do any experienced developer waste time learning, porting... along the years? Ever heard about reuse? (hint: if component O1 uses L1 do do X, and O2 uses L2 to do the same X task, you have either trouble or bloat if you need to use both O1 and O2).
Bounds checking on arrays: Agree. Now, go fix all 3rd-party and legacy code that you rely on and was implemented without boundschecked arrays and exposes raw arrays in public interfaces. Once again, Java's advantage is not that I can do something the right way, but that everybody does it the right way.
Printing stack traces from exceptions: You can always spend your money and/or time (if you have the necessary discipline) to use C++ libraries and code instrumenting debuggers. Java does it for free, easy, and every time. Add this to the safer typesystem, bounds checks, library checks and you know why so many Java developers never use any debugger.
Reflection: This is hilarious. C++'s RTTI is pitiful compared to Java's reflection -- in the same measure that Java's is, compared to Smalltalk's, but I don't think you have minimal experience in metaprogramming.
> Your premise is compeltely off. To restate the above: "Java shouls run code tuned for C++ as fast as C++."
You completely mis-respresent what I say, then refute it. What I'm saying is people should not believe your statements wrt performance because they are false , do your own testing.
> In general java today is MUCH better at in-lining then ANY C++ compiler
So why is it only 1/5 the speed ?
> It is at this point I believe an undisputed fact that a Java coder can write correct code faster then a C++ coder.
Totally disagree. I have been coding Java for 5 years and C++ for 9, I have written a commercial application consisting of 30,000 lines of Java. I first learned Java when 0.9 was released. I'm not some fucking novice.
Several people who's opinion I respect insist that they can develop stuff faster with Java than with C++. If they really know C++ I just don't understand this, unless they are comparing old (pre-STL) C++ with modern (post-collections)java. The other possibility is that they have been using MFC, a piece of code so vile, that I can barely speak it's name.
I can see that if you're working on a project where (2 or more apply): threads are important; has to work on multiple platforms; requires functionality that JDK library classes cover well; is deployed over the internet; speed is not an issue; memory useage is not an issue; very precise control is not important; some team members are inexperienced;
then Java may well be the best choice.
However for implementing arbitrary fresh functionality I can develop far faster in C++ than java. For instance a fragment of a C++ program that reads in a file and gets a list of the starting positions for every word in the file:
Writing the equivalent in Java would take 20+ lines.
Now, I admit this is a contrived example, but do it the other way round - give me a nice piece of algorithmic code in Java and I believe the equivalent C++ will almost always be considerably smaller, and thus easier to grasp. Java is good the beginners, there are fewer pitfalls, but as a language it's just almost entirely a subset of C++.
well... i think it's because borland didn't really jar up their classes very well.... seems like they didn't preserve case so the IBM VM can't load em... weird....
it would have been nice to run the slow ass jbuilder ide on ibm's vm as it is *really* fast;-)
anyone know how to fix it btw ? =o)
Re:Great job IBM -- acknowledged
by
Sayjack
·
· Score: 1
Thanks for all the information. Like you, I don't place too much stock in benchmarks, especially ones existing prior to product implementations. Volano specs also demonstrated a performance difference, though it should be noted that Volano server produced a thread dump when running versus IBM JDK 1.3. The closest test I could run to a pure 1.2.2 w/inprise jit versus IBM 1.3 was to have the server run 1.2.2 w/ inprise with varied clients. IBM still produced superior numbers though not as pronounced as the previous test. It was about 25% faster (sorry I don't have the actual data handy).
--
-- Good judgement comes with experience.
-- Experience comes with bad judgement.
Re:Very few good C++ programmers...slighly OT
by
DoofusRufus
·
· Score: 1
Thanks for the forum. For an old fart newbie who has just popped the hood on programming, reading these comments makes dry text juicy.
Keep the flow going, and maybe my late life education will bloom./:)
--
'Looking back to a better day, feeling old and in the way.'
-David Grisma
Slashdot Mirror
So now Java Swings both ways? :)
http://kered.org
I think the best way to get java really doing well would be to have compilers ported to individual platforms, as you could get rid of the speed disadvantage. Until that point, java is too slow for anything i'm using it for.
it's java. if there's one buzzword you gotta know... okay, maybe java isn't it, but it's still pretty useful to know. i'm just glad linux is getting this support for java. it took sun long enough to make a jdk for it.
I haven't downloaded it yet, but I hope native threads can make it in this release. It hurts running my Java apps in Linux while the threads run like they're in Windows 3.1.
No.. Java 2 = Java 1.2
IBM just released Java 1.3... so they're in step.
It's nice to have a fast java 2 jvm for linux. But what about VAJ 3.02 (enterprise edition) and websphere 3.02. :-(...
I still used NT because of this two software
I'm waiting for you IBM guys !
Just in time, i've got a java application to deploy on a new linux server i'm building on friday, and this'll be the JDK for me. Previously i would have used SUN/Blackdown 1.2 with the borland JIT compiler. Heres the servers spec (gloat), AMD Athlon 850 (last one with the pluto 2:5 cache), ABit KA7 motherboard, 4*256 PC100 ECC SDRAM (hey Its a server you got to go for reliable memory over fast memory.) IBM 30Gig 7200rpm ATA66 disk drive, 3Com Etherlink 3 100-Base-T networking card, Voodoo 3 3000 (just goes 3dfx does linux drivers). After testing we'll be using it as part of a server farm (with a lot of the same spec machines) for our search engines, at www.remotesearch.com P.S. Got any good keys for freenet.
Good job, IBM. It's wonderful that support is so forthcoming. Though naturally, when someone says ``available for Linux,'' they really mean ``available for Intel Linux.''
Users of all other Alpha Linux are screwed. PowerPC Linux. UltraSPARC Linux.
Oh well, that's the real world, isn't it? It'd be nice if there at least was some source code to play with on other architectures. But that, naturally, isn't forthcoming.
GNU GCC currently ships with a pretty decent Java compiler, that can be used with libgcj in order to write native apps. I have no idea how complete libgcj currently is.
you're thinking of java 2 platform. java 1.2 was java 2 platform. so this 1.3.0 ibm release is also java 2 platform.
Would you feel better if everyone said: "Me too!!!! Java sucks!!!
Any guesses what they'll come up with when they feel it's time to change numbering again? The logical next step would be shifting the significant digit further to the left, yielding Java 30 or Solaris 90, wouldn't it?
Of course Java does have the one benefit of being ostensibly platform independent. I mean you can't say everyone should move to C, C++, whatever, because there is nothing to currently compete with Java. Maybe if something appears in competition the way it works may be optimized.
Very cool, very cool...
The Blackdown 1.2 JDK runs JBuilder3.5 ass slow (not that I don't appreciate it guys... it's far better then most Mac support I've seen)
It will be good to have something all super-quick like IBMs 1.1.8 JDK.
Right on, you guys rock!
---
I wear pants.
jdk 1.2 *IS* java 2 silly.
JDK 1.2 was re-named Java Platform 2 as part of the re-arrangement of the Enterprise, Standard and Micro editions. See SUN's Java site for more information on this, and the differences between the versions.
IBM are definitely at the head of the queue for this one !
I'm looking forward to being able to use some critical Java Platform 2 features, and remember this is the enabling technology for Enterprise Java Beans...
Before Solaris 8, there was Solaris 7...
"You know you want me baby!" - Crow T Robot
As a programmer, one thing Java is lacking is hardware acceleration of windowing widgets.
In any OS worth mentioning standard windowing calls (such as pulling down a menu or pushing a button) make specific calls to the video hardware. Sun's JVM, however, does not accelerate swing components, relying instead on your CPU to draw them.
There is no reason the VM cannot make calls to specific hardware, as we all know they're written for specific platforms. In fact, I am told that the VMs for Sun's OS ARE accelerated. This is either just plain lazyness on their part, or a ploy to increase the popularity of their OS.
"Hey, buddy. You like that Swing Office Suite? Well, it runs 30% faster on a Sun workstation..."
Does anyone else see this?
http://kered.org
Yeah, the Sun way of counting, like Solaris 2.7 followed by Solaris 8.
No.. like Solaris 2.51, Solaris 2.6, Solaris 7, Solaris 8.
It's now up to SunOS 5.8 if I'm remembering my Sun versioning...
Maybe we need to send some Sun Marketing types back to kindergarden to learn to count!
-What have you contributed lately?
Oops, right, so it was 2.6 -> 7, still a funny way of counting.
Although IBM's 1.1.8 JDK was by far the fasted VM available for linux [aside from native compiling towerJ] it's native threads' implementation was not nearly as efficient as Blackdown's. IBM uses a mixed-mode JIT, which ends up ( in my experience) considerably faster then even Inprise's JIT plugged into Blackdown's VM for single thread loads. However, under heavy multi-thread loads, IBM's VM acctually underperforms blackdown's vm considerably. You can tell their threads implementation is a bit "funny" because when a system running the IBM JRE is under heavy load, the entire system becomes unusable, --even if the load average is only nearing 2. The mouse becomes extreemly jerky in X, console commands take 3-5 seconds to execute, all this with 5 active threads. Verses with blackdown's VM I've had 40 active running threads, and the rest of the applications run just as responsivly as you would expect linux to. I suspect IBM did a bit of cheating, and toyed iwth the priority threads were being issued, such that IBM VM threads end up being the highest priority to run. This gives them a bit of an edge when it comes to single threaded benchmarking; but once the IBM VM threads start competing against eachother.. it all falls to bits. I wonder if they'll fix that in 1.3.
...yet there is method in it.
Solaris 7 == Solaris 2.7
Java 2 == Java 1.2
I also wanted to see if I should think otherwise or if I wasn't alone in my thoughts about java.
Does this release go any way as to bridge the gap between the native GUI and applets which are being run under the JVM? I'm not expecting full support for all the features KDE/Gnome/whatever provide, just the option of using the Widgets from the relavent toolkits, hence inheriting Theme support and the like.
Still, it's great news for other Linux Java developers, I'm sure, and it makes me glad to know that Win/Solaris aren't the only ones anymore.
When will Apple catch up? They still don't have a Java 2 JVM yet. MacOS X will bring that, true, but have they even begun work on a 1.3 JDK?
This whole debate has been gone over again and again. If you want your components implemented in native code and hardware accelerated, use AWT. If you want really flexible components that look pixel-identical on every platform and have all kinds of cool features that your graphics card can't accelerate, use Swing.
And what's wrong with Sun making a fast VM for Solaris? There's nothing stopping you from joining the Blackdown project and doing the same for Linux.
Java on web pages was a stupid, stupid idea. Java as a non-GUI, server side solution is a viable idea. Just because org.lame.StupidApplet is slow in your browser is no reason to count out a nice language.
Well, I'm glad to see they did release a 1.3 compiler, but whatever happened to a 1.2 compiler? I think IBM's getting version-skipping happy. Not that I'm complaining, just curious.
;)
Thanks to IBM, it may one day be reasonable to run Java Servlets/JSP's for a web page
-What have you contributed lately?
This is cool and all, but what I want to know is when Mozilla for Linux will ever get Java support. Apparently nobody's come in with a JVM to drop in, and Sun's been pretty silent about whether they will provide one or not for Linux...
surak_at_my-deja.com, using Mozilla build 2000050308 without a clue about whether it will crash when he attempts to post this comment.
From the License Agreement:
2. Term and Termination
This Agreement will terminate ninety (90) days after the date on which you receive the Software. Upon such termination you will delete or destroy all copies of the Software.
Darn. I'd better delete my copy on day 89...
...just to be safe
Or better yet - maybe I just won't download it at all.
I notice that you've failed to mention the obvious requirements of a _real_ server: - redundant disk drives (ie. RAID) - redundant power supplies - multiple network cards and adapter teaming - multiple processors - tape backup Also, if you're going to deploy this wonderful app of yours on a brand new JVM without testing, you are crazy. It doesn't sound to me like you've ever seen a real server...
By the time I've posted this, I bet there'll be half a dozen posts saying that Java is crap, Java is slow, moan, groan, Java can't be used for low-level system programming etc. Oh well, if you can't beat them, join them... Java is great, it'll replace C for all high level programs :)
Seriously, I wonder how much of the opposition to Java from many C programmers is due to the amount of experience they've accumulated in C? It's bound to make people resentful [disclaimer: I've spent the last 18 months learning Java in university]
Well, Java is a proprietary and Mozilla is fully open source and Sun is a bit antsy about opensourcing Java. I've heard about some projects to reverse engineer Java, but mozilla is a corp. entity and they tend to get a bit antsy with legal issues...so... :(
I this this would be useful, too, but I don't see many people working on Gtk+ or Qt lookalike PLAFs for Swing. A notable exception is the Skin Look & Feel, but it doesn't seem to be progressing very quickly.
Swing does however support 'look-n-feel' classes, and Sun ships looks and feels for Windows, Motif, and 'Metal' (which is the most aesthetically pleasing, IMNSHO). O've also seen a decent BeOS LnF. Theoretically, you can write a look-n-feel that knows how to use the same pixmap sources the KDE/Gnome/whatever themes. That exercise is left to the reader :^)
I'm voting for Java e^i*Pi
Kudos to IBM for providing this environment (even if it expires after 90 days). Note: also thanks to the Blackdown team who have done an excellent job in less than excellent conditions to provide excellent tools that I rely on now.
A note on Java:
This is actually a huge boon for Linux. Look at it this way...Linux provides an excellent (cheap and stable) platform on which to develop Java applications. I'm not talking about applets here...I'm talking about large / distributed software systems. I'm building one in a research setting right now using CORBA that's up to 40 KLOC.
I develop entirely on Linux using XEmacs, CVS, and make. For everyone who argues that there isn't a good Java development environment for Linux (article seen recently on ZDNet), that talk is for the birds. These are perfectly good tools that have been proven in the trenches writing code for the guts of the internet, UNIX, C/C++, and thousands of other packages / programs. If you want an environment that handles drag & drop JavaBeans, servlets, etc, go buy a fast box with 256 MB memory and JBuilder. The tool works just fine...just put the horsepower behind it. This isn't to say that XEmacs could be useful for the average Joe programmer (VB developers-come-Java programmers). It does take some tinkering, but there are good develoment environments out there. Anyway, what does a good environment provide you that you can't accomplish with a shell, some scripts, and syntax highlighting. Nothing as far as I've seen except bulk, sluggishness, and programmers who don't understand the fundamentals of development and rely on the tools to find their problems (a poor way to program).
Linux provides a great platform for this kind of development, though, and the gains realized are immense. I can run my object servers spread across the network and virtually guarantee that my clients can run on Mac, Solaris, Linux, and even Microsoft as long as the appropriate Java runtime is installed. Remember, this is an application not an applet! The Swing toolkit is slow and has a huge memory footprint, granted, but there are also some fabulous Swing tools out there (NoMagic MagicDraw UML comes to mind).
I'm not getting religious here; I use Perl, Tcl/Tk, and C/C++ when appropriate. All I'm saying is that Java has its place, and a great toolkit like this one from IBM goes a long way to advancing the Java development capabilities of software developers who won't pay for SPARCs or Windows and want a customizable, robust, and fast environment.
So, knock off the hatred of Java, find some good development tools, and use it for what it's good for (use Flash for providing animations in web browsers), as a full featured applications development language with thorough APIs. It's not perfect, but it has its place in a development toolkit.
Kudos to IBM. Keep up the good support.
Is it just me, or are the only java applications are development tools. Where are the java applications that were supposed to tranform the computer industry it's been five years now.
As some of the postings throw everything together, there is 1) Java the OOP language, there is 2) the huge runtime library of classes and 3) there is the virtual machine that interprets the byte code OR the compiler that creates a native executable from either bytecode or source code.
:-)).
So, if speed is a problem, try compiling into a native executable. What's new (compared to C, as an example) is the fact that no platform-dependent problems will arise when programming, so you don't have to do a thousand ifdef checks to see how large an int variable is. If it wasn't for these nasty problems, C would also be a great platform-independent programming language (well, not great
The RTL is a huge plus IMHO - all basic stuff is already there and it works.
First, your points are spot-on when it comes to C versus Java. When comparing C++ to Java, though, many of your issues go away.
Simplicity: a well-architected C++ solution, which intelligently uses the appropriate features of the language, is just as simple as Java. In fact, Java borrowed most of its simplicity from C++ in the first place.
Threading: Okay, this one is granted.
Garbage collection: Contrary to popular belief, Java's GC isn't exactly the best thing since sliced bread. There's a fairly large industry providing third-party garbage collection tools for Java. Can't remember any of them off the top of my head, but I do know that some of them are wealthy enough to afford full-page ads in Communications of the ACM.
Bjarne Stroustrup has also said that GC will likely be implemented in the next ANSI draft of C++. While that doesn't balance C++ and Java, it does mean that you're comparing no GC in C++ to a somewhat broken GC in Java. Neither one is an optimal solution.
Standard libraries: Are you at all familiar with the STL and free (liberty) C++ libraries? The advantage of Java isn't that it has every function under the sun; it's that the collection which ships with the JDK is very comprehensive. C++'s body of free (liberty) libraries is far superior, but you have to search for them.
I also have a slight objection to your use of the word "standard". There is no Java standard; therefore, there can be no standard library. C++ has been standardized; Java isn't.
Bounds checking on arrays: C++ includes this. It's included this for quite some time. It's not possible to bounds-check a C array, but it's trivial to bounds-check a C++ container (list, vector, etc.).
Printing stack traces from exceptions: Look around the free (liberty) C++ libraries. I'd be extremely surprised if you couldn't find one.
Reflection: C++ includes this. It's called RTTI (run-time type identification).
... I am not trying to denigrate Java or elevate C++. I've used both, and I have no clear favorite between the two. Java borrows very heavily from C++, and it constantly surprises me at just how many Javagrinders say "well, C++ doesn't have features foo and bar!" without realizing that Java borrowed foo and bar from C++.
That said, it is incredibly difficult to become a good C++ programmer. The language is straightforward, but has extremely complex nuances which require years of exposure to fully comprehend. Java is a much more straightforward language, but occasionally the lack of nuance makes it difficult to achieve subtle hackery.
We did some speed comparisons between IBM's 1.1.8 JDK and the 1.2.2 JDK from Blackdown/Sun/Borland and found the 1.2.2 platform to be significantly faster. Now, our tests were centered around using JRun behind Apache, but using the Apache Servlet Killer program, the 1.2.2 JDK held up a lot longer under load than 1.1.8 did. (shrug) We haven't tried the 1.3 JDK yet as it's a flippin' HUGE download (~60 megs) but it'll be interesting to test it out in the same way.
James
You can still use the old account, but someone changed the password.
Java is good for designing end user systems, where the real work is done by the database. Java is good for doing websites, again, where the real work is done by the database. I'd like someone to show me an example of real software(i.e word processor, database, game, compiler, OS) that is written in Java. Silly Yahoo games don't count.
C and C++ on the other hand do that stuff well. I wouldn't want to use them for a website, however.
No, Thursday's out. How about never - is never good for you?
The numbers are ops per second for a P-266 running RedHat 6.2 and Resin 1.1 as a standalone HTTP/servlet engine and using 4 clients.
The Apache 1.3.12 number is just for comparison.
Scott Ferguson
Scott Ferguson
Caucho Technology
This whole thread is built on a misconception. Modern Java VMs, such has Sun's HotSpot on Windows or IBM's 1.1.8, produce code that is as fast or faster then that produced by static compilers. Some things to understand: (1) Java code IS compiled. Its just compiled at run-time rather then build-time. The result is the same however-- machine code running on your machine. (2) JITs have a number of advantages over static compilers: (a) A static compiler must compile for a lowest common denominator platform (typicly Pentium). A JIT can determine the processor type at run-time and produce processor-tuned code. (b) A static compiler must "guess safe" in situations where code is ambiguous. A JIT can go ahead and take risky optimizations because it can un-optimize if the need arises. One place this occurs a lot is in in- lining. The static compiler can only safely in-line finals. The JIT can try to in-line anything and adjust by how the code actually gets used. (HotSpot calls this "agressive inlining" and you can read about it at the HotSpot section of java.sun.com) Simple fact. For raw computation that doesn't incurr array bounds checking, Java is as fast or faster today then C/C++. (And static compiling doesn't help you with the bounds checking penalty.) There are some actual experiemntal numbers and a chapter discussing this and other Java v. native code issues in "Java(tm) Platform performance: Strategies and tctics" coming out at JavaOne. (Its already up for pre-order at amazon...)
This whole thread is built on a misconception.
Modern Java VMs, such has Sun's HotSpot on Windows or IBM's 1.1.8, produce code that is as fast or faster then that produced by static compilers.
Some things to understand:
(1) Java code IS compiled. Its just compiled at run-time rather then build-time. The result is the same however-- machine code running on your machine.
(2) JITs have a number of advantages over static compilers:
(a) A static compiler must compile for a lowest
common denominator platform (typicly
Pentium). A JIT can determine the
processor type at run-time and produce
processor-tuned code.
(b) A static compiler must "guess safe" in
situations where code is ambiguous. A
JIT can go ahead and take risky
optimizations because it can un-optimize
if the need arises.
One place this occurs a lot is in in-
lining. The static compiler can only
safely in-line finals. The JIT can
try to in-line anything and adjust by
how the code actually gets used.
(HotSpot calls this
"agressive inlining" and you can read about
it at the HotSpot section of java.sun.com)
Simple fact. For raw computation that doesn't incurr array bounds checking, Java is as fast or faster today then C/C++. (And static compiling doesn't help you with the bounds checking penalty.)
There are some actual experiemntal numbers and a chapter discussing this and other Java v. native code issues in "Java(tm) Platform performance: Strategies and tactics" coming out at JavaOne. (Its already up for pre-order at amazon...)
According to some of the early reviews on
http://www.javalobby.com
Sun's 1.2 for Linux beats the pants off of IBMs 1.3 for GUI apps.
While a good java kit is good news anyway, I think it's important to emphasize this in the article. We still don't have a good free java kit for linux!
> . The optimizations performed as not nearly as >aggressive as static compilers try, why ? >Because at runtime you cant afford the time >penalty This statement shwos a compelte lack of understanding about what HotSpot does. HotSpot focuses the compilation effort on the code that gets most used ( the "HotSpots") and thus has the time to do all the optimizatiosn it needs. The actualy optimizatiosn are actually MORE agressive because Hotspot can guess agressively in ambiguos optimization situations and back those optimizatiosn out later if they prove wrong. I gave a more complete, but still brief, explaination of this in the top thread -- look at the message titled "Misconceptions." More detailed theoretical information can be found in white papers at java.sun.com in the HotSpot section. A whole section on the real life costs/benefits of Java code v. native code (including real world measurements) is in the book "Java Platform Performance: Strategies and Tactics" which will be released at JavaOne next month. (
(a) A static compiler must compile for a lowest common denominator platform (typicly Pentium). A JIT can determine the processor type at run-time and produce processor-tuned code.
That depends largely on your environment and how widely you plan to disseminate binaries. Where I work, we regularly compile codes where we need good performance with the highest possible optimization targeted to the specific CPU type on the machine, but we're hardly a typical shop.
Simple fact. For raw computation that doesn't incurr array bounds checking, Java is as fast or faster today then C/C++. (And static compiling doesn't help you with the bounds checking penalty.)
That's a pretty bold assertion. What kind of "raw computation" applications were these: number crunching, DB access, GUI desktop apps, what? Also, what architecture or architectures were these comparisons done on? If you're talking number crunching, will it outperform a good optimizing Fortran 77 or Fortran 90 compiler? (Note: Neither g77 nor the Sun Fortran compilers constitute a "good optimizing Fortran compiler". I'm talking about something like the Portland Group's Fortran compilers for IA32 or the SGI MIPSpro Fortran compilers for MIPS. Compaq's Visual Fortran may or may not qualify; I've never used it.)
The reason I ask is, I work in high performance computing, and I deal with trying to optimize codes all the time. I find it difficult to believe that JIT compiling is the panacea you describe it as, but if you've got numbers to back it up I'd love to see 'em, if for no other reason than to dissuade our physicist users from trying to program in C++...
"My life's work has been to prompt others... and be forgotten." --Cyrano de Bergerac
Following Sun's lead would probably call it Java 3!
Java's libraries are so deeply nested and full of synchronization code that its unlikely that Java programs will ever in actuality match C code.
(Sorry, I accdientally posted as HTML and silly slashdot wont let me delete and repost when that happens nor add another response beneath so I had to up here.)
Troy,
The basic numbers are in the book I mentioned. They are somewhat annecdotal but based on real world problems (like calculating a Bresenham line.) If you want to email me at jeffpk@iname.com I can probably dig you up some "harder" test type numbers.
I would have to be honest and say that I don't knwo enough about FORTRAN compilers to answer your second question. Its possible that FORTRAN creates such trivial linear code that a lot of the value of run-time analysis goes away.
There is anoter issue with older languages though that is particularly obvious when benchamrking java v. hand crafted assembly.
The REAL performance gains in any program of signifcant size can be found not in the byte crunching but in algorthim selection and tuning. This is very hard to do in lower level languages. The compelxity of the problem quickly becoems the dominant conrolling factor.
An object oriented langauge like Java makes isolation of functional units clean and easy, resulting in a much more tunable program.
So while I wouldn't say a modern JIT produces tiny amounts of code better then a processor espert could hand code (though its getting damn close to equal), and I don't knwo enough about FORTRAN to comment intelligently on its code generation, I AM confident in saying thawt Java today is as good or better then C/C++ and is more easily debugged and tuned.
SO given a fixed amount of time to do a non-trivial program, I'd lay money I could get a faster runnin result in Java then any other language I know of.
I just ran a CaffeineMark on my PC versus the jdk1.2.2 supplied by SUN versus the new jdk1.3 supplied by IBM. SUN's caffeinemark was 444, while the IBM JVM scored a whopping 6,309. This is an amazing performance difference.
-- Good judgement comes with experience. -- Experience comes with bad judgement.
Hotspot is not even as fast as decently written C/C++. Show me one such benchmark and I'll tell you how rigged it is.
Now I am not saying that the approach is wrong. JIT compilers indeed have a promising future. But Hotspot is not there today. Maybe next year, maybe in 5 years will a JIT compiler beat a good Java to native compiler with profile feedback.
And when this JIT appears, you can apply most of the same ideas to C and get it to run still faster than Java... (shipping an ANDF-like format)
Note that I am not dismissing Java. IMHO 95% of most applications should be written in Java or even higher-level languages (smalltalk, Dylan, etc.), 90% of the rest in C and a few lines in assembly (if needed).
HotSpot drasticly reduces the cost of syncrhonization, such that you are only paying it where threads are actually going to collide.
Still i agree with you that synchronization should always be doen minimally and ideally by the programmer.
As far as I am aware, Java2 lets you do this. If there are places that are still over-synchrinized I'd like to hear about them.
So Bruce was trolling. But I get so sick of this crap every time there is a Java story on Slashdot...
I'd like someone to show me an example of real software(i.e word processor, database, game, compiler, OS) that is written in Java.
Yeah, except most lines of code aren't written for apps like that. Try buisiness systems in major companies. Have a look at IBM Websphere, BEA Weblogic or Oracle8i or any of several dozen other similar products. You know - stuff used by real businesses.
Just becuase Java isn't used by 20 dorks a day to write a CD player front end and put it on freshmeat doesn't mean it isn't used.
Do you even know anything about perl? -- AC Replying to Tom Christiansen post.
At my work, we're using java (quite successfully) in a system which generates over a million legacy system accesses a day, formatting the results through use JSP as well as DCL (a small perl-like language written in java). The system does millions of dollars of business a day in a mission critical atmosphere. Java delivers great performance for us and minimizes development time.
-- Good judgement comes with experience. -- Experience comes with bad judgement.
IBM wants to sell more hardware. IBM doesn't sell Sparc or Alpha hardware, so those would clearly be silly ports (they'd just help Sun and Compaq, who are direct competitors).
As for PowerPC, maybe IBM would consider a port if they saw a substantial number of serious, enterprise customers buying PPC hardware to run Linux. But, frankly, very few people are doing that right now. It is NOT just an issue of "grab a PPC and compile", because much of a good JVM's performance comes from a good JIT. JITs are, of course, highly architecture-specific.
And, as for their failure to distribute source, remember that they license code from Sun (it's not a true "clean room" JVM). Thus, at best, they could consider a SCSL license. Remember how popular the SCSL was? But then Sun (public enemy #1 for IBM right now) would get the benefit of all their JVM enhancements (and IBM has PLENTY). Doesn't sound like a compelling business case.
--JRZ
I'll admit that is one of the more unpleasant cases, but I've made an attempt to outline a strategy I'd use - basically to get around your issue with multiple return values from a method call I'd either return a Map or pass in a Map ( or Object[] ) that I could fill with values. This could also be a list but I tend to like the named entries in a Map.
// store connection
// ------- Build call string
// loop through args adding "? ," for each arg listed
// ------- Register parameters
// Get out list of parameters for this call, this info could be cached // Schema // Whatever "all" pattern is
// Build the call to call
// Go through the meta info about each function parameter to set parameter
// types and values
// gets In, out, in/out, or returnVal
// Based on the parameter flow, do what we need to. Probably remember
// return type for out params and return value.
// add this parameter index to list of OUT params
// add this parameter index to list of OUT params
// now that all the parameters are set, call the procedure
// go through result set adding any results to the map
// Go through each OUT paramater stored in our list of OUT paramindexes
// Add parameter to result map, perhaps by name "Param[i]Result"
// If you want to flow back through objects passed in the object array,
//just get them out by index and either set values (if mutable object) or
//create new object and put that into the passed Object[].
// map full of results
Below, I have some code and some pseudo code in comments outlining one way that you could do something like what you want to do - it relies on database metadata information to pull out parameter types and help map what you are sending into it.
It also takes a connection to build this object, I've found in general it's a pretty good idea to pass connections to JDBC helper objects of this sort as you can easily share one connection across multiple helper objects, you get to manage the commits, and you can close when it's the right time. You can also build up multiple helper objects connected to different data sources which is nice.
Here's an example use of the helper class:
Connection conn = DriverManager.getConnection(...);
ProcedureCaller caller = new ProcedureCaller( conn );
Map resultMap = caller.callProcedure( "myProc", new Object[]{ myArg } );
String myResult = (String)resultMap.get( "Param2Result" );
int myResult2 = ((Integer)resultMap.get( "Param3Result" )).intValue();
Admittedly, it does not look a lot prettier than the code you already had - it does let you do multiple calls through one wrapper object and I think the call itself is pretty clean [you could even go so far as to add callStatement(name, arg1), callStatement(name, arg1, arg2)... to ProcedureCaller though I don't like the look of it for some reason!] and it lets you get to the results pretty easily.
I think if I were writing this for myself I'd pass in a ordered Map instead of an Object[] so I could provide names for in and out paramaters to get them out of the result map in a more meaningful way.
You could also provide a bit more useful type of Map wrapper that helped in obtaining primitive values by automatically unwrapping primitives from the objects returned in the map. (like an [int getInt()] call in the map).
The code below at the end does not do the type translation bit much at the end - I was assuing calls to getObject() that would stuff the results back into the result map with essentially the same type as the database. One could provide a custom map as well, which might be nice to get back Timestamps instead of Date objects if you want to keep the whole value of your Date object!
I also assumed the use of JDBC 2.0, though I think you could do most of this with just a bit more work in a JDBC 1.1 driver...
Here's the code for the helper object (terribly unoptimized!! Assume a GPL license for the whole post)
public class ProcedureCaller
{
public ProcedureCaller( Connection conn )
{
}
public Map callProcedure( String procname, Object[] args )
{
StringBuffer call = "{" + procname + "( ";
call.append(" }");
String catalog = conn.getCatalog();
ResultSet dbFunction =
conn.getMetaData().getProcedureColumns( catalog,
""
procname,
""
);
CallableStatement cs = conn.prepareCall( call );
short columnOutness;
short columnDataType;
int i = 1;
while ( dbFunction.next() )
{
columnOutness = dbFunction.getShort( "COLUMN_TYPE" );
columnDataType = dbFunction.getShort( "DATA_TYPE" );
switch ( columnOutness )
{
case DatabaseMetaData.procedureColumnIn:
cs.setObject( i++, params[i] );
break;
case DatabaseMetaData.procedureColumnInOut:
cs.registerOutParamter( i, columnDataType );
cs.setObject( i++, params[i] );
case DatabaseMetaData.procedureColumnOut:
cs.registerOutParamter( i++, columnDataType );
}
}
ResultSet procResults = cs.executeUpdate();
{
}
return
}
}
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Also have a look at VisualAge Micro Edition. It's a Java IDE (geared toward the embedded world) written in Java. http://www-4.ibm.com/software/ad/embedde d/
--- One world, one chance Doc.
Sun marketing be damned, the main reason to use Java is not portability, it's development time. Versus C or C++ my productivity at least tripled and for certain kinds of applications (network servers in particular) it's way, way better than that. And that's been pretty much the same story for everyone else I know using it, too. Furthermore the bug counts are way, way down and the bugs tend to be irritating rather than debilitating (ie throw an exception and keep running rather than dumping core).
Swing and AWT could use a lot more maturity but if you don't need a GUI, or you only need a basic GUI, Java is awfully nice for building applications.
More speed I can definitely use but realistically speaking we're building some damn fast servers with Java, stuff that runs rings around the C++ competition, even using the Sun 1.1 JDKs. When you're building the code three times as fast you have a lot more time for optimization!
jim frost
jim frost
jimf@frostbytes.com
Caffine is an old Benchmark.
m l
Its is possible you are running into the "on-stack replacement" issue in the JDK1.2 version of HotSpot. This is a problem that only affected micro-benchamrks, not real apps, but was fixed in 1.3 anyway because it was confusing people trying to mesaure things.
There's a discussion of it here:
http://java.sun.com/products/hotspot/1.0/Q+A.ht
It's been mentioend a few tiems. (Okay its been mentioned a few times by me, and once or twice by others ;) ) That niether Volano or Caffine are terribly realistic benchkmarks. I've suggested SPEC a few times. Here's where to get it: http://www.spec.org/osg/jvm98 All my cautions about not trusting ANY synthetic benchmark overly much still apply.
Download them from this directory
Hey, when the JDK1.3 will become stable, Java may become a real usable solution for both client and server!
:-) :-) Good!
From my POV, Java was a really poor solution:
JDK1.0 was poor in many respects, 1.1 was better but still buggy and AWT is a braindead API (yes, I know that Swing could be used indepently of the JDK1.1.x), the JDK1.2 contains vastly improved APIs but they were quite buggy for a looong time (the bugParade was full of bitter complaints, Sun was constantly adding new API but bugs weren't corrected).
The JDK1.3 seems to correct many,many bugs from the bugParade
I've been burnt badly by Java in the past: for me it was hyped to death while still being very imature (from a client point of view anyway).
The Sun's JDK1.3 is still in the Release Candidate status (if I remember correctly, it was supposed to be released in January), and IBM's JDK is a beta release.
When they finally become stable release, I think that I will take another look at Java.
For anybody listening to this BS, I suggest you actually do some experiments yourself. Java and C++ are close enough that it's quite easy to compile virtually identical code in both. There are too many lies told by both sides and ymmv depending on what you're doing.
I typically find Java runs at 1/5th the speed of C++ (using latest compilers). My own results correlate closely with http://sprout.stanford.edu/uli/java_cpp.html
Listening to what Sun says about Java v C is like listening to what Microsoft says about W2k v Linux.
Your arguments are fine theoretically, they're just false in practise. HotSpot is not nearly that good yet.
http://rareformnewmedia.com/
Perhaps if they had a more understandable syntax, Java wouldn't be so bad. I downloaded the latest JDK a few weeks ago and tried in futility for 20 minutes to get a Java program compiled. It just didn't want to accept anything that I wrote. Unfortunately, I can't recommend Java to the Man in THe Street until they work on the syntax, because it's really finicky and unfriendly.
no sig
On the other hand, some standard libraries (like Swing) have performance problems that can't be fixed just by throwing in good code generation, and the JVM still fails to make use of hardware acceleration wherever possible -- a world-class JIT compiler will compete with a static compiler, but never with dedicated hardware (e.g. for 2D graphics). And there's a lot to do on platform-specific tuning (AWT, threads, memory mgmt, I/O).
This is only to make things clear, as I guess all the previous replies should originate from people thinking "duh, so why does it still look slow here".
But just to add another plus, array bounds checking is not a problem. Both Symantec's and IBM's latest JIT compilers seem to do a great job in avoiding these checks or moving them out of loops. In IBM, this is not even an issue anymore. And you still have full safety! Compare this to a C/C++ program that aims to be safe while doing lots of arrays -- it needs manual boundchecks (more likely, encapsulated by some array class's operator[]) and these checks can't be removed by an optimizing compiler as much as Java's can (hint for C fans: pointers). IBM has a ton of research to make Java *the* language for number crunching, and they have already shown very exciting results (up to 90% of FORTRAN performance).
Here's something I thought I'd throw out there. First, a bit of a disclaimer. I'm no MS VB weenie that likes Java because it's simple to use. I prefer coding in assembler and I do so quite often when appropriate (I reprogram the ECU in my car, for example). However, I also happen to really enjoy coding in Java. It's the most "pleasant" coding environment I've ever used in the past 15 years; period.
I'm a big fan of the "learn one thing well and become an expert on it" approach to life. I focus on something that I know is going to be powerful and/or popular in the future and I learn it well. Java is that thing when it comes to coding.
I learned about vi while in college (about 5 years ago). I thought it was weird and awkward to use, but because it was everywhere and because I could focus on honing my skills with that one editor and be proficient on so many different platforms with it all at once, I learned it. Now I know that editor very well and I happily co-develop under Linux, Solaris, HP, AIX, and even windows with it.
Java is the same type of thing. I learned Java, I learned it well, and now I code peacefully on all those same platforms (sans HP and AIX...I just haven't used those in a while). I've written a datalogger in Java using Swing for my car that works in conjunction with the aforementioned ECU reprogramming effort to provide me with real time data gathering while I'm powering around at the track. What's great is that I did ALL my development under Linux. When it was all done, I slapped the exact same jar file under Windows NT for a friend of mine with a similar car (didn't even have to recompile it!) and it ran flawlessly. He prefers Windows, I prefer Linux.
Why on earth would I have ever considered writing that application under anything but Java? If I had used MFC, I would not only still be pulling my hair out trying to figure out what the hell was wrong with it, but I also would be forced to use Windows when I was done. The same is true if I had coded it using Motif or GNOME/Gtk or most any other X-based environment. I could not have shared that application with friends that happen to like Windows.
That's one of the many benefits of Java; and it's one of the benefits of vi. Learn something that's powerful and flexible once, learn it really well, and you end up reaping benefits from it on a variety of different platforms. Java is quite powerful and I'm happy as hell to see IBM doing all the great work they're doing with Java under Linux!
Ridiculous. Garbage collection alone is enough to make Java slower than C/C++. Then, there's the penalty of translating (compiling?) Java byte code into machine code. No matter what you claim, this is an extra step that takes extra time. "Compiled at run-time" means time spent compiling at run-time.
Java is a good language with an incredible library. It's easier and faster to write code in Java than in C/C++ but the tradeoff is run-time performance. It's ideal for business applications that need to run on multiple platforms. But it is not appropriate for performance-critical tasks. You will not see Java used to write operating systems, device drivers, and high-end 3D games. It's just too slow.
This should be obvious stuff. I only write it down here for readers who might not know that the quote above is just flat wrong.
It does indeed, just as 1.1.8/Linux/IBM.
/ Peter Schuller
--
peter.schuller@infidyne.com
http://www.scode.org
at least in a few simple tests I did. Hotspot on Win98 outperformed gcc-2.95.2 there, especially in memory management (object allocation/deallocation).
Arrays were a little slower than C (about 10%). Integer calculations the same speed.
And I cannot help people that still believe that Java is slower than Perl...
While this notion of 'real software' strikes me as flamebait, I'll go ahead and bite.
I recently came accross JEdit. Its a pretty cool Java text editor.
You might want to try Ganymede, which is an extensible directory management system written in Java. Oh, and it's a database too.
You can also look at java.sun.com for a bunch of stories about web sites that use Java on the back end.
The java compiler is written in java.
Mike
++ Say to Elrond "Hello.".
Elrond says "No.". Elrond gives you some lunch.
I've used Javascript, but my fear of slowness has kept me away from using Java for anything serious. However, I admire Java for its simplicity. I have Eckel's book "Thinking in Java" and the thing that attracts me most to it is his statement that Java would enable people to be "software craftsman" rather than operating system hacks. The language itself seems to have gotten rid of a lot of things that make C++ painful to program in.
So actually, I am interested in trying Java seriously. I just wanted some good examples of what it can do.
No, Thursday's out. How about never - is never good for you?
Okay,
I've now seen a bunch of real-world benchmarks that more or less explain what everyone has seen. They're internal numbers that I can't release, but in general...
The 800: 6200 (approx 8x difference) v. jdk1.2 seems reasonable on purely computational things. This confused me until I remembered that Linux is the one place where the jdk1.2 ISN'T hotspot. This is a classic v. much more modern VM comparison. Hotspot can be expected to perform similarly when released on Linux.
The varying GUI numbers are explained by the fact that it performas somehwt differently on different GUI tasks. A few its very good at now, some it still needs some work on.
In general, on Linux IBM 1.1.8 is still beating JDK1.2.2 and IBM 1.3 respectably in most GUI things. IBM 1.3 is kicking repectable rear in non-gui tasks.
Others have already reported some scaling issues with 1.3 I don't have tests for those.
You're absoluely right that therr are library problems. Alot of them have to do with implementation details, which are being worked on. (Anoyone whose tried Swing under JDK1.2 v. the 1.3 thats currently out has seen the results, and there are better thinsg still in the works.)
A few of them have to do with the nature of the libraries as very high-level, idiot proof things. Lower level facillities are gradually appearign in java. I've been playing with java for games myself, and as part of that I've written JNI to talk to DX directly. Doing that, Java easily flips frames at the limit of my video-synch (70hz) on my PC.
There are a few key things missing from Java for real ultra-high performance stuff. A number of these are being added... I can't say much more now but I'll gladly post abotu them when they are public. (Actually, when one of them is public, I'll be able to finish and post my DirectJava library, which I intend to make open-source.)
Now I hate to disagree with someone whose on the same philisophical side... but I need to disagree with you on bounds checking. Unless you know of some approach I don't, AFAIK there is no way to eliminate it from random-access reading and writing of arrays.
What you mentioned about loops is called "hoisting" and yes this is happeneing, but an array implementation of a stack, for instance, must still check every access to make sure its within the memory area of the array proper. We have to be careful not over-sell hoisting and lead people the wrong way in their programming.
Simplicity: Java is considered simple precisely when compared to C++, not to C. A well-architected solution in C++ is possible, but considerably more painful to achieve than a well-architected equivalent in Java.
Garbage Collection: You are utterly wrong there. There's no such thing as "third party GC tools for Java". You might be extremely confused because different JVM implementors boast their own GC as a great feature. It's not even possible to plug a 3rd-party GC engine to ANY Java VM or compiler I know of. And safe GC in C++ depends on enforcing restrictions that break 99% of the legacy code and 3rd-party libs around, and performance will likely be inferior because C++ was not designed for that, and of course we will still live with manual memory mgmt (yet another hybrid situation to make things complex and risky).
Standard Libraries: Yes, there's a huge number of excellent, even multiplatform, libs for C++. And how good are they when they're not standards? How many C++ GUI libs do any experienced developer waste time learning, porting... along the years? Ever heard about reuse? (hint: if component O1 uses L1 do do X, and O2 uses L2 to do the same X task, you have either trouble or bloat if you need to use both O1 and O2).
Bounds checking on arrays: Agree. Now, go fix all 3rd-party and legacy code that you rely on and was implemented without boundschecked arrays and exposes raw arrays in public interfaces. Once again, Java's advantage is not that I can do something the right way, but that everybody does it the right way.
Printing stack traces from exceptions: You can always spend your money and/or time (if you have the necessary discipline) to use C++ libraries and code instrumenting debuggers. Java does it for free, easy, and every time. Add this to the safer typesystem, bounds checks, library checks and you know why so many Java developers never use any debugger.
Reflection: This is hilarious. C++'s RTTI is pitiful compared to Java's reflection -- in the same measure that Java's is, compared to Smalltalk's, but I don't think you have minimal experience in metaprogramming.
How is Java syntax is not understandable?
Sorry, but Java syntax is straight C, with "."'s for object methods.
If you want messed up syntax, try VBScript.
Now that is one screwed up language.
() are not allowed on method calls unless there
is a return value AND you are using it? Who thought of this?
(appended to the end of comments you post, 120 chars)
> Your premise is compeltely off. To restate the above: "Java shouls run code tuned for C++ as fast as C++."
You completely mis-respresent what I say, then refute it. What I'm saying is people should not believe your statements wrt performance because they are false , do your own testing.
> In general java today is MUCH better at in-lining then ANY C++ compiler
So why is it only 1/5 the speed ?
> It is at this point I believe an undisputed fact that a Java coder can write correct code faster then a C++ coder.
Totally disagree. I have been coding Java for 5 years and C++ for 9, I have written a commercial application consisting of 30,000 lines of Java. I first learned Java when 0.9 was released. I'm not some fucking novice.
Several people who's opinion I respect insist that they can develop stuff faster with Java than with C++. If they really know C++ I just
don't understand this, unless they are comparing old (pre-STL) C++ with modern (post-collections)java. The other possibility is that they have been using MFC, a piece of code so vile, that I can barely speak it's name.
I can see that if you're working on a project where (2 or more apply):
threads are important;
has to work on multiple platforms;
requires functionality that JDK library classes cover well;
is deployed over the internet;
speed is not an issue;
memory useage is not an issue;
very precise control is not important;
some team members are inexperienced;
then Java may well be the best choice.
However for implementing arbitrary fresh functionality I can develop far faster in C++ than java. For instance a fragment of a C++ program that reads in a file and gets a list of the starting positions for
every word in the file:
map > word_positions;
string word;
while (cin >> word)
word_positions[word].push_back((int)cin.tellg() - word.size());
Writing the equivalent in Java would take 20+ lines.
Now, I admit this is a contrived example, but do it the other way round - give me a nice piece of algorithmic code in Java and I believe the equivalent C++ will almost always be considerably smaller, and thus easier to grasp. Java is good the beginners, there are fewer pitfalls, but as a language it's just almost entirely a subset of C++.
http://rareformnewmedia.com/
it would have been nice to run the slow ass jbuilder ide on ibm's vm as it is *really* fast ;-)
anyone know how to fix it btw ? =o)
Thanks for all the information. Like you, I don't place too much stock in benchmarks, especially ones existing prior to product implementations. Volano specs also demonstrated a performance difference, though it should be noted that Volano server produced a thread dump when running versus IBM JDK 1.3. The closest test I could run to a pure 1.2.2 w/inprise jit versus IBM 1.3 was to have the server run 1.2.2 w/ inprise with varied clients. IBM still produced superior numbers though not as pronounced as the previous test. It was about 25% faster (sorry I don't have the actual data handy).
-- Good judgement comes with experience. -- Experience comes with bad judgement.
Thanks for the forum. For an old fart newbie who has just popped the hood on programming, reading these comments makes dry text juicy.
/:)
Keep the flow going, and maybe my late life education will bloom.
'Looking back to a better day, feeling old and in the way.' -David Grisma