[CVS ci] JIT/NCI
I have put in the follwing patch:
- if CAN_BUILD_CALL_FRAMES is defined, call the JITed version
- if that returns zero, use the hardcoded version in nci.c
- else use hardcoded version
So you can implement signatures step by step.
If you are going to implement JITted NCI stubs:
1) create a function:
void *
Parrot_jit_build_call_func(Parrot_Interp interpreter, PMC *pmc_nci,
String *signature)
{
return NULL;
}
in jit/*/jit_emit.h
2) enable calling this for your architecture in
build_tools/build_nativecall.pl near line 180
3) make libnci.$(SO)
4) Implement signatures step by step
5) Have fun
leo
Re: Freezing strings?
Leopold Toetsch wrote: If it's just some busywork, such as copying some code into PerlString and tweaking it, I can probably do it, but I've been out of the loop for a while, so anything particularly involved is likely beyond me. The interfaces are all there. It *should* just be: - cut'n paste code from perlint - s/_integer/_string/ for (push, shift) and s/int_val/str_val/ It was. I've committed it, along with a test for it. All tests pass on Debian. I also tried to add freeze and thaw to PerlNum (as long as I was screwing around in that bit of the code), but the linker wasn't very happy with that--complained about being unable to find VTABLE_shift_number and VTABLE_push_number, so I undid that. By the way, I never realized how patient you gcc guys were with the computed-goto core--VC++ doesn't support it, so I didn't know that it took so long to compile. -- Brent Dax Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker Oceania has always been at war with Eastasia. [I *will* learn to use Thunderbird correctly one of these days!]
Re: [perl #27391] parrot -t crash
Jens Rieks [EMAIL PROTECTED] wrote: The following code crashes parrot if run with -t (trace). Fixed. That was not an easy one. A slightly wrong implementation (braino courtesy of leo) did reset interpreter-lo_var_ptr (the stack limit), when reentering the run loop, e.g. in object's __init calls. This lead to memory corruption if a DOD or GC was triggered inside the method call. During tracing, a lot of string handling is done, which sooner or later always exposed the bug. jens leo
Re: Freezing strings?
Brent Dax Royal-Gordon [EMAIL PROTECTED] wrote: Leopold Toetsch wrote: The interfaces are all there. It *should* just be: - cut'n paste code from perlint - s/_integer/_string/ for (push, shift) and s/int_val/str_val/ It was. I've committed it, along with a test for it. All tests pass on Debian. Whee. FTL check in :) I also tried to add freeze and thaw to PerlNum (as long as I was screwing around in that bit of the code), but the linker wasn't very happy with that--complained about being unable to find VTABLE_shift_number and VTABLE_push_number, so I undid that. My fault. Mixed up shift_number vs shift_float. So the macros don't match. You could just rename in pmc_freeze.h: typedef struct _image_funcs s/_number/_float/ or call the functions explicitely. By the way, I never realized how patient you gcc guys were with the computed-goto core--VC++ doesn't support it, so I didn't know that it took so long to compile. Yep. Albeit newer gcc versions seem to be faster. BTW try an optimized compile ... leo
Re: Freezing strings?
Leopold Toetsch wrote: Brent Dax Royal-Gordon [EMAIL PROTECTED] wrote: I also tried to add freeze and thaw to PerlNum (as long as I was screwing around in that bit of the code), but the linker wasn't very happy with that--complained about being unable to find VTABLE_shift_number and VTABLE_push_number, so I undid that. My fault. Mixed up shift_number vs shift_float. So the macros don't match. You could just rename in pmc_freeze.h: Renaming did it. freeze/thaw for PerlNum checked in, with test. The first time I ran tests after compiling, I got a failure in t/pmc/signals.t--it thought that no tests had run, and the harness eventually reported 12/6 subtests of signals.t failed. Immediately re-running make test came out fine; I added the new PerlNum test to freeze.t and ran it a third time, which also passed. I guess it was a fluke. Yep. Albeit newer gcc versions seem to be faster. [EMAIL PROTECTED]/~/parrot% gcc -v Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs gcc version 2.95.4 20011002 (Debian prerelease) So my compiler's almost as old as Parrot itself. Typical Debian. A project for the weekend, perhaps... -- Brent Dax Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker Oceania has always been at war with Eastasia.
Re: Freezing strings?
Brent Dax Royal-Gordon [EMAIL PROTECTED] wrote: Renaming did it. freeze/thaw for PerlNum checked in, with test. Fine, thanks. The first time I ran tests after compiling, I got a failure in t/pmc/signals.t--it thought that no tests had run, and the harness eventually reported 12/6 subtests of signals.t failed. Immediately re-running make test came out fine; I added the new PerlNum test to freeze.t and ran it a third time, which also passed. I guess it was a fluke. It's mainly a problem with the test script (and likely timing of that). The test is of course a big hack. Yep. Albeit newer gcc versions seem to be faster. [EMAIL PROTECTED]/~/parrot% gcc -v Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs gcc version 2.95.4 20011002 (Debian prerelease) Pah. That's a really new one ;) $ gcc -v Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.2/specs gcc version 2.95.2 19991024 (release) But ony my laptop I have: gcc-version 3.3.3 20040110 (prerelease) (Debian) So my compiler's almost as old as Parrot itself. Typical Debian. A project for the weekend, perhaps... $ apt-get install gcc # w. appropriate sources.list? leo
Re: [DOCS] Documentation tools
On 6 Mar 2004, at 05:31, Robert Spier wrote: [...] The problem isn't today. It's the trend and next month, when someone decides they need to add some other module, and has a precedent to follow. Then, suddenly we end up with 30 different modules included in our distribution, each one changed slightly from the CPAN one. Dual-lifed modules that live with perl5 are hard enough. I shoved Pod::Simple in because I had problems with the Pod modules in the Perl distribution and the people on pod-people assured me Pod::Simple was the way to go. It was the soft option, i wanted people to be able to build the html docs easily, and I took the existence of the other modules in lib as examples of how to go about it. So, yes, precedent is the problem. Which is why I'd prefer if we could decide what the rule is and apply it to Pod::Simple etc* now, so that it sets the correct precedent. I have held off modifying it, so that it can be removed if necessary. Also, Dan, is it inherently bad to to install perl modules off the 'net, or, just bad for Parrot's config to do it? Would it be acceptable for write_docs.pl to do it? Or, do you mean that the distribution has to be complete in itself, so that it can be installed off a cd on a network-less box and run? Lastly, if we use Leo's prominent notes approach, is that note in the end not just going to be: To install the additional Perl modules required by Parrot run the following command in a shell: perl -MCPAN -e 'CPAN::Shell-install(Parrot::Bundle) Mike [*] Class::Struct has been patched to work with 5.005_03. Digest::Perl::MD5 is unmodified except where I changed the bang perl line. Parse::Parse::RecDescent has been modified for perl6. Pod::Simple unmodified. Test::More, only Test::Builder has been modified. Text::Balanced is unmodified.
Re: Compile-time undefined sub detection
Austin Hastings writes:
Perhaps this is one of those places where properties can help. Instead of
having BEFORE, REALLY_BEFORE, NO_I_MEAN_REALLY_BEFORE, DONE, MOSTLY_DONE,
PARTIALLY_DONE, WELL_DONE, DONE_AND_PROCESS_SPACE_ALMOST_RECLAIMED, etc., we
could simply use some ordering properties:
# Each broad class of upcased block is an execution group. The entries
# in each execution group are not guaranteed to run in any particular order,
# and in fact may run in parallel on a multithreaded perl.
Would you guys cut that out! Nothing's running in parallel unless I
tell it to! Or peraps, Nothing's running in parallel if I tell it not
to! In either case, it could be an easy, global pragma overridable
locally[1].
If I'm printing debug messages during compilation, say:
BEGIN {
print Before load\n;
}
use SomePackage;
BEGIN {
print After load\n;
}
I don't want to be getting:
BefAfter load
ore load
Obviously this is a pathological case, due to the restriction
immediately below, but you can extrapolate to more complex things.
# However, blocks in the same source file are guaranteed to run in order of
# occurrence. (Since they're catenated, basically.)
#
# Thus, all BEGIN blocks in a file are effectively catenated and added to
# an overall BEGIN execution group. All the separate BEGIN entries have
# the same initial priority(10), so they will run in whatever order suits
# the P6 runtime.
#
# The Cgo property introduces changes to the execution group and/or
# priority of the block in question. (Note that different priorities may
# be attached to different blocks within the same file. Doing so creates
# separate execution bundles, and breaks any guarantees about order of
# execution.)
#
package OtherPackage;
BEGIN will go first {
print first!;
}
And what's with all the weird notation? Perl 6 naturally supports this
without adding new syntax:
BEGIN :first {...}
BEGIN :priority(5) {...}
I trust that these pairs will be somehow moved into their pair position
after the block by Perl, since named args have to come after positional
args. There are a lot of functions that take blocks, and writing:
BEGIN {
print I am here: [ ;
print(
@data == map { .join(',') }
== join ';');
print ]\n;
} :first;
Seems to horribly violate end weight.
package SomePackage;
BEGIN will go after OtherPackage::BEGIN {
print Second!;
}
END will go priority 5 {
print End block with early priority;
}
package ThirdPackage;
END will go group BEGIN before SomePackage::BEGIN {
print I feel really out of place!;
}
Comment?
As far as the execution groups, no, I don't think so. In particular,
because I want:
use SomePackage;
BEGIN {
SomePackage::foo();
}
to work without doing some unnecessarily verbose encantation on that
BEGIN.
On the other hand, using a flag to indicate that you want a particular
END to be [one of] the very last may be the right way to go. It's
uncommon enough that the people who need it will be more than willing to
look it up.
Luke
[1] And that's really just to make those happy who are efficiency-crazy.
I have a strong aversion to automatic threading, and I don't care if it
takes more than one line to put it in. In any case, I want control of
my threads, otherwise my sweatshirt's going to come out raveled.
RE: Compile-time undefined sub detection
-Original Message-
From: Luke Palmer [mailto:[EMAIL PROTECTED]
Austin Hastings writes:
# Each broad class of upcased block is an execution group. The entries
# in each execution group are not guaranteed to run in any
particular order,
# and in fact may run in parallel on a multithreaded perl.
Would you guys cut that out! Nothing's running in parallel unless I
tell it to! Or peraps, Nothing's running in parallel if I tell it not
to! In either case, it could be an easy, global pragma overridable
locally[1].
True. But in a potentially-parallel environment, it's good to specify expected
behavior. In this case, the expected behavior is such that if I say
perl6 -P (or --parallel) myscript.p6
I know what the result will be, because the nice man on p6language specified it. And
if that never happens, well, the spec didn't hurt anyone.
# Thus, all BEGIN blocks in a file are effectively catenated
and added to
# an overall BEGIN execution group. All the separate BEGIN
entries have
# the same initial priority(10), so they will run in whatever
order suits
# the P6 runtime.
#
# The Cgo property introduces changes to the execution group and/or
# priority of the block in question. (Note that different priorities may
# be attached to different blocks within the same file. Doing so creates
# separate execution bundles, and breaks any guarantees about order of
# execution.)
#
package OtherPackage;
BEGIN will go first {
print first!;
}
And what's with all the weird notation? Perl 6 naturally supports this
without adding new syntax:
BEGIN :first {...}
BEGIN :priority(5) {...}
That's why we pay you, Luke -- to keep up with the syntax. :-)
(Actually, Outlook seems to have transmogrified my guillemets into angle brackets. I
find that quite frustrating -- I think I'd rather have them appear to everyone else as
Korean spam than as incorrect ascii. So much for Office ServicePack 3...)
I trust that these pairs will be somehow moved into their pair position
after the block by Perl, since named args have to come after positional
args. There are a lot of functions that take blocks, and writing:
BEGIN {
print I am here: [ ;
print(
@data == map { .join(',') }
== join ';');
print ]\n;
} :first;
Seems to horribly violate end weight.
Ayup.
package SomePackage;
BEGIN will go after OtherPackage::BEGIN {
print Second!;
}
END will go priority 5 {
print End block with early priority;
}
package ThirdPackage;
END will go group BEGIN before SomePackage::BEGIN {
print I feel really out of place!;
}
Comment?
As far as the execution groups, no, I don't think so. In particular,
because I want:
use SomePackage;
BEGIN {
SomePackage::foo();
}
to work without doing some unnecessarily verbose encantation on that
BEGIN.
Who says you need verbosity? The default behavior will dwym, natch. The execution
grouping and prioritization and other stuff, which those-who-live-in-compiler-land
understand better than I ever hope to, are where the verbosity goes.
If you want after p6 reads the end of file but before the final reduction, well,
there's an execution group for that. And if you want after the reduction but before
peephole optimization, you're in luck. And if you want I'm not sure when, but it
should be just before the BEGIN block from this other module, we can do that, too.
And there's not an entire page of uppercase names that I have to thumbtack to my
cubicle wall, since I can never remember this crap. Instead, we stay with BEGIN and
END for compiler-phase stuff, and then immediately switch to better ways of thinking
about this stuff, like at object instantiation, at destruction, which are actually
data-related.
On the other hand, using a flag to indicate that you want a particular
END to be [one of] the very last may be the right way to go. It's
uncommon enough that the people who need it will be more than willing to
look it up.
My thought, exactly.
Luke
=Austin
A Perl Task - Benchmarking
I'd a short look at perlbench from CPAN. This inspired me to the following idea: examples/benchmarks/* has a bunch of programs e.g. oo1.pasm oo1.pl oo1.py stress.pasm stress.pl ... Now like perlbench is able to compare run times of different perl versions, the goal of this task is to provide a script that compares different interpreters and finally spits out: Parrot-j Parrot-C PerlPython Ruby oo1 100%103% 75% 50% - mops 100%200% 4% stress ... - - or some such. To simplify the task, we could of course move used tests into a separate directory. Unavailable interpreters (or missing scripts for that language) are just skipped. Any takers? leo
[perl #27469] [PATCH] Use named constants in iterator.pod
# New Ticket Created by Bernhard Schmalhofer # Please include the string: [perl #27469] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=27469 Hi, this patch is just a little documentation update in 'docs/iterator.pod'. Now named constants are used for setting up the iterator in the examples. There was even a little bug, .ITERATE_FROM_END is no longer 3, but 4. There is now also a PIR test in 't/pmc/iter.t'. CU, Bernhard -- /* [EMAIL PROTECTED] */ +++ NEU bei GMX und erstmalig in Deutschland: TV-geprfter Virenschutz +++ 100% Virenerkennung nach Wildlist. Infos: http://www.gmx.net/virenschutz iterator_20040306.patch Description: Binary data
Re: [perl #27469] [PATCH] Use named constants in iterator.pod
Hi, On Saturday 06 March 2004 13:55, Bernhard Schmalhofer wrote: # New Ticket Created by Bernhard Schmalhofer # Please include the string: [perl #27469] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=27469 Hi, this patch is just a little documentation update in 'docs/iterator.pod'. Now named constants are used for setting up the iterator in the examples. This file is automatically generated from classes/iterator.pmc There was even a little bug, .ITERATE_FROM_END is no longer 3, but 4. There is now also a PIR test in 't/pmc/iter.t'. CU, Bernhard jens
[perl #27465] [PATCH] Library to access configuration info
# New Ticket Created by Brent Dax
# Please include the string: [perl #27465]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=27465
The attached patch creates a Parrot-level library similar to Parrot::Config.
There are three components to this:
1. A .pasm file, generated at Configure time and run at make time
(just after $(TEST_PROG) is built), which creates a PerlHash and
freezes it to...
2. A file, Flibrary/config.fpmc (for Frozen PMC), which is usually
accessed by...
3. An IMCC library, Flibrary/config.imc, which contains a
subroutine to open, unfreeze, and return the configuration.
This approach has two benefits:
1. The configuration data is always for the *current* machine, rather
than the machine on which Fconfig.imc was assembled/linked in.
2. It avoids bloating bytecode files that use Fconfig.imc.
Flibrary/config.imc and Fconfig/gen/config_pm/config_lib.in are the
only new files added to CVS; Fconfig/gen/config_pm.pl,
Fconfig/gen/makefiles/root.in, and FMANIFEST are also touched.
There are no tests because I don't know where to put them.
One potentially controversial aspect of this patch is that it means that
Parrot is invoked during the make process, before it's been tested. I
don't see any easy way around this, short of re-implementing PMC
freezing in Perl 5, allowing Configure to write Fconfig.fpmc itself.
Fconfig.fpmc does not contain all of the configuration data--Parrot
seems to segfault when fed some of the really long values[1], so it
doesn't include any entry with a newline in it. On my Debian box,
Fconfig.fpmc weighs in at around 15k.
As currently implemented, you must be in Flibrary/'s parent directory
(i.e. the Parrot root directory) to make use of Flibrary/config.imc.
I'm not sure what I can do about that yet.
The following PIL will dump your entire configuration to stdout:
.sub _main
.local PerlHash config
config=_config()
_dumper(config, config)
end
.end
.include library/config.imc
.include library/dumper.imc
I'm going to bed now. Good night.
[1] Said really long values are cases where someone inserted a key
into the Configure data for the sole purpose of interpolating it into a
particular file--a Configure no-no. I may rant on this practice in the
near future.
--
Brent Dax Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
? config/gen/config_pm/config_lib.in
? library/config.imc
Index: MANIFEST
===
RCS file: /cvs/public/parrot/MANIFEST,v
retrieving revision 1.580
diff -u -r1.580 MANIFEST
--- MANIFEST6 Mar 2004 07:35:18 - 1.580
+++ MANIFEST6 Mar 2004 11:09:14 -
@@ -110,6 +110,7 @@
config/gen/config_h.pl[]
config/gen/config_h/config_h.in []
config/gen/config_pm.pl []
+config/gen/config_pm/config_lib.in[]
config/gen/config_pm/Config_pm.in []
config/gen/core_pmcs.pl []
config/gen/feature_h.pl []
@@ -2302,6 +2303,7 @@
lib/Test/Simple.pm[devel]
lib/Text/Balanced.pm [devel]
libnci.def[]
+library/config.imc[devel]
library/dumper.imc[devel]
library/libpcre.imc [devel]
library/ncurses.declarations [devel]
Index: config/gen/config_pm.pl
===
RCS file: /cvs/public/parrot/config/gen/config_pm.pl,v
retrieving revision 1.3
diff -u -r1.3 config_pm.pl
--- config/gen/config_pm.pl 26 Feb 2004 00:43:05 - 1.3
+++ config/gen/config_pm.pl 6 Mar 2004 11:09:17 -
@@ -19,7 +19,7 @@
use Parrot::Configure::Step;
use Data::Dumper;
-$description=Writing Parrot::Config module...;
+$description=Writing configuration data modules for Perl 5 and Parrot...;
@args=();
@@ -36,6 +36,38 @@
close IN or die Can't close Config_pm.in: $!;
close OUT or die Can't close Config.pm: $!;
+
+ open(IN, config/gen/config_pm/config_lib.in) or die Can't open config_lib.in:
$!;
+ open(OUT, config_lib.pasm) or die Can't open config_lib.pasm: $!;
+
+ print OUT END;
+# Generated by config/gen/config_pm.pl
+# This file should be the last thing run during
+# the make process, after Parrot is built.
+END
+
+ while(IN) {
+if(/HERE/) {
+ my $k;
+ for $k(Configure::Data-keys) {
+ my $v=Configure::Data-get($k);
+ if(defined $v) {
+ next if $v =~ /\n/;
+ $v =~ s/([\\])/\\$1/g;
+
Re: [perl #27469] [PATCH] Use named constants in iterator.pod
Bernhard Schmalhofer [EMAIL PROTECTED] wrote: this patch is just a little documentation update in 'docs/iterator.pod'. Now named constants are used for setting up the iterator in the examples. Thanks, applied. leo
Re: [perl #27469] [PATCH] Use named constants in iterator.pod
Jens Rieks [EMAIL PROTECTED] wrote: Hi, On Saturday 06 March 2004 13:55, Bernhard Schmalhofer wrote: this patch is just a little documentation update in 'docs/iterator.pod'. This file is automatically generated from classes/iterator.pmc Actually the patch is against docs/pmc/iterator.pod, which is fine. leo
Magic blocks (was: Compile-time undefined sub detection)
Okay you guys, you're running away from one kind of madness and
proposing various other kinds of madness in its place. Mostly you're
confusing what should be easy and what should be possible.
First a note about cleanup dependencies. In general, these should be
driven by the structure of the data, not the structure of the program.
If you want to make sure one piece of data is cleaned up before
another, make sure there's a reference that enforces that.
That's the principle on cleanup. It's also, more or less, the
principle on initialization. What these various blocks are obscuring
from your calculations is that there is a data structure for each of
these sets of queued events, and as long as there's a way to name such
a queue, it's not necessary to access it through the official block
name. It would be nice if the property that stores a particular
queue has a related name, of course. But for fancy things, we don't
have to add options to the syntax of blocks in order to manipulate
these queues. If you want to make sure you're last in the END queue,
just manipulate that queue.
We also don't need a new abstraction like execution group, unless by
that you simply mean one of these callback queues. We particularly
don't need to orthogonalize all the names and make them equally
obfuscational. This is very much a place where easy things should
be easy, and hard things should be difficult.
So here's the ruling. We don't need any special names for hacking
on the queue in another module. So CHECK means UNITCHECK, always.
There's no MAINCHECK name. If you want to do something fancy to
the main program's CHECK list or END list, then at export time,
modify the queue contained in Main's CHECKLIST property or ENDLIST
property. If you really, really, really, want something to run last,
then install something into Main::ENDLIST that looks to see whether
there's anything after it when it gets triggered, and if so, reinstalls
itself at the end again. And then we can have the entertaining
situation of two or more modules both playing leapfrog trying to
be last. Perhaps something fancy with priorities can be worked out,
but if so, that's the domain of direct queue manipulation routines.
It has nothing to do with the easy-to-use block declarations, which
have to remain simple interfaces, or there's no point to them.
So we're back to the standard four phase oriented blocks:
my @x will begin {...} # at BEGIN time
my @x will check {...} # at CHECK time (redefined to unit check)
my @x will init {...} # at INIT time
my @x will end {...}# at END time
plus these four block oriented blocks:
my @x will pre {...}# at PRE time (return boolean for DBC)
my @x will enter {...} # at ENTER time (block entry)
my @x will leave {...} # at LEAVE time (block exit)
my @x will post {...} # at POST time (return boolean for DBC)
plus three specialty times for things with lifetimes not related to
blocks:
state @x will first {...} # at FIRST time (first time through)
has @.x will build {...}# at BUILD time (object init time)
has @.x will destroy {...} # at DESTROY time (object final time)
There's no LAST corresponding to FIRST because you can't generally
tell when you've called a block for the very last time. (If there
is a LAST, it'd be loop related, but then FIRST and LAST aren't
really opposites, and it'd duplicate LEAVE anyway.)
Oh, and I guess we still have the two leave variants:
my @x will keep {...} # at LEAVE time, if leaving successfully
my @x will undo {...} # at LEAVE time, if leaving unsuccessfully
There's also, in a sense, a catch time, but you can't have more than
one of those, so there's no CATCHLIST property to modify. If you're
trying to add semantics to your CATCH, you're probably wanting an
undo instead.
A good case can be made for all of those--unless you happen to be
against transactional programming, or design by contract. Or state
variables, or objects, or blocks, or modules... :-)
Larry
Re: Magic blocks (was: Compile-time undefined sub detection)
Oh, I accidentally left NEXT out of my canonical list. We do need to have the equivalent to Perl 5's continue. Larry
Re: A Perl Task - Benchmarking
Hi Leo, Attached is a quick'n dirty parrotbench, instead of a complicated test harness it uses bash to make time measurements, so that new languages are very simple to add. Currently it's just a proof of concept but if you like it i will make a better version with pretty printing, extended reports and stuff. Here's an example run: parrotperl python ruby addit 8.469 7.379 - - arriter- 1.657 - - bench_newp 1.827 - - - fib - 0.594 - - freeze 0.783 1.65 - - gc_alloc_new 0.191 -- - gc_alloc_reuse 4.068 - - - gc_generations 6.363 - - - gc_header_new 1.168 - - - gc_header_reuse 5.772 - - - gc_waves_headers 1.302 - - - gc_waves_sizeable_data1.074 - - - gc_waves_sizeable_headers 3.702 - - - oo1 3.571 1.189 0.689 - primes 27.991 383.851- - primes2 17.325 - 44.379 - primes2_p 29.753 - - - prop0.14 - - - shared_ref 0.55211.563 - - stress 1.988 0.905 - - stress1 27.53917.312 - - stress23.908 3.440 - - stress3 19.050 - - - utf8 0.13 - - - vpm- 40.057 - - Cheers, Sebastian Leopold Toetsch wrote: I'd a short look at perlbench from CPAN. This inspired me to the following idea: examples/benchmarks/* has a bunch of programs e.g. oo1.pasm oo1.pl oo1.py stress.pasm stress.pl ... Now like perlbench is able to compare run times of different perl versions, the goal of this task is to provide a script that compares different interpreters and finally spits out: Parrot-j Parrot-C PerlPython Ruby oo1 100%103% 75% 50% - mops 100%200% 4% stress ... - - or some such. To simplify the task, we could of course move used tests into a separate directory. Unavailable interpreters (or missing scripts for that language) are just skipped. Any takers? leo parrotbench.patch.gz Description: application/tgz
