Prev: (lack of) Helpfulness of Perl error messages.
Next: libwww-perl authorization problem
From: bugbear on 18 Feb 2010 11:25
No, I'm not starting yet another perl vs C thread.

I have some concerns about the performance
of perl varying more than I would expect
between different installations I'm maintaining
(and running my perl code on)

Is there a standard benchmark, used (perhaps)
when people port Perl to different CPUs/OS/compilers?

I tried to search, but google gave me loads
of perl VS Python (etc...) pages/flamewars.

BugBear
From: Ben Morrow on 18 Feb 2010 16:40

Quoth bugbear <bugbear(a)trim_papermule.co.uk_trim>:
> No, I'm not starting yet another perl vs C thread.
>
> I have some concerns about the performance
> of perl varying more than I would expect
> between different installations I'm maintaining
> (and running my perl code on)

Are these different versions of perl? There are often large differences
in performance between major version, in both directions (depending on
what exactly you're doing).

> Is there a standard benchmark, used (perhaps)
> when people port Perl to different CPUs/OS/compilers?

There is perlbench on CPAN, but I believe it's not considered to be as
representative as it used to be.

Running the core test suite, or the test suite of any large CPAN
distribution that does the sort of work you are interested in, is often
good enough.

Ben

From: sln on 18 Feb 2010 21:06
On Thu, 18 Feb 2010 16:25:33 +0000, bugbear <bugbear(a)trim_papermule.co.uk_trim> wrote:

>No, I'm not starting yet another perl vs C thread.
>
>I have some concerns about the performance
>of perl varying more than I would expect
>between different installations I'm maintaining
>(and running my perl code on)
>
I don't know but I just found out that the percentage
of time involved with the 'Growing' (only) of scalars
on a Windows box is from 35 to 100 times more than
on a *nix box. This is due to win32 realloc in the
linked crt library (and this is due to calling heap
primatives), not to Perl itself.

Though pre-allocating buffers will solve the problem
as it calls malloc once and avoids realloc() flavors,
but this is not dynamic.

I'd say this is a big deal, depending on your code.

http://www.perlmonks.org/?node_id=810276

-sln
From: Phred Phungus on 19 Feb 2010 00:25
sln(a)netherlands.com wrote:
> On Thu, 18 Feb 2010 16:25:33 +0000, bugbear <bugbear(a)trim_papermule.co.uk_trim> wrote:
>
>> No, I'm not starting yet another perl vs C thread.
>>
>> I have some concerns about the performance
>> of perl varying more than I would expect
>> between different installations I'm maintaining
>> (and running my perl code on)
>>
> I don't know but I just found out that the percentage
> of time involved with the 'Growing' (only) of scalars
> on a Windows box is from 35 to 100 times more than
> on a *nix box. This is due to win32 realloc in the
> linked crt library (and this is due to calling heap
> primatives), not to Perl itself.
>
> Though pre-allocating buffers will solve the problem
> as it calls malloc once and avoids realloc() flavors,
> but this is not dynamic.
>
> I'd say this is a big deal, depending on your code.
>
> http://www.perlmonks.org/?node_id=810276
>
> -sln

And then there's the time for coding as opposed to the time for execution.

I've been working up the same material with differing syntaxes for the
*nix platform, and the perl version may have taken me 48 hours.

I'm getting closer to a C solution, because I'm hauling Heathfield's DL
list library with me this time, but it's been a month at least.

I'm a person who would gladly leave this task to the implementation.
--
fred
From: bugbear on 19 Feb 2010 04:21
Ben Morrow wrote:
> Quoth bugbear <bugbear(a)trim_papermule.co.uk_trim>:
>> No, I'm not starting yet another perl vs C thread.
>>
>> I have some concerns about the performance
>> of perl varying more than I would expect
>> between different installations I'm maintaining
>> (and running my perl code on)
>
> Are these different versions of perl? There are often large differences
> in performance between major version, in both directions (depending on
> what exactly you're doing).
>
>> Is there a standard benchmark, used (perhaps)
>> when people port Perl to different CPUs/OS/compilers?
>
> There is perlbench on CPAN, but I believe it's not considered to be as
> representative as it used to be.

I downloaded this (shortly after my first post).
I must be missing something - it only runs 8 tests, none
of which look very "general";
perl-5.10.0 (DEBUGGING)
@bugbear-dell
app/podhtml 674.190 ms �-11.429
startup/noprog 2.484 ms �-2.098
statement/func-call-empty-5arg 1.058 �s �-0.020
statement/func-call-empty-2arg 670.138 ns �-20.012
statement/func-call-empty-1arg 397.798 ns �-7.001
statement/func-call-empty-0arg 215.374 ns �-2.893
statement/assign-int 68.174 ns �-1.229
statement/inc 46.290 ns �-1.217

is there a separate Module of tests, with perlbench being
just a harness?

(the funny character appears to be a further perlbench bug).

> Running the core test suite, or the test suite of any large CPAN
> distribution that does the sort of work you are interested in, is often
> good enough.

Interesting suggestion - can you recommend a "Generic" package
with a good test suite?

I really am concerned with Perl itself at the moment - literally
stuff like regexp evaluation, code parse time, has lookup, integer
arithmetic, real "nuts and bolts".

BugBear
 |  Next  |  Last
Pages: 1 2
Prev: (lack of) Helpfulness of Perl error messages.
Next: libwww-perl authorization problem