General Category > LisaList2

Cameo/Aphid benchmarking

<< < (3/3)

stepleton:
Thanks for trying it out! I guess that settles it. Cameo/Aphid will just be slower than the X/ProFile for now.

In a read request, there is basically one likely place for an Apple parallel port hard drive to be slow, and that's when it's getting the data ready for the computer to read back. Once the hard drive says "ready", the computer sets the pace, and there's no reason to expect that the Lisa would treat any hard drive differently at that point.

So the place to look for speedups on read is at the point where the drive marshals data to be read into the computer. In Cameo/Aphid there's definitely some room for improvement in the higher-level side of things. (Cameo/Aphid's programming is split into two parts: fast lower-level I/O that runs on these dedicated TI coprocessors that the PocketBeagle has, then a slower high-level Python program that runs on the ARM.)

While Cameo/Aphid is running, the entire drive image is living in a memory mapped file, so it's starting off in a place where it can be accessed very rapidly. It's simple to access a block --- you just pull the right run of bytes out of an array.

But then it has to copy the data over to the PocketBeagle's speedy I/O coprocessors --- and ah yes, this is probably a big reason for why reads are slower. It can't just do a copy --- it also has to compute and interleave the parity bytes* for all of the data bytes on the fly. This line would probably be WAY faster in any common compiled language. Once it does that, it has to do that copy, but it does it in three chunks (not two) because of that 512-byte limited internal I/O that I mentioned: we have 2*532 bytes to copy given the parity bytes.

In a way I'm relieved, since there's probably a lot of low-hanging fruit to get more speed. I'm reluctant to move away from Python since that's what makes the "magic block" plugin facility so easy to program. (This is the system that powers the hard drive image selector.)

But I probably won't try to do anything unless I hear that running twice as slowly as an X/ProFile is a problem :-) I'm guessing (hoping!) that Cameo/Aphid will still smoke a ProFile or a Widget, but the main setting where I could anticipate an issue with the speed as-is is if you're trying to watch a video.

Thanks for doing this investigation! I'm still annoyed that the termination resistors aren't a general solution. More development is required to see if the TXS0108 chip option can be reliable at the end of the internal cable. I'll update the Cameo/Aphid GitHub page soon to say that it's not a sure bet.


* ETA: Parity bytes? Well, we only use one bit of each byte, but we still use a whole byte for simplicity.

Navigation

[0] Message Index

[*] Previous page