perl runtime model

Discussion in 'Perl Misc' started by Peng Yu, Jan 18, 2010.

  1. Peng Yu

    Peng Yu Guest

    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?
     
    Peng Yu, Jan 18, 2010
    #1
    1. Advertising

  2. Peng Yu

    smallpond Guest

    On Jan 18, 10:01 am, Peng Yu <> wrote:
    > 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.
     
    smallpond, Jan 18, 2010
    #2
    1. Advertising

  3. On Mon, 18 Jan 2010 16:01:03 +0100, Peng Yu <> wrote:

    > 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.
     
    Jochen Lehmeier, Jan 18, 2010
    #3
  4. Peng Yu

    Peng Yu Guest

    On Jan 18, 1:03 pm, "Jochen Lehmeier" <>
    wrote:
    > On Mon, 18 Jan 2010 16:01:03 +0100, Peng Yu <> wrote:
    > > 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).


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

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

    >
    > 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?

    > Plus, just for your information, your question is pure flame bait - don't 
    > be irritated if you get heated answers.
     
    Peng Yu, Jan 18, 2010
    #4
  5. Peng Yu

    Peng Yu Guest

    On Jan 18, 9:55 am, smallpond <> wrote:
    > On Jan 18, 10:01 am, Peng Yu <> wrote:
    >
    > > 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?


    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.
     
    Peng Yu, Jan 18, 2010
    #5
  6. Peng Yu

    smallpond Guest

    On Jan 18, 4:03 pm, Peng Yu <> wrote:
    > On Jan 18, 9:55 am, smallpond <> wrote:
    >
    > > On Jan 18, 10:01 am, Peng Yu <> wrote:

    >
    > > > 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?

    >

    .... 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.
     
    smallpond, Jan 18, 2010
    #6
  7. Peng Yu

    Guest

    On Mon, 18 Jan 2010 13:03:12 -0800 (PST), Peng Yu <> wrote:

    >On Jan 18, 9:55 am, smallpond <> wrote:
    >> On Jan 18, 10:01 am, Peng Yu <> wrote:
    >>
    >> > 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?

    >
    >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.


    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
     
    , Jan 18, 2010
    #7
  8. Peng Yu

    sreservoir Guest

    On 1/18/2010 3:50 PM, Peng Yu wrote:
    > 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.

    --

    "Six by nine. Forty two."
    "That's it. That's all there is."
    "I always thought something was fundamentally wrong with the universe"
     
    sreservoir, Jan 18, 2010
    #8
  9. Peng Yu

    Peng Yu Guest

    On Jan 18, 3:57 pm, sreservoir <> wrote:
    > On 1/18/2010 3:50 PM, Peng Yu wrote:
    >
    > > 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.


    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?
     
    Peng Yu, Jan 18, 2010
    #9
  10. Peng Yu

    sreservoir Guest

    On 1/18/2010 5:12 PM, Peng Yu wrote:
    > On Jan 18, 3:57 pm, sreservoir<> wrote:
    >> On 1/18/2010 3:50 PM, Peng Yu wrote:
    >>
    >>> 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.

    >
    > 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.

    --

    "Six by nine. Forty two."
    "That's it. That's all there is."
    "I always thought something was fundamentally wrong with the universe"
     
    sreservoir, Jan 18, 2010
    #10
  11. Peng Yu <> wrote:
    >On Jan 18, 9:55 am, smallpond <> wrote:
    >> On Jan 18, 10:01 am, Peng Yu <> wrote:
    >>
    >> > 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?

    >
    >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.

    >> 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.


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

    jue
     
    Jürgen Exner, Jan 18, 2010
    #11
  12. Peng Yu

    sreservoir Guest

    On 1/18/2010 5:59 PM, Jürgen Exner wrote:
    > Peng Yu<> wrote:
    >> On Jan 18, 9:55 am, smallpond<> wrote:
    >>> On Jan 18, 10:01 am, Peng Yu<> wrote:
    >>>
    >>>> 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?

    >>
    >> 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.
    >
    >>> 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.

    >
    > 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.

    --

    "Six by nine. Forty two."
    "That's it. That's all there is."
    "I always thought something was fundamentally wrong with the universe"
     
    sreservoir, Jan 18, 2010
    #12
  13. On Mon, 18 Jan 2010 21:50:07 +0100, Peng Yu <> wrote:

    > '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, Jan 19, 2010
    #13
  14. On Tue, 19 Jan 2010 00:35:42 +0100, sreservoir <>
    wrote:

    >>> 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.


    > 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
     
    Jochen Lehmeier, Jan 19, 2010
    #14
  15. Peng Yu

    Peng Yu Guest

    On Jan 18, 6:00 pm, "Jochen Lehmeier" <>
    wrote:
    > On Mon, 18 Jan 2010 21:50:07 +0100, Peng Yu <> wrote:
    > > '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?


    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, Jan 19, 2010
    #15
  16. Peng Yu

    Peng Yu Guest

    On Jan 18, 6:12 pm, "Jochen Lehmeier" <>
    wrote:
    > On Tue, 19 Jan 2010 00:35:42 +0100, sreservoir <>  
    > wrote:
    >
    > >>> 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.

    > > 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. ;-)


    Your interpretation is wrong.
     
    Peng Yu, Jan 19, 2010
    #16
  17. Peng Yu

    sreservoir Guest

    On 1/18/2010 7:25 PM, Peng Yu wrote:
    > On Jan 18, 6:00 pm, "Jochen Lehmeier"<>
    > wrote:
    >> On Mon, 18 Jan 2010 21:50:07 +0100, Peng Yu<> wrote:
    >>> '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?

    >
    > 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

    --

    "Six by nine. Forty two."
    "That's it. That's all there is."
    "I always thought something was fundamentally wrong with the universe"
     
    sreservoir, Jan 19, 2010
    #17
  18. sreservoir <> wrote:
    >On 1/18/2010 5:59 PM, Jürgen Exner wrote:
    >> 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.


    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, Jan 19, 2010
    #18
  19. Peng Yu <> wrote:
    >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
     
    Jürgen Exner, Jan 19, 2010
    #19
  20. Peng Yu

    sreservoir Guest

    On 1/18/2010 8:47 PM, Jürgen Exner wrote:
    > sreservoir<> wrote:
    >> On 1/18/2010 5:59 PM, Jürgen Exner wrote:
    >>> 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.

    >
    > 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.

    --

    "Six by nine. Forty two."
    "That's it. That's all there is."
    "I always thought something was fundamentally wrong with the universe"
     
    sreservoir, Jan 19, 2010
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Hal Vaughan
    Replies:
    11
    Views:
    1,124
    Gordon Beaton
    May 22, 2006
  2. Replies:
    1
    Views:
    489
    Andreas Wollschlaeger
    Oct 6, 2006
  3. Soren

    Perl Memory Model

    Soren, Aug 25, 2005, in forum: Perl Misc
    Replies:
    1
    Views:
    191
  4. Ilias Lazaridis

    Model Centric Perl Web Framework

    Ilias Lazaridis, Oct 29, 2011, in forum: Perl Misc
    Replies:
    7
    Views:
    336
    Ilias Lazaridis
    Dec 4, 2011
  5. Rainer Weikusat

    Two remarks about the Perl object model

    Rainer Weikusat, Aug 22, 2012, in forum: Perl Misc
    Replies:
    0
    Views:
    406
    Rainer Weikusat
    Aug 22, 2012
Loading...

Share This Page