[Haskell-cafe] vector to uvector and back again

[Roman Leshchinskiy]

On 12/02/2010, at 13:49, Don Stewart wrote:

> rl:
>> On 12/02/2010, at 12:39, Don Stewart wrote:
>> 
>>> bos:
>>>> I'm thinking of switching the statistics library over to using vector. uvector
>>>> is pretty bit-rotted in comparison to vector at this point, and it's really
>>>> seeing no development, while vector is The Shiny Future. Roman, would you call
>>>> the vector library good enough to use in production at the moment?
>>> 
>>> uvector's not seeing much development, but at least in the last round of
>>> benchmarks it was still consistently faster -- since it's been
>>> micro-optimized.
>> 
>> FWIW, the development version of vector is usually faster the both
>> uvector and dph-prim-seq, at least for the development version of
>> NoSlow.
> 
> Ah ha -- that's useful. Public benchmarks soon? In time for the Zurich
> Hackathon?? (March 20)

I've been trying to find the time to put the benchmarks on my blog since the beginning of January but, alas, unsuccessfully so far. In any case, vector and NoSlow currently live in

  http://www.cse.unsw.edu.au/~rl/code/darcs/vector
  http://www.cse.unsw.edu.au/~rl/code/darcs/NoSlow

> If Roman declares the vector to be faster -- my main concern here for
> flat uarrays -- and makes the repo available so we can work on it, I'd
> be willing to merge uvector's tests and docs and extra array operations
> in.

It is generally faster than dph-prim-seq. Benchmarking against uvector is a bit difficult because it's missing operations necessary for implementing most of the algorithms in NoSlow (in particular, bulk updates). For the ones that uvector supports, vector tends to be faster.

BTW, this is for unsafe operations which don't use bounds checking. Bounds checking can make things a little slower but often doesn't cost anything as long as only collective operations are used. Sometimes it makes things faster which means that the simplifier still gets confused in some situations. There are also some significant differences between 6.12 and the HEAD (the HEAD is much more predictable).

In general, I find it hard to believe that the performance differences I'm seeing really matter all that much in real-world programs.

Roman