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 Removing two-arg ne
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
 
Dan Sugalski  
View profile  
 More options Oct 11 2002, 5:48 pm
Newsgroups: perl.perl6.internals
From: d...@sidhe.org (Dan Sugalski)
Date: Fri, 11 Oct 2002 17:01:49 -0400
Local: Fri, Oct 11 2002 5:01 pm
Subject: Re: [PATCH] Removing two-arg ne
Print | View thread | Show original | Report this message | Find messages by this author
At 9:02 PM +0100 10/11/02, Nicholas Clark wrote:

>On Fri, Oct 11, 2002 at 01:30:33PM -0400, Dan Sugalski wrote:
>>  At 7:10 PM +0200 10/10/02, Leopold Toetsch wrote:

>>  >There are also 2 operand math operations of dubious achievement:

>>  >Each of them will be doubled for each RHS INT argument giving ~25 opcodes.

>>  Those are all for the:

>>     a op= b

>>  form. There's a minor benefit to keeping them.

>I would like to kill all generated variants of all the 3 argument opcodes
>where both input arguments are constants. They truly are superfluous.

Where both operands are ints or nums, I think it's a good idea. I'm
less sure in the case where there's a PMC or string involved, as
there may be some assumption of runtime behaviour (in the case of
constant PMCs that might have some methods overloaded) or strings
where the compiler is expecting runtime conversion to happen before
whatever gets done.

>  > >I would kill these too.
>>  >IMHO a smaller core will perform better, then the above saving of 1
>>  >operand in the byte code can achieve.

>>  Maybe, but I'm unconvinced. We are going to do a cull of the opcodes
>>  before release, but I'm not inclined to do it now, and I'm not really
>>  sure that there'll be any speed win at all from it. Size win, yes,
>>  but still, not much. (And we do want the two-arg forms that use PMCs,

>It should make the computed goto core compile more rapidly.

True, though I'm not hugely worried about this, as it happens only once.

>It might also make the computed goto core run more efficiently, as by
>being smaller it will bring more frequently used opcodes closer together.
>(Although we can probably have a larger effect by specificy a sort order
>either by iterative benchmarking the speed of parrot with different orders,
>or by code coverage profiling to find the most common opcodes.)
>Not much gain, but it might be worth it if we can automate the discovery
>process.

True. I think reordering is a bigger win, honestly. Lightly used
opcode functions won't get swapped in until they're really needed.

--
                                         Dan

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


 
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