Hi Max. Thanks much for passing on this info. Very encouraging news! -
Conal
On Wed, Mar 10, 2010 at 8:41 AM, Max Bolingbroke wrote:
> This is my understanding:
>
> Old story (GHC 6.12.1 (?) and below):
> 1) Function bodies are only optimised if they are not marked INLINE.
> The assumption is
This is my understanding:
Old story (GHC 6.12.1 (?) and below):
1) Function bodies are only optimised if they are not marked INLINE.
The assumption is that INLINE bodies will be inlined and then
optimised at the point where they are inlined.
2) Unfoldings are exported in .hi files for functions if
Here's a transcript from a conversation I had with Conal on IRC.
tl;dr: cross-module inlining is only possible because ghc
stashes a definition in a .hi, iuuc. i'm suggesting that the stashed
definition either (a) never include further inlinings, or (b) be
augmented by such a definition.
Full t
On Tue, Mar 9, 2010 at 11:53 AM, Conal Elliott wrote:
> I think Jake is referring to my vector-space package. He did the work of
> writing 171 INLINE pragmas, covering lots of methods and standalone function
> defs. I'm simultaneously grateful for the effort and repelled by the added
> syntacti
I think Jake is referring to my vector-space package. He did the work of
writing 171 INLINE pragmas, covering lots of methods and standalone function
defs. I'm simultaneously grateful for the effort and repelled by the added
syntactic noise. Also concerned about the impact of all these directive
jake.mcarthur:
> I've run into an issue with inlining that I'm not sure how to work
> around. I am instantiating some pre-existing type classes with
> Vector-based types. There already exist generic functions in modules I
> do not control that use this type class, and they are not tagged with
I've run into an issue with inlining that I'm not sure how to work
around. I am instantiating some pre-existing type classes with
Vector-based types. There already exist generic functions in modules I
do not control that use this type class, and they are not tagged with
the INLINE pragma. I am
On 06/03/2010, at 03:10, stefan kersten wrote:
> i'm still curious, though, why my three versions of direct convolution perform
> so differently (see attached file). in particular, i somehow expected conv_3
> to
> be the slowest and conv_2 to perform similar to conv_1. any ideas? i haven't
> had
On Mar 4, 2010, at 9:05 PM, Roman Leshchinskiy wrote:
> On 05/03/2010, at 04:34, stefan kersten wrote:
>
>> i've been hunting down some performance problems in DSP code using vector and
>> the single most important transformation seems to be throwing in INLINE
>> pragmas
>> for any function tha
> This is a general problem when working with RULES-based
> optimisations. Here is an example of what happens: suppose we have
>
> foo :: Vector Int -> Vector Int
> foo xs = map (+1) xs
>
> Now, GHC will generate a nice tight loop for this but if in a
> different module, we have something like th
On 05/03/2010, at 04:34, stefan kersten wrote:
> i've been hunting down some performance problems in DSP code using vector and
> the single most important transformation seems to be throwing in INLINE
> pragmas
> for any function that uses vector combinators and is to be called from
> higher-leve
sk:
> hi,
>
> two questions in one post:
>
> i've been hunting down some performance problems in DSP code using vector and
> the single most important transformation seems to be throwing in INLINE
> pragmas
> for any function that uses vector combinators and is to be called from
> higher-level c
hi,
two questions in one post:
i've been hunting down some performance problems in DSP code using vector and
the single most important transformation seems to be throwing in INLINE pragmas
for any function that uses vector combinators and is to be called from
higher-level code. failing to do so s
13 matches
Mail list logo
