Fast, Open Alternative to Java

DrInequality writes: "For those of you out there who admire the portability of Java but want something faster or open source, the answer to your prayers is finally here. The Internet Virtual Machine is open source, fast and supports C, C++, Java and ObjectiveC. There are some cool demos for Linux (requires Redhat 6.0 or above, and OpenGL 1.2 or Mesa 3.41) here (1.5MB) and for Windows (requires glut32.dll, here) here (1.5MB)." We mentioned this last year; perhaps it has improved. I'm sure a lot of people would be interested in a language as portable as Java but speedier.

Comments

A fried of Mono?

[Whyte Wolf]

COuld this possibly be useful with Ximian's Mono project, or Gnu.NET? I could imagine using this as a VM for C# could seriously PO M$ :)

Re:A fried of Mono?

[RevAaron]

A quote penned by a retard, seeing how it's incorrect. If I said "Creationism is true in every and any sense of the word!" you could quote me- but that wouldn't make it any less incorrect, or you any less stupid.

Re:A fried of Mono?

[barneyfoo]

Ximian isn't interested in staking new ground. THey want a sure thing. THey are a company in need of money. They want C# because they think it will be a new revenue source in which they can make a name for themselves.

Java is full of weenies mark(et)ing their territory already. No room for ximian. Poor ximian, so badly in need of revenue. what for-ever shall they do? C# Ah yes. Ride on teh back of microsoft. maybe they are wiser than me, for I would be too scared. (offtopic, OSU was kicking tonight! I am so druNK! Fsxk me! hahahha ahahhahah. It aint the 4th biggest party school in the US for nothing!)

I wonder...

[L-Wave]

"Our vision is to bring the Internet Virtual Machine to the Internet completely, enabling video games, interactive entertainment, and applications to be operated from the Internet on your browser or television"

I wonder how secure they expect this to be? I know I wouldn't want to run an Accounting program (or anything similar) via the internet. Does anyone have any experience with the code to share info?

Re:I wonder...

[small_dick]

In the future, there will be middleware.

I don't know how else to put it. The laws, the technology...everything is going to middleware.

Java, C#, this product...a better question is : how will i find apps that don't run off the internet?

Answer: a computer museum. I'm totally serious.

It crashes on RedHat Linux 7.1

[BlowCat]

I downloaded the binary and it crashed on RedHat Linux 7.1 with all updates and kernel 2.4.9-ac10. It looks like that it's the library loader that crashes, because even ldd icvm dumps the core.

Sorry, I have no time to download 23M of compressed sources to compile it. But if it crashes for you, you probably have to.

Re:It crashes on RedHat Linux 7.1

[MarkusQ]

I kinda hate to say it, but a lot of stuff crashes under 7.1--at least, a dozen or more apps that ran fine under older RH (and seem to work fine on other distros) core dump. etc. on my RH 7.1 box. Mostly it's been glibc incompatibilities and such, but still rather anoying if you don't have the time to chase it down. So this may not be a problem with the IVM per se.

-- MarkusQ

P.S. Who the heck moderated the parent "offtopic"?

Re:It crashes on RedHat Linux 7.1

[barneyfoo]

Lol. And why do you think anyone on slashdot should care? Mmmm Beta software doesn't work for person X. Maybe I shouldn't try it. Yeah! Great, thanks for passing on the gewd wh0rd (goat speak - yes, I am durnk)!

Re:It crashes on RedHat Linux 7.1

[BlowCat]

