Luke Palmer wrote:
>
> Leopold Toetsch writes:
> > Juergen Boemmels <[EMAIL PROTECTED]> wrote:
> > > what still fails is pbc2c.pl (This needs Parrot::Packfile, which can
> > > only read format 0 (old assemble.pl) bytecodes).
> >
> > This is obsoleted by Daniel's exec patches.
>
> Sadly. I mean, the exec patches are great, but I found no faster way to
> run parrot bytecode than to run it through pbc2c.pl and compile it with
> gcc -O3. That was still about twice as fast as the JIT (and thus the
> exec).
What is different about the resulting executable code from the code
produced by jit? If we could determine what the differences are, then
we might be able to change our jit to produce the same code as gcc -O3
is producing, thus getting the same speed.
> But, as previously pointed out, pbc2c.pl's idea doesn't scale well and
> has a few other drawbacks, so I suppose this was destined to happen.
Is there any chance that we could try and make pbc2c.pl turn each pir
subroutine into a seperate function?
If not enough information is available in the pbc to do that (though
AFAIK, there should be), then imcc itself could output the C code.
As another alternative, can't gcc optomize assembly, at least a little?
Suppose we ran a disassembler on the program produced by exec, then
compiled that using gcc -O3? Obviously, it likely won't be quite as
good as if it compiled C code with -O3, but it still might be able to
make *some* optomizations.
--
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "[EMAIL PROTECTED]
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}
