I've only ever seen the one standard one from I/O magazine, so I'm not clear if you think that one isn't good (it seems fine to me) or if you've discovered something I've not come across. Anyway, it's not hard to find; obviously just search for "I/O別冊 PC-8001活用研究."
I would say the main problem here, sure, is on my end, IE, I'm not conversant in the correct language to search for information about this computer.
Anyway, now that I have an actual schematic of it to look at (all I could find before was a block diagram) it's plain that, yes, this thing has a hardware cursor. So whatever other periodic interrupt overhead it might have blinking the cursor is probably not a component of it.
The Aquarius+ is probably using a single point, hence the precision is fairly poor compared to the rest. But it goes to show how even within the same group of CPU, you can get pretty widely different performance.
Most Microsoft 8 and 16 bit BASICs that support both single and double precision default to single precision; since you didn't specify I'm pretty positive that's what you're getting on the IBM 5150. (The format of the value you put in the table in the block post actually makes it feel like it's a sure thing it was single precision, because it's the number of digits that the single precision results returned for me on GW-BASIC.) Also, FWIW:
I'm curious if someone has a V-20 equipped 5150 if their numbers match mine or the 8088 machine's numbers. (IE, is it the CPU, or is there a difference between the code in the IBM BASIC ROM and what went into the stand-alone disk version of BASIC.)
I did the obvious control and ran the benchmark using GW-BASIC in DOSBOX; the precision and randomness numbers agree with my Tandy 1000. So I would *guess* it is a difference in the BASIC code stored in the original IBM ROM implementation and *not* a CPU variance.
Anyway, per my observation setting double precision with GW-BASIC at least hardly changed the execution time *at all*. I'm pretty confident saying that most of the variation in these scores has practically nothing to do with the actual CPU in the machine and it's all about the actual language implementation. I mean, recall my guess about what was actually taking so long for GW-BASIC was the repeated runs of the RND command? Just for laughs I stuck a REM in front of the contents of lines 40, 70, and 90, IE, commented out the square-ing, square root-ing, and the floating point addition at 90, just leaving the two sets of R+RND(1), and at 7.16mhz it cut the runtime from 12 seconds to 8. And then, to really take it over the top, I converted lines 45 and 75 to just "A-RND(1)", getting rid of the addition entirely, all the nested loops are doing is getting, what, 2000 random numbers? And... that takes about six seconds.
Trimming it down to the very, very minimum:
Code:
1 DEFDBL R
2 DEFINT N
20 FOR N=1 to 2000
75 R=RND(1)
95 NEXT N
IE, getting rid of the conversion of the iterator N from integer to float at the start of each cycle and ditching the nested loops, takes it down to 4 seconds at 7.16mhz.
So... yeah. It looks like at least a third of the runtime of this program when run on GW-BASIC is *just* getting the random numbers, and it also looks like the overhead of running the FOR loops is a significant factor; at least with GW-BASIC the time actually spent on doing the arithmatic is a minor enough component that it doesn't even matter if it's single or double precision.
You know what's really a hoot? Since it was there I decided to try running the program using several other BASICs I have installed on my Tandy 1000, IE, the "qbasic" interpreter included with DOS 5, and then I tried compiling it with actual QuickBASIC 4.5 for DOS. Here are the results in single and double precision at 7.16 mhz:
| lang/precision | f/a | randomness | time |
| gwbasic/double | 5.938744544977226D-03 | 7.188650009002686 | 12 seconds |
| qbasic/double | 7.275846591880963D-13 | 6.234999179840088 | 34 seconds |
| qb/double | same | same | 31 seconds |
| qbasic/single | 1.152344E-02 | 6.234985 | 35 seconds |
| qb/single | same | same | 30 seconds |
These results make my head hurt, because usually qbasic is a *little* faster than GW-BASIC, while compiled QuickBASIC will completely and utterly blow the doors off it. (Well, at least with code that uses integers as much as possible.) But, no, both newer BASICS take three times longer than GW-BASIC.
What's really odd is that loop of 2000 RNDs takes the same 4 seconds as GW-BASIC. So apparently the two BASICs use the same method to generate random numbers... but why in the world is the math performance so much worse on Q[uick]Basic? The "float accuracy" for double precision *is* much, much higher than GW (if the numbers on your table are to believed it actually crushes *all* other contestants), but the speed doesn't improve with single precision? Does QuickBASIC do everything internally as double even if you say single?(*)
(
*EDIT: Looked it up, apparently QBASIC/QuickBASIC use full IEEE representation for floating point numbers instead of Microsoft's binary format. So it's legit lugging a much bigger stone around its neck. If I had a numeric coprocessor that'd be great, but, well, I don't.)
Also, just for grins I tried this in a "cycle-accurate" TRS-80 Model I emulator (1.77mhz Z80) with both single and double precision specified. If I get a chance I'll try it on my real TRS-80 to confirm the speed is correct. Just like GW-BASIC single vs. double precision seems to make very little difference. I have to admit I find this rather puzzling. Is single vs. double more about saving memory than performance?
| f/a | randomness(*) | time |
| double precision | .03404722213744549 | 8.140957355499268 | 2:19 |
| single precision | .0338745 | 23.7814 ... or 6.61066 ... or... | 2:15 |
* the "randomness" value varies *a lot* between different runs on the TRS-80... which triggers vague memories that GW-BASIC uses the same seed every time you RUN unless you use the RANDOMIZE command at the start of a program, while the TRS-80 just uses the value of the DRAM refresh register as the seed unless you give it a specific one with RANDOM?
EDIT: Did some more reading on RND in Level II basic, and it says the value returned by RND(0) is always a single-precision value. I'm willing to wager that the bulk of the time difference between the single and double precision TRS-80 runs is just converting the output of RND into double on those lines.
Anyway, again... as a real world *hardware* benchmark I still have to say this thing... leaves a lot to be desired. Unless, I dunno, you're writing a lot of BASIC software that *really* relies on random numbers and will only consider in your evaluation the software that comes in ROM? What this *doesn't* do is tell you anything meaningful about the actual hardware of the computer. As *all* the numbers prove, your mileage is all down to the software implementation of your interpreter, not the hardware under it.
voidstar.blog
