[Haskell-cafe] the last mile in haskell performance

Kosyrev Serge skosyrev at ptsecurity.com
Tue Nov 17 09:50:42 UTC 2015


"Alberto G. Corona " <agocorona at gmail.com> writes:
> Hi Will,
> Right, I'm not an expert on low level things, but yes, each memory
> page can cache a different vector and even can work faster. Specially
> if the algoritm uses a few fields of a large structure. I was wrong on
> that.
>
> But anyway, Unboxed need more native support to give Haskell more
> credibility in performance critical problems. Now it has some
> conversion overhead for user defined data. That may be optimized away
> but the whole thing is second class, via an instance instead of a
> language feature.
>
> Maybe automatic deriving Unboxed instances can be the right compromise

Given how the imagination immediately suggests that:

  1. performance nuances dictated by the context might suggest different
     preferences for Unboxed encodings..

  2. and, on the other hand, given the undesirability of always engaging
     oneself into full-blown instance definition -- for various reasons..

..it suggests that a language feature would be helpful, that would allow
to gradually inform the derivation GHC makes, without fully engaging into
specifying complete details.

Can we imagine that a derivation could proceed, for example, from:

  - a /subset/ of minimal typeclass definition, or alternatively
  - direct parameters

..?

Also, a set of deeper questions could be asked, if you can forgive me this
daydreaming..

If we follow the spirit of self-defined languages (won't name them):

 1. does it make sense to "open up" the process of derivation?

 2. what prevents us from describing derivations as a functional transformation?

 3. what is the possible language for these -- TH? something else?


-- 
с уважениeм / respectfully,
Косырев Сергей


More information about the Haskell-Cafe mailing list