Slashdot Mirror

There is a blog entry for OMS Video.

The Black Box is a complete watercooled data center in a shipping container.

As far as I know, that's what project Blackbox uses for cooling. Note the blurb where it specifies the water connectivity requirements.

I'm not sure whether the comment was intended to be funny or not.

But I think you are correct. Java has synchronisation primitives built into the language and the standard libraries have lots of concurrent save types (e.g. a Vector can be used like a thread safe ArrayList). Compared to other languages where the concurrency is a bolt on (sorry pthreads), this really does make it easy to thread an app and get the synchronisation correct. Sun's tutorial goes into more depth:

http://java.sun.com/docs/books/tutorial/essential/concurrency/locksync.html

In this particular case, the Sun system has two sockets (8 cores per socket) which run at 1.4GHz vs a 4 socket (dual core per socket) IBM running at 4.7 (I didnt find a nice benchmark for the new 5.0's) . If you add up the MHz, IBM has an almost 2:1 lead (37.6 vs 22.4) and yet they score the same on the benchmark.

Note that the article is also wrong on some of the numbers. Sun's T2 runs at 1.4, not 2.4.

Hmmm, what about That's the good thing about standards, there is so many to choose from" ;-)

Is the Microsoft sponsored one better or worse than the one from Sun?

well, you can get one of these, but that'll still put 30 of those to waste unless they're got something else cobbled together, as 40GBe and 100GBe are still WIP.

'In the early days of C++, I worried a lot about "not being able to teach teachers fast enough." I had reason to worry because much of the obvious poor use of C++ can be traced to fundamental misunderstandings among educators. I obviously failed to articulate my ideals and principles sufficiently.'

Yes, clearly that was the problem—you failed to articulate bad ideas sufficiently. Not that they were overarticulated and everyone has 50 different ways to do the same thing.

'Given that the problems are not restricted to C++, I'm not alone in that. As far as I can see, every large programming community suffers, so the problem is one of scale.'

I'm a Java programmer myself, after struggling with idiocies of C and C++ for a long time (#include, anyone? care to chase down this header for me?). Java has shown when you start with better principles, you get a better language...and then eventually foul that up, too.

It boggles me that there are still people trying to breathe life into C++. If you are a university student at this very moment, do yourself a favor: realize that if you learn C++, and decide to base a career on knowing it, you will be doing legacy programming until you lose your job and there is no other. Legacy programming means that you will be mostly working on maintaining and occasionally extending bad ideas poorly written. This has only marginally to do with the language itself, but there it is. If you decide Java is your thing, then after you've worked about another 5 years, you'll find yourself in the same state, because I give Java until about 2013 the way things are going. Then again, maybe we'll move at "Internet speed" and it'll only be 2010 until people are wondering if Java's worth anything any more.

(The harbinger of evil on Java was marked by the introduction of varargs in Java 5, if you're wondering. I can think of no better way to say, Hey, let's do something pointless that will make it tough to resolve which method is getting called! And slow too, can we make it slow? Oh and also we should say we're doing this so you only have to write one method instead of a bunch, but actually you should have to write a bunch of methods when you only wanted to write one!...just check out that ugly-ass of() method. Of course, now I think about it we did really need it...after all there's no other way that already existed to accomplish the same thing -ahemcoughcougharraycoughcollectionscough-. I'm sure there are lots of good reasons that are sound design for a developer to shroud a method prototype in a could of mystery.)

So if you're a uni student, learn Java, b/c god knows you'll need it for that first job out of college. But do yourself a big favor and start preparing for the inevitable gigacore processors that will be all the rage by 2015...learn Haskell and LISP. Go write something that runs on a Beowulf cluster (yea, I said it). Figure out how to make an AJAX call to a Java servlet that farms out jobs to an Erlang ring. You'll be glad you did.

It's hard to appreciate, but we are in the middle of a revolution. High-performance, multi-core computing has made significant progress in the last few years and it's causing a lot of headache for software developers who try to exploit the potential power available. Multi-threaded programming does not bring a solution to the masses - understanding and preventing the issues arising from concurrency requires a lot of exposure to it.

The young generation of programmers have the confidence to try out multi-core programming, but only because they yet lack the painful experience of doing it. Whilst hardware is running away towards 100 cores in 5 years time and still keeping up with Moore's "Law", software is sadly lacking such advances. There's a very good white paper over on the 2 Cubed website about the problem The Multicore Revolution and a new framework just out called infoQuanta which looks intersting.

Meanwhile, Sun is tackling the problem from within the language. They've got Fortress Fortress which has a certain Java/C syntax about it. I haven't used it but I would say that it doesn't look like the 21st Century solution that's going to advance software development significantly.

Nonsense,

multithreading has nothing to do with the actual number of cores, as you can create 20 different threads into a single core computer. Usually the operating system distributes and organizes your threads so you don't have to and it usually does a damn good job as some Sun servers are able (and have been able to do it for quite a time now) to run up to 64 simultaneus threads.

Multithreading is tricky and can lead to a lot of problems and headaches but, as CPU power is currently reaching its limits (or so it seems) multicore seems to be the only way to go so we better learn and start using it. I've developed multithreading applications and the number of threads doesn't matter so much, what does actually matters is the number of task in which you can subdivide the problem. In my case there where 4 fixed threads with 4 different concrete task and a variable number (configurable under app settings) of background workers wich will consume data generated by the other 4, so its not actually that difficult, for the standar programmer at leas, maybe OS guys will have to work harder but ...

See installing fedora core 8 on hyper-v . Even Ubuntu server is being used by people on HyperV. SUSE is supported in the sense of calling up MS's support desk and talking to them about it.

and the M series from Sun has already been able to do 2TB of memory

http://www.sun.com/servers/highend/m9000/

http://www.sun.com/servers/highend/m9000/

Something like this one?

And a stripped-down non-existent API is a way to make things simple?

No, quality != quantity, let's compare the C++ STL to the standard Java libraries. The STL is quite succinct, the standard Java libraries are outrageously bloated. Arguably, the standard Java libraries can do more, but god forbid if you ever actually want to use part of it that you're not already familiar with, as there'll be at least half a dozen slightly different ways to do what you want to do, 90% of which are obtuse and half of which are deprecated. In the time you spent searching for something suitable to use in the standard Java libraries, you could have written the same functionality yourself twice, taken a nap, gone grocery shopping and played 36 holes of golf. To add fuel to the fire, because the standard Java libraries are so bloated, it's not even feasible to actually know more than perhaps 5-10% of them, at most. In sharp contrast, the STL can be learned in it's entirety within a few hours.

The STL has the map container, the standard Java libraries have approximately a dozen map implementations, each of which is subtly different, but in ways that don't matter 95% of the time. Of course, for the other 5% of the time when you find out that you've picked the wrong map implementation, %s/Hashtable/HashMap/g will probably break things anyways, despite the fact that they're essentially the same.

The STL has the pair container, the standard Java libraries (as far as I can tell) do not have a pair implementation. How they managed to write approximately a trillion and one standard classes without thinking "Hey, a pair class could be useful!" is beyond me.

The STL has the list container, the standard Java libraries have at least a dozen different lists that can't easily be converted between one another, and classes will randomly only use a small (and inconsistent) subset of these lists.

Why should a programmer have to re-write common routines and data structures for every program?

They shouldn't, they also shouldn't spend more time scouring through documentation than coding.

I suspect that the job jar is the bottle neck for the LINDA approach, and further research is required. But the concept is really easy to work with.

I plan on getting myself Solaris developer edition to have a play.

I plan on getting myself Solaris developer edition to have a play.

Yeah, Javadoc should have a place for that stuff. Oh wait, it does! It even has a style guide for information about your fields, methods, classes, and packages. They even describe how to embed (wonder of wonders) diagrams and other images into your source documentation.

It's not like Javadoc (or any other documentation tool) can magically create annotated code samples and training tools on its own. Don't blame Javadoc, blame the lazy bums who never bother to actually document their stuff.

Java also has a very nice concurrency library: http://java.sun.com/j2se/1.5.0/docs/guide/concurrency/index.html and VERY good parallel collections library.

Yes I know. But that is a function of Java class library not of the language itself. I written similar libraries for embedded projects using C++ and any language that supports encapsulation and has support for / or have access to semaphores can easily be made thread safe. My personal favorite use of such objects are FIFOs that transport messages between threads (and processes).

Ok, now you can see the second person who claims that Java is extremely fast.

References: http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=javaxx&lang2=gcc - Java is generally about 20% slower than optimized C, thanks to http://en.wikipedia.org/wiki/HotSpot compiler.

Objective C performance is about the same as Python: http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=javaxx&lang2=python - i.e. Java is in general more than 1000% faster.

Oh, and Java GUI can be fast - check Google Android, it has a very nice custom Java GUI, which works blazingly fast on 200MHz CPU.

You show benchmarks for Java versus C, python versus C, and only provide conjecture that loosely links ObjC versus Java via Python. Unfortunately, you provide no benchmarks comparing ObjC to Python or more importantly ObjC to Java. You did show references for Java, C, and Python but none for Objective-C

It's refreshing to see someone come to the aid of Java. I like Java (and have used it since forever), but I just don't quite fully believe that Java is "faster" than Objective-C. I really don't know why it should matter...

The really cool thing about Objective-C is that you don't have to compare it's speed with C. You can write actual C code in your application. It looks like you can write your dynamically linked objects in Objective-C (which makes the GUI programming nice at least that's what I've heard) and you can write your bare-metal stuff in C. Java only offers JNI.

What specific 'Java related problems' are you having? I'm pretty sure that whatever you're talking about can be easily googled for, and/or asked/answered on one of the gazillion forums out there. This one here is usually helpful for programming at various skill levels. The only real problem I know of, is when teachers insist on using garbage libraries for assignments.

>As for threading, Obj-C has an atomic attribute, @synchronized attribute, exception handling across threads, NSLock, NSRecursiveLock, NSConditionLock, and Semaphores. As for Java, you have the monitor attribute, synchronized, and event handling. I believe that both languages do adequately support threads. Both languages are subject to the limitation imposed by their host OS. Ok the JVM could perform multitasking in its own time slice, but boy would that suck...

Java also has a very nice concurrency library: http://java.sun.com/j2se/1.5.0/docs/guide/concurrency/index.html and VERY good parallel collections library.

>You are the first person I have seen (outside of Sun) that has used "extremely fast" and "java" in the same sentence. Do you have references?

Ok, now you can see the second person who claims that Java is extremely fast.

References: http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=javaxx&lang2=gcc - Java is generally about 20% slower than optimized C, thanks to http://en.wikipedia.org/wiki/HotSpot compiler.

Objective C performance is about the same as Python: http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=javaxx&lang2=python - i.e. Java is in general more than 1000% faster.

Oh, and Java GUI can be fast - check Google Android, it has a very nice custom Java GUI, which works blazingly fast on 200MHz CPU.

I can't speak for the GP, but I've written several medium-sized programs in Java (largest around 30 kloc). Swing is the only good thing about Java -- it's an MVC graphics toolkit that's reasonably cross-platform.

Java's syntax is so verbose it makes my teeth hurt. Its data structures are unimpressive: all the casting from ArrayList/Vector (these names don't even make sense!) was too much, so they added Generics, which make Java code look even more like C++. And its primitives are just too primitive: you get int and Integer and BigInteger, and after 5 years of complaints we'll add a new feature to make int/Integer mostly kind of sort of compatible! (You know, like every other language created in the past 20 years does automatically.) Its control-flow constructs seem rather limited compared to other languages, and there's zero extensibility. Its Unicode support scares me -- why do I have to pass around UTF-16 encoded strings, instead of just strings of Unicode characters (codepoints) like Python or Lisp? I could go on for hours -- the entire API is full of this kind of weird onion-varnish crap.

Objective-C at least has an excuse: it's a proper superset of a 30-year-old language. Java was supposed to be a fresh start, and yet it turned out almost exactly like the not-quite-proper superset of the same language. Oh, but without pointers -- yay, I guess.

Every good programmer I know who is willingly using Java at all is simply targeting the JVM and Java libraries like Swing through another language, like Scala or Jython. If Swing was the worst part of Java, I expect this would be the other way around. There are alternatives to Swing, like AWT and SWT and wx, but I know nobody who has ever used them with Java.

Yes, Java is pretty fast these days. That's because Sun welded the virtual machine from another 30-year-old language, Smalltalk, onto their Java implementation. But is there any way that Java is better than straight up Smalltalk? Smalltalk is as fast, and simultaneously simpler and more powerful. And not just more powerful than Java today (with the abomination that is Generics), but more powerful than Java with the BGGA Closure proposal, which threatens to make Java even more confusing than C++.

Java is the new COBOL. It was neat for a couple years when we had 5 or 10 different major operating systems and portability was a pipe dream, but today we really only have 3 major operating systems, and languages and libraries have improved so you can write portable code in anything without really trying. Java has a slight advantage if you're doing a GUI, because Swing is better than most cross-platform GUIs, but in the past 2 years I've seen more people using Gecko+XUL+JS for that than Swing.

If I sound bitter, it's because I was in college right when the Java Hype Bomb hit, and so I spent about 2 years writing Java code, continuously waiting for Java version N+1 to actually have some features we were begging for. I'm glad I had the sense to get out when I did, because if I was waiting for language features as basic as closures (which are far older than 30 years, gramps), I'd still be waiting, 10 years later.

sorry but you are wrong.

if you have a java application and want the menu bar to appear at the top of the desktop (like all other OS X apps), then simply invoke the jvm/java app and pass the following system property as a JVM arg:

-Dcom.apple.macos.useScreenMenuBar=true

as described here

its not that complicated....

http://www.sun.com/software/javafx/

Note that this means that if Sun pulls out of OASIS, future OASIS development of ODF is under a patent cloud.

No, that is not the case. In the unlikely event of Sun pulling out of the ODF TC at OASIS (which it currently chairs), future versions of the standard would be covered to the extent they implemented the specifications published while Sun was still a member. Sun's unlikely withdrawal would not invalidate previous covenant protection. Additions to the standard made once Sun was no longer a participant would not be covered. That seems completely reasonable considering anyone could add anything in Sun's absence.

As far as the necessary claims language goes, note that IBM has it, too. Open source developers seem to have managed to deal with it there, so I expect they'll manage to deal with it in Microsoft's covenant, too.

IBM's decision to restrict patent protection to only "necessary claims" is deeply regrettable and makes their promises of little value in giving developers certainty. IBM came to the patent covenant table even later than Microsoft, and so far open source developers have had very little time to consider the implications of that deficiency, so I think you're a bit premature calling the all-clear.

The cause of software freedom is ill-served by the tired re-application of discredited ideas from the patent-encumbered world of standards. We should be demanding full patent safety from standards bodies as a routine part of their process. Both IBM and Microsoft do us all a disservice by perpetuating "necessary claims" language because it results in a situation where the only people able to gain certainty about their actions are those with access to legal advice. To remind you of what I said in my blog about "necessary claims":

That patent non-assert covenant is almost identical ... to Microsoft's patent no- assert covenant

That's because Microsoft based their document on Sun's. I know that because the author of the Sun covenant is a colleague, because it was released at least a year before Microsoft copied it and because, after I pointed this out, Microsoft credited Sun for the original document.

(and the differences are in the parts that aren't important)

I disagree, and I have explained why before on my blog. Sun's covenant is intended to empower open source developers, and Microsoft has altered the parts that make that happen. Most notably, Sun's covenant grants all patents, Microsoft's is limited to "necessary claims". That is a very major difference since it means open source developers cannot be sure they have actually been given cover by Microsoft's covenant whereas they can be certain they have by Sun's. It is deeply regerttable that Microsoft added essential claims language in this way. For those who don't follow links, I also find the conformance requirements and the patent peace asymmetry poor in Microsoft's document.

Many have said that the latter is unacceptable for use with free software.

Indeed, and I am among them. However, your implication that the same applies to Sun's covenant is incorrect.

Unless you reimplement it in Java. Which Android happens to run. (For the most part, anyway.)

While it's neither here nor there in relation to this story (and wouldn't perform very well, anyway), I just thought it was an interesting observation. Perhaps one day developers will stop looking at Java as a nice sandbox environment for tiny applications and start realizing that there are real benefits to deploying a high-performance JVM. Especially when HotSpot has already been ported to mobile devices...

Then what is the point of having a Virtual Machine?

The point of the virtual machine is to provide an imaginary execution platform. The original purpose of such a platform was portability, though these days it has become a center for all kinds of research.

If JIT compiles JAVA to native code and allows it to execute outside the boundaries of the VM

That is an incorrect statement. The JVM is logically perfect. i.e. There is no way to feed a program into the JVM that penetrates to the hardware below. How the JVM executes the code is irrelevant as long as it does it per the contract it is designed under. If you want to know more about the contract, feel free to read the Java Virtual Machine Specification: http://java.sun.com/docs/books/jvms/

If you want to learn more about the Computer Science concept of a Virtual Machine, then feel free to start here: http://en.wikipedia.org/wiki/Virtual_Machine

And if the JIT is that hot, then why bother with the rest of the cruft?

What cruft? There is no cruft.

Why not Simply JIT the code and launch it native and abandon the notion of a VM?

Early JITs pretty much did a compile at startup and then disappeared into the background. But you still need services like object creation, object management, heap management, garbage collection, thread management, etc. Those are all services integral to the JVM. There's no reason to compile new code to do it when the services have already been compiled into the VM layer.

With all the optimizations that JIT can do, how come it is not a stand-alone native compiler?

I just got done yelling at the original moron for this complaint. Don't you think you should pay closer attention to that reply rather than repeating the same mistake?

Are you saying that in the middle of execution post _JIT, that the VM will simply halt application, roll everything back or save the state of the application, recompile the code ( I am assuming a new executable image is created ) reset all the data and then relaunch at the last know Instruction Pointer? How can that be if the code has recompiled since all kinds of code is now very different?

You're thinking at least, but you don't understand the coupling of classes inside the JVM. Each class in Java is an independent code file that does NOT link at runtime. Inside each of those code files is a collection of methods. Each of these methods is an independent chunk of code. When a call is made from one method to another, control is handed off to the JVM so that it can be redirected to the correct target.

Think about that for a moment. What you effectively have is a bunch of loosely coupled code modules floating around in memory. The default way of executing a method in the Hotspot JVM is to run it through an interpreter. Very clean and simple, though not exactly fast. But if the HotSpot JVM sees that a method is being executed a lot (remember, it gets control every time a method is called!), it will change the code path. It will first compile the bytecode into native code, then perform a native jump to the new method. All method and return calls (unless they get inlined!) will be compiled into native instructions that jump back to the JVM's control.

Now if the JVM continues to see a method called a lot, it will decide to waste a LOT of CPU power on optimizing it. It will do all kinds of analyses on the path the code can execute, if it is possible for an edge case to occur, if there are instructions that will never get executed, so on and so forth. It will then create a super-optimized piece of native code that is logically wrong. And when I say it is logically wrong, I mean that there are checks or huge swathes of code that simply don't exist. It's just b

A few more links...

Optimizations added to Java 5.0:
http://java.sun.com/performance/reference/whitepapers/5.0_performance.html

Hotspot internals Q&A session:
http://blogs.sun.com/nike/entry/hotspot_internals_q_a

Another highly interesting set of benchmarks:
http://java.sys-con.com/read/45250.htm?CFID=388847&CFTOKEN=9460D898-B6BB-AC8B-3C74121E272A4D92

A few more links...

Optimizations added to Java 5.0:
http://java.sun.com/performance/reference/whitepapers/5.0_performance.html

Hotspot internals Q&A session:
http://blogs.sun.com/nike/entry/hotspot_internals_q_a

Another highly interesting set of benchmarks:
http://java.sys-con.com/read/45250.htm?CFID=388847&CFTOKEN=9460D898-B6BB-AC8B-3C74121E272A4D92

Unless the VM directly exposes the application that is running within the VM to an OS call ( fopen() ) then the VM must puts its own wrapper around it, do whatever error checking the VM is going to do, then pass it to the OS, let the OS complete the operation, take the handoff back from the OS, then handoff back to the application that is running within the VM.

Do you any concept at all what a Just In Time Compiler is? The JVM has absolutely no problem linking to an fopen() call because it compiles the code into native instructions. The reason why it's faster is because it can optimize that native code at runtime. i.e. It can take the results of runtime profiling and recompile the source into a different code path. That code path can execute for as long as the JVM detects that it is valid. The moment the JVM detects that it is invalid, it can recompile with a more general code path.

You assume there is something magical about system calls. Why? System calls link against code just fine, and an fopen() will run just as fast in Java as it will in C. (Though there's no performance gain because the OS calls are out of the VM's reach.)

I really doubt if java is going to do this any faster:

Your Hello World example is a straw-man. There is no significant computation going on there, and therefore, nothing that can truly be tested. Try something more realistic like inserting 10,000 items into a hashtable, running an RC4 encryption routine, performing a Fast-Fourier Transformation, or one of the millions of other processes that will have a real-world result that can be measured and compared.

In these areas the JVM can (and does!) shine because of its ability to optimize execution on the fly. An expert coder can use low-level features of C/C++ to cheat the test (as McCombs managed to do here), but usually only at the expense of violating the test purpose of the test. (e.g. McCombs ignored the fact that the hashtable would normally contain a wide variety of object types, and thus in optimizing for small strings, screwed up the purpose of the test. Even worse, his solution was highly wasteful with memory and has a bug that would result in a buffer overflow if a large enough number of iterations was passed in.)

In apples to apples comparison, the JVM almost always wins. And there's no reason why it shouldn't. The JVM JIT compiler can do all the same optimizations that a traditional compiler can do, plus a wide variety of optimizations that never used to be possible. The JVM is at the cutting edge of Computer Science. It has well over a decade of new technologies on the now-aging C/C++ platform. There are hundreds of academic papers on the engine, and dozens of computer scientists who have helped make it as fast as it is today.

But don't take my word for it. Go read up on the Hotspot VM before you decide to call me a liar again. Here, I'll even get you started.

A decade old, but easy to read introduction to the engine: http://www.javaworld.com/javaworld/jw-03-1998/jw-03-hotspot.html?page=1

A more recent architectural overview on the modern Hotspot compiler:
http://java.sun.com/products/hotspot/whitepaper.html

A variety of papers and presentations on the VM:
http://java.sun.com/javase/technologies/hotspot/publications/

The Hotspot FAQ (answers a lot of questions about why Hotspot sometimes shows up impossibly fast/slow in microbenchmarks):
http://java.sun.com/docs/hotspot/HotSpotFAQ.html

When you're done, think about the number of optimizations the VM is doing in everything from heap management to mallo

Unless the VM directly exposes the application that is running within the VM to an OS call ( fopen() ) then the VM must puts its own wrapper around it, do whatever error checking the VM is going to do, then pass it to the OS, let the OS complete the operation, take the handoff back from the OS, then handoff back to the application that is running within the VM.

Do you any concept at all what a Just In Time Compiler is? The JVM has absolutely no problem linking to an fopen() call because it compiles the code into native instructions. The reason why it's faster is because it can optimize that native code at runtime. i.e. It can take the results of runtime profiling and recompile the source into a different code path. That code path can execute for as long as the JVM detects that it is valid. The moment the JVM detects that it is invalid, it can recompile with a more general code path.

You assume there is something magical about system calls. Why? System calls link against code just fine, and an fopen() will run just as fast in Java as it will in C. (Though there's no performance gain because the OS calls are out of the VM's reach.)

I really doubt if java is going to do this any faster:

Your Hello World example is a straw-man. There is no significant computation going on there, and therefore, nothing that can truly be tested. Try something more realistic like inserting 10,000 items into a hashtable, running an RC4 encryption routine, performing a Fast-Fourier Transformation, or one of the millions of other processes that will have a real-world result that can be measured and compared.

In these areas the JVM can (and does!) shine because of its ability to optimize execution on the fly. An expert coder can use low-level features of C/C++ to cheat the test (as McCombs managed to do here), but usually only at the expense of violating the test purpose of the test. (e.g. McCombs ignored the fact that the hashtable would normally contain a wide variety of object types, and thus in optimizing for small strings, screwed up the purpose of the test. Even worse, his solution was highly wasteful with memory and has a bug that would result in a buffer overflow if a large enough number of iterations was passed in.)

In apples to apples comparison, the JVM almost always wins. And there's no reason why it shouldn't. The JVM JIT compiler can do all the same optimizations that a traditional compiler can do, plus a wide variety of optimizations that never used to be possible. The JVM is at the cutting edge of Computer Science. It has well over a decade of new technologies on the now-aging C/C++ platform. There are hundreds of academic papers on the engine, and dozens of computer scientists who have helped make it as fast as it is today.

But don't take my word for it. Go read up on the Hotspot VM before you decide to call me a liar again. Here, I'll even get you started.

A decade old, but easy to read introduction to the engine: http://www.javaworld.com/javaworld/jw-03-1998/jw-03-hotspot.html?page=1

A more recent architectural overview on the modern Hotspot compiler:
http://java.sun.com/products/hotspot/whitepaper.html

A variety of papers and presentations on the VM:
http://java.sun.com/javase/technologies/hotspot/publications/

The Hotspot FAQ (answers a lot of questions about why Hotspot sometimes shows up impossibly fast/slow in microbenchmarks):
http://java.sun.com/docs/hotspot/HotSpotFAQ.html

When you're done, think about the number of optimizations the VM is doing in everything from heap management to mallo

Unless the VM directly exposes the application that is running within the VM to an OS call ( fopen() ) then the VM must puts its own wrapper around it, do whatever error checking the VM is going to do, then pass it to the OS, let the OS complete the operation, take the handoff back from the OS, then handoff back to the application that is running within the VM.

Do you any concept at all what a Just In Time Compiler is? The JVM has absolutely no problem linking to an fopen() call because it compiles the code into native instructions. The reason why it's faster is because it can optimize that native code at runtime. i.e. It can take the results of runtime profiling and recompile the source into a different code path. That code path can execute for as long as the JVM detects that it is valid. The moment the JVM detects that it is invalid, it can recompile with a more general code path.

You assume there is something magical about system calls. Why? System calls link against code just fine, and an fopen() will run just as fast in Java as it will in C. (Though there's no performance gain because the OS calls are out of the VM's reach.)

I really doubt if java is going to do this any faster:

Your Hello World example is a straw-man. There is no significant computation going on there, and therefore, nothing that can truly be tested. Try something more realistic like inserting 10,000 items into a hashtable, running an RC4 encryption routine, performing a Fast-Fourier Transformation, or one of the millions of other processes that will have a real-world result that can be measured and compared.

In these areas the JVM can (and does!) shine because of its ability to optimize execution on the fly. An expert coder can use low-level features of C/C++ to cheat the test (as McCombs managed to do here), but usually only at the expense of violating the test purpose of the test. (e.g. McCombs ignored the fact that the hashtable would normally contain a wide variety of object types, and thus in optimizing for small strings, screwed up the purpose of the test. Even worse, his solution was highly wasteful with memory and has a bug that would result in a buffer overflow if a large enough number of iterations was passed in.)

In apples to apples comparison, the JVM almost always wins. And there's no reason why it shouldn't. The JVM JIT compiler can do all the same optimizations that a traditional compiler can do, plus a wide variety of optimizations that never used to be possible. The JVM is at the cutting edge of Computer Science. It has well over a decade of new technologies on the now-aging C/C++ platform. There are hundreds of academic papers on the engine, and dozens of computer scientists who have helped make it as fast as it is today.

But don't take my word for it. Go read up on the Hotspot VM before you decide to call me a liar again. Here, I'll even get you started.

A decade old, but easy to read introduction to the engine: http://www.javaworld.com/javaworld/jw-03-1998/jw-03-hotspot.html?page=1

A more recent architectural overview on the modern Hotspot compiler:
http://java.sun.com/products/hotspot/whitepaper.html

A variety of papers and presentations on the VM:
http://java.sun.com/javase/technologies/hotspot/publications/

The Hotspot FAQ (answers a lot of questions about why Hotspot sometimes shows up impossibly fast/slow in microbenchmarks):
http://java.sun.com/docs/hotspot/HotSpotFAQ.html

When you're done, think about the number of optimizations the VM is doing in everything from heap management to mallo

My employer recently adopted Sun's standards. They posted them here: http://developers.sun.com/docs/web-app-guidelines/uispec4_0/

The problem is sometimes that we, the users, are not listened.

My proposal: Fix the fucking GTK-file-selection box! http://www.gnome.org/~seth/designs/filechooser-spec/
Why on earth is "Browse other folders" taking huge amount of screen estate (in save dialog)???
Do hidden files work (when I type ".bashrc" will gedit open it)?

Vista: http://www.tmssoftware.com/atbdev6.htm (?)
XP: http://www.microsoft.com/library/media/1033/windowsxp/images/using/setup/tips/68222-click-save.gif
Leopard: http://www.betalogue.com/images/uploads/finder/OpenDialogBox-ListView.gif
Java: http://java.sun.com/docs/books/tutorial/figures/uiswing/components/FileChooserOpenMetal.png
Other: http://www.guidebookgallery.org/screenshots/openfile
More: http://www.raizlabs.com/interface/hall-of-shame/default.asp

There is even a theme to change it to KDE style!!!
KGtk: http://www.kde-apps.org/content/preview.php?preview=1&id=36077&file1=36077-1.png&file2=36077-2.png&file3=36077-3.png&name=KGtk+(Use+KDE+Dialogs+in+Gtk+Apps)&PHPSESSID=83fa01cf68ec222d01626c20f3ebe9af

Some would argue that all of these deviations from their core business is why Sun is in the trouble they're in now.

Lately they have been doing quite well I thought. They made a decent profit last four quarters in a row.

McNealy is a shitty CEO, and should have been canned a long time ago.

Er, you know that Jonathan Schwarz has been the CEO of Sun for quite some time now?

"Some" people are way ahead of the curve on being an internet of its own, but not only the telco wired land.

After all, the network is the computer ... BHWAHAHA ! ;)

