Neanderthal 0.4.0 has just been released with OpenCL-based GPU support and pluggable engines.
http://neanderthal.uncomplicate.org On Tuesday, June 23, 2015 at 12:39:40 AM UTC+2, Dragan Djuric wrote: > > As it is a *sparse matrix*, C++ library unavailable on JVM, I don't > consider it relevant for comparison as these are really apples and > pineapples. For now, at least. > > On Tue, Jun 23, 2015 at 12:13 AM, A <> wrote: > >> >> Here's another benchmark for comparison: >> https://code.google.com/p/redsvd/wiki/English >> >> -A >> >> >> >> On Monday, June 22, 2015 at 12:27:57 PM UTC-7, Dragan Djuric wrote: >>> >>> core.matrix claims that it is fast on its project page (with which I >>> agree in some cases). I expected from that, and from the last couple of >>> your posts in this discussion, that there are some concrete numbers to >>> show, which I can't find. >>> >>> My claim to win "ALL benchmarks" (excluding maybe tiny objects) came >>> only as a response to mike's remarks that I have only proven that >>> neanderthal is faster for dgemm etc. >>> >>> OK, maybe the point is that other libraries do not care that much about >>> speed, or that current speed is enough, or whatever, and I am ok with that. >>> I would just like it to be explicitly said, so I do not lose time arguing >>> about what is not important. Or it would be nice to see some numbers shown >>> to draw at least rough picture of what can be expected. I am glad if my >>> raising this issue would improve the situation, but I do not insist... >>> >>> On Monday, June 22, 2015 at 9:16:15 PM UTC+2, Christopher Small wrote: >>>> >>>> Well, we also weren't claiming to win "ALL benchmarks" compared to >>>> anything :-) >>>> >>>> But your point is well taken, better benchmarking should be pretty >>>> valuable to the community moving forward. >>>> >>>> Chris >>>> >>>> >>>> On Mon, Jun 22, 2015 at 12:10 PM, Dragan Djuric <drag...@gmail.com> >>>> wrote: >>>> >>>>> So, there are exactly two measurements there: matrix multiplication >>>>> and vector addition for dimension 100 (which is quite small and should >>>>> favor vectorz). Here are the results on my machine: >>>>> >>>>> Matrix multiplications are given at the neanderthal web site at >>>>> http://neanderthal.uncomplicate.org/articles/benchmarks.html in much >>>>> more details than that, so I won't repeat that here. >>>>> >>>>> Vector addition according to criterium: 124ns vectorz vs 78ns >>>>> neanderthal on my i7 4790k >>>>> >>>>> Mind you that the project you pointed uses rather old library >>>>> versions. I updated them to the latest versions. Also, the code does not >>>>> run for both old and new versions properly (it complains about :clatrix) >>>>> so >>>>> I had to evaluate it manually in the repl. >>>>> >>>>> I wonder why you complained that I didn't show more benchmark data >>>>> about my claims when I had shown much more (and relevant) data than it is >>>>> available for core.matrix, but I would use the opportunity to appeal to >>>>> core.matrix community to improve that. >>>>> >>>>> On Monday, June 22, 2015 at 8:13:29 PM UTC+2, Christopher Small wrote: >>>>>> >>>>>> For benchmarking, there's this: >>>>>> https://github.com/mikera/core.matrix.benchmark. It's pretty simple >>>>>> though. It would be nice to see something more robust and composable, >>>>>> and >>>>>> with nicer output options. I'll put a little bit of time into that now, >>>>>> but >>>>>> again, a bit busy to do as much as I'd like here :-) >>>>>> >>>>>> Chris >>>>>> >>>>>> >>>>>> On Mon, Jun 22, 2015 at 9:14 AM, Dragan Djuric <drag...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> >>>>>>>> As for performance benchmarks, I have to echo Mike that it seemed >>>>>>>> strange to me that you were claiming you were faster on ALL benchmarks >>>>>>>> when >>>>>>>> I'd only seen data on one. Would you mind sharing your full >>>>>>>> benchmarking >>>>>>>> analyses? >>>>>>>> >>>>>>> >>>>>>> I think this might be a very important issue, and I am glad that you >>>>>>> raised it. Has anyone shared any core.matrix (or, to be precise, >>>>>>> core.matrix) benchmark data? I know about Java benchmark code project >>>>>>> that >>>>>>> include vectorz, but I think it would help core.matrix users to see the >>>>>>> actual numbers. One main thing vectorz (and core.matrix) is claiming is >>>>>>> that it is *fast*. Mike seemed a bit (pleasantly) surprised when I >>>>>>> shared >>>>>>> my results for vectorz mmul... >>>>>>> >>>>>>> So, my proposal would be that you (or anyone else able and willing) >>>>>>> create a simple Clojure project that simply lists typical core.matrix >>>>>>> use >>>>>>> cases, or just the core procedures in core.matrix code that you want to >>>>>>> measure and that you are interested to see Neanderthal doing. Ready >>>>>>> criterium infrastructure is cool, but I'm not even ask for that if you >>>>>>> do >>>>>>> not have time. Just a setup with matrix objects and core.matrix >>>>>>> function >>>>>>> calls that you want measured. Share your numbers and that project on >>>>>>> Github >>>>>>> and I will contribute comparative code for Neanderthal benchmarks, and >>>>>>> results for both codes run on my machine. Of course, that would be >>>>>>> micro >>>>>>> benchmarks, but useful anyway for you, one Neanderthal user (me :) and >>>>>>> for >>>>>>> all core.matrix users. >>>>>>> >>>>>>> You interested? >>>>>>> >>>>>>> With all that out of the way... I'm glad that you're willing to play >>>>>>>> ball here with the core.matrix community, and thank you for what I >>>>>>>> think >>>>>>>> has been a very productive discussion. I think we all went from >>>>>>>> talking >>>>>>>> _past_ each other, to understanding what the issues are and can now >>>>>>>> hopefully start moving forward and making things happen. While I think >>>>>>>> we'd >>>>>>>> all love to have you (Dragan) personally working on the core.matrix >>>>>>>> implementations, I agree with Mars0i that just having you agree to >>>>>>>> work-with/advise others who would do the actual work is great. I'd >>>>>>>> personally love to take that on myself, but I already have about a >>>>>>>> half >>>>>>>> dozen side projects I'm working on which I barely have time for. Oh, >>>>>>>> and a >>>>>>>> four month old baby :scream:! So if there's anyone else who's willing, >>>>>>>> I >>>>>>>> may leave it to them :-) >>>>>>>> >>>>>>> >>>>>>> I'm also glad we understand each other better now :) >>>>>>> >>>>>>> -- >>>>>>> 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 >>>>>>> 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 >>>>>>> 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/dFPOOw8pSGI/unsubscribe. >>>>>>> To unsubscribe from this group and all its topics, send an email to >>>>>>> clojure+u...@googlegroups.com. >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> >>>>>> -- >>>>> 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 >>>>> 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 >>>>> 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/dFPOOw8pSGI/unsubscribe. >>>>> To unsubscribe from this group and all its topics, send an email to >>>>> clojure+u...@googlegroups.com. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> -- >> 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/dFPOOw8pSGI/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/d/optout. >> > > -- 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/d/optout.
