On Tue Oct 02 10:24:02 2007, pcoch wrote:
> In the file src/mmd.c there is the todo item within
> mmd_create_builtin_multi_meth_2():
>
> * TODO cache the namespace
>
> Do this. (please)
This function (and the TODO) are no longer present after the recent MMD
mer
On Sat May 17 14:55:53 2008, pmichaud wrote:
> On Mon Jun 12 16:30:13 2006, jonathan wrote:
> > Both Parrot_store_global and store_sub call
> Parrot_invalidate_method_cache,
> > however the versions of these that take keys (Parrot_store_global_p and
> > store_sub_p) fail to do so.
>
> Is this t
On Mon Jun 12 16:30:13 2006, jonathan wrote:
> Both Parrot_store_global and store_sub call
Parrot_invalidate_method_cache,
> however the versions of these that take keys (Parrot_store_global_p and
> store_sub_p) fail to do so.
Is this ticket still relevant after the pdd15oo changes incorporated
hod cache invalidation should be a namespace function */
Parrot_invalidate_method_cache(interp, str_key, globalname);
ary hack to notice when key is actually a string, so that
* the legacy logic for invalidating method cache will be called; this
* is not good enough but it avoids regressesions for now
hod cache invalidation should occur */
ect()):
/*
* quick'n'dirty method cache
* TODO: use a hash if method_name is not constant
* i.e. from obj.$Sreg(args)
* If this hash is implemented mark it during DOD
*/
One would guess this needs implementing more robustly
h_2():
* TODO cache the namespace
Do this. (please)
# New Ticket Created by Jonathan Worthington
# Please include the string: [perl #39430]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=39430 >
Both Parrot_store_global and store_sub call Parrot_invalidate_method_cache,
ho
Brad Bowman (via RT) wrote:
Looking through pobj.h, I found what seems to be a dated
comment referring to "cache.*". I don't think this exists
anymore, unless it's referring to hashval in some oblique way.
Sorry for the delay, I must have missed it. Anyway, your obser
to "cache.*". I don't think this exists
anymore, unless it's referring to hashval in some oblique way.
UINTVAL hashval; /* cached hash value computation; not yet used */
};
-/* cache.* is intended to just be *shortcuts* to*/
-/* commonly-accessed
On Jul 9, 2005, at 19:37, Nicholas Clark wrote:
On Fri, Jul 08, 2005 at 06:52:28PM +0200, Leopold Toetsch wrote:
No, for sure not. And AFAIK it's not needed nor used. Please drop
this line.
Done, although curiously it did involve changing 1 line in io/io.c
Thx. Fixed that line too.
Nic
On Fri, Jul 08, 2005 at 06:52:28PM +0200, Leopold Toetsch wrote:
> No, for sure not. And AFAIK it's not needed nor used. Please drop this line.
Done, although curiously it did involve changing 1 line in io/io.c
Nicholas Clark
Nicholas Clark wrote:
Line 216 of pobj.h has:
#define cache obj.u
Is redefining such a common name a good idea?
No, for sure not. And AFAIK it's not needed nor used. Please drop this line.
Nicholas Clark
Thx,
leo
Line 216 of pobj.h has:
#define cache obj.u
Is redefining such a common name a good idea?
Nicholas Clark
If a name is stored into a namespace that starts with two underscores,
the method cache is invalidated now.
The follwing program runs now as expected:
.sub main @MAIN
.local pmc o, cl
newclass cl, "Foo"
subclass cl, cl, "Bar"
$I0 = typeof cl
o = new $I0
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
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 b
to sweep through, as well as speeding
> up allocation (since we're more likely to have ones at hand, and
> likely in cache too) of the things in the first place.
And, dammit, making a full continuation isn't something a programmer
should do lightly.
sed in the near-overwhelming majority of the cases
-- that is, when nothing can possibly have a hold of 'em. That leaves
a lot fewer objects for the DOD to sweep through, as well as speeding
up allocation (since we're more likely to have ones at hand, and
likely in cache too) of the things in th
All~
I don't like the idea of having to dig down through the entire return
chain promoting these guys. Is there a reason not to use DOD/GC to
recycle continuations?
Matt
On Tue, 2 Nov 2004 14:10:09 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 6:51 PM +0100 11/2/04, Leopold Toetsch wrote
At 6:51 PM +0100 11/2/04, Leopold Toetsch wrote:
* The stack frame caching is back, hopefully now implemented correctly:
1) when a return continuation is invoked the stack frame is recycled
2) when a continuation is created, all the return continuations up the
call chain are converted to re
* The stack frame caching is back, hopefully now implemented correctly:
1) when a return continuation is invoked the stack frame is recycled
2) when a continuation is created, all the return continuations up the
call chain are converted to real continuations by changing the
vtable. This
Here are recent numbers with the new method cache:
$ perl tools/dev/parrotbench.pl -c=parrotbench.conf -b=^oo
Numbers are relative to the first one. (lower is better)
parrotj parrot parrotC perl-th perlpython ruby
oo1 100%104%106%98% 83% 54% 70%
oo2
I am still _way_ behind on my perl6 e-mail but there has been
a spate of discussion on gcc list about how garbage collector
is bad for data-cache locality (particularly temporal locality).
At least some of gcc folk are considering a switch to refcounts
to try and get gcc-3.* back to nearer
Ars Technica's got a reasonably nice explanation of CPU caches at
http://arstechnica.com/paedia/c/caching/caching-1.html, for the
interested.
--
Dan
--"it's like this"---
Dan Sugalski
This is the first step of three major changes coming over the weekend.
The only change visible to the assembler will be the syntax 'set
P0[3],7' and 'set P5["foo"],P30[7]' for accessing array and hash
aggregates. The changes should also allow us to implement
multidimensional arrays.
--
Jeff <[EMAI
At 03:48 PM 9/28/00 +, John van V wrote:
>How would the byte-compiled caches relate to the compiled C code XS'd into
>the modules??
When a module is built, in addition to transforming any XS code (or
whatever it ultimately is) into an executable, perl will also compile any
perl code into b
How would the byte-compiled caches relate to the compiled C code XS'd into the
modules??
Could it be embedded, I think not, but please enlighten me.
he neck to install in AFS. It's one of the
hardest software packages that we have to support because of the cache
directory. We tried to maintain it like it's supposed to work, and it
failed miserably. We finally had to give up completely and wrap Purify to
redirect the cache directo
st
RA> compile at installation time and then leave it alone.
This isn't really a problem. Purify does this already. If it is not
allowed to write into the original directory, You give it a cache
directory and it does appropriate magic to map to the original file
and associate the correct user t
nstaller would do this when the program was installed), but I can
see times when it'd be useful. Perhaps it should be optional and only done
if requested with a command-line switch. -C (for cache) perhaps.
You'd also want the startup to check all the dependencies in the bytecode
(in case mo
Michael Maraist <[EMAIL PROTECTED]> writes:
> I suggested this a while ago, and the response was that automatically
> writing files is a security risk. You should extend your RFC to
> describe a caching directory or configuration.
This will be completely impossible to implement in some installa
t_ cause problems if not implemented correctly
(namely that a perl and module version is associated with each .p[lm]c
file).
In general, I'm for the idea, but I figured I'd pass on the obsticles I
encountered.
To further your RFC, I'd suggest working out a configuration for a .*c
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Cache byte-compiled programs and modules
=head1 VERSION
Maintainer: Simon Cozens <[EMAIL PROTECTED]>
Date: 25 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 301
Version: 1
Status: Deve
35 matches
Mail list logo
