IRC channel logs


back to list of logs

***fangism is now known as fangism-at-llvm
<nalaginrut>morning guilers~
<ArneBab>mark_weaver: how do you call TCO in scheme?
<ArneBab>nalaginrut: that has multiple meanings, I think (IIRC it’s also used for /usr/bin/env)
<ArneBab>is there some unambigous wording which sounds like “this is something special”?
<lloda>'proper tail calls'
<nalaginrut>dunno, my understand is 'proper tail calls' is better TCO-able
<nalaginrut>rather than TCO itself #IMayWrong
***Guest26662 is now known as Cork
<ArneBab>“proper tail calls” sounds like “should be available in software”, which is rather nice.
<nalaginrut>huh, I just learned that CPS generator provides a natural context for register allocation, so I guess the allocator in 2.2 will be very different and interesting ;-)
<nalaginrut>maybe 2.4
<civodul>Hello Guilers!
<wingo>morning civodul :)
<nalaginrut>I'm glad we have weak hash, then it's easier to implement the same thing in lua~
<janneke>hi all
<dsmith-work>Morning Greetings, Guilers
***brendyyn is now known as brendyn
<davexunit>hello guilers.
<davexunit>I have a memoization problem to solve for my game engine.
<davexunit>does anyone have any tips for memoizing procedures in which the internal cache has a size limit or uses weak keys?
<davexunit>my basic problem is this: my rendering algorithm traverses a DAG every frame, and calculates the transformation matrices of each object by multiplying the object's local transformation matrix with that of its parent.
<davexunit>this leads to a lot of unnecessary work when a scene is mostly static. matrix multiplication is expensive, and it increases the frequency of GC runs.
<davexunit>traditionally, people use a "dirty" flag to mark when an object needs its matrix recomputed, but that is insufficient because this high-level DAG structure is immutable.
<davexunit>I'm done rambling now.
<paroneayea>davexunit: make the DAG structure not-immutable and restrict the domain of what's allowed to affect it? :)
<paroneayea>not-immutable, aka mutable, go language :)
<davexunit>I would like to just memoize the procedures that act on the immutable objects to cache their return values, but "there are only two hard things in Computer Science: cache invalidation and naming things."
<davexunit>paroneayea: the other problem is that its possible to re-use parts of the graph in multiple places. in other words, a node can have more than one parent.
<paroneayea>I suppose I can't be helpful here
<davexunit>which is quite useful, honestly. I don't want to sacrifice that. I think it would be strange for users if that didn't work.
<davexunit>you're helping me brainstorm. :)
<paroneayea>maybe instead of setting flags
<paroneayea>you should accrue a list of functions
<paroneayea>with relevant things to recalculate?
<paroneayea>a list of curried procedures
<paroneayea>and then just execute them
<paroneayea>hm, that may make no sense in this juncture :)
<paroneayea>maybe by replying to my nonsense you will figure out what to do :)
<paroneayea>what I mean though is maybe if you can't attach a list of flags because the thing is immutable
<paroneayea>maybe you should accrue the flags outside of it somehow
<davexunit>I think I should stop thinking about this for a minute, and just memoize the procedures that I think need memoizing and see what the performance benefit is.
<paroneayea>do it!
<davexunit>then worry about the fact that the cache will just continue to grow out of control.
<paroneayea>davexunit: without knowing how it works, I say: maybe you could use a bloom filter to handle de-cacheing
<paroneayea>all I know is that's how git-annex handles dropping unused files :)
*paroneayea just throws names of things at davexunit till he gets permanently banned from #sly and #guile
<davexunit>paroneayea: :P
*paroneayea is the worst sounding board
<dsmith-work>Just talking to someone really helps. Being forced to verbalize the vague ideas floating in your head tends to crystallize things.
***spock_ is now known as spock