Re^7: Why is Windows 100 times slower than Linux when growing a large scalar?

Yes, I got the same results (using MSVC).

Now I'm trying to understand what USE_IMP_SYS really means, and why it is incompatible with USE_PERL_MALLOC.

Perhaps the most interesting discovery is cdarke's post about ActiveState being "compiled in debug"--whatever that means?

That said, my tests of the CRTs realloc() were built in /release mode on MSVC and whatever is teh default on MinGW, and both exhibited the abysmall (N³) performance slowdown as the number of increments rose. Which maybe suggests that's a red-herring?

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

RIP PCW It is as I've been saying!(Audio until 20090817)

Comment on Re^7: Why is Windows 100 times slower than Linux when growing a large scalar?

Replies are listed 'Best First'.
Re^8: Why is Windows 100 times slower than Linux when growing a large scalar? by cdarke (Prior) on Dec 02, 2009 at 12:59 UTC
Compiled in debug might be a red-herring, but it can have an big effect on performance. On Visual Studio there is a supplied configuration called Debug; configurations are a way of grouping different compilation options, although they can be used for other things. Using Debug, the symbol table will be attached to the code for debugging, as you would expect, but it has other effects: it disables all optimization and uses a different heap management system. So far as I am aware the -g option on gcc does not have those side-effects (stepping through optimised code in a debugger can be weird).	[reply]
Re^9: Why is Windows 100 times slower than Linux when growing a large scalar? by BrowserUk (Patriarch) on Dec 02, 2009 at 14:02 UTC
ActiveState 5.10.1 has a Perl510.dll ... I noticed that the code is all compiled in Debug Okay. I'm more used to the phrase "compiled with debug", rather than "compiled in debug". A small difference, but enough to cause me to question what you meant. The other question I have is what evidence do you have for believing AS perl is compiled with debug? When I use -V on a freshly downloaded 32-bit AS perl 5.10.1 install, I get this output: <Reveal this spoiler or all in this thread> The significant portion of which is `cc='cl', ccflags =... -DNDEBUG -O1 -DWIN32`? In the source code they just call the CRT malloc/calloc/realloc, they don't do any magic with Win32 Heap APIs. It is the CRT itself that uses the Heap apis...not Perl. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. RIP PCW It is as I've been saying!(Audio until 20090817)	[reply] [d/l] [select]
Re^10: Why is Windows 100 times slower than Linux when growing a large scalar? by ikegami (Patriarch) on Dec 02, 2009 at 16:41 UTC
Additionally, it uses /MD: link with MSVCRT.LIB (as opposed to /MDd, link with MSVCRTD.LIB debug lib) /O1: minimize space (as opposed to the default /Od, disable optimizations) /GF: enable read-only string pooling That doesn't smell like debug. It does include the symbol table (/Zi: enable debugging information), but that shouldn't affect performance.	[reply]