Of course it's not a problem with IVM, if ldd crashes. ldd should never crash. It's a libc problem (or the kernel, but it's less likely).

Sorry, I keep forgetting that an average /. reader cannot figure it out.

Faster?

[silicon_synapse]

Java is already comparable to C/C++ in speed. It has made a lot of improvements over time. I think the key to better speed now lies more in better code than in a better virtual machine. I can't see this gaining a significant acceptance. It'll probably do it's job well, but there needs to be some pretty compelling reason to move away from java.

Re:Faster?

[spiro_killglance]

Java is no where NEAR the speed of C, java makes everything High level and must be run through in an interpreter in order to run (which is most of the slow down).

But if the interpreter is a highly advanced on
the fly optimisating JVM like in Hotspot, you
may well find its optimising your code to a native
binary than you C compiler does. Have you tried
Java 2, v 1.4 beta 2 yet?, a lot of Java slowness
was not due to the JVM but due to badly designed
I/O and String classes. Additions to Java 1.4
add a Native Input/Output libraries for much
faster access, and move powerful access such as
mapping a Buffer to a region of a file.

Re:Faster?

[Waffle Iron]

Java is already comparable to C/C++ in speed.

Well, the actual situation depends very much on the abstraction level of the program being implemented.

JIT compiled Java is kind of strange because it is competeitive with C++ at both low-level (bit banging primitives) and high-level (dynamically allocated objects). However, in middle ground (nontrivial objects that can be allocated solely on the stack), C++ blows Java away. This is mainly because all Java data that is not a local primitive variable must be dynamically allocated.

As an example, one concept that is on the border between mid-level and high-level abstraction is strings:

If you use C++ at a nice comfortably high level of abstraction (i.e., with some implementations of STL's std::string), it can be significantly slower than Java because of construction and destruction of every function parameter. OTOH, if you write your C++ program in a painstaking and dangerous C-like fashion (using one stack-based buffer for a string across many levels of function call), it can be an 1 or 2 orders of magnitude faster. If you bang on strings alot, a language like Perl can be a good choice because its mutable strings are more efficient than Java and safer or easier than C/C++.

(Aside: In my experience, a rule-of-thumb is that most dynamic memory allocations in any language seem to take on the order of 1000 CPU clocks, and most dynamic "objects" end up consuming about 1000 bytes.)

Of course, at the end of the day, all the issues that I just raised pale in comparison to the importance of the basic structure of your algorithms. If you feed in 50X times your expected load into your application, it will often slow down and/or eat memory in a spectacular fashion. By recoding to eliminating that problem, you can often make a "slow" language outperform "fast" one. This is often done by identifying the portions of your algorithm that depend on input size and perform worse than N*log(N) in space or time, then recoding them so they don't.

The upshot: it all depends.

Re:Faster?

[eric17]

Well I've never had a compelling reason to move TO java, so I think perhaps there is a group of people like me that have different needs than the group of people who find Java compelling.

Perhaps Java is _too_ dynamic, _too_ simplified, and _too_ rigidly held by its creators for certain developers. On the other hand C++ is annoyingly crufty, but does let us do stuff that Java will not, and is not controlled by any one company. Java's design prevents many forms of optimizations, and there will always be programs that are impossible to write in Java with anything near C++ speeds. Java can beat C++ in some forms of code where its design does not prevent good optimizations. On the other hand there is a separate but smaller set of optimizations (and associated cruft) that C++ can't perform because of its forced compatability with C and old style linking.

Perhaps IVM will allow someone to build a language that jetisons the cruft from C++ without removing the power, perhaps not. While the JVM design prevents this from happening, the IVM does not seem to prevent it, AFAICT.

Re:Faster?

[quintessent]

Have you ever programmed with swing? It's just painful.

Re:Faster?

[cabbey]

That would just be because Swing is broken by design. It's terrifying to think that a bunch of unix geeks could come up with something that is just that horribly broken. If you want a snappy java gui just use the remnants of AWT and ignore all the deprecated warnings, or pick up one of the java to native widget libraries that are floating around the net.

Re:Faster?

[MarkusQ]

...if you write your C++ program in a painstaking and dangerous C-like fashion (using one stack-based buffer for a string across many levels of function call), it can be an 1 or 2 orders of magnitude faster...

There is a general principle at work here: you can quite often go one or two orders of magnitude faster if you are willing to give up safety. It applies to everything from sex to ice hockey, and (viewed at the right level of abstraction) the results are always pretty much the same.

-- MarkusQ

Re:Faster?

[kryps]

How nice it may sound, some things in this comment are just not true:

JIT compiled Java is kind of strange because it is competeitive with C++ at both low-level (bit banging primitives) and high-level (dynamically allocated objects). However, in middle ground (nontrivial objects that can be allocated solely on the stack), C++ blows Java away. This is mainly because all Java data that is not a local primitive variable must be dynamically allocated.

Objects that are used only in the function in which they are created can be allocated on the stack if no references to this object are returned/passed as arguments. In fact recent VMs (Sun 1.3.1, IBM 1.3) do exactly that.

If you use C++ at a nice comfortably high level of abstraction (i.e., with some implementations of STL's std::string), it can be significantly slower than Java because of construction and destruction of every function parameter. OTOH, if you write your C++ program in a painstaking and dangerous C-like fashion (using one stack-based buffer for a string across many levels of function call), it can be an 1 or 2 orders of magnitude faster. If you bang on strings alot, a language like Perl can be a good choice because its mutable strings are more efficient than Java and safer or easier than C/C++.

Well that is what the StringBuffer class in Java is for. StringBuffers are very fast for this kind of thing. While I have to admit that Java immutable Strings make it easier for the developer too generate code which performs poorly it is well possible to produce (text processing) code which performs really well.

Aside: In my experience, a rule-of-thumb is that most dynamic memory allocations in any language seem to take on the order of 1000 CPU clocks, and most dynamic "objects" end up consuming about 1000 bytes.)

Your numbers are just wrong at least for recent Java implementations. Object allocation is very fast in languages using a generational garbage collector because allocating an object just consists of increasing a pointer by the size of the newly generated object. On the other hand the time needed for object deallocation has to be considered. The cost for deallocation is highly dependant on the number of live objects and the way objects are created. If the way objects are created is "compatible" with the generational GC (i.e. most newly created objects are short-lived) deallocation is very fast as well. Example: Object creation takes about 60 CPU cycles (JDK 1.3.1) on my Athlon 1200 if the objects are discarded directly after creating.

I don't know where you got the "1000 bytes per dynamically allocated object" number from. In JDK 1.3.1 each object has an overhead of 16 bytes.


Of course, at the end of the day, all the issues that I just raised pale in comparison to the importance of the basic structure of your algorithms. If you feed in 50X times your expected load into your application, it will often slow down and/or eat memory in a spectacular fashion. By recoding to eliminating that problem, you can often make a "slow" language outperform "fast" one. This is often done by identifying the portions of your algorithm that depend on input size and perform worse than N*log(N) in space or time, then recoding them so they don't

With this I have to agree.

-- kryps

Re:Faster?

[X]

Some things you got wrong:

1. All Java data that is not a local primitive variable must be dynamically allocated.
2. Dynamic memory allocations in any language seem to take on the order of 1000 CPU clocks.
3. Most dynamic "objects" end up consuming about 1000 bytes.

1. I presume by this you actually mean stack allocated, as opposed to dynamically allocated (it's certainly possible to define statically allocated objects). While on one hand objects are meant to appear to be allocated on the heap, IBM has done a great deal of research on using linear analysis to allocate linear objects onto the stack. Works great.
2. Allocations in the HotSpot VM can take only a few instructions, much like stack allocation. Unlike C++ you don't have a heap that you are constantly trying to keep balanced and unfragmented.
3. Objects in Java are quite small. Indeed they have to be smaller than the 1K that you claim they need. Try allocating a million objects in a system with less than 1GB of memory. You'll find it works just fine. Again, with a compacting garbage collector, you don't have to worry about all the overhead associated with heap management which causes objects to be bigger than they need to be.

It seems to me your programming prejudices are tied to experiences with C++. If you learn the Java paradigm better, you'll discover that a lot of the performance trade-offs you learned in the C++ world don't play out the same way in the Java world.

Re:Faster?

[mj6798]

However, in middle ground (nontrivial objects that can be allocated solely on the stack), C++ blows Java away.

What you are complaining about there is that a particular coding style you are used to from C++ doesn't carry over to Java. However, there are reasonable, alternative ways of expressing the same kind of code in Java. They aren't ideal (and Java isn't perfect), but they are workable.

(Aside: In my experience, a rule-of-thumb is that most dynamic memory allocations in any language seem to take on the order of 1000 CPU clocks, and most dynamic "objects" end up consuming about 1000 bytes.)

That may be a good rule for C++ (whose storage allocators generally have high overhead), but in a language like Java, a good implementation should have about one word of overhead for a large object and no overhead for small objects, and it should take about as much time as one store on average per word of storage allocated. The current JDK is a bit worse, but it still seems to beat most C++ allocators.

Re:Faster?

[mj6798]

I have experince in all three languages, Java is no where NEAR the speed of C

Sure it is, but it's harder than in C. Basically, in C, it's easy to write code that runs fast, but it's hard to write code that's correct and robust. In Java, it's easy to write code that's correct and robust, but it's hard to write code that runs fast. If you invest enough effort, you can write code that runs fast and is correct in either language. Which language makes the better tradeoff? 20 years ago, the choice was clearly C. On today's hardware, the choice is pretty clearly Java.

[Java] must be run through in an interpreter in order to run (which is most of the slow down)

Sun's JDK and IBM's runtime both are compiled implementations; they run Java at machine speeds, not interpreted.

Re:Faster?

[greenrd]

What's broken about it? They didn't do enough optimisation on it until this year (1.4), sure, but that's not a fundamental external API problem, just an internal design problem.

Re:Faster?

[cabbey]

AWT widgets map directly to the native widget sets for almost all platforms: Windows, Mac, Unix (Motif in many cases). This allows the windowing system to do all types of optimizations, and minimizes the complexity of the application, as well as the volume of information it needs to send to the display.

Swing by contrast maps all the way to pixels within the JVM. This not only prevents the native optimized windowing system from having any advantage, but nearly always degenerates into full frame bitmaps being pushed for every refresh. While it is true that IBM is pushing a lot of performance tweaks into 1.4 to try and work around this, there really isn't any way it will ever catch up with awt.

This is not a problem on windows where applications can get direct access to the hardware to push a pixel image down, but on most other operating systems this simply isn't the case. X is particularly hard hit in this, have a look at a swing application running under xscope to really see this.

Java was promissed to be a platform independent environment, but it has become clear that Java's GUI team only cares about Windows. Sadly by the time this was discovered a lot of applications had already been coded and deployed. Within my company for example an entire toolchain was developed before anyone had discovered this, and the impact of widespread use on the network had been discovered. The result is that the large unix boxes that the applications are run on have been set up with VNC servers and the users have vnc clients on their thin client machines because it's compression and selective redraw logic does such a major improvement over raw swing.

This is more than just an internal design problem, it's a core architectural issue because Swing was *intentionally* designed to work this way, doing all the widget rendering (and font rendering, and focus management, and ...) in the JVM so that it could present the same (bit for bit) gui no matter the platform. While they have reached that goal, it has been at a cost... while all java based applications can look and feel the same, it also means that none of them really blend in with the other applications on the system, infact they stand out as "differnet" and sometimes "broken" in the user reactions. An end user (who else are applications written for?) usually wants something that integrates with their platform, they don't care what we used to implement it. This is why I say swing is fundamentally flawed by design, unfortunately most of AWT has been deprecated.

Re:Faster?

[cabbey]

From a UI designer perspective I fully agree with you; however, that wasn't what I was talking about.

The front end of swing is nice, but the backend behind it is FAR worse than AWT, and unfortunately, because of the other promises swing made about having the same user impression no matter the platform means that there really isn't any other option.

Re:Faster?

[cabbey]

Actually I've seen the parts that *aren't* freely available and dealt with the so called "support" organization they put together, so I know you're being polite in your understatement. ;)

DotGNU

[bstadil]

The DOTGNU guys has already looked at it. From Carsten Kuckuk via the MAilinglist

Quote

I printed out the spec last night and read it on the commuter train back
home. The IVM team essentially created a specification for a Motorola 68000
like 32 bit processor, assigned 16 bit opcodes to instructions and
implemented an interpreter for it as well as an adoption of the gcc
compiler.

Advantages:
+ Portable
+ It works
+ Very fast

Disadvantages:
- No separation of data and code
- Interface to the underlying operating system is POSIX
- No built-in security, not even a sandbox

My assessment:
o Good piece of Engineering: It's there, it works, it solves a problem, it's
GPLed, it's tested.
o In order to be used as one of the VMs for DotGnu, security needs to be
added. As one of the rules in secure programming is that you can never add
security to a system, but that it needs to be designed into it, I don't know
if that is possible.
o For my personal taste it's too close to real untyped assembly language.

Carsten Kuckuk

Unquote

Four 32-bit integer registers?

[idiot900]

Looking at the description of the VM, I see only 4 general-purpose 32-bit integer registers - which seems like a rather shortsighted limitation to me. Seems like this VM is designed to be easily dynamically-translatable to x86 code - but there are plenty of other (better designed) architectures with more registers that IVM could target...seems like a waste to me.

This is a neat idea - but isn't this essentially a clone of what Amiga's been doing with their universal VM?

Re:Four 32-bit integer registers?

[b0rken]

That's right -- the "internet virtual machine" seems designed to map well onto a single CPU, the x86.

The standard library seems designed to map well onto a single OS, Unix.

You can run it on your big fancy RISC machine (well, if they've gotten around to writing a stable back-end), but it'll still approximate the performance of a register-emasculated ia32 processor.

It's a bit more portable than an Linux ELF binary, but not much. And about as revolutionary, given that a Linux runtime also exists on the modern BSDs (for example)

Re:Four 32-bit integer registers?

[Russ Steffen]

Why even bother with registers at all? Hardware CPU's use registers as because they are bits of faster memory, but that isn't necessary in a pure virtual machine. Unless you're trying to model a real CPU, why screw up the acrchitecture with unnecessary registers. Just have it do everything on the stack. In an all software VM, regsiters buy you nothing but unneeded compiler complexity.

What about C#?

[tshak]

What about C#? Many Java and anti-Java advocates have come to a common ground that C# is a great language. It's fully OO and very easy to code in. MS has submitted the spec to the ECMA, so isn't this possible?

Re:What about C#?

[Graymalkin]

If Microsoft submitted it to the EMCA that means the GCC folks can compile it. Whether or not you can use Microsoft's libraries has nothing to do with whether or not it's portable.

Re:What about C#?

[Waffle Iron]

Could someone _please_ explain to me how this got modded as a Troll???

Probably because they said "C# is a great language". The adjective "great" is so overused in MS literature that the original poster is obviously a paid MS shill. A genuine /. complement would have said something more like "I ported all of emacs to C# in 3 days and it's rock solid running on my Amiga and BeOS boxen".

Re:What about C#?

[Graymalkin]

You dumb piece of horseshit. If a language is posted for standardization that means anyone can write their own compiler and distribute it without paying royalties. It isn't a technical hinderance but a legal one. Why don't you think before you write dickhead.

Re:What about C#?

[WasterDave]

Couldn't agree with you more. It's a good language, Microsoft invented it, nobody uses it. So bite me, no troll here.

Dave

Re:What about C#?

[Graymalkin]

I didn't say it was useful for anyone but Microsoft for fuck sake. Can you fucking read? I was responding to the glaring inaccuracy of the guy's statement. He berated the original poster saying C# was some sort of magical Microsoft-only language which it isn't. Besides, the entire reason for Mono (Ximian's .NET runtime) is to run .NET apps open source style. So your C# apps don't end up in the shitcan if you're not using a Microsoft OS. Jesus man get the net.

Re:What about C#?

[Waffle Iron]

Don't worry, I was employing irony.. (noun: the use of words to express something other than and especially the opposite of the literal meaning)

Except about the word "great"... Microsoft's overuse of the word has almost ruined its meaning for me. I can't read it without seeing an image of Bill Gates.

(Actually, I haven't used C#, but it looks reasonable enough. The main problem I see with it from looking at MS example snippets is that this "attribute" stuff tacked into the syntax to do COM stuff seems to be out of control. A couple of examples I saw had more of that in it than real code.)

Re:What about C#?

[tshak]

But they also submitted the CLR - doesn't that contain many of the essential libraries?

Re:What about C#?

[quintessent]

Oops. That was an anti-Slashdot post. Here: Microsoft Sucks!

Re:What about C#?

[11223]

Really? Every term I hear "great" I see this puke-inducing image of Steve Jobs shouting "Insanely Great!"

C++ vs. Java all over again.

[under_score]

Okay - this is a "religious" issue. Building and promoting for C++ works up to a point. But the fact is that C++ and Java are both industrial strength languages (especially if you consider their libraries and tool support). It seems that the IVM does C++ "natively" but requires an extra step for Java etc. Why? Can't it just figure it out from the context? The file extension? The syntax? This IVM seems to be a pretty cool idea. Not new, but cool (IBM's UVM). I like the fact that they bothered with Objective-C (although that might just be because I believe the GNU GCC supports it).

Re:C++ vs. Java all over again.

[Malcontent]

Actually there is something called internet c++ I haven't played around with it much but it sure looks interesting. Does anybody have any experience with it? It looks like a pretty good idea.

Re:C++ vs. Java all over again.

[Dixie_Flatline]

Objective-C has been supported by GCC for a long time. In fact, the NeXT Obj-C compiler was a hacked up version of GCC.

In any case, I think Obj-C support was added because Obj-C is finally being used again. With OSX, Obj-C is seeing a small resurgence. It's about time.

Execute cross-platform code with native speed

[goingware]

If you'd like to execute your code with native speed on any platform from a single sourcebase, why not use a cross-platform application framework?

Here is a list of many application frameworks, many of which are cross-platform, and many of which are free software.

My favorite is ZooLib, a multithreaded C++ framework.

Read about the importance of cross-platform application development.

Re:Execute cross-platform code with native speed

[iapetus]

If you'd like to execute your code with native speed on any platform from a single sourcebase, why not use a cross-platform application framework?

Because then you either have to recompile for all platforms and provide binaries for all of them (along with suitable installation instructions/programs) or you have to make your source available. The former is a pain, since the whole aim of writing truly cross-platform software is that it can run on any platform, not just those you happen to have development tools for. The latter may not be desirable (not all software is open source, you know) and causes hassle for people who don't feel they have the skill to compile code from source and install it.

Well, you asked...

Re:Execute cross-platform code with native speed

[iapetus]

You may be the last person on this planet to learn that WORA (in java at least) is a complete myth for non-trivial software.

Complete myth? Hardly. Many programs (the majority of real-world code IME) will work straight off. Of course if you're going to have to support it, particularly under heavy use, then you'll expect people to be using it with a specified and tested JVM and platform. They call it WOTE for a reason, you know. ;) And unless you're utterly insane the same is true for cross-platform libraries of any level of complexity. If I tested my program with FooLib 1.2 on Red Hat then I'm not supporting you using FooLib 1.3b on OS X.

Java does allow you "to just write the code once and ship it to all your customers", provided you make it clear that the only supported versions are the ones you've tested against and they run it on other versions/VMs/platforms at their own risk. And anyone who needs to run it on a different platform will be able to, and 99% of the time it will work just fine provided the code was well written in the first place. The same can never be true of binary distributions using shared libraries.

Of course WORA doesn't work perfectly - it's one of the first things I point out when teaching Java. But you seem to be painting a picture of a world where Java code needs to be carefully targetted at particular platforms and will fall over if you try to run it elsewhere, and that's even further from the truth.

You could distribute your app as "shrouded source" which is just machine obfuscated source code.

Which does nothing for those users who aren't happy recompiling from scratch, and doesn't do much to appease the boss/lawyers/project manager who is hung up on the idea that it's a bad plan to let customers see our source code in any form.

C++, Java and Objective-C

[under_score]

I have used Java and Objective-C professionally in a very extensive manner, and a little bit of C++. I think they are all great, but I feel more friendly to Objective-C :-) It is great to see that the IVM people have bothered with it. It would be really fantastic if they made it so that you could inline any language inside any other. The big difficulty with this is that the three languages (C++, Java, Objective-C) have fundamentally different ways of "implementing" objects, particularly method calls, but other aspects as well. Objective-C provides more flexible run-time typing and meta-class objects. Java has decent security, exception and threading built in (decent, not great). C++ has operater overloading, friends, etc.
Check out my Courselet: Architectures with XML Documents

Re:C++, Java and Objective-C

[Malcontent]

You bring up an intersting point. How fast is objective C and why aren't more people using it?

Re:C++, Java and Objective-C

[bnenning]

Fast. Method invocations take (I think) about 3 times longer than normal C function calls, and if that becomes a problem in a tight loop (which is rare) you can cache the function pointer for a method and use it to bypass the dynamic lookup. Unfortunately Objective-C mostly got overlooked due to the momentum of C++, but hopefully Mac OS X and GNUStep can change that.

Java *is* open source

[magic]

The original post was misleading.

Java is open source, at least for practical purposes. Sun has released the source to the entire Java standard library. IBM's Jikes is one of the best Java compilers available (it is more reliable and faster than javac), and is available with full source.

Open source doesn't just mean the GPL! The GPL trouble more often than not because most companies won't get within miles of it for fear of legally contaminating their sources. The important thing is getting provided source code to be seen as a standard, not a wierd alternative. With Java, the source is provided and is really useful.

I wouldn't put Java and C# in the same boat as far as "proprietary". You can't fork the Java code base directly, but Sun is really responsive to the community. Most new libraries are incorporated from user built packages, and all new features go through a community review. The bug database is open to the public. Sun provides open source repositories like jxta.org to help the community. Sun is the good guy... C# is Java Microsoftified and is evil (although a decent language) because it won't have this kind of community interaction and open source.

-m

Re:Java *is* open source

[oops]

This is a perfectly fair comment, despite the replies it's received already. I use the API source to answer queries from programmers I work with, resolve issues wrt. performance/usage etc. From my clients perspective (big banks, usually) this is perfectly adequate. They're not going to want to modify the source. They invest in Java to have a maintainable code base that does (to any practical degree) run anywhere.

The Sun developer connection is responsive. I vote for bugs to be fixed (3 at one time). In the last 3 weeks I've had three issues resolved.

One of my developers came across a threading issue last month. It's resulted in Sun's kernel people, Java people and threading people banging their heads together and finally issuing a bug fix in the form of a new JVM for us to test. Once we've confirmed that it's a fix, it'll go into the main branch.

Is it GPL ? No. But from a big business perspective, there are other more important issues.

Re:Java *is* open source

[egomaniac]

Hmmm. I'm using Jikes with 2000+ file programs, no problem. I'm not using Ant, so maybe that's the issue, but I can assure you that Jikes has been able to handle *really* big programs for years.

Re:Java *is* open source

[cabbey]

Java is open source, at least for practical purposes. Sun has released the source to the entire Java standard library.

Not really, last I checked the sun.* packages have not been released, and the packages that have been released are under the equivalent of MS's "shared source" license.

IBM's Jikes is one of the best Java compilers available (it is more reliable and faster than javac), and is available with full source.

Why thank you. But Jikes is more a result of Sun having attempted to standardize Java, we work from the two pubished specifications for the language and the virtual machine, not from anything released under the SCSL. (aside: we're also in need of more active developers.)

Open source doesn't just mean the GPL! The GPL trouble more often than not because most companies won't get within miles of it for fear of legally contaminating their sources. The important thing is getting provided source code to be seen as a standard, not a wierd alternative. With Java, the source is provided and is really useful.

hmm... well that's true, however, a more important aspect I've always felt was what you can *do* with the source. With the SCSL for example if you find a bug in a given class you can't distribute a fix without violating the license. The best you can do is submit a bug telling them how to fix it, then hope it eventually get's incorporated.

The bug database is open to the public.

Um, not entirely. You don't get 100% view of the bugs, even in the community source area.

Some quick thoughts. (No sound, GPLed)

[BrookHarty]

The demos are nice and small, very impressive. Ill need to try this on my linux box in a few moments. (Looks like from the /. posts is crashs on some redhat installs..)

No sound, but its still in beta, so things should be added. The most impressive thing, is IVM is GPLed! No pesky Sun or Microsoft License! Now give me a QNX, Ipaq and Gameboy Advance IVM and im set!

Re:Source?

[BlowCat]

You didn't look carefully. The source is here.

Re:Faster -- with evidence

[Leeji]

Okay.. Here's a few things. First, about the original statement, "Java is almost as fast as C." I agree, with evidence.

In terms of raw computation, let's dump some equivalent C and Java. I tested these on my schools large Solaris box.

int main(void)
{
float x = 0;
int counter;

for(counter = 0; counter < 10000000; counter++)
x += (counter / 3.14159265359);

printf("%f\n", x);

return 0;
}

[11:29pm || 24](~)> date && compute && date
Fri Sep 14 23:29:06 EDT 2001
15969064845312.000000
Fri Sep 14 23:29:11 EDT 2001
(5 seconds)

public class Compute
{
public static void main(String args[])
{
float x = 0;
int counter = 0;

for(counter = 0; counter < 10000000; counter++)
x += (counter / 3.14159265359);

System.out.println("" + x);
}
}

[11:29pm || 26](~)> date && java Compute && date
Fri Sep 14 23:29:53 EDT 2001
1.59690648E13
Fri Sep 14 23:30:02 EDT 2001
(9 seconds)

I did this a few times, and the general trend continues.

What also kills Java performance is lazy programming. People tend to use vectors (high-maintenance linked lists) when native arrays will do. Or they'll store a load of information in a Vector, then repeatedly search through it (in O(n) time). If they had any mind for performance, they'd use a native O(logn) data-structure like a Treeset. People use Treesets (a sorted, tree-like data structure) and then re-sort them. Or worse, if they can't find a sort() method for their specific object-type, they'll hack together a bubble or shell sort.

The only place that Java beats other languages is the API. Large enterprises have a Java fetish *not because it's portable*, but because their almighty productivity numbers go through the roof. Where a C++ programmer has to code (or buy) linked lists, b-trees, hashtables, sockets, etc, Java wraps it neatly into the language core.

Second, answers to your peeves :)
1) Typedef = class!
2) Constants only require "final int foo". The public keyword only makes your constant visible to other classes. You don't need this if you define the constant in the class you're using it. The static keyword simply lets you use the variable without having to instantiate the class. Again, you don't need this if you define the constant in the class you're using it.
3) You only have to use parseInt() to take an int from a string. I'd say the equivalent atoi(...) in C is just about the same!

