[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