NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/arch/9347

Internet Message Format | 1992-09-10 | 6.7 KB

Xref: sparky comp.arch:9347 sci.math:11238 comp.lang.misc:3012 comp.lang.fortran:3508 comp.edu:1618
Newsgroups: comp.arch,sci.math,comp.lang.misc,comp.lang.fortran,comp.edu
Path: sparky!uunet!mcsun!dxcern!dscomsa.desy.de!zeus02.desy.de!hallam
From: [e-mail] (Phill Hallam-Baker)
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Message-ID: <[e-mail]>
Sender: [e-mail] (USENET News System)
Nntp-Posting-Host: zws006.desy.de
Reply-To: [e-mail]
Organization: Deutsches Elektronen Synchrotron, Experiment ZEUS bei HERA
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 10 Sep 1992 23:42:39 GMT
Lines: 136

In article <[e-mail]>, [e-mail] (Herman
Rubin) writes:

|>In article <[e-mail]> [e-mail]
|>writes:

|>>This is just the generic language war taken to root. Of course no language
|>can
|>>provide more capabilities than machine code. However this is irrelevant
|>since
|>>working at such a low level of abstraction is too error prone to be feasible
|>for
|>>anything like a large project.
|>
|>None of the features I have mentioned are at "such a low level of
|>abstraction."
|>These are naturally occurring operations and conditions.  There are many more
|>of them.  If the language does not permit these things, one has to work
|>around
|>them, and these workarounds are likely to be less portable than the
|>constructs.
|>
|>The constructs of the language do need translation into machine code, and of
|>course this is non-portable.  But it should be possible to use these
|>constructs
|>without necessarily translating them clumsily into the machinery which the
|>language designers decided was "adequate."  A major reason for the success
|>of English is that there is no attempt to keep the language "pure."

Yeah, I tend to spend most of my time using an assembly language that can be
ported to any machine, it has quite a few HLL features too you know, its called
C.

|>>The machine instruction set is of very little relevance since it is very
|>rarely
|>>the case that the target machine is known. I can predict the machines we will
|>be
|>>using for the next 18 months/2 years, no more. We will certainly have at
|>least 3
|>>major manufacturers involved. People who piddle about optimising their code
|>to a
|>>particular machine end up stuck with it. This is OK for embedded controllers
|>>which we rarely change but not for general purpose stuff.
|>
|>Again, there can be improvement by using machine-independent constructs,
|>implemented in a machine-dependent manner.

Generally if we are that desperate for speed we use a DSP, forget machine code,
lets go for the microcode level.


|>>We run massively parrallel machines and have a massive data rate to cope
|>with.
|>>Thats why we *have* to use high level languages, the complexity of the
|>problem
|>>is too great to allow use of machine code.
|>
|>Wrong again!  Massively parallel machines require, for efficiency, the
|>elimination of branches as much as possible.

Bollocks (to put it politiely).

Massively parallel machines are very rarely compute bound, the big problem is
being communications bound.

|>  This calls for really CISC
|>architecture, and quite a few tricks not envisioned by the HLL designers.

Nope, we run RISC architecture, 1000 processors, 2000 DSPs. Since the HLL
designers also designed our chip I guess they anticipated themselves.

|>A switch operator is likely to end up taking every branch, so every
|>processor spends the time for every branch.  It is more important that
|>massively parallel machines find a way to reduce this than to avoid
|>machine instructions, especially if the machine instructions can eliminate
|>branches, as is often the case.

Only if you are hung up on vector machines. I never saw anyone get one of those
things really cranked up well except when they had a problem that fitted nicely
into rectangular boxes. Ours does not fit into such boxes and branches like
crazy. In any case we require substantialy more than any vector machine ever
built can deliver. If you consider Amdahls law for a moment you will recall that
for n processors you must parallelize at least an (n-1)/n th of the code. This
is why it is worth constructing a control system per processing unit.

I will agree that on a SIMD machine you will have problems, probably requiring
you to get into deep machine code. For MIMD you can get good efficiency from
compilers and translators, well at any rate I can. This is one reason why I
think that SIMD is pretty much finished and that the future is more in the MIMD
field. Connection machine LISP was interesting though...


>>|>This would occasionally be useful. I sometimes look at the output of
>>|>the compiler to see if it is generating reasonable code, and to find
>>|>out if there's any point in my doing certain optimizations at the
>>|>source level (e.g. loop unrolling). This is reasonable for me to do
>>|>because I have years of experience at this sort of thing. It probably
>>|>isn't reasonable for you to do it.

|>>If we needed that type of optimisation we would either buy a compiler which
|>did
|>>it or write our own.
|>
|>Not all of us have this option.  Those of us who are in American universities
|>rarely have either choice.  Also, I doubt if one could buy such a compiler at
|>this time.

There are several approaches to loop unrolling, one is to take such great tools
as AWK or PERL and use them to unroll the loop. Alternatively write a parser for
C with yacc and splice in a back end that writes out C with loops unwound. The
meta language Goedel can be used to produce the same effect although it's not
yet avaliable outside ZEUS.

It is a sad fact but most people when they "optimise" code work by applying a
set of rules. Generalising these into a compiler is not that difficult to do.


|>>We shiould stop calling it Computer Science and call it engineering.
|>
|>>Machine code is important, CS graduates should know how to build compilers
|>and
|>>processors.

I'll agree to that! But the point of learning machine code is that without
knowing what it is you can't form a meaningful idea of how the machines work and
how to optimize code for them. Having to understand machine code is not however
the same as having to use it to solve every problem.

One thing computer scientists should know is the sort of approach that is most
likely to solve the problem (the best will also be able to recognise what the
problem is, these are called politicians). This means building tools,
assemblers, compilers translators etc.

--

Phill Hallam-Baker