I wondered why it's so wrong if the Microsoft OS works better with its own software?
If Microsoft had solid competition, there would be no problem. The issue as it stands is that Microsoft has a monopoly on the Operating System business. Because of that monopoly, Microsoft can crush nearly any competitor they want in other areas by ensuring that their own software works better than the competitor's software. Examples of this include:
- Windows Media Player provides a superior Windows experience than RealPlayer
- IE provided a superior browsing experience on Windows over Netscape Navigator
In both cases, Microsoft effectively wiped out those company's markets by giving the software away for free. Which meant that Real and Netscape could no longer charge for their software.
Now one can argue that Microsoft produced superior products to both company's offerings. And there would be truth to that statement. The problem is that Microsoft ensured that there will never again be competitors in either space. Microsoft effectively wiped both markets out of existence and forced consumers to accept higher costs for Windows to subsidize those markets. Even worse, there is then zero incentive for Microsoft to innovate in either market. So consumers pay higher prices when no new development is happening in those areas.
While some balance is returning to those markets thanks to Apple and Open Source, the damage done has been extremely negative for the industry, with the WMV pseudo-standard and the IE pseudo-standard locking out competing OSes for nearly a decade. From an economist's point of view, the OS, multimedia, and web-browser markets would be a lot farther along today if Microsoft had never managed a stranglehold on these markets.
Why the hell do EA men and Sweeney make the crapiest games and then complain about the gaming market?
In his defense, Tim Sweeney (and by extension, John Carmack) create gaming engines for a living. The games they put out (Unreal and Quake/Doom respectively) are mostly technology demonstrations, and not really games in of themselves. Tim expects licensees like Activision to produce "fun" games off his work.
Sooo... in the grand scheme of things, Sweeney has found himself a free pass out of the creative side of game development.
The catch-22 is that they come from the same type of breeder reactor and have to separated by processing. Ergo, lack of breeder reactors == lack of PU-238. You follow?
Ion propulsion does indeed work. NASA has used it on a variety of craft to great success. There's just one catch-22: You need POWER to convert into thrust. And where are you going to get that power when you're too far from the Sun for solar panels?
Oh, oh! I have an idea! Plutonium would solve everything!
The official position of the US Government is that breeder reactors are a potential threat. Bad Guys(TM) might get ahold of fissible materials bound for reprocessing, and THEN where would we be, hmm?
Never mind the fact that it's about 1000x simpler to create a gun-type bomb with Uranium rather than creating an uber-complex implosion device. All terrorists obviously have access to the advanced nuclear engineering and simulation capabilities necessary to create a plutonium implosion device.
...
Despite the fact that they can't refine Uranium...
Maybe you don't, but I got most of my job offers on my last job search through Monster. I had my resume up for a day and a half, after which I had to take it down because I was getting too many calls!
The scary part is that I still get calls and emails from recruiters, even though I've happily settled into a job and haven't been on the market in half a year.
Thanks for the link. Unfortunately, Microsoft is NOT promising any of the features I'm referring to. I read the white paper on Circular References. Are they building a better, more standards-compliant Javascript engine? No, they're only fixing circular references, a problem that never should have existed in the first place. I read the white paper on "DOM Core Improvements". Are they adding DOM2 features? No, they're just fixing a few minor differences between the W3C spec and their implementation of DOM.
About the only spec that Microsoft MIGHT actually be taking seriously is CSS2.1. And even then, I'm not holding my breath that they do a good job of it.
We had the discussion you were asking for yesterday.
No, no we didn't. Yesterday we had the discussion that Microsoft promised standards mode to be on by default rather than their previous promise to turn it OFF by default. At no point did Microsoft say *what* standards they were actually promising to support.
...tell Microsoft that we don't give a flying hoot about Activities and Internet Julian Fries. As developers, we want to know if they'll support CSS2 (and God-forbid even some CSS3 *gasp!*), DOM2, SVG, ECMAScript 3rd Edition, and half-a-billion other standards that they've been ignoring. If they want to make developers really happy while future-proofing their browser, they'll support HTML5 and ECMAScript 2.0.
You are the type of person who simply wants to show off.
Someone took the time to explain to you how things actually work regardless of the fact that you didn't do even a modicum of research up front. That someone also gave you a very large pile of ready-made research material to help you understand so that you could discuss more intelligently. (Which you obviously didn't read.) Even then, that same person was willing to explain the inner workings of the Hotspot VM in terms that were easy to digest and understand.
And the only response you can come up with is, "Wah! Show-off!"?
Grow up, will you? Your behavior is unbefitting of a man your age.
Actually, I'm still pretty happy about this. Regardless of whether Microsoft was first or not, they're going to manage to market the concept far better than a conglomeration of OSS developers ever could. (Sorry, guys!) If everything goes well, perhaps the public impression of managed code being "nothing but an interpreter" can finally get turned around and Computer Science can keep moving forward.:-)
Several of the vulnerabilities in libPNG are exploitable integer overflow vulnerabilities. Java does absolutely nothing to stop those vulnerabilities.
Bull. Java will overflow the integer, but how exactly will it result in an underflow or an overflow of a memory buffer if Java does not have pointers? All you have is a negative value. At best you'll cause an IndexArrayOutOfBoundsException when you attempt to access an invalid array location. At worst, the code will detect it as an invalid value and move on.
And even if it does, much of the java runtime is written in C, and is just as vulnerable to buffer overflows.
Oh noes! Not C! That must make it, like, automagically vunlnerables!
Yeah.
The JVM is a design that is logically proven to be 100% absolutely secure. If Java code can reach down and manipulate memory at the level of the JVM, then there is a serious flaw in the JVM's implementation. A flaw that means that it does NOT meet the Java spec. Thankfully, Sun has a Test Kit that checks for compliance before a VM can be called "Java". It does a pretty decent job of ensuring the correctness of a VM.
People should stop thinking that somehow interpreted languages (Java,.Net, VB6, etc) are solutions to security problems. All they do is to raise the bar.
Raising the bar is exactly what I'm talking about. Java is impervious to buffer overflows because it does NOT allow for memory management. Memory management is the responsibility of the JVM.
Oh, and Java is not interpreted. Strike 3, you're out.
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...
It would probably be a bit painful. Many cell phones require you to hook up a transfer cable to install a new set of firmware. Of course, this is a fancy new smartphone OS, so it's possible that Google has devised a software update procedure. However, if they have designed an update procedure, what's to stop attackers from attacking the update procedure? (Methinks that an unauthorized GSM base station is all that's needed for a man-in-the-middle attack...)
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/
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
The VM isn't written in some magical code above and beyond normal code - it has to be written in C/C++ itself.
Actually, it doesn't *have* to be written in C/C++. It can be written in any self-hosting language. The fact that you are unaware of that already displays your ignorance.
So why not just write any optimizations the VM can do into your own code.
You're really not wrapping your head around this idea of runtime optimizations, are you? The idea that the Virtual Machine can understand the underlying data structures well enough to NOT compile in any exception checking or cast checking until the JVM traps changes to the data structures that then back out those optimizations is not percolating, is it?
Can you do it in C/C++ code? Sure. The result would look a lot like what the JVM is doing, except with a lot of duplicate hand-written assembly code to provide multiple execution paths.
I could easily write some embedded assembler to test the CPU type (x86 cpuid op ill do nicely) and base the flow of my C/C++ code around that.
Modern C/C++ compilers already do that, genius. As I mentioned before, it bloats the code beyond belief. (But it does work!) That covers only a small section of the optimizations that the JVM is capable of performing. Though it is theoretically possible, no one has yet produced a C/C++ compiler that creates programs that can insert and yank alternate versions of a code path depending on the runtime profiling. And even if they did, it would produce a rather MASSIVE (possibly reaching an impractical size) increase in the the size of the executable. The JVM gets around this because it can generate the code at runtime. Thus the JVM can use a set of optimizations that cannot be computed at compile time.
Now hand in your geek card. You're fired for failing Comp-Sci.
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.
But if its on a static machine architecture why bother?
Because there's no such thing? The performance paths of a PIV, Core Duo, Xeon, and AMD64 are all different. Should we continue compiling code for the lowest common denominator and just accept that our code isn't performing as well as it could?
And what of runtime optimizations? If the VM detects that this collection only contains objects of type X, it can do away with the casting checks on that collection. Yet if it detects an object of type Y added to the collection, it can undo the optimization on the fly. Statically compiled code can't do that. At best it can provide alternate code paths under certain conditions. Of course, additional code paths massively bloat the executables.
The JVM does these sorts of optimizations today, and thus has unparalleled performance when working with OOP code. That's why all these benchmarks show the JVM kicking ass and taking names later:
A C compiler can still outperform a JVM under ideal conditions, but ideal conditions are becoming more scarce for C compilers. In real-world terms, the JVM is going to be able to run your average Java code far faster than your average C/C++ code.
This idea that native code is always faster than virtualized code is a myth, and an old one at that. You need to get with the times or you'll find yourself a dinosaur. (And you don't really want to be brushing up on your "Get off my lawn!" speech yet, do you?;-))
Look a few posts up to the link the AC posted. There's also an old Slashdot story on it, though I can't be flummoxed to try and dig it out right now.:-)
You know, I was out in SanFran for a while. Didn't like it at all. The food was terrible (I'm not a fan of seafood, though there was some good Chinese), the transportation system sucked, there were technology wannabes everywhere (did you know that Linux runs over 80% of the internet? Heard that gem on the BART from some fool who didn't understand that Apache != Linux), the weather was painful (Am I hot or cold? No idea, what with the sun and the Bay breeze), Christmas doesn't feel like Christmas, shopping sucks, and the city was dirty as a wild pig with unlimited slop. (Especially the rather disgusting homeless.) About the only thing I liked was the job. In the end it wasn't enough to keep me out there.
FWIW, I'm having the same problem you are. The Chicago-based company I work at right now has done a bang-up job of separating the wheat from the chaff. The people who work here are extremely smart, and our interviewees always have positive things to say about us to their recruiters.
Unfortunately, I don't think we have any magical formula for finding the right programmers. As Joel says in his articles, all the best developers are already working. All you can do is wait patiently and try to lure them in when they decide to switch jobs.
Speaking of which, if you are a kick-ass programmer in the Chicago area, we have plenty of openings! My email address is right above.;-)
Slashdot Mirror
If Microsoft had solid competition, there would be no problem. The issue as it stands is that Microsoft has a monopoly on the Operating System business. Because of that monopoly, Microsoft can crush nearly any competitor they want in other areas by ensuring that their own software works better than the competitor's software. Examples of this include:
- Windows Media Player provides a superior Windows experience than RealPlayer
- IE provided a superior browsing experience on Windows over Netscape Navigator
In both cases, Microsoft effectively wiped out those company's markets by giving the software away for free. Which meant that Real and Netscape could no longer charge for their software.
Now one can argue that Microsoft produced superior products to both company's offerings. And there would be truth to that statement. The problem is that Microsoft ensured that there will never again be competitors in either space. Microsoft effectively wiped both markets out of existence and forced consumers to accept higher costs for Windows to subsidize those markets. Even worse, there is then zero incentive for Microsoft to innovate in either market. So consumers pay higher prices when no new development is happening in those areas.
While some balance is returning to those markets thanks to Apple and Open Source, the damage done has been extremely negative for the industry, with the WMV pseudo-standard and the IE pseudo-standard locking out competing OSes for nearly a decade. From an economist's point of view, the OS, multimedia, and web-browser markets would be a lot farther along today if Microsoft had never managed a stranglehold on these markets.
Sooo... in the grand scheme of things, Sweeney has found himself a free pass out of the creative side of game development.
The catch-22 is that they come from the same type of breeder reactor and have to separated by processing. Ergo, lack of breeder reactors == lack of PU-238. You follow?
Ion propulsion does indeed work. NASA has used it on a variety of craft to great success. There's just one catch-22: You need POWER to convert into thrust. And where are you going to get that power when you're too far from the Sun for solar panels?
Oh, oh! I have an idea! Plutonium would solve everything!
Wait... ah, crap.
The official position of the US Government is that breeder reactors are a potential threat. Bad Guys(TM) might get ahold of fissible materials bound for reprocessing, and THEN where would we be, hmm?
...
Never mind the fact that it's about 1000x simpler to create a gun-type bomb with Uranium rather than creating an uber-complex implosion device. All terrorists obviously have access to the advanced nuclear engineering and simulation capabilities necessary to create a plutonium implosion device.
Despite the fact that they can't refine Uranium...
Of course, not many users install Flash anyway. It ships pre-installed on most computers these days.
Maybe you don't, but I got most of my job offers on my last job search through Monster. I had my resume up for a day and a half, after which I had to take it down because I was getting too many calls!
The scary part is that I still get calls and emails from recruiters, even though I've happily settled into a job and haven't been on the market in half a year.
Thanks for the link. Unfortunately, Microsoft is NOT promising any of the features I'm referring to. I read the white paper on Circular References. Are they building a better, more standards-compliant Javascript engine? No, they're only fixing circular references, a problem that never should have existed in the first place. I read the white paper on "DOM Core Improvements". Are they adding DOM2 features? No, they're just fixing a few minor differences between the W3C spec and their implementation of DOM.
About the only spec that Microsoft MIGHT actually be taking seriously is CSS2.1. And even then, I'm not holding my breath that they do a good job of it.
...tell Microsoft that we don't give a flying hoot about Activities and Internet Julian Fries. As developers, we want to know if they'll support CSS2 (and God-forbid even some CSS3 *gasp!*), DOM2, SVG, ECMAScript 3rd Edition, and half-a-billion other standards that they've been ignoring. If they want to make developers really happy while future-proofing their browser, they'll support HTML5 and ECMAScript 2.0.
I'm not holding my breath, though.
And the only response you can come up with is, "Wah! Show-off!"?
Grow up, will you? Your behavior is unbefitting of a man your age.
Managed code! Look at that! Microsoft has managed to prove...
:-/
:-)
What OSS developers already proved years ago.
Actually, I'm still pretty happy about this. Regardless of whether Microsoft was first or not, they're going to manage to market the concept far better than a conglomeration of OSS developers ever could. (Sorry, guys!) If everything goes well, perhaps the public impression of managed code being "nothing but an interpreter" can finally get turned around and Computer Science can keep moving forward.
Yeah.
The JVM is a design that is logically proven to be 100% absolutely secure. If Java code can reach down and manipulate memory at the level of the JVM, then there is a serious flaw in the JVM's implementation. A flaw that means that it does NOT meet the Java spec. Thankfully, Sun has a Test Kit that checks for compliance before a VM can be called "Java". It does a pretty decent job of ensuring the correctness of a VM.Raising the bar is exactly what I'm talking about. Java is impervious to buffer overflows because it does NOT allow for memory management. Memory management is the responsibility of the JVM.
Oh, and Java is not interpreted. Strike 3, you're out.
For this type of problem? You bet your horse it is. Buffer overflow problems are so 1970's. Can we please move on?
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...
It would probably be a bit painful. Many cell phones require you to hook up a transfer cable to install a new set of firmware. Of course, this is a fancy new smartphone OS, so it's possible that Google has devised a software update procedure. However, if they have designed an update procedure, what's to stop attackers from attacking the update procedure? (Methinks that an unauthorized GSM base station is all that's needed for a man-in-the-middle attack...)
He was referring to Android, not the libraries. :-/
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.
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
What cruft? There is no cruft.
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.
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?
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
Can you do it in C/C++ code? Sure. The result would look a lot like what the JVM is doing, except with a lot of duplicate hand-written assembly code to provide multiple execution paths.Modern C/C++ compilers already do that, genius. As I mentioned before, it bloats the code beyond belief. (But it does work!) That covers only a small section of the optimizations that the JVM is capable of performing. Though it is theoretically possible, no one has yet produced a C/C++ compiler that creates programs that can insert and yank alternate versions of a code path depending on the runtime profiling. And even if they did, it would produce a rather MASSIVE (possibly reaching an impractical size) increase in the the size of the executable. The JVM gets around this because it can generate the code at runtime. Thus the JVM can use a set of optimizations that cannot be computed at compile time.
Now hand in your geek card. You're fired for failing Comp-Sci.
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
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.)
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
And what of runtime optimizations? If the VM detects that this collection only contains objects of type X, it can do away with the casting checks on that collection. Yet if it detects an object of type Y added to the collection, it can undo the optimization on the fly. Statically compiled code can't do that. At best it can provide alternate code paths under certain conditions. Of course, additional code paths massively bloat the executables.
The JVM does these sorts of optimizations today, and thus has unparalleled performance when working with OOP code. That's why all these benchmarks show the JVM kicking ass and taking names later:
http://www.kano.net/javabench/
A C compiler can still outperform a JVM under ideal conditions, but ideal conditions are becoming more scarce for C compilers. In real-world terms, the JVM is going to be able to run your average Java code far faster than your average C/C++ code.
This idea that native code is always faster than virtualized code is a myth, and an old one at that. You need to get with the times or you'll find yourself a dinosaur. (And you don't really want to be brushing up on your "Get off my lawn!" speech yet, do you?
Look a few posts up to the link the AC posted. There's also an old Slashdot story on it, though I can't be flummoxed to try and dig it out right now. :-)
You know, I was out in SanFran for a while. Didn't like it at all. The food was terrible (I'm not a fan of seafood, though there was some good Chinese), the transportation system sucked, there were technology wannabes everywhere (did you know that Linux runs over 80% of the internet? Heard that gem on the BART from some fool who didn't understand that Apache != Linux), the weather was painful (Am I hot or cold? No idea, what with the sun and the Bay breeze), Christmas doesn't feel like Christmas, shopping sucks, and the city was dirty as a wild pig with unlimited slop. (Especially the rather disgusting homeless.) About the only thing I liked was the job. In the end it wasn't enough to keep me out there.
FWIW, I'm having the same problem you are. The Chicago-based company I work at right now has done a bang-up job of separating the wheat from the chaff. The people who work here are extremely smart, and our interviewees always have positive things to say about us to their recruiters.
;-)
Unfortunately, I don't think we have any magical formula for finding the right programmers. As Joel says in his articles, all the best developers are already working. All you can do is wait patiently and try to lure them in when they decide to switch jobs.
Speaking of which, if you are a kick-ass programmer in the Chicago area, we have plenty of openings! My email address is right above.