I've added a new op to the list, foldup, to make unprototyped calls
(and some prototyped calls) a bit easier. The syntax is:
foldup Px
and Px gets a brand new Array PMC, with all the PMC arguments put
into it. This includes all the args in PMC registers as well as args
in the overflow
Dan Sugalski wrote:
Dunno if I replied, but... Next step is a higher level wrapper, if
you're up for fiddling with Postgres itself. Stuff like a single call
to connect (right now you have to make the connect call and poll over
and over again),
I did some benchmarks using your original
On Sat, Dec 27, 2003 at 01:02:34PM +, Harry Jackson wrote:
Dan Sugalski wrote:
Dunno if I replied, but... Next step is a higher level wrapper, if
you're up for fiddling with Postgres itself. Stuff like a single call
to connect (right now you have to make the connect call and poll
So can someone tell me what the Bundle is here for? What's it trying to
achieve? How would someone use it? Is it part of a bigger test thing
I'm not aware of?
Curious,
xoxo,
Andy
I implemented the same variable argument function varargs_adder
in both Perl 5 (addit.pl) and Parrot (f4.pasm).
The variable arguments can be strings, integers or floats
(I wanted to excercise dynamic variable behavior).
I called the function 50 times in a loop to benchmark it.
The results
At 12:19 PM -0800 12/27/03, Joe Wilson wrote:
I implemented the same variable argument function varargs_adder
in both Perl 5 (addit.pl) and Parrot (f4.pasm).
The variable arguments can be strings, integers or floats
(I wanted to excercise dynamic variable behavior).
I called the function 50
At 4:16 PM -0500 12/27/03, Dan Sugalski wrote:
1) Perl's data structures (the equivalent of PMCs) been heavily
optimized, to date Parrot's haven't been
2) Parrot's Array and SArray values all accept mixed-type data,
which perl's arrays do *not* do, and as such have some extra speed
hits that
Using a recursive version of the fibonacci function (with
the integer 32 as an argument) to test function call overhead
I get these timings for various languages and configurations:
perl 5.6.1fib.pl 10.93 seconds
python 2.2.2 fib.py6.76 seconds
parrotf.pasm2.74
Dan Sugalski:
2) Parrot's Array and SArray values all accept mixed-type data, which
perl's arrays do *not* do, and as such have some extra speed hits
that perl arrays don't.
What do you mean?
Perl's arrays do indeed accept mixed data types (see example below).
$ cat addit2.pl
Joe Wilson writes:
Using a recursive version of the fibonacci function (with
the integer 32 as an argument) to test function call overhead
I get these timings for various languages and configurations:
perl 5.6.1fib.pl 10.93 seconds
python 2.2.2 fib.py6.76 seconds
parrot
Joe Wilson writes:
Dan Sugalski:
2) Parrot's Array and SArray values all accept mixed-type data, which
perl's arrays do *not* do, and as such have some extra speed hits
that perl arrays don't.
What do you mean?
Perl's arrays do indeed accept mixed data types (see example below).
No,
--- Luke Palmer [EMAIL PROTECTED] wrote:
The overhead you're seeing comes from many things. First, using
prototyped (or unprototyped) functions from in imcc follows the parrot
calling conventions. That is, it uses continuation-passing instead of
bsr, sets a few int registers on the run, and
--- Luke Palmer [EMAIL PROTECTED] wrote:
Joe Wilson writes:
Dan Sugalski:
2) Parrot's Array and SArray values all accept mixed-type data, which
perl's arrays do *not* do, and as such have some extra speed hits
that perl arrays don't.
What do you mean?
Perl's arrays do indeed
At 2:34 PM -0800 12/27/03, Joe Wilson wrote:
I get consistantly much better timings when arguments of prototyped functions
(regardless of type, number of arguments, or whether it is a vararg function)
are simply all passed in a single PMC array unconditionally.
Please consider it.
Considered, but
At 2:38 PM -0800 12/27/03, Joe Wilson wrote:
--- Luke Palmer [EMAIL PROTECTED] wrote:
Joe Wilson writes:
Dan Sugalski:
2) Parrot's Array and SArray values all accept mixed-type data, which
perl's arrays do *not* do, and as such have some extra speed hits
that perl arrays don't.
At 6:17 PM -0500 12/27/03, Dan Sugalski wrote:
[reasons and some excuses for slowdowns snipped]
None of this, I should point out, in any way means we don't have a
problem, because we do. Things are *not* as fast as they should be,
and we need to address it. (And I'm glad you've brought it up,
On Sat, Dec 27, 2003 at 06:17:34PM -0500, Dan Sugalski wrote:
Also, you might want to make sure you've built Parrot with
optimizations on. By default we don't enable GCC's -O to do any
optimization, and that does slow things down a bunch. On the other
hand, it makes debugging a whole lot
One thing that can help in our sub calling is to keep IMCC from
unconditionally saving all the registers. It does that now, which is
fine, but there's no need to do a full restoretop/savetop between
calls when there haven't been any changes to some of the register
frames. If someone wants to
I used the default ./configure options (no idea what they were).
But more to the point - no one explained why the Parrot JIT ran
the code 3 times slower and arrived at the wrong result.
--- Nicholas Clark [EMAIL PROTECTED] wrote:
On Sat, Dec 27, 2003 at 06:17:34PM -0500, Dan Sugalski wrote:
That's okay - I've also considered and discarded Parrot. ;-)
Good luck with Parrot guys.
I will check out either Mono or Lua's VM for my purposes.
Thanks.
--- Dan Sugalski [EMAIL PROTECTED] wrote:
At 2:34 PM -0800 12/27/03, Joe Wilson wrote:
I get consistantly much better timings when
At 6:34 PM -0800 12/27/03, Joe Wilson wrote:
I used the default ./configure options (no idea what they were).
The default's no optimization. At this point we're in development, so
having a build that can be meaningfully thrown into a debugger's more
important than the ultimate speed. (Besides,
21 matches
Mail list logo
