On Monday, March 14, 2016 at 4:56:19 PM UTC+1, tbc++ wrote: > > Just a side comment, Dragan, if you don't want to be compared against some > other tech, it might be wise to not make the subtitle of a release "X times > faster than Y". Make the defining feature of a release that it's better > than some other tech, and the proponents of that tech will probably start > to get a bit irritated. >
I agree with you, and I am not against Neanderthal being compared to Vectorz or core.matrix, or Clatrix or Y. I only commented that it is funny that every time Neanderthal is mentioned anywhere, Mike jumps in with the comment that I should step off the heretic work immediately and convert Neanderthal to the only true core.matrix api. I am sorry if it came out as if I was offended by that, *which I am not*. > And I think the distinction made here about floats vs doubles is very > important. We can all construct benchmarks that show tech X being faster > than tech Y. But if I am evaluating those things I really want to know why > X is faster than Y. I want to know what tradeoffs were made, what > restrictions I have in using the faster tech, etc. Free performance gains > are very rare, so the moment I see "we are X times faster" I immediately > start looking for a caveats section or a rationale on why something is > faster. Not seeing that, or benchmark documentation, I almost immediately > consider the perf numbers to be hyperbole. > > Sure. 1) The benchmark page links to the benchmark source code on github, and all 3 projects are open-source, so I expect any potential user would be wise enough to evaluate libraries himself/herself. I took care to mention drawbacks more times than is usual. I do not want to give people false hope. 2) The reason I am posting the benchmarks is mainly that in Java (and Clojure) land there is much superstition about what can be done and what performance to expect. People read some comment somewhere and tend to either expect superspeed for free (and be disappointed when their naive approach doesn't work well) or to dismiss an approach because "it can't be done" or "calling the native library is slow" (it isn't, if done right). -- 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.
