in reply to Re^4: Why is Windows 100 times slower than Linux when growing a large scalar?
in thread Why is Windows 100 times slower than Linux when growing a large scalar?

Yes, it is a threaded perl under linux and threads work there fine.

A perhaps more interesting question is if perl is built on win without USE_IMP_SYS so that USE_PERL_MALLOC can be enabled, does that stop you from using threads? Or just fork?

Whilst I would miss the piped open, which i believe requires the fork emulation, I could work around it using threads. And I would infinitely prefer threads + faster memory, to the fork emulation.

Does anyone know the answer or should I just suck it and see?

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^5: Why is Windows 100 times slower than Linux when growing a large scalar?

Replies are listed 'Best First'.
Re^6: Why is Windows 100 times slower than Linux when growing a large scalar?
by syphilis (Archbishop) on Dec 01, 2009 at 12:52 UTC
    does that stop you from using threads? Or just fork?

    On a second reading, it seems that you might only miss out on fork emulation. One *can* build perl with PERL_MALLOC, USE_MULTI and USE_ITHREADS, but without USE_IMP_SYS (and I've now just done that) ... which, according to the comments in the makefile.mk/Makefile, would mean that you miss out on fork emulation, but not threading ... and that's exactly what I'm finding: 
    C:\_32\comp\perl-5.11.2>perl -Mthreads -e "print \"ok\""
ok
C:\_32\comp\perl-5.11.2>perl -e "fork()"
The fork function is unimplemented at -e line 1.

    [download]
    (And I still get good results regarding the concatenation operator.)

    Existing ppm packages for extensions would, according to the comments in the makefile.mk/Makefile, be unusable on such a perl.

    Cheers,
    Rob
[reply]
[d/l]

      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 (N3) 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.
[reply]
        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]

In Section Seekers of Perl Wisdom