Re: Object semantics
At 4:58 AM +0530 1/4/03, Gopal V wrote: If memory serves me right, Dan Sugalski wrote: language-level "we're object-oriented dammit!" objects, not the lower-level stuff we're currently working with) should/will behave. yay ! ... finally ! reference-style objects and non-reference values. How large can a non-reference value be ? ... (in the .NET opcodes the 'struct' seems to be unlimited in size ...) But well, I'd settle for a non-reference of at least large integers (64bit)... It can be as big as you like. Hang a buffer off the data pointer and stick anything and everything you might want into it. Do we need to build with 64 bit integers to make sure you have space? :) And how will non-reference values dispatch methods ? ... would they be "boxed" into a reference for each method call, so that the method call can modify them ? ...or are all non-reference values immutable ? Neither. Non-reference values are just plain PMCs. Reference values are PMCs that point to other PMCs. to put it down clearly ... MyValueType a; a.Modify(); would a be able to modify itself ? (unfortunately C# allows that) Absolutely. It makes things generally faster and easier for perl, and doesn't affect python or ruby. Yeah, I know, immutable values make a number of static compilation things better with sufficient engineering resources, but we're not particularly static, and our resources are occasionally spotty. :) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Object semantics
At 7:27 PM +0100 1/3/03, Erik Bågfors wrote: On Sat, 2003-01-04 at 00:28, Gopal V wrote: If memory serves me right, Dan Sugalski wrote: > language-level "we're object-oriented dammit!" objects, not the > lower-level stuff we're currently working with) should/will behave. yay ! ... finally ! The moment we've all been waiting for :) Sheesh, everyone lay on the guilt, why don't you? :-P > > reference-style objects and non-reference values. How large can a non-reference value be ? ... (in the .NET opcodes the 'struct' seems to be unlimited in size ...) But well, I'd settle for a non-reference of at least large integers (64bit)... And how will non-reference values dispatch methods ? ... would they be "boxed" into a reference for each method call, so that the method call can modify them ? ...or are all non-reference values immutable ? to put it down clearly ... MyValueType a; a.Modify(); would a be able to modify itself ? (unfortunately C# allows that) So does ruby. We need that :) I wasn't aware that ruby had value types--I thought it was all reference types. Time to crack open the nutshell book again, apparently. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: no no-strict-aliasing (more bondage and stricture)
Done.
--Josh
At 22:57 on 12/31/2002 GMT, Nicholas Clark <[EMAIL PROTECTED]> wrote:
> Currently Parrot is picking up Perl's C compiler flags. Perl is quite
> deliberately attempting to set -fno-strict-aliasing, to stop gcc using
> ANSI's aliasing rules to infer possible optimisations; optimisations that
> will actually break Perl's code.
>
> (Don't ask me to remember exactly what the aliasing rules are, let alone
> explain them correctly, but it's something to do with more than one type of
> pointer not being allowed to point at the same thing (except via a union,
> and where char pointers are exempt) in a strictly conformant ANSI C
> program. Providing this holds true in the C source, the compiler can safely
> reorder memory access and potentially gain speedups. Perl's source isn't
> ANSI conformant in this way. Well, you can ask what the aliasing rules are,
> but I won't answer)
>
> The upshot is that you can't guarantee that any compiler won't be optimising
> based on aliasing assumptions, because, hell, it's allowed to. And we may
> not be able to turn it off. So we ought to be writing code that doesn't make
> aliasing assumptions. Hence we ought to remove -fno-strict-aliasing from
> Parrot's cflags. And as Dan put it "see what breaks". So far nothing, at
> least for a test build on Debian/x86. And as we're now letting gcc make
> aliasing based optimisations, we might see more speed. (And maybe unicorns,
> flying pigs, and round tuits)
>
> Nicholas Clark
>
> --- config/inter/progs.pl~Fri Oct 25 11:23:17 2002
> +++ config/inter/progs.pl Tue Dec 31 21:18:24 2002
> @@ -15,6 +15,7 @@ sub runstep {
>my($cc, $link, $ld, $ccflags, $linkflags, $ldflags, $libs) =
>Configure::Data->get(qw(cc link ld ccflags linkflags ldflags libs));
>$ccflags =~ s/-D(PERL|HAVE)_\w+\s*//g;
> + $ccflags =~ s/-fno-strict-aliasing//g;
>$linkflags =~ s/-libpath:\S+//g;
>$ldflags =~ s/-libpath:\S+//g;
>my $debug='n';
Re: "my int( 1..31 ) $var" ?
> From: "Joe Gottman" <[EMAIL PROTECTED]> > Date: Fri, 3 Jan 2003 22:25:16 -0500 > > > > "JG" == Joe Gottman <[EMAIL PROTECTED]> writes: > > > > JG> Speaking of which, is there a run-time test to check if a variable > is of > > JG> integral type? Something like > > > > JG> print "date" if ($var is int) && (1 <= $var <= 31); > > > > the old standby is: > > > > int( $var ) == $var > > > >I'm not sure if this works. > > my $var = "0"; # Notice the quotation marks > print "is integer" if (int($var) == $var); > > In the above case int($var) == $var returns true when I would want it to > return false. print "date" if $var.isa(int); print "date" if isa $var: int; print "date" if $var ~~ int; Those should all work. IMO the first reads the best. That will also work for Cs, as C is a subclass of C (I think). Luke
Re: [perl #19630] [PATCH] undef warning in Configure.pl
Applied both, thanks.
--Josh
At 19:11 on 12/31/2002 GMT, Nicholas Clark (via RT)
<[EMAIL PROTECTED]> wrote:
> # New Ticket Created by Nicholas Clark
> # Please include the string: [perl #19630]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt2/Ticket/Display.html?id=19630 >
>
>
> I was seeing this:
>
> Generating config.h...done.
> Generating feature.h...done.
> Writing Parrot::Config module...done.
> Use of uninitialized value in substitution iterator at lib/Parrot/Configure/S
tep.pm line 121, line 111.
> Generating Makefiles...done.
> Recording this configuration in myconfig...done.
> Moving platform files into place...done.
> Generating libparrot.def...done.
> Generating core pmc list...done.
> Okay, we're done!
>
>
> And it was annoying me. So I did this to track it down:
>
> --- lib/Parrot/Configure/Step.pm~ Sat Dec 28 12:10:18 2002
> +++ lib/Parrot/Configure/Step.pm Tue Dec 31 18:55:14 2002
> @@ -120,7 +120,9 @@ sub genfile {
> }
> s{
> \$\{(\w+)\}
> -}{Configure::Data->get($1)}egx;
> +}{my $val=Configure::Data->get($1);
> + defined $val ? $val
> + : (warn "value for '$1' in $source is undef", '')}egx;
> print OUT;
> }
>
>
> I think that something like that is a good idea, as this is more helpful:
>
> Generating config.h...done.
> Generating feature.h...done.
> Writing Parrot::Config module...done.
> value for 'asmfun_o' in config/gen/makefiles/root.in is undef at lib/Parrot/C
onfigure/Step.pm line 122, line 111.
> Generating Makefiles...done.
> Recording this configuration in myconfig...done.
> Moving platform files into place...done.
> Generating libparrot.def...done.
> Generating core pmc list...done.
> Okay, we're done!
>
> So I think we also need the appended patch, which elimates the warning.
>
> Nicholas Clark
>
> --- config/auto/jit.pl~ Fri Dec 27 18:27:04 2002
> +++ config/auto/jit.plTue Dec 31 18:59:16 2002
> @@ -73,6 +73,8 @@ sub runstep {
> copy_if_diff("config/gen/platform/$cpuarch.s", "asmfun.s");
>
> Configure::Data->set(asmfun_o => 'asmfun$(O)');
> + } else {
> +Configure::Data->set(asmfun_o => '');
>}
>
>$jitcapable = $set_jitcapable if defined $set_jitcapable;
>
Re: Infant mortality
On Jan-02, Leopold Toetsch wrote: > Steve Fink wrote: > > >On Dec-31, Leopold Toetsch wrote: > > > >>I think, it moves the problems just around with a lot of overhead. E.g. > >>cloning a PerlArray of 10^6 entries would need 1000 generations > > >I don't understand. The outer clone belongs to generation N. Then if > >you called clone() individually on each PMC within the array, then by > >default you wouldn't create any more generations at all. > > Ah, ok. I thougt that at each dod run a new generation is started. But > you seem to manage generation count manually. I was assuming the generation would be automatically incremented per op, either in the runops loop or (if that is too slow) in the implementation of selected ops.
Re: "my int( 1..31 ) $var" ?
- Original Message - From: "Uri Guttman" <[EMAIL PROTECTED]> To: "Joe Gottman" <[EMAIL PROTECTED]> Cc: "Perl6" <[EMAIL PROTECTED]> Sent: Friday, January 03, 2003 10:06 PM Subject: Re: "my int( 1..31 ) $var" ? > > "JG" == Joe Gottman <[EMAIL PROTECTED]> writes: > > JG> Speaking of which, is there a run-time test to check if a variable is of > JG> integral type? Something like > > JG> print "date" if ($var is int) && (1 <= $var <= 31); > > the old standby is: > > int( $var ) == $var > I'm not sure if this works. my $var = "0"; # Notice the quotation marks print "is integer" if (int($var) == $var); In the above case int($var) == $var returns true when I would want it to return false. Joe Gottman
Re: "my int( 1..31 ) $var" ?
> "JG" == Joe Gottman <[EMAIL PROTECTED]> writes: JG> Speaking of which, is there a run-time test to check if a variable is of JG> integral type? Something like JG> print "date" if ($var is int) && (1 <= $var <= 31); the old standby is: int( $var ) == $var uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com - Stem and Perl Development, Systems Architecture, Design and Coding Search or Offer Perl Jobs http://jobs.perl.org Damian Conway Perl Classes - January 2003 -- http://www.stemsystems.com/class
Re: "my int( 1..31 ) $var" ?
- Original Message - From: "Mr. Nobody" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, January 03, 2003 1:58 PM Subject: Re: "my int( 1..31 ) $var" ? > --- Smylers <[EMAIL PROTECTED]> wrote: > > Murat Ünalan wrote: > > > > > print "date" if $var is int( 1..31 ); > > > > I don't think that the type needs to be specified here, especially if > > the variable has already been declared to be of the required type, so a > > junction should be sufficient: > > > > print "date" if $var == any(1 .. 31); > > > > Smylers > > Superpositions in the core? You're kidding, right? > > What's wrong with "if 1 <= $var <= 31"? > For one thing they're not equivalent. my $var = 2.5; print "date" if $var == any(1..31); print "in interval" if 1 <= $var <= 31; Speaking of which, is there a run-time test to check if a variable is of integral type? Something like print "date" if ($var is int) && (1 <= $var <= 31); Joe Gottman
Auto-lazy lists
Do list objects automatically turn lazy if they are assigned another
lazy list. Could I make a lazy list of the natural numbers like
this:?
@natural = 0..Inf;
Or would that end up consuming aleph-null time (neglecting issues of
finite representation)?
More interestingly, could C be used lazily? i.e. make a (very
slow) lazy list of primes like this:?
@primes = grep -> $n { $n % none(2..ceil(sqrt($n))) == 0 } 2..Inf;
That would be so cool! Does it work?
Luke
Re: nag Exegesis 2
Murat Ünalan wrote: my int ($pre, $in, $post) is constant = (0..2); Two things "type and property" that belong so together Do they? Surely the type and constancy of a variable are entirely orthogonal to each other. Besides, if you want them near each other, you can write them this way: my ($pre, $in, $post) returns int is constant = (0..2); Damian
Re: This week's Perl Summary
Piers Cawley wrote: Acknowledgements But, of course, modesty forebade him from thanking the tireless Perl 6 summarizer himself, for his sterling efforts wading through the morasses that are P6-language and P6-internals, endlessly straining out the essentials for the benefit of those in the Perl community without the stamina to follow both groups in their terrifying entirity! ;-) *And* managing to raise money for the Perl Foundation in the process! Thank-you, Piers! Damian
Re: "my int( 1..31 ) $var" ?
[EMAIL PROTECTED] (Damian Conway) writes: > > http://groups.google.com/groups?q=superpositions+group%3Aperl.perl6.language > > finds 141 articles. > > BTW, searching for "junctions" as well (i.e. the new name for the concept) > adds an extra 70 or so articles. Some of which are superimposed! :) Oh, and Mr. Nobody - if you still don't think it's been argued against properly, look at any one of my posts from those threads. :) -- > I never thought I'd say this, but you're getting very strange. Thank God: I thought it was everybody else. - J-P Stacey
Re: "my int( 1..31 ) $var" ?
Simon Cozens wrote: http://groups.google.com/groups?q=superpositions+group%3Aperl.perl6.language finds 141 articles. Thanks, Simon. BTW, searching for "junctions" as well (i.e. the new name for the concept) adds an extra 70 or so articles. Damian
Re: "my int( 1..31 ) $var" ?
Various folks wrote: Superpositions in the core? You're kidding, right? Nope. They're in (this week at least!) What's wrong with "if 1 <= $var <= 31"? ...nothing. If you like it, by all means use it. But, (1) TIMTOWTDI, (2) Smyler's version is more visually concise (although, granted, it actually takes a few extra chars), (3) Smyler's version puts the variable (the important thing in the expression) on the left instead of the in the middle, and (4) IMHO, Smyler's version reads better as English. It's also far slower. Constructing a 31-element list, junctionizing it, This might well be done at compile-time. And/or, lazily. So the cost of these two steps is likely to be negligible. then testing against each element vs. 2 numeric comparisons. Yes. That's a significant cost in this case. Wanting to do this for arbitrary lists dosen't need junctions. "if grep $_ == $var, @mylist" suffices. Except that it's much uglier (and hence less maintainable) than: if $var == any(@mylist) Moreover, in this case, junctions may well be faster, since they short-circuit and C probably still doesn't. Damian
Re: "my int( 1..31 ) $var" ?
[EMAIL PROTECTED] (Mr. Nobody) writes: > I looked through the p6l archives, there really wasn't much discussion about > it. http://groups.google.com/groups?q=superpositions+group%3Aperl.perl6.language finds 141 articles. -- An ASCII character walks into a bar and orders a double. "Having a bad day?" asks the barman. "Yeah, I have a parity error," replies the ASCII character. The barman says, "Yeah, I thought you looked a bit off." -- from Skud
Re: "my int( 1..31 ) $var" ?
--- Smylers <[EMAIL PROTECTED]> wrote: > David Storrs wrote: > > > On Fri, Jan 03, 2003 at 10:58:49AM -0800, Mr. Nobody wrote: > > > > > --- Smylers <[EMAIL PROTECTED]> wrote: > > > > > > > junction should be sufficient: > > > > > > > > print "date" if $var == any(1 .. 31); > > > > > > Superpositions in the core? You're kidding, right? > > Yeah, somehow they just slipped right in there without anybody on this > mailing list really noticing -- and certainly without any long threads > discussing the syntax for their operator incarnations and the knock-on > effect that could have on other operators ... I looked through the p6l archives, there really wasn't much discussion about it. > > What's wrong with "if 1 <= $var <= 31"? > > > > ...nothing. If you like it, by all means use it. But, (1) TIMTOWTDI, > > (2) Smyler's version is more visually concise (although, granted, it > > actually takes a few extra chars), (3) Smyler's version puts the > > variable (the important thing in the expression) on the left instead > > of the in the middle, and (4) IMHO, Smyler's version reads better as > > English. It's also far slower. Constructing a 31-element list, junctionizing it, then testing against each element vs. 2 numeric comparisons. I know where my money is... > Those are stylistic things, and to some degree a matter of taste. More > importantly the junction version -- or even better, the smartmatch > version as pointed out by Chris Dutton -- work for arbitrary sets, not > just ranges of consecutive values. Wanting to do this for arbitrary lists dosen't need junctions. "if grep $_ == $var, @mylist" suffices. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
nag Exegesis 2
In the name of the bum (and c++-used eyes), i have some small criticism about the "type and property" syntax. "Exegesis 2 - Any variables to declare?" suggests: my int ($pre, $in, $post) is constant = (0..2); Two things "type and property" that belong so together are visually so disrupted, which hurts. Additionally it is so confusing for a mainly c++/java/c# that he would mixup "perl property" with his "c++ object declaration" (resulting in a hard learning curve during p6 basics). While the type "int" is more the "object" he would have expected. My suggestion for alternativ syntax: my constant int ($pre, $in, $post) = (0..2); my int is constant ($pre, $in, $post) = (0..2); This also protects from overlooking somewhere trailing properties in growing variable lists, like in: my int ($one, $two, $three, $four, $five, $six, $seven, $eight, $nine, $ten) is constant = (0..9); or complex property collections my int ($one, $two, $three, $four, $five, $six, $seven ) is Prop( 'camel', 'perl', 'camel', 'perl' ) = (0..X); In "alternativ syntax": my constant int ($one, $two, $three, $four, $five, $six, $seven, $eight, $nine, $ten) = (0..X); here i had just looked in the head and see whats it. my int Prop( 'camel', 'perl', 'camel', 'perl' ) ($one, $two, $three, $four, $five, $six, $seven ) = (0..6); here i had just looked at the tail and can count how many vars to initialize (more like perl5, nothing disturbing inbetween). Addition: I have an idea ;) Also i think one could recycle decleration "is" for testing values in non-declerational-context. What if i have a "propertyless" variable and want to test whether its would suffice a property's spirit. When "is" would result in a boolean value i could write my unloading perl6 like: my ($var, $a); print "this is a month day" if $var is Any(1..31); print "this is a valid email" if $var is Email( 'mxcheck' ); print "debug: var was constant" if $var is constant; print 'MasterCard' if $a is CreditCard( 'MASTER' ); print 'VISA'if $a is CreditCard( 'VISA' ); print 'i am confused' if $a is SocialNumber( 'US' ); boolean expr Greetings, Murat PS: Sorry for opening a new thread, but after rereading my last stupid question i realized that i wasn't using perl6-talk. So i reread apo/exe and reconfigured my whole intention ;)
Re: "my int( 1..31 ) $var" ?
David Storrs wrote: > On Fri, Jan 03, 2003 at 10:58:49AM -0800, Mr. Nobody wrote: > > > --- Smylers <[EMAIL PROTECTED]> wrote: > > > > > junction should be sufficient: > > > > > > print "date" if $var == any(1 .. 31); > > > > Superpositions in the core? You're kidding, right? Yeah, somehow they just slipped right in there without anybody on this mailing list really noticing -- and certainly without any long threads discussing the syntax for their operator incarnations and the knock-on effect that could have on other operators ... > > What's wrong with "if 1 <= $var <= 31"? > > ...nothing. If you like it, by all means use it. But, (1) TIMTOWTDI, > (2) Smyler's version is more visually concise (although, granted, it > actually takes a few extra chars), (3) Smyler's version puts the > variable (the important thing in the expression) on the left instead > of the in the middle, and (4) IMHO, Smyler's version reads better as > English. Those are stylistic things, and to some degree a matter of taste. More importantly the junction version -- or even better, the smartmatch version as pointed out by Chris Dutton -- work for arbitrary sets, not just ranges of consecutive values. Smylers
Re: "my int( 1..31 ) $var" ?
Chris Dutton wrote: > On Friday, January 3, 2003, at 08:55 AM, Smylers wrote: > > > Murat Ünalan wrote: > > > > > print "date" if $var is int( 1..31 ); > > > > print "date" if $var == any(1 .. 31); > > I was under the impression the "smart match" operator would cover that > implicitly. Ah, yes; of course it does. > print "date" if $var =~ 1..31; > > Has this changed somewhere without my noticing it? No -- I just forgot about it. But now you bring it up, I do remember that the symbol changed, so I think it should be: print "date" if $var ~~ 1..31; Smylers
Re: "my int( 1..31 ) $var" ?
> Date: Fri, 3 Jan 2003 12:06:24 -0500 > From: Chris Dutton <[EMAIL PROTECTED]> > > On Friday, January 3, 2003, at 12:00 PM, Chris Dutton wrote: > > > print "date" if 1..31 given $var; > > Except that this would always be true. Nevermind, I'm an idiot. You're not such an idiot. You just got one word wrong: print "date" when 1..31 given $var; There is definitely postfix C. C, and C are postfix, so I don't see why C wouldn't be. Miko seems to want it enough. But, in accordance with Larry's "Nope, still can't chain [postfix conditions,]" this would not be very useful. Hopefully he'll reconsider whether you can chain them or not? :) Luke
Re: GC/DOD feedback & runtime tuning
Dan Sugalski wrote: At 1:34 PM +0100 1/3/03, Leopold Toetsch wrote: 1) parrot compiled -O3 (classes/Makefile is br0ken, doesn't get CFLAGS from Configure) - but unoptimized is still faster then perl5 :-) Odd. Not on my system. Might be a x86/PPC issue. I must have overlooked -O3 in classes/Makefile, it was there. Oh, apply it, by all means. (Though I think I see that you already have... :) Only the list related part. Ok. Here ist the rest. - No stackwalk, as already sent by separate #19668, which is included if this is a problem for $architecture, please enable trace_system_areas in dod.c again - feedback still welcome - a hack to reduce DOD runs by some amount, helping for this test, where only allocations happen. If we keep it, it should be reworked to have the stats in interpreter and "skip" has to be disabled for explict "sweep" calls. - allocation constants give good results on my systems which might probably not apply to yours. In the long run some sself tuning will be necessary, we will definitely need lower allocation sizes, when e.g such a big allocation is gone, and we have plenty of free PMCs - we currently do only increase headers_per_alloc. - statistics need to be reworked, they are only valid after a DOD run, though I update num_free_objects now immediately. - memory_pool does increase allocation size too now leo
Re: GC/DOD feedback & runtime tuning
Dan Sugalski wrote: At 5:46 PM +0100 1/3/03, Leopold Toetsch wrote: Leopold Toetsch wrote: [ this is Mr. f'up myself again ] You've a *long* way to go to get that title. (It's mine, and you can't have it! :) Oh, sorry for misusing your prenome ;) This test is with a 10% smaller PMC giving 10% increase in speed. Damn, I was afraid of that. On the one hand I like the speed, on the other... :( [ differently sized PMCs ] I'm not willing to go so radically to start, but I did have an idea. I think part of the extra cost is just in cache fluffiness--the sync info just isn't being used much. I don't think that it, or the property info, will be used most of the time. We could yank the metadata and sync fields out of the PMC itself and put them in a separate segment of the PMC's arena, and replace them with a single pointer to the PMC's particular section. A little bit more radically: - a PMC has a PObj and a vtable (= 16 byte) - if a PMC needs data, metadata or synchronize then cache.pmc_val points to the "Extra PMC data" (our current PMC ) containing this fields so we do nether resize, but have for aggregates or PMCs with properties one more indirection. - PerlStrings move from ->data to ->cache.string_val As programs tend to have much more scalars then aggregates and probably more scalars w/o properties then with, this would win a lot of precious cache mem. It ultimately increases the size of a PMC by one pointer if we preallocate all the property/sync pairs, but it makes the PMC itself more dense and, if I'm calculating things right, makes it fit on an 8-byte boundary better. Not here: current PMC 32 byte, simple PMC 16 byte. BTW tt.c prints these numbers ;-) leo
Re: "my int( 1..31 ) $var" ?
On Fri, Jan 03, 2003 at 10:58:49AM -0800, Mr. Nobody wrote: > --- Smylers <[EMAIL PROTECTED]> wrote: > > junction should be sufficient: > > > > print "date" if $var == any(1 .. 31); > > Superpositions in the core? You're kidding, right? > > What's wrong with "if 1 <= $var <= 31"? My understanding was that junctions were most definitely in the core. As to what's wrong with the example you give...nothing. If you like it, by all means use it. But, (1) TIMTOWTDI, (2) Smyler's version is more visually concise (although, granted, it actually takes a few extra chars), (3) Smyler's version puts the variable (the important thing in the expression) on the left instead of the in the middle, and (4) IMHO, Smyler's version reads better as English. --Dks
Re: GC/DOD feedback & runtime tuning
At 5:46 PM +0100 1/3/03, Leopold Toetsch wrote: Leopold Toetsch wrote: [ this is Mr. f'up myself again ] You've a *long* way to go to get that title. (It's mine, and you can't have it! :) $ time parrot -j stress.pbc real0m0.849s By reducing the amount of DOD runs I now have: $ time parrot -j stress.pbc A total of 9 DOD runs were made real0m0.708s But this still could go faster: $ parrot -j stress.pbc # w/o pmc->synchronize (-10% size) A total of 9 DOD runs were made real0m0.635s This test is with a 10% smaller PMC giving 10% increase in speed. This seems to indicate again the necessity for a smaller Scalar PMC as already proposed in the thread "[CVS ci] mark5 - PMC/Buffer unification #10". Having only 50% size for a "plain" scalar could inidicate 50% speed increase for such programs with many live PMCs. Damn, I was afraid of that. On the one hand I like the speed, on the other... :( The problem is, we can't promote a smaller PMC to a bigger one. But what about this strategy: - scalars start with a small PMC (16 bytes on a 32 bit machine) except when the HL indicates, that the var needs properties or may be be shared between threads - 99% of all scalars will probably nether be used differently - when such a small scalar gets runtime properties added then: - make a new "big" PMC and point the old PMC to the newly created one. This should work like an unvisible reference, doing all functions on behalf of the scalar. - in the next DOD run, when we find such a PMC pointer, replace it with the real PMC. As this might need a modified pobject_lives function (digging in all places to find all occurencies) this could be a separate step too, run only when needed. I'm not willing to go so radically to start, but I did have an idea. I think part of the extra cost is just in cache fluffiness--the sync info just isn't being used much. I don't think that it, or the property info, will be used most of the time. We could yank the metadata and sync fields out of the PMC itself and put them in a separate segment of the PMC's arena, and replace them with a single pointer to the PMC's particular section. It ultimately increases the size of a PMC by one pointer if we preallocate all the property/sync pairs, but it makes the PMC itself more dense and, if I'm calculating things right, makes it fit on an 8-byte boundary better. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: GC/DOD feedback & runtime tuning
At 1:34 PM +0100 1/3/03, Leopold Toetsch wrote: Dan Sugalski wrote: At 12:52 AM +0100 1/3/03, Leopold Toetsch wrote: Dan Sugalski wrote: First, the resource system falls down hard when doing lots of allocations with no deallocations. It gets exponentially slower, which is a Bad Thing. 1) parrot compiled -O3 (classes/Makefile is br0ken, doesn't get CFLAGS from Configure) - but unoptimized is still faster then perl5 :-) Odd. Not on my system. Might be a x86/PPC issue. 2) I did finetune block allocation, which did cause DOD runs too often. Memory blocks are growing too now. 3) Changed growing factor for PMCs from 4 to 1.5 and started with a bigger initial size. Growing too aggressively causes far too many PMCs allocated for programs with many live objects. Also I did introduce some (arbitrary) upper limit for pool size. Keen, thanks. >>> Second, Array and its subclasses need some performance thumping, as they seem to come in at about half the speed of perl 5. 4) classes/perlarray.pmc was totally unoptimized (cut&paste blabla). Figured as much. Not at all a problem, just an easy spot to get some extra performance. But, this is not the original stress.pasm it is a worse one, more similar to the perl version (you were reusing P0 for @arr1 and @arr2, while mine does allocate new arrays leading to more live objects). perl: 5.8.0 -Duselongdouble (which shouldn't matter here) i386/linux, athlon 800, 256 Meg I'll comment the changes a little bit more and [ ] send patch [ ] check it in? Oh, apply it, by all means. (Though I think I see that you already have... :) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Infant mortality
On Tue, Dec 31, 2002 at 06:32:42PM -0800, Steve Fink wrote:
> On Dec-31, Jerome Vouillon wrote:
> > The temporary objects could be stored in a stack, which is popped when
> > leaving the current function (both with normal exits and longjmp).
> > This should make it a lot less likely to forget the unanchoring.
>
> How do you do this with longjmp? I could see chaining another handler
> onto the longjmp context so that longjmp would backtrack through all
> of these allocations, but that would require allocating space for
> another context. And allocating space further slows down the common
> case...
I'm thinking of something like this.
First, PMCs are not stored directly in C variables, but only in "PMC
references" (in the field "ref"). A stack of PMC references is
maintained, using the field "previous". The GC will consider all the
PMCs in the stack as part of the root.
typedef struct _PMC_ref {
PMC * ref;
_PMC_REF * previous
} PMC_ref;
These PMC references need to be initialized: the PMC pointer is set to
a valid value and they are pushed into the stack. (This function
could take a least of PMC references instead of just one.)
void init_pmc_ref (Parrot_Interp *interp, PMC_ref *ref) {
ref->ref = NULL;
ref->previous = interp->c_roots;
interp->c_roots = &ref;
}
A "scope" datastructure is used to save the current stack top, and
restore it later.
typedef struct {
struct Parrot_Interp *interp;
PMC_ref * saved_top;
} scope;
void enter_scope (Parrot_Interp *interp, scope * s) {
s->interp = interp;
s->saved_top = s->c_roots;
}
void exit_scope (scope * s) {
s->interp->c_roots = s->saved_top;
}
Then, the body of a C function would look something like this:
/* Create a new scope */
scope s;
enter_scope(interp, &s);
/* Initialize the PMC references */
PMC_ref a;
init_pmc_ref(interp, &a);
...
/* Exit the scope and return */
exit_scope(&s);
return;
I don't think there is any difficulty with exception handling :
scope s;
jmp_buf buf;
enter_scope(interp, &s);
if (setjmp(buf)) {
... /* Something that might throw an exception */
exit_scope(&s);
} else {
exit_scope(&s);
... /* Handle the exception */
}
-- Jerome
Re: Introduction and cygwin results
--- James Michael DuPont <[EMAIL PROTECTED]> wrote: > Hi There! > [SECTION PACKDUMP] > make packdump.exe > packdump.c: In function `PackFile_Constant_dump': > packdump.c:111: structure has no member named `flags' > make: *** [packdump.o] Error 1 > > I have commented that out for now : > /*PIO_printf(interpreter, "FLAGS=> > 0x%04lx,\n", >(long)self->string->flags); > */ Oopps : more then that : pdump.c: In function `main': pdump.c:21: storage size of `file_stat' isn't known pdump.c:37: `O_RDONLY' undeclared (first use in this function) pdump.c:37: (Each undeclared identifier is reported only once pdump.c:37: for each function it appears in.) under cygwin you need : #include mike = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: "my int( 1..31 ) $var" ?
--- Smylers <[EMAIL PROTECTED]> wrote: > Murat Ünalan wrote: > > > print "date" if $var is int( 1..31 ); > > I don't think that the type needs to be specified here, especially if > the variable has already been declared to be of the required type, so a > junction should be sufficient: > > print "date" if $var == any(1 .. 31); > > Smylers Superpositions in the core? You're kidding, right? What's wrong with "if 1 <= $var <= 31"? __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Introduction and cygwin results
Hi There! My name is Mike, and I have decided to pick up on the parrot again. You seem to be making good progress, let me help you test this thing and build some interfaces to other programs. Can someone tell me if anyone uses packdump from cvs? is that an equivalent to ildasm in dotnet? It seems to be broken. Can I dump an set of instructions from a program into a file, and reassemble them? If not, is there a way to dump a parrot program? Is there a way to capture the line number, and comments of a perl6 program in parrot? What about high level type information? I am interested in building a interface from parrot into the introspector, that will give you a way to convert your programs internals into RDF/XML and visualize and manipulate them via the GUI. I am using the redland perl api, and would like to link that into parrot. We are freezing the gcc interface soon, and because the introspector is mostly writtten in perl, I think that parrot would be the next step. I would be willing to port my code to the subset of perl/parrot that is currently supported, where I can i find that? Here is my first test results with parrot under cygwin : [SECTION GCC -V] compiler version [SECTION MAKE TEST] results of maketest [SECTION PACKDUMP] compiling error in packdump running examples : [SECTION MOPS] [SECTION LIFE] Mike [SECTION GCC -v] gcc -v : Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/3.2/specs Configured with: /netrel/src/gcc-3.2-3/configure --enable languages=c,c++,f77,java --enable-libgcj --enable-threads=posix --with-system-zlib --enable-nls --without-included-gettext --enable-interpreter --disable-sjlj-exceptions --disable-version-specific-runtime-libs --enable-shared --build=i686-pc-linux --host=i686-pc-cygwin --target=i686-pc-cygwin --enable-haifa --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --includedir=/nonexistent/include --libexecdir=/usr/sbin Thread model: posix gcc version 3.2 20020927 (prerelease) [SECTION MAKE TEST] perl t/harness --gc-debug --running-make-test t/src/basic.ok t/src/exit..ok t/src/intlist...ok t/src/list..ok t/src/manifest..ok t/src/sprintf...ok t/op/basic..ok t/op/bitwiseok t/op/comp...ok t/op/conv...ok t/op/debuginfo..ok t/op/gc.ok t/op/globalsok t/op/hacks..ok t/op/ifunless...ok t/op/jitok t/op/jitn...ok t/op/lexicals...ok t/op/macro..ok, 1/15 skipped: Await exceptions t/op/number.ok t/op/rx.ok, 1/23 skipped: Pending some sort of lowercasing op t/op/stacks.ok, 1/35 skipped: Await exceptions t/op/string.ok t/op/time...ok t/op/trans..ok t/op/types..ok t/pmc/array.ok t/pmc/boolean...ok t/pmc/intlist...ok t/pmc/multiarrayok t/pmc/nci...ok, 11/11 skipped: needs jit/i386 and libnci.so t/pmc/perlarray.ok t/pmc/perlhash..ok t/pmc/perlint...ok, 1/5 skipped: add_keyed: not yet t/pmc/perlstringok, 1/8 skipped: Pending new version of concat_p_p_s t/pmc/pmc...ok 31/80# Failed test (t/pmc/pmc.t at line 491) # got: '2.70 # ' # expected: 'bar2.70 # ' t/pmc/pmc...ok 79/80# Looks like you failed 1 tests of 80. t/pmc/pmc...dubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 32 Failed 1/80 tests, 98.75% okay (-2 skipped tests: 77 okay, 96.25%) t/pmc/prop..ok t/pmc/scratchpadok t/pmc/sub...ok Failed Test Status Wstat Total Fail Failed List of Failed --- t/pmc/pmc.t1 256801 1.25% 32 18 subtests skipped. Failed 1/42 test scripts, 97.62% okay. 1/584 subtests failed, 99.83% okay. make: *** [test_dummy] Error 2 [SECTION PACKDUMP] make packdump.exe packdump.c: In function `PackFile_Constant_dump': packdump.c:111: structure has no member named `flags' make: *** [packdump.o] Error 1 I have commented that out for now : /*PIO_printf(interpreter, "FLAGS=> 0x%04lx,\n", (long)self->string->flags); */ [SECTION MOPS] $ ./examples/mops/mops.exe Iterations:1 Estimated ops: 2 Elapsed time: 0.784000 M op/s:255.102028 [SECTION LIFE] $ examples/assembly/life.exe .. 5000 generations in 6.707000 seconds. 745.489785 generations/sec A total of 460064 bytes were allocated A total of 14 DOD runs were made A total of 93 collection runs were made Copying a total of 13534560 bytes There are 471 active Buffer structs There are 6400 total Buffer structs = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: Object semantics
On Sat, 2003-01-04 at 00:28, Gopal V wrote: > If memory serves me right, Dan Sugalski wrote: > > language-level "we're object-oriented dammit!" objects, not the > > lower-level stuff we're currently working with) should/will behave. > > yay ! ... finally ! The moment we've all been waiting for :) > > reference-style objects and non-reference values. > > How large can a non-reference value be ? ... (in the .NET opcodes the > 'struct' seems to be unlimited in size ...) But well, I'd settle for > a non-reference of at least large integers (64bit)... > > And how will non-reference values dispatch methods ? ... would they be > "boxed" into a reference for each method call, so that the method call > can modify them ? ...or are all non-reference values immutable ? > > to put it down clearly ... > > MyValueType a; > a.Modify(); > > would a be able to modify itself ? (unfortunately C# allows that) So does ruby. We need that :) /Erik -- Erik Bågfors | [EMAIL PROTECTED] Supporter of free software | GSM +46 733 279 273 fingerprint: A85B 95D3 D26B 296B 6C60 4F32 2C0B 693D 6E32
Re: Object semantics
If memory serves me right, Dan Sugalski wrote: > language-level "we're object-oriented dammit!" objects, not the > lower-level stuff we're currently working with) should/will behave. yay ! ... finally ! > reference-style objects and non-reference values. How large can a non-reference value be ? ... (in the .NET opcodes the 'struct' seems to be unlimited in size ...) But well, I'd settle for a non-reference of at least large integers (64bit)... And how will non-reference values dispatch methods ? ... would they be "boxed" into a reference for each method call, so that the method call can modify them ? ...or are all non-reference values immutable ? to put it down clearly ... MyValueType a; a.Modify(); would a be able to modify itself ? (unfortunately C# allows that) Gopal -- The difference between insanity and genius is measured by success
Re: Variable Types Vs Value Types
One of the wise may override my evaluation, but... On Thu, 2 Jan 2003, Dave Whipp wrote: > Can the type of a variable vary independenty of its value? My understanding is that the type of a variable merely restricts the type of value you can assign to it. (Well, it probably does more, but I'm not clear on what or how yet.) > Consider the following: > >my @a = (1,2,3); >my $b := @a; > > @a and $b both refer to the same object. $b's object has methods such as > PUSH, POP, etc, as does @a's. Do they? One is obviously an array, and one is obviously a scalar. You may get an error (cannot alias an array as a scalar) or $b get aliased to the array-in-scalar-context (a reference). > So the type of the value (object) is the same in each case, but the > variable's types are different. OK, I'll assume $b is a reference to @a. > The difference becomes very obvious when you start doing DWIM stuff. > > Consider this code: > >print @a + $b > > This will evaluate each, in numeric context. To get at those numbers, > Perl will translate this to something like > >print @a.FETCHSIZE + $b.FETCHNUM > > And will promptly get a run-time error for the latter (maybe just a > warning). No, as smylers said, an arrayref in numeric context is the length of the array. (Arrays and arrayrefs behave the same in scalar context, if I'm paraphrasing Larry correctly.) > Now consider a more extreme (and probably very bad) example: imagine > we want to (lexically) redefine how an array behaves in numeric context: > Lets say that we want it to use the sum of its elements, not its size. > We don't want to modify the object itself (except to give it the C > method): we simply want Perl to use the object slightly differently: > >my @a = (1,2,3) but implements_sum_method; # add .sum method to vtable >my SummingArray $b := @a; Actually, (unless implements_sum_method is a subclass of SummingArray,) it looks like an error to me, because @a is an array and/or an implements_sum_method, but $b is restricted to holding a SummingArray. We're getting into areas of "but" which I'm not sure about, but if SummingArray is a class which impliments .sum and overrides .num to use it, then this might work (with the same caveats about aliasing an array to a scalar): my @a = (1,2,3) but SummingArray; # or subclass of summingarray my SummingArray $b := @a; > The type of $b refers to the variable's type, not the object's. But the value's type is what will be used in vtable lookups, I assume. > Let us > suppose that the type-definition syntax allows us to tell perl: "when > you use this variable in numeric context, call your object's C > method.". now, when we code That would happen when you override the .num method, or whatever the value-in-numeric-context method is called. >print @a + $b; > > perl maps this to > >print @a.FETCHSIZE + $b.sum; or to: print @a.Array::num + $b.SummingArray::num; > and prints 9. > > We don't need the variable-type magic, of course. We could have just said > >print @a + @a.sum; > > and gotten the same result. But the ability to express the behaviour of > variables, independently of values, could be useful (and more powerful > than a c). Or it might just cause confusion. As counter-example, consider: my Array @array := SpecialArray.new; Should the value in @array act like an Array or a SpecialArray? Most people would say SpecialArray, because a SpecialArray ISA Array. I can interpret what you are saying as "sometimes, WIM is to act like Array", in which case, that's not what most people mean, so you need to be more explicit somehow. I can also interpret what you want as saying "my SpecialArray @array := Array.new" should autopromote the value to a subclass somehow, which would be very strange. I'm no OO guru, but trying to call a method which is only defined in a subclass of an object's class is probably not going to work. On the other, other hand, if the SpecialArray class has defined a constructor or assignment operator which accepts an Array, then you have told the compiler how to do the desired autopromotion (although I still doubt it would work with an alias-operator), and it can mostly DWYM, although the type of the value has actually changed in this scenario. ~ John Williams
Re: "my int( 1..31 ) $var" ?
On Friday, January 3, 2003, at 12:00 PM, Chris Dutton wrote: print "date" if 1..31 given $var; Except that this would always be true. Nevermind, I'm an idiot.
Re: "my int( 1..31 ) $var" ?
On Friday, January 3, 2003, at 08:55 AM, Smylers wrote: Murat Ünalan wrote: print "date" if $var is int( 1..31 ); I don't think that the type needs to be specified here, especially if the variable has already been declared to be of the required type, so a junction should be sufficient: print "date" if $var == any(1 .. 31); I was under the impression the "smart match" operator would cover that implicitly. print "date" if $var =~ 1..31; Has this changed somewhere without my noticing it? Hmmm... thinking about another form of the above, I wonder... is there a postfix version of "given"? print "date" if 1..31 given $var;
Re: GC/DOD feedback & runtime tuning
Leopold Toetsch wrote: [ this is Mr. f'up myself again ] $ time parrot -j stress.pbc real0m0.849s By reducing the amount of DOD runs I now have: $ time parrot -j stress.pbc A total of 9 DOD runs were made real0m0.708s But this still could go faster: $ parrot -j stress.pbc # w/o pmc->synchronize (-10% size) A total of 9 DOD runs were made real0m0.635s This test is with a 10% smaller PMC giving 10% increase in speed. This seems to indicate again the necessity for a smaller Scalar PMC as already proposed in the thread "[CVS ci] mark5 - PMC/Buffer unification #10". Having only 50% size for a "plain" scalar could inidicate 50% speed increase for such programs with many live PMCs. The problem is, we can't promote a smaller PMC to a bigger one. But what about this strategy: - scalars start with a small PMC (16 bytes on a 32 bit machine) except when the HL indicates, that the var needs properties or may be be shared between threads - 99% of all scalars will probably nether be used differently - when such a small scalar gets runtime properties added then: - make a new "big" PMC and point the old PMC to the newly created one. This should work like an unvisible reference, doing all functions on behalf of the scalar. - in the next DOD run, when we find such a PMC pointer, replace it with the real PMC. As this might need a modified pobject_lives function (digging in all places to find all occurencies) this could be a separate step too, run only when needed. leo
Re: [PASM] PerlHash and keys
Aldo Calpini wrote: I was the proposer. I have written an Iterator PMC back in the ol' 0.0.8 days, but then I was distracted and never finished my work. I will try to reimplement my addition to 0.0.9 and submit a patch ASAP (probably after 07 jan ;-). Thanks, great. cheers, Aldo leo
Re: GC/DOD feedback & runtime tuning
Leopold Toetsch wrote: [ another f'up myself ] stress2 results: $ time perl examples/benchmarks/stress2.pl real0m2.430s user0m2.410s sys 0m0.020s $ time parrot stress2.pbc real0m1.854s user0m1.710s sys 0m0.140s $ time parrot -j stress2.pbc real0m1.460s user0m1.370s sys 0m0.090s leo
Re: "my int( 1..31 ) $var" ?
Murat Ünalan wrote: > print "date" if $var is int( 1..31 ); I don't think that the type needs to be specified here, especially if the variable has already been declared to be of the required type, so a junction should be sufficient: print "date" if $var == any(1 .. 31); Smylers
Re: Variable Types Vs Value Types
Dave Whipp wrote: >print @a + $b > > This will evaluate each, in numeric context. To get at those numbers, > Perl will translate this to something like > >print @a.FETCHSIZE + $b.FETCHNUM I thought[*0] that Larry said arrays in a scalar context are now treated as array references, so actually both sides are array refs. Then there's a further rule that array refs in _numeric_ scalar context yield the number of elements in the array (since it doesn't make sense to do arithmetic on references). So it's C<@a> that's going through two steps to get to the size, not C<$b>. I'm not sure how much that effects the general point you were trying to make. [*0] Though this is just from memory. I've just had a brief scan through Apocalypse 2 and can't find it, so I could be wrong. Smylers
"my int( 1..31 ) $var" ?
I have an idea ! Damian conway's Attribute::Types suggests "my $date: INTEGER(1..31);" but i think "my int( 1..31 ) $date" is more like a c++/java "Integer date( 1, 31 );" and a weddig of both should fit perl6 best. Would mean: my int( 1..31 ) $var; $date = 23; # okay $date = 32; # KABOOM! I have some additional idea, when someone dislikes the tie-like behaviour: an explicit testing with print "date" if $var is int( 1..31 ); I think this suggestion should had been packed into a RFC, but when the RFC-process closed i was still in my perl baby-shoes. Murat
Re: GC/DOD feedback & runtime tuning
Leopold Toetsch wrote: $ time parrot stress.pbc real0m0.508s Sorry, due to some lack of coffee, I ran a version, where DOD was blocked in buildarray. Here are updated numbers: $ time perl examples/benchmarks/stress.pl real0m0.786s user0m0.590s sys 0m0.200s $ time parrot -j stress.pbc real0m0.849s user0m0.780s sys 0m0.070s $ time parrot stress.pbc real0m0.953s user0m0.890s sys 0m0.050s The speed difference is due to 12 DOD runs, which take by far the most time: time seconds secondscalls us/call us/call name 20.34 0.24 0.24 73 3287.67 3698.63 free_unused_pobjects 16.95 0.44 0.20 1332629 0.15 0.15 pobject_lives 14.41 0.61 0.17 cg_core 12.71 0.76 0.15 155 967.74 2257.78 list_mark 11.02 0.89 0.13 500078 0.26 0.56 new_pmc_header 7.63 0.98 0.09 13 6923.08 6923.08 alloc_objects 4.24 1.03 0.05 500051 0.10 0.50 list_assign leo
Variable Types Vs Value Types
Can the type of a variable vary independenty of its value? Consider the following: my @a = (1,2,3); my $b := @a; @a and $b both refer to the same object. $b's object has methods such as PUSH, POP, etc, as does @a's. So the type of the value (object) is the same in each case, but the variable's types are different. The difference becomes very obvious when you start doing DWIM stuff. Consider this code: print @a + $b This will evaluate each, in numeric context. To get at those numbers, Perl will translate this to something like print @a.FETCHSIZE + $b.FETCHNUM And will promptly get a run-time error for the latter (maybe just a warning). The underlying object is not designed to be used in numeric context: it relies on a variable to call the appropriate methods to get its numeric value (Of course, an array object could define FETCHNUM to delegate to FETCHSIZE: but that obscures the point: a variable's type defines which methods are called in various contexts). Now consider a more extreme (and probably very bad) example: imagine we want to (lexically) redefine how an array behaves in numeric context: Lets say that we want it to use the sum of its elements, not its size. We don't want to modify the object itself (except to give it the C method): we simply want Perl to use the object slightly differently: my @a = (1,2,3) but implements_sum_method; # add .sum method to vtable my SummingArray $b := @a; The type of $b refers to the variable's type, not the object's. Let us suppose that the type-definition syntax allows us to tell perl: "when you use this variable in numeric context, call your object's C method.". now, when we code print @a + $b; perl maps this to print @a.FETCHSIZE + $b.sum; and prints 9. We don't need the variable-type magic, of course. We could have just said print @a + @a.sum; and gotten the same result. But the ability to express the behaviour of variables, independently of values, could be useful (and more powerful than a c). Dave.
Re: GC/DOD feedback & runtime tuning
Dan Sugalski wrote: At 12:52 AM +0100 1/3/03, Leopold Toetsch wrote: Dan Sugalski wrote: First, the resource system falls down hard when doing lots of allocations with no deallocations. It gets exponentially slower, which is a Bad Thing. 1) parrot compiled -O3 (classes/Makefile is br0ken, doesn't get CFLAGS from Configure) - but unoptimized is still faster then perl5 :-) 2) I did finetune block allocation, which did cause DOD runs too often. Memory blocks are growing too now. 3) Changed growing factor for PMCs from 4 to 1.5 and started with a bigger initial size. Growing too aggressively causes far too many PMCs allocated for programs with many live objects. Also I did introduce some (arbitrary) upper limit for pool size. >>> Second, Array and its subclasses need some performance thumping, as >>> they seem to come in at about half the speed of perl 5. 4) classes/perlarray.pmc was totally unoptimized (cut&paste blabla). $ time parrot stress.pbc real0m0.508s user0m0.430s sys 0m0.080s $ time parrot -j stress.pbc real0m0.420s user0m0.350s sys 0m0.070s $ time perl examples/benchmarks/stress.pl real0m0.643s user0m0.610s sys 0m0.030s But, this is not the original stress.pasm it is a worse one, more similar to the perl version (you were reusing P0 for @arr1 and @arr2, while mine does allocate new arrays leading to more live objects). perl: 5.8.0 -Duselongdouble (which shouldn't matter here) i386/linux, athlon 800, 256 Meg I'll comment the changes a little bit more and [ ] send patch [ ] check it in? leo
Re: [PASM] PerlHash and keys
Leopold Toetsch wrote: > There is a nextkey_keyed mentioned in pdd02_vtables.pod, which would > almost be all to implement aggregate iterators. Missing is IMHO how to > reset (start) an iteration. > Also not too long ago, there was some proposal WRT an iterator class. I was the proposer. I have written an Iterator PMC back in the ol' 0.0.8 days, but then I was distracted and never finished my work. I will try to reimplement my addition to 0.0.9 and submit a patch ASAP (probably after 07 jan ;-). > This proposal needed more vtable functions. yes, it does. > Also not specified: how to attach an iterator to an aggregate. this was solved with the implementation of the 'assign' op. cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print;
Re: PRE / POST in loops
Luke Palmer wrote: > The difference between POST and NEXT is simply that POST fails to > refrain from executing after the final iteration, while NEXT does not. Or in other words: The difference between POST and NEXT is that POST executes after the final iteration, while NEXT does not. NEXT happens before the next item, POST happens after each item. > I hope this clarified things. It has failed to refrain from unenlightening me. :-) A
