Jason, can you please help me with this: > I'm not sure if the protocol-based implementation can give users any help > writing new core operations efficiently (say, making a new array with > c[i] = a[i] + b[i]^2 / 2) -- unless there's some clever way of > combining protocols with macros (hmmm).
Did you mean an optimization of the whole expression (like in expresso project) or optimization of the way this operation is done on the actual matrix representation? The difference is subtle, but important: the former one can be done with some "abstract" matrix implementation and the latter one is a matter of a particular implementation. If I understand correctly, expresso project is strictly about the former. I've elaborated on this in numerical-clojure group: https://groups.google.com/forum/#!topic/numerical-clojure/eioNIa8oc7E (point 4). On Sunday, June 30, 2013 1:01:32 AM UTC+4, Jason Wolfe wrote: > > This looks very interesting, thanks for sharing! I'll think about it a > bit while working on our codebase and see if I can contribute any good > examples. > > > On Fri, Jun 28, 2013 at 7:17 AM, Mikera <mike.r.an...@gmail.com<javascript:> > > wrote: > >> On Thursday, 20 June 2013 08:45:47 UTC+1, Jason Wolfe wrote: >>> >>> On Saturday, June 15, 2013 4:37:06 AM UTC-7, Mikera wrote: >>>> >>>> On Friday, 14 June 2013 18:15:34 UTC+1, Jason Wolfe wrote: >>>> >>>>> Hey Mikera, >>>>> >>>>> I did look at core.matrix awhile ago, but I'll take another look. >>>>> >>>>> Right now, flop is just trying to make it easy to write *arbitrary* >>>>> array operations compactly, while minimizing the chance of getting >>>>> worse-than-Java performance. This used to be very tricky to get right >>>>> when flop was developed (against Clojure 1.2); the situation has >>>>> clearly improved since then, but there still seem to be some >>>>> subtleties in going fast with arrays in 1.5.1 that we are trying to >>>>> understand and then automate. >>>>> >>>>> As I understand it, core.matrix has a much more ambitious goal of >>>>> abstracting over all matrix types. This is a great goal, but I'm not >>>>> sure if the protocol-based implementation can give users any help >>>>> writing new core operations efficiently (say, making a new array with >>>>> c[i] = a[i] + b[i]^2 / 2) -- unless there's some clever way of >>>>> combining protocols with macros (hmmm). >>>>> >>>> >>>> A longer term objective for core.matrix could be to allow compiling >>>> such expressions. Our GSoC student Maik Schünemann is exploring how to >>>> represent and optimised mathematical expressions in Clojure, and in theory >>>> these could be used to compile down to efficient low-level operations. API >>>> could look something like this: >>>> >>>> ;; define an expression >>>> (def my-expression (expression [a b] (+ a (/ (* b b) 2)))) >>>> >>>> ;; compile the expression for the specified matrix implementation A >>>> (def func (compile-expression A my-expression)). >>>> >>>> ;; now computation can be run using the pre-compiled, optimised function >>>> (func A B) >>>> >>>> In the case that A is a Java double array, then perhaps the flop macros >>>> could be the engine behind generating the compiled function? >>>> >>>> >>>> >>>>> I just benchmarked core.matrix/esum, and on my machine in Clojure >>>>> 1.5.1 it's 2.69x slower than the Java version above, and 1.62x slower >>>>> than our current best Clojure version. >>>>> >>>> >>>> Great - happy to steal your implementation :-) >>>> >>>> Other core.matrix implementations are probably faster BTW: vectorz-clj >>>> is pure Java and has esum for the general-purpose Vector type implemented >>>> in exactly the same way as your fast Java example. Clatrix executes a lot >>>> of operations via native code using BLAS. >>>> >>> >>> I should follow up on this and clarify that core.matrix's esum is in >>> fact as fast as Java -- I apologize for the false statement (I was unaware >>> that new versions of leiningen disable advanced JIT optimizations by >>> default, which lead to the numbers I reported). >>> >>> Nevertheless, I hope there may be room for interesting collaboration on >>> more complex operations, or code gen as you mentioned. I'll follow up >>> later when we're a bit further along. >>> >>> >> >> Great thanks for confirming, I was getting worried :-) >> >> On the topic of code gen, we've been thinking a bit about how to >> represent expressions in the expresso project, and are developing >> a few potential use case API examples. >> >> https://github.com/clojure-numerics/expresso/wiki/User-API-examples >> >> If anyone has any additional use cases to think about, then please throw >> them in! >> >> >> -- >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clo...@googlegroups.com<javascript:> >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+u...@googlegroups.com <javascript:> >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You received this message because you are subscribed to a topic in the >> Google Groups "Clojure" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/clojure/LTtxhPxH_ws/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> clojure+u...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
