Newsgroups: perl.perl6.internals
Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!nntp.perl.org
Return-Path: <l...@toetsch.at>
Mailing-List: contact perl6-internals-h...@perl.org; run by ezmlm
Delivered-To: mailing list perl6-intern...@perl.org
Received: (qmail 55793 invoked by uid 76); 17 Mar 2004 17:50:44 -0000
Received: from x1.develooper.com (HELO x1.develooper.com) (63.251.223.170)
  by onion.perl.org (qpsmtpd/0.27.1) with SMTP; Wed, 17 Mar 2004 09:50:44 -0800
Received: (qmail 1814 invoked by uid 225); 17 Mar 2004 17:50:41 -0000
Delivered-To: perl6-intern...@perl.org
Received: (qmail 1674 invoked by alias); 17 Mar 2004 17:50:10 -0000
Received: from [195.170.70.19] (HELO mail.nextra.at) (195.170.70.19)
  by la.mx.develooper.com (qpsmtpd/0.27.1) with ESMTP; Wed, 17 Mar 2004 09:50:10 -0800
Received: from lux.leo.home (at24a01-dial-184.nextranet.at [195.170.73.184])
	by mail.nextra.at (20030919/20030919/nextra) with ESMTP id i2HHo4cY000105;
	Wed, 17 Mar 2004 18:50:05 +0100 (MET)
Received: from thu8.leo.home (thu8.leo.home [192.168.1.5])
	by lux.leo.home (Postfix on linux 2.0.36 (i386)) with ESMTP
	id 8EC51118023; Wed, 17 Mar 2004 18:47:48 +0100 (MET)
Received: (from lt@localhost)
	by thu8.leo.home (8.10.2/8.10.2/SuSE Linux 8.10.0-0.3) id i2HHkon26793;
	Wed, 17 Mar 2004 18:46:50 +0100
Message-ID: <200403171746.i2HHkon26793@thu8.leo.home>
To: d...@sidhe.org (Dan Sugalski)
Subject: Re: Optimizations for Objects
In-Reply-To: <a06010206bc7e29eca1e5@[10.0.1.2]>
References: <a06010206bc7e29eca1e5@[10.0.1.2]>
Reply-To: l...@toetsch.at
Cc: perl6-intern...@perl.org
Date: Wed, 17 Mar 2004 18:46:50 +0100
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on x1.develooper.com
X-Spam-Status: No, hits=-4.9 required=8.0 tests=BAYES_00 autolearn=ham 
	version=2.63
Approved: n...@nntp.perl.org
From: l...@toetsch.at (Leopold Toetsch)

Dan Sugalski <d...@sidhe.org> wrote:
> Okay, as I see it there are two big things that we can do to speed
> objects up. (Well, besides speeding up the creation of continuation
> PMCs, which I am, at the moment, sorely tempted to put in a special
> pool for fast allocation)

I though about that already. Returncontinuations created via the *cc
opcode variants are created in the opcode and used exactly once just for
returning from the sub.  So I'd do for these a per-interpreter
freelist, where they get put back after invokeing the return
contination.

> 1) A method cache. Which we need anyway, so this isn't any surprise

> 2) Pre-figuring the delegated vtable functions.

> At the moment I'm considering two storage schemes for the PMC
> pointers (one hanging off the vtable itself, another in the class
> attributes) but I'm open to suggestions here.

Or: after the 1st delegate lookup create a JITed stub that is in
pseudo-code:

  enter
  call saveregs
  S0 = "meth"
  P2 = obj
  P5 = value  # arguments
  call runops
  call restoreregs
  # handle return val
  leave
  ret

This function's address replaces the vtable slot of the old one and is
now called directly as the delegate. When the register assignments are
done interpreter-relative, this stub should be reusable by different
threads too.

> --
>                                          Dan

> --------------------------------------"it's like this"-------------------
> Dan Sugalski                          even samurai
> d...@sidhe.org                         have teddy bears and even
>                                        teddy bears get drunk

leo