Are you purposely ignoring all the other benchmarks? For example, the one immediately preceding the one you cited.
In many situations, Java absolutely thrashes VBS/JS/Python/Perl. In other situations, it doesn't. The numbers certainly shouldn't lead you to conclude that Java is the slowest of them all.
There are optimizations that a runtime-managed environment like Java can make that a non-managed environment cannot. For one example, the runtime could tell if a virtual method is not actually overridden in any class that is currently loaded, and so can be treated as a nonvirtual method (inlined into call sites, for example). I'm sure there are many other examples, but I'm not an expert.
Another possible reason is because C/C++ has to free up memory as it goes; in Java, that cost is paid only during garbage collection (which might never happen during the lifetime of the process), and even when it does, in some cases it could be a lower total cost than the equivalent time spent cleaning up in C/C++. (Not taking into account libraries that add automatic memory management to C/C++.)
Fine. I changed "lawsuit" to "attack" (I couldn't think of a more suitable word) and the results didn't change much... although it does surface a lot of hits speculating that MS may launch a patent attack on Linux in the future, and coverage of their announcement that they will beef up their patent portfolio.
A google search for "microsoft patent lawsuit" comes up with a ton of examples of them settling or losing lawsuits where they're the defendant, but I don't see any where they're suing someone else for infringement.
Thanks for the correction. Google found this page on the subject:
As you can see from this graph, TSCP has even more branches and they're harder to predict, so it's a good test of a processor's BPU and ability to recover from mispredicted branches. TSCP also has relatively high ILP, so it tests the processor's instruction scheduler. It clearly fits in L1 cache, so it doesn't test a computer's L2 cache or main memory performance. Basically, TSCP measures a processor core's worst case integer performance. It may be a good predictor for compilers, other AI programs, and other branch intensive code.
I wonder if the "relatively high ILP" balances out the branching. Ah well... it seems even with synthetic benchmarks, things are rarely as simple as they might first appear.
If Intel's current roadmap is any indication, AMD made the right decision and Intel made the wrong one, at least for the long term. They're planning on phasing out the P4 architecture in favor of multi-core variants of Pentium-M, which is a lot closer to PIII than P4 in terms of pipeline length.
You've gotta give Intel credit for having the guts to go all the way with the clock speed thing, though. But then I also applaud them for their daring design with Itanium, even though we all know how that has worked out for them.
I'm no expert on CPU architecture or synthetic benchmarks, but it seems like most of the synthetic benchmarks they used (primegen, super_pi, TSCP, uBench CPU) are the kinds of jobs that the Pentium 4 architecture is specifically designed to handle well: not much memory bandwidth required, little unpredictable branching. In these situations, the Xeon's 63 percent clock speed advantage is definitely going to make itself felt.
My guess is that if these same benchmarks had been run on any Athlon vs. the equivalent P4 throughout history, the outcome would've been similar. But the results would also have been as irrelevant yesterday as they are today, since we all know the Xeon isn't 40% faster than the A64 in anything like real-world usage.
I hate the "all [other] things being equal" argument.
All things being equal, you would choose the DBMS whose executable takes less space on your hard disk.
All things being equal, you would choose the DBMS vendor that is located closest to you (in case they need to fly someone out).
All things being equal, you would choose the DBMS with the shorter name (less to type in at the command prompt).
All things being equal, you would choose the DBMS with the nicer looking logo.
I'm going to hazard a guess that you don't consider any of these when choosing a DBMS. In the same way, it is not unreasonable for someone to not consider the Java memory footprint penalty.
I'm obviously hyperbolizing, but, all things are usually not equal. The poster's point was that memory consumption is no longer a great reason not to use a Java-based database. Whether you agree with that is a matter of your particular set of needs and constraints, but the whole "Memory still costs a nonzero amount of money" argument is just annoying.
That's the reaction I had to this article as well. It seemed to respond to the AT and SR benchmarks by saying "These tests doesn't put the right kind of load on the storage subsystem to demonstrate the benefits of RAID 0, therefore they're bad tests." Whereas that's the point of those articles--that the kind of loads you're likely to encounter are not going to be affected much by RAID 0.
The tweakers.net article does also say that the AT and SR benchmarks do not give enough credit to their readership's ability to generate heavy I/O loads, via multitasking (I think an example was scanning your HD for viruses while starting a game). Maybe some people do that, but I for one found the examples they suggested pretty silly.
That said, plenty of people testify that RAID 0 feels faster, and I believe them. There's been similar backlash against SMP systems on the desktop for years, but back when the Pentium Pro was top dog I had a dual-PPro system that definitely felt faster than the equivalent single-PPro setup, though the benchmarks at the time couldn't explain it.
I wonder if the benchmarks they use today might be flawed because they only measure the total elapsed time of a relatively long script. For example, the Business Winstone script might take 5% less total time with Machine A than Machine B. That might not seem like a big improvement, but what if the 5% improvement was concentrated entirely in application launch times? I.e. the monster Excel spreadsheet still takes 120 seconds to do the filtering, pivot, recalc, solve operations, but startup time has been cut from 6 seconds to 2 seconds. The perceived improvement to the user would be much greater than 5%, and certainly much greater than if the 120-second operation had been reduced to 116 seconds.
It might be useful to have real-world benchmarks where the result of each run is not a scalar, but a vector (i.e. a set of waypoints and how long it took from each one to the next). Or do these already exist?
SQL injection is a very large problem in the enterprise
It doesn't have to be. In Java, for example, just always use PreparedStatement, which disambiguates queries and parameter values. There's an equivalent in.NET; not sure about other programming platforms.
It sounds like the author is comparing PHP to old-style ASP. ASP (non-.NET) was a web scriping language like PHP, JSP, CF, etc., where basically all you did was intermingle code blocks with HTML.
ASP.NET (and the Java equivalent, JavaServer Faces) have a much different, (arguably) more sophisticated approach to web development. There is actually a pretty good story for UI/logic separation, eventing, and maintaining state. You can have your HTML tags constituted into a mutable object graph before rendering (example).
The end result is a development style that lets one write web apps the same way one writes desktop GUI apps, and as a bonus you get far more compile time guarantees than before (even vis-a-vis compiled scripting languages like JSP). Whereas in most scripting languages, getting a dynamic <select> to default to the proper selection and remember its selection across page redraws takes an annoying kludge of code, it's trivial in ASP.NET.
You don't have to like the direction MS has taken with ASP.NET, but the fact that the author didn't even mention the fundamentally different programming model it offers vs. PHP says to me that he didn't bother doing much research into it.
I don't think you really want to run Windows in a VM, at least if you are planning to compile any decently sized project in it. Dual boot is much better IMO.
I found SuSE 9.1 to be pretty much painless to get up and running, beautifully themed right out of the box, and extremely easy to keep up-to-date (with YaST/YOU), but the versions of software that are available on YaST are not always the latest ones. For example, as of this writing they're still on Firefox 0.8 and Thunderbird 0.5.
By the way, I had the same problem with the Windows defrag tool not actually working beyond a certain point. Supposedly, commercial defraggers like Diskeeper work much better.
It does say they were running 21 databases before. With all of the data consolidated into one, you could likely perform that query like so:
SELECT MAX(price) FROM trades WHERE ticker = ?;
Very easy to believe culling that data from several different unindexed databases could take 36 seconds (especially on older hardware), and the latter only 30 millis.
It may well have been the case "well, with Linux, we can buy enough CPU, I/O, and DBA tuning time to make this thing sing. With Windows we blow money of software licenses. With Solaris we blow it on licenses and proprietary hardware."
That may be true, but not to the degree of a 1000X performance increase, which is what I think OP was protesting.
Reflector does an amazing job and lets you decompile into VB.NET, C#, or Delphi (I believe). No serious.NET programmer should be without this tool, as unlike Java, the.NET framework class libraries do not come with source code.
You do lose local variable names, but method parameter names and field names stay intact.
Internet Explorer has had the QuickSearch feature ("g foo" searches google for "foo") for several years, although for some bizarre reason they didn't surface it in the UI. You had to download a PowerToy for IE that was simply a UI for editing registry keys that IE was already checking.
If you still (are forced to) use IE, an easier way to tap into QuickSearch these days is here.
IE <=6 users will be adversely affected, because in any situation where 8-bit alpha blending makes a difference, it will look terrible (not to mention extremely unprofessional) in IE. Like when some people take a.gif that was clearly antialiased for a black background, and slap it on a page with a white background. Do you really want 95%, 94%, 93% (and falling) of the browsing population to see your site like that?
These stupid patents just about piss me off enough that I'm ready to boycott Amazon... and if not for this one issue, they would be my favorite online retailer (well, aside from Newegg).
From what I can tell, Bezos' statements can be summarized as "Don't hate the player, hate the game"--the same line that all the big players use--but it seems that AMZN in particular has gone far off the wrong end of the stupid-patent-o-meter way more than anyone else. (I have no actual data to back up this claim.)
I have heard that IBM alone files 10 patent applications a day. And yet it's Amazon that is the poster child for frivilous patents. I like to think a responsible tech industry giant like Amazon should be able to amass a defensive patent arsenal without stooping as low as they have.
Making it a corporate policy is like saying "All saboteurs, please sign this document swearing you will not steal our intellectual property."
Those who are going to commit espionage are going to do it with or without an iPod, and meanwhile you've seriously inconvenienced owners of MP3 players.
You get used to the case. It bothered me a lot in the beginning, but it goes away. In fact it just might be more readable with the capitalized methods... but still, there's something more aesthetically pleasing to me about Java style case.
I agree that the value keyword is weird. I was pretty opposed to the whole properties thing (not as object oriented) but they turn out to be pretty nice in practice. For a counterexample, defining annotations in Java 1.5 is a lot weirder than attributes in C# (and I believe Java uses "value" as a magic member in this case).
C#'s synchronization utilities are actually much stronger than Java's. The lock statement is identical to Java's sychronized statement (you can't mark a method as locked, you have to put the lock in the method body). But if you want you can also handle the locking yourself by doing Monitor.Enter/Monitor.TryEnter and Monitor.Exit. So if you need to lock in a way that doesn't lend itself to lexical scopes, you're much better off in C# than in Java (where you'd basically have to write your own mutex on top of their synchronization primitives).
Java's Object.wait() and.notify() have Monitor.Wait() and Monitor.Pulse() as their equivalents in C#.
C# has a bunch of facilities (besides just "volatile") to allow you to do some sharing of state across threads without locking at all. Check out the Interlocked class, in the System.Threading namespace. There's also an explicit Thread.MemoryBarrier() operation. Last time I checked (1.4.x) there was no equivalent in Java, although the vast majority of C#/Java programmers should probably stay away from this stuff and stick to locking anyway.
Slashdot Mirror
In many situations, Java absolutely thrashes VBS/JS/Python/Perl. In other situations, it doesn't. The numbers certainly shouldn't lead you to conclude that Java is the slowest of them all.
Another possible reason is because C/C++ has to free up memory as it goes; in Java, that cost is paid only during garbage collection (which might never happen during the lifetime of the process), and even when it does, in some cases it could be a lower total cost than the equivalent time spent cleaning up in C/C++. (Not taking into account libraries that add automatic memory management to C/C++.)
If the stuff could make me stop surfing /. during the work day, it would way more than offset any negative effects!
So again... anyone have any evidence?
You need to read the previous two posts again.
...or in Guantanamo Bay.
A google search for "microsoft patent lawsuit" comes up with a ton of examples of them settling or losing lawsuits where they're the defendant, but I don't see any where they're suing someone else for infringement.
As you can see from this graph, TSCP has even more branches and they're harder to predict, so it's a good test of a processor's BPU and ability to recover from mispredicted branches. TSCP also has relatively high ILP, so it tests the processor's instruction scheduler. It clearly fits in L1 cache, so it doesn't test a computer's L2 cache or main memory performance. Basically, TSCP measures a processor core's worst case integer performance. It may be a good predictor for compilers, other AI programs, and other branch intensive code.
I wonder if the "relatively high ILP" balances out the branching. Ah well... it seems even with synthetic benchmarks, things are rarely as simple as they might first appear.
You've gotta give Intel credit for having the guts to go all the way with the clock speed thing, though. But then I also applaud them for their daring design with Itanium, even though we all know how that has worked out for them.
My guess is that if these same benchmarks had been run on any Athlon vs. the equivalent P4 throughout history, the outcome would've been similar. But the results would also have been as irrelevant yesterday as they are today, since we all know the Xeon isn't 40% faster than the A64 in anything like real-world usage.
I hate the "all [other] things being equal" argument.
All things being equal, you would choose the DBMS whose executable takes less space on your hard disk.
All things being equal, you would choose the DBMS vendor that is located closest to you (in case they need to fly someone out).
All things being equal, you would choose the DBMS with the shorter name (less to type in at the command prompt).
All things being equal, you would choose the DBMS with the nicer looking logo.
I'm going to hazard a guess that you don't consider any of these when choosing a DBMS. In the same way, it is not unreasonable for someone to not consider the Java memory footprint penalty.
I'm obviously hyperbolizing, but, all things are usually not equal. The poster's point was that memory consumption is no longer a great reason not to use a Java-based database. Whether you agree with that is a matter of your particular set of needs and constraints, but the whole "Memory still costs a nonzero amount of money" argument is just annoying.
The tweakers.net article does also say that the AT and SR benchmarks do not give enough credit to their readership's ability to generate heavy I/O loads, via multitasking (I think an example was scanning your HD for viruses while starting a game). Maybe some people do that, but I for one found the examples they suggested pretty silly.
That said, plenty of people testify that RAID 0 feels faster, and I believe them. There's been similar backlash against SMP systems on the desktop for years, but back when the Pentium Pro was top dog I had a dual-PPro system that definitely felt faster than the equivalent single-PPro setup, though the benchmarks at the time couldn't explain it.
I wonder if the benchmarks they use today might be flawed because they only measure the total elapsed time of a relatively long script. For example, the Business Winstone script might take 5% less total time with Machine A than Machine B. That might not seem like a big improvement, but what if the 5% improvement was concentrated entirely in application launch times? I.e. the monster Excel spreadsheet still takes 120 seconds to do the filtering, pivot, recalc, solve operations, but startup time has been cut from 6 seconds to 2 seconds. The perceived improvement to the user would be much greater than 5%, and certainly much greater than if the 120-second operation had been reduced to 116 seconds.
It might be useful to have real-world benchmarks where the result of each run is not a scalar, but a vector (i.e. a set of waypoints and how long it took from each one to the next). Or do these already exist?
On the other hand, it's still a (relative) memory hog.
It doesn't have to be. In Java, for example, just always use PreparedStatement, which disambiguates queries and parameter values. There's an equivalent in .NET; not sure about other programming platforms.
From the article: Messages that fail the check will not be rejected, but will be further scrutinized and filtered
ASP.NET (and the Java equivalent, JavaServer Faces) have a much different, (arguably) more sophisticated approach to web development. There is actually a pretty good story for UI/logic separation, eventing, and maintaining state. You can have your HTML tags constituted into a mutable object graph before rendering (example).
The end result is a development style that lets one write web apps the same way one writes desktop GUI apps, and as a bonus you get far more compile time guarantees than before (even vis-a-vis compiled scripting languages like JSP). Whereas in most scripting languages, getting a dynamic <select> to default to the proper selection and remember its selection across page redraws takes an annoying kludge of code, it's trivial in ASP.NET.
You don't have to like the direction MS has taken with ASP.NET, but the fact that the author didn't even mention the fundamentally different programming model it offers vs. PHP says to me that he didn't bother doing much research into it.
I found SuSE 9.1 to be pretty much painless to get up and running, beautifully themed right out of the box, and extremely easy to keep up-to-date (with YaST/YOU), but the versions of software that are available on YaST are not always the latest ones. For example, as of this writing they're still on Firefox 0.8 and Thunderbird 0.5.
By the way, I had the same problem with the Windows defrag tool not actually working beyond a certain point. Supposedly, commercial defraggers like Diskeeper work much better.
SELECT MAX(price) FROM trades WHERE ticker = ?;
Very easy to believe culling that data from several different unindexed databases could take 36 seconds (especially on older hardware), and the latter only 30 millis.
That may be true, but not to the degree of a 1000X performance increase, which is what I think OP was protesting.
You do lose local variable names, but method parameter names and field names stay intact.
If you still (are forced to) use IE, an easier way to tap into QuickSearch these days is here.
IE <=6 users will be adversely affected, because in any situation where 8-bit alpha blending makes a difference, it will look terrible (not to mention extremely unprofessional) in IE. Like when some people take a .gif that was clearly antialiased for a black background, and slap it on a page with a white background. Do you really want 95%, 94%, 93% (and falling) of the browsing population to see your site like that?
From what I can tell, Bezos' statements can be summarized as "Don't hate the player, hate the game"--the same line that all the big players use--but it seems that AMZN in particular has gone far off the wrong end of the stupid-patent-o-meter way more than anyone else. (I have no actual data to back up this claim.)
I have heard that IBM alone files 10 patent applications a day. And yet it's Amazon that is the poster child for frivilous patents. I like to think a responsible tech industry giant like Amazon should be able to amass a defensive patent arsenal without stooping as low as they have.
Those who are going to commit espionage are going to do it with or without an iPod, and meanwhile you've seriously inconvenienced owners of MP3 players.
I agree that the value keyword is weird. I was pretty opposed to the whole properties thing (not as object oriented) but they turn out to be pretty nice in practice. For a counterexample, defining annotations in Java 1.5 is a lot weirder than attributes in C# (and I believe Java uses "value" as a magic member in this case).
C#'s synchronization utilities are actually much stronger than Java's. The lock statement is identical to Java's sychronized statement (you can't mark a method as locked, you have to put the lock in the method body). But if you want you can also handle the locking yourself by doing Monitor.Enter/Monitor.TryEnter and Monitor.Exit. So if you need to lock in a way that doesn't lend itself to lexical scopes, you're much better off in C# than in Java (where you'd basically have to write your own mutex on top of their synchronization primitives).
Java's Object.wait() and .notify() have Monitor.Wait() and Monitor.Pulse() as their equivalents in C#.
C# has a bunch of facilities (besides just "volatile") to allow you to do some sharing of state across threads without locking at all. Check out the Interlocked class, in the System.Threading namespace. There's also an explicit Thread.MemoryBarrier() operation. Last time I checked (1.4.x) there was no equivalent in Java, although the vast majority of C#/Java programmers should probably stay away from this stuff and stick to locking anyway.