Indeed! There's no one true best format.  <div>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. <span></span><br><br>On Saturday, November 14, 2015, Will Yager <<a href="mailto:will.yager@gmail.com">will.yager@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div></div><div>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. </div><div><br></div><div>-Will</div><div><br>On Nov 14, 2015, at 05:30, Alberto G. Corona <<a href="javascript:_e(%7B%7D,'cvml','agocorona@gmail.com');" target="_blank">agocorona@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr"><div><br></div><div><font color="#000000" face="sans-serif"><span style="line-height:18.2px">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.  </span></font></div><div><br></div></div></blockquote></div></blockquote></div>