Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
perl.perl6.internals
+ new post
About this group
Subscribe to this group
This is a Usenet group - learn more
Message from discussion This week's Perl 6 Summary
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Leopold Toetsch  
View profile  
 More options Feb 28 2003, 3:48 pm
Newsgroups: perl.perl6.internals
From: l...@toetsch.at (Leopold Toetsch)
Date: Fri, 28 Feb 2003 21:28:55 +0100
Local: Fri, Feb 28 2003 3:28 pm
Subject: Re: This week's Perl 6 Summary
Print | View thread | Show original | Report this message | Find messages by this author

Dan Sugalski wrote:
> At 8:54 AM +0100 2/28/03, Leopold Toetsch wrote:
>> I see that limitation. But currently we have a high overhead JIT. The
>> problem is not so much program run time, but load time.
> Damn. Okay, what sort of metadata would be appropriate to aid in this?
> If it means having the assembler, IMCC, or some external utility write a
> chunk that identifies the basic blocks and edges, then I'm all for it.

gprof does indicate that the branch target calculation is the main culprit.
My -Oj hack writes out currently 6 opcode_t per BB:
- bb->begin (with highbit set for a branch target)
- bb->end
- 4 * registers_used

(end is somehow redundant, the latter 4 could be shifted into one op).

The plain jit optimizer would need:
- bb->begin (implying bb->end)
- (bb->end)
- bb->end->branch_target (where the ->end branches to)
- flags (branch source or target per block boundary), could also be
   coded into offsets

 From this info, jit optimizer could build its internal sections (parts
of blocks that are JITed or not). A BB is at least one section, but
could be split into more. The register usage scan and allocation is all
the same (two linear scans over all ops) and another run for actual code
generation.
Here could also be some need for improvement, e.g. register usage could
as well be passed by imcc (top N first usage per block - albeit this is
different to current usage calculation per section). Sean already did
propose this variant. This could save one scan through all ops.

Timing estimations WRT *big* programs are all rather vague, we just
don't have them yet. We badly need a at least medium implemented HL
*with* some RL test cases for this. The Java spec suite implemented in a
supported HL would be nice to compare :) Ook.

leo


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2013 Google