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
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
--- 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
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
with only a better runloop. This is still very good.
But for better timings Parrot would have to use type inference
analysis to avoid the overhead of PMCs in favor of builtin types
wherever possible.
--- Dan Sugalski [EMAIL PROTECTED] wrote:
At 10:28 PM -0800 12/23/03, Joe Wilson wrote
In order to get the 20x speed gain you seek I assume
that Parrot would have to perform some sort of variable
type inference to distinguish, for example, when a
scalar is really just an integer and use an integer register.
Otherwise, the PMCs in Parrot would perform much the same
as the Python
Grotty bits? Can you be more specific?
What Python features or idioms do you believe Parrot will run faster
than the CLR?
--- Dan Sugalski [EMAIL PROTECTED] wrote:
Yeah, but alas Miguel's mis-informed. A reasonable reimplementation
of core python (without all the grotty bits that arguably
Perhaps some of you may be interested in this
entry from Miguel de Icaza's web log:
Python running fast on .NET
http://primates.ximian.com/~miguel/archive/2003/Dec-09.html
Wasn't there supposed to be a Python/Parrot challenge this month?
If so, who won and where are the results?
Dan Sugalski wrote:
1) The changes I proposed are going in. We get arg counts for I/S/N
registers if they're used.
What purpose do these individual I/S/N arg counts serve exactly?
To simply check how many arguments are passed to a function you would
need to get the sum of the number of
My unanswered question below was legitimate, but if you insist...
Perhaps another register can hold the number of problems
with this calling convention.
rim shot
Dan Sugalski wrote:
1) The changes I proposed are going in. We get arg counts for I/S/N
registers if they're used.
What
I agree with Leo.
What good are param counts for the different return types anyway?
How can you tell the difference between a function returning
(int, int, string, PMC, string, float, string, PMC)
and a function returning
(string, int, int, PMC, string, float, PMC, string)?
Both will have the
http://archive.develooper.com/[EMAIL PROTECTED]/dateindex.html
May 26 appears to be the last entry.
__
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
--- Steve Fink [EMAIL PROTECTED] wrote:
On Wed, Feb 12, 2003 at 08:42:59AM -0800, Joe Wilson wrote:
I can build the latest CVS parrot, but how do you build imcc?
There does not seem to be a Makefile in parrot/languages/imcc
even after running 'perl Configure.pl make'.
I'm guessing
The languages/imcc/Makefile is generated when the system calls
below are commented out.
Thanks.
By the way, I had no luck with the alternate quote syntax
suggested by someone else.
--- Juergen Boemmels [EMAIL PROTECTED] wrote:
But after looking a little more closer I found this:
I can build the latest CVS parrot, but how do you build imcc?
There does not seem to be a Makefile in parrot/languages/imcc
even after running 'perl Configure.pl make'.
I'm guessing that parrot/languages/imcc/Makefile is generated
since it appears in parrot/languages/imcc/.cvsignore
What am I
I'd have to agree with Andrew. With only 32 registers of each type in
Parrot (the last time I checked) using most of them for function arguments
would cause much needless register copying within each function.
Surely 8 registers of each type would be more than sufficient for
function
OO code is full of subs which a) are called very often and b) look
like this:
sub code
{
my $self = shift;
return $self-{CODE};
}
sub body
{
my $self = shift;
if (_) {
$self-{BODY} = shift;
}
I vote for mutable strings.
Anything but immutable strings please!
Java sucks as a string manipulation engine because of their immutable
String class. The best GC and JIT in the world can't save it.
High performance Java parsers generally write their own mutable
string class for this very
21 matches
Mail list logo
