I guess this is one place where being CISC really is better than being
RISC. But how much improvement with outputting to a pbc first? But a
couple notes, there's no --help-optimize like --help-debug, and as far
as I know, there's no way to disable optimizations completely, e.g.
this pir
.sub main :main
$N0 = pow 2.0, 5.0
.end
Is always converted to this.
main:
set N0, 32
end
Which can lead to misleading test results for when pow's actually
broken.
On Feb 8, 2006, at 7:07 AM, Leopold Toetsch wrote:
> Parrot runs the ackermann benchmark faster than C.
> leo
> Heureka - from the -Ofun department
>
> Or - running the ackermann function (and possibly other recursive
> functions) really fast.
>
> $ time ./parrot -Oc -C ack.pir 11
> Ack(3, 11) = 16381
>
> real 0m0.567s
> user 0m0.559s
> sys 0m0.008s
>
> $ time ./ack 11
> Ack(3,11): 16381
>
> real 0m0.980s
> user 0m0.978s
> sys 0m0.002s
>
> Parrot is svn head (not optimized BTW), the C version is compiled -O3
> with 3.3.5. Below is the C [1] and the PIR source [2]. The ack
> function is renamed to __pic_test - currently all the checks that
> would enable this optimization are missing, e.g. if only I and N
> registers are used and not too many, if there is no introspection and
> so on.
>
> The created JIT code for the ack function is also shown [3]. This is
> actually only the recursive part of it, there is a small stub that
> moves the arguments into registers and fetches the return result.
>
> ./parrot -Oc -C turns on tail-recursion optimization (recursive tail
> calls are converted to loops). -C is the CGP or direct-threaded
> runcore, which is able to recompile statically known stuff into faster
> versions by e.g. caching lookups and such.
>
> Have fun,
> leo
Thread Previous
|
Thread Next