[Haskell-cafe] the last mile in haskell performance

[Carter Schonwald]

Indeed! There's no one true best format.
There was some work to add native support for c structs to the Haskell ffi,
as storable format for non recursive records, but there's some really
gnarly subtleties with respect to alignment and packing that come up that
likely are fundamentally impossible to characterize in a simple algorithmic
fashion that will serve everyone well.

On Saturday, November 14, 2015, Will Yager <will.yager at gmail.com> wrote:

> This is why CPUs have many independent cache lines. Unpacking a vector
> into multiple vectors is usually fine for performance. I have seen it
> actually increase performance, because it simplifies addressing.
>
> -Will
>
> On Nov 14, 2015, at 05:30, Alberto G. Corona <agocorona at gmail.com
> <javascript:_e(%7B%7D,'cvml','agocorona at gmail.com');>> wrote:
>
>
> This is nice in some cases, but does most of the time does not. this does
> not solve the problem of CPU cache since the fields in the data are at
> least lenght (Vector)  away. I mean that if the vector is moderately long,
> if the first field is in the cache, the second or third etc may not be.
> Usually the fields of any data are handled together.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151114/925bfd84/attachment.html>