Compiler Speed Trials

[britlion]

First of all, a big Thank you. Wow! What an impressive work! :o

I like ZX Basic A LOT. I want it to produce the best code possible. *grin* Perhaps we can get it to the point where it gives that upstart C compiler a run for its money. *hmmph* A zx spectrum should be coded in basic *laugh*

The above benchmarks are interesting. I'm somewhat surprised of BM7 I didn't suppose array handling was so slow.
BTW do these compilers handle multiple-dimentions arrays?

No. Yours is the only one that will do that from this list. I think Hisoft Basic did, though. Some of them won't do it at all. ZIP might be fast, but it's VERY limited in what it can do - not even string handling, I believe.

Yes, -O3 definitely makes a difference in array-access speed :!: This is something I'm currently fixing. It seems I reintroduced 2 old bugs back (one in the peephole and another on comparators already fixed). I'm currently working on them.

When the optimizer is back together, I'll re-run the speed tests, certainly. Sadly, -O1 seems to work, but anything higher than 1 just fails at the moment.

I'm happy to read this.
For the FP, it's somewhat odd: I just use constant folding (precalculation) and ROM-CALC for that. Please, check the FP results are right... I mean do you print the FP calculation result on the screen? Do they match? How strange... :| I like this FP result, but... as you, I'm too surprised.

I was too, especially given the little tutorial I wrote about using smaller data types when possible to get the fastest code - we know handling five byte numbers (and in the rom routines too) is slower than integers.

You can see the code I wrote and ran - it finds sin(2), ln(2) and 2^2 in the loop. I'm pretty sure the 2^2 uses integer math, and rightly so; but sin and ln...well... if you're using ROM routines, I have no idea why it came back that fast. Does it work out a fixed result for sin(2) and just use that? That would be one reason it works so quickly!

It ISN'T printing the numbers, because it would make it very slow - PRINT is a pretty time consuming thing to do. I'm wondering if it might be possible to have a faster print routine that doesn't do all the bounds checking, and control character checking. I tested the loop with printing on - and it spun through some decimals happily. I timed it with printing off. I did wonder if the compiler would optimize out data that wasn't being used. The time results for this test were staggeringly fast.