JamesD

31 minutes, 20 seconds. Congrats, you broke MS BASIC That would be dog slow even at double speed.

Does this program actually finish? It's been running for 20 minutes.

SORTBAS7.MSB isn't formatted so I can use it. How about carriage returns instead of > I used the data from the text file version and reformatted the code. GOTO everywhere. This is definitely not written by someone used to optimizing MS BASIC code.

If you look at how MS BASIC is implemented, it works pretty much the same way on every 68xx & 6502 platform. If anything, it's closer to the machines doing the same work than any other test. The one significant difference... patching the BASIC to take advantage of the hardware multiply on the MC-10 & CoCo 3 makes a huge speed difference. The MC-10 number even came from an early version of BASIC I created that is missing most of the optimizations I've written. Most of the changes in that version were to squeeze in the larger multiply code. I know you don't like the slower numbers, but it is most definitely a good machine to machine comparison.

Not for a MS BASIC.

Practical? Do benchmarks have to be practical? The DATA statements are a PITA, but the MC-10 doesn't have a disk drive, and that's what I used to test my BASIC changes. Sorry it turned out to be a wrench for the Atari. Would a disk file have been better? That would be a PITA on MS BASIC since every DOS is different. Is the banana sort a variation of an insertion sort? I haven't spent much time looking at it. The standard MC-10, Apple, and Plus/4 ROMs usually copy a byte at a time. My update uses some 16 bit memory copies, but I don't know which code this will pass through to do that. If you have to use ^3, or ^5, it uses the same code as ^2 on every 8 bit. *2 does not. You'll never budge, so I won't waste any more time but to say the following... I've already patched the MC-10 and CoCo 3 to use a hardware multiply. Your last number for Atari using that optimization was 42.3. On the MC-10 with the new ROM, using *2 instead of ^2 drops the time from 66 seconds, to about 42 or 43 seconds (hand timed) That's about a 36% difference! Are you going to tell me the MC-10 is as fast as the Atari? With an HD6303, the hardware multiply is 3 clock cycles faster (30%), and many opcodes are only 1 clock cycle. That would put it ahead of the Atari even with just a 5% speedup. The CoCo 3 runs at double the clock speed, so even without the multiply or any other patch, using *2 comes in at 43.55, machine timed. Using *2 with the multiply patch should easily put it in the 27 second range if it has the same speedup. A CoCo 3 with an HD6309 is 20% faster in native mode on 6809 code, and I could implement some of the math functions using the additional 16 bit register, combined 32 bit register, and could use memory move instructions. That would put it in the sub 20 second range. According to Creative Computing, the IBM PC was timed at 24 seconds... even with it's internal *2 optimization in BASIC A note on the scan shows the Amiga at 22. The BBC Micro is 21, but who knows with what optimizations. Do you still think this is fair?

Do we really need a specific reason? My interest is a little bit of all of the above. There's the 'this is how the machines performed on different benchmarks' aspect, and how the performance changed over time. There's the what if angle... like what if some worthless manager actually made a smart decision to update the BASIC they included with the machine, possibly even before it's release. Seriously, a 4%-5% speedup on the CoCo, and MC-10 required almost no effort. The Atari? How do you slow down the one of the fastest personal computers on the market (at intro), to where it looks the slowest??? And then you NEVER do anything about it even though BASIC came on a freakin cart? Why couldn't they have It's also interesting to see the different solutions to a problem, while sticking to just BASIC. MS BASIC is pretty strait forward with string handling, and that was mostly tweaking the sort to work properly using for loops. Porting the MS BASIC to Apple, and the C64 required changing one command, and it took a couple minutes to look up the Plus/4 display disable POKE. The new gap calculation was sort of a "how can I do this with less code, and no divide?" challenge, thinking that would speed it up a tiny bit. The fact it seems to work that well was a total surprise, but it may not be as efficient with much smaller, or larger data sets. The Atari was a bit different. I remember seeing a couple comments about it's poor string handling, and was curious to see if/and how it could do it. How many different versions and tweaks were tried before coming to the "final" one? Imagine if Atari had actually funded a BASIC XL like project, and introduced it by 1981, and faster math to go with it before the XL series came out. Speaking of XL, did you ever run the last version of the code on BASIC XL and XE?

Did the algorithm change by putting constants in variables? No Did the algorithm change by switching from ^2 to *2? Yes Every other machine benchmarked in Creative computing used ^2. Does the PC benefit unfairly from recognizing that optimization? Maybe. but then that's part of BASIC itself, not a change to the benchmark. They could have used the math coprocessor for drastically better results, so if anything, PC BASIC is slower than it could be. Besides, isn't that why we are benchmarking modern optimized BASICs? So people can add things like that if they want? Because clearly, no optimization was used in the Atari code but lots was used in the MS BASIC code. MS BASIC wrenches. It doesn't convert constants to binary at tokenization time. Not even line numbers. They must be converted from ASCII to float every time. *edit* It converts the line #s at the start of the line, not line #s in GOTOs, GOSUBs, or ON GO... statements. This slows down GOTO & GOSUB Using FOR loops saves the address of the end of the FOR statement, making it easy to return to with the NEXT, so it's faster than GOTO. It puts variables in it's table in the order they are created, and searches from start to finish to find them. FLOATS are stored before strings. This is why MS BASIC programs almost always define variables at the top. Since you complained about how I optimized the MS BASIC code, I just changed line 0 to define variables in slightly better order for the sort, and the MC-10 time dropped another second. Not much, but if you don't define them it can add up to quite a difference. If I play with it, I might knock off another second. But you can see, defining/moving a variable or two can make a difference, even if it's small. It doesn't store a pointer to the current line. Any loop on the same line using GOTO has to start searching from the start of the program. It does check to see if the line number in the GOTO follows the current line number. It also has to search for the end of a line character by character to find the end of line marker after a failed IF condition. If you have a long line of code that depends on an IF at the start of the line, it's better to reverse the logic and GOTO a line a few lines down, and drop down for the true condition of the IF. But this also depends on how often the condition is TRUE, so you may have to benchmark it. So, to make it run faster, this: 50 IF A > 1 THEN do a lot of crap:GOTO 70 60 do something else 70 Becomes: 50 IF A<=1 THEN 70 60 do a lot of crap:GOTO80 70 do something else 80 Those are the biggies off the top of my head. NEXT without the loop variable is faster. Spaces are left in the code except on the Apple II, which removes them during tokenization. But you can't use certain variables on the Apple II because they may combine with keywords during tokenization. On other machines, the spaces just slow down the interpreter. The biggest problem with MS BASIC is inefficient implementation, which is what most of my optimizations target. Poll the entire keyboard before every token is executed, inefficient parsing, 8 instead of 16 bit code... If I convert constants during tokenization, create a faster way to look up lines, and a faster way to look up variables, everything should run faster. Math offers the biggest room for improvement. A faster LOG function is on the list.

