ANNOUNCE: vector 0.1 (efficient arrays with lots of fusion)

Hi all, the vector library will eventually provide fast, Int-indexed arrays with a powerful fusion framework. It's very immature at the moment (I haven't tested most of the code) and implements just a few combinators but I thought releasing early wouldn't hurt. Use at your own risk and expect things to break horribly! What it provides: * Boxed and unboxed arrays with a generic interface and a very basic set of combinators. * A powerful loop fusion framework. It is based on stream fusion but already goes beyond that (in particular, it can do some things in-place) and will be significantly extended in the future. * Extensibility. * Rudimentary documentation. * Bugs. The code is based on the DPH libraries but is much more generic and a *lot* simpler. This has only been made possible by the tremendous progress in GHC's simplifier in the recent months/years (thanks Simon!). Consequently, you'll need a recent development version of GHC to build this, 6.8 won't work. It might be able to compile the library but you'll get terrible code, much worse than with lists. If you want to try it out, compile with -O2 -fno-spec-constr-count and please don't forget to let me know about things that didn't work (or, miraculously, did). Grab it from http://hackage.haskell.org/cgi-bin/hackage-scripts/package/vector or darcs get http://darcs.haskell.org/vector Again, special thanks to Simon for doing such a wonderful job with the optimiser. Enjoy, Roman

Hello Roman, Saturday, July 12, 2008, 7:01:05 PM, you wrote:
the vector library will eventually provide fast, Int-indexed arrays with a powerful fusion framework.
GREAT! doom4 would be written in Haskell! -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

bulat.ziganshin:
Hello Roman,
Saturday, July 12, 2008, 7:01:05 PM, you wrote:
the vector library will eventually provide fast, Int-indexed arrays with a powerful fusion framework.
GREAT! doom4 would be written in Haskell!
Did you know about Cheplyaka's Summer of Code project to build a physics engine using fusible arrays? http://physics-dph.blogspot.com/ :) -- Don

On 7/12/08, Roman Leshchinskiy
Hi all,
the vector library will eventually provide fast, Int-indexed arrays with a powerful fusion framework. It's very immature at the moment (I haven't tested most of the code) and implements just a few combinators but I thought releasing early wouldn't hurt. Use at your own risk and expect things to break horribly!
What it provides:
* Boxed and unboxed arrays with a generic interface and a very basic set of combinators.
* A powerful loop fusion framework. It is based on stream fusion but already goes beyond that (in particular, it can do some things in-place) and will be significantly extended in the future.
(moving to cafe) Is there any more (easily-digested, like a paper) information available about this? Specifically what things can happen in-place, and future extensions... -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862

Sebastian Sylvan wrote:
Is there any more (easily-digested, like a paper) information available about this? Specifically what things can happen in-place, and future extensions...
Apart from the stream fusion papers, unfortunately no, it's all very much work in progress. Basically, at the moment it will avoid allocating some unnecessary arrays even if no loop fusion happens. So for instance, in something like map f (xs // us) the two loops can't be fused ((//) is the same update operation as in Data.Array). Usually, you'd allocate one array for (xs // us) and then another one for the map. This library will do the map in-place if f doesn't change the type of the elements. This is pretty important at least for data-parallel code. I'll have to see how far this scales. In the future, the fusion system will also be able to handle multiple directions of traversals and permutations (it can only do left-to-right traversals at the moment). The "Rewriting Haskell Strings" paper talks a bit about that but DPH has much more complex requirements so I'll have to use a different approach which I haven't implemented so far. Roman
participants (4)
-
Bulat Ziganshin
-
Don Stewart
-
Roman Leshchinskiy
-
Sebastian Sylvan