In article <bde0e3$rs02u$1@ID-37212.news.dfncis.de>,
tonreG.Frisch@Dream-D-Sign.de says...
The difference in floating point speed, is probably due to a difference
in the compilers -- I'd guess you're using gcc under Linux and MS VC++
under Windows. The basic difference is NOT one of compiler optimization
(there's not much here to optimize) but in the way the compiler sets up
the FPU -- MS sets it for 64-bit precision, while gcc most likely leaves
it at its default 80-bit precision.
There is at least one obvious difference between the way your testing
file read/write speed under the two: under Windows opening with "r" or
"w" means you're opening the file in translated mode -- a C new-line
gets converted to a CR/LF pair on writing, and a CR/LF pair gets
converted to a new-line during reading. Under Linux, there really is no
translated mode. It's open to question whether this accounts for the
entire difference you're seeing or not -- MS seems to have optimized
their file cache for lots of small reads and writes, where Linux seems
(at least to me) to work better when you're doing a few large
transactions, such as you use in this test.
In this kind of situation, Windows generally does better if bypass the
file cache. Unfortunately, you can't (at least AFAIK) do that with the
standard library function though -- you have to open the file with
CreateFile, passing it FILE_FLAG_NO_BUFFERING. As such, you may or may
not care about it at all -- but if you can use it, Windows seems to do
disk transfers right at the limits of the hardware.
Memory allocation is one of the hardest things around to measure well,
and I'm afraid I don't think your test is really accomplishing much
here. There are a number of problems: first of all, you're not using
any of the memory you allocate, which allows a tricky optimization: they
may not really allocate the memory at all, but instead just allocate
some address space, and delay allocating memory to back it until you use
it. If one compiler does this and the other doesn't, you'll get a huge
apparent difference in speed (though I can only even guess at the
compilers you're using, so it's impossible to say whether that applies
here). Another point is that you never do a random mixture of
allocation and freeing. Again, a particular allocator can optimize this
situation, but still work quite poorly under more typical conditions.
In the end, I don't know of anybody who's written an allocator that's
very close to optimum under all possible conditions. Given the infinite
variety of conditions under with a compiler's allocator gets used, the
author is usually more interested in preventing outright disaster than
in making sure it's optimal for one particular situation. In the end,
almost any allocator that does really well under one set of conditions
will do extremely poorly under another. If an allocator goes to the
extra work to keep from doing badly in bad situations, that extra work
will also prevent it from doing extremely well under simple ones.
This is one of the reasons C++ allows you to overload operator new (and
delete) on a class-specific basis -- if you know something about how
memory will be used in a particular situation, you can almost always do
substantially better than a general-purpose allocator like the one in
the standard library.
--
Later,
Jerry.
The universe is a figment of its own imagination.
