Andy Dougherty <[EMAIL PROTECTED]> wrote:
> Thinking it might have something to do with the SPARC architecture,
> I tried it on x86, where Parrot took 80 times as long:
>
> C: time ./ack 11
> Ack(3,11): 16381
>
> real0m0.759s
> user0m0.758s
> sys 0m0.002s
>
> Parrot: t
On Feb 10, 2006, at 18:34, Andy Dougherty wrote:
On Wed, 8 Feb 2006, Leopold Toetsch wrote:
Parrot runs the ackermann benchmark faster than C.
This looked like fun, so I tried it on Solaris/SPARC.
Solaris/SPARC doesn't have a working JIT runcore rurrently and I can't
test it - no chance
On Wed, 8 Feb 2006, Leopold Toetsch wrote:
> Parrot runs the ackermann benchmark faster than C.
>
> $ time ./parrot -Oc -C ack.pir 11
> Ack(3, 11) = 16381
>
> real0m0.567s
> user0m0.559s
> sys 0m0.008s
>
> $ time ./ack 11
> Ack(3,11): 16381
>
> real0m0.980s
> user0m0.978s
>
On 2/9/06, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>
> On Feb 8, 2006, at 22:28, Joshua Isom wrote:
>
> > but an option to disable compile time optimizations would help with
> > the testing the interpreter instead of the compiler
>
> It's not an optimization and it can't be turned off, as there
Markus Laire wrote:
Is there a reason why this can't be "turned off" like this:
convert
$N0 = pow 2.0, 5.0
to
$N = 2.0
$N0 = pow N, 5.0
That's exactly what is executed. Registers are filled with the value of
the constants and the 'pow' opcode is executed. The little difference i
On Feb 8, 2006, at 22:28, Joshua Isom wrote:
but an option to disable compile time optimizations would help with
the testing the interpreter instead of the compiler
It's not an optimization and it can't be turned off, as there are no
such opcodes like 'pow_i_ic_ic'. And again - the evaluatio
But with jit enabled on x86/freebsd/openbsd, I was having problems with
some of the pow functions. The rt number is #38382. Because of the
compile time optimization, it made it trickier to work with because the
compile time was ok, but the jit runtime wasn't, and it took me a
little while to
Leopold Toetsch wrote:
ori r11, r31, 20# r31 is 0
add r3, r4, r11# a 2nd oris is needed for constants > 0x
Well that's actually a bad example as there exists addi and addis
instructions.
But have a look at src/jit/arm/jit_emit.h emit_load_constant() and
follow the functio
Joshua Isom wrote:
I guess this is one place where being CISC really is better than being
RISC.
It really depends on the hardare you are running. E.g.
add I0, I1, 20
translates either to something like:
lea %ecx, 20(%edx) # not yet but in case ..
or
ori r11, r31, 20# r31 is 0
"Joshua Isom" <[EMAIL PROTECTED]> wrote:
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 optim
ter 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
real0m0.567s
user0m0.559s
sys 0m0.008s
$ time ./ack 11
Ack(3,11): 16381
real
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
real0m0.567s
user0m0.559s
sys 0m0.008s
$ time
12 matches
Mail list logo
