optimizing StgPtr allocate (Capability *cap, W_ n)
Hello Glasgow-haskell-users,
i'm looking a the
https://github.com/ghc/ghc/blob/23bb90460d7c963ee617d250fa0a33c6ac7bbc53/rts/sm/Storage.c#L680
if i correctly understand, it's speed-critical routine?
i think that it may be improved in this way:
StgPtr allocate (Capability *cap, W_ n)
{
bdescr *bd;
StgPtr p;
TICK_ALLOC_HEAP_NOCTR(WDS(n));
CCS_ALLOC(cap-r.rCCCS,n);
/// here starts new improved code:
bd = cap-r.rCurrentAlloc;
if (bd == NULL || bd-free + n bd-end) {
if (n = LARGE_OBJECT_THRESHOLD/sizeof(W_)) {
}
if (bd-free + n = bd-start + BLOCK_SIZE_W)
bd-end = min (bd-start + BLOCK_SIZE_W, bd-free +
LARGE_OBJECT_THRESHOLD)
goto usual_alloc;
}
}
/// and here it stops
usual_alloc:
p = bd-free;
bd-free += n;
IF_DEBUG(sanity, ASSERT(*((StgWord8*)p) == 0xaa));
return p;
}
i think it's obvious - we consolidate two if's on the crirical path
into the single one plus avoid one ADD by keeping highly-useful bd-end pointer
further improvements may include removing bd==NULL check by
initializing bd-free=bd-end=NULL and moving entire if body
into separate slow_allocate() procedure marked noinline with
allocate() probably marked as forceinline:
StgPtr allocate (Capability *cap, W_ n)
{
bdescr *bd;
StgPtr p;
TICK_ALLOC_HEAP_NOCTR(WDS(n));
CCS_ALLOC(cap-r.rCCCS,n);
bd = cap-r.rCurrentAlloc;
if (bd-free + n bd-end)
return slow_allocate(cap,n);
p = bd-free;
bd-free += n;
IF_DEBUG(sanity, ASSERT(*((StgWord8*)p) == 0xaa));
return p;
}
this change will greatly simplify optimizer's work. according to my
experience current C++ compilers are weak on optimizing large
functions with complex execution paths and such transformations really
improve the generated code
--
Best regards,
Bulat mailto:bulat.zigans...@gmail.com
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
status of rebindable syntax for arrows
The GHC manual already for quite a number of version states:
• Arrow notation (see Section 7.17, “Arrow notation ”) uses whatever
arr, (), first, app, (|||) and loop functions are in scope.
But unlike the other constructs, the types of these functions must
match the Prelude types very closely. Details are in flux; if you want to use
this, ask!
When using this feature we get the error:
Var/Type length mismatch:
[s{tv aVL} [tv]]
[]
ghc: panic! (the 'impossible' happened)
(GHC version 7.8.3 for x86_64-apple-darwin):
tcTyVarDetails s{tv aVL} [tv]
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug;
So our question is whether we should really report this as a bug, and/or what
we can do about this.
Thanks for your help,
Doaitse
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: The future of the haskell2010/haskell98 packages - AKA Trac #9590
Title: Re: The future of the haskell2010/haskell98 packages - AKA Trac #9590 Hello Brandon, Wednesday, October 1, 2014, 1:02:54 AM, you wrote: On Tue, Sep 30, 2014 at 5:00 PM, Malcolm Wallace malcolm.wall...@me.com wrote: How about doing the honest thing, and withdrawing both packages in ghc-7.10? Haskell'98 is now 15 years old, and the 2010 standard was never really popular anyway. There are apparently educators using both, although they're not used much if at all in production. does they need latest GHC version? an option may be to drop support of Haskell'98 in GHC 7.10, then implement superclass proposal in GHC 7.12 and return haskell'98 support -- brandon s allbery kf8nhsine nomine associates allber...@gmail.comballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net -- Best regards, Bulat mailto:bulat.zigans...@gmail.com ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: status of rebindable syntax for arrows
On Tue, Oct 14, 2014 at 10:26:46PM +0200, S. Doaitse Swierstra wrote:
The GHC manual already for quite a number of version states:
• Arrow notation (see Section 7.17, “Arrow notation ”) uses whatever
arr, (), first, app, (|||) and loop functions are in scope.
But unlike the other constructs, the types of these functions must
match the Prelude types very closely. Details are in flux; if you want to use
this, ask!
When using this feature we get the error:
Var/Type length mismatch:
[s{tv aVL} [tv]]
[]
ghc: panic! (the 'impossible' happened)
(GHC version 7.8.3 for x86_64-apple-darwin):
tcTyVarDetails s{tv aVL} [tv]
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug;
So our question is whether we should really report this as a bug, and/or what
we can do about this.
It already has a bug entry: #7828. What would help is to know the kind
of use you have in mind, to see whether it fits with the proposed solution.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
