foldable flexible bridges (putting foldable+traversable in prelude) Re: Burning bridges

[Carter Schonwald]

Indeed. Type annotations, inlining, and writing monomorphic functions are
quite handy for making tight inner loops.

As are making sure there are no bad branch predictors, that memory locality
quality is superb, and that if possible SIMD instructions, and
cache hierarchy aware parallelism.

At the same time, these are not AND should not be the concerns of normal
end user codes. Tuning tight inner loops is a nontrivial task engineering
task in any language, providing generic apis by default does not prevent
writing monomorphic versions as needed.

Unless you have an example where for normal application code there will be
a significant constant factor difference in performance with the proposed
changes, i don't understand your contention :)

Also, for those sorts of problems as you point at, what is an example that
can't be resolved with the inlinable + specialize pragmas, that wouldn't
otherwise be a problem anyways?

Anyways, I do care about performance, but small constant factors are
cheaper to fix if need be than are the constant factors in better base api.
Anyone who's privy to my work over the past few months know I quite
literally spend all my time thinking about memory locality :)

cheers
-Carter


On Sun, May 26, 2013 at 5:21 AM, Malcolm Wallace <malcolm.wallace at me.com>wrote:

>
> On 21 May 2013, at 06:06, Carter Schonwald wrote:
>
> > lets see what concerns there are
> >
> > 1) will any code break? Nope!
> > 2) does the change make learning the language more challenging? No.
>
> One concern that is conspicuously missing from your list is
>
> 3) performance.  Will my code get slower, because it now has many more
> class dictionaries, requiring new runtime indirections?
>
> I quote from the GHC manual:
>
> "Overloaded functions are not your friend:
> Haskell's overloading (using type classes) is elegant, neat, etc., etc.,
> but it is death to performance if left to linger in an inner loop."
>
> Regards,
>     Malcolm
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130526/bf09e052/attachment.htm>