elwell@osu-eddie.UUCP (02/09/87)
Sometimes you don't know what you've got until you try to improve on it... I thought I'd share the following somewhat annoying experience with any other "speed freaks" out there in netland: I thought it would be nice to have a terminal emulator that could keep up at 38.4K baud without handshaking. So, I sat down with my 68000 databook and my trusty HP-41CX (to count cycles with, of course), and wrote a carefully optimized piece of assembly code to update a 26x80 screen in Monaco 9. I preshifted all of the character images, avoided multiplies, moved invariants out of loops, kept everything in registers, ... you get the idea. And, not suprisingly, it's fast. It can update a full 26x80 screen in 13 clock ticks (that translates to about 86Kbaud), and it only takes 45K extra for the preshifted character images (aw, who uses 128K macs anymore? :-)). So far so good. The disappointment came when I benchmarked it against the standard QuickDraw text routines (you know, the one that go through the font manager). They can update a full 26x80 screen in 19 ticks. This means that all my careful optimization only gained my about 15-20%, which is hardly worth it for the extra memory eaten up. When I did the shifting on the fly, it took 17 ticks. There are two morals of this story: 1. The sluggish performance of most terminal emulators is NOT due to QuickDraw, but to bottlenecks elsewhere, and 2. Never underestimate the power of the ROM. Sigh. -- ==================== Total Nuclear Annihilation: Clayton Elwell The Ultimate Error Message. Elwell@Ohio-State.ARPA ...!cbosgd!osu-eddie!elwell ====================
radford@calgary.UUCP (02/11/87)
In article <3076@osu-eddie.UUCP>, elwell@osu-eddie.UUCP (Clayton M. Elwell) writes: > Sometimes you don't know what you've got until you try to improve on it... > I thought it would be nice to have a terminal emulator that could keep up at > 38.4K baud without handshaking. So, I sat down with my 68000 databook... > ... all my > careful optimization only gained my about 15-20%, which is hardly worth it > for the extra memory eaten up. > 2. Never underestimate the power of the ROM. I'm not sure, but as I understand it, the Mac ROMs have significantly faster access times than the RAM, due to the RAM having to also handle screen refresh. This means that whenever you re-write ROM code for speed, you start with a significant penalty. This could explain a lot about your experiences. Radford Neal