Re: Clojure, floats, ints and OpenGL

... as well core.matrix supports normalise, which I just reali*z*ed since I am American English. haha On Saturday, October 19, 2013 8:05:47 AM UTC-4, Chris Gill wrote: > > I am in this boat as well, clojure + opengl, currently using lwjgl for > bindings and management. I am curious why you need

Re: Clojure, floats, ints and OpenGL

I am in this boat as well, clojure + opengl, currently using lwjgl for bindings and management. I am curious why you need float support actually, what specific methods are you hoping to utilize this with? Currently I create float-arrays from the loaded mesh and build the VBOs and push that all

Re: Clojure, floats, ints and OpenGL

Hi Christophe, Looks like a good patch to me - would you be able to submit it to JIRA? I already submitted an issue to add primitive support for statically compiled functions (http://dev.clojure.org/jira/browse/CLJ-1263) which I think would complement yours nicely. The combination of the two sh

Re: Clojure, floats, ints and OpenGL

I ported Mikera's benchmark to Clojure using my patch https://gist.github.com/cgrand/6595939 The ratio between time-float and time-double (0.632) is very similar to the ratio between timeFloat and timeDouble Mikera reported (0.618) On Tue, Sep 17, 2013 at 1:25 PM, Christophe Grand wrote: > Here

Re: Clojure, floats, ints and OpenGL

Here is the mundane patch I described earlier: https://github.com/cgrand/clojure/commit/4c202ad9757ce47ac9e669847c0e5bf68785e2d6 It adds four functions (add-, multiply-, divide- and subtract-float), backs them with their corresponding bytecodes and enhance the conversion emitted when going from lo

Re: Clojure, floats, ints and OpenGL

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 t

Re: Clojure, floats, ints and OpenGL

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 wrote: > Timothy, thank you

Re: Clojure, floats, ints and OpenGL

If you're worried about NIO buffer marshalling, Vertigo [1] lets you treat them as native Clojure data structures. This doesn't save you from the float<->double coercion for arithmetic operations, but as James said earlier in the thread, this tends to be insignificant. However, if you're abso

Re: Clojure, floats, ints and OpenGL

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

Re: Clojure, floats, ints and OpenGL

On 16 September 2013 09:03, Mikera 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

Re: Clojure, floats, ints and OpenGL

Hi Mikera, I don't have a whole lot of skin in this game as, unfortunately, I haven't run into any performance bottlenecks that I couldn't fix in a satisfying way whilst writing Clojure. My impression, however, is that there are some people in the community who feel the performance limitations of

Re: Clojure, floats, ints and OpenGL

On Saturday, 14 September 2013 00:36:05 UTC+8, James Reeves wrote: > On 13 September 2013 08:54, Mikera >wrote: > >> Either way, if Clojure's semantics prove to be a fundamental issue for >> performance, then I think it is better to start work to improve Clojure's >> semantics (perhaps targetin

Re: Clojure, floats, ints and OpenGL

Hi Alex, Just one more thing to think about: Dmitry Groshev has been doing some good early work on Clojure float support in the core.matrix NDArray implementation (basically a NumPy-style multidimensional array implementation backed by a single large float[] array). The per-object overhead is

Re: Clojure, floats, ints and OpenGL

Hi Timothy, Clearly, the "partial dynamic recompilation" feature depends on storing enough information to actually perform the recompile. You could store either the source, or some sort of transformed AST. There are many ways to make this kind of system work - at the REPL or otherwise (but I ag

Re: Clojure, floats, ints and OpenGL

Hi Timothy, Clearly, the "partial dynamic recompilation" feature depends on storing enough information to actually perform the recompile. You could store either the source, or some sort of transformed AST. There are many ways to make this kind of system work - at the REPL or otherwise (but I ag

Re: Clojure, floats, ints and OpenGL

How are you going to recompile at all, when the compiler doesn't store the source code of functions after it compiles them? This is why this proposal needs to have a working prototype, to prove that these ideas actually work, until then proposals don't do much at all. Personally I don't see how th

Re: Clojure, floats, ints and OpenGL

On Saturday, 14 September 2013 01:04:16 UTC+8, tbc++ wrote: > >> This would be better, IMHO, than forever accepting semantics that > prevent idiomatic code from ever being truly fast. > > You're going to have a hard time convincing people to give up some of > the dynamism of Clojure just for the

Re: Clojure, floats, ints and OpenGL

+1 on all the answers from Timothy to these items Been working with Clojure for 5 years by now handling huge data loads in real time. You want to get lean and mean performance in specific areas then thunk down to Java or native libs. We never had to do from Clojure btwy, there's been always an al

Re: Clojure, floats, ints and OpenGL

On 14 September 2013 12:14, Alex Fowler wrote: > Timothy, thanks,for giving a thorough answer to my questions, I appreciate > this! As far as I understood, you did some work for Clojure team, and you > have the necessary knowledge to express a knowing opinion on what are the > implications of the

Re: Clojure, floats, ints and OpenGL

>> 1) Clojure is said to be "data-oriented". Well it is, it's just that your definition of "data" is radically different from the normal business use case. In the line of work I'm in, "big data" is millions of hash maps filled with heterogeneous data types. In these cases, Clojure really shines.

Re: Clojure, floats, ints and OpenGL

Excuse me, when I said "Vertex3f" I meant "Vector3f". суббота, 14 сентября 2013 г., 15:14:01 UTC+4 пользователь Alex Fowler написал: > > Timothy, thanks,for giving a thorough answer to my questions, I appreciate > this! As far as I understood, you did some work for Clojure team, and you > have

Re: Clojure, floats, ints and OpenGL

7) Maybe genclass and stuff can still get away as it is now, falling back to boxing and reduced number of types? Or special genclass metadata hints be introduced? Still, not everyone will use that. But those who will, could spare a couple more hints to the compiler.. -- -- You received this m

Re: Clojure, floats, ints and OpenGL

Timothy, thanks,for giving a thorough answer to my questions, I appreciate this! As far as I understood, you did some work for Clojure team, and you have the necessary knowledge to express a knowing opinion on what are the implications of the matter. That was one of the things I wanted to know -

Re: Clojure, floats, ints and OpenGL

>> This would be better, IMHO, than forever accepting semantics that prevent idiomatic code from ever being truly fast. You're going to have a hard time convincing people to give up some of the dynamism of Clojure just for the sake of more performance. Especially considering that many Clojure user

Re: Clojure, floats, ints and OpenGL

On 13 September 2013 08:54, Mikera wrote: > Either way, if Clojure's semantics prove to be a fundamental issue for > performance, then I think it is better to start work to improve Clojure's > semantics (perhaps targeting 2.0 if we think it's a really big breaking > change). This would be better,

Re: Clojure, floats, ints and OpenGL

On Friday, 13 September 2013 12:11:50 UTC+8, tbc++ wrote: > >> If we can do away with the interface generation, then support for > arbitrary primitive arguments should become relatively straightforward. > > How would we even call a function without an interface? Remember > everything is defined

Re: Clojure, floats, ints and OpenGL

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 hi

Re: Clojure, floats, ints and OpenGL

>> If we can do away with the interface generation, then support for arbitrary primitive arguments should become relatively straightforward. How would we even call a function without an interface? Remember everything is defined behind vars, so you simply can't assume that a function won't be re-de

Re: Clojure, floats, ints and OpenGL

People *have* run into this problem a lot. People have just worked around it. The existence of great libraries like HipHip and vectorz-clj and some of Zach's stuff is IMHO to a large extent because people have needed high performance operations (often involving primitives / primitive arrays / c

Re: Clojure, floats, ints and OpenGL

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

Re: Clojure, floats, ints and OpenGL

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. (So you may have to roll your own interface and a couple of helper m

Re: Clojure, floats, ints and OpenGL

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 clojure@googlegroups.com Note that posts

Re: Clojure, floats, ints and OpenGL

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 >

Re: Clojure, floats, ints and OpenGL

While there are "double" types for OpenGL, like GLdouble (reference-1, reference-2 ), their use is, softly speaking, not wide-spread: reference-3

Re: Clojure, floats, ints and OpenGL

Think for youself: how much you gain for storing color in 64 bit instead of 32? How much you gain of storing positions to be projected on a, say, 1920x1080 screen, in 64 bit, not 32? Considering this, how much you gain from manufacturing 64-bit enabled GPUs for average humans to use? And puttin

Re: Clojure, floats, ints and OpenGL

+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

Re: Clojure, floats, ints and OpenGL

Also, how much of this is a limit of the OpenGL library you are using? The raw OpenGL API supports glVertex3d and glVertex3f. Is the double version not supported by your java interface library? Timothy On Mon, Sep 9, 2013 at 11:07 AM, Timothy Baldridge wrote: > It's worth noting that the restri

Re: Clojure, floats, ints and OpenGL

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 have the same problem with char. Because I cannot typehint e.g. my whitespace

Re: Clojure, floats, ints and OpenGL

It's worth noting that the restrictions to IFn do not apply to definterface and deftype. Not that solves all (or any) of your problems, I've used definterface before to lock down the actual types used. Timothy On Mon, Sep 9, 2013 at 11:03 AM, Jozef Wagner wrote: > You can typehing ints for loca

Clojure, floats, ints and OpenGL

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 developme