On Friday, 13 September 2013 00:07:03 UTC+8, Christophe Grand wrote: > As others have already said: long & double only is a restriction for > function args. Not for interop. Not for local computations. Not for args to > definterface methods. The reason for this restriction is the combinatorial > explosion. >
I still don't understand why combinatorial explosion is even a problem: why are these interfaces necessary? If we can do away with the interface generation, then support for arbitrary primitive arguments should become relatively straightforward. IMHO, in cases where performance matters enough to need primitive function arguments, you aren't going to want to be using a higher-order function / IFn-based polymorphism anyway. You just want a direct invocation, which shouldn't need to go via any interfaces. It just needs the compiler to figure out the right method to invoke at the function callsite. Dynamic / higher order use cases (which I agree need an interface) can be handled via the regular [Object ....] argument version of the function, which is already provided by IFn. Bonus: if you take this approach, I think it's also possible to support arbitrarily typed return values using the same infrastructure. That would be another big performance win. > (So you may have to roll your own interface and a couple of helper macros > to have some kiind of fns handling ints and floats as args/return values.) > > On the bright side: there are even functions specialized for ints: > unchecked-add-intfor example, and the compiler hs intrinsics for them (ie > emits an IADD opcode). > However there's no such support (fns and intrinsics) for floats. > I think floats support on par with ints support could be added without > being controversial. > > hth, > > Christophe > > > On Thu, Sep 12, 2013 at 5:11 PM, Timothy Baldridge > <tbald...@gmail.com<javascript:> > > wrote: > >> There are a combination of issues all contributing to the lack of >> response on this subject. But before I continue let me state that these >> opinions are my own. I have worked on Clojure and core.async, but these >> comments are going to be personal conjecture and opinions: >> >> 1) As mentioned there is a high amount of complexity required to >> implement all the interfaces needed for the different variants of functions >> you want. Primitive hinted functions currently implement Java interfaces, >> implementing every combination of float, double, object, short, int, long, >> and byte for arities up to 5 would require the addition of over 16,000 >> interfaces. With the current config, we only need 81 interfaces. I'm not >> saying this couldn't be changed to happen on-the-fly, it would just take >> some serious work, and would cause problems with Java Interop >> >> 2) The current system works, there are production databases (see >> Datomic), neural networks (see the work by Prismatic), and many high >> performance libraries (Zach Tellman has a reputation for bending Clojure to >> his will in this area), all written in Clojure. >> >> 3) Because of #2, some may even go so far as to say that we should drop >> everything but longs and doubles. Other dynamic languages (Python for >> instance) do this without problems, they simply relegate all the high >> performance stuff to highly optimized libraries. This is what Prismatic did >> with HipHop ( >> http://blog.getprismatic.com/blog/2013/7/10/introducing-hiphip-array-fast-and-flexible-numerical-computation-in-clojure >> ). >> >> 4) Writing small functional libraries in Java that interop with Clojure >> is actually quite nice. So perhaps the answer is to build the inner kernels >> of your system in Java and then wrap them? I know that doesn't sound fun, >> but you won't get much faster code than that. >> >> So all the above make me sit back and say "what is it about your problem >> that is unique and really requires floats? Why haven't we had problems like >> this in the past." >> >> 5) And I think the problem really comes down to your API and target >> platform (GPU). See, most of us would just typehint to doubles and take the >> memory hit. Doubles are fast on modern CPUs and memory is cheap. Not so in >> your case, as you mentioned you have concerns about memory size and >> performance of certain primitives. >> >> My conclusion is that you'd probably be best looking at the HipHop >> library, and figuring out how you can adapt their ideas to your own code. >> That is, write a small Java library that contains all the kernel code you >> need, and then stitch together these primitives with Clojure. >> >> As it stands, Clojure's support for type hinting floats is poor, but >> that's not likely to change soon. >> >> ---- >> >> TL;DR - The reason you haven't heard back is because no one has a good >> answer as to how to fix it, or if it even needs to be fixed. That's not the >> answer anyone likes to hear, but I'm afraid that's the truth. Anyone else >> on this list can feel free to correct me. >> >> Timothy Baldridge >> >> >> On Thu, Sep 12, 2013 at 8:38 AM, Alex Fowler >> <alex.m...@gmail.com<javascript:> >> > wrote: >> >>> >>> Does somebody from the development team read this user group? Or maybe I >>> have addressed my questions to a wrong place? >>> >>> -- >>> -- >>> 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. >>> >> >> >> >> -- >> “One of the main causes of the fall of the Roman Empire was that–lacking >> zero–they had no way to indicate successful termination of their C >> programs.” >> (Robert Firth) >> >> -- >> -- >> 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. >> > > > > -- > On Clojure http://clj-me.cgrand.net/ > Clojure Programming http://clojurebook.com > Training, Consulting & Contracting http://lambdanext.eu/ > -- -- 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.
