IRC channel logs

2013-07-24.log

back to list of logs

<nalaginrut>morning guilers~
<brendyn>If I were remaking something like emacs i would take the opportunity to fix old problems like crappy keybinding defaults
*youlysses loves the default bindings... :^U
<mark_weaver>hello guilers!
<davexunit>hello mark_weaver!
<mark_weaver>davexunit: I hacked up something that you might appreciate. it's a preliminary patch for guile to make floating point numbers immediates (not heap allocated), at the cost of 3 less bits of precision (50 bits instead of 53 bits).
<davexunit>mark_weaver: !
<davexunit>wow that's a pretty awesome development
<mark_weaver>I did some simple tests and it seemed to make floating point math about 4 times faster, and of course no GC required.
<davexunit>I was debating moving my sprite batch code into C or perhaps a GLSL vertex shader, but perhaps I'll leave it in Guile if performance will improve in the future.
<davexunit>mark_weaver: the no GC is the real improvement.
<mark_weaver>at the cost of one less bit of precision on fixnums (61 bits instead of 62)
<mark_weaver>when we have native compilation, it should get a lot better.
<davexunit>I can use pooling techniques to get around the GC for my own data types, but I don't know how to deal with fundamental things like floating point numbers
<mark_weaver>and the use of the R6RS flonum library will be able to help the compiler with that quite a bit. (although at present, the flonum+fixnum libraries only makes things slower).
<davexunit>I wonder if the precision loss be a no-go for people?
<taylanub>Were all floats heap-allocated before this ?
<davexunit>I was about to say that I tried flonums
<davexunit>and I got even worse performance.
<tupi>mark_weaver: this is great! will you make this vailable in stable?
<mark_weaver>yes, and they still are. my patch is not ready to be committed, and I'm not entirely sure it's a good idea to commit.
<davexunit>granted, it was a quick hack
<mark_weaver>and it definitely cannot be deployed in 2.0.x, because it changes the representation of fixnums, which is part of our ABI and cannot be changed in 2.0.x
<davexunit>the precision issue is a concern, but the idea of not having floats on the heap sounds soooo good to me.
<davexunit>would that be a 2.2 thing, provided it was committed?
<taylanub>I didn't know our float situation was that grave. :P (Or is it not *that* bad to haep-alloc all floats ? Before hearing that Guile does it, i.e. right now, I would've thought that it would be an *unacceptable* thing to do. :D)
<mark_weaver>davexunit: right. though I think the only way it could be committed permanently would be as a run-time flag.
<davexunit>hmm.
<davexunit>better than nothing I suppose.
<taylanub>Run-time flag sounds neat, configurability FTW.
<mark_weaver>taylanub: it's very painful, but it's pretty much standard for languages where types are associated with values (not variables), which includes most modern dynamically-typed languages.
<davexunit>wingo and I both hit this issue with floats whilst doing our own separate experiments with particle simulations.
<taylanub>I see, I thought it would be one of the first things to optimize (along with ints and cons-cells ...)
<taylanub>I wonder how Elisp does it ?
<davexunit>likely the same way
<davexunit>it's not really an issue for elisp
<mark_weaver>taylanub: the problem is that C doubles are 64-bits, and there are no bits to spare for a type tag.
<taylanub>Ah, and one cannot bit-shift them (as easily) ?..
<mark_weaver>there are two usual ways to make floats faster on high-level languages: make a clever compiler that can infer the types of some variables, thus eliminating the need for a type bits in some cases (this is called "unboxing"), or to use "NaN-boxing", which means that you use doubles to represent *everything*, with NaNs being used to represent all non-floats.
<mark_weaver>The problem with NaN boxing is that it penalizes everything other than floats, and allows only about 52 bits for everything else.. which means much smaller fixnums, and a much smaller range of addresses that can be directly stored.
***serhart_ is now known as serhart
<mark_weaver>davexunit: anyway, my patch is not nearly ready for consideration, but you're welcome to play with it in the meantime and see whether it helps you.
<mark_weaver>davexunit: oh, one more thing: you might consider using Guile's native complex numbers to implement your 2D inexact vectors.
<mark_weaver>davexunit: then (real-part Z) and (imag-part Z) would be the X and Y coordinates, and you could add vectors with (+ A B), scale them with (* scale A), point them in the opposite direction with (- A), etc.
<mark_weaver>you can even do things like rotate these vectors using (* A (make-polar 1 <angle>))
<mark_weaver>(where ideally the result of 'make-polar' would be cached for commonly-used angles
<mark_weaver>rotate by 90 degrees by (* A -i) or (* A +i) (clockwise and counterclockwise)
<mark_weaver>davexunit: I'm reasonably confident that one way or another, we'll fix the efficiency problems with floats. Ideally we'd fix it by clever compilation, but in the meantime there's this hack that could act as a stopgap measure for you, to allow you to use more Scheme and less C :)
<mark_weaver>actually, it's not entirely infeasible to add this to 2.0.x, but in 2.0 we'd have to lose 5 bits of precision, not 3.
<mark_weaver>oh wait, sorry. it's not doable in 2.0.x at all.
<mark_weaver>well, maybe. I have to think on it some more.
<davexunit>mark_weaver: sort of afk. will read shortly.
<mark_weaver>davexunit: no rush. we can talk later.
<tupi>mark_weaver: in 2.0.x would be great for all of us who are or would like to use guile for intense 'small precision' float/integer computation. this is the case for digital image processing, which i slowly dream of being able to do some in guile, one day, maybe, and then guile 2.2 will be there already i guess :)
<mark_weaver>the issue with 2.0 is that the SCM_REALP and SCM_REAL_VALUE macros are part of our ABI, and yet they would not recognize the new immediate floats.
<mark_weaver>However, if these immediate floats were enabled by a run-time flag, then programs compiled against the old headers would still work as long as you didn't enable the flag.
<tupi>that would be great, i think
<mark_weaver>OTOH, keeping both the old and new kinds of floats would make the numerics code more complex.
<mark_weaver>I'm still not sure if this whole idea really makes sense, given that a clever compiler will probably solve these problems in a much better way.
<tupi>meanwhile a have a <gtk-cell-renderer-spin> list-store renderer problem: anyone using guile-gnome and this beast?
<tupi>mark_weaver: yes, maybe it is not worth the effort in 2.0.x, i agree
<tupi>... (make <gtk-cell-renderer-spin> :family "Monospace" :climb-rate 0.1 :digits 1) ...
<tupi>it does _not_ the digits argument and displays my floats with many decimals. anyone knows a solution ? [appart from rendering as text i mean, that i'll do as an ultimate solution]
<davexunit>mark_weaver: thanks for the explanation of my options
<davexunit>the complex number thing is pretty cool, but I don't think it would solve my issue, since I'm eventually storing floating point numbers in a bytevector for opengl calls.
<nalaginrut_>hah~ guile-redis is cool~
<add^_>psyntax-pp go go go
<add^_>I'm glad that I at least don't have dsmith's old computer. ;-)
<add^_>Then compiling guile would take all weekend
<add^_>Or should I say sneek's old computer?
<add^_>sneek: botsnack
<sneek>:)
<add^_>wow, that's some latency.
<add^_>Hm, ping seems to be fine though
<add^_>sneek: later tell ijp Something seems to have been broken since the last updates (of guile) with guildhall, &assertion or something.. Not sure.
<sneek>Got it.
<mark_weaver>sneek's computer is actually fairly new, but indeed not so powerful. it's a raspberry pi.
<mark_weaver>sneek: botsnack
<sneek>:)
<add^_>I know :-)
<add^_>mark_weaver: I was talking about the old computer sneek used to be on.
<mark_weaver>ah, okay :)
<mark_weaver>The trick I used for my raspberry pi was to simply copy the .go files from an intel-based machine.
<add^_>Oh?
<add^_>I thought the raspberry pi was ARM?
<add^_>Cool though
<mark_weaver>iirc, as long as the word size and the endianness is the same, the .go files are the same as well.
<add^_>aha
<add^_>Neat
<mark_weaver>maybe there's some detail I'm missing, but it seems to work for me anyway :)
<add^_>^^
<davexunit>I need to get guile on my raspberry pi sometime.
<davexunit>I need to actually use my raspberry pi, in general.
***linas_ is now known as linas