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
Delivered-To: perl6-intern...@perl.org
Message-ID: <3E4D7816.90804@toetsch.at>
Date: Sat, 15 Feb 2003 00:13:26 +0100
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011129
X-Accept-Language: en-us
MIME-Version: 1.0
To: Dan Sugalski <d...@sidhe.org>
Cc: Jason Gloudon <p...@gloudon.com>, perl6-intern...@perl.org
Subject: Re: YARL - yet another run loop: CSwitch
References: <3E437319.3060007@toetsch.at> <20030207151150.GA21715@gloudon.com> <3E43E39F.7040408@toetsch.at> <20030208144905.GB24341@gloudon.com> <3E45322A.6040900@toetsch.at> <a05200f08ba731337608c@[63.120.19.221]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-SMTPD: qpsmtpd/0.21-dev, http://develooper.com/code/qpsmtpd/
X-Spam-Check-By: one.develooper.com
X-Spam-Status: No, hits=-1.8 required=7.0 tests=CARRIAGE_RETURNS,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02,USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43
X-SMTPD: qpsmtpd/0.20, http://develooper.com/code/qpsmtpd/
Approved: n...@nntp.perl.org
From: l...@toetsch.at (Leopold Toetsch)
Lines: 64

Dan Sugalski wrote:

> At 5:36 PM +0100 2/8/03, Leopold Toetsch wrote:


[ threaded JIT/prederef ]


>> Ouch, yes. So does JIT.
>> So JIT/prederefed code must be separated for threads.

> Yup. This was a decision made a long time ago, back when Daniel started 
> the first JIT stuff. 


Not necessarily so now, it seems. Adressing registers by (thread + 
index), as outlined in Jerome's recent reply to the YARL (switched run 
loop) thread is equally fast on e.g. I386. Dunno if other $arch has a 
similar addressing mode. But as all recent processors now are (very) 
pipelined, one extra argument in the op stream only increases code size 
but not execution speed.

> ... (And that was 
> before everyone got it going insanely fast :)


Thank you Sir.


> It's one of the reasons I haven't been too worried about speeding up the 
> core loop. I've been figuring we'll end up with three:
> 
> *) JIT
> *) CGoto
> *) Old indirect dispatch


The fastest are in terms of possible $arch/compiler features now:

  - JIT
  - CGP (makes CGoto obsolete)
  - Switched Prederef (not in CVS)

but plain function call is needed e.g. for JIT - now.


> and leave it at that. When Gregor was working on the prederef I figured 
> we'd use it as the third, since the JIT was new and I wasn't sure it'd 
> be possible to get it as a good general solution, but it's developed so 
> much that I'm not sure it's worth more loop development. (I could, of 
> course, be wrong... :)

JIT (known as that acronym, but isn`t just in time in parrot) is a very 
$arch depend feature. I did speed up mul_i_ic by 2-50 for some constants 
today, which a different $arch doesn't yet have implemented.

The CGP core is really fast for all compilers that have computed goto - 
and honestly, the code that HL emit, will resemble much a code that is 
not well suited for JIT.

The optimizer in imcc is the real *challenge* in the whole story.

leo