The Return of Tiny Basic (2006) | Hacker News Reader

The Return of Tiny Basic (2006)

drdobbs.com

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...

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)

I've been surprised how fast javascript can go - faster than C here. They did good work on that JIT.

Playing around I see: for (i=1;i<1e9;i++) {}

runs about 10x faster than: for (i=1.5;i<1e9;i++) {}

presumably because it complies to integer code for the first (using Chrome)

> faster than C here

It's "faster than C which swims with the tied hands": when you allow all optimizations C is "infinitely fast" in this given case, as the loops aren't even executed but the results precomputed in the compile time.

Can you give your numbers for Chrome? Typically it was slower than Firefox for such Javascript since a while. Note that to make comparison fair you have to use a while loop in a while loop and to print the resulting counters after both loops finish.

> 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.

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.

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

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

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

and here I thought it had returned again.

Reply on news.ycombinator.com