All good points. I'm more interested in how fast the machines are. No, one rule for you, but no rules for me stuff. Machine, which BASIC, and year. Year would also mean when the BASIC came out in the case upgrades. Having to adapt the code to a different BASIC... there has to be some allowance for that. Unrolling loops, changing the functionality as with going from ^2 to *2 in Ahl's benchmark, changing sort, etc... it's not the same thing even if the result is the same. If some machines can sort more names, we can also include that number, and how fast it was. The Plus/4 would win this hands down, or a CoCo 3 with a program called Big BASIC. The fastest machine is going to differ by year, and newer machines are likely to be faster. That's just the way it is. It seems a bit disingenuous to say some machines that came out later can't be compared, when the Atari came out later than the Apple II, TRS-80 Model I, and Pet. The Atari had the benefit of later development, and it was designed to be better than those machines. The first three were designed to compete with with the KIM 1, Altair, etc... which weren't really even personal computers. The whole I get to use a machine that was introduced later than the Apple, but you can't bring up Apples introduced later thing is laughable. The Apple III from 1980 was about twice as fast as the Apple II. It should manage around the 107 number I posted for a 2MHz Apple with zero BASIC modifications. The CoCo came out in 1980, and it could run anything in the ROM bank at double speed. That speeds up BASIC by 30%, a 6309 can make it another 20% faster, it's ROM would benefit from the same modifications as the MC-10, and there are ways to make it even faster without an accelerator. So, is 1980 too late?

Interpreters became the thing because they required little RAM, fit in a small ROM, and didn't require disk storage.

Oh, the IIc Plus is too late but software is different... then the date doesn't matter. Accessible to the masses? You left off not the classes... I thought that was Commodore's line. Anyone that wants a IIgs can probably buy one if they look around. ebay prices are a bit absurd (starting around $150 shipped). but you can still find them locally for under $100. You can also buy new accelerator boards for the IIe. A bit overpriced at $150, but then people are buying them at that price: http://www.a2heaven.com/webshop/index.php?rt=product/product&product_id=147 I'm not seeing how that is out of reach for people.

I *think* there was a 15+ second difference for 891 in my tests.

What is the point of bringing a BASIC into the picture that came out over 20 years after the Apple IIc Plus? And the first Apple II accelerator board came out in 82... something I already mentioned. I haven't had time to look at the banana sort yet

If I remember right, one of the options runs the math on the host machine, not the 6502. Have you been turning that on? That would definitely be fast! LOL

But what about the time difference for 891?

The full run on an Apple II takes 215 seconds. At 2 MHz, it only takes 107 seconds, but every accelerator or fast Apple was clocked higher than that, and should finish it in under 100 seconds. Those came out long before the modern Atari BASICs. My IIc Plus will finish this in under a minute. So, invincible? Against 1 MHz (or less), and crippled BASICs like the Plus/4... maybe.

Yeah, I think the original calculation tries to drop the gap way too quickly at first. I haven't done more than a handful of tests, but this gap calculation has always finished faster. The new Math ROM + Altera certainly offers quite an improvement.

I think I said I switched to that a couple times, but... sorry if I wasn't clear. That sounds a little more like what I was expecting here. *edit* If the HD6303 offers even a 10% speedup, it will be pretty close to the Atari with the Antic on.

The Plus/4 turns in a time of 193.15 for the list of 561 names, full run, when turning off the screen for the sort.

I'm currently using emulation. I don't even have a cassette cable for my MC-10 at the moment. The #'s are consistent over multiple runs. No way I'm typing in all that data. For that matter, the only RAM expansion I have is the factory one so it might not hold that many names. The MCX RAM expansion would though. The Plus/4 is timing itself, so it should be pretty accurate since the interrupts are based on the emulator's internal timing. Not sure about the Apple emulator, but it's always going to be the slow MS BASIC machine here. I might have a serial cable to transfer the program with.

Ouch!

28? Maybe for the 891, but not 561. I only get 23 passes with this sort using the modified gap calculation... which was mostly supposed to eliminate the division which is slow. Not that I'd be able to measure the difference. It only makes two passes at 1, where 891 required 3 O = constant for One, Z = Constant for Zero

I think only MS BASIC

Just an FYI, I found something I forgot to optimize in the sort before. This uses constants which have to be converted from ASCII to FLOAT every time 4 IFG>1THENT=1 So I switched it to O which is defined as 1 at the top 4 IFG>OTHENT=O