These libraries are tuned for wildly different workloads and use cases,
so these sorts of micro benchmarks are an Apples to Frogs comparisons.
You can argue that for any benchmark, but sometimes the choice is
between Apples and Frogs. If you have some more extensive benchmarks I'm
happy to have a look at them.
(even aside from the fact that you'll get very different perf if you
used -fllvm and set things up so the array indexing and associated loop
code get inlined and fused together!)
I think llvm should be default by now. In any case, if you write code,
it is important to know how well something works out of box without you
having to spend hours optimizing it.
what is the actual concern? Strawman micro benchmarks that don't even
compare the respective libraries for their intended use cases seeems....
weird.
Perhaps i should have explained that better.
If one library was clearly superior to the others, that would have made
it easier to choose.
Also I wanted to check if Unboxed was usually better than Storable as
they are semantically the same (correct me if i'm wrong). Which it is in
one example. Still I think Storable could be done so we don't need
Unboxed, too.
I would have said that sum/fold (i.e. consecutive access of the
elements) is a reasonable use case for how we typically use bytestring
and the random access sum is a reasonable you use case for how we
typically use array/vector. Interestingly enough the performance was
exactly opposed to these reasonable use cases.
Silvio
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
