Alice

streaming platforms should have non-temporal loads

@jonocarroll@fosstodon.org it's a hint to the optimizer! this means that it will generally try to apply the rule whenever possible, but it might not have a chance to do so depending on other optimizations it does. e.g. if you have reverse (id reverse list)) (with reverse defined via foldl) and the optimizer inlines the id first, you get reverse (reverse list), which is rewritten to list list but if it inlines the outer reversefirst, you will get foldl (:) [] (id reverse list) and (after inlining id) foldl (:) [] (reverse list), none of which will trigger your rewrite rule this is a contrived example and it's not quite as bad in reality since a lot of list functions have carefully chosen INLINE/INLINABLE pragmas to make sure that rewrite rules have enough opportunities to fire, but you still cannot generally rely on rewrite rules. i actually looked at the core (~optimizer output) of this code (the magical incantation for getting readable output is ghc -O2 -ddump-simpl -ddump-to-file -dsuppress-all -dsuppress-uniques) and it still contained two calls to reverse! (i'm not quite sure why though since it didn't seem to inline anything interesting) if you really want fusion, there are libraries like massiv (https://hackage.haskell.org/package/massiv) that can guarantee fusion by encoding into the types if an array is actually materialized in memory or just an intermediate step of the computation

@jonocarroll@fosstodon.org sorry if this has been said before, but this is only fast in haskell because you're not actually evaluating the result ^^. running length x takes around a minute before running out of memory on my machine (with 108 it finishes after around 20s). that's to be expected though for two reasons: 1) you're running this in ghci, which is an interpreter that is optimized for fast interactive use and performs no optimizations at all (although even compiled with -O2, this runs out of memory for me) 2) you're comparing singly linked lists of boxed integers (just about the least cache and memory efficient representation you could use here) to unboxed (probably?), vectorized arrays. using unboxed arrays from vector instead takes ~12s (compared to ~10s for R on my machine) i don't doubt that optimizations can give haskell an advantage but they won't make a difference here since you're only running two presumably already well-optimized functions