I gave up on optimizing the read for knucleotides, but I did greatly
improve the sort. It's only used twice, but added a fair number of
lines just to get it in there, so it's more readability than anything
else. The bottleneck is reading in the file. Anyway, attached are
fasta.pir and knucle
On Dec 13, 2005, at 5:55, Brent Fulgham wrote:
On Dec 12, 2005, at 12:23 PM, Leopold Toetsch wrote:
Another one: examples/shootout/pidigits.pir
The formatting on this is off. It looks like it's generating the
sequence of digits, but it needs to be split into individual lines
The progra
On Dec 13, 2005, at 5:06, Joshua Isom wrote:
... This brings me to a request, a sort opcode. The method I think
would be best would be similar to perl's `sort {$a <=> $b} @array`
syntax.
$ perldoc src/classes/fixedpmcarray.pmc
"METHOD void sort(PMC* cmp_func)"
Sort this a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 12, 2005, at 12:23 PM, Leopold Toetsch wrote:
On Dec 8, 2005, at 6:53, Brent Fulgham wrote:
Let the games begin!
Another one: examples/shootout/pidigits.pir
The formatting on this is off. It looks like it's generating the
sequence
I've written up the fasta and knucleotide benchmarks. The knucleotide
takes 25 seconds, but since their benchmark says it's given an argument
of 2,500,000 and none of the programs use argv, and they all read from
stdin, I'm assuming the 2,500,00 is for the fasta benchmark and it's
output file.
On Dec 8, 2005, at 6:53, Brent Fulgham wrote:
Let the games begin!
Another one has hit the svn repo: examples/shootout/nsieve-bits.pir
Actually there are 2 versions: examples/shootout/nsieve-bits-2.pir
The former cheats a bit by setting bits, the 2nd resets bits as of
specs.
le
On Dec 12, 2005, at 22:10, Ed Peschko wrote:
Just curious, but why is mono at .38 seconds and 10.00 seconds
respectively?
What in the .NET implementation makes recursive calls so fast?
Parrot function call and return sequence isn't really optimized yet.
Currently I'm happy to be faster than
On Sun, Dec 11, 2005 at 10:25:54PM +0100, Leopold Toetsch wrote:
>
> On Dec 11, 2005, at 17:01, Leopold Toetsch wrote:
>
> >Leopold Toetsch wrote:
> >
> >>I've timed Ack(3, 9) with an optimized Parrot build:
> >>Python 13.7
> >>Parrot -j 15.3
> >>Parrot -C 13.8
> >
> >Down now (r10445) a
On Dec 8, 2005, at 6:53, Brent Fulgham wrote:
Let the games begin!
Another one: examples/shootout/pidigits.pir
leo
On Dec 12, 2005, at 0:38, Joshua Isom wrote:
... Oh, attached is fannkuch, works fairly well. Only about four
seconds for me, three with an optimized build. And given that their
machine's faster(and x86 linux as opposed to my ppc OSX), I think it's
reasonable to say that parrot beats small
On Dec 12, 2005, at 9:29, Brent Fulgham wrote:
Well, to be honest I've been adding them as you've posted them here or
to SVN. If anyone objects to this, please let me know and I'll remove
them immediately. I assume you are okay with them being posted to the
shootout website under a BSD-styl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 11, 2005, at 2:07 PM, Leopold Toetsch wrote:
On Dec 11, 2005, at 22:25, Leopold Toetsch wrote:
./parrot -C ack.pir4.9s
./parrot -C binarytrees.pir 1659.1s
And another f'up me: should we collect these shootout benchma
Leopold Toetsch:
> Dr.Ruud:
>> Roger Browne:
>>> Unfortunately I could only get to Ack(3, 6) before parrot aborted
>>> with "maximum recursion depth exceeded", at recursion depth 1000.
>>
>> Alternative: use Memoize;
>
> Sure. And there is a (inline) memoized perl Ack already, which is one
> of th
Are there plans to submit these tests?
leo
From the faq...
Please will you include my favourite language?
Maybe we will when you write 15 of the benchmark programs in your
favourite language, and contribute them to "The Computer Language
Shootout" :-)
From the all benchmarks page...
And r
On Dec 10, 2005, at 19:18, Dr.Ruud wrote:
Roger Browne:
Unfortunately I could only get to Ack(3, 6) before parrot aborted with
"maximum recursion depth exceeded", at recursion depth 1000.
Alternative:
use Memoize;
Sure. And there is a (inline) memoized perl Ack already, which is one
Roger Browne:
> Unfortunately I could only get to Ack(3, 6) before parrot aborted with
> "maximum recursion depth exceeded", at recursion depth 1000.
Alternative:
#!/usr/bin/perl
use strict;
use warnings;
use Memoize;
{ local ($,, $\) = ("\t", "\n");
sub ack {
return $_[1] +1 if 0 ==
On Sun, Dec 11, 2005 at 11:07:32PM +0100, Leopold Toetsch wrote:
>
> On Dec 11, 2005, at 22:25, Leopold Toetsch wrote:
>
> >./parrot -C ack.pir4.9s
> >./parrot -C binarytrees.pir 1659.1s
>
> And another f'up me: should we collect these shootout benchmarks in a
> separate dir
On Dec 11, 2005, at 22:25, Leopold Toetsch wrote:
./parrot -C ack.pir4.9s
./parrot -C binarytrees.pir 1659.1s
And another f'up me: should we collect these shootout benchmarks in a
separate directory, with tests attached (with reduced N aka reduced
runtime)?
Are there p
On Dec 11, 2005, at 17:01, Leopold Toetsch wrote:
Leopold Toetsch wrote:
I've timed Ack(3, 9) with an optimized Parrot build:
Python 13.7
Parrot -j 15.3
Parrot -C 13.8
Down now (r10445) at:
parrot -C ack.pir 5.7s
parrot -C binarytrees 16 1m14s
./parrot -C ack
Leopold Toetsch wrote:
I've timed Ack(3, 9) with an optimized Parrot build:
Python 13.7
Parrot -j 15.3
Parrot -C 13.8
Down now (r10445) at:
parrot -C ack.pir 5.7s
parrot -C binarytrees 16 1m14s
That is a little code cleanup was good for 100% speedup ;-)
This is
Joshua Isom wrote:
I just wrote up the binarytrees test in pir, based on the c version.
Although I haven't waited more than twenty minutes yet, I can't get it
working with the argument being 16(what they test with) beyond printing
the first line. The results I'm getting, it's slow, and I don't
I just wrote up the binarytrees test in pir, based on the c version.
Although I haven't waited more than twenty minutes yet, I can't get it
working with the argument being 16(what they test with) beyond printing
the first line. The results I'm getting, it's slow, and I don't have
enough ram.
On Dec 10, 2005, at 16:12, Leopold Toetsch wrote:
I've now checked in ack.pir and ack.py into examples/benchmarks. And
I've timed Ack(3, 9) with an optimized Parrot build:
Python 13.7
Parrot -j 15.3
Parrot -C 13.8
With recent parrot (r10436) and mostly due to this patch ...
$ diff
On Dec 10, 2005, at 13:29, Shane Calimlim wrote:
You can see the generated PIR here: http://theguildforge.com/ack.pir
Indeed nice code already. You can also get rid of "subtract", "concat"
et al by using the n_infix opcodes:
$ cat x.pir
.sub main :main
.local pmc x,y,z,s
x = new .I
On 12/10/05, Roger Browne <[EMAIL PROTECTED]> wrote:
>
> Does your compiled code use PMC Integers or native ints? (I'm using
> PMCs).
>
> Regards,
> Roger Browne
My goal is to have the compiled code as simple as possible, so the compiler
uses native ints and strings if it can.
I also upgraded t
Shane Calimlim wrote:
> You can see the generated PIR here: http://theguildforge.com/ack.pir
Wow, that's nice tight code for something that's spat out by a compiler.
Well done Shane!
I've appended Amber's generated PIR to this message. No need to tell me
all the ways that it can be improved, beca
Roger Browne wrote:
With Parrot 0.4.0, no optimizations, default runcore, Ack(3, 9) takes
233 seconds of CPU time. With "-C" this reduces to 205 seconds. I
haven't tried an optimized Parrot build (so many things to do, so little
time...).
On the same machine, Python 2.4.1 computes Ack(3, 9) in
Shane,
> With some adjustments to the compiler I've gotten the times down to:
>
> Ack(3,6): 509 0.70313 seconds
> Ack(3,9): 409350.51184 seconds
>
> Still not amazing, but I'm sure there's performance to be squeezed out yet.
Does your compiled code use PMC Integers or native in
On 12/9/05, Shane Calimlim <[EMAIL PROTECTED]> wrote:
>
>
> I ran a couple benchmarks with a language/compiler I've been toying with:
>
> (running on redhat el3, p4 3.2 ghz)
> Ack(3,6): 509 2.85374 seconds
> Ack(3,9): 4093223.19224 seconds
>
> Using the following code:
>
> ack(x, y
Leo suggested:
> $P0."recursion_limit"(1)
As it happens, a recursion limit of 1 is enough to complete the
Ackermann benchmark.
> Optimized build? Which runcore? Currently parrot -C may perform fastest.
With Parrot 0.4.0, no optimizations, default runcore, Ack(3, 9) takes
233 seconds
On Dec 8, 2005, at 10:40, Roger Browne wrote:
The recursion limit of 1000 is assigned in inter_create.c and seems
somewhat arbitrary. Is it likely to be raised in the future?
No. But you can raise it in the code ;-)
$P0 = getinterp
$P0."recursion_limit"(1)
Regards,
Roger Browne
Brent Fulgham wrote:
> ... I have
> updated the shootout build machine with parrot (0.3.1) and can start
> running tests if any exist.
A few weeks ago I wrote Brent's "Ackermann" benchmark in Amber for
Parrot. Ackermann is a heavily recursive benchmark.
Brent reports benchmarks for Ack(3, 7),
32 matches
Mail list logo
