I have to disagree.
When it comes to benchmarking, it is vital that someone else can reproduce your result.
Seconded. While the benechmarks and results presented here are certainly fun, I wonder what's really being measured. Machine-to-machine speed is lost, since the performance of a BASIC program is also dependent on the performance of the BASIC interpreter.
And the programs need to be modified just to work, since the hardware (and BASIC) isn't identical. But it also probably leaves performance on the table -- adjusting the code to take advantage of features of each platform isn't done (or is it?) and means that each examined platform might end up being faster than the benchmark allows itself to demonstrate.
That plus the fact the the Mandelbrot benchmark, as currently written, includes the time needed to display the result. Display speed varies wildly from platform to platform.
A more accurate test can be had by creating the output in a string or array, then displaying it. The time to build the output may be more interesting for some people while others may care about the display time or the total time.
As the author of this thread and the Mandelbrot code in it, I would have to suggest using caution here....
It is true that output time can affect things, however in this case the millions of floating point calculations by far outweigh the output speed (or lack of) any terminal (OK, lets not think about using a TTY33 here!)
Test runs with my code under BBC BASIC 4 on my 16Mhz Ruby: With printing: 48.24 seconds. Without printing 47.26. A difference of 0.98 seconds or maybe 2% faster... So while measurable, that's not significant in the times we're talking about here and my suspicion is that doing something like: O$(L) = O$(L) + MID$(...) would take longer than simple PRINT MID$(...
OK - I'll test it.... 49.28 seconds. Which has surprised me as I thought storing with string concatenation might be slower but in brief, it's about a second either way. Storing and printing later added a second to a 48 seconds run, and not printing saved a second.
Someone else can try this under EhBASIC, etc. ...
But again, in all cases do be careful what you're benchmarking - this is all about floating point performance. I deliberately wrote it to try to make it source-code (at the textual level) compatible with generic BASICs, so MS style BASICs, BBC Basic and my own RTB Basic. There is no point in, say, re-writing this in a system with scaled Integers then saying - look how much faster this is because you're really not comparing like for like.
With regard to printing, my RubyOS tries to line-buffer output as the transaction between the 6502/816 and the host MCU has a rather high latency, so there is a 128 byte output buffer that's flushed when a newline is printed or input is requested. One thing that came up on another forum (stardot) was the time taken to check for Control-C, (relatively high on Ruby under EhBASIC and CBM2) so it's sometimes worthwhile turning it off, but again, you're falling into the trap of optimising a benchmark for your own platform.
(RubyOS has the same concept of "Escape" as the Acorn MOS which handled it asynchronously via interrupt and the test for escape is to simply check bit 7 of $FF which is very fast and efficient)
Maybe it's time to re-write or just re-publish those old PCW benchmarks, but then again, that's been done to death many times over the past few decades and we're not going to learn anything new - old MS style Basics are slower than newer (e.g.) BBC Basic because the newer Basics were written by some very clever university boffins who had the benefit of using those older systems, reeling back in horror and saying "Hold my Beer" ...
-Gordon
