Re: Performance & Perl
- From: "Tassilo v. Parseval" <tassilo.von.parseval@xxxxxxxxxxxxxx>
- Date: Sun, 30 Oct 2005 08:23:53 +0100
Also sprach robic0@xxxxxxxxx:
> Or C?
>
> (Disclaimer: I have not delved into the Perl source)
>
> How close does Perl follow C as far as primatives?
Sometimes closely, but more often it doesn't follow C at all.
Some operators are implemented in terms of their C counterparts (most
notably all the bitwise operators).
The biggest differences are probably with arrays (that resize
dynamically) and strings. Perl strings are implemented on top of C
char-pointers and yet are infinitely smarter than C strings (e.g. they
transparently morph from one encoding into the other, ideally with the
programmer not even noticing it).
And there are of course hash-tables, something that C doesn't have at
all.
> Can I rely on Perl language constructs to follow C when
> writing performance code?
Some generic wisdom can probably be applied to writing both C and Perl
code. One such rule is to avoid the copying around of data although it's
sometimes not obvious what Perl code will result in a copy.
One difference for example is how C and Perl handle structures. One
common consideration with C is the order of struct-members that has an
impact both on memory consumption and performance due to memory
alignment issues:
struct A {
char a;
int32_t b;
char c[3];
}; /* 12 bytes on machines that align on 4-byte boundaries */
struct B {
char a;
char c[3];
int32_t b;
}; /* only 8 bytes */
In Perl, hashes are ordinarily used for modelling structs. They have
very different characteristics. One is that access to the members is
resolved at runtime whereas the members of a C structure have a fixed
memory offset from the base address which the compiler knows about.
On the other hand, certain C constructs might end up being faster in
Perl. Perl's index() is likely to be faster than C's strstr() as it uses
Boyer-Moore on the inside and attaches these information to the
variable.
Likewise length() versus strlen(): Perl's length() happens in constant
time as the length of each string is stored in the underlying
data-structure. C on the other hand has to loop over each character to
find the terminating '\0'.
Another thing to keep in mind is that function calls in Perl are slow.
In C they are also slower than inlined code, but with Perl the penalty
is by an order of a few magnitudes more severe. It's even worse with
method calls as the resolution of every method happens at runtime
(although perl does cache the information). In C++ method dispatch can
often by figured out at compile-time unless it's dynamic dispatch. Perl
only has dynamic dispatch.
I believe the best way to improve the performance of Perl programs is by
using the Benchmark module to find out which of the conceivable versions
performs better.
> In a runtime race will a Perl for loop time exactly the same as a
> C for loop? When the race begins, if not, why not?
The C loop wins. But then the Perl for-loop is more than just a loop:
It's a generic iterator construct that iterates over any list-alike
thing.
> Any divergence in stack processing Perl to C?
Perl only uses the stack for passing arguments to and from functions and
methods. Unlike in C, it has a variadic size. That's why Perl functions
don't need a prototype. And if they have a prototype, it's for an
entirely different purpose.
> Is there such a thing as a Perl "temporary" on the stack?
Perl knows about temporaries but they are not created on the stack but
instead on a separate thing called a scratchpad of which each block gets
its own. These temporaries aren't blindly destroyed when the block is
left. Instead, their reference-count is decremented. In the below
$temporary isn't freed because set_tmp() and get_tmp() still reference
it in their bodies. That means Perl has real closures:
{
my $temporary;
sub set_tmp { $temporary = shift; }
sub get_tmp { return $temporary; }
}
set_tmp 42;
print get_tmp;
> Why would I need to care about any of this on a "higher level"
> language, or is Perl a higher level language?
Perl is a higher level language because you never have to worry about
any of those menial tasks that a C programmer constantly needs to be
aware of. That comes at a price so a Perl program can easily be 50 times
slower than a well-written C equivalent.
But there are ways to couple the convenience of Perl with the
performance of C. Many modules on the CPAN were written in C or C++ (or
rather in a dialect called XS which facilitates the passing of data from
Perl to C and vice versa). There is also Inline::C.
Toying around with any of these is an excellent and fun way to learn
about the inner workings of Perl because you'll inevitably learn how the
Perl stack works, how Perl's reference-counting is used to do
garbage-collection, how Perl's primitive data-types work and so on and
so forth.
Tassilo
--
use bigint;
$n=71423350343770280161397026330337371139054411854220053437565440;
$m=-8,;;$_=$n&(0xff)<<$m,,$_>>=$m,,print+chr,,while(($m+=8)<=200);
.
- Follow-Ups:
- Re: Performance & Perl
- From: robic0
- Re: Performance & Perl
- Prev by Date: FAQ 8.49 How do I add a directory to my include path (@INC) at runtime?
- Next by Date: Re: Perl site - Elementary question
- Previous by thread: Re: Performance & Perl
- Next by thread: Re: Performance & Perl
- Index(es):
Relevant Pages
|