In reality, the "free" stuff is not really all that competitive with products that are expensive. [...] There are some exceptions, of course, like apache, and linux is obviously successful in the server market.

All you see is the desktop, but the desktop is the exception. You mentioned Linux being competitive on the server market, yes, and what about Linux on appliances: wireless access points, NAS, network printers, network cameras, mobile phones, etc ? Linux devices probably outnumber Windows devices by far. The OLPC foundation is going to produce millions of laptops running 100% open source software. Google built their infrastructure on open source software, just like my of their competitors. What about Firefox, (Open)Solaris, Perl, Python, PHP, MySQL, PostgreSQL, BIND, Sendmail, Postfix. All of these are open-source. And Java (now open source), which runs on 1+ billion mobile phones ?

"The free stuff is not really all that competitive" What planet are you living on ?!

*sigh*

As someone who works for Sun, I feel the need to point you to our lovely UltraSPARC T2. You will soil yourself.

Systems this large are usually offered by cray, sun, and other players (sure also dell)

But if you ask whats this one different from the others I must say that it is in the interconnection network. It uses only 2 SUN (extremely high density) switches called magnum to interconnect the system, and its one of a kind infiniband switch, as described here (among other features with links): http://blogs.sun.com/marchamilton/entry/more_ranger_facts_and_figures

