Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!sdd.hp.com!news.cs.indiana.edu!uceng!minerva!dmocsny
From: dmocsny@minerva.che.uc.edu (Daniel Mocsny)
Newsgroups: comp.arch
Subject: Re: standard extensions
Message-ID: <7469@uceng.UC.EDU>
Date: 17 Feb 91 21:40:05 GMT
References: <1087@kaos.MATH.UCLA.EDU> <14814@lanl.gov> <1991Feb15.192653.9846@rice.edu> <6049@mentor.cc.purdue.edu>
Sender: news@uceng.UC.EDU
Organization: University of Cincinnati, Cin'ti., OH
Lines: 74

In article <6049@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
>This assumes that the one who needs the operations, or the
>improved performance, has the resources and time to do this.
>Montgomery and Silverman are number theorists, I am a professor
>of Statistics and Mathematics.  We are expected to do other
>things.

This is a problem I have grappled with at virtually every stage
of my own work: I see all these interesting and compelling tools
the computer people create for their own work, or their own idea
of a market. Needless to say, if one has anything resembling a
specialized need, one finds oneself shunted off the mainstream
into a sort of computer orphanage.

What are scientists and mathematicians "expected to do"? Historically,
that answer has been: "Whatever it takes". Scientific researchers
have a venerable tradition of inventing all manner of experimental
and computational devices to support their work. In the "good old
days", when a scientist had a challenging problem to solve, often
the response was to design and build machines to assist.

The decline of this tradition speaks to the success of general-purpose 
computers. Today computers are so cheap and effective that scientists
find they usually can't afford to try to build anything better suited
to their problem. (This is almost always true for hardware, and it is
often true for software.) What's more, general-purpose computers are 
improving so rapidly that even machines designed specifically to solve 
specialized problems are in great danger of rapid obsolescence. If a 
research team decides to design a specialized computational device, 
they had better get cracking, because the general-purpose performance 
they are trying to beat is a rapidly moving target. A factor-of-ten 
improvement buys you about 3--5 years. If you sink 1--4 years into 
building the specialized box, you may have wasted your time.

If I may muse a bit---I see much hope in the recent trend toward 
object-oriented languages. These are inherently extensible, making
them nice substrates for specialized development. Each of the
scientific disciplines may well evolve its own standard set of
common objects, methods, operators, etc., much as they have always
evolved their own nomenclature, curricula, and so on. Assuming, of
course, that busy specialists will find time to detour into all the
intellectual overhead involved in mastering a second discipline (which
is what learning a language well enough to extend it represents).

Unfortunately, piling all this makeup on top of uncooperative hardware
may give us a performance hit. However, at some point the computer
industry will find ways to let users cooperate in the design of their
machines. Optimizing compilers are, in fact, a first step in this
direction. The optimizing compiler permits the computer to adapt itself
to the user's "paradigm". I.e., the user thinks in a language containing
many constructs and instructions that do not directly tell the computer
how best to solve the problem at hand. The correct response is not to
tell the user to think like the computer, but to teach the computer
to think like the user.

Eventually we must extend the notion of optimization to the hardware
as well as the software. Computers need some sort of hardware
flexibility permitting them to shift resources in response to user
demands. I.e., instead of collecting average statistics on instruction-
set usage, and then imposing a one-size-fits-all cast-in-stone 
"solution" on everyone, why can't the computer have flexibility in
deciding how it should execute instructions? Buying a computer should
be like hiring an employee: the longer that employee stays on your
payroll, the more productive (s)he becomes. Computers, however,
turn in pretty much the same benchmarks the first time you run your
problem as they will after the 1,000,000th run. By the time the
computer has served you for several years, it has had ample time
to compile detailed statistics on the instruction mix that *you*
want.


--
Dan Mocsny				
Internet: dmocsny@minerva.che.uc.edu