[26645] in Perl-Users-Digest
Perl-Users Digest, Issue: 8752 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Dec 10 21:06:33 2005
Date: Sat, 10 Dec 2005 18:05:04 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sat, 10 Dec 2005 Volume: 10 Number: 8752
Today's topics:
Re: Can device drivers be written in Perl? <nobody@bigpond.com>
Re: threads <tassilo.von.parseval@rwth-aachen.de>
Re: threads xhoster@gmail.com
Re: threads <ves@ves.net>
Re: Win32 thread vs fork xhoster@gmail.com
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 10 Dec 2005 14:49:35 GMT
From: Gregory Toomey <nobody@bigpond.com>
Subject: Re: Can device drivers be written in Perl?
Message-Id: <439aeafe@news.comindico.com.au>
robic0 wrote:
> ???????
No. You have obviously never written a device driver.
gtoomey
------------------------------
Date: Sat, 10 Dec 2005 12:40:18 +0100
From: "Tassilo v. Parseval" <tassilo.von.parseval@rwth-aachen.de>
Subject: Re: threads
Message-Id: <3vvt55F17u5s4U1@news.dfncis.de>
Also sprach robic0:
> On Sat, 10 Dec 2005 06:56:57 GMT, Vespasian <ves@ves.net> wrote:
>
>>The CPAN documentation on perl threads state the overhead of creating
>>a thread is rather large. Anyone know why or could point me to a
>>website that explains the reason.
>>
>>TIA,
>>ves
> Less than a process. I can only imagine the win32 api on that
> platform. Its all about state and context, as the threads
> switch, the manager has to save the execution state of the
> leaving thread, then install the newly running thread state.
[...]
This has absolutely nothing to do with the OP's question of why Perl
threads have such a high overhead on creation (as opposed to threads in
other environments).
The actual reason is the fact that Perl threads are interpreter threads,
meaning that a whole Perl interpreter has to be cloned. The C structure
backing up an instance of one interpreter is already very big: It has
over a hundred members. But that is not all. Each and every variable
created thus far has to be duplicated as well.
And there is some remarkable book-keeping involved, so it's not only a
matter of doing the equivalent of a few memcpies.
Incidentally, this message cropped up on the perl5-porters list this
morning:
ithreads clone time is crap. However, if anyone is interested and
motivated, read on for how we might improve it.
The ithreads cloning is done by copying everything in the old thread
to the new thread. The clone code keeps track of what it's already
cloned by using a custom hash table to map the pointer in the old
thread to the pointer in the new thread. This is all the ptr_table_*
code.
The hash is structured like the regular perl hash code - an array of
linked lists, with a hash function used to map the pointer into an
index in that array. The current hash function is:
#if (PTRSIZE == 8)
# define PTR_TABLE_HASH(ptr) (PTR2UV(ptr) >> 3)
#else
# define PTR_TABLE_HASH(ptr) (PTR2UV(ptr) >> 2)
#endif
The idea of the hash function is to spread the possible input values
evenly around. It seems that this hash function is pretty lousy.
[...]
Tassilo
--
use bigint;
$n=71423350343770280161397026330337371139054411854220053437565440;
$m=-8,;;$_=$n&(0xff)<<$m,,$_>>=$m,,print+chr,,while(($m+=8)<=200);
------------------------------
Date: 10 Dec 2005 20:25:39 GMT
From: xhoster@gmail.com
Subject: Re: threads
Message-Id: <20051210152539.738$gB@newsreader.com>
Vespasian <ves@ves.net> wrote:
> The CPAN documentation on perl threads state the overhead of creating
> a thread is rather large. Anyone know why or could point me to a
> website that explains the reason.
Because it copies the interpreter itself and all the data.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: Sat, 10 Dec 2005 22:17:03 GMT
From: Vespasian <ves@ves.net>
Subject: Re: threads
Message-Id: <oukmp19d0dvnfmj3gore6e2hvu19hprq3a@4ax.com>
Thanx, Tassilo -- that's the answer I was looking for
ves
On Sat, 10 Dec 2005 12:40:18 +0100, "Tassilo v. Parseval"
<tassilo.von.parseval@rwth-aachen.de> wrote:
>Also sprach robic0:
>> On Sat, 10 Dec 2005 06:56:57 GMT, Vespasian <ves@ves.net> wrote:
>>
>>>The CPAN documentation on perl threads state the overhead of creating
>>>a thread is rather large. Anyone know why or could point me to a
>>>website that explains the reason.
>>>
>>>TIA,
>>>ves
>> Less than a process. I can only imagine the win32 api on that
>> platform. Its all about state and context, as the threads
>> switch, the manager has to save the execution state of the
>> leaving thread, then install the newly running thread state.
>
>[...]
>
>This has absolutely nothing to do with the OP's question of why Perl
>threads have such a high overhead on creation (as opposed to threads in
>other environments).
>
>The actual reason is the fact that Perl threads are interpreter threads,
>meaning that a whole Perl interpreter has to be cloned. The C structure
>backing up an instance of one interpreter is already very big: It has
>over a hundred members. But that is not all. Each and every variable
>created thus far has to be duplicated as well.
>
>And there is some remarkable book-keeping involved, so it's not only a
>matter of doing the equivalent of a few memcpies.
>
>Incidentally, this message cropped up on the perl5-porters list this
>morning:
>
> ithreads clone time is crap. However, if anyone is interested and
> motivated, read on for how we might improve it.
>
> The ithreads cloning is done by copying everything in the old thread
> to the new thread. The clone code keeps track of what it's already
> cloned by using a custom hash table to map the pointer in the old
> thread to the pointer in the new thread. This is all the ptr_table_*
> code.
>
> The hash is structured like the regular perl hash code - an array of
> linked lists, with a hash function used to map the pointer into an
> index in that array. The current hash function is:
>
> #if (PTRSIZE == 8)
> # define PTR_TABLE_HASH(ptr) (PTR2UV(ptr) >> 3)
> #else
> # define PTR_TABLE_HASH(ptr) (PTR2UV(ptr) >> 2)
> #endif
>
>
> The idea of the hash function is to spread the possible input values
> evenly around. It seems that this hash function is pretty lousy.
>
> [...]
>
>Tassilo
------------------------------
Date: 10 Dec 2005 20:21:43 GMT
From: xhoster@gmail.com
Subject: Re: Win32 thread vs fork
Message-Id: <20051210152143.309$LP@newsreader.com>
"Barry" <barryg@highstream.net> wrote:
> Is it true the port of fork() is faked by using threads? If so why?
Um, because Windows doesn't have a native fork. What would you prefer fork
to be faked with, if not threads?
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 8752
***************************************