I would have agreed with you about 10 or 15 years ago. So you tell me where the professional me stop and the personal me start? I pretty much work round the clock for a larg US multinational, where my professional space and my personal space are intertwined like a devil's knot. I think the point is, the network has changed the boundaries between the two spaces, perhaps even eliminated it. Personally, I think CNN should allow all their employees blog or do what ever else they want to do with their own free time. I personally think, this would be a good thing for everyone. The best thing CNN has going for them are their people. These people can be great ambassadors for the company. One only needs to look to http://blogs.sun.com/ to realize how Sun has figured out a way to provide a corporate sponsored blogspace whilst at the same time excersice a degree of implicit control over the content.

Google got its start during a brief age where efficiency didn't matter at all. The Moore's curve was steep, Oil was $10/barrel, coal and gas were also at historical lows when adjusted for inflation and X86 PCs became a dirt-cheap commodity, land was cheap even in Silicon Valley and free open source *nix variants were reaching enterprise-class stability. Therefore cheapest/easiest way to build a massive international web infrastructure was to throw more X86 hardware at it.

Now that oil is nearly $100/barrel, huge demand has driven up the cost of even coal energy and electricity is becoming significantly more expensive even for locales which have not yet enacted carbon taxes; Google might be wise to consider hardware with a SWaP (Space Watts and Performance) of their IT infrastructure. Disclaimer, I work for Sun, I don't know if IBM, Intel , HP and Dell have yet made any progress in chip multithreading efficiency. But Sun's introductory Niagara servers (T1, T1000, T2000) already have 8 to 10 times the SWaP performance of conventional X86 web server architectures.

