I had someone else run it on a straight XP machine with the same
result. After some initial investigation, the cos/sin function in
cmath library seem to be the biggest usage of the time. Using a trig
table lookup instead, C++ outperforms the other two in the DFT
benchmark app. Still curious on why the quicksort is slower in VC++.
Is C++ slower at stack operations?
It could have something to do with memory management. Garbage collection
has a cost, but it's a very specific cost and happens at very specific
times. The flip side is that memory allocations are extremely fast, so
code that spends a relatively significant amount of time allocating new
buffers can do very well in .NET/C#. Does your quicksort implementation
use allocated buffers? Or just do everything in-place?
To know for sure why the speed different, you'd need a profiler of
course. There are any number of actual possible explanations.
Years ago, before I knew much about .NET and only shortly after .NET
actually _was_ anything (for some time, it was just a marketing term), I
had prejudices about .NET regarding it's potential for performance and
capabilities. Not only were those prejudices proved almost entirely false
as soon as I started doing any actual .NET programming, I continue to
every now and then hear about or see myself examples of things that .NET
actually does _better_.
Perhaps your tests are an example of that. Or perhaps it just means that
the code you've written is only optimal in one environment and there's a
better way to do it in some other environment. Without some detailed
analysis it would be very difficult to say for sure.
The most important thing here though, I think, is that these sorts of
benchmarks are probably not really all that meaningful anyway. It's
helpful to know some broad generalizations between environments I suppose,
but even if there was an environment that was 100% reliably
better-performing than some other environment, one could always write slow
code in the faster environment and better performing code in the slower
environment.
It is IMHO more useful to focus on picking an environment that suits the
overall needs of the applications best, and then worry about performance
issues as they come up. This doesn't mean one should write stupid code,
of course. There are some basic rules that are always helpful to follow.
But unless you're an optimization guru, it's not really even possible to
write useful comparison benchmarks for different environments. What works
best in one environment is not necessarily what will work best in another.
And even if you are an optimization guru, because in practically any
reasonable development environment it is possible to write applications
that perform well, it makes more sense to focus on the features of an
environment that help other aspects of the development process, like code
correctness, readability, built-in feature-rich support for a wide variety
of tasks, etc.
I wouldn't worry too much about apparent performance differences across
various platforms (and this is especially true if it happens that you
don't have a _lot_ of experience writing benchmarks and optimizing them
for the specific needs of each platform).
Pete
