Re: Object semantics
Dan Sugalski <[EMAIL PROTECTED]> writes: > 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. :) Hey, I know some of the Parrot developers are young, but it doesn't necessarily follow that they have acne. -- Piers
Re: More thougths on DOD
Mitchell N Charity wrote: The attached patch adds a scheme where: - gc flags are in the pool, and - pmc->pool mapping is done with aligned pools and pmc pointer masking. Observations: - It's fast. (The _test_ is anyway.) I did try it and some more in realiter. Summary: its slower :-( Calculating the flags position in the pool in pobject_lives() and free_unused_pobjects() takes more time then the smaller cache foot_print does gain. Two reasons: positions have to be calced twice and cache is more stressed with other things, IMHO. There seems to be remaining only: smaller PMCs for scalars. leo
Re: This week's Perl Summary
Steve Fink <[EMAIL PROTECTED]> writes: > On Jan-04, Leopold Toetsch wrote: >> Damian Conway wrote: >> >> >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 >> >> Remembering e.g. perl6 operator threads, brrr, I just can say ... >> >> >Thank-you, Piers! >> >> me2 > > Me3. But watch out -- you are single-handedly responsibility for the > sanity of hundreds of us, and are therefore responsible for anything > we might do in this unnatural state. I accept no responsibility for any such actions, and reserve the right to cease producing summaries at any time (but not in the foreseeable future). Now, I've got the perl6-internals section of the christmas/new year summary written, hopefully I'll have the perl6-language and other bits written and mailed out later today. Hang in there people. -- Piers
Re: More thougths on DOD
Summary: its slower :-(
:(
Calculating the flags position in the pool in pobject_lives() and
free_unused_pobjects() takes more time then the smaller cache foot_print
does gain. Two reasons: positions have to be calced twice and cache is
more stressed with other things, IMHO.
Hmm... the first reason, a second bit of pointer arithmetic, seems
surprising, cycles being sooo much cheaper than cache misses. So I
modified the tpmc test with a second calc. Plus two extra function
calls to make sure it wasn't optimized away (to a separately compiled
file and back). The two real test cases (linear flag-only walk, and
random PMC->flag) were fine (unchanged and perhaps 1/3 slower), though
the fast toy case of linear PMC->flag was 5x slower (still faster than
the equivalents). So it's not the first reason.
That leaves the cache being stressed by other things.
Do we have any candidates?
I'd expect some interference effects between flag arrays, given _lots_
of arrays and random access. I'm not sure the stressX benchmarks are
"lots" enough. But while this interference might be worse in reality
than in the test program, it should still be much less than for
touching PMCs (say by 10x). So that doesn't seem a likely candidate.
Is the gc run doing anything memory intensive aside from the flag fiddling?
I don't suppose it is still touching the PMC bodies for any reason?
Puzzled,
Mitchell
("[..] in realiter"?)
Message-ID: <[EMAIL PROTECTED]>
Date: Wed, 08 Jan 2003 15:00:38 +0100
From: Leopold Toetsch <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: P6I <[EMAIL PROTECTED]>, Dan Sugalski <[EMAIL PROTECTED]>
Subject: Re: More thougths on DOD
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Mitchell N Charity wrote:
> The attached patch adds a scheme where:
> - gc flags are in the pool, and
> - pmc->pool mapping is done with aligned pools and pmc pointer masking.
>
> Observations:
> - It's fast. (The _test_ is anyway.)
I did try it and some more in realiter.
Summary: its slower :-(
Calculating the flags position in the pool in pobject_lives() and
free_unused_pobjects() takes more time then the smaller cache foot_print
does gain. Two reasons: positions have to be calced twice and cache is
more stressed with other things, IMHO.
There seems to be remaining only: smaller PMCs for scalars.
leo
Re: More thougths on DOD
At 6:15 PM -0500 1/6/03, Mitchell N Charity wrote: +pool_pmc[i] = memalign(ALIGN, SIZE*sizeof(PMC)); This is the only problem--memalign's not universal unless we build with the malloc we provide. Have we looked into whether we can mix this malloc with the current memory allocation system? -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #19807] [PATCH] rx.ops doc typos
At 10:09 PM + 1/7/03, Jim Radford (via RT) wrote: I found a few typos while reading through the documentation in rx.ops. Applied, thanks. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[perl #19834] [PATCH] sub, add, mul, div with combinations of INT, NUM, PMC
# New Ticket Created by Bernhard Schmalhofer
# Please include the string: [perl #19834]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=19834 >
Hi,
I have been looking into the possibility of adding complex numbers as PMCs.
When looking at core.ops I was missing some operations, where INT, NUM
and PMC interact.
For addition I found the operations:
add_i_i, add_n_n, add_p_i, add_p_n, add_p_p, add_i_i_i, add_n_n_n,
add_p_p_i, add_p_p_p.
Trying to make this more consistent I added:
add_n_i, add_n_n_i and app_p_p_n.
This means that there are now 12 addition ops.
I also brought 'sub', 'mul' and 'div' to the same level.
I have put some tests in t/op/arithmetics.t. Each of the operations
mentioned above should be called in the test.
However I still wonder about operations like 'div_p_n_p'. Unlike
'div_p_p_n', it can't be implemented with the vtable-function divide_float.
I have attached the patch for core.ops and the file arithmetics.t.
CU, Bernhard
--
*
Bernhard Schmalhofer
Senior Developer
Biomax Informatics AG
Lochhamer Str. 11
82152 Martinsried, Germany
Tel:+49 89 89 55 74 - 839
Fax:+49 89 89 55 74 - 25
PGP:https://ssl.biomax.de/pgp/
Email: mailto:[EMAIL PROTECTED]
Web:http://www.biomax.de
*
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/47101/37035/779e55/core.ops.patch
-- attachment 2 --
url: http://rt.perl.org/rt2/attach/47101/37036/45ee9d/arithmetics.t
--- core.opsWed Jan 8 20:13:48 2003
+++ core.ops.20020108 Wed Jan 8 18:57:49 2003
@@ -1279,8 +1279,6 @@
=item B(inout INT, in INT)
-=item B(inout NUM, in INT)
-
=item B(inout NUM, in NUM)
=item B(inout PMC, in INT)
@@ -1293,14 +1291,10 @@
=item B(out INT, in INT, in INT)
-=item B(out NUM, in NUM, in INT)
-
=item B(out NUM, in NUM, in NUM)
=item B(inout PMC, in PMC, in INT)
-=item B(inout PMC, in PMC, in NUM)
-
=item B(inout PMC, in PMC, in PMC)
Set $1 to the sum of $2 and $3.
@@ -1312,11 +1306,6 @@
goto NEXT();
}
-inline op add(inout NUM, in INT) {
- $1 += $2;
- goto NEXT();
-}
-
inline op add(inout NUM, in NUM) {
$1 += $2;
goto NEXT();
@@ -1342,11 +1331,6 @@
goto NEXT();
}
-inline op add(out NUM, in NUM, in INT) {
- $1 = $2 + $3;
- goto NEXT();
-}
-
inline op add(out NUM, in NUM, in NUM) {
$1 = $2 + $3;
goto NEXT();
@@ -1357,11 +1341,6 @@
goto NEXT();
}
-inline op add(inout PMC, in PMC, in NUM) {
- $2->vtable->add_float(interpreter, $2, $3, $1);
- goto NEXT();
-}
-
inline op add (inout PMC, in PMC, in PMC) {
$2->vtable->add(interpreter, $2, $3, $1);
goto NEXT();
@@ -1477,91 +1456,40 @@
-=item B(inout INT, in INT)
-
-=item B(inout NUM, in INT)
-
-=item B(inout NUM, in NUM)
-
-=item B(inout PMC, in INT)
-
-=item B(inout PMC, in NUM)
-
-=item B(inout PMC, in PMC)
-
-Divide $1 by $2.
-
=item B(out INT, in INT, in INT)
-=item B(out NUM, in NUM, in INT)
-
=item B(out NUM, in NUM, in NUM)
-=item B(inout PMC, in PMC, in INT)
-
-=item B(inout PMC, in PMC, in NUM)
-
=item B(inout PMC, in PMC, in PMC)
+=item B(inout PMC, in INT)
+
Set $1 to the quotient of $2 divided by $3. In the case of INTVAL division, the
result is truncated (NOT rounded or floored).
=cut
-inline op div(inout INT, in INT) {
- $1 /= $2;
- goto NEXT();
-}
-
-inline op div(inout NUM, in INT) {
- $1 /= $2;
- goto NEXT();
-}
-
-inline op div(inout NUM, in NUM) {
- $1 /= $2;
- goto NEXT();
-}
-
-inline op div (inout PMC, in INT) {
- $1->vtable->divide_int(interpreter, $1, $2, $1);
- goto NEXT();
-}
-
-inline op div (inout PMC, in NUM) {
- $1->vtable->divide_float(interpreter, $1, $2, $1);
- goto NEXT();
-}
-
inline op div(out INT, in INT, in INT) {
$1 = $2 / $3;
goto NEXT();
}
-inline op div(out NUM, in NUM, in INT) {
- $1 = $2 / $3;
- goto NEXT();
-}
-
inline op div(out NUM, in NUM, in NUM) {
$1 = $2 / $3;
goto NEXT();
}
-inline op div (inout PMC, in PMC, in INT) {
- $2->vtable->divide_int(interpreter, $2, $3, $1);
+inline op div (inout PMC, in PMC, in PMC) {
+ $2->vtable->divide(interpreter, $2, $3, $1);
goto NEXT();
}
-inline op div (inout PMC, in PMC, in NUM) {
- $2->vtable->divide_float(interpreter, $2, $3, $1);
+inline op div (inout PMC, in INT) {
+ $1->vtable->divide_int(interpreter, $1, $2, $1);
goto NEXT();
}
-inline op div (inout PMC, in PMC, in PMC) {
- $2->vtable->divide(interpreter, $2, $3, $1);
- goto NEXT();
-}
+
@@ -1703,28 +1631,18 @@
=item B(inout INT, in INT)
-=item B(inout NUM, in INT)
-
=item B(inout NUM, in NUM)
=item B(inout PMC, in INT)
-=item B(inout PMC, in NUM)
-
=item B(inout PMC, in PMC)
Set $1 to the product of $1
Re: [perl #19834] [PATCH] sub, add, mul, div with combinations of INT, NUM, PMC
At 7:41 PM + 1/8/03, Bernhard Schmalhofer (via RT) wrote: I have been looking into the possibility of adding complex numbers as PMCs. When looking at core.ops I was missing some operations, where INT, NUM and PMC interact. For addition I found the operations: add_i_i, add_n_n, add_p_i, add_p_n, add_p_p, add_i_i_i, add_n_n_n, add_p_p_i, add_p_p_p. Trying to make this more consistent I added: add_n_i, add_n_n_i and app_p_p_n. This means that there are now 12 addition ops. I also brought 'sub', 'mul' and 'div' to the same level. I have put some tests in t/op/arithmetics.t. Each of the operations mentioned above should be called in the test. However I still wonder about operations like 'div_p_n_p'. Unlike 'div_p_p_n', it can't be implemented with the vtable-function divide_float. I have attached the patch for core.ops and the file arithmetics.t. Applied, thanks. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
The perl 6 parser
Could one of the folks working on the perl 6 parser give us a status update as to where it stands? Which bits of the apocalypses don't work, and what parts of the regex definiton's not done yet? Things have stalled a bit, and I'd like to get it going again, and the perl 6 tests into the standard parrot test suite. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
LXR - source-code indexing
I am pleased to announce that LXR has been installed on perl.org to index the source of parrot and perl5 (additional modules, such as perl6, can be added as needed). So, you might be asking: "What is LXR?" LXR is a source-code indexing tool that was originally developed for the Linux kernel. With LXR, you can browse the source, search by filename (regular expression match), search by contents (regular expression match), or search for identifiers (functions, preprocessor macros, etc...). Furthermore, all source files are linkified, so that clicking on a function name gives the location where it was defined, and all references to that function (this works with subroutines in perl code too). LXR will even allow you to do diffs between two versions, comparing (for example) how a file changed between the 5.6.x branch and the 5.8.x branch. "And where can I get this tool if it is so great?" That's easy! Just hop on over to tinderbox.perl.org/lxr and choose the source-tree you want. You can then select the version you want to browse with from the top of the next page. But of course, there is always a catch. LXR is running rather slow at the moment, despite mod_perl. I think this is mostly because it needs more use for the cache to build up, but I'm going to try to do some more profiling and see where the problem is. Occasionally, LXR will return a blank or near-blank page. If you hit this bug, hitting reload a couple of times should make the correct file show up. The code is updated every night, parrot is pulled from the cvs repository at 11:00pm, and perl5 from the activestate rsync server at 1:00am. If you would like more frequent updates, please let me know and I can arrange for more. Please let me know about any bugs you hit or feature requests, and I'll do my best to incorporate them. Remember, it's tinderbox.perl.org/lxr. Zach
Re: More thougths on DOD
Mitchell N Charity wrote: Summary: its slower :-( :( Yep Calculating the flags position in the pool in pobject_lives() and free_unused_pobjects() takes more time then the smaller cache foot_print does gain. Two reasons: positions have to be calced twice and cache is more stressed with other things, IMHO. Hmm... the first reason, a second bit of pointer arithmetic, seems surprising, cycles being sooo much cheaper than cache misses. Here are the relevant bits: # define pool(o) ((struct Small_Object_Arena *) (PTR2UINTVAL(o) & POOL_MASK)) # define DOD_FLAGS(o) \ ((POOL_FLAG_TYPE *)pool(o)->flags) \ [((char*)(o) - (char*)(pool(o)->start_objects)) / pool(o)->object_size] (object_size is copied from pool, not currently there) This is a general version that plugs in as a replacement for PObj_get_FLAGS(o), but it was called only once per function. I think the real problems are here not the cycles of pointer arithmethic, there are different problems: - we can't use explicit pool pointers, handling flags directly is faster (getting the pool pointer has the same cache impact) - when there are no explicit pool pointers, something like above has to calulcate the pool position, which needs a fixed sized POOL_MASK i.e the pool size. - with fixed sized pools (buffer & PMCs) all alike, a List, List_chunk, Hash, String and so on, get all the same pool size, though they may be used just once, leading to huge buffer and bufferlike pools too. - e.g. stress.pasm needs 500K PMCs, fastest is to grow pools huge to some Megs of mem or finally ~200.000 PMCs per pool->arena. - e.g. life.pasm needs per cycle only ~ 50 strings, but needs really fast recycling of these, so the pool size should be not really bigger then the demand (which holds for all programs). - with fixed sized pools, I see no possibilty, to deal with these to extreme demands. - I did also try to not add_free all objects immediatly and reduce arena->used, so that the free_unused_pobjects is faster, but this needs a DOD run before. We don't know, in which header_pool is the shortage. And, when one pool holds ~10^6 objects and other pools ~nothing, a DOD run for allocating more for the rarely used pool is too expensive. stress.pasm with fixed sized pools spends the time in free_unused_pobjects() because there are too many (dead - or better never alive) objects around. ... So I modified the tpmc test with a second calc. The test is for one fixed sized pool with one header kind. We have pools for objects of sizeof Buffer, List_chunk, List, hash, PMC and probably more which may have very different header counts from 0 to 1e6 or more. All have to be somehow equally fast. We can trade a little bit to favor one kind of headers, but not all. We can't allocate a fixed size huge pool arena for the worst case, all others and memory consumption suffer. I don't suppose it is still touching the PMC bodies for any reason? No. But wading through the root set, zig header pools, marking stacks and so on, needs cache space. Puzzled, So was I. Tests looked really fine. BTW If you (or anyone) wants a patch just mail me Mitchell leo
Re: The perl 6 parser
On Wed, 8 Jan 2003, Dan Sugalski wrote: > Could one of the folks working on the perl 6 parser give us a status > update as to where it stands? languages/perl6/README mostly reflects the status with respect to the language definition of about 4-5 months ago. Differences include: - IIRC hyper-assignment operators are there. - regex capture groups are partial/flaky, not completely unimplemented. Joseph Ryan has updated string and numeric literals to correspond to the latest consensus on the list. Other than that, it's inconsistent with the current spec in a number of ways. A lot of it's just syntax (e.g. hyper-ops, for which I'll have to cut-and-paste the non-ASCII bits). The tests should all still pass (barring inclement GC bugs), but they reflect the outdated spec. /s
This week's summary
The Perl 6 Summary for the week ending 20030105 Hello and welcome to the first summary of 2003, welcome to the future. This summary covers 2 weeks, but they've been quietish what with Christmas and the New Year. So, starting as usual with perl6-internals A pile of patches to the Perl 6 compiler Joseph F. Ryan submitted a bunch of patches to the Perl 6 mini compiler, (found in the languages/perl6 subdirectory of your friendly neighbourhood parrot distribution) mostly implementing the the semantics for string and numeric literals discussed on perl6-documentation. Garbage Collection headaches Heads have been put together in an attempt to get Parrot's Garbage Collection system working efficiently and accurately (no destroying stuff before anyone's had a chance to use it, dammit!) It appears that there's still a good deal of head scratching to be done in this area (the chaps over on the LL1 list are wondering why we aren't just using the Boehm GC system...) I freely admit that GC makes my head hurt (especially as, in my current Perl 5 project I'm busy implementing mark and sweep collection for a persistent object store whilst also making sure that my random assortment of circular data structures has weakened references in just the right places so that stuff gets destroyed but only when it *should* be destroyed... Boy, am I looking forward to Perl 6 and not having to worry about this stuff ever again...) but I I'll have a go at summarizing the issues. The main problem appears to be that of 'Infant mortality', an issue that I will now attempt to explain. All the objects in memory can be represented as nodes in a graph, and the pointers between those objects can be represented as edges in that graph. The process of garbage collection involves taking a subset of those nodes (the rootset) and freeing (or marking as freeable) all those nodes in the graph which are not reachable from the rootset. Now, consider a function that sets up a new PMC, specifically a PMC that contains another PMC. The first step is grab the memory for our new PMC. Next we create the contained PMC, a process which allocates more memory... and there's the rub. Garbage Collection can get triggered at any point where we go to allocate more memory; unless the *containing* PMC is reachable from the rootset then it will get freed at the point. And that leads to badness. So the Infant Mortality problem can also be thought of as the problem of rootset maintenance. Which is, in theory, simple; just treat all C variables as members of the rootset. However, in practice it isn't that simple, mostly because hardware registers complicate the issue. Steve Fink offered an overview of the issues and some of the possible approaches to dealing with them, which sparked a fair amount of discussion amongst those who understood the issues. http://makeashorterlink.com/?K2FE52303 http://makeashorterlink.com/?Y20F32303 -- Steve's overview Variable/value vtable split Leo Tötsch posted a summary of where we stand on doing the variable/value vtable split, suggesting that he wanted to start feeding in patches soon. Mitchell N Charity supplied a handy dandy 'context' post with links to appropriate articles, and he and Leo did a certain amount of thrashing out of issues. http://makeashorterlink.com/?B11F21303 http://makeashorterlink.com/?G12F32303 Parrot gets another new language Ook! Jerome Quelin offered an implementation of the latest silly language, Ook! which can be thought of as brainf.ck for Librarians. Due to insanity, the Ook! compiler is implemented in Parrot assembly, and emits parrot assembly too, which led Jerome to ask for an 'eval' opcode. Which Leo promised to supply. And which Dan specced out in PDD6. All of which led Leo to comment that, for all these languages are toys, they do seem to be driving the implementation of important bits of Parrot. Nicholas Clark reminded everyone that a zcode interpreter would be another good thing to have a crack at because it would require a couple of other really useful bits of Parrot functionality. Ook! is now in the core. http://makeashorterlink.com/?R53F23303 Returning new PMCs David Robins wondered what was the resolution about creating and returning a new PMC in PMC ops that take a "PMC* dest" parameter. He and Dan discussed it back and forth and it became apparent that Dan really needs to get Parrot Objects defined... http://makeashorterlink.com/?Q24F21303 Fun with PerlHash Jerome Quelin noticed that you couldn't delete an item from a PerlHash. Leo fixed it. Jerome later asked how one could retrieve the keys of a PerlHash in Parrot assembly and wondered if there was a way to traverse a hash. Sadly the
Re: The perl 6 parser
Dan Sugalski wrote:
Could one of the folks working on the perl 6 parser give us a status
update as to where it stands? Which bits of the apocalypses don't
work, and what parts of the regex definiton's not done yet? Things
have stalled a bit, and I'd like to get it going again, and the perl 6
tests into the standard parrot test suite.
I think that before development kicks back up again, perhaps we use
the long absense to look objectively at P6C and look for potential
places to refactor.
For instance, one thing that I'd like to do is abstract operator
symbols from their node definition. After the monster operator
thread on p6-lang awhile back, at least 50% (guess) of the operators
are no longer the same as they used to be.
However, these symbols are still hardcoded into the Binop node type,
meaning that nearly every single module in P6C needs to be updated.
However, if the symbols were mapped to an operator name/number in the
tree deciphering phase in Tree.pm, then updating the operators would
be simple if future changes occur.
So, a node like this:
bless {
op => '_', # yes, it is '~' now, but there are still dozens of
# usages of '_' throughout P6C
l => bless {type=>'PerlUndef', name=>'$x'}, 'P6C::variable'
r => bless {type=>'PerlUndef', name=>'$y'}, 'P6C::variable'
}, 'P6C::Binop';
Might become:
bless {
op => 'concat',
l => bless {type=>'PerlUndef', name=>'$x'}, 'P6C::variable'
r => bless {type=>'PerlUndef', name=>'$y'}, 'P6C::variable'
}, 'P6C::Binop';
or
bless {
op => 1, # or whichever operator number concat is
l => bless {type=>'PerlUndef', name=>'$x'}, 'P6C::variable'
r => bless {type=>'PerlUndef', name=>'$y'}, 'P6C::variable'
}, 'P6C::Binop';
The operator name/number could then be resolved during IMCC code
generation phase using a dispatch table similar to the one already
in place.
Joseph F. Ryan
[EMAIL PROTECTED]
