Dan Sugalski [EMAIL PROTECTED] wrote:
Interesting. However... the two programs aren't equivalent. You're
using constant values and putting results onto an existing data
structure in perl, so true 'equivalence' requires a few changes to
the source. With those in place, I get the following:
Dan Sugalski [EMAIL PROTECTED] wrote:
SArray and Array PMCs, in addition to being sparse (which has some
overhead), allow you to really store PMC *, STRING *, INTVAL, and
NUMVAL entries, which means that each slot in an SArray and Array
needs to have a flag on it that says what data type's in
Joe Wilson [EMAIL PROTECTED] wrote:
Perl's arrays do indeed accept mixed data types (see example below).
Perl's Arrays take SV's. Please use a PerlArray instead of SArray.
Parrot (still built unoptimized) is significantly faster then perl5 on this
test.
leo
Joe Wilson [EMAIL PROTECTED] wrote:
$ time parrot -j f6.pasm
21001094.10 (note: wrong result and slower with jit)
I don't get a slow down nor a wrong result (i386/linux). On what
platform do you test?
leo
Joe Wilson [EMAIL PROTECTED] wrote:
I implemented the same variable argument function varargs_adder
in both Perl 5 (addit.pl) and Parrot (f4.pasm).
I've put in the addit benchmarks and some variations of it:
- addit.pl ... as of Joe Wilson
- addit.pasm .. ditto but use PerlArray
- addit.imc ...
On Dec 28, 2003, at 1:42 AM, Leopold Toetsch wrote:
Joe Wilson [EMAIL PROTECTED] wrote:
Perl's arrays do indeed accept mixed data types (see example below).
Perl's Arrays take SV's. Please use a PerlArray instead of SArray.
Parrot (still built unoptimized) is significantly faster then perl5 on
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
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:
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:
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: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
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:
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,
17 matches
Mail list logo
