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' ?) Nicholas Clark -- Even better than the real thing: http://nms-cgi.sourceforge.net/
