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
_______________________________________________
Haskell-Cafe mailing list
Haskel...@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
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.Z...@gmail.com
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
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.
Did you know about Cheplyaka's Summer of Code project to build a physics
engine using fusible arrays?
http://physics-dph.blogspot.com/
:)
-- Don
IIUC, uvector is based on an older version of the DPH libraries and only
provides unboxed arrays. On the other hand, it's much more stable and
has more functionality. I expect that the two libraries will be merged
eventually.
That would be great indeed.