in reply to Re^3: 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?

Is the Perl inside the virtual box also threaded?

Obviously, that makes no sense. I sleep now.

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

Replies are listed 'Best First'.
Re^5: Why is Windows 100 times slower than Linux when growing a large scalar?
by BrowserUk (Patriarch) on Dec 01, 2009 at 08:32 UTC

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

In Section Seekers of Perl Wisdom