Dan Sugalski <[EMAIL PROTECTED]> wrote:
> ... We rework the current pmc
> processor to take the entries that are getting tossed and
> automatically add them to the MMD tables on PMC load instead.
I've now implemented MMD for PerlInt's bitwise_xor as a test case. Syntax
looks like this:
void b
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> ... And... we
> move *all* the operator functions out of the vtable and into the MMD
> system. All of it.
This *all* includes vtable functions like add_int() or add_float() too,
I presume. For these we have left argument dispatch only. But what is
the rig
On Thu, 2004-04-29 at 03:33, Leopold Toetsch wrote:
> As Dan already said there is no performance hit (at least if the MMD
> tables don't blow the caches).
Good stuff! One thing leaps to mind when you mention the cache though...
keep in mind that blowing L2 cache (which we might be in no danger o
At 11:42 AM -0400 4/29/04, Dan Sugalski wrote:
At 3:55 PM +0200 4/29/04, Leopold Toetsch wrote:
Another long running discussion: do we need duplicate mmd tables.
Here is a proof of concept to avoid it:
Oh, right, and... this is really, really evil. Which is why I just
put it in. :)
And just to add
At 3:55 PM +0200 4/29/04, Leopold Toetsch wrote:
Another long running discussion: do we need duplicate mmd tables.
Here is a proof of concept to avoid it:
Oh, right, and... this is really, really evil. Which is why I just
put it in. :)
--
Dan
--
At 3:55 PM +0200 4/29/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
Okay, we've a long-running discussion between Leo and I about the
keyed variants for all the binary vtable entries.
Another long running discussion: do we need duplicate mmd tables.
Dunno. Don't care, really
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Okay, we've a long-running discussion between Leo and I about the
> keyed variants for all the binary vtable entries.
Another long running discussion: do we need duplicate mmd tables.
Here is a proof of concept to avoid it:
#v+
--- parrot/src/mmd.cTh
Aaron Sherman <[EMAIL PROTECTED]> wrote:
> On Wed, 2004-04-28 at 11:33, Dan Sugalski wrote:
> Only one question. What's the performance hit likely to be and is there
> any way around that performance hit for code that doesn't want to take
> it?
As Dan already said there is no performance hit (at
At 8:21 PM +0200 4/28/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
We toss the keyed variants for everything but get and set. And... we
move *all* the operator functions out of the vtable and into the MMD
system. All of it. Math, logical ops, bit ops... the works. All
that
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> We toss the keyed variants for everything but get and set. And... we
> move *all* the operator functions out of the vtable and into the MMD
> system. All of it. Math, logical ops, bit ops... the works. All
> that's left are the gets, sets, and meta-informa
Ok, nuff said. I think there are slightly too many definitions that
we're not agreeing on (though, I suspect if we ironed those out, we'd be
in violent agreement).
As for INT/PMC thing I'm pretty sure all of my concerns come down
to: compilers can really screw each other over, but then we knew
At 12:51 PM -0400 4/28/04, Aaron Sherman wrote:
On Wed, 2004-04-28 at 12:33, Dan Sugalski wrote:
At 12:21 PM -0400 4/28/04, Aaron Sherman wrote:
>Since we're specifically talking about Perl here (and probably not Perl
>5, since its overloading model is baroque and probably has to be managed
>b
On Wed, 2004-04-28 at 12:33, Dan Sugalski wrote:
> At 12:21 PM -0400 4/28/04, Aaron Sherman wrote:
> >Since we're specifically talking about Perl here (and probably not Perl
> >5, since its overloading model is baroque and probably has to be managed
> >by the compiler, not Parrot)
>
> Actually pe
At 12:21 PM -0400 4/28/04, Aaron Sherman wrote:
On Wed, 2004-04-28 at 12:06, Dan Sugalski wrote:
I'm not sure of the hit--an MMD version of the perl base scalar PMCs
is faster than the non-mmd version in some tests. I fully expect that
can't hold, though. And no, there's no way around it--if we
On Wed, 2004-04-28 at 12:06, Dan Sugalski wrote:
> I'm not sure of the hit--an MMD version of the perl base scalar PMCs
> is faster than the non-mmd version in some tests. I fully expect that
> can't hold, though. And no, there's no way around it--if we do this
> everyone pays. (OTOH, all perl
At 11:59 AM -0400 4/28/04, Aaron Sherman wrote:
On Wed, 2004-04-28 at 11:33, Dan Sugalski wrote:
We toss the keyed variants for everything but get and set. And... we
move *all* the operator functions out of the vtable and into the MMD
system.
[...]
Comments?
Only one question. What's the perfor
On Wed, 2004-04-28 at 11:33, Dan Sugalski wrote:
> We toss the keyed variants for everything but get and set. And... we
> move *all* the operator functions out of the vtable and into the MMD
> system.
[...]
> Comments?
Only one question. What's the performance hit likely to be and is there
any
Okay, we've a long-running discussion between Leo and I about the
keyed variants for all the binary vtable entries.
On the one hand, there's a hell of a lot of 'em, of potentially
limited utility.
On the other, without them it means creating temporary PMCs if we do
something like:
foo[1
18 matches
Mail list logo
