Compiler Speed Trials

[boriel]

Finally got a quick chance to test this. Yes, -O3 does improve BM7 - but the 0.16 seconds value isn't really fair. -O3 reports that variables are not used and optimizes out all the loops!

I don't remember that optimization. Which code snippet are you using? BM7 above?

Hmm. You yourself said:

if O3 were in use, this program could be reduced to a single NOP, as it does nothing (it does not print on the screen).

This "reduced to a single NOP" optimization was removed in 1.2.5 since an empty loop makes sense for programmers who need execution delay. But there are other "unused variables" optimizations which only optimize SPACE (memory) not SPEED (code). So I still don't understand this difference in Speed. Anyway, here is your latest BM7 code:

Code:

7 REM :INT +a,k,v,i,m()
    8 REM : OPEN#
    9 CLS
    10 POKE 23672,0: POKE 23673,0
    90 POKE 23672,0
    100 LET a=0: LET k=5: LET v=0
    110 LET a=a+1
    120 LET v=k/2*3+4-5
    130 GO SUB 1000
    140 DIM m(5)
    150 FOR i=1 TO 5
    160 LET m(i)=a
    170 NEXT i
    200 IF a<1000 THEN GO TO 110
    210 PRINT (PEEK 23672+256*PEEK 23673)/50
    999 STOP
    1000 RETURN

I'm going to test with this code. Please, confirm this is the correct test-case.

Do the other compilers allow multidimensional arrays of float / string / Integers?

You asked that before, and I'll say again: Almost all of them only allow single dimension number arrays. (Zip compiler won't deal with strings AT ALL!). Hisoft basic does allow multidimensional arrays and string arrays:

HiSoft BASIC supports numeric and string arrays of up to 2 dimensions. Ordinary string variables behave as in BASIC except that they must not exceed in length the amount of space reserved for them at compile time. By default this is 257 bytes (to allow a string of up to 255 characters, plus 2 bytes for the length) but it can be changed by means of the REM : LEN directive.

Quite outside the array issues, I think Hisoft Basic's string handling is vastly less flexible, but far faster than yours. Your strings are always mutable, and of variable sizes. Hisoft uses far less memory efficient fixed string system, not in the heap, which is faster to use. As always, it's memory size and waste vs speed, here. Luckily I've never seen your neat and efficient strings running too slowly, so I think the only "issue" here is array handling. I don't know why your version of the array handling code is the slowest of the tested integer compilers. Is it to do with it handling more variable types, and having to deal with that?

ZX Basic allows per-element size up to 65535 char strings (2 bytes length). I could reduce it to 1 byte (up to 255), but I know of many Sinclair BASIC programs that use long strings (e.g. 1000 chars) for strange purposes. In fact I used this technique very often. Thus, not supporting 256+ length strings will break (even more) compatibility with Sinclair Basic.

Does it internally know the difference between an array of strings and an array of bytes? Are these different types to the compiler? A fixed size array of numbers is really just a lookup table. Your variable sized string handling (while brilliant in its memory efficiency) makes string arrays much much more awkward to deal with. If you're using the same code to handle arrays of ANYTHING, I can see why hisoft seems to be going faster, here.

Yes, having 1 dimensional array (a vector) is very fast. For a vector of bytes, you can even use IX + n indirections. Having up to 2 dimension arrays can also be optimized (in fact, z88dk also uses 2 dimensional arrays or vector, I can't recall know, but in the end, you have to compute the element offset your self).

ZX BASIC tries to be as much compatible as possible with Sinclair Basic. So it allows multiple dimension array. Each dimension carries out a multiplication. It also allows "any size" elements (BTW, Strings are pointers to the Heap, hence 2 byte elements). Currently, only 1, 2, 4, 5 element sizes are allowed. The multiply-chain (1 multiplication per dimension) ends with an extra multiplication (element size) to get the final element offset.

This final element-size multiplication could be slightly optimized:

• Size 1 => Return
  
• Size 2 => Shift Left, Return
  
• Size 4 => Shift Left, Shift Left, Return
  
• Size 5 => BC = Size, Shift Left, Shift Left, +BC, Return

But in the future, when objects / struct are available, "anysize" elements will appear => multiplication.

Update: You can implement an array as a cascade of look-up tables. This is the way I implement them in C (it's really fast), but in a 48K-memory machine this is prohibitive! :|