Google might not only measure links to pages, but also counts users which use a link to a page. If Yahoo feeds in link hits from Yahoo directory users, than Yahoo sites will go up in the google rankings.
From a business perspective Yahoo has every power to demand from their search machine provider, to rank their pages high. Advertising is Yahoo's main income stream. Feeding in link hits could be a way to do it in a more soft way. It could explain the slow change of rankings, if the data given isn't wrong.
AFAIK are CD's are not able to store informations for such a long time. By now even 30 years might be a problem. Certain conditions like constant low temperature are required.
Benchmarks are HOTSPOT-friendly. The same functions are called again and again.
The Life game is the only test which requires the garbage collector a little bit, but here C looks not so bad.
The Fibonacci test is not so important, it proves only that HOTSPOT and the IBM JVM do function calls faster on Athlon. It seems that both C compilers don't do good opimizations here for Athlon. Pipeline stalls might be the cause.
The FFT C code uses calloc() to create the FFT matrixes. malloc() would be sufficient. For arrays with 2^16 doubles the clearing of half a megabyte needs some time. A for-loop is used for copying data and not memcpy(). The Java code uses System.arraycopy():-).
The result is predictable.
Running current C compilers on an Athlon is also not fair, because both compilers will not produce good code for it. The Visual C++ didn't even had the Pentium specific flags.
I think that the compiler-based JVMs have gone a long way. I wish some of that developement resources had gone into the C++ compilers of both companies.
My conclusion: The Java performance penalty is reducing on some platforms. Linux on x86 is one of them, thank IBM. I doubt, that we will see a free JVM with that performance anytime soon.
Microsoft wouldn't have started this, if the result wouldn't have been predictable.
I could write here a long list, why these simple brute performance tests are not appropriate to compare operating systems. We know now that Windows NT serves the Windows native network file system better on higly optimized machines and a NT machine can flood your network with twice the amount of static web pages than Linux.
Microsoft defined with these tests the battle ground. Next time we should know the territory before going into the battle.
Slashdot Mirror
How about this?
Google might not only measure links to pages, but also counts users which use a link to a page. If Yahoo feeds in link hits from Yahoo directory users, than Yahoo sites will go up in the google rankings.
From a business perspective Yahoo has every power to demand from their search machine provider, to rank their pages high. Advertising is Yahoo's main income stream. Feeding in link hits could be a way to do it in a more soft way. It could explain the slow change of rankings, if the data given isn't wrong.
AFAIK are CD's are not able to store informations for such a long time. By now even 30 years might be a problem. Certain conditions like constant low temperature are required.
Benchmarks are HOTSPOT-friendly. The same functions are called again and again.
:-).
The Life game is the only test which requires the garbage collector a little bit, but here C looks not so bad.
The Fibonacci test is not so important, it proves only that HOTSPOT and the IBM JVM do function calls faster on Athlon. It seems that both C compilers don't do good opimizations here for Athlon. Pipeline stalls might be the cause.
The FFT C code uses calloc() to create the FFT matrixes. malloc() would be sufficient. For arrays with 2^16 doubles the clearing of half a megabyte needs some time. A for-loop is used for copying data and not memcpy(). The Java code uses System.arraycopy()
The result is predictable.
Running current C compilers on an Athlon is also not fair, because both compilers will not produce good code for it. The Visual C++ didn't even had the Pentium specific flags.
I think that the compiler-based JVMs have gone a long way. I wish some of that developement resources had gone into the C++ compilers of both companies.
My conclusion: The Java performance penalty is reducing on some platforms. Linux on x86 is one of them, thank IBM. I doubt, that we will see a free JVM with that performance anytime soon.
Microsoft wouldn't have started this, if the result wouldn't have been predictable.
I could write here a long list, why these simple brute performance tests are not appropriate to compare operating systems. We know now that Windows NT serves the Windows native network file system better on higly optimized machines and a
NT machine can flood your network with twice the amount of static web pages than Linux.
Microsoft defined with these tests the battle ground. Next time we should know the territory before going into the battle.