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.anderson...@gmail.com>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 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 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+unsubscr...@googlegroups.com. > 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.
