At 3:50 PM -0400 8/17/02, Dan Sugalski wrote:
>At 3:07 PM +0200 8/14/02, Josef Hook wrote:
>>I've moved all code into one file now.
>
>Cool. Would someone commit this, please?
Nevermind--I did.
--
Dan
--"it's like this
> Attached is my first cut of a patch to address the keyed access issues.
First, thanks for spending the time to implement and clean up the keyed
code. Hopefully this'll clean the floor so that when this list has key
discussions, we'll all be arguing about the same thing. :)
> This patch doesn't
Applied, thanks.
Mike Lambert
> This is a config test for the direction of stack growth that makes
> the direction a compile time constant.
>
> --
> Jason
Applied, thanks.
> Moved the static prototype to dod.c
>
> Jason
On Sun, Aug 18, 2002 at 02:51:34AM +, Jason Gloudon wrote:
> # New Ticket Created by Jason Gloudon
> # Please include the string: [perl #16278]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt2/Ticket/Display.html?id=16278 >
Moved the static
# New Ticket Created by Jason Gloudon
# Please include the string: [perl #16278]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=16278 >
This patch modifies the stack walking code to create a prefix mask for doing a
fast a
The POD below my sig is a proposed PDD on external data interfaces, that
is, the way embedders and extenders will access Parrot's data types. It
covers Strings, Buffers, and PMCs, as well as a few related functions.
Let me know what you think.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot
[EMAIL PROTECTED] (Dan Sugalski) writes:
> Has someone looked at and maybe committed this?
The reason I asked which pieces of Parrot were prototypes was because
optimizing the hell out of something that's only a prototype is nothing
short of intellectual masturbation, and it seems nobody actually
At 11:41 PM +0200 8/13/02, Jerome Quelin wrote:
>Well, I don't know if this is interesting, but here's a patch that implement:
>op rand(out NUM)
>op rand(out NUM, in INT)
>
>and does what you can guess. There's also a test file (I don't know wether
>the tests should go in an existant test
At 8:45 AM +0200 8/7/02, Angel Faus wrote:
>Dan Sugalski escribió:
>> At 8:40 AM +0200 8/6/02, Angel Faus wrote:
>> >The point about the lack of documentation remains, and i will
>> > solve it as soon as i get an indication that the design is ok.
>>
>> The design's fine, and we can add what we
At 9:33 PM -0400 8/16/02, Melvin Smith wrote:
>At 03:45 PM 8/16/2002 -0400, Jerrad Pierce wrote:
>>I was wondering if perl would be handling negative array indices in the
>>same manner as perl 5?
>>That is to FETCHSIZE + index = real index, before attempting to fetch
>>the element.
>>It would be s
Jason Gloudon wrote:
> The configure-time-stack-growth-direction patch makes these #define'd
constants,
> so you get the same speedup.
Do you also have a patch to determine the minimum stack increment?
The IA32 architecture, for example, has no restrictions on pointer
alignment (and hence PARROT
On Sat, Aug 17, 2002 at 10:23:32PM +0200, Peter Gibbs wrote:
> If you want to get some improvement at the cost of some duplicated
> code, you can remove the * direction logic, and write two copies of the
> loop. (patch attached, but not fully tested)
> I'm sure there is more that can be done, b
At 3:30 PM + 8/17/02, Tom Hughes (via RT) wrote:
>
>Attached is my first cut of a patch to address the keyed access issues.
>
>This patch doesn't do everything, but it does bring things more or less
>in line with Dan's recent specification I hope. I'm sure there are also
>problems with it so i
Mike Lambert wrote:
> As Peter has pointed out, our stackwalk code is rather slow.
> Anyone feeling adventuresome and want to attempt to speed this up?
If you want to get some improvement at the cost of some duplicated
code, you can remove the * direction logic, and write two copies of the
loo
At 3:07 PM +0200 8/14/02, Josef Hook wrote:
>I've moved all code into one file now.
Cool. Would someone commit this, please?
--
Dan
--"it's like this"---
Dan Sugalski even samur
As Peter has pointed out, our stackwalk code is rather slow.
The code that's in there was my first-attempt at the need for stack
walking code. There's one optimization in place, but the algorithm behind
the optimization could use some work.
Basically, it finds the min and max values of all heade
Hi Mike
Elapsed times for 'time parrot hanoi.pbc 14 > /dev/null' are:
CVS: 52.81, 52.05, 52.33
CVS + grey COW: 51.53, 52.06, 51.67
CVS + Mike's COW: 44.31, 44.48, 44.55
CVS + grey1: 35.89, 36.48, 36.60 (+COW +cyclecount -stackwalk)
End June grey: 30.14, 29.35, 29.53
And 5000 generations of life
At 8:53 AM + 8/17/02, Mike Lambert (via RT) wrote:
>
>However, in the interest of saving someone from updating yet-another COW
>patch in the long-distant future because this wasn't applied (similar to
>how Peter's patch got left to bit-rot), can we try to reach a closure on
>this patch (either
Mike Lambert wrote:
> Just for fun, can you run Hanoi on CVS versus CVS+COW?
>
> I just got COW implemented here, and while I get a 17% speedup on
> life, I get a 5% loss on hanoi. Since you only posted life, it's a
> bit hard to see if the drop on hanoi is just my fault, or the fault of
> COW in
# New Ticket Created by Mike Lambert
# Please include the string: [perl #16269]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=16269 >
I finally was able to get Peter's old COW patch up and running with our
current codebas
Peter Gibbs wrote:
> > How much of the speed win is from the cycle count instead of stack
> > walking? Unless you've solved the problem of recursive interpreter
> > calls and setjmp, it's not a valid solution, no matter what the speed
> > win might be.
> According to my notes the progression (fo
22 matches
Mail list logo
