On Tuesday, 10 September 2013 01:03:12 UTC+8, Jozef Wagner wrote: > You can typehing ints for locals (let, loop), restrictions are just for > function arguments. > AFAIK the reason is combinatorial explosion at > https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/IFn.java#L91 >
I never understood the point of these restrictions.... surely primitive function invocation is much better handled by: a) generating the exact primitive function required in an AFn subclass (e.g. invokePrim(long, char, byte, Object); ) b) Creating a direct invocation of the method in a) at any function call site c) The usual IFn.invoke(...) methods can handle the dynamic use cases when you pass this AFn to a higher order function i.e. you don't really need these interfaces at all. As a bonus, the same method could also improve performance by avoiding type casts for non-primitive type-hinted arguments like String, since you aren't limited to casting every non-primitive argument via Object either. Or am I missing something obvious? > I have the same problem with char. Because I cannot typehint e.g. my > whitespace? function with ^char, I recieve a boxed Object and thus cannot > use == for comparison. > > JW > > > On Mon, Sep 9, 2013 at 6:02 PM, Mikera <mike.r.an...@gmail.com<javascript:> > > wrote: > >> +1 for supporting all the JVM primitive types properly. >> >> It is worth noting that the benefits would extend much further than just >> OpenGL, e.g.: >> - int is a commonly used type in Java interop. Casting to/from it all >> the time is a minor annoyance/overhead >> - int is the type used for array indexing on the JVM >> - all the small (< 8 byte) primitive types save memory footprint, which >> is important since memory bandwidth is the limiting factor in some workloads >> - int/float fit into a register (and therefore perform much better) on >> 32 bit machines (which still exist, believe it or not....) >> - char is a pretty useful primitive type if you are doing text processing >> - byte is also frequently useful, especially for IO >> >> I believe that with some enhancements to the Clojure compiler, supporting >> all the JVM primitive types shouldn't be too difficult, and it would >> provide many benefits both in terms of overall performance and interop >> convenience. >> >> On Monday, 9 September 2013 21:43:12 UTC+8, Alex Fowler wrote: >>> >>> Hello! >>> >>> With this letter I would like to receive an answer from somebody from >>> the development team (if anyone else has something to say, you're surely >>> welcome :) ). >>> >>> I am working for a big multimedia company and recently I have been >>> considering moving to Clojure as the main language of development. We have >>> been doing Java and Scala before, but now when I tried Clojure and see the >>> possibilities it provides, I would definitely stand for it to be our >>> ground. However, while I am so satisfied with everything - the language, >>> the community, the Java interop, there is still something that hinders and >>> makes me linger. Namely, the lack of good support of floats and ints in the >>> language. While many people would not consider it to be a huge disadvantage >>> or even notice it, things are not so bright when it comes to OpenGL. >>> >>> The case is that OpenGL and 3D graphics hardware in general has no >>> support for doubles or longs. Therefore, all libraries, all data and all >>> computations are meant to be performed with floats and ints (shaders too). >>> Due to the lack of good support of these data types in Clojure (for >>> example, there are no ^float and ^int typehints, float and int values can >>> only be typecasted to, all calculations always retain doubles and longs), >>> results in too many extra typecasts, which are absolutely unnecessary and >>> take too much time. So, calculations become very cumbersome, even if we do >>> not take mandatory boxing into account. >>> >>> Considering that such kinds of calculations are usually abuntant in the >>> aforementioned types of applications, the penalty grows really huge. I have >>> endeavoured several discussions on the IRC to find out possible >>> workarounds. Although many good proposals by many good people were made, >>> aimed at improving the situation, none of them could solve the fundamental >>> lack of the ability to manipulate 32bit primitive (or even boxed) data >>> types. That lack renders Clojure not really suitable for heavy-load OpenGL >>> applications that require somewhat extensive calculations: some kinds of >>> games, simulations, generative graphics and so on. Considering how superior >>> Clojure is to any other language available for JVM, that black spot looks >>> especially embarrasing. And I could imagine falling back to Java for fast >>> computations, just like we fall back to ASM in, say C, that is very >>> undesirable and discouraging, since we want to pick Clojure for Clojure and >>> it will be too cumbersome to make 50/50% Java/Clojure apps just to work >>> around that design decision. >>> >>> Therefore, while deciding if to pick Clojure as the base for our >>> development, I would like to know answers to the following questions: >>> >>> 1) What is the current reason for the support for these types to be >>> missing? >>> 2) Are there any plans for improvement of support for floats, ints and >>> maybe, localized unboxed calculations? Or is there some advice on how to >>> enable their support? >>> 3) What is you vision for Clojure + OpenGL applications? >>> 4) Is it possible to request support for floats, ints and maybe shorts >>> for the language? >>> 5) Is it possible to request support for localized unboxed calculations, >>> like (with-unboxed ... ) and localized float-only and int-only >>> calculations, like, say in special macros (with-floats-&-ints ... here go >>> (+) (-) and stuff ONLY with floats/ints ... ) ? >>> >>> Preferably, I would like to hear the answers from somebody from the >>> development team, because I have already received enough support from the >>> community, on the IRC, I appreciate it, but now I have to make a serious >>> choice for our company and I feel quite responsible for that. I also feel >>> that these questions are very important for any specialist that works with >>> OpenGL and influence Clojure acceptance for OpenGL-enabled applications >>> world-wide. Thank you. >>> >> -- >> -- >> 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.
