Delay the computation until the last possible point.

[strelec]

We have been talking about this on the google groups, but I am reporting the enchantment here, too.

As we all know, BLAS contains many composite operations, like GEMM.

C += A*B

But, as the library is currently designed, we are unable to take advantage of that, since each operation is performed eagerly, as soon as possible.

The right way to do it would be to keep the operations stored as an AST, performing some kind of smart analysis to keep it unevaluated until it is certain that the most specific BLAS function can be used.

Since the overhead of the breeze library is already insignificant, the performance could be improved a lot this way.

[dlwh]

It's very much on my list, but my plan is to wait until a post-1.0/API-stabilized world. I'm not sure whether to go the macro route or the runtime expression tree route. Thoughts?

[strelec]

I'd avoid macros anytime if it is possible to do so. And indeed it is.

Conceptually, I'd do it so every operation first inspects all parameters. The code for this should be simple, because most of the work and thinking should be done on paper, and then only the final results implemented as code.

Because ASTs never get bigger than 6 nodes, it is very efficient, too. As seen from the talk on the readme, the breeze overhead is already insignificant, because the work is delegated. However, someone might multiply small matrices in a loop. So, we would want to enable native backend only for matrices > 100. Note that without native backend, this enchantment (this github bug) is not needed and should be disabled, doing away with the overhead.

[dlwh]

this is actually a duplicate of #310

[strelec]

Actually, no.

His example can be made lazy by simply making c a "lazy val".

If he wants to make a matrix to be partially lazy (eg. able to be just partially computed, LazyMatrix), that is also a completely different beast.

I do not agree. This is not a duplicate.

[dlwh]

I mean, I think he meant the general case of delaying computation so they
could be composed with others and executed more efficiently. That's the way
I took it.

On Fri, Feb 20, 2015 at 12:27 AM, Rok Kralj notifications@github.com
wrote:

Actually, no.

His example can be made lazy by simply making c a "lazy val".

If he wants to make a matrix to be partially lazy (eg. able to be just
partially computed, LazyMatrix), that is also a completely different beast.

I do not agree. This is not a duplicate.

—
Reply to this email directly or view it on GitHub
#360 (comment).