Ray Tracing in J
17 points by veqq
17 points by veqq
I should also mention, it is fast. I’ve written a very similar ray tracer in Common Lisp (which I won’t claim to be any good at, but certainly have at least as much experience in) and without optimizing anything in either implementation J is performing around 5 times as fast. While it isn’t very fair to CL or indicative of what can be done in the language it does seem telling that a fast solution is more apparent in J, at least to this novice.
unfortunately, i think it is not really telling of very much. skimming both of them, the author got a bit unlucky in his j solution, and then really quite unlucky in his common lisp solution. the predominating implementations of both j and common lisp have very fragile and unintuitive performance characteristics if you do not know what you are doing. there are simple, fairly mechanical transformations that could be undertaken on both implementations to get significant integer factor speedups, which i can easily see because i do know what i am doing, but those implementations should do them automatically
Which transformations?
undertaken on both implementations to get significant integer factor speedups
Are these the kind of issues which made Beach start SICL (i.e. SBCL maintainers not wanting to allow some improvements for reasons I don’t know/understand)?
Which transformations?
j: vectorise more instead of tracing every coordinate separately
common lisp: avoid dispatch and indirections/allocations from generic array accesses and generic numerics on boxed floats
SICL
not exactly but sort of indirectly. sbcl’s compiler has a lot of technical debt and there is not much interest in making it not suck. sicl was designed to be more modular and cleaner so that it would be easier for people to contribute to all components of it, including the compiler. robert has stated he’d be ok with performance slower than sbcl for the applications he cares about, so it’s not a particularly salient concern for him
there is some limited planned facility for speculative optimisation (it’s not good enough but it’s something). and last i checked, bike was doing a lot of work on clasp’s fork of cleavir (the compiler) and knows what he’s doing