Thanks John.
So here's one more strategic decision to take.
We should realise that both SB and FBSL are now dealing with an interpreter implemented in an interpretative language. This is interesting and instructive but quite weird and uninspiring, speed-wise.
Let's take another recursive example from the Rosetta Code site that computes Fibonacci numbers up to the
26th number in the
topmost Fibonacci sequence here.
The algorithm uses two child recursions in each parent recursion so that the recursive tree grows deeper and deeper as the span of possible numbers to evaluate becomes broader with each next number to find following those already found. This is a very serious stress test to verify the integrity of memory management in a language. Both SB and FBSL LISPs pass it successfully, but!
A static or JIT compiler would do this blazing fast even for a much larger Fibonacci number while the 26th number will be found so fast that the benchmark won't be even registered with the Windows system tick timer.
We can assume that both Oxygen and FBSL's DynC JITs are equally fast and very close to static compilers. So the Fibonacci function written directly in either of them can be taken for reference. Please take a look at the leftmost picture below. It implements this function in C and tries to benchmark it as it runs in JIT-compiled machine code. It will run just a little faster in a true optimizing static C compiler like VC or GCC.
Next we can roughly assume that SB and FBSL have equally fast BASIC interpreters. Have a look at the middle picture below. It implements a verbatim equivalent to the function used in the C benchmark above but rewritten in FBSL BASIC. You can easily translate this code to SB to see the SB results on your machine. Or you can use it for equivalent Oxygen code to verify JIT BASIC speeds compatible to my JIT C above.
And finally, we can roughly assume that our LISPs are also equal in their potential at their current internal settings. So now have a look at the rightmost picture. It presents a verbatim equivalent rewritten in BASIC LISP (I'm always using this term to denote its three current implementations in SB, FBSL, and O2 at once). You can try it on your SBLisp on your machine too to the same effect if you're patient enough. And we'll be also able to test it in OxyLISP as soon as its GC is fully functional. OxyLISP will be showing the results very close to what we have for interpreted SB and FBSL in the middle picture below. No wonder: it will be an interpretative LISP with an engine running in true machine code.
We will never be able to achive OxyLISP results in both SB and FBSL LISPs as we know them now. They are no match for the former. Hehe OxyLISP will be a good match for SB and FBSL BASICs instead.
So we should take a strategic decision now what is reasonable to do in the future. My current opinion is as follows:
-- OxyLISP can continue its development based on the code at hand;
-- FBSL LISP should be rewritten in DynC and therefore go fully C compliant; and
-- SBLisp should be rewritten in CBASIC where possible and utilize verbatim C inlines where not, i.e. inherit the best of the two worlds.
What else can we do so as not to be wasting our time for nothing? I do not know.
.
