On Monday 21 April 2008 19:17:34 Bob Rogers wrote:
> The hack is attached; it isn't headerized, has some coding standards
> failures, and leaks memory, so it's incomplete. Disappointingly, it
> produces an overall speedup of less than 4% in building gen_actions.pir
> in r27087 (which has chromati
From: Bob Rogers <[EMAIL PROTECTED]>
Date: Mon, 21 Apr 2008 18:54:19 -0400
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Mon, 21 Apr 2008 15:42:27 -0500
. . . If it looks like having a separate stack for bsr/ret is
workable then I'll go at it that way.
Fai
From: Bob Rogers <[EMAIL PROTECTED]>
Date: Mon, 21 Apr 2008 18:54:19 -0400
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Mon, 21 Apr 2008 15:42:27 -0500
. . . If it looks like having a separate stack for bsr/ret is
workable then I'll go at it that way.
Fai
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Mon, 21 Apr 2008 15:42:27 -0500
On Mon, Apr 21, 2008 at 04:31:17PM -0400, Bob Rogers wrote:
>There is another solution that ought to speed up "bsr" dramatically:
> Give the "bsr" return addresses their own stack.
I thou
Am Montag, 21. April 2008 22:49 schrieb chromatic:
> On Monday 21 April 2008 13:44:44 Patrick R. Michaud wrote:
> > On Mon, Apr 21, 2008 at 04:38:52PM -0400, Bob Rogers wrote:
> >
> > Thanks again. I was misreading from comments in stack_push, which
> > say that it pushes things onto the "generic
On Monday 21 April 2008 13:44:44 Patrick R. Michaud wrote:
> On Mon, Apr 21, 2008 at 04:38:52PM -0400, Bob Rogers wrote:
> Thanks again. I was misreading from comments in stack_push, which
> say that it pushes things onto the "generic stack" when in reality
> it seems to use whatever stack is pa
On Mon, Apr 21, 2008 at 04:38:52PM -0400, Bob Rogers wrote:
>From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
>Date: Mon, 21 Apr 2008 14:25:53 -0500
>
>. . . this seems to be the case for everything using the
>"generic stack", which AFAICT is the &interp->dynamic_env structure.
>
>
On Mon, Apr 21, 2008 at 04:31:17PM -0400, Bob Rogers wrote:
>From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
>Date: Mon, 21 Apr 2008 14:55:21 -0500
>
>> On Mon, Apr 21, 2008 at 8:25 PM, Patrick R. Michaud <[EMAIL PROTECTED]>
> wrote:
>> > I think we'd get a BIG win if we changed t
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Mon, 21 Apr 2008 14:25:53 -0500
. . . this seems to be the case for everything using the
"generic stack", which AFAICT is the &interp->dynamic_env structure.
Your point is correct, except that you are talking about the "dynamic
envi
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Mon, 21 Apr 2008 14:55:21 -0500
> On Mon, Apr 21, 2008 at 8:25 PM, Patrick R. Michaud <[EMAIL PROTECTED]>
wrote:
> > I think we'd get a BIG win if we changed the dynamic_env stack to
> > have an approach similar to ResizableInt
On Mon, Apr 21, 2008 at 02:25:53PM -0500, Patrick R. Michaud wrote:
>
> The parts of the stack code we've discussed eliminating is actually
> the user_stack, used for push/pop/saveall/restoreall opcodes.
I inadvertently wrote push/pop here where I really meant save/restore.
The push/pop opcode
On Mon, Apr 21, 2008 at 08:48:10PM +0100, Klaas-Jan Stol wrote:
> On Mon, Apr 21, 2008 at 8:25 PM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> > I think we'd get a BIG win if we changed the dynamic_env stack to
> > have an approach similar to ResizableIntegerArray, where we allocate
> > arra
On Monday 21 April 2008 12:25:53 Patrick R. Michaud wrote:
> To me, the scary part of src/stacks.c is at the beginning:
>
> The stack is stored as a linked list of chunks (C),
> where each chunk has room for one entry.
>
> Eek! For something like bsr_ic, which is really just pushing a
> r
On Mon, Apr 21, 2008 at 8:25 PM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 21, 2008 at 10:19:08AM -0700, chromatic wrote:
> > I'm still exploring the Rakudo build progress as a profiling target for
> likely
> > optimizations. After this weekend's work, I have src/gen_actions.p
On Mon, Apr 21, 2008 at 10:19:08AM -0700, chromatic wrote:
> I'm still exploring the Rakudo build progress as a profiling target for
> likely
> optimizations. After this weekend's work, I have src/gen_actions.pir
> generation down to 27,788,055,796 instructions (with an optimized Parrot). A
>
I'm still exploring the Rakudo build progress as a profiling target for likely
optimizations. After this weekend's work, I have src/gen_actions.pir
generation down to 27,788,055,796 instructions (with an optimized Parrot). A
big chunk of that time goes to support bsr_ic:
7,784,136,854 core.
16 matches
Mail list logo
