Hi Rob,
This one seems to produce a much, much better structured and completely filled-out grid -- looks cool!
I wish there were some algo to have it smoothly colored or perhaps even turned into a surface rather than point cloud. A "real" 3D model might look really awesome.
1. The
Abs() et al. problem in a tight loop is the function overhead, i.e. the time it takes to push the arguments, perform the actual call, and then fetch the return value clearing the arguments off the call stack in order to balance it. The time penalty accumulated over thousands of calls may be much heavier than the task that the function actually performs. You can see it yourself in
x*x>y versus
Abs(x)>y, even if floating-point multiplication and comparison aren't as speedy as their integer counterparts.
In C/C++/compatibles, you can define
Abs() and other critical expressions as a preprocessor macro or inline function that would expand to a very fast in-place
x < -y || x > +y though they would still look like function calls in the source script. But you can't do the same in most contemporary BASICs.
2.
dynload is what *nix geeks would name the process of loading a dynamically linked library (
.dll in Windows,
.so in Linux, and
.dylib in OSX) and calling functions from it. Such calls are executed exactly as fast as if the code were statically linked into the executable proper.
The difference in execution speed may be due to how well (or rather bad) GCC is optimized for Windows. The chase for being a Jack-of-all-trades for all known platforms often leads GCC to not being optimized well enough for anything other than PC Linux, and some of its optimizations for minor OSes in some of its builds in the past were known to break its compatibility with the best operating system in the world -- MS Windows -- very badly.
