perl runtime model

[Peng Yu]

Could somebody let me know a reference on the runtime of a perl
script? I.e how a perl script run? What parts make a perl script be
slower than an equivalent, say, C programe?

 

[smallpond]

Could somebody let me know a reference on the runtime of a perl
script? I.e how a perl script run? What parts make a perl script be
slower than an equivalent, say, C programe?

What do you mean by equivalent?

Perl scalar variables have runtime type checking and conversion. A
"string" in C is just a pointer to memory with no checking, so of
course the code runs much faster.

If you wrote a C library that supported Perl scalar data types it's
not clear that C would be much faster. And C doesn't have hash
or array data types at all.

 

[Jochen Lehmeier]

Could somebody let me know a reference on the runtime of a perl
script? I.e how a perl script run?

If you are asking for the internal execution details, then you have to
read the source code (of perl, not your script). It's fun!

Everything else is explained to total exhaustion in "man perl" (also fun
to read through).

What parts make a perl script be slower than an equivalent, say, C
programe?

Google "interpreted vs compiled".

Plus, just for your information, your question is pure flame bait - don't
be irritated if you get heated answers.

 

[Peng Yu]

If you are asking for the internal execution details, then you have to  
read the source code (of perl, not your script). It's fun!

Everything else is explained to total exhaustion in "man perl" (also fun  
to read through).

'man perl' lists a lot of documents. Would you please be specific on
which one I should read?

Google "interpreted vs compiled".

I don't see a webpage specifically listing what language features in
perl may cause a perl script be slower than a C program doing the
same. Here, "same" means that given the same input the output is the
same. That is, I don't care what language features are used in a perl
script, as long as the perl script is fastest among all perl scripts
that can produce the same output from the same input.

Would you please point me a webpage?

 

[Peng Yu]

What do you mean by equivalent?

Two programs are "equivalent" if and only if given the same input, the
output is the same. That is, what are used in the two programs do not
matter.

Now, given the same input and the same output, theoretically, we can
have a fastest perl program and a fastest C program that are
equivalent. "fastest" is measured in terms of the runtime.

It is generally understand that this fastest perl program is slower
than this fastest C program in a lot of cases. I want to understand
why it is so and what features in perl cause perl be slow in these
cases.

Perl scalar variables have runtime type checking and conversion.  A
"string" in C is just a pointer to memory with no checking, so of
course the code runs much faster.

Are you sure it is only the runtime type check make perl slower.

If you wrote a C library that supported Perl scalar data types it's
not clear that C would be much faster.  And C doesn't have hash
or array data types at all.

I have no interest in blaming perl is slow. It is not relevant to my
OP to explain in what aspect perl is not slow.

 

[smallpond]

.... snip ...

I have no interest in blaming perl is slow. It is not relevant to my
OP to explain in what aspect perl is not slow.

In that case I don't understand your question.

 

[sln]

Two programs are "equivalent" if and only if given the same input, the
output is the same. That is, what are used in the two programs do not
matter.

Now, given the same input and the same output, theoretically, we can
have a fastest perl program and a fastest C program that are
equivalent. "fastest" is measured in terms of the runtime.

It is generally understand that this fastest perl program is slower
than this fastest C program in a lot of cases. I want to understand
why it is so and what features in perl cause perl be slow in these
cases.


Are you sure it is only the runtime type check make perl slower.


I have no interest in blaming perl is slow. It is not relevant to my
OP to explain in what aspect perl is not slow.

Assembly has operations that can do assignments, addition
substraction, bitwise shifts (multiplication/division), sets
flags, can take the contents of one variable and move it to
another variable. It has hardwired variables and access to
memory locations, which can be variables or hold data.
It has a few real stacks, push/pop etc, and pseudo stacks.

These can all be used to efficiently process data, move it
around, etc..

There is a language below assembly, called microcode. Each assembly
instruction executes several microcode instructions. Below microcode
are flip/flop gates and electron plasma. Below plasma there are quarks
and sub-atomic particles and the quantum physics realm.

This is the language tree up to assembly. Obviously, sub-atomic
particles react faster than assembly instructions. The reason is that
assembly requires organization of the particles into electron gates (cpu),
the gates facilitate microcode, which facilitate assembly.

