You can always fork Clojure and patch IFn.java and Compiler.java to support floats for at least some types of functions. It probably won't be so hard. As your case is a very specific one, this may be a viable solution.
JW On Mon, Sep 16, 2013 at 11:40 PM, Alex Fowler <alex.murat...@gmail.com>wrote: > 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. > -- -- 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.
