NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/lang/misc/3837

Text File | 1992-11-22 | 6.1 KB | 136 lines

Newsgroups: comp.lang.misc
Path: sparky!uunet!munnari.oz.au!cs.mu.OZ.AU!munta.cs.mu.OZ.AU!fjh
From: [e-mail] (Fergus James HENDERSON)
Subject: Re: Hardware Support for Numeric Algorithms
Message-ID: <[e-mail]>
Sender: [e-mail]
Organization: Computer Science, University of Melbourne, Australia
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 23 Nov 1992 07:38:40 GMT
Lines: 124

[e-mail] (Herman Rubin) writes:

>In article <[e-mail]> [e-mail] (Wayne Throop) writes:
>
>>Except that when such capabilities are pointed out, he sneers at
>>them, and then asks for something else.  For example, gcc can generate
>>inline procedures with assembly instructions interspersed.  For pointing
>>this out, people get sneered at, and told that the notation isn't
>>simple enough.
>
>Working in a university environment does produce some problems, which
>those with reasonable manpower support do not seem to realize.  I can
>get gcc on some machines, but we do not yet have it on the one I am
>supposed to use for production.

Do you have access to ftp and access to roughly 20M of disk space (maybe in
/tmp)? If so, ftp the source and compile it yourself!
It should take about an hour to install, not counting compilation time
(you can compile it in the background while you read news :-).
Considering the time that you and other people have spent posting on this
topic, it would seem like a worthwhile investment.

>Also, it cannot be used for program
>design for more than one machine, which is something I am supposed to
>be involved in.

Why on earth not?

>This is a major reason for asking for a good macro
>translator, to isolate the dependent problems from the independent
>ones and still be able to communicate.  I cannot reasonably communicate
>SPARCstation program to someone using an RS/6000 or a CRAY Y-MP, but I
>can communicate the algorithm to a mathematician using any one of those
>machines in such a way that a language hacker could come up with good
>code in consultation.

In what ways are inline functions and gcc's inline asm constructs insufficient?

In a sense the compiler is just a good macro preprocessor, except that it
does type-checking, register allocation, code generation and optimization for
you. If it's code generation is not good enough or doesn't give you access
to all the machine instructions, you can use inline asm. If the register
allocation is suboptimal, you can specify which variables go in registers
and with gcc, even which variables go in which registers.

In theory at least, it should be possible to provide high-level code which
serves to communicate your algorithm, but implement that code using
inline functions and inline asm, etc. You haven't said anything which
might convince me that this is not a practical and reasonable approach.

>I am not just interested in producing good code for one machine, but
>good code in general, and I believe that this can be done without
>requiring every mathematician or physicist wanting good procedures
>for non-uniform random numbers to learn Lisp.

So do I, but obviously they will have to learn *something*.
I think that C with inline assembly is probably going to be as good
as anything else.

>>: So if C doesn't know how to do a fp divide with integer quotient and a
>>: remainder in one instruction, or how to do a "add in parallel, but
>>: only on those processors in this mask" (a CM),
>>: then no amount of higher-level rewriting will help.
>
>>Yes, this is the most central problem, which Jim Giles mentioned also.
>>Some method is needed which will specify the generated code, and yet
>>will fit in with the optimizations and register allocations and so on
>>which are already in place.  Jim says this "isn't too difficult", but
>>I think it is the single most difficult part.  I've seen several
>>solutions, each with some advantages over the others.
>
>THIS is one aspect of the problem; the attempt to get a detailed complete
>package, instead of putting partial solutions together;

As I have said before, I think that gcc should do the trick.
Inline asm is well integrated into gcc, it's not just a partial
solution.

>the attempt to
>take the programmer out of an interactive optimization procedure with the
>compiler

Whose attempt?
If you want an interactive optimization procedure, it's already there.

1. Compile with -S
2. Examine the assembly output file
3. If looks OK, go to step 6.
4. Modify compiler flags, introduce new compiler hints, and/or introduce
   inline asm code.
5. Go to step 1.
6. Profile the code again (you already did that before examining the assembly
   output, right?) to make sure that it is satisfactory. If not, go back to
   step 1.

Of course, next thing someone will be complaining that we need a GUI interface
to do this properly...

>the failure to realize that the present so-called optimizations
>and register allocations are often bad; etc.

>>But ultimately, when you are going after that last 1% or .1% of speed,
>>you will simply have to spell out the istream, operation by operation.
>>No amounts of hints to the optimizer will ever be enough, because
>>ultimately the optimizer can only deal with hints it is prepared to
>>accept, and if a programmer comes up with something unforseen by the
>>optimizer, there's no simple way to give a hint about it.
>
>So put in simple ways to give hints, instead of saying that no hints
>can be given.  The difference is not the last 1% of speed, but often
>50% of the running time or more.

I fully agree that it is important to be able to provide hints to the compiler.
Hell, I just finished my honours thesis on almost exactly that topic!
(although it was for logic programming languages, not for C).

The tricky question is exactly what sort of hints are required.
Do you have any particular hints in mind?

--
Fergus Henderson             [e-mail]
This .signature virus is a self-referential statement that is true - but
you will only be able to consistently believe it if you copy it to your own
.signature file!