Cross platform?

[bay43270]

I know Java isn't very popular here, but I have to say this... (I guess I wasn't going to be able to spend the karma on Christmas presents anyway) I think this is a bit insulting to the people at Sun to say IVM is cross platform. Cross platform means a lot more than just being able to run on more than one OS. Think about internationalization support. Does the ability to swap out text in the GUI constitute internationalization? No. Currency, calendars, colors and many other issues make up internationalization. The same principal applies to cross platform support. Sun spent a lot of work grappling with issues such as how to provide the programmer with an operating system independent environment. They deal with memory management, threads and display capabilities in ways that work consistently from a kiosk to a cluster of Alphas. They spent a lot of time dealing with j2ee, making sure the application server environment was swappable. They spent a lot of time working on platform independence in general, and I think its insulting to Sun to say that slapping a virtual machine under a compiled language is any more than a small part of the platform independence offered by Java.

Re:Cross platform?

[egomaniac]

I've been able to switch my application between different app servers in about five minutes.

What sorts of problems are you running into?

Re:Faster -- with evidence

[Spankophile]

Do you realize what you're doing when you type:

System.out.println("" + x);

Probably not, so I'll tell you.

First of all, you instantiate a StringBuffer class, which is used to concatenate the "" and the x. Then the StringBuffer is used to create a String object. Then you rinse and repeat to the tune of ten million. That's a LOT of allocating.

