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
> 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, wh
Uri Guttman <[EMAIL PROTECTED]> wrote:
> i even sent leo (though i am not sure of ownership since that company
> went under) a generic event loop in c that i wrote.
Thanks again, its really helpful, albeit running event handlers in PASM
is a bit different :)
> ... dan's
> plan is to put the sing
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
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
>
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 fo
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 pr
> "RA" == Rod Adams <[EMAIL PROTECTED]> writes:
> What's the problem with doing this in an event loop? Step 2. I've
> had times where this was intensive enough that Step 1 happening for
> other sites were dropping tcp connections. Forking didn't work well,
> because I needed to mark th
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
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 blo
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 pe
> "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.
> -
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 cro
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 life
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 n
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 kno
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 actu
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
are
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 acc
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 t
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 wo
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
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 would have one interpreter instance and
multipl
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 would have one interpreter instance and
multiple threads (sharing that instance). I would think o
It sounds like an assumption here is that separate threads get separate
interpreter instances. I would have thought that a typical
multithreaded program would have one interpreter instance and multiple
threads (sharing that instance). I would think of separate interpreter
instances as the analo
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
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 entr
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
> 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 seg
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
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 y
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
i
33 matches
Mail list logo
