Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 9:18 PM +0200 7/20/04, Leopold Toetsch wrote:
[ I've to come back to my proposed scheme ]
>>No. The whole frame is the continuation. Its holding exactly the
>>interpreter state at the time of calling into the sub. Including
>>registers, which makes reg
Larry Wall <[EMAIL PROTECTED]> wrote:
> So Evil Larry? suggests that you embed a Python interpreter and hand off
> the unsuccessful tests back to Python. :-)
Good idea. Here is bx.pir from Evil Leo:
$ cat bx.pir
.sub main @MAIN
.param pmc argv
.const string PY = '/usr/local/bin/python -
On Tue, Jul 20, 2004 at 07:24:52PM +0200, Leopold Toetsch wrote:
: There is no need to change these things before OSCON. All benches that
: run are running from equal speed C up
: to around 3 times the speed of Python, e.g. the PI() coroutine in b2.py
: :)
So Evil Larryâ suggests that you embed a
At 9:18 PM +0200 7/20/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 6:46 PM +0200 7/20/04, Leopold Toetsch wrote:
I forgot that in my proposal. Subroutine PMCs need duplication for
new threads.
That doesn't work for closures, which can be shared across threads in
a pool
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 6:46 PM +0200 7/20/04, Leopold Toetsch wrote:
>>I forgot that in my proposal. Subroutine PMCs need duplication for
>>new threads.
> That doesn't work for closures, which can be shared across threads in
> a pool.
We don't have shared closures. We don't
Larry Wall <[EMAIL PROTECTED]> wrote:
> On Tue, Jul 20, 2004 at 11:34:32AM -0400, Dan Sugalski wrote:
>: So much for not changing the calling conventions. :(
> I think most of us would agree that you're allowed to break anything
> you like this week. Worry about unbreaking things after OSCON...
At 6:46 PM +0200 7/20/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
... It's desperately un-thread-safe, which is
one of the things that didn't make it out in my last reply.
Your recent words related to threads were: we don't optimize for threaded
programs. We optimize for th
At 9:43 AM -0700 7/20/04, Larry Wall wrote:
On Tue, Jul 20, 2004 at 11:34:32AM -0400, Dan Sugalski wrote:
: So much for not changing the calling conventions. :(
I think most of us would agree that you're allowed to break anything
you like this week. Worry about unbreaking things after OSCON...
I'm
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> ... It's desperately un-thread-safe, which is
> one of the things that didn't make it out in my last reply.
Your recent words related to threads were: we don't optimize for threaded
programs. We optimize for the common case, that is single-threaded.
I fo
On Tue, Jul 20, 2004 at 11:34:32AM -0400, Dan Sugalski wrote:
: So much for not changing the calling conventions. :(
I think most of us would agree that you're allowed to break anything
you like this week. Worry about unbreaking things after OSCON...
Larry
At 5:56 PM +0200 7/20/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
Copying 640 bytes once, or 640 bytes * 2 * nr of calls? What is
inefficient?
This *only* makes a difference for vtable functions written in
bytecode. For normal code we're already copying the frames in and o
Dan Sugalski <[EMAIL PROTECTED]> wrote:
>>
>>Copying 640 bytes once, or 640 bytes * 2 * nr of calls? What is
>>inefficient?
> This *only* makes a difference for vtable functions written in
> bytecode. For normal code we're already copying the frames in and out
> when we make a call and there's no
At 4:59 PM +0200 7/20/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 10:35 AM +0200 7/20/04, Leopold Toetsch wrote:
And yes, this will, with sufficient call depth, result in an
all-bits-set dirty mask, which is also why we allow bytecode to
*unset* bits in the dirty fram
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 10:35 AM +0200 7/20/04, Leopold Toetsch wrote:
> And yes, this will, with sufficient call depth, result in an
> all-bits-set dirty mask, which is also why we allow bytecode to
> *unset* bits in the dirty frame marker, but only if those bits are
> set in
At 10:35 AM +0200 7/20/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
Leo, we've talked about this before. The sensible and straightforward
thing to do in a case like this is to tag in the sub pmc which
register frames are used by the sub.
And what, if the sub calls another s
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
>> Leo, we've talked about this before. The sensible and straightforward
>> thing to do in a case like this is to tag in the sub pmc which
>> register frames are used by the sub.
>
> And what, if the sub calls
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Leo, we've talked about this before. The sensible and straightforward
> thing to do in a case like this is to tag in the sub pmc which
> register frames are used by the sub.
And what, if the sub calls another sub?
The current pushtopp() is already an ill
At 9:40 PM +0200 7/19/04, Leopold Toetsch wrote:
Below [1] is a small test program, which basically shows the speed of
calling generators aka coroutines. But *what* I want to discuss isn't
restricted to calling coroutines. Its the same (more or less) with
calling any subroutine-like thingy, being i
18 matches
Mail list logo