As anyone who does Java knows, object allocations are DEATH in java. Avoid them if at all possible.

I bet if you change just the "" + x to just x, you'll shave off those extra 4 seconds.

It Will Never See Widespread Acceptance

[istartedi]

It Will Never See Widespread Acceptance. Why? It's GPL'd. So, until Linux conquers the desktop, or Netscape recaptures the browser market it's irrelevant.

PNG and JPEG are in IE because of the license. If they were GPL, all the MS browsers would be supporting GIF and some other alternative for lossy.

I didn't download IVM, but I decided to take a look at the instruction set. I gave up because it was taking too long to download! It looks like it has thousands of instructions. The JVM has less than 256. Something tells me IVM won't be targeting the embedded market. :)

Don't get me wrong. There is a market for embedded C or C++ virtual machines. I know because I'm working on one for my own use, and other parties have expressed interest to me. But I don't expect to bring in big bucks with it. MS CLR will probably win on Windows, and the JVM will win every place else. The smart money is on tools and languages that target the installed base. Sound familiar?

Re:It Will Never See Widespread Acceptance

[Arandir]

If the libraries for PNG and JPEG were GPL, they would be rare even under Linux.

But I wonder about IVM and the GPL. Will all programs executing under IVM also have to be GPL? If the programs have to link to an IVM module of some kind, they may have to. I guess it all depends upon how it's done.

But how in the world will one be able to write a IVM plugin for Mozilla? Or Galeon and Nautilus, which still use non-GPL Mozilla code? If IVM is truly GPL, and with no exceptions, then it may be limited to Konqueror only.

More programming languages than programs

[WildBeast]

It's crazy, at this rate we'll have more programming languages than programs, we'll have more OS's than we can think off, etc.. I don't know if you're getting it but at this rate, the value of software will sink. Supply is much bigger than demand, soon enough developpers will not afford to pay for food. Don't say I didn't warn you.

Is this possible ?

[tmark]

Am I missing something ? How can a language 'support' another language (I assume this means relatively full support), support other languages, and yet still be faster than *any* of the languages ? The only thing I can imagine is that their compilers are better, but somehow I doubt that's the answer.

Re:java is not slow

[Outlet of Me]

As a person who works with the internals of a Java Virtual Machine day in and day out, and a user of Java applications, I have to say Java has some ways to go before it matches C in all aspects.

I submit this example: Forte is a Java application, and I recently saw it being run on a 700MHz PIII machine with 256MB RAM. It literally crawled on bootup, and the performance at runtime was not on par with other non-Java GUI apps.

Now true, I would love for Java to match C performance-wise (would make my job a lot easier :-), but there would be a lot of value in something that could compile C to a platform-independent format that would execute at native C speeds.

Ignore above post.

[Malcontent]

Sorry my bad. Same thing

Wish it luck, but...

[arQon]

There's a lot to be said of platform-neutral environments. Typically tho, what's said is: "It doesn't f**king work". C++ is standard only as long as you're willing to stay with the language as it was 5 years ago, since we're constantly forced to use (eg) SunCC 4 or MSVC 6 or some other hopelessly broken compiler because of broken legacy code that NEEDS it; and Java has never been anything other than "write once, debug everywhere".
Being language-neutral on top of that is also a great thing for a VM, although it's no shock that the VM is going to be biased towards one language over the others. But let's face it: anyone using Java doesn't need hard-realtime performance anyway, otherwise they wouldn't be using Java in the first place. Same as if they were VB devs. So it makes sense that the bias would be towards C++.
The IVM runs DAMN fast, supports a truly open, pretty well-designed, widely-available graphics library: it's got a lot going for it.
But it'll have to bully its way past Java to get wide acceptance even if it's 10x better; and to truly become a standard it ironically needs to be adopted by, yes, THEM. The people whose browser has 80+% of the market. Of course, since it's GPL'd that's hosed it right there.
Then there are the same security issues that you see with every inet VM: how sure can I be as a user that some site's little applet didn't just funnel a ton of info back to them, that it won't do nasty things to me, etc. THOSE are the sorts of things that always bother me about "active" content: take a look sometime at how trivial it is to totally ruin someone's machine with an ActiveX control.
As an "Internet VM", I have as much use for this as I do for ANY objects-on-Web-pages "solution", which is to say, damn close to none. I have ONE site that I'm willing to run Java from: ESPN for it's baseball applet. Every "enabling" technology that people use for this stuff tends to end up meaning "enabling inept web designers to create gimmicky pages that don't work", especially when they end up using scripting and crapplets to mimic the most *basic* HTML functionality like hyperlinks. (No, I'm not joking. I've seen it happen).
OTOH, for an *intra*net I would definitely consider something like this, and I'd prefer it over Java any day of the week. And for little noddy apps, being able to use my language of choice and still have portability AND much better performance, well, that sounds pretty good to me too.
So I think it's a useful bit of tech: just that it'll never go anywhere in the role they're pushing for it. That's not necessarily a bad thing though. :)

