Re: why the perl docs suck

Also sprach robic0@xxxxxxxxx:
> On Wed, 26 Oct 2005 07:40:12 +0200, "Tassilo v. Parseval"
><tassilo.von.parseval@xxxxxxxxxxxxxx> wrote:
> I'm not trying to be rude or insult you or any of that.

OK, sorry then.

> It appears the Perl source code is written in Perl(eze), and compiled,
> somewhere, that maps to a standard C api, that sits on top of a OS
> implemented C library.

I am not sure I fully understand that. It stands to reason that perl
makes use of the standard C API. This, in fact, can be taken literally
as perl has been written so it can be compiled on any C89-conforming C
compiler. This is crucial as perl is supposed to run and compile on more
than just a handful platforms.

> I'm pretty sure the standard C adresses re-allocation vs
> allocation-copy-free sitting on top of block memory fragmented
> allocation as a computation left to designers of the software that
> uses its api.

Correct in so far as the standard says nothing about which should be
used under what circumstances. It's even possible that reallocation
never happens under certain OS even when explictely requested by using
realloc. The internal implementation is free to allocate a fresh block
and copy everything over and free the old block. That's why realloc()
has a return-value that must not be discarded.

> Most probably, that api is never penetrated in
> regard to memory when application writers use the C
> api, but I can assure you optimizations are done.

Optimizations at what level? At the application level using the standard
libc infrastructure?

> You can't just look at the Perl/perl "source" and
> add up machine cycles, as what it "may" mean in
> assembly for looping. In Perl there is no fixed
> size (it appears) for elements in a list/array.

There is. Each element's size is the size of a pointer on the given
machine. What they point to naturally varies in size. They point to C
structures whose size depends on what is stored inside. This can be
easily analyzed by using Devel::Peek or so:

ethan@ethan:~$ perl -MDevel::Peek -e 'Dump(1); Dump("1")'
SV = IV(0x8163388) at 0x814cc6c
REFCNT = 1
FLAGS = (PADBUSY,PADTMP,IOK,READONLY,pIOK)
IV = 1
SV = PV(0x814ceb4) at 0x8160cb8
REFCNT = 1
FLAGS = (PADBUSY,PADTMP,POK,READONLY,pPOK)
PV = 0x8150778 "1"\0
CUR = 1
LEN = 2

>From the above it becomes obvious that a scalar holding a string is
bigger than a scalar holding a plain integer. Also, these scalar types
grow as needed:

ethan@ethan:~$ perl -MDevel::Peek -e 'my $v = 1; Dump($v); $v .= ""; Dump($v)'
SV = IV(0x81633a4) at 0x814cc6c
REFCNT = 1
FLAGS = (PADBUSY,PADMY,IOK,pIOK)
IV = 1
SV = PVIV(0x814d2a0) at 0x814cc6c
REFCNT = 1
FLAGS = (PADBUSY,PADMY,POK,pPOK)
IV = 1
PV = 0x815d628 "1"\0
CUR = 1
LEN = 2

The addresses in brackets shows that the block of memory where the
plain-integer-$v resided has been freshly allocated to accomodate for
the three new slots PV (a char pointer), CUR (the length of the string)
and LEN (the number of bytes allocated). The previous values of REFCNT,
FLAGS and IV have been copied (and in case of FLAGS changed
accordingly).

This process is called upgrading and there is the function
Perl_sv_upgrade() that tries to upgrade a given SV to a more complex
form, by allocating a new body (on the top level an SV is only a small
structure containing a pointer to a body where the real data-structure
needed for that type of value is stored).

The fact that an upgrade results in a fresh allocation instead of an
attempted resize has been mused over often enough in the past by the
perl-porters and it's general consensus that trying to resize using a
realloc-alike would be better. Perl internally uses C's structural
equivalence to emulate something similar to inheritance and that means a
reallocation is technically possible and would avoid some amount of
copying.

> It may be that strings are converted internally
> to pointers as with scalars to be the machine word.

Strings are pointers by the time the lexer is done with its analysis of
the source of a Perl program. Perl almost exclusively uses heap-memory,
either through the system's malloc or its own memory allocator that
requests huge blocks (called "areas") from the system using sbrk(),
whichever is more beneficial for a given machine. This decision is made
at Configure-time or by explicitely asking for one of the two methods by
setting the 'usemymalloc' configuration variable before compilation.

Only simple scalar types such as integers and floating point numbers are
mapped directly to the respective C types.

> Stored seperately, thats a language management
> intermediate step. But that complicates memory
> management because its not the element then,
> its the size of the element that has to be "pushed".
> When to you its a single element but the real data
> that has to be manipulated varies in size.

I can hardly guess what you intend to say with this paragraph. Pushed
onto what? What elements and what size of elements were you referring
to?

> Thats the problem. If this dosen't make a connection
> with you at all (ie: none of it) then

It might make a connection with me if you didn't remain so vague and
abstract. When talking about the various subtleties of memory management
in C it really helps if you talked C instead of employing cloudy
English periphrases.

Tassilo
--
use bigint;
$n=71423350343770280161397026330337371139054411854220053437565440;
$m=-8,;;$_=$n&(0xff)<<$m,,$_>>=$m,,print+chr,,while(($m+=8)<=200);
.

Relevant Pages

  • Re: memory allocation in perl
    ... There is no explicit memory ... >> allocation in perl (well, actually, you can treat a string as a chunk ... > I want to whether we have some sort of allocation method as we have in C ... In perl there are only two basic ways to allocate variables. ...
    (perl.beginners)
  • Re: why the perl docs suck
    ... It stands to reason that perl ... >> allocation as a computation left to designers of the software that ... >The addresses in brackets shows that the block of memory where the ... >> to pointers as with scalars to be the machine word. ...
    (comp.lang.perl.misc)
  • Re: Perl garbage collector
    ... Does your OS have a function that allows processes to return memory to ... As you see some RAM is given back to the OS ... I would expect that the Perl virtual machine ... memory allocation and garbage collection. ...
    (perl.beginners)
  • Re: memory allocation in perl
    ... There is no explicit memory ... > allocation in perl (well, actually, you can treat a string as a chunk ... I want to whether we have some sort of allocation method as we have in C ... As far as my knowledge in perl is concerned it ...
    (perl.beginners)
  • Questions about Inline::C
    ... > new Perl string scalar. ... is there is any danger with malloc() from within Inline::C ... I much prefer to do the allocation myself, ... that I fear that using perl guts for my calculations (accessing the ...
    (comp.lang.perl.misc)