If this "perceived value" theory held any water, MS would be out of business and Sun would be the monopoly.

Sun's OS was once coveted, but nobody used because it was too expensive. Now that you can get it free for any old PCs, still nobody runs it. Sun's so desperate to sell desktops that its entry-level Ultra is an AMD machine they'll install anything from Linux to Windows on, not just Solaris.

Nope, the reason folks don't switch away from Windows isn't a big mystery; it's the human condition: laziness. Or, if that hits too close to home, call it inertia, resistance to change, fear of the unknown, herd mentality, call it what you will.

The only way to overcome the Windows inertia would be a heavily-funded, big-name PC maker willing to ditch Windows to risk becoming another Apple, built around Linux-or-nothing on well-designed hardware. Then, a ton of universities teaching everything primarily on Linux so the supply of Linux-savvy workers would increase. Then, other PC makers following suit in a way Apple currently doesn't allow, each carving its own unique niche rather than considering themselves artless cloners selling cheap knock-offs. Even if that's the reality, distort the reality with an inspired design.

"We don't do Windows" is simply too risky a slogan for IT lemmings to grok. So many vendors try to copy Apple, so few seem to be willing to do what it takes to be a better Apple.

*whine* "The PC business is just a commodity now *sniffle* The monopoly is too powerful to go up against *sob* I can't even blow my nose without paying homage to Redmond! *tears* I hate what's been done to my industry!"