this is good but not great

[Anonymous Coward]

Having a VM to make C, C++, Obj-C (and Java) alll portable and still fast is great. Java does reduce the need for this and since the VM isn't portable to my platform of choice (OS X) this certainly isn't the answer for me at the moment. If it grows and moves to other platforms, tremendous.

People here have already started rebutting the need for this as Java is fast, has great libraries and enforces good writing style. In response to that, from a person who makes his living writing Java:

• Java is fast. It runs close to C/C++ in basic algorithm tests from what I've seen, depending on your runtime settings and VM.
  
  
• Java's lack of direct pointer manipulation (e.g. pointer arithmetic) does help people from hurting themselves and that alone leads to better code. The OO nature helps a bit, but really, not much more than taking C++, removing pointer manipulation and removing huge reliance on globals. Obj-C, which I use in my hobbies for OS X, is just as good an OO language, with some minor quibbles about its syntax being more awkward. The lack of memory control in Java loses out big time to the option of manual or automatic memory deallocation in Obj-C. Big Time Loss, even in 1.4.
  
  
• Java's libraries lead to code bloat. People substitute poor use of OO code and APIs for their poor use of pointers in their C work. Sun encourages this poor use by advertising its APIs' functionality and not their many weak points and the fact that its APIs aren't particularly efficient outside of a limited scope.
  Example: People commonly use a Vector when they just want an array of simple types (e.g. int) that will always be "large enough". Vector implements things that have nothing to do with this functionality and Vector doesn't support simple types. Code using the Vector with an Integer rather than an array with an int runs at less than 2/3 the speed and has a much larger memory overhead. Yes, teaching will help people reduce this error but with many classes the poor API coding is two, three or four parent classes above the class you think about using and oftentimes performance of the code is obfuscated - you don't want to have to write replacement code and test yours by theirs in order to determine if you should write replacement code. Java substitutes interfaces and Object-Orientedness (e.g. "Integer" support but not int) as so-called functionality while sacrificing efficiency and usefulness. Whereas efficient programs like to keep good form while remaining close to the bone, java likes to wrap your whole body in saran wrap and then cover that in tupperware and then let you touch the code through those nice OO pieces of plastic surrounding your hands. People teaching Java generally never tell the students the API code sucks, often because they don't really realize it themselves (in academia) or ..? Or if not that I don't know why they don't. I guess the modus operandi for many Java programmers is to rarely research the code beyond the published docs. It came to heart for me after I had to write an editable text component extending from JPanel as everything they offered was wretched for something requiring complex formatting.
  
  
• Java's libraries are very buggy and often poorly written. In final release versions their code still has questions, e.g. "How should this be handled?". They have some bugswhich are 3 or 4 years old, easily noticeable and in a basic part of their API which aren't even fixed as of 1.4. Leading to...
  
  
• Sun doesn't support community fixes to its libraries. This is the worst thing possible given their oft-shit code. If they simply had a "submit bug fix" section in an easily found place that would help so much. This is the major downfall of them not having truly open source code - you can look, but you can't fix and post so no one else will have to fix. This, above all the other reasons, is why Java still has such a poorly implemented API and thus (through its poorly made API) why it is not automatically the language of choice when considering C++, Java or other OO languages. It's really not the language that is so slow, it's the poor implementations in and the misuse of the APIs.
  

So, please, all you fellow Java programmers, realize that Java is far from perfect, and even just among the languages with an OO nature, it is not the best (none of them are). If Sun made it easy to fix its code, and offered more classes with less "functionality" and better performance it would become vastly better. I don't see Sun really making the changes necessary to make Java fast and memory efficient and, well, responsive to programmer's needs. If this VM can become a practical substitute for coding across platforms I would happily make the switch and would certainly hope that my company does the same. Unfortunately for both these paths the promises therein are still well in to the future.

Speedier?

[NitsujTPU]

Ahh, I can tell that you know a language other than JAVA, because people who only know one language seem to want to defend that language to the death. I am so sick of listening to programmers who only know one language, call themselves programmers, and will fight to the death explaining why that language is better than all others without a good grasp on theory to do so.

I don't see why this should be any quicker though :-P

Requires RedHat 6.0 or Higher?

[Lethyos]

Does not sound very cross-platform to me. :)

Java is two things

[MushMan]

The problem with arguing about java is that it is two things.

1. A language.

2. A virtual machine.

There is no need for a virtual machine. Simply a language with a full and developing library which is cross platform. Any language which is defined and left alone is going to become out of date very quickly.

VM's are always going to be slower than native code. If you want a cross platform language, implement the cross platform ability at compile time rather than at run time.

HZ.

ps I'm a Lazy Bastard, not an Anonymous Coward :P

Re:Java is two things

[egomaniac]

"There is no need for a virtual machine?"

This sort of quote sounds very much like you read it off the net in some opinion piece somewhere, because it's meaningless and you offer no support for your assertion.

Let's see how you'd define Java without a virtual machine. Firstly, we'd assume that we'd not want to give up any of Java's features or 'niceness', because after all if there's no "need" for a virtual machine it implies that we can eliminate the VM without compromising anything.

So let's enter an alternate universe in which javac just produces a native executable file. Fine and dandy. Unfortunately, we immediately hit a few snags. How do applets work? Applets are distributed to whatever machine requests them, so unless you already have a compiled version you just can't do it. Hmmm. What about security? Java is a secure language, meaning that untrusted code running in the sandbox can't cause meaningful harm to your computer. You can't make that guarantee about an executable.

What about Web Start, which distributes code to different computers? That will be a problem too. How about a program which requests a few classes from elsewhere? Same thing.

Okay, so scrap that idea - clearly we'll have to give some things up. So instead of javac only producing executables, we'll change it to instead produce an intermediate format, and then have it automatically translated into the final representation as soon as we know what that representation is. Well, guess what, genius! VMs have been doing exactly that for five years.

"VM's are always going to be slower than native code. If you want a cross platform language, implement the cross platform ability at compile time rather than at run time"

