Orton, Yves wrote:
>>Your patch needs to account for PERL_IMPLICIT_SYS too like
>>t/op/fork.t does, as Schwern just pointed out.
>>
>>
>
>Ok, ill look into that test to see how it works.
>
>
>
>>I should have mentioned that rather than just "ithreads" in my mail.
>>PERL_IMPLCIT_SYS is, in fact, also the reason that I don't build with
>>ActivePerl-style build options: enabling PERL_IMPLICIT_SYS
>>means that Perl's malloc cannot be used, so you get the system's
>>malloc() instead, which I've found several times to be absolutely crap on
>>
>>
>Win32.
>
>Ah ok, thanks. Ill check into that. So basically you are saying that unless
>you need fork you are probably better off using an unthreaded perl?
>
>
Not quite. I'm saying: "Unless you need fork you're probably better off
using a perl without PERL_IMPLICIT_SYS" [on Win32, obviously]. There's
no problem with having ithreads enabled; it's PERL_IMPLICIT_SYS that
requires perl's malloc to be disabled.
>
>
>>For example, running this program (20 large extensions to a string):
>>
>>my $a = '';
>>my $start = time;
>>for my $i (1 .. 20) {
>> print "$i\n";
>> $a .= '.' x 8000000;
>>}
>>printf "OK (%d seconds)\n", time - $start;
>>
>>takes 1 second on my 5.8.6 with Perl malloc() versus 7 seconds using
>>ActivePerl Build 810 (5.8.4).
>>
>>And this program (500,000 small extensions to a string):
>>
>>my $a = '';
>>my $start = time;
>>for my $i (1 .. 500000) {
>> print "$i\n" if $i % 1000 == 0;
>> $a .= '.' x 20;
>>}
>>printf "OK (%d seconds)\n", time - $start;
>>
>>is even worse: 1 second again on 5.8.6/perl-malloc versus 56
>>seconds on
>>5.8.4/system-malloc!
>>
>>
>
>Wow, ive been working on optimising some code recently that required very
>similar behaviour as these examples. Ill definately check out an unthreaded
>build. (Preallocating the full string and then substr()ing the snippets into
>place reduced the time massively)
>
>
Yes. I believe it is the system's realloc() which is especially crap.
I think it keeps moving the allocated space even when it doesn't need
to, hence does loads of unnecessary copying. Other system's realloc()'s
are probably better by not moving the allocated space unless they have to.
>
>
>>(I know that I'm not quite comparing apples with apples here,
>>but I have done so before using otherwise identically configured Perls
>>and it *is* the malloc() that makes the difference.)
>>
>>
>
>Thats really useful to know. Thank you.
>
>
>
>>I do mean to investigate using ithreads without PERL_IMPLICIT_SYS
>>sometime (Perl's malloc works fine in that configuration), but that
>>doesn't give you the fork() emulation ;)
>>
>>
>
>Threading with a faster malloc sounds very nice. Anything I can do to
>motivate you on this? Single-malt maybe? ;-)
>
As above, I think you've mis-understood me (or I didn't explain
clearly). You can already have threaded perl with faster malloc -- just
be sure to disable PERL_IMPLICIT_SYS. You keep the threads and perl's
malloc. You only lose the fork() emulation.
- Steve
------------------------------------------------
Radan Computational Ltd.
We would like to take this opportunity to wish all our customers, suppliers and
colleagues seasons greetings. We will not be sending corporate greetings
cards this year. Instead, we will be making a donation to charity.
The information contained in this message and any files transmitted with it are
confidential and intended for the addressee(s) only. If you have received this
message in error or there are any problems, please notify the sender
immediately. The unauthorized use, disclosure, copying or alteration of this
message is strictly forbidden. Note that any views or opinions presented in
this email are solely those of the author and do not necessarily represent
those of Radan Computational Ltd. The recipient(s) of this message should
check it and any attached files for viruses: Radan Computational will accept no
liability for any damage caused by any virus transmitted by this email.
