3 ms·
The section about speed had some interesting claims: > The direct interpretation technology chosen for Tiny Basic sacrifices up to an order of magnitude execut
by acqq 9y ago
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/TinyBasic.c 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)
- tim333 9y agoI'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)
- acqq 9y ago> 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.
- timbit42 9y ago> 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 9y agohttps://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.