More and more overhead is required for each level of organization (language)
up you go.

Finally, you reach a point of dynamic language called your desktop, it is
you dragging things around scheduling tasks and doing many things in your
multi-threaded world. You do everyday, dynamically program and run your
own world.

So you see that on the low level, while things are fast, not too much
can be done with limited organization. The more you want done, the more
dynamic an language is, the more organization it takes, the more time
it consumes as with any higher level complexities.

End of PhD thesis!!

-sln

 

[sreservoir]

I don't see a webpage specifically listing what language features in
perl may cause a perl script be slower than a C program doing the
same. Here, "same" means that given the same input the output is the
same. That is, I don't care what language features are used in a perl
script, as long as the perl script is fastest among all perl scripts
that can produce the same output from the same input.

the short version: everything not directly related to your problem.

perl does a lot of stuff not directly related to your problem whenever
you rune something. it handles memory, and scoping, and it takes a few
cycles at the beginning and end to compiled and clean up after itself.

your c program isn't doing this stuff. your c program can just ignore
everything irrelevant.

the real problem comes when you get input you're not expecting: in c,
you might get a segfault or you might get a silent buffer overflow. in
perl, you'll get a nice warning message that tells you what went wrong.

 

[Peng Yu]

the short version: everything not directly related to your problem.

perl does a lot of stuff not directly related to your problem whenever
you rune something. it handles memory, and scoping, and it takes a few
cycles at the beginning and end to compiled and clean up after itself.

your c program isn't doing this stuff. your c program can just ignore
everything irrelevant.

the real problem comes when you get input you're not expecting: in c,
you might get a segfault or you might get a silent buffer overflow. in
perl, you'll get a nice warning message that tells you what went wrong.

Your understanding of output is more limited than I meant. Warning
message is also considered as 'output' in my original message. Would
you please reconsider my question?

 

[sreservoir]

Your understanding of output is more limited than I meant. Warning
message is also considered as 'output' in my original message. Would
you please reconsider my question?

if it were to have the same input and the same output in every possibly
conceivable situation, it's not likely to be significantly faster.

and stderr is distnct from stdout, but that's not very relevant.

 

[Jürgen Exner]

Two programs are "equivalent" if and only if given the same input, the
output is the same. That is, what are used in the two programs do not
matter.

Now, given the same input and the same output, theoretically, we can
have a fastest perl program and a fastest C program that are
equivalent. "fastest" is measured in terms of the runtime.

It is generally understand that this fastest perl program is slower
than this fastest C program in a lot of cases. I want to understand
why it is so and what features in perl cause perl be slow in these
cases.

C is a low-level language, much closer to native assembler code.
Perl is a high-level language providing much more powerful features to
the programmer. Of course those features come at a price.

Are you sure it is only the runtime type check make perl slower.

No. The main difference is obviously that Perl is interpreted while C is
compiled.

jue

 

[sreservoir]

C is a low-level language, much closer to native assembler code.
Perl is a high-level language providing much more powerful features to
the programmer. Of course those features come at a price.


No. The main difference is obviously that Perl is interpreted while C is
compiled.

not quite. simplest scheme can be faster than simplest c simply because
the scheme interpreter is optimizing its lists and uses tail-calls for
recursion. but then, perl tries to be general-purpose, where scheme is
made for a specific mindset.

 

[Jochen Lehmeier]

'man perl' lists a lot of documents. Would you please be specific on
which one I should read?

Did you read my post? The question you are probably asking (the one you
elaborated on later in this thread) is not answered by those documents
directly; I mentioned "man perl" at that point because it was not clear
what you meant. You have to read the source code to find out what perl
does exactly when executing a script (some things are obvious, like
garbage collection, and interpretation instead of compilation, but I
assume you know all that already, don't you?).

Would you please point me a webpage?

Did you actually look into any of the pages the search I mentioned turned
up? Several mention reasons why compiled languages are faster than
interpreted ones. Since you mentioned some logical language, I assume that
you are aware of the distinction between interpreted and compiled
languages. Is it not obvious then what makes any interpreted language
slower than a compiled one?

 

[Jochen Lehmeier]

not quite. simplest scheme can be faster than simplest c simply because
the scheme interpreter is optimizing its lists and uses tail-calls for
recursion.

He's not asking about simplest, but about fastest. Since C is allowing to
program closer to machine code than almost any other language known to
man, I'd rather say it would be very hard to beat a dedicated C
programmer. (And heck, he could just program a scheme interpreter in C
which is even more optimized to the specific problem than the normal
optimizing scheme interpreter - problem solved).

But on the other hand, I believe the OP is just conducting a social
experiment in this group (unless he is trying to solve homework), so I'll
sit back and enjoy the show. ;-)

