Dan Sugalski <[EMAIL PROTECTED]> wrote:
> ... Threads or not, the single-threaded case is going to
> be the common case for parrot, and it's mildly faster in general.
That and the overhead to just test the scheme (in the absence of RL code)
are really good arguments to keep the status quo :)
leo
At 10:23 AM +0200 5/28/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
If you want to go back to a frame pointer style of register stack
access, that's doable, but that's the way it was in the beginning and
the performance penalties in normal code outweighed the savings in
st
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Piers Cawley <[EMAIL PROTECTED]> wrote:
>
>> Then, at runtime, 'fred' gets set up as the implemntation for an op.
>
>> Which, given your implementation, means that each function call that
>> fred makes should be protected with savetop/restoretop pairs.
Piers Cawley <[EMAIL PROTECTED]> wrote:
> Then, at runtime, 'fred' gets set up as the implemntation for an op.
> Which, given your implementation, means that each function call that
> fred makes should be protected with savetop/restoretop pairs. Oops.
The implementation checks register usage of
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Piers Cawley wrote:
>> But under this scheme, the implementing function will have to do a
>> saveall for every function it calls because it doesn't know what
>> registers its caller cares about. And you're almost certainly going
>> to want to call othe
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> If you want to go back to a frame pointer style of register stack
> access, that's doable, but that's the way it was in the beginning and
> the performance penalties in normal code outweighed the savings in
> stack pushes.
JITted memory access through the
At 4:54 PM +0200 5/26/04, Leopold Toetsch wrote:
Piers Cawley wrote:
But under this scheme, the implementing function will have to do a
saveall for every function it calls because it doesn't know what
registers its caller cares about. And you're almost certainly going
to want to call other function
Piers Cawley wrote:
But under this scheme, the implementing function will have to do a
saveall for every function it calls because it doesn't know what
registers its caller cares about. And you're almost certainly going
to want to call other functions to do the heavy lifting for all the
usual reaso
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Piers Cawley <[EMAIL PROTECTED]> wrote:
>> Leopold Toetsch <[EMAIL PROTECTED]> writes:
>
> [ calculating registers to save ]
>
>>> ... once per sub per location where the sub is called from. But there
>>> isn't any knowledge that a sub might be called.
Piers Cawley <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch <[EMAIL PROTECTED]> writes:
[ calculating registers to save ]
>> ... once per sub per location where the sub is called from. But there
>> isn't any knowledge that a sub might be called. So the cost is actually
>> more per PMC instruction t
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Piers Cawley wrote:
>> Leopold Toetsch <[EMAIL PROTECTED]> writes:
>>
>>>Not quite for this case. Or in theory yes, but... As calling the
>>>subroutine mustn't have any changes to the caller's registers, it's just
>>>simpler to save these registers th
Piers Cawley wrote:
Leopold Toetsch <[EMAIL PROTECTED]> writes:
Not quite for this case. Or in theory yes, but... As calling the
subroutine mustn't have any changes to the caller's registers, it's just
simpler to save these registers that the subroutine might change.
But generating the save signat
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Piers Cawley <[EMAIL PROTECTED]> wrote:
>> Leopold Toetsch <[EMAIL PROTECTED]> writes:
>
>>> - if it calls a PASM routine, registers have to be preserved. Which
>>> registers depend on the subroutine that actually gets called (ok, this
>>> informat
Piers Cawley <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch <[EMAIL PROTECTED]> writes:
>> - if it calls a PASM routine, registers have to be preserved. Which
>> registers depend on the subroutine that actually gets called (ok, this
>> information - which registers are changed by the sub - can b
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>> At 11:35 AM +0200 4/30/04, Leopold Toetsch wrote:
>>>Dan Sugalski <[EMAIL PROTECTED]> wrote:
If we go MMD all the way, we can skip the bytecode->C->bytecode
transition for MMD functions that are wr
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 12:02 PM +0200 5/5/04, Leopold Toetsch wrote:
>>Changing C or any MMDed opcode to look like a branch is a severe
>>performance impact for the non-overloaded case.
> If the JIT structure makes it untenable, it doesn't work, and that's
> fine. I don't thi
At 12:02 PM +0200 5/5/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 11:35 AM +0200 4/30/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
If we go MMD all the way, we can skip the bytecode->C->bytecode
transition for MMD functions that are written in pa
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 11:35 AM +0200 4/30/04, Leopold Toetsch wrote:
>>Dan Sugalski <[EMAIL PROTECTED]> wrote:
>>> If we go MMD all the way, we can skip the bytecode->C->bytecode
>>> transition for MMD functions that are written in parrot bytecode, and
>>> instead dispatch
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> 3) Inspect the delegated method or MMD sub and save only the needed
> register range.
Have this now running here locally and tested:
$ ./bench -b=^over
Numbers are relative to the first one. (lower is better)
p-j-Oc p-C-Oc perl-th p
At 4:00 PM +0200 5/2/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
Well... about that. It's actually easily doable with a bit of
trickery. We can either:
I have trickery number 4) here. Dunno if its doable, but worth
considering IMHO:
It's doable but the problem you run into
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> # recompile each bxor_p_p_p
> mmdvtfind P20, .VTABLE_BXOR, .PerlInt, .PerlInt
^^
This has to use the dynamic type of the PMC of course.
typeof I20, P17
typeof I21, P18
mmdvtfind P20,
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Well... about that. It's actually easily doable with a bit of
> trickery. We can either:
I have trickery number 4) here. Dunno if its doable, but worth
considering IMHO:
Here is mmd.pasm (using bxor but substitute any math/bitwise/... op).
Comments inline
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> 1) Mark the overload subs as special and change their calling conventions
Different calling conventions are not really pleasant for the
compiler(s). But doable.
> 2) Wrap the overload subs in some bytecode that Does The Right
> Thing--takes a continuatio
At 11:35 AM +0200 4/30/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
If we go MMD all the way, we can skip the bytecode->C->bytecode
transition for MMD functions that are written in parrot bytecode, and
instead dispatch to them like any other sub.
Not really. Or not w/o sign
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> ... Operator overloading has to
> have some cost :)
$ ./bench -b=over#[1]
Numbers are relative to the first one. (lower is better)
p-j-Oc perl-th perlpython ruby
overload100%151%131%- -
Not too bad,
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> If we go MMD all the way, we can skip the bytecode->C->bytecode
> transition for MMD functions that are written in parrot bytecode, and
> instead dispatch to them like any other sub.
Not really. Or not w/o significant overhead for MMD functions
implemented
Dan Sugalski wrote:
> Not to sound like a Jackie Chan cartoon or anything, but...
I was thinking Columbo, actually...
> If we go MMD all the way, we can skip the bytecode->C->bytecode
> transition for MMD functions that are written in parrot bytecode, and
> instead dispatch to them like any ot
Not to sound like a Jackie Chan cartoon or anything, but...
If we go MMD all the way, we can skip the bytecode->C->bytecode
transition for MMD functions that are written in parrot bytecode, and
instead dispatch to them like any other sub.
Not to make this sound good or anything, of course. :-P
-
28 matches
Mail list logo
