Gram matrix initialization

[UnixJunkie]

Dear futharckers,
I wrote this recently:
https://github.com/ocaml-bench/sandmark/blob/master/benchmarks/multicore-grammatrix/grammatrix.ml
The Gram matrix is quite useful in several machine learning settings.
I think it might be a nice, real-world, addition to the futhark benchmarks.
Futharkly yours,
F.

[UnixJunkie]

Some people wrote a multithread version of it:
https://github.com/ocaml-bench/sandmark/blob/master/benchmarks/multicore-grammatrix/grammatrix_multicore.ml
I have a parallel (multicore) version of it there:
https://github.com/UnixJunkie/gram-matrix-bench/blob/master/src/gram.ml

[UnixJunkie]

My bench results can be seen there:
https://github.com/UnixJunkie/gram-matrix-bench

[athas]

Is there much to gain by exploiting the symmetry, when compared to just doing a normal matrix multiplication? It seems like it would only reduce the work by a factor of two.

[UnixJunkie]

The matrix is diagonal symmetric. Usually, I only compute one half plus the diagonal.
Also, this matrix can be quite big quite fast, because of the dataset size.

[UnixJunkie]

Also, probably stupid question, can we read a file in Futhark, and write to one?
I have read that there is no IO in the futhark doc, so I am really wondering.

[athas]

No, Futhark is pure. For testing and benchmarking programs, the compiler automatically inserts IO for reading input and writing results (see here), but for actual production use, Futhark code must be invoked from a conventional programming language (discussed here).

[UnixJunkie]

Wow, amazing. Thanks for the pointers.
I read that: "Simplicity. I think modern computers are too slow, too fragile, and too incorrect, and I believe the root cause is uncontrolled complexity. Attempts to introduce simplicity by mindlessly adding abstraction layers are ultimately counterproductive. Simplicity is best achieved by lowering feature count and flexibility."
Now, I feel less lonely. :)