# New Ticket Created by Simon Glover # Please include the string: [perl #17803] # in the subject line of all future correspondence about this issue. # <URL: http://rt.perl.org/rt2/Ticket/Display.html?id=17803 >
Who came up with the idea of two-argument ne, anyway? That's kind of bizarre. I'd much rather have it tested if it exists at all, but it seems pretty obscure.
>Who came up with the idea of two-argument ne, anyway? That's kind of >bizarre.
Definitely bizarre. I think I'd rather not have it, it doesn't make much sense. -- Dan
--------------------------------------"it's like this"------------------- Dan Sugalski even samurai d...@sidhe.org have teddy bears and even teddy bears get drunk
>Who came up with the idea of two-argument ne, anyway? That's kind of >bizarre. I'd much rather have it tested if it exists at all, but it >seems pretty obscure.
It's not completely without precedent, on the Z-80:
RET CC Return from sub if CC is true
But reversing the sense of the test makes it doubly weird. :)
>There are also 2 operand math operations of dubious achievement:
>5 add >2 sub >4 mul >1 div >2 mod
>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 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, since they may well need them if Larry decides to allow overloading += differently from + and =) -- Dan
--------------------------------------"it's like this"------------------- Dan Sugalski even samurai d...@sidhe.org have teddy bears and even teddy bears get drunk
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.
> >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. 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.
Does anyone know a good way of doing permutations with a genetic algorithm? I think that a good way to represent a permutations such that similar permutations have similar genes would be more effective than an efficient way to convert a number to a permutation.
And I don't know of either.
(I don't know an efficient way to turn the number 105124 into the 105124th permutation of 60 things. divide by 60, take remainder; divide by 59, take remainder; etc doesn't feel efficient at all. Is the correct answer use more 'Knuth' ?)
>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
On Fri, Oct 11, 2002 at 05:01:49PM -0400, Dan Sugalski wrote: > At 9:02 PM +0100 10/11/02, Nicholas Clark wrote: > >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 think I agree with this reasoning. I was really thinking of the ints as being easiest to bump off, providing we can be sure that things will consistently for bytecode compile on a 32 bit parrot, but run by a 64 bit parrot (or likewise for different length floating point)
IIRC C99 states that the pre-processor must do all calculations in its longest int type, and it's sort of related. I think we'd need to state that constant folding will be done at compile time, and will be done at the precision of the compiling parrot.
> >It should make the computed goto core compile more rapidly.
> True, though I'm not hugely worried about this, as it happens only once.
Per user who compiles parrot. The current computed goto code hurts my desktop at work (128M RAM, x86 linux) and with more ops it will get worse.
It may turn out that gcc improves to the point that it can build measurably better code for specific CPUs, but distributions/*BSDs require a lowest common denominator build (typically 486 in the x86 family, isn't it?)
In which case many people may gain quite a lot by building their own custom parrot, and they're going to notice the compile time.
I admit this is low down any list of priorities, but it ought to be somewhere. I find with my work code (the C, not perl related) that gcc3.2 with all the stops out generates code that was about 5% faster than deadrat's (default 2.96 heresy non-)gcc. And at YAPC::EU someone reported that (IIRC) he'd seen 12% speedup from newer gcc and option tweaking.
And getting even 5% without changing your perl6 code or parrot's code is nice.
However, the more interesting thing about getting compile times down is you get more smoke in finite time. (And also developers get more done if they spend less time waiting for the compiler. BUT EVERYONE SHOULD ALREADY BE USING ccache AS THAT MAKES REBUILDS AND EDITING COMMENTS DAMN FAST (unless they can think of good reason not to))
> True. I think reordering is a bigger win, honestly. Lightly used > opcode functions won't get swapped in until they're really needed.
More free speedup. I had this crazier idea - experiment with splitting every parrot function out into its own object file, and see what happens with permuting the order of all of them.
But I think I need a lot of tuits, and a decent way of doing permutations with genetic algorithms. (I've got access to a fast machine, but it will have to stop smoking perl5 for the duration). Although potentially I'll end up with an order optimised for x86 FreeBSD, which should keep the Linux vs FreeBSD performance arms race going nicely.
Nicholas Clark wrote: > On Fri, Oct 11, 2002 at 05:01:49PM -0400, Dan Sugalski wrote:
>>At 9:02 PM +0100 10/11/02, Nicholas Clark wrote:
>>>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.
Ok, we need 2 + 3 args PMC ops becaus of overloading.
> I think I agree with this reasoning. I was really thinking of the ints > as being easiest to bump off, providing we can be sure that things will > consistently for bytecode compile on a 32 bit parrot, but run by a 64 > bit parrot (or likewise for different length floating point)
By preprocessing ints and nums, we would move overflow/precision issues from the running machine to the compiling machine. But the issue itself would remain.
where the latter could be tossed, when the assebler/imcc swaps arguments. This saves 6 opcodes for each <add> and <mul> and ~2 opcodes for each <sub>, <div> and <mod>. <sub> with constants could be rewritten to <add>. Saving a total of ~20 ops.
Some 2 operand bitwise operations are there some not - there is no consistency - I would remove the to operand bitwise integer ops.
> More free speedup. I had this crazier idea - experiment with splitting > every parrot function out into its own object file, and see what happens > with permuting the order of all of them.
I have s small shell script (attached), which generates opcode coverage for all PBC files in the parrot tree:
total ops 866 ops types 177 op usage stat 540 op-list-all 161 op-list-s
So only ~2/3 opcodes are currently used/tested (ops types/op-list-s are ops short names w/o variants).
To run the script do: make test cd languages/perl6 make perl6 --test cd - make disassemble ./op-stat
> But I think I need a lot of tuits, and a decent way of doing permutations > with genetic algorithms. (I've got access to a fast machine, but it will > have to stop smoking perl5 for the duration).
This would keep the machine busy for some time ;-) Interesting idea.
