home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Info-Mac 3
/
Info_Mac_1994-01.iso
/
Periodical
/
TidBITs
/
TidBITS#186
< prev
next >
Wrap
Text File
|
1993-12-31
|
30KB
|
649 lines
27-Jul-93 8:07:37-GMT,30450;000000000001
Return-Path: <tidbits!ace@tidbits.com>
Received: from terminator.rs.itd.umich.edu by CAMIS.Stanford.EDU (4.1/inc-1.0)
id AA22668; Tue, 27 Jul 93 01:07:37 PDT
Received: from nwnexus.wa.com by terminator.rs.itd.umich.edu (5.67/2.2)
with SMTP id AA00334; Tue, 27 Jul 93 04:06:06 -0400
Received: by nwnexus.wa.com id AA16289
(5.65c/IDA-1.4.4 for macgifts@mac.archive.umich.edu); Tue, 27 Jul 1993 01:05:53 -0700
Received: by tidbits.com (uA-1.6v2); Mon, 26 Jul 93 22:14:26 PDT
From: ace@tidbits.com (Adam C. Engst)
To: TIDBITS@RICEVM1.RICE.EDU
Subject: TidBITS#186/26-Jul-93
Date: Mon, 26 Jul 93 22:14:26 PDT
Organization: TidBITS
Reply-To: ace@tidbits.com (Adam C. Engst)
Message-Id: <D2150083.7k1u0o@tidbits.com>
X-Mailer: uAccess - Macintosh Release: 1.6v2
TidBITS#186/26-Jul-93
=====================
This week brings several corrections and clarifications of
previous articles, RAM prices increasing, the pen-based
PowerBook project disappearing, and the postponement of the
online Congressional hearing. In the rumor department, Apple
releases another hardware update and Prodigy appears on the
Internet. Finally, Roy McDonald of Connectix anchors the
issue with a thoughtful paper on software acceleration.
This issue of TidBITS sponsored in part by:
* APS Technologies -- 800/443-4199 -- 71520.72@compuserve.com
Makers of hard drives, tape drives, memory, and accessories.
For APS price lists, email: aps-prices@tidbits.com
Copyright 1990-1993 Adam & Tonya Engst. Details at end of issue.
Automated info: <info@tidbits.com>. Comments: <ace@tidbits.com>
---------------------------------------------------------------
Topics:
MailBITS/26-Jul-93
RAM Prices Increase
Pen-Based PowerBook Crossed Out
Online Congressional Hearing Postponed
Software Acceleration
Reviews/26-Jul-93
[Archived as /info-mac/per/tb/tidbits-186.etx; 30K]
MailBITS/26-Jul-93
------------------
I need to issue a correction and an apology. There is no way Jesse
Helms could be involved with the House of Representatives' pilot
project because he is a Senator, not a Representative. That's the
correction. The apology is this: It was inappropriate to imply
that Senator Jesse Helms would not participate in an Internet
project. Whatever the Senator's politics, and whether or not I
agree with them, there is room on the Internet for all opinions.
And as long as I'm apologizing, just a quick note to clarify that
the blurb for TidBITS #185_ inappropriately implied that
Microseeds no longer supports Rival due to a problem with Rival.
We know of no problems with Rival and congratulate the authors on
their admirable efforts to support existing users and enhance
Rival. If only all companies were as diligent in their customer
service.
**The Macintosh LC 520** is sold in Canada, or so
<DELANEYG@wl.aecl.ca> writes to tell us. Unlike in the U.S., where
Apple currently sells the LC 520 only to the education market,
normal people can buy the LC 520 in Canada. The Canadian versions
of the LC 520 sport 8 MB of RAM, an 80 MB or 160 MB hard disk, and
an internal CD300i. All that, and apparently at a price lower than
a comparably equipped LC III.
**Bite the Purple Bullet** and buy yourself a bigger PowerBook
drive. Along with the cases that various hard drive vendors sell,
you can now buy a $99 NuBus card from ETC Peripherals that will
accept your 2.5" hard drive (or a 3.5" low-power drive if you buy
an optional Purple Bullet Expander). The Purple Bullet provides a
selectable SCSI address switch, an LED activity light, ETC Disk
Tools 4.0, and all the necessary cables. ETC -- 800/876-4ETC --
813/884-2863 -- 813/888-9535 (fax)
**In the unconfirmed news department**, I hear that Apple has
finished the Macintosh Hardware System Update 2.0, but that the
update is not yet generally available. It fixes a many bugs on
many different models of the Mac, many of which seem to be more
operating system bugs than hardware problems, but who's
complaining? We'll let you know more details once we have a copy
ourselves. Also, I just heard that Prodigy is beta-testing an
Internet gateway. We don't know if there's any cost to Prodigy
users, but they need new software, called Mail Manager, and can
sign up for Internet access at JUMP INTERNET. Prodigy users can
receive Internet mail via the address format
abcd12a@prodigy.com
where "abcd12a" is the recipient's user ID. It's about time
Prodigy appeared on the Internet, but don't expect a reliable
gateway right away since it's still in testing. Again, details as
they arise.
RAM Prices Increase
-------------------
Fireworks weren't the only thing blowing up on the Fourth of July
this year. In Japan the Sumitomo epoxy plant, which made most of
the epoxy used in constructing DRAM chips, blew up. Along with
parts of the factory, RAM prices immediately skyrocketed. The
explosion wasn't the only factor in recent price increases, since
supplies have been barely meeting demand in the PC industry, which
has squeezed the smaller Macintosh market.
Although the price of SIMMs was of course affected, a less obvious
effect may show up in the price of configured computers. It's
unclear if Apple will raise prices to compensate, or if Apple is
even all that affected, given that the company was well-insulated
from price shifts in the last price scare.
There's nothing to do about the problem except wait it out,
although I've heard the opinion that the price jumps happening at
the moment are temporary and that prices will drop again in a few
weeks or a month, though not to previous levels.
Pen-Based PowerBook Crossed Out
-------------------------------
Along with all the layoffs, Apple has cut back projects deemed
non-essential. Among them was the pen-based PowerBook, probably a
modified Duo.
In some ways it's a shame that such projects are dying, because
even if they never lead to real products, the research often
benefits Apple in other ways. However, I'm not surprised that
Apple shelved the pen research for the time being, at least until
they see how popular the MessagePad proves, given its pen
interface.
Several years ago handwriting research and pen interfaces were all
the rage, and one developer I spoke with said that to receive
venture capital you essentially had to include pen computing in
your business plan. However, with GO's PenPoint remaining a niche
operating system and with the demise of the much-touted Momenta
pen notebook, pen computing fell out of favor with even the
venture capitalists, and last I heard pen computing in your
business plan meant almost certain rejection.
In many ways, I think it all comes down to the manner in which you
wish to record and manipulate information. The concept of a
writing stick has been around for hundreds of years - first
because it was necessary to make an impression and later because
it could leave a trail of lead or ink behind it. But does that
make sense as an interface to a computer, where you can't make an
impression and where there is no permanence to a marked trail? I
don't wish to imply that the current interfaces to computers are
anything special, or that there aren't applications that lend
themselves to a pen interface. The pen's primary advantage is that
people know what to do with it, not that it's usable as a
universal interface for a computer.
Nonetheless, it's shame that Apple dropped the project, if only
because only through experimentation will Apple (or anyone)
determine the interface methods that work and those that don't.
It's becoming painfully clear that the Macintosh interface is due
for an overhaul despite its still-obvious lead over Windows. But
that's another editorial.
Information from:
PEN.IDEAS@applelink.apple.com
Online Congressional Hearing Postponed
--------------------------------------
Fresh off the heels of correcting my egregious mistake regarding
Senator Helms, it seems that the Online Congressional Hearing was
postponed until later in the year. The story behind the delay is
interesting.
The Internet Town Hall depends on donations from many
organizations, many of which are commercial entities. Given the
cost of computers, software, and network links, this isn't
surprising, and in fact, it's an example of how even competing
companies can cooperate for the community good, much as people
cooperate on the Internet.
Along with everything else, the Online Congressional Hearing was
going to transmit audio and video over the Internet, and to avoid
destroying the standard links, ARPA volunteered the use of their
high-speed experimental DARTNET, whose underlying facilities are
operated by Sprint. The Internet Town Hall folks asked if Sprint
would like to join, and in the process provide a high-speed link
to the hearing room. Sprint expressed some concerns about the
ethical considerations of donating the link to the government,
even for this use alone, so the subcommittee postponed the hearing
for several months.
The problem is that donations to the underlying infrastructure of
the congressional committee could be construed as expenses which
the government would have to reimburse. The idea is to avoid it
seeming as though the committee was beholden to a specific
interest group. I have a feeling that things are not so squeaky
clean in Washington as this may imply, but I approve of the
Internet Town Hall folks making sure that the Internet is kept
above any such impropriety. We hope this hearing will happen in a
few months and not end up sucked into a giant black hole of
government investigations.
You can still email comments to <congress@town.hall.org> to be
forwarded to the Subcommittee staff. You can also ask to be added
to a list that will be notified when the hearing is rescheduled.
Information from:
Carl Malamud -- carl@trystero.malamud.com
Software Acceleration
---------------------
by Roy K. McDonald, Connectix -- connectix@applelink.apple.com
Presented at the Sumeria Technologies & Issues Conference
Hardware gets faster every year. We've all come to expect it. And,
a huge amount of work is going on right now to ensure that next
year the same thing will happen.
Software gets more features. And unfortunately, all too often, the
presumption that fast hardware will take up the slack has meant
that inelegant software design needlessly eats up performance
advances. The irony is that software improvements are often far
more dramatic in their impact than hardware improvements. Hardware
is the tortoise, advancing relentlessly in tens of percents per
year; software is the hare - on occasion it leaps orders of
magnitude.
This article reviews what has been done in software acceleration
on the Mac, highlighting how much more could be done right now. I
aim to persuade you to think about Mac performance as a hybrid of
hardware and software acceleration and perhaps shift your
priorities a little in favor of pushing the envelope on code
rather than silicon.
Decade of Macintosh Hardware Advances
Let's start by seeing what can be done with hardware. How has
Macintosh hardware improved in performance over the past 10 years?
The original 128K Mac had an effective speed of roughly 1/2 MIP.
Today's Quadra 950 provides about 8 MIPs. Of course, the Quadra
950 is relatively expensive, so on a real $/MIP basis, the growth
is only eight-fold, equivalent to a yearly average improvement of
26 percent.
SCSI, NuBus, and AppleTalk speeds have changed less. SCSI may be
about twice as fast as it originally was. The new Cyclone NuBus
standard will give a four times performance boost. AppleTalk is
basically unchanged. And, although EtherTalk has led to a high-
speed network standard bandwidth that is roughly twenty times
better than what we had in 1984, actual throughput is roughly only
a factor of five better.
Typical RAM installation has grown from 128K to the current
average of 6 MB, a 50 times growth, or about 50 percent per year.
Access speeds of main storage have only improved about a factor of
two (although caching has mitigated this otherwise fatal
limitation).
Common hard drives seek an average of about five times faster and
have ten times the capacity than they did when drives first
shipped for the Mac Plus. The average transfer rate hasn't
improved by much more than a factor of two.
Overall, we might imagine a "Speedometer" increase of as much as a
factor of 20 over the past decade (with perhaps much more than
that for floating-point operations).
That's not to say that hardware can't make occasional big leaps,
too. RISC processors will provide a roughly three times
performance jump on one-third the die size, for an overall price-
performance step of ten times in what will probably be a two to
three year transition period. DSP can also accelerate certain
processes by an order of magnitude.
But, taken all together, typical jobs on a constant-priced Mac
have been able to be performed roughly 25 percent faster every
year, solely because of technical advances in hardware and
increased performance for the price. This means hardware
performance doubles roughly every three years, a rate likely to
continue for the foreseeable future.
Software Advances
While hardware advances are relentless and pervasive, software
improvements are often more specific in their impact. The
performance results, however, can be dramatic.
For a familiar example, consider the case of 'Find File' running
under System 6 versus System 7. For fun, we recently took a Mac
Plus running System 7 and raced it against a Mac IIci using System
6. The System 7 software was running on hardware five years older
than the System 6 version. Still, Find File went slightly faster
on the Plus, because Find File is roughly ten times faster in its
current form.
Unfortunately, it often takes a long time for well-known software
techniques to enter the commercial sector. For instance, it was
many years after the introduction of the first spreadsheet
(VisiCalc) before sparse and virtual array techniques were used.
If you wanted a 50 by 1,000 cell spreadsheet, you had to have
50,000 cells worth of RAM (say, 800K), even if most cells were
empty.
Sparse techniques would have allowed you to use only the amount of
memory taken by full cells, and virtual techniques to use disk
space as well, at the cost of slower calculation. But the
marketing war focussed on porting to new platforms and adding new
features, not on saving RAM. A few engineer-years could have saved
users tens of millions of dollars worth of RAM.
Many new technologies which seem to arrive because of hardware
advances are in fact largely enabled by software breakthroughs. We
did a rough analysis of the increased performance in a variety of
frontier technologies over the past five years and tried to assess
what fraction of speed improvements came from software as opposed
to hardware. We concluded that the software components for the
various technologies were:
* Voice recognition 80%
* Handwriting recognition 80%
* Dynamic 3D graphics 60%
* Compression 50%
In all cases, some hardware improvement was necessary in order to
make the technologies practical, (e.g. DSP) but better software,
particularly better software algorithms were the most important
enabling technology.
Components of Speed
Where does the speed come from? You can break the software design
process into three components: algorithms, implementation, and
compilation.
The largest range of performance difference comes from algorithm
selection. This may also be the area of poorest performance in the
industry today. Factors of 10 and 100 losses in performance are
common. Why is this?
Consider the basic Order theory of algorithms. Every computer
algorithm can be classed by Order. For example, an Order N
algorithm takes twice as long when you run it on twice as much
data. An Order N-squared algorithm takes four times as long. Lots
of computational problems are easy to code as N-squared
algorithms, but can be rewritten with difficulty to scale as
NlogN.
A famous example was the introduction of the Fast Fourier
Transform in the mid-60's, an NlogN algorithm that replaced the
previous N-squared algorithm.
A 1,024 point transform could thus be performed 100 times faster
by this new software method. So this advance was comparable in
speed to over 20 years of general-purpose hardware speed
improvement. And, it was accomplished through a software change
which, once developed, had no marginal cost over the prior
solution.
Unfortunately, plenty of commercial software ships every day
containing inefficient algorithms. Sorting records in a database
is a familiar example where NlogN algorithms can be used but
aren't always. When you scale your data from 10 to 100 records,
pixels, or whatever, it means the algorithm may take 100 times
longer to run, when it only needs to take twenty times longer.
It's easy to see why it happens. From the technical perspective,
debugging and benchmarking is often done on limited data sets that
don't reveal how badly the code will bog down in real world
applications. And the real world constantly increases data set
size, often at an exponential rate. Screen diagonal and pixel
resolution are two common parameters which quadruple data set size
when the parameters double.
Over in marketing, they know that software is not as rigorously
benchmarked for speed as hardware, because comparisons are often
more difficult to apply. So feature lists and time-to-market
become disproportionately important factors.
Good algorithms are not enough. Implementation counts as well. For
example, suppose you need code for looking up records in a
database. An efficient algorithm for this is Order N - twice as
many records means twice as long a search.
The usual way to accomplish this is to index the records in a
binary tree. Then you need to do log(2) N index lookups to get the
location. To find a single record in a 1,000 record data base
requires 10 lookups.
But, if each of these lookups involves a separate hard drive
access, the implementation is poor, even though the algorithm is
optimal. A better (and more typical) implementation would bring
some or all of the directory information into RAM at the time of
the first disk hit and cache it there for the next nine lookups.
Whether or not you use an optimized algorithm, if the
implementation is three times slower than necessary, the overall
performance suffers by the same ratio.
Good implementation is often a matter of deep familiarity with the
target hardware platform, a familiarity which is increasingly
difficult to achieve as technology life cycles shrink ever
shorter.
Also, the code we write is not the code the system runs. Between
the two stands a compiler.
Within the Mac world one can find a range of commercial C
compilers that vary by as much as 30 percent or more in ultimate
compiled code performance. To do better than that, one must write
in assembler, and here the variations are even greater. To put it
bluntly, it's not hard to do a lot better than MPW.
Looking beyond the Mac, we must face the fact that much more
effort has gone into optimizing 80x86 compilers than 680x0
products. As Windows has gained market share, more and more cross-
platform benchmarks are being published of essentially identical
object code compiled for Windows versus Mac and run on similarly
powered CPUs. The Windows products tend to run faster because the
compilers are, by and large, a little bit better. The most
striking example I've seen was a recent PC Magazine benchmark of
WordPerfect where the Windows advantage was substantial. This is
not because of a superior operating system, but because of the
availability of a better optimized compiler.
With the move from CISC to RISC architecture, and especially with
the move to superscalar pipelines, ever more burden is placed upon
the compiler. If sloppy compilers can be written for CISC
machines, time-to-market pressures could produce RISC compilers
which have even more of an effect.
The trend in the software industry today is in the opposite
direction of this theme. We are all sacrificing performance in
favor of time-to-market. Object Oriented Programming is the
epitome of this trade-off. Now, there's nothing wrong with OOP,
and it's great that we'll all soon be writing Newton applications
by dragging and dropping resources from the object pool.
But OOP is an obvious formula for inefficient code. Witness the
feel of the Finder in System 6 vs. System 7. In many applications
I'll guess that early products will be sketched in OOP and later,
more mature products or versions will be coded at lower levels.
Lately we've been thinking about starting a development house that
specializes in knocking off popular OOP-based products with C or
assembler-based me-too versions. We'd be second to market but we'd
win the benchmark wars every time.
System Software
System software is particularly important because of its pervasive
impact on performance. Well-written, native-mode system calls are
critical to good performance for a wide range of software
products, and can to some extent overcome limitations imposed by
inefficient compilers. If most of the computer's time is spent in
highly-optimized system calls, the inefficiencies of the calling
program can easily be overlooked.
On the downside, many advances in system software have undermined
performance. Windowing systems and multitasking both advance
overall productivity, but add overhead which slows routine
operation. The user gets new functionality, but it doesn't come
for free, and it affects all applications.
Moreover, advances often improve performance in ways that are
difficult to define quantitatively. Both virtual memory and RAM
disk technology can significantly enhance Mac productivity, but
it's hard to benchmark their contributions. For example, Connectix
end-user studies of Virtual and MAXIMA customers indicate that
either product can increase total work output per session by 5-20
percent, but results vary widely according to the type of work
performed and the system configuration.
An area of particular interest to Connectix is the use of
advanced, dynamic disk caching techniques, utilizing all of the
often "wasted" RAM on computers to avoid unnecessary disk access.
The benefits of this are two-fold:
First, disk accesses are usually a hundred to a thousand times
slower than RAM accesses, so tremendous speed improvements can be
achieved. Preliminary benchmarks on our Velocity caching product
show an overall work throughput increase of about 25 percent.
That's not bad for a low-cost software extension considering what
it costs to accomplish the same boost in hardware.
Second, caching has become increasingly important because of
portable computing. PowerBook users will enjoy considerable
battery life extension through the elimination of unneeded disk
spin-ups, which typically account for 10 percent of power use in a
battery-powered PowerBook session. Many PowerBook users also
complain that their PowerBooks seem sluggish compared to
comparable desktop systems - mainly, it appears, because of the
random annoying delays of drive spin up.
The key to a successful caching strategy involves maximizing the
available cache size and filling it with the data most likely to
be called for next by the CPU. Velocity incorporates unique
advances in both of these areas, which I look forward to
discussing in the future.
Input/Output
One of the most productive areas for software acceleration is in
the I/O domain, both internal to the system, and over a network.
After all, processing has three major steps - you get the
information, then you process it, then you spit out the results.
Two thirds I/O, one third processing.
Consider the following thought experiment: Watch a typical user
for an hour. She opens files, launches applications, enters
alphanumeric data, spell checks, calculates, sends email, closes
windows. Now, double the processor speed. Maybe she'll save 5
minutes out of the hour. Instead, suppose you double the I/O
speeds - SCSI, ADB, AppleTalk, and NuBus. How much does she save
then? Our testing indicates it's also about five minutes, and it's
certainly within a factor of two of that either way for most
sessions.
Moreover, a lot of the time saved will occur during periods when
the user would be especially annoyed at delays. Most people are
prepared to watch their clock spin a few seconds when calculating,
but have less patience when saving or opening a document. The
system just doesn't seem to be working as hard then.
Hardware I/O speeds are generally not improving quite as fast as
raw computation speeds. But a lot can be done in software here.
Many I/O bottlenecks give 10 to 1 or even 100 to 1 speed delays.
Even though they are only relevant to system operation a small
fraction, say 10 percent of the time, addressing these bottlenecks
can have a big impact. If you want a graphic example of this,
compare benchmark data of third-party 25 versus 33 MHz accelerator
boards. With a 33 percent higher clock speed, you often see
benchmarks only 10 or 20 percent better, because I/O is setting
the pace.
Networks
Enormous increases in network bandwidth are becoming available
because of the introduction of new technologies, particularly
optical transmission. The underlying structure of network data
transmission on the Mac is starting to be strained by these
capabilities.
I recently spoke with a vendor who successfully developed an
attractive low-cost, high-performance FDDI card with about ten
times the effective speed of today's Ethernet systems. It failed
as a product, however, because the throughput of the network
bottlenecked at both ends of the link by packet creation and
decoding time. This seems like an area ripe for new software
paradigms.
Video
There has been little improvement in the software that drives Mac
video over the years. This reflects the fact that the Mac started
with an excellent foundation, the original version of QuickDraw.
Subsequent versions have improved screen draw times by about a
factor of two, and big improvements in the future seem unlikely.
User/System
Finally, there is one bandwidth limitation which dominates all
others in importance, one link in the I/O chain responsible for 99
percent of the wasted clock cycles in every Macintosh. This, of
course, is the interface between the user and the system. Far
outweighing compiler, implementation, and even swamping the effect
of new algorithms is how efficiently a user can communicate her
wishes to the machine, and how in turn the machine can let the
user understand or appreciate the results and implications of
those actions. The ultimate bandwidth limitation, and the single
most important way to improve the total performance of the user-
system combination is the user interface metaphor.
The Mac established its special position in the industry by virtue
of its unique ability to address this one issue. Essentially, the
key technology that enabled it to do so was software. But more
remains to be done, and the pace of improvement in the last five
years has not been particularly impressive. For all the two
thousand engineer years that went into its development, is the Mac
a lot easier to use under System 7 than it was before? I don't
believe so, and I hope we're in for some paradigm shifting
breakthroughs here. Personal computing could use such a shot in
the arm today.
Conclusion
Time-to-market and feature list forces are driving software
developers to work in ever higher-level programming languages and
to pay less and less attention to the efficiency of the underlying
code. Because hardware speed has increased over the years, they
have been able to get away with this for some time.
But considering how much effort goes into pushing the speed
envelope of the hardware, it seems like users would be well served
if more emphasis were placed on software acceleration. In
everything from mainstream applications to system software, users
do care about speed and software will often be the best price-
performance technology to provide it.
Reviews/26-Jul-93
-----------------
* MacWEEK -- 19-Jul-93, Vol. 7, #29
Power To Go 2.0 -- pg. 43
Authorware Professional 2.0.1 -- pg. 43
Quicken 4.0 -- pg. 52
Working Model 1.0 -- pg. 53
* BYTE -- Aug-93
Illustrator 5.0 -- pg. 22
PowerBook 145B and 180c -- pg. 36
PowerPC 601 -- pg. 56
$$
Non-profit, non-commercial publications may reprint articles if
full credit is given. Others please contact us. We don't guarantee
accuracy of articles. Caveat lector. Publication, product, and
company names may be registered trademarks of their companies.
This text is wrapped as a setext. For more information send email
with the single word "setext" (no quotes) in the Subject: line to
<fileserver@tidbits.com>. A file will be returned shortly.
For an APS price list, send email to: <aps-prices@tidbits.com>
For information on TidBITS: how to subscribe to our mailing list,
where to find back issues, how to search issues on the Internet's
WAIS, and other useful stuff, send email to: <info@tidbits.com>
Otherwise, contact us at: ace@tidbits.com * CIS: 72511,306
AppleLink & BIX: TidBITS * AOL: Adam Engst * Delphi: Adam_Engst
TidBITS * 1106 North 31st Street * Renton, WA 98056 USA
----------------------------------------------------------------