Timothy, thank you very much for such a good explanation! I fully agree with you. Actually, except for a few details, that is really how I thought the things are. It is good that you describe the technical base for problems with the issue. As well as clearified the human factor. What you're saying is very much like what I would say if I were in your shoes. Currently, what you're saying, is the present. In the present we make our choices for currents. And I also agree with Mikera, that an attempt should be taken. I would participate in it myself if I was into JVM and Clojure internals. I plan to learn it, but it will take time.
Mikera, thanks for the reference for the library, I will have a look. Also I strongly encourage you in the attempt and I will be happy if I can be of any help, although, you seem to know much more than me. I agree with Tim that some more decisive steps have to be taken into this direction. James, ah.. yes, we did benchmarks. We use highly optimized mathematical calculations, derived from numerical analysis. Every single instruction matters there. Due to the nature of the calculations, the amout of casts, however, varies from 3 to N in one computation. There can be 1 to M such computation for a data unit. And thre can be 1 to P data units. At the end, what worked on plain Java or Java-stylized Scala, worked that times faster, NxMxP more instructions to be computed. Where there were 500 fps, sometimes happen to be 480 fps and sometimes 0.01 fps. And I am not even talking about operations on vast arrays or NIO buffers. But imagine for example, you have a 1.5GB float NIO-buffer, that came from an OpenGL data-type and will go back to it. Operation on each float takes, say 5 casts double<->float in Clojure. Also, as Mikera points out, bus speeds come into play too. Of course, as Timothy said, why don't we go back to C for that kind of stuff? This is a popular question in such cases. I am not going to go into details on that, except for saying that we have mostly migrated from C to JVM and it satisfies our requirements, while giving huge benifits. However, we still do some things in C. To prevent arguments, here is an article<http://beautynbits.blogspot.ru/2013/01/performance-java-vs-c.html> that somewhat describes what one can lose in computation, but does not describe what one gains in other aspects. The loss is what can be tolerated. But that loss for JVM is understandable. The one more loss for Clojure is understandable too, but it can be changed. I think that the discussion branch of Java vs C may be laid to rest. On Mon, Sep 16, 2013 at 9:03 PM, James Reeves <ja...@booleanknot.com> wrote: > > > > On 16 September 2013 09:03, Mikera <mike.r.anderson...@gmail.com> wrote: > >> >> Obviously this is just a microbenchmark, but it fits my general >> experience that floats are a reasonable bit faster than doubles, typically >> 20-100% (doubles are closer when it is pure number crunching since 64-bit >> CPUs are actually pretty good at doubles, floats have a bigger advantage >> when you are manipulating a lot of data points and hence memory bandwidth >> matters more) >> >> Code here for those interested: >> src/test/java/mikera/vectorz/performance/FloatVsDoubleBenchmark.java >> > > That's a pretty interesting result. I ran some tests of my own, based on > your code, as I wondered whether or not the time to instantiate the array > of doubles was biasing the test. My goal was to see whether or not I'd get > a similar result running an array of floats through a method that processed > doubles. (See: https://gist.github.com/weavejester/6583367) > > It turns out that I get a similar result. Passing floats to a method that > takes doubles slows things down by a similar amount, unless I've somehow > botched up the test. Considering that converting between single and double > precision should be pretty cheap on the CPU, I'm surprised at the > difference. > > This somewhat changes my view on things. It doesn't affect me in practice, > but I can see how someone might be frustrated by having to drop down to > Java to achieve performance for floating point calculations. > > - James > > -- > -- > 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/H5P25eYKBj4/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.
