
The Return of Tiny Basic (2006) - bryanrasmussen
http://www.drdobbs.com/web-development/the-return-of-tiny-basic/184406381
======
acqq
The section about speed had some interesting claims:

> The direct interpretation technology chosen for Tiny Basic sacrifices up to
> an order of magnitude execution speed, but the speed of modern computers
> reduces the impact. Moreover, the memory bus bandwidth limits in modern
> computers can completely cancel the speed advantage of native code over
> interpretation.

I decided to verify how much TinyBasic really achieves. Downloading

[http://www.ittybittycomputers.com/IttyBitty/TinyBasic/TinyBa...](http://www.ittybittycomputers.com/IttyBitty/TinyBasic/TinyBasic.c)

compiling it with VC -O2, and running the program to count to 10 million (for
which it seems a loop in loop is needed as TinyBasic variables are 16 bit).
The result: around 20 seconds needed to count to 10 million. The inside loop
is:

    
    
        10 a = 0
        20 if a > 9999 then goto 50
        30 a = a + 1
        40 goto 20
    

It's far from the optimal modern interpreter speed. I've repeated the same
procedure with Python, which used 14 seconds for the 10 times bigger count.
Lua 5.1 needed 4.4 seconds for the same loops as Python.

Finally, to compare with the compiler which is intentionally controlled not to
overoptimize, I've made a loop in loop in C too, declaring both variables as
volatile to avoid optimizing the loops out or doing too much at once, giving
the inner loop:

    
    
        $LL3@main:
            add	DWORD PTR _a$[esp+8], eax
            mov	edx, DWORD PTR _a$[esp+8]
            cmp	edx, 100000
            jl	SHORT $LL3@main
    
    

The VC for 32 bits needed 7.8 second to count to 1 billion, and assuming the
"3 equivalent lines of the inside loop" (assuming the last two are the
equivalent to "if") that gives 385 M "equivalent lines" per second. Moving to
the even higher optimizations, the equivalent Javascript in Firefox needed 3
seconds to count to 1 billion, and the C code without "volatile" optimizes the
loops away completely, needing 0 seconds.

The relative speedup vs TinyBasic:

    
    
          1 TinyBasic
         14 Python 2.7 (Interpreter)
         45 Lua 5.1 (Interpreter)
        256 Visual C (volatile vars)
        667 Javascript in Firefox 59
        inf Visual C (loops optimized away)

~~~
timbit42
> Although Tiny Basic is tiny, if the IL interpreter generally fits into the
> primary CPU cache with its IL, while the much larger native code does not,
> the IL code will execute at native CPU speed while the native code thrashes
> much slower.

Caches are larger today than in 2006.

~~~
acqq
[https://en.wikipedia.org/wiki/Pentium_M](https://en.wikipedia.org/wiki/Pentium_M)

Pentium M, introduced 2003, 1 MB L2. Since 2004: 2 MB L2.

I'm quite sure the TinyBasic was slower than the "properly written"
interpreter even in 2006, even comparing on the 256 MB L2 cache CPU. Lua
language exists since 1993, it was actually tiny enough and fast from the
start.

------
fernly
Tom Pittman, the author of this article, is still extant at [1], or at least,
he wrote a blog post [2] in May 2018. However it is not clear to me why this
old article should be reposted. Is Tiny Basic [3] of any current interest?

[1]
[http://ittybittycomputers.com/Bio.html](http://ittybittycomputers.com/Bio.html)

[2]
[http://ittybittycomputers.com/WebLogs/WebLog18a.htm](http://ittybittycomputers.com/WebLogs/WebLog18a.htm)

[3]
[https://en.wikipedia.org/wiki/Tiny_BASIC](https://en.wikipedia.org/wiki/Tiny_BASIC)

------
codewritinfool
and here I thought it had returned again.

