That sounds about right. The big caution I would place on interpreting these results is: "This won't necessarily apply for games implemented in J for Linux, where I intend to rely on the SDL and byte-per-pixel graphics layouts. Nonetheless, I retain the logic here, since it's representative of a real-world design decision which directly influences performance on the slower Kestrel architecture."
If J is to perform well when applied in suboptimal fashion we'll need some way of representing the code which strips out a lot of the functionality (type checks, size checks, rank handling, maybe even overflow handling?), at least for the time-critical routines. (As much as possible, hoisting redundant operations out of primitives used in bottleneck loops.) Thanks, -- Raul On Sun, Jan 12, 2014 at 11:59 PM, William Tanksley, Jr <wtanksle...@gmail.com> wrote: > A friend of mine wrote the following paper describing his attempt to > characterize the differences between a few different styles of > implementing the same code in J a few different ways -- explicit, > implicit, and a few variations. He also baselined against a Forth > implementation. > > I found his writeup very interesting. What do you think? > > http://sam-falvo.github.io/2014/01/05/subroutine-performance-in-j/ > > -Wm > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
