Re: Improvements to execution and loading of bytecode programs and modules
On Wed, 2004-11-03 at 20:08, Milscvaer wrote: > First, Perl ought to allow bytecode, already compiled, > to be loaded via a bytecode equivelant to eval(), if > this cannot be done already. Please read through the design documents: http://dev.perl.org/perl6/ Many of these ideas have come up already. -- c
[PATCH] dynclass build
Attached patch makes building in the dynclass ghetto a bit less
inhospitable...
- Sam Ruby
? pyint.imc
? test.imc
? config/gen/makefiles/.dynclasses_pl.in.swp
? dynclasses/pyboolean.pmc
? dynclasses/pydict.pmc
? dynclasses/pyfloat.pmc
? dynclasses/pyfunc.pmc
? dynclasses/pyint.pmc
? dynclasses/pylist.pmc
? dynclasses/pymodule.pmc
? dynclasses/pynone.pmc
? dynclasses/pyobject.pmc
? dynclasses/pystring.pmc
? dynclasses/pytuple.pmc
? t/dynclass
Index: config/gen/makefiles/dynclasses.in
===
RCS file: /cvs/public/parrot/config/gen/makefiles/dynclasses.in,v
retrieving revision 1.8
diff -u -r1.8 dynclasses.in
--- config/gen/makefiles/dynclasses.in 12 Oct 2004 09:00:16 - 1.8
+++ config/gen/makefiles/dynclasses.in 4 Nov 2004 05:15:59 -
@@ -14,10 +14,10 @@
BUILD = ${perl} build.pl
all :
- $(BUILD) generate $(PMCS)
- $(BUILD) compile $(PMCS)
- $(BUILD) linklibs $(PMCS)
- $(BUILD) copy --destination=$(DESTDIR) $(PMCS)
+ @$(BUILD) generate $(PMCS)
+ @$(BUILD) compile $(PMCS)
+ @$(BUILD) linklibs $(PMCS)
+ @$(BUILD) copy --destination=$(DESTDIR) $(PMCS)
clean :
$(RM_F) *.c *.h *$(LOAD_EXT) *.dump lib-* *$(O)
Index: config/gen/makefiles/dynclasses_pl.in
===
RCS file: /cvs/public/parrot/config/gen/makefiles/dynclasses_pl.in,v
retrieving revision 1.3
diff -u -r1.3 dynclasses_pl.in
--- config/gen/makefiles/dynclasses_pl.in 14 Oct 2004 09:40:12 - 1.3
+++ config/gen/makefiles/dynclasses_pl.in 4 Nov 2004 05:15:59 -
@@ -43,9 +43,11 @@
my ($group_files, $pmc_group) = gather_groups(@pmcs);
while (my ($group, $pmcs) = each %$group_files) {
-my $pmcfiles = join(" ", map { "$_.pmc" } @$pmcs);
-run("$PMC2C --library $group --c $pmcfiles")
- or die "pmc2c library creation failed ($?)\n";
+my @pmcfiles = map { "$_.pmc" } @$pmcs;
+if (needs_build("$group.c", @pmcfiles)) {
+run("$PMC2C --library $group --c " . join(" ",@pmcfiles))
+ or die "pmc2c library creation failed ($?)\n";
+}
}
} elsif ($mode eq 'compile') {
my ($group_files, $pmc_group) = gather_groups(@pmcs);
@@ -123,7 +125,7 @@
my $target_mod = modtime($target)
or return 1;
for my $source (@sources) {
-return 1 if modtime($source) >= $target_mod;
+return 1 if modtime($source) > $target_mod;
}
return 0;
}
@@ -134,8 +136,6 @@
if (needs_build("$pmc.dump", "$pmc.pmc")) {
run("$PMC2C --dump $pmc.pmc")
or die "pmc2c dump failed ($?)\n";
-} else {
-print "$pmc.dump is up to date\n";
}
}
@@ -155,6 +155,9 @@
run(compile_cmd("$dest_stem$O", "$src_stem.c"))
or die "compile $src_stem.c failed ($?)\n";
}
+else {
+1;
+}
}
sub partial_link {
@@ -164,4 +167,7 @@
run(partial_link_cmd("$group$LOAD_EXT", @sources))
or die "partial link $group$LOAD_EXT failed ($?)\n";
}
+else {
+1;
+}
}
Index: lib/Parrot/Pmc2c.pm
===
RCS file: /cvs/public/parrot/lib/Parrot/Pmc2c.pm,v
retrieving revision 1.48
diff -u -r1.48 Pmc2c.pm
--- lib/Parrot/Pmc2c.pm 1 Nov 2004 12:28:49 - 1.48
+++ lib/Parrot/Pmc2c.pm 4 Nov 2004 05:16:03 -
@@ -1577,6 +1577,7 @@
my %opt = %{$self->{opt}};
my $library = $opt{library} ? 1 : 0;
+if (!$library) {
while (my @fc = each %{$self->{pmcs}}) {
my ($file, $generator) = @fc;
print Data::Dumper->Dump([$generator]) if $opt{debug} > 1;
@@ -1600,7 +1601,8 @@
close C;
}
-if ($library) {
+}
+else {
my $hout = $self->gen_h($opt{library});
my $h = "$opt{library}.h";
print "Writing $h\n" if $opt{verbose};
Improvements to execution and loading of bytecode programs and modules
First, Perl ought to allow bytecode, already compiled, to be loaded via a bytecode equivelant to eval(), if this cannot be done already. This would work the same way as executing Perl code via eval(). For instance, perhaps through a new bceval function: bceval($bytecode);. In addition, Perl should make sure to allow users to produce bytecode copies of programs and modules, and allow modules compiled into bytecode to be easily loaded into a perl program. I propose allowing a user to create bytecode copies of a module, and saving the bytecode under a filename with a .pmb extension, such as module.pmb, which would be a compiled copy of module.pm. If placed in the same directory as module.pm in the path, Perl will load it instead of module.pm. Perl would first look for module.pmb, and if it couldnt find that, search for module.pm., if the user types use module; in the their program. Perl programs could compiled into bytecode could be given the .plb extenstion, like program.plb. Allowing modules to be compiled into bytecode would save compile time for very large programs. __ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com
Re: Solicitation of Ideas for Performance Statistics and Graphs
On Wed, 3 Nov 2004 12:52:26 -0800 (PST), Joshua Gatcomb <[EMAIL PROTECTED]> wrote: [snip] > What we would like to do is determine if what we have > done so far is sufficient or, if not, what specifically > people would like to see. Some of our unimplemented > ideas so far are: > 1. Include the computed goto core > 2. Summary of results over N week(s)/month(s) > 3. Provide user form for dynamic results > If people would like this, they also need to > indicate what the form should provide: > (benchmark name, date, executable, etc) > 4. Provide HTML table of data for some/all of graphs > 5. Provide links for people to work locally > A. A db schema/structure dump so people can > collect statistics on other architectures > B. Source code > C. daily db dump > > If you would like to see any of these ideas > implemented, or you have some of your own - please > respond to this on the list. [snip] I think this is a really great idea. I made some picture graphs for the register allocation stuff myself, and tried to evangelize the idea a little, but you guys have introduced a useful tool that can help developers see the results of their work. Now, one can anxiously check the results after a checkin and see if a desired speedup has occurred or not. Great job. To make this idea, and philosophy, pay off, we need (3&5B)++. I think what you're suggesting is to provide the software to others, so they can run their own tests. That's great, but I'd rather create the test, check it in, and modify a master config file, that says which tests will run. The administrator, of course would have to approve the patch. For long tests, they don't have to be in the nightly test suit, but could be run by name, by the user. For number 4, I'd say that a comma separated values (CSV) file would be most useful. Then users can view and manipulate the data themselves. Various spreadsheets have nice capabilities for this, and of course certain scripting languages can parse this kind of data well. So I hear, at least :). Once again, great idea, great job! ~Bill
Re: Closures and subs
Klaas-Jan Stol wrote: Hello, I've been playing with closures and subs but I have a little bit of trouble with those. I'm a bit confused by all different flavours of syntax, I've been trying to read and understand all documents concerning this subject, the most useful was reading the test scripts. However, that is PASM, and I like PIR better :-). A general question is: what syntax should one use in what context? (I understand that PCC should be used whenever one wants to interact with other languages. Also, calling functions can be done in many ways) A more specific question is this: I'm trying to create a closure, and I think I've implemented this code (it's lua code, but I'm not sure if it's 100% correct, anyway, I'm trying to get a feeling for how one should translate this). So, actually I have 2 questions; (1): did I translate the function below correctly (I think the Lua syntax won't be a problem, it's quite straightforward). (2): what is causing my strange result (see below). [snip] # foo(q) .arg q $P0() Try this instead: $P0(q) - Sam Ruby
Closures and subs
Hello, I've been playing with closures and subs but I have a little bit of trouble with those. I'm a bit confused by all different flavours of syntax, I've been trying to read and understand all documents concerning this subject, the most useful was reading the test scripts. However, that is PASM, and I like PIR better :-). A general question is: what syntax should one use in what context? (I understand that PCC should be used whenever one wants to interact with other languages. Also, calling functions can be done in many ways) A more specific question is this: I'm trying to create a closure, and I think I've implemented this code (it's lua code, but I'm not sure if it's 100% correct, anyway, I'm trying to get a feeling for how one should translate this). So, actually I have 2 questions; (1): did I translate the function below correctly (I think the Lua syntax won't be a problem, it's quite straightforward). (2): what is causing my strange result (see below). function main() local p = 123; local q = 345; foo(q); foo(q); function foo(a) # nested function, it does have access to p in "main" print(p); p = p + p; print(typeof(a)); print(a); end end I would translate this to this PIR code: .sub _main new_pad 0 # local p = 123 .local pmc p p = new .PerlInt p = 123 store_lex 0, "p", p # local q = 345 .local pmc q q = new .PerlInt q = 345 store_lex 0, "q", q newsub $P0, .Closure, _foo # foo(q) .arg q $P0() # foo(q) .arg q $P0() end .end .sub _foo .param pmc a # print(p); find_lex $P0, "p" print $P0 # p = p + p; $P0 = $P0 + $P0 store_lex "p", $P0 # print(typeof(a)); $S0 = typeof a print $S0 # # print(a); print a # ERROR! .end My problem with the last 2 statements is: - the statement print(typeof(a)); print "SArray", which I don't understand. - "print a" causes an error: "get_string() not implemented in SArray" ( I know that is because of a being an SArray) I know there are more important issues at the moment, but if someone could spare a moment, that'd be great. I'm trying to get a grip on function syntax. Regards, Klaas-Jan Stol
Re: Solicitation of Ideas for Performance Statistics and Graphs
At 5:25 PM -0500 11/3/04, Matt Diephouse wrote: On Wed, 3 Nov 2004 16:04:38 -0500, Matt Fowles <[EMAIL PROTECTED]> wrote: I think it would be really cool if commits that had a significant increase or descrease in speed would be flagged. Possibly just a section of the page could be a table with commit dates and the percent effect they had. This table would not contain all commits dates, but only the most recent N that caused a greater than 5% change in speed. It would be a LOT of work to do this for every commit. We're currently running once per day, which narrows it sufficiently. It's also tough to tell exactly what a commit is, with CVS. It doesn't have the concept of multi-file commits, so if I check in twenty files at once it's viewed as twenty commits. Which is one of CVS's issues. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Solicitation of Ideas for Performance Statistics and Graphs
On Wed, 3 Nov 2004 16:04:38 -0500, Matt Fowles <[EMAIL PROTECTED]> wrote: > I think it would be really cool if commits that had a significant > increase or descrease in speed would be flagged. Possibly just a > section of the page could be a table with commit dates and the percent > effect they had. This table would not contain all commits dates, but > only the most recent N that caused a greater than 5% change in speed. It would be a LOT of work to do this for every commit. We're currently running once per day, which narrows it sufficiently. I was kicking around an idea like this, but I was thinking only to protect from slow downs. The basic idea was to check whether there had been a slowdown of X percent in the last N days. If so, it'd ping the list with a message describing when and where the speedup/slowdown happened. It'd also be possible to create a graph for these N days. With multiple rules, this could be pretty neat: o Detect any change of 25% in the past 60 days o Detect any change of 50% in the past 2 days o Detect any change of 15% in the past 3 months The idea being that various scenarios could be caught. For instance, the recent disablement of JIT would get caught and a message would be sent to the list. > The idea being that this would provide an easy way to sync to > particular revision for people playing the optimization game without > having to guess based on the graphs. Combining this with the N-weekly/monthly performance summaries idea would let you know when a big (or small) speed change happened. -- matt
Re: Solicitation of Ideas for Performance Statistics and Graphs
All~ I think it would be really cool if commits that had a significant increase or descrease in speed would be flagged. Possibly just a section of the page could be a table with commit dates and the percent effect they had. This table would not contain all commits dates, but only the most recent N that caused a greater than 5% change in speed. The idea being that this would provide an easy way to sync to particular revision for people playing the optimization game without having to guess based on the graphs. Matt On Wed, 3 Nov 2004 12:52:26 -0800 (PST), Joshua Gatcomb <[EMAIL PROTECTED]> wrote: > All: > Matt Diephouse and I spent the majority of our time > coming up with a flexible design and gathering > historical statistics. We didn't spend a lot of time > in how to present the data since everybody has their > own opinion (including us). > > What we would like to do is determine if what we have > done so far is sufficient or, if not, what > specifically > people would like to see. Some of our unimplemented > ideas so far are: > > 1. Include the computed goto core > 2. Summary of results over N week(s)/month(s) > 3. Provide user form for dynamic results > If people would like this, they also need to > indicate what the form should provide: > (benchmark name, date, executable, etc) > 4. Provide HTML table of data for some/all of graphs > 5. Provide links for people to work locally > A. A db schema/structure dump so people can > collect statistics on other architectures > B. Source code > C. daily db dump > > If you would like to see any of these ideas > implemented, or you have some of your own - please > respond to this on the list. > > While Matt and I are likely to do some of the work, we > are always open to volunteers as well. In fact, if > this idea generates a lot of buzz, we may cross post > to other Perl forums such as PerlMonks > (http://www.perlmonks.org). This is a perfect way for > non C programmers and those who have no knowledge of > Parrot to still contribute in a meaningful way. > > Cheers > Joshua Gatcomb > a.k.a. Limbic~Region > > __ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > -- "Computer Science is merely the post-Turing Decline of Formal Systems Theory." -???
Solicitation of Ideas for Performance Statistics and Graphs
All: Matt Diephouse and I spent the majority of our time coming up with a flexible design and gathering historical statistics. We didn't spend a lot of time in how to present the data since everybody has their own opinion (including us). What we would like to do is determine if what we have done so far is sufficient or, if not, what specifically people would like to see. Some of our unimplemented ideas so far are: 1. Include the computed goto core 2. Summary of results over N week(s)/month(s) 3. Provide user form for dynamic results If people would like this, they also need to indicate what the form should provide: (benchmark name, date, executable, etc) 4. Provide HTML table of data for some/all of graphs 5. Provide links for people to work locally A. A db schema/structure dump so people can collect statistics on other architectures B. Source code C. daily db dump If you would like to see any of these ideas implemented, or you have some of your own - please respond to this on the list. While Matt and I are likely to do some of the work, we are always open to volunteers as well. In fact, if this idea generates a lot of buzz, we may cross post to other Perl forums such as PerlMonks (http://www.perlmonks.org). This is a perfect way for non C programmers and those who have no knowledge of Parrot to still contribute in a meaningful way. Cheers Joshua Gatcomb a.k.a. Limbic~Region __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Performance Statistics (and Graphs!)
On Wed, 3 Nov 2004 18:30:58 +0100, Jerome Quelin <[EMAIL PROTECTED]> wrote: > What about comparing against perl*, python and ruby? What about it? Many of the benchmarks are parrot only: the gc tests, for example. The others should remain mostly static, unless we do daily checkouts, which is a lot of work, even for parrot. Presumably you can just run the perl, python, and ruby scripts yourself and compare. Unless you're asking for them to be on the graphs? > Nice work, Thanks. -- matt
Re: dor and backwards compat (was Re: [ANNOUNCE] Test::Simple 0.49)
Abigail <[EMAIL PROTECTED]> writes:
>
>No new keywords in perl-5.001
>New in perl-5.002: tied __DATA__ sysopen prototype
>No new keywords in perl-5.003
>New in perl-5.004: __PACKAGE__ sysseek
>New in perl-5.005: qr lock INIT
>New in perl-5.6.0: CHECK our
>No new keywords in perl-5.8.0
> Deleted keywords: LE NE GE EQ GT LT
>New in perl-5.9.1: err
>
>
>While I won't deny 'err' may be used in many existing programs, I doubt
>it's used more than 'lock' was before 'lock' was introduced as a keyword.
But lock keyword is overridden by a sub called lock ;-)
>
>
>
>Abigail
>
>
>
>
>#!/usr/bin/perl
>
>use strict;
>use warnings;
>no warnings qw /syntax/;
>
>my @versions = qw /5.000 5.001 5.002 5.003 5.004 5.005 5.6.0 5.8.0 5.9.1/;
>my $dir = "/home/abigail/Src/perl";
>
>my %keywords;
>foreach my $version (@versions) {
>my $file = "$dir-$version/keywords.h";
>open my $fh => $file or die "open $file: $!\n";
>while (<$fh>) {
>/KEY_(\w+)/ or next;
>$keywords {$version} {$1} = 1;
>}
>}
>
>for (my $i = 1; $i < @versions; $i ++) {
>my %tmp = %{$keywords {$versions [$i]}};
>delete $tmp {$_} for keys %{$keywords {$versions [$i - 1]}};
>if (keys %tmp) {
>print "New in perl-", $versions [$i], ": @{[keys %tmp]}\n";
>}
>else {
>print "No new keywords in perl-", $versions [$i], "\n";
>}
>%tmp = %{$keywords {$versions [$i - 1]}};
>delete $tmp {$_} for keys %{$keywords {$versions [$i]}};
>if (keys %tmp) {
>print " Deleted keywords: @{[keys %tmp]}\n";
>}
>}
>
>__END__
Re: No C op with PMC arguments?
Jerome~ On Wed, 3 Nov 2004 18:33:28 +0100, Jerome Quelin <[EMAIL PROTECTED]> wrote: > Damn, is it a new rule that perl 6 summarizer should be a maths teacher? :-) Actually, as an American I would be a lowly math teacher... ;-) Matt -- "Computer Science is merely the post-Turing Decline of Formal Systems Theory." -???
mod_parrot 0.1
I've just released mod_parrot 0.1. As I noted in my previous post a few weeks ago, it now supports authentication handlers. Other major changes include a testing framework (using Apache::Test), access to Apache constants, and POD documentation. You can download it here: http://www.smashing.org/mod_parrot Maybe one day I'll have a real web page there. :) Enjoy, -jeff
Re: No C op with PMC arguments?
On 04/11/03 11:19 -0500, Matt Fowles wrote: > What gets more fun is raising something (usually e) to a matrix power. > Then you have to do things with the Jordan Connical form and > decompose your matrix into eigenvalues and stuff. On the plus side, > this also allows you to define the sin and cos of a matrix... ::evil > grin:: Damn, is it a new rule that perl 6 summarizer should be a maths teacher? :-) Jérôme -- [EMAIL PROTECTED]
Re: Performance Statistics (and Graphs!)
On 04/11/02 22:10 -0500, Matt Diephouse wrote: > We have collected benchmark data for regular and > optimized builds with and without JIT from June 1st through October. What about comparing against perl*, python and ruby? Nice work, Jerome -- [EMAIL PROTECTED]
Re: No C op with PMC arguments?
Dan Sugalski wrote: At 11:04 AM -0500 11/3/04, Sam Ruby wrote: This omission seems odd. Was this intentional? Nope. A single pow_p_p_p op backed by a (non-MMD) vtable entry would make it easier to support code like the following: def f(x): return x**3 print f(3), f(2.5) Yeah, it would. I know I'm going to regret asking, but... any reason *not* to make it MMD? (Though I have no idea what happens if you square a matrix) No objection to a MMD, just attempting to propose the "simplest thing that can possibly work". Also, there are all sorts of other opcodes that might be worth discussing, like pow_p_p_ic. - Sam Ruby P.S. Yes, squaring a matrix is valid operation. As would be squaring a complex number.
Re: No C op with PMC arguments?
Dan~ On Wed, 3 Nov 2004 11:09:49 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote: > Yeah, it would. I know I'm going to regret asking, but... any reason > *not* to make it MMD? (Though I have no idea what happens if you > square a matrix) Squaring a matrix is easy (so long as it is square). A^2 == A * A. What gets more fun is raising something (usually e) to a matrix power. Then you have to do things with the Jordan Connical form and decompose your matrix into eigenvalues and stuff. On the plus side, this also allows you to define the sin and cos of a matrix... ::evil grin:: Matt -- "Computer Science is merely the post-Turing Decline of Formal Systems Theory." -???
Re: No C op with PMC arguments?
At 11:04 AM -0500 11/3/04, Sam Ruby wrote: This omission seems odd. Was this intentional? Nope. A single pow_p_p_p op backed by a (non-MMD) vtable entry would make it easier to support code like the following: def f(x): return x**3 print f(3), f(2.5) Yeah, it would. I know I'm going to regret asking, but... any reason *not* to make it MMD? (Though I have no idea what happens if you square a matrix) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
No C op with PMC arguments?
This omission seems odd. Was this intentional? A single pow_p_p_p op backed by a (non-MMD) vtable entry would make it easier to support code like the following: def f(x): return x**3 print f(3), f(2.5) - Sam Ruby
Re: Performance Statistics (and Graphs!)
> At 11:08 PM -0800 11/2/04, Jeff Clites wrote: > >On Nov 2, 2004, at 7:10 PM, Matt Diephouse wrote: > > > >>Joshua Gatcomb and I have been working a little > under a week to set up > >>an automated build system for parrot that tracks > performance (with > >>help from Dan's box). We have collected benchmark > data for regular and > >>optimized builds with and without JIT from June > 1st through October. > >> > >>With some help from Perl and GD, we've up several > pages of graphs: > >> > >> http://www.sidhe.org/~timeparrot/graphs/ > >> > >>Both the build process and the creation of the > graphs will (hopefully) > >>be run daily (automated). There are plans to do > some other things with > >>the data as well (some notification scripts). > > > >Very cool. A useful thing to do would be to > preserve all of the > >builds, so that newly-created benchmarks could be > back-filled. (That > >way, if we realize that we've not been effectively > testing > >something, we can devise an appropriate benchmark, > and evaluate the > >consequences of past design changes against it.) > Actually, we already thought of that. We were thinking more along the lines of people wanting to check other run-time cores (such as computed goto). To save on disk space, the executables are stripped and bzip2'd, but we can go back easily to any previous point in the 5 month window if we want. Cheers Joshua Gatcomb a.k.a. Limbic~Region __ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com
Re: Are we done with big changes?
Garrett Goebel <[EMAIL PROTECTED]> wrote: > Dan Sugalski wrote: >>Piers Cawley wrote: >>> >>>Release candidate? >> >>What, think this warrants a 0.1.2 release? I'm not so sure about that. >>It's not that big a deal... > Weren't you the one calling them big changes? Tagging CVS can be helpful before committing bigger changes. Its independent from a release. > What ever happened to: "release early, release often"? The last gap was an exception. We'll release in an approximately quarterly interval. Last release is just 1 month ago. > Garrett leo
Re: [perl #32270] parrot -t leaks like a sieve
At 11:57 AM +0100 11/3/04, Leopold Toetsch wrote: Dan Sugalski <[EMAIL PROTECTED]> wrote: Throwing the trace switch on makes parrot leak. A *lot*. Processes that top out at 100M VSIZE hit 1G or more, which, well... it ain't good. Tracing's slow enough as it is without the added hit of swapping and ever-increasing memory usage. Yep. Tracing is using PIO_eprintf(), which finally is calling Parrot_vsprintf_s(). Around that function call GC was disabled, so no buffer memory got recycled, as the vast majority of buffer allocations is coming from the trace. Fixed. Cool, thanks. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Performance Statistics (and Graphs!)
At 11:08 PM -0800 11/2/04, Jeff Clites wrote: On Nov 2, 2004, at 7:10 PM, Matt Diephouse wrote: Joshua Gatcomb and I have been working a little under a week to set up an automated build system for parrot that tracks performance (with help from Dan's box). We have collected benchmark data for regular and optimized builds with and without JIT from June 1st through October. With some help from Perl and GD, we've up several pages of graphs: http://www.sidhe.org/~timeparrot/graphs/ Both the build process and the creation of the graphs will (hopefully) be run daily (automated). There are plans to do some other things with the data as well (some notification scripts). Very cool. A useful thing to do would be to preserve all of the builds, so that newly-created benchmarks could be back-filled. (That way, if we realize that we've not been effectively testing something, we can devise an appropriate benchmark, and evaluate the consequences of past design changes against it.) That's doable through the joys of timestamped CVS checkouts. (Which is how the graphs were built in the first place) Granted, it hammers the build machine, but... :) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: dor and backwards compat (was Re: [ANNOUNCE] Test::Simple 0.49)
On 2004-11-03, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 03, 2004 at 12:19:08AM +0100, Abigail wrote:
>> While I won't deny 'err' may be used in many existing programs, I doubt
>> it's used more than 'lock' was before 'lock' was introduced as a keyword.
I wouldn't be so sure. I imagine I a lot more people have to deal with
'errors' than they do with 'locks'. I'm one of those people has
production code with a subroutine named 'err' it, and would like to
avoid the hassle of changing that in a number of places.
> Difference between lock() and err() is this.
>
> $ perl5.6.1 -wle 'sub lock { "foo" } print lock'
> foo
> $ bleadperl -wle 'sub lock { "foo" } print lock'
> foo
> $ bleadperl -wle 'sub err { "foo" } print err'
> Ambiguous call resolved as CORE::err(), qualify as such or use & at -e line 1.
> syntax error at -e line 1, at EOF
> Execution of -e aborted due to compilation errors.
This seems like an important difference. It would be nice if my 'err'
routines could keep working, like custom 'lock' routines appeared to.
Mark
--
. . . . . . . . . . . . . . . . . . . . . . . . . . .
Mark StosbergPrincipal Developer
[EMAIL PROTECTED] Summersault, LLC
765-939-9301 ext 202 database driven websites
. . . . . http://www.summersault.com/ . . . . . . . .
RE: Are we done with big changes?
Dan Sugalski wrote: >Piers Cawley wrote: >>Jeff Clites <[EMAIL PROTECTED]> writes: >> >>> On Nov 1, 2004, at 6:14 AM, Dan Sugalski wrote: >>> Because I need to get strings working right, so I'm going to be implementing the encoding/charset library stuff, which is going to cause some major disruptions. >>> >>> Please tag cvs before checking this in. >> >>Release candidate? > >What, think this warrants a 0.1.2 release? I'm not so sure about that. >It's not that big a deal... Weren't you the one calling them big changes? What ever happened to: "release early, release often"? To those lingering on the project's periphery, releases are one of the only measures of the project's vitality that they have. Just look at the new faces that pop in after a release. Who's going to argue that new blood isn't better than old lurkers like myself that have a long track record of well... not much? Garrett -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com garrett at scriptpro dot com
Re: Traceback or call chain
Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 11:16 AM +0100 11/2/04, Leopold Toetsch wrote: > I was thinking something a bit more primitive. Since we can treat the > call chain as an array, we could do: > $S0 = insert_opname_here [0; 'subname'] # Get the current sub name > $S1 = insert_opname_here [1; 'subname'] # Get the caller's sub name > $P1 = insert_opname_here [2; 'pad'] # Get grandparent's pad > We could do the same thing with continuation objects -- access them > as an array and pull parts out, which'd work fine. We don't have opcodes with a keyed on nothing syntax. So 2nd idea: $P2 = getinterp # this exists $P0 = $P2['current_sub'] # aka P0 $P1 = $P2['current_cont']# formerly P1 $P0 = $P2['current_sub', 1] # caller's info $P1 = $P2['current_cont', 1] $S0 = $P0# subname := get_string >>I think having methods is ok for that. It's in no way time critical to >>warrant opcodes. > The one downside to methods is that we need an object, which means > that we've got to instantiate the current continuation. Not really, We can hang these methods off the interpreter too. > ... I'm not sure I'd want to go with > methods here, though -- there's a reasonable chance that the method > code might mess up some of the environmental info in the traceback. That's an argument. OTOH you can't override NCI methods on plain PMCs. The chance of disruption is low. >>When and in which run loop do we update the C[1] ? Only, >>when warnings are enabled or always? > We should always be able to get a sane value out of it. If that means > with the JIT that we have to play some interesting games with line > number metadata sections or something, well... that's OK. It doesn't > have to be cheap, just doable. Ok. I presume "line number" is both HLL and PIR line numbers. To be able to create a precise traceback, we've to update the program counter in the interpreter context, so that we know, what we are executing. Metadata is basically not the problem. We have that for PASM albeit it's not too exact always. What is the granularity of updating the PC? E.g. when we have: a = func(b, c) this translates to several PASM instructions. Alone setting I0..I4 for call and return are 10. For a traceback, we'd need one PC update only. OTOH when we have: add P0, P1 it could be an overridden method call, which would need updating the PC. We could of course just say, that's not our problem: the HLL is responsible for emitting setline n setfile "file" opcodes. leo
Re: [perl #32270] parrot -t leaks like a sieve
Dan Sugalski <[EMAIL PROTECTED]> wrote: > Throwing the trace switch on makes parrot leak. A *lot*. Processes > that top out at 100M VSIZE hit 1G or more, which, well... it ain't > good. Tracing's slow enough as it is without the added hit of > swapping and ever-increasing memory usage. Yep. Tracing is using PIO_eprintf(), which finally is calling Parrot_vsprintf_s(). Around that function call GC was disabled, so no buffer memory got recycled, as the vast majority of buffer allocations is coming from the trace. Fixed. leo
Re: Performance Statistics (and Graphs!)
Matt Diephouse <[EMAIL PROTECTED]> wrote:
> Joshua Gatcomb and I have been working a little under a week to set up
> an automated build system for parrot that tracks performance (with
> help from Dan's box). We have collected benchmark data for regular and
> optimized builds with and without JIT from June 1st through October.
> With some help from Perl and GD, we've up several pages of graphs:
> http://www.sidhe.org/~timeparrot/graphs/
Great. That's really helpful.
Some remarks WRT various {in,de}creases:
* ~2 weeks in Oct including the release, JIT was accidentally disabled
(best seen in primes*_i)
* ~ Sep 22th the broken return continuation recycling was abandoned
(fib)
* end of Oct the indirect register addressing was working (fib)
* the increase in e.g. fib in the beginning of Sept could be related
to disabling ARENA_DOD_FLAGS during incremental GC implementation
Thanks a lot,
leo
Re: [CVS ci] indirect register frames 14 - cache the register frame
Dan Sugalski <[EMAIL PROTECTED]> wrote: >>$P1 = interpinfo .INTERPINFO_CURRENT_CONT >>$P1 = clone $P1 >> >>I'm still inclined to make this sequence an opcode, though. The >>cloning is still necessary, as the return continuation is returned. > Hrm. I think the returned continuation should be usable without > cloning. If we need to clone it it should be part of the continuation > fetching. Probably yes[1]. Eventually we can get rid of the return continuation object. But that's not easy as we have "invoke sub_obj" too, which uses an existing continuation in P1. Additionally there's already a lot of code around that just does "invoke P1". To disambiguate call and return for the case "plain subroutine", we would need a "returncc" opcode, that use the information in the context to return as we now do with P1. A sequence: invokecc ... returncc doesn't need a P1 object, it just needs a pointer in the Sub context to the caller's context. [1] There'is the case of pure introspection, where cloning isn't needed, *if* the return continuation isn't abused. Could be dangerous, though. leo
Re: [CVS ci] indirect register frames 14 - cache the register frame
Piers Cawley <[EMAIL PROTECTED]> wrote: > And, dammit, making a full continuation isn't something a programmer > should do lightly. BTW I had to change your example code (you remember it for sure, it's in t/op/gc_13 inv CVS) (define (choose . all-choices) (let ((old-fail fail)) (call-with-current-continuation ... I had to use a distinct second "choose" closure to make that code working again during changes for the indirect reegister addressing. # XXX need this these closures have different state newsub choose, .Closure, _choose y = choose(arr2) I presume it's technically correct, as these two closures have different "choices" arrays in their lexical pads. leo
Re: case mangling and binary strings
Sam Ruby <[EMAIL PROTECTED]> wrote: > Python has two data types: str and unicode. Python's unicode "features" are probably not really good examples generally. Ongoing discussion in Python lists seem to indicate that there a rather rough edges still. > - Sam Ruby leo
Re: case mangling and binary strings
Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 6:16 PM +0100 11/2/04, Leopold Toetsch wrote: >> >>If it's pure binary pitch a fit. >>If it has an encoding attached, continue, > Yeah, that's the plan. > I'd like to add another entry to the internal API: >OPTIONAL_INTERNAL_EXCEPTION > which works like INTERNAL_EXCEPTION only it checks first to see if > the exception should get thrown before throwing it. We are doing that already in the find_global opcode. Depending on a bit in the interpreter->ctx.errors flag, we through a real exception or not. So I'd propose: - make that a real_exception instead - new API is then real_exception_if_error(..., ERROR_foo_bit, ...) leo
Re: setref a misnomer?
Sam Ruby <[EMAIL PROTECTED]> wrote: > I just spent some time debugging a problem which turned out to be due to > the "set" operator not doing what I expected (i.e., calling pmc_set). > In retrospect, what set id doing is perfectly defensible, but "setref", > as implemented by PerlScalar, remains counter intuitive, at least to me: Yep. The C opcode is intended to set a reference inside a reference type, like Ref or SharedRef. The implementation of perlscalar's setref is the old "assign the RHS value" behavior. We have to cleanup classes. > - Sam Ruby leo
Re: case mangling and binary strings
Dan Sugalski <[EMAIL PROTECTED]> wrote: > I expect I'll put together a Unicode charset that uses ICU to do its > thing, and go from there. We certainly need Unicode support, so it's > not like we can't do it. (And we still don't have a better option, > unfortunately) ICU 3.0 should be out AFAIK. This is supposed to fix a lot of build issues. leo
Re: case mangling and binary strings
On Tue, 2 Nov 2004 13:33:47 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 1:16 PM -0500 11/2/04, Sam Ruby wrote: > > Making ICU optional, at least. It's too problematic on too many > platforms, and just turns into a big headache. It seemed like a good > idea at the time, and while it's still better than most of the > alternatives that doesn't, unfortunately, make it good. > Ah, hooray. Please announce when this is done... the porting problem will become much more interesting and much less irritating when this happens once more. Porting parrot and porting ICU need to be separate issues. Adam