Shut up, pathetic pansy. *yawn* We're giving you dang software for free, so go build some great hardware to run it on and give Ballmer and Jobs the finger. If you can't figure out how to do it, your MBA isn't worth the recycled oilrag it's printed on. If you're an IT pro who can't do Linux, your skills aren't as marketable as the guy who can, so stop whining and learn. Any CEO or CTO of a PC manufacturer without the brains, vision, or cajones to take the Apple business model to Linux needs to be fired by their directors at the next meeting, because they're sit idly by while some other company starts the inevitable revolution.

If an Anonymous Coward can figure it out, it can't be rocket science.

If this "perceived value" theory held any water, MS would be out of business and Sun would be the monopoly.

Sun's OS was once coveted, but nobody used because it was too expensive. Now that you can get it free for any old PCs, still nobody runs it. Sun's so desperate to sell desktops that its entry-level Ultra is an AMD machine they'll install anything from Linux to Windows on, not just Solaris.

Nope, the reason folks don't switch away from Windows isn't a big mystery; it's the human condition: laziness. Or, if that hits too close to home, call it inertia, resistance to change, fear of the unknown, herd mentality, call it what you will.

The only way to overcome the Windows inertia would be a heavily-funded, big-name PC maker willing to ditch Windows to risk becoming another Apple, built around Linux-or-nothing on well-designed hardware. Then, a ton of universities teaching everything primarily on Linux so the supply of Linux-savvy workers would increase. Then, other PC makers following suit in a way Apple currently doesn't allow, each carving its own unique niche rather than considering themselves artless cloners selling cheap knock-offs. Even if that's the reality, distort the reality with an inspired design.

