Leopold Toetsch [EMAIL PROTECTED] wrote:
3) a separate array for the JITed method stubs, which are per interpeter
and only if the platform can generate such stubs on the fly.
Done now. JITted NCI methods are now enabled again but only i386 has the
necessary interface code in jit/*.
leo
On Tuesday, December 23, 2003, at 08:40 , Rod Adams wrote:
- Most treaded code can be converted to an event loop (+async I/O)
without issue. Esp if we have co-routines.
- For the other stuff, we'd still have Type 2 threads, which gets the
job done.
(Just got back from vacation and was reviewing
At 18:33 -0500 12/23/03, Dan Sugalski wrote:
At 3:54 PM -0600 12/23/03, Rod Adams wrote:
If parrot is fast enough at threading and general computation, I'd
see a PPWAS as an amazing attractive target platform.
- Open Source Specs Code.
- Multiple native languages
- Could relatively easily port
A marriage between Parrot and APR (Apache Portable Runtime) might be
a marriage in heaven, in that respect. For those not in the know,
APR contains most of the grotty low-level bits.
It misses some things that are important to us, like fork(), and it's
got this concept of memory pools,
At 14:16 -0500 12/22/03, Dan Sugalski wrote:
At 8:05 PM +0100 12/22/03, Elizabeth Mattijsen wrote:
In Perl 5, the sharedness of a variable can be determined at
run-time. Leo's mentioned that a PMC will never change its address
during its lifetime. Can these two requirements be met if there
Elizabeth Mattijsen [EMAIL PROTECTED] wrote:
At 14:16 -0500 12/22/03, Dan Sugalski wrote:
Yes. Making a PMC shared can be as simple as swapping out the vtable
pointer in the PMC structure--no need to move it around at all. (Or,
worst case, turning the PMC into a reference PMC for the actual PMC,
At 10:37 +0100 12/23/03, Leopold Toetsch wrote:
2) the Perl5ish declaration
my $var : shared;
is basically:
$P0 = new SharedPerlUndef;
OTOH:
share($var);
may need to morph $var into a shared reference, with an additional
indirection and memory overhead.
(I don't
On Tue, Dec 23, 2003 at 11:07:53AM +0100, Elizabeth Mattijsen wrote:
At 10:37 +0100 12/23/03, Leopold Toetsch wrote:
2) the Perl5ish declaration
my $var : shared;
is basically:
$P0 = new SharedPerlUndef;
OTOH:
share($var);
may need to morph $var into a
At 9:49 AM +0100 12/23/03, Elizabeth Mattijsen wrote:
At 14:16 -0500 12/22/03, Dan Sugalski wrote:
At 8:05 PM +0100 12/22/03, Elizabeth Mattijsen wrote:
In Perl 5, the sharedness of a variable can be determined at
run-time. Leo's mentioned that a PMC will never change its
address during its
Dan Sugalski wrote:
They'll live. Python and Ruby both have a single global interpreter lock
and nobody much cares.
People won't move to parrot because of signal or thread support, or
because we give them a cookie. People will move to parrot because it
runs perl 6, or because it gives them
RA == Rod Adams [EMAIL PROTECTED] writes:
A major use of many languages these days is web services.
In the parrot world, I see three possible ways for this to happen.
- CGI/Exec. No problem to make parrot work, but the performance issues
with this are well known.
- mod_parrot.
On Tue, 23 Dec 2003, Uri Guttman wrote:
RA == Rod Adams [EMAIL PROTECTED] writes:
A major use of many languages these days is web services.
In the parrot world, I see three possible ways for this to happen.
- CGI/Exec. No problem to make parrot work, but the performance issues
Uri Guttman wrote:
RA == Rod Adams [EMAIL PROTECTED] writes:
that is not the only way as i have pointed out. it is just a way that is
promoted heavily (like java). events if done correctly are generaly
faster than threads and use much less ram (no stack context created for
each thread). and
At 3:54 PM -0600 12/23/03, Rod Adams wrote:
Dan Sugalski wrote:
They'll live. Python and Ruby both have a single global interpreter
lock and nobody much cares.
People won't move to parrot because of signal or thread support, or
because we give them a cookie. People will move to parrot because
At 6:15 PM -0500 12/23/03, Simon Glover wrote:
On Tue, 23 Dec 2003, Uri Guttman wrote:
RA == Rod Adams [EMAIL PROTECTED] writes:
A major use of many languages these days is web services.
In the parrot world, I see three possible ways for this to happen.
- CGI/Exec. No problem to
Uri Guttman wrote:
RA == Rod Adams [EMAIL PROTECTED] writes:
Except then the client wanted it to work under Win32, where I've
never trusted any of the pseudo-forks that perl did (esp with
Network I/O going on). So I rewrote the whole thing in a language
that supported threads.
other than the fork
At Tue, 23 Dec 2003 14:23:45 -0500,
Dan Sugalski wrote:
It's that last thing I'm worried about. That all thread related
things in Parrot are forced to use an extra indirection and
consequent performance penalty.
They'll live. Python and Ruby both have a single global interpreter
lock
Elizabeth Mattijsen [EMAIL PROTECTED] wrote:
The main problem with Perl 5 ithreads is the thread startup CPU and
memory usage.
I've now compiled a threaded perl5.8.0 and benchmarked prime-pthread
from perlthrtut against parrot:
$ time parrot t.imc 1
real0m1.044s
user0m0.730s
sys
At 6:38 PM -0800 12/21/03, Jeff Clites wrote:
On Dec 21, 2003, at 5:44 PM, Dan Sugalski wrote:
At 5:31 PM -0800 12/21/03, Jeff Clites wrote:
It sounds like an assumption here is that separate threads get
separate interpreter instances. I would have thought that a
typical multithreaded program
At 11:00 -0500 12/22/03, Dan Sugalski wrote:
Easily, albeit with a bit of a speed hit for threaded code. (Java
has immutable strings which cuts out a lot of the need for
synchronization, since you don't need any for immutable data) If all
access is through PMCs, and it needs to be, you use the
At 8:05 PM +0100 12/22/03, Elizabeth Mattijsen wrote:
At 11:00 -0500 12/22/03, Dan Sugalski wrote:
Easily, albeit with a bit of a speed hit for threaded code. (Java
has immutable strings which cuts out a lot of the need for
synchronization, since you don't need any for immutable data) If
all
I'm currently investigating various issues related to internal
interpreter data structures and multiple threads.
Here is one, that need some design decision:
Parrot_base_vtables[] (the master array of all registered vtables) is
currently a true global. This causes nice errors and segfaults on
Please note that these are comments from a Parrot list lurker and
outsider, but also as someone with some hands on experience with Perl
threads... ;-) And probably stating the bleedingly obvious.
At 11:09 +0100 12/21/03, Leopold Toetsch wrote:
*If* ParrotClasses are per thread (very likely
Elizabeth Mattijsen [EMAIL PROTECTED] wrote:
Hi Liz,
Please note that these are comments from a Parrot list lurker and
outsider, but also as someone with some hands on experience with Perl
threads... ;-) And probably stating the bleedingly obvious.
I'm appreciating your (and of course
I'm currently investigating various issues related to internal
interpreter data structures and multiple threads.
Here is one, that need some design decision:
Parrot_base_vtables[] (the master array of all registered vtables) is
currently a true global. This causes nice errors and
At 14:17 +0100 12/21/03, Leopold Toetsch wrote:
Elizabeth Mattijsen [EMAIL PROTECTED] wrote:
Ideally I'd see a COWed structure: a thread startup would not
actually copy the main vtable structure. As soon as something needs
to be specific for the thread, only then needs that structure to be
Elizabeth Mattijsen [EMAIL PROTECTED] wrote:
At 14:17 +0100 12/21/03, Leopold Toetsch wrote:
1) a real global Parrot_base_vtables[] containing pointers to the local
*static* temp_base_vtable inside the PMC classes C file.
2) another per interpreter vtable array holding all dynamic entries
Elizabeth Mattijsen wrote:
Whenever a PMC gets shared, it would get changed read and write
function slots of the applicable vtable entries that would add mutexes
around all accesses to that PMC.
Yep. That was my conclusion too. A shared PMC will be a variant of the
plain one, where all vtable
28 matches
Mail list logo
