Memory manager problem? | Tech Off

PhrostByte

Hey guys, there seems to be something horribly wrong with the Windows memory manager.

See this source: http://dev.int64.org/memory.c
It runs in 8sec on winxp, and 0.013sec in linux. Even with my 1.5GiB of ram I thought maybe it wasn't able to expand the memory each time but I made it use a fixed 10MiB heap it and performs just as bad. Any gurus care to comment?

RomSteady
Kimono's rock...

Okay, token dumb questions...

1) Are you running the code as debug in Windows?

2) Which compiler and version are you using?

PhrostByte

good point.

under windows: it's compiled with full optimizations in non-managed mode using vs.net 2003. it happens with vs6 also.

under debian linux: gcc 3.4, full optimizations.

msemack
Embedded Systems Guy

There could be any number of things going on.

First you need to see if the code is taking a long time to execute by itself, or if something on the system is starving it.

Fire up PerfMon. Get some solid graphs of CPU and Memory usage. Make them detailed. Look at total RAM, FS cache, Commit Charge, and RAM Used by your Program. Look at total CPU time, and CPU time in your specific process.

Don't just look at Task Manager, it can miss sudden spikes and nosedives.

Find an equivalent program in Linux, and compare the same things.

Have you done anything stupid like changing your Windows memory management settings (changing the pagefile, registry tweaks, etc)?

Make sure your Windows and Linux configurations are as close as possible (same background RAM and CPU usage, no Anti-virus software, no server services or other background tasks, etc).

Also, where are you getting your time numbers? Are they from the output of the code? If yes, don't put too much faith in them. You'd be amazed how inaccurate system timekeeping can be (especially in Windows). Use a stopwatch.

Another interesting thing to do is look at the disassembly of the two programs. Besdies obvious differences in system calls and statically linked libs, look at how the core algorithim is compiled.

It might be fun to try with a non-Microsoft compiler (Intel, OpenWatcom, gcc, etc).

jonathanh
My mod color is red

"Horribly wrong" is overstating things, unless your program spends its entire time realloc'ing memory - which is almost NEVER a good idea. The Windows heap manager has historically been optimized for the common case (i.e. malloc and free), rather than the edge cases (realloc). Finding a benchmark that punishes the edge case of one implementation is no great news.

Having said all that, if you really want to get into this stuff you should also test the Low Fragmentation Heap on Windows XP and up.

PhrostByte

Case #1:
That sample prog I gave did nothing but call realloc in a loop 640 times, so it is definately in realloc. Havn't changed any memory settings, and it is on the same PC with nothing unneeded running in the background. The times are from the program, and I don't need it to be any more accurate as there is a massive noticable difference. I also compiled the same source with GCC in Windows (ala MinGW) and it ran even slower.

Case #2:
libxml2. This stemmed out of a recent convo in their mailing list where dumping large xml documents would take *much* longer on windows. After some investigation we found it was growing a buffer by 16KiB up to 10MiB. As soon as it was made to double the current size instead of increasing it by a 16KiB the speed skyrocketed to be the same as it was on Linux.

PhrostByte

I'm sorry but regardless of how often or not a function is used, realloc() going over 600 times slower on Windows *is* horribly wrong. There is no excuse for slow code.

Thanks for the link though, I'll try that on the heap code.

edit: didn't mean to come off as hostile there. inefficiency in code is a pet peeve - I bug friends about things they write if they could be even 5% faster Wink

AndyC

PhrostByte wrote:
I'm sorry but regardless of how often or not a function is used, realloc() going over 600 times slower on Windows *is* horribly wrong. There is no excuse for slow code.

I think you're missing the point. Windows memory management is optimised for the most common case, so by making realloc() 600 times slower they may well have made malloc() 5 times faster. Since malloc() is called considerably more often, the overall effect is a more efficient system.

Good optimisation is often a case of sacrificing the performance in extreme cases to benefit the more common scenarios.

lars

I got similar results. I compiled it and ran it just for fun:

XP / VS2K3 debug: 12s,
XP / VS2K3 full optimizations: 10s.
RH9 / GCC on MS Virtual PC: 0.010
Win98 / VS2K3 full opt / MS Virtual PC: 25+ (I said it was for fun, remember?)

It's interesting. But it's a benchmark of a single function call. What matters is real life application performance. When Apache or MySQL run 600 times faster on Linux I'll pay more attention. Still it's an interesting quirk to explore.

/Lars.

Manip

Shouldn't you be freeing up buf even if realloc fails? I mean in its current form you will get a memory leak.

juancri

The problem may be the compiler optimizations. You should compare the assembly generated code.