Please, no! Sure, forking Clojure is technically possible and might even solve the specific problem for the OP. But that's not the point. This isn't a technical problem, it's a social/organisational problem.
The idea that we should fork Clojure (or even create an intricate clever new library that does some funky code generation) every time someone has a new performance requirement is going to be disastrous for the Clojure ecosystem. It will cause massive fragmentation and/or cause people to give up and abandon Clojure altogether. People have written extensively about the "Lisp Curse" and this is exactly the kind of dysfunction we should try to avoid. See e.g.: http://kresimirbojcic.com/2012/08/14/why-lisp-did-not-and-never-will-gain-enough-traction.html http://www.winestockwebdesign.com/Essays/Lisp_Curse.html The right answer is to figure out how to get these kind of "core" improvements into Clojure itself. That's harder to do. It requires people to work together and understand each others' requirements rather than just dismissing them (the "well I don't need this so you should just find a workaround" attitude isn't at all helpful). It requires engaging, cultivating and encouraging the people with the skill and motivation to to make these kind of improvements. It may require developing a proper roadmap for Clojure. It requires people to sign CAs and follow JIRA processes etc. But the effort to do this is worth it: this way everyone benefits from the development effort, we avoid creating a thousand different incompatible software stacks, and we make traction happen on Clojure development itself. Please note: my only reason for arguing passionately about this kind of stuff is to help Clojure succeed. Presumably that's what we would all like to see, or we wouldn't be here, right? On Tuesday, 17 September 2013 14:48:32 UTC+8, Jozef Wagner wrote: > > 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.m...@gmail.com<javascript:> > > 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<javascript:> >> > wrote: >> >>> >>> >>> >>> On 16 September 2013 09:03, Mikera <mike.r.an...@gmail.com <javascript:> >>> > 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 clo...@googlegroups.com<javascript:> >>> 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 <javascript:> >>> 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+u...@googlegroups.com <javascript:>. >>> >>> 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 clo...@googlegroups.com<javascript:> >> 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 <javascript:> >> 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+u...@googlegroups.com <javascript:>. >> 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.