"We don't do Windows" is simply too risky a slogan for IT lemmings to grok. So many vendors try to copy Apple, so few seem to be willing to do what it takes to be a better Apple.

*whine* "The PC business is just a commodity now *sniffle* The monopoly is too powerful to go up against *sob* I can't even blow my nose without paying homage to Redmond! *tears* I hate what's been done to my industry!"

Shut up, pathetic pansy. *yawn* We're giving you dang software for free, so go build some great hardware to run it on and give Ballmer and Jobs the finger. If you can't figure out how to do it, your MBA isn't worth the recycled oilrag it's printed on. If you're an IT pro who can't do Linux, your skills aren't as marketable as the guy who can, so stop whining and learn. Any CEO or CTO of a PC manufacturer without the brains, vision, or cajones to take the Apple business model to Linux needs to be fired by their directors at the next meeting, because they're sit idly by while some other company starts the inevitable revolution.

If an Anonymous Coward can figure it out, it can't be rocket science.

Because TCP/IP has become the generic name for the IETF managed suite of protocols. BGP is only one of the routing protocols used to route IP packets. If you're going to be a pedant, then at least be accurate: from a traffic perspective it's IP, everything else rides on top of it (except ARP and RARP).

SO, Smart arse: Here's the real deal: MPLS creates effective PVCs that map BGP propagated routes to telco circuits in a deterministic manner, which undermines the fundamental dynamic nature of all Internet routing protocols, of which BGP is only one (and the most brain dead/static). The reason we have such a cluster-bollocks is because Cisco made underpowered, fundamentally single-threaded, routers, and so were wedded to Bellman-Ford/distance vector routing protocols. This is because their routers couldn't handle the demand of link-state algorithms, especially OSPF, which would not have required any of this mucking around with alternate routing protocols, Autonomous System numbers and route reflectors, since it included the concept of stub, not so stubby, and aggregated areas. Instead they had to devise a suite of ever increasingly unreliable/suboptimal routing protocols named IGRP (It Greatly Reduces Performance), EIGRP (Egads! It Greatly Retards Packets), and BGP (Broken Gateway Protocol).

Believe it or not, there were, and may still be, networks that run OSI routing protocols to route IP, like IS-IS, which works pretty well. The problem is, all these require people with clue and background, which the ILECs, in their race to the bottom, have jettisoned wholesale, to be replaced with those who hold vendor certs, and therefore only know one vendor's approach, and nothing of the history or underlying protocols. Before spouting off, go read your Perlman, Stevens, Moy, and anything written by Li.