Check out the Java Performance Report, in which Java delivers MS Visual C++ a thorough spanking. (Disclaimer: it does lose to Intel's compiler, but gcc isn't anywhere as good as Intel's)

The Slashdot community, at least, should be smarter than this. Never, ever say that technology A will never beat technology B without a mathematical proof of its limitations in hand.

Re:Java is two things

[egomaniac]

I continue to disagree with .class -> .exe being the way to go. After all, native compilation *is* available (there are a bunch of native compilers for java) and for all intents and purposes nobody uses them. I certainly don't. If native compilers were so very desireable, they'd be a lot more popular.

As for VM sharing, you're absolutely right that multiple VMs are a huge memory sink, and it really sucks. However, research on solving this problem has been in progress for years and is scheduled to be included in version 1.5 (it was originally targetted at 1.4, which is currently in beta, but was pushed back). For the record, I don't understand the difficulty but the people working on the project seem to feel that fixing this issue is a hell of a lot more involved than it would sound at first blush. I don't know the details.

And yes, the VMs are pretty frickin' amazing right now, aren't they? I honestly never thought we'd reach the point where they were even close to native compilation, let alone beating all but the best C compilers...

GNUStep?

[jcr]

Has anyone tried building the GNUStep-Base library on this?

-jcr

Squeak!

[BitwizeGHC]

Looking for a fast, portable, free-as-in-speech, object-oriented language? Try Squeak, a wonderful smalltalk implementation. It's great. I've been playing with it quite a bit myself, and have been very pleased with it.

Re:[insert scary music here]

[jilles]

It's just C compiled to bytecode. It doesn't have most of the features that made Java popular (e.g. security, dynamicity, reflectiveness because inherent design decisions in the way C programs work inhibit this). In other words it is no replacement.

Don't understand me wrong, maybe integrating such a thing with e.g. the gnu compiler would be useful. It would be great to create a single set of binaries and distribute them to the hubndreds of unix versions and other operating systems. But it has to be clear that this thing is orthogonal to java rather than the same.

In any case, I'm not impressed and even bored. Java is a relatively simple language. Most of the language concepts are easy to grasp, even for novice programmers. Yet people keep comparing it to more primitive languages such as C and suggesting alternatives which are basically C++ improved rather than Java improved. After years of being confronted with a rapidly growing java community, even some C++ programmers begin to appreciate things like garbage collection (after having dismissed it for years based on performance concerns). However, beyond garbage collection they are still largely missing the point (i.e. C is not so cool after all).

What I would like to see from the open source community (perhaps as a proof of concept) is a more ambitious effort, not just a (partial) duplication of features inspired by ignorance rather than innovation. Java has room for lots of improvement, lets set it as a baseline rather than a design goal. Duplicating all of Java's useful features should be a minimum requirement and not the ultimate design goal.

This post is rather harsh, I know. However, I think this is a fundamental problem with open source in general and linux in particular: it's mass production of commodity software components (kernels, compilers, IDEs, word processors), not creation of new ones. If cutting edge technology is your thing, the propietary world is still the source of it (speech recognition, cool 3d technology, AI related improvements to user interfaces, compiler technology, languages, ...). It is very rare to see an open source project that does not just duplicate features but instead introduces radically new features and paradigms. There are some research projects that use open source to distribute their stuff but these generally play only a marginal role in the open source community. The big open source projects are all about duplicating and imitating the bigger/better (in most cases) propietary counterparts.

In short I find the open source community boring & backwards. Its contributions are very useful and I use them on a daily basis. However, as a researcher I don't want to wait for thirty years to see things like OO being grudgingly accepted; I hate it when linux is advocated as a windows alternative when the people doing so largely fail to even realize why windows got popular in the first place. The same applies to Java and Visual Basic (yes, from the *evil empire* you understand me correctly). The features that made those things popular have yet to be duplicated. Effords like the one advocated in this article are just so backwards they only make me angry. Go do something useful! Don't waste your time figuring out how to reinvent the wheel, I already have half a dozen.

Like small children...

[macpeep]

Sometimes, I cannot believe the silly fights I see here on Slashdot. I'm a software engineer myself and I use both Java and C++, but for different purposes.

At work, we write cross platform C++ code for a large number of platforms in a pretty large scale project. This is amazingly straight forward given a strict set of rules that everyone has to follow, but it also requires that you constantly test on all these platforms. The actual product that we are working on, is C++, like I said, and it would never even occur to us to write it in Java. Even if Java would be 80% as fast as C/C++, we wouldn't use it, because we want all the speed we can get. (yes, some of our inner loops are optimized in assembler - separately for every CPU that we support)

However.. In order to be able to compile and test on all platforms, we needed a tool so that every engineer could just press a button and have the code compile and test on platform X. To enable this, we built a tool in Java, that checks out code from CVS, compiles it, and sends logs to a server where you can view the build logs with a web interface. From the same server, you can also initiate the compilation remotely on any one of the client machines (one per target platform) that are running the tool. This whole system is coded in Java, and just like would never occur to us to code the actual product in C++, it would never occur to us to code this tool in anything other than Java.

It seems like everyone here is trying to prove that one particular language is best for all tasks. Guess what - that's not true. I see C zealots try to prove how slow Java is. Well, it's actually way faster than many believe. I see silly proofs that try to show that Java is slow by using benchmark apps that do string manipulation with String objects. If you write your own strcat, strcmp, strstr etc. in Java and use byte arrays, you'll find that string manipulation is about 70-85% as fast as in plain C - and that's fast enough for just about any purpose you can think of. Of course your productivity advantage is now gone.

Just use whatever you feel comfortable with and whatever works for the application that you need to write. In most cases, you'll find that Java will be very nice forit. In other cases - like graphics and game programming, C++ - used wisely - is your best choice. Some dislike OOP and want to use C instead... Whatever gets the job done for you! I don't see why everyone has to prove that Java is "damn slow" all the time. Obviously, it's fast enough, as evident by the fact that a few millions programmers use it every day for real life tasks.

Re:Like small children...

[macpeep]

"Advantage? If people did what you're suggesting, C would probably be a more productive language to program in! I mean, c'mon! You have to re-implement basic functionality to get decent performance?"

I think you misunderstood. I just meant that Java itself isn't slow. It's the class libraries - like the String class - that are the cause of most of the slowdown in your average application. If you are writing a large scale app, implementing a fast string class is completely trivial. If that gets your speed up to Perl & C levels for string handling (which it would), then it's well worth it.

For most people and most tasks, even String and in particular StringBuffer is fast enough already.

Personally I find Java's string manipulation really nice API wise.. but that's just me, and I remember that I loathed it at first since it was object oriented string manipulation. Oh well.. :)

Re:Faster -- with evidence

[pangloss]

thanks for posting your numbers.
my only question is what jvm (and version) was used?

Squeak is Smalltalk...

[Ungrounded Lightning]

Looking for a fast, portable, free-as-in-speech, object-oriented language? Try Squeak

Squeak is Smalltalk. That means, among other things:

The is no clear separation between the environment and the program.

There is a confusion between a pointer and the object itself.

There is no finalaization (destruction)

There is a single memory model for instances (heap) versus, for instance, C++es minimum of 4 (heap, stack, static, member-of-another-object)

There is a single model of memory management (garbage collection over ALL objects - lose them and the memory eventually returns - sometimes after a sudden "freeze" of the program). It is automatic and can't be replaced with improved handling of special cases.

There is no strong typing.

The environment is hostile to multi-programmer cooperation.

The language design allows incomplete programs to appear to run, encouraging the release of incomplete and buggy programs.

Methods (member functions) of subclasses (derived classes) are executed during construction of the superclasses (base class), invalidating the debugging of the superclass (base class) constructor.

I could go on.

Smalltalk is useful for throwing together a program to run once to get an answer to a question or sometimes to test an idea. It is totally unsuitable for the construction of mission-critical or commercial-grade applications.

Since the problem here is to create an environment for writing code you want to DISTRIBUTE to a large number of people who will use them without being inside their development, it's an amazingly wrong language choice.

Re:Squeak is Smalltalk...

[hding]

It's hard even to know where to start with that.

The is no clear separation between the environment and the program.

Okay, one point in favor of Smalltalk, IMHO. :-)

There is no finalaization (destruction)

I can't speak for every Smalltalk, but then what exactly am I telling my objects when I define a #finalize method for them and send them the #beFinalizable message in Dolphin? I'm relatively sure that other Smalltalks implement similar measures.

There is no strong typing.

Kindly review the meanings of strong/weak vs. static/dynamic typing. Smalltalk is strongly and dynamically typed. I don't necessarily disagree that strong typing is a good thing (under its correct definition, of course). The whole dynamic/static argument is considerably less clear, however, IMHO.

The environment is hostile to multi-programmer cooperation.

Please tell us specifically what is wrong with approaches such as StORE for Visual Works, or even less ambitious tools such as David Gorisek's Source Tracking System for Dolphin.

The language design allows incomplete programs to appear to run, encouraging the release of incomplete and buggy programs.

It's unclear that your premise implies your conclusion. It's also unclear exactly what your premise means. As you pointed out above, there is no clear separation between the working programming environment and a developed program. So how is it that an incomplete program is appearing to run? A modification or extension to the existing Smalltalk image actually is running. In contrast to your assertion that this results in buggy code, the typical Smalltalker would observe that this makes it a lot easier to test and correct code incrementally.

Methods (member functions) of subclasses (derived classes) are executed during construction of the superclasses (base class), invalidating the debugging of the superclass (base class) constructor.

I have an inkling what you mean by this, but I'm not sure. Would you mind posting a snippet of Smalltalk code to clarify it?

It is totally unsuitable for the construction of mission-critical or commercial-grade applications.

I will admit that I only know one massively successful Smalltalk "commercial-grade" application, viz. Visual Age for Java. OTOH, you might want to ask companies such as Sprint, FedEx, and various large banks about the suitability of Smalltalk for mission-critical applications.

If you don't like Smalltalk, that's fine with me (it's not my first choice for most things either, honestly), but please don't spread misinformation about it.

Re:Faster -- with evidence

[Thorgal]

Ok, I multiplied counters by 100 to get more reasonable times on Athlon1.1Ghz/143MHz SDRAM and to minimize JVM startup overhead. Results:

fantomas:te/> gcc -v
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
gcc version 2.95.4 20010827 (Debian prerelease)
fantomas:te/> gcc c.c -o c -O2
fantomas:te/> time ./c
9007199254740992.000000

real 0m19.273s
user 0m19.220s
sys 0m0.000s

fantomas:te/> java -version
java version "1.4.0-beta2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta2-b77)
Java HotSpot(TM) Client VM (build 1.4.0-beta2-b77, mixed mode)

fantomas:te/> time java Compute
9.0071993E15

real 0m18.699s
user 0m18.570s
sys 0m0.030s

Well, enough said.

Re:Faster -- with evidence

[iapetus]

I'm afraid your code is pretty much useless for testing Java vs C++ performance. If you'd checked out the Sun FAQ on benchmarking Hotspot you'd have seen something like this:

I write a simple loop to time a simple operation and HotSpot looks even slower than Java 2 SDK. What am I doing wrong? Here's my program:

(Program almost identical to yours snipped, since it's setting off the lameness filters ;)

You are writing a microbenchmark.

Remember how HotSpot works. It starts by running your program with an interpreter. When it discovers that some method is "hot" -- that is, executed a lot, either because it is called a lot or because it contains loops that loop a lot -- it sends that method off to be compiled. After that one of two things will happen, either the next time the method is called the compiled version will be invoked (instead of the interpreted version) or the currently long running loop will be replaced, while still running, with the compiled method. The latter is known as "on stack replacement" and exists in the 1.3/1.4 HotSpot based systems.

Re:Bullshit

[iapetus]

Okay, let's look at those arguments again.

1) Java is slow because Java is slow.

Cool. I'm convinced, but some would view this as a slightly circular argument.

2) Java is slow because some libraries have already been written in other languages.

You make a good case here. But again, some might frown and accuse that argument of being a bit of a non sequitur.