/em opens a big can of popcorn

 

[Peng Yu]

Did you read my post? The question you are probably asking (the one you  
elaborated on later in this thread) is not answered by those documents  
directly; I mentioned "man perl" at that point because it was not clear  
what you meant. You have to read the source code to find out what perl  
does exactly when executing a script (some things are obvious, like  
garbage collection, and interpretation instead of compilation, but I  
assume you know all that already, don't you?).


Did you actually look into any of the pages the search I mentioned turned 
up? Several mention reasons why compiled languages are faster than  
interpreted ones. Since you mentioned some logical language, I assume that  
you are aware of the distinction between interpreted and compiled  
languages. Is it not obvious then what makes any interpreted language  
slower than a compiled one?

I don't think that you understand what I meant. Those pages don't give
as much details. It is not obvious what makes any interpreted language
slower than a compiled one. I want to know exactly what make an
interpreted language slower. And if perl is slow because it is
interpreted, can a perl script be compiled to a machine executable
code so that it will be as fast as a C program?

 

[Peng Yu]

He's not asking about simplest, but about fastest. Since C is allowing to 
program closer to machine code than almost any other language known to  
man, I'd rather say it would be very hard to beat a dedicated C  
programmer. (And heck, he could just program a scheme interpreter in C  
which is even more optimized to the specific problem than the normal  
optimizing scheme interpreter - problem solved).

But on the other hand, I believe the OP is just conducting a social  
experiment in this group (unless he is trying to solve homework), so I'll 
sit back and enjoy the show. ;-)

Your interpretation is wrong.

 

[sreservoir]

I don't think that you understand what I meant. Those pages don't give
as much details. It is not obvious what makes any interpreted language
slower than a compiled one. I want to know exactly what make an
interpreted language slower. And if perl is slow because it is
interpreted, can a perl script be compiled to a machine executable
code so that it will be as fast as a C program?

http://lmgtfy.org/?q=why+interpreted+program+slower+than+compiled

 

[Jürgen Exner]

not quite. simplest scheme can be faster than simplest c simply because
the scheme interpreter is optimizing its lists and uses tail-calls for
recursion.

I don't buy that argument. You may be right with the program conversion,
you can do just the same in C, too, you just have to do it manually.

On the other hand launching an interpreter, parsing the source code,
creating some form of executable code and starting that code adds
overhead that you simply don't have with code that is already compiled,
linked, and assembled.

jue

 

[Jürgen Exner]

I don't think that you understand what I meant.

To be honest I don't either.

It is not obvious what makes any interpreted language
slower than a compiled one. I want to know exactly what make an
interpreted language slower.

That is a question for a compiler construction class.
In short: all of the analytical work (scanner, parser, context checker)
as well as some sort of code generation (this varies very widely because
of the many different styles of interpreters) that a compiler does
upfront must to be done by the interpreter at runtime and thus adds
significant overhead to interpreted program execution.

And if perl is slow because it is
interpreted,

Perl is not slow. For what it does it's pretty darn fast.

can a perl script be compiled to a machine executable
code

No, because Perl supports self-modifying programs, see "perldoc -f
eval".

so that it will be as fast as a C program?

Irrelevant, because the language has a feature that mandates
interpretation.

jue

 

[sreservoir]

I don't buy that argument. You may be right with the program conversion,
you can do just the same in C, too, you just have to do it manually.

in the case of 'most efficient program', I wouldn't buy that, either. I
didn't read that until later, though. it is also not as obvious as it
might seem to you.

On the other hand launching an interpreter, parsing the source code,
creating some form of executable code and starting that code adds
overhead that you simply don't have with code that is already compiled,
linked, and assembled.

lots of code is dynamically linked, but that's not a significant
difference.