2) Java is slow because some people who don't use it don't know how to use it.

Again, 100% solid. But I fear some might be slightly wary of the utter irrelevance of what you're saying and still other might suggest that the fact you can't count to three makes you a less than optimal judge of speed of numerical computation...

Open Source Innovation

[richieb]

[...] It is very rare to see an open source project that does not just duplicate features but instead introduces radically new features and paradigms. There are some research projects that use open source to distribute their stuff but these generally play only a marginal role in the open source community. The big open source projects are all about duplicating and imitating the bigger/better (in most cases) propietary counterparts

This is true in general. It is rare to see a project open source or proprietary that is really innovative and different. That's because it's easy to copy existing ideas than to think up and implement new ones.

But remember that the Web (http, server, browser) were started as open source projects and today Apache is still one of the best web servers there is.

If you look around there are number really cool open source projects that are way ahead of anything the propriatary world is doing. Here are two I like:

Jazz - a Zooming user interface, as discussed in Jef Raskin's book The Humane Interface.

Squeak - a ground up implementation of Smalltalk-80 which is being used in all kinds of explorations. One of the leaders of this project is Alan Kay (you've heard of him, haven't you?).

Innovation can come from unexpected places. If more people get to play with the code, then it's more likely that someone will think of something really cool...

...richie

Re:Open Source Innovation

[jilles]

Both these projects I would refer to as rather marginal efforts (interesting though). Squeak is essentially a smalltalk clone. I haven't heard of jazz yet (will check it out soon).

I have heard of Alan Kaye. In fact I was about to listen to a keynote by him only last week(unfortunately it was cancelled at the last moment).

There is already a good alternative to Java

[TCM_VA]

-It supports many processors.
-It is based on TAO's Intent.
-There are currently STABLE "runtimes" for Linux and Windows, with more in development.
-It's faster than Java.
-Most programs run faster through the runtime than they would if coded in C for a native OS.
-It has already been adopted by Sharp.

It's called AmigaDE.

Re:[insert scary music here]

[jilles]

Well, my complaint isn't that there aren't innovative projects (because there are) but that many self proclaimed OSS advocates are mainly concerned with reinventing the wheel and actually have a very conservative attitude towards anything new.

Just to provide some opposition:
ReiserFS. Check out Oracle's and MS plans to replace filesystems with databases. That is innovation, what Reiser does is just an admirable effort to duplicate the journaling feature invented by others.

Berlin. This is a nice project, however, apple has a vector based (pdf) backend for their GUI in mac os X. That is what I call innovative.

Perl, Python, Ruby, TCL, Java (the language, not the VM) are all variants of the same language constructs. Lots of syntactic sugar, good libraries. A lot of hard work went in them. But take a look at intentional programming from microsoft research or multidimensional separation of concerns tools from IBM and you will see my point because that is true innovation.

Some of the stuff I mentioned is actually open source BTW but I'm not discussing the license but the process and the community instead.

MOD PARENT UP

[egomaniac]

What the hell is up with moderating the above post as a troll? There is absolutely nothing in there that any reasonable person could object to.

The issue with companies shying away from the GPL is a fact. I don't mess around with GPLed code for that exact reason. I'm really hoping I manage to get that moderator in metamod *rubs hands gleefully*...

Re:I would like the other-way-around

[j7953]

There is nothing that prevents you from compiling a software written in Java (the language) to something else than the Java VM (Java the platform). Doesn't the latest release of gcc even include a Java-to-native compiler? I don't know how much of Java (the class library) is supported then, though.

Almost no language has any features that tie the language to a single platform exclusively. This includes Java. You could even support operating system functions in Java by writing an appropriate library. That library would likely not be compatible with the Java VM, but if you don't target that platform anyway, who cares?

One problem with Java, I think, is that Sun has marketed "Java" as a programming language and never made any real difference between Java the language, Java the platform, and Java the library. What they should have done, IMHO, is to release the Java VM and the Java class library as one product, and make the Java the language a seperate product that happens to support the Java VM as a target platform. That's essentially what Microsoft is doing with .net -- there is the .net platform, which is basically a bytecode ("intermediate code") format and a class library, and there are the programming languages that support the .net platform, including a new language (C#).

Re:java is not slow

[egomaniac]

I submit this example: Microsoft Word is a C++ application, and it sucks ass on a 700MHz PIII machine with 256MB RAM.

The fact that a particular program runs poorly is not an indication that the language in which it is written sucks. I get great performance out of Java. (And, Forte runs fine on my 128MB 400MHz PII, but I'm not going to argue with you about that...)

The problem with Java is the language

[Dwonis]

My biggest beef about Java used to be that it was slow and not backward-compatible across minor versions. People are saying that Java is faster, and I believe them. However, it is becoming apparent that Java is only a first-generation cross-platform language, and it has many design deficiencies.

Java's second-biggest problem is that it seems to have been designed to run on a virtual machine (or a piece of custom hardware), rather than being translated to native code. This is what made it inefficient for so long. IBM has done a great job of working around this problem, but if it wasn't a problem in the first place, IBM could have spent the time making Java even faster than it s now.

The largest problem I can see with Java, though, it that you're tied to the Java language. This is basically assuming that the Java language fits all for anything that needs to be cross-platform.

My preference right now is the Amiga DE. It's a translated (rather than interpreted) version of assembly language, which means GCC could (at least in theory) have an amigade target. My beef with the Amiga DE is the fact that it's a proprietary standard, which may have been fine 10 years ago, but it certainly doesn't fit into today's reality of open standards.

IVM looks promising in that it seems to address all the problems I've stated above. I hope it does well.

(Please excuse me bad English. It's not my primary language in the morning.)

Re:Faster -- with evidence

[greenrd]

Yes, read the rest of the FAQ - but only if you accept that all benchmarks are valid only for certain types of applications. CPU-intensive benchmarks don't mean much for IO-intensive database apps.

Re:Faster -- with evidence

[greenrd]

You don't need to. Write a class which is backed by a RandomAccessFile. Lazy evaluation!

Realism - Re:Faster -- with evidence

[RallyDriver]

Your test isn't very comparable, because you are also measuring the startup time of a compiled binary (crt0.o) against the startup time of the JVM and byte-compile. Unless of course part of your point is that Java isn't suitable for writing Unix-style command line data filters and other apps with a short life of only 5-10 secs CPU, which I agree, it isn't.

A better test would be to put the "date" commands into the code in both cases; perhaps I'll re-run them that way and post the results. Don't get me wrong, C will still win, the gap will just be a bit narrower.

Having said that, I wouldn't advocate Java (yet) for something compute intensive, you are right on in that respect; however, you must note this:

- very little software these days has CPU time as its limiting performance factor

- in terms of the total cost of doing computation, CPU performance is getting cheaper and cheaper (Moore's Law) while developer time is getting more and more expensive.

The cost in $$ to develop a straight line block of code of the compelxity of your loop body there is literally trillions of times the cost in $$ to execute it once, so unless it is in a place where it will be run trillions of times and performance matters, an easier to code language wins out over a faster one. There is a reason we aren't still all hand coding machine code in hex, and it's not a yes/no thing, it's a sliding scale moving effort form people to machines.

Assembly -> C -> C++ -> Java -> ???

We use pure Java for our server side web application. It runs with a servlet runner (Apache JServ) and we typically run a single VM ("java" command) for about 3-6 weeks, accumulating a couple of hundred hours CPU.

The thing I find most interesting in your test is the speed ratio - despite the disadvantage that you've given Java, it's less than 2:1 which is better than I suspect most people would expect. This is number cruching, it's not what Java does well, althoguh the gap has closed enough for it not to be a concern. I saw a paper about 18 months ago (can't remember the reference)

Nowadays, very few apps do enough computation to redline the CPU in any useful sense - the limiting factor is I/O.

The real advantage of Java is not so easy to benchmark, and that is indeed developer productivity; the app is not rocket science, but it has some very useful platform layer caching between itself and the database. There is no way we could have gotten as far as we did with this with so few people in this amount of time if we had to build it in C++ and worry about type issues and garbage collection.

This productivity advantage far outweighs the 25 to 50% performance penalty of using Java - the limiting factor in our app is not CPU, depending on the individual screen it's either I/O bandwidth to the browser or I/O speed to disk. Not much we can do about the former for end users (though we make sure customers using our admin tool get a cable modem / DSL) and our caching is making good strides at the latter. I have yet to ask a developer to recode an algorithm for **CPU efficiency**, though I do keep a close eye on database and filesystem I/O load, memory footprint (JVM heap), and HTML page weight.

Assuming we can deliver pages to browsers close to as fast as the users' connections can handle them, the efficiency of the overall system to our business is measured in $$$, and includes the cost of developer time (lots) and the cost of hardware (small) - throwing hardware at it here **is** the right solution.

For appservers, we use rackmount dual Pentium 3 pizza boxes, running two Sun 1.2.2 green threads JVM's on Linux; I picked up **twenty-two** of these, less than a year old, at the deja.com sell off in Feb 2001 for about 10 grand total. That won't even cover the fully loaded cost (salary, taxes, medical and Mountain Dew :) of one senior engineer for a month.

Bear in mind guys, I'm not a suit, I'm a techie - I have a Ph.D not an MBA, and my background curiously enough is in one of the few areas where the CPU performance **does** matter, doing compute intensive stuff, mostly FORTRAN and C and mostly on hardware made by Cray Research. This gives me the perspective to know when and where performance matters, and I chose Java with that in mind.

David Crooke
Chief Technology Officer
Convio

Re:I hate the word portability

[mikera]

Emulation is a perfectly valid way of achieving portability, so it's patently not BS. Anyway, most Java nowadays is using JIT compilation of bytecode into native machine langauge. So a modern JVM is only emulation in the sense that a C++ compiler is.

JITs rock because they get you the performance of native code compilers with the portability of bytecode/intermediate langages. JIT, possibly combined with some features stolen from functional langages are the way of the future.

You're perfectly right in that you can emulate any language using anything else. Therefore what matters using a standard platform that is widely available and efficient. Right now Java fits the bill better than anything else. I may change my opinion if .NET really takes off, but my guess is that it will tumble at the portability hurdle.

Re:Funny thing is...

[mikera]

I will not ignore just because it comes from Microsoft. But I probably will end up ignoring it because Microsoft won't port the libraries properly.

Not much point being able to run the bytecode if it can't access the network, the GUI or the filesystem.

I will use and support .NET if and only if it results in *any* .NET program being portable to *any* system. That means no COM dependancies, no requirements for a Win32 OS, no MS-only protocols and properly open file formats. I'm not really expecting to see any of these. Are you?

More data - Re:Faster -- with evidence

[RallyDriver]

As promised, some tests with the timing rolled into the runtime environment. I did a couple of things:

1. Tried to get more accurate timing resolution - for this I used System.currentTimeMillis() in Java, which is a wallclock time, and clock() in C which is CPU time, but since this is an approximate, compute intensive test I didn't feel it was a big issue. In 15 mins of man page archaeology I couldn't find a C or POSIX system call which gave sub-second resolution on wallclock, making part of my my point about C :-)

2. Move the timing inside the programs, so it was only timing the loop (see speedtest.c and Compute.java below)

3. Tried a couple of different versions of the Java VM - Sun's 1.2 JDK with no JIT, and IBM's 1.3 JDK with JIT, to see the difference there - this is not just JIT but also VM general improvements from version to version.

4. Did a test of bundling the loop off into a subroutine so it would get the full benefit of the JIT; to trigger this I call it twice and measure the second pass.

A further baseline observation: your "school's big Sun box" is clearly quite heavily loaded, because I tested using a cheesy old 500MHz P3 and it ran rings around those times. I know the Sun should be faster. This is another problem with benchmarking - what exactly are you measuring? The generally accepted rule is that wallclock on an otherwise idle system is the true measure, but if you're using a shared system, then **for this kind of test** CPU time is a fair proxy.

I tested on the following platform:

Intel Pentium 3, 500MHz, 100MHz FSB, 384Mb RAM
Linux 2.2.12 (Red Hat 6.1)
Running multi-user system, but largely idle

I used the following compilers / JDK's:

[glenfarg:dave]speedtest: gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/sp ecs
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
[glenfarg:dave]speedtest: /usr/local/sun/jdk1.2.2/bin/java -version
java version "1.2.2"
Classic VM (build 1.2.2-L, green threads, nojit)
[glenfarg:dave]speedtest: /usr/local/ibm/IBMJava2-13/bin/java -version
java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0)
Classic VM (build 1.3.0, J2RE 1.3.0 IBM build cx130-20001124 (JIT enabled: jitc))
[glenfarg:dave]speedtest:

One interesting point - when I first tried Compute2.java, it was 10% slower than Compute.java on the Sun JDK, and about a wash on the IBM JDK. The default setting of Java VM's is to start with a modest heap size and dynamically increase it; I found that with the Compute2.java program, increasing the starting heap size with "-ms32M" improved performance in both cases, and those numbers are quoted below. You might argue that this makes Java seem very memory hungry, but that heap includes a lot of stuff besides your 10 lines of code - it doesn't mean it takes a 128M heap to efficiently run 40 line programs :-)

The average quoted times over 10 runs each by the code, using the built in measurement, were as follows:


C version-----------------: 0.78 sec
Compute.java, Sun 1.2 JDK-: 3.39 sec
Compute2.java, Sun 1.2 JDK: 3.51 sec
Compute.java, IBM 1.3 JDK-: 1.24 sec
Compute2.java, IBM 1.3 JDK: 1.09 sec


As you can see, the performance once the JIT gets up to speed is not a million miles away from the compiled C - the latter shows about 28% saving in run time; making both use wallclock timing to get a like for like comparison might bring it one or two points closer.

One might be amused to note that using "gcc -O2" instead of the default option made the C version about 6% SLOWER.

As ever, a benchmark is only a benchmark - if you want a real test, use real code in a real scenario. YMWV.

Enjoy
Dave

Re:More data - Re:Faster -- with evidence

[RallyDriver]

Here's the code I tested - when I posted I thought it wouldn't fit in the above comment, but actually the < signs were being truncated by the Slashcode parser:


/* speedtest.c */

#include
#include
#include

int main(void)
{
float x = 0;
int counter;
clock_t start, end;
float cpu;

start = clock();

for(counter = 0; counter < 10000000; counter++)
x += (counter / 3.14159265359);

end = clock();

printf("%f\n", x);

cpu = (end - start) / (1.0 * CLOCKS_PER_SEC);

printf("%f\n",cpu);

return 0;

}

::::::::::::::
Compute.java
::::::::::::::
// Compute.java - moves timing inside JVM

public class Compute
{
public static void main(String args[])
{
float x = 0;
int counter = 0;

long start = System.currentTimeMillis();

for(counter = 0; counter < 10000000; counter++)
x += (counter / 3.14159265359);

long end = System.currentTimeMillis();

System.out.println("" + x);

System.out.println("Time: " + ((end-start) / 1000.0));
}
}

::::::::::::::
Compute2.java
::::::::::::::
// Compute2 - puts code in method and pre-seeds JIT

public class Compute2
{
public static void main(String args[])
{
float discard = do_Compute();

long start = System.currentTimeMillis();

float x = do_Compute();

long end = System.currentTimeMillis();

System.out.println("" + x);

System.out.println("Time: " + ((end-start) / 1000.0));
}

private static float do_Compute() {
float x = 0;
int counter = 0;
for(counter = 0; counter < 10000000; counter++)
x += (counter / 3.14159265359);
return x;
}
}

Re:Faster -- with evidence

[RallyDriver]

Horse output.

What's non-standard about HotSpot? It implements the bytecode perfectly. It may not be the most common JVM, but it's certainly standard.

That's like saying you have to do all performance tests of C++ using MS-Visual Studio on an Intel P3 running Windows 98, because it is the most common platform for compiled C++ code.

Whole systems - Re:Faster -- with evidence

[RallyDriver]

I once found something kind of similar in a non-trivial case, which demostrates a more realistic scenario.

A company I used to work for had an object data model stored in an RDBMS, with its own abstraction layer and tools to automatically generate the persister code, demand loading, etc. There were two implementations - one in Microsoft COM, the other in Java. This abstraction layer requires dynamic linkage of the kind not easily possible in plain C++, so it used COM objects for that in the C++/Windows version, and weak references and so forth in Java.

One of the apps had a batch mode "engine" which ran overnight to do number crunching on the data; this was only avalable in a C++/COM version, hence only for NT (this predates COM porting tools). One large customer found Windows NT Server not to be man enough for the job (in those days, a quad Xeon 300MHz was your limit for Microsoft) and wanted the engine ported to their IBM SP/2,; as an experiment, rather than trying to port all the infrastrcture from COM to plain C++, one of the developers quickly recoded the engine in Java over a weekend (note the development time advantage).

Well, as you've guessed, the Java version on the SP/2 was much faster and the customer was happy. This was in the days of JDK 1.1.7 when Java performance was not what it is today, but we expected that result with using hardware that was so much more powerful.

More interestingly the Java 1.1 version was also faster than the C++/COM version on Windows NT - further testing revealed that the cost of the COM dynamic linkage over Java's much more elegant linkage model outweighed the then significant difference in computation performance of the plain compiled C++ vs Java bytecode.

Clearly this can only have moved further in Java's favour with advances in the garbage collector and things like HotSpot - I don't think COM has advanced much in the last 3-4 years, at least not in performance.

Re:Faster -- with evidence

[jovlinger]

well,

more to the point, hotspot will do very little for this example. Hotspot is a VM implementation in the style of SELF, and does a very bad job at compiling code the first time around; maybe even interpreting it directly. Then, when enough profiling data has been collected, it goes back and recompiles the code agressively, using the full profiling info to specialise code to be fast for the dynamic common case.

Thus, hotspot is great for servers that have uptimes measured in weeks and programs with long common paths. You aren't going to see much speed in a small program, as your time will be dominiated by profiling costs, rather than payoffs.

As for the classloading delay, people seem to accept an initial delay when starting an application (which can be augmented by quickly slapping up a splash screen), so this isn't really a real world issue.