chen@digital.sps.mot.com (Jinfu Chen) (09/19/90)
>A factor of three speed increase (for floating point code) is usually >what I get from going from a " cpu any" (the default) to a "cpu 3000" >(which turns on the use of inline floating point code and the 68020 >specific addressing modes). There is another compiler switch (cc 6.7 only) that can make floating point code run faster, "-def BUILTINS" (or "-D_BUITLINS" in /bin/cc). With combination of the "cpu 3000", performance can be sped up significantly.
rehrauer@apollo.HP.COM (Steve Rehrauer) (09/20/90)
In article <4ce36164.12c9a@digital.sps.mot.com> chen@digital.sps.mot.com (Jinfu Chen) writes: >>A factor of three speed increase (for floating point code) is usually >>what I get from going from a " cpu any" (the default) to a "cpu 3000" >>(which turns on the use of inline floating point code and the 68020 >>specific addressing modes). > >There is another compiler switch (cc 6.7 only) that can make floating point >code run faster, "-def BUILTINS" (or "-D_BUITLINS" in /bin/cc). With >combination of the "cpu 3000", performance can be sped up significantly. "_BUILTINS" causes some common math functions to be emitted as inline code, if the CPU model permits (3000 does): abs sin cos tan log exp atan atan2 sqrt Also note that "_BUILTINS" doesn't only control floating-point, it also enables inline coding of some common C string functions: strcpy strncpy strcat strncat strcmp strncmp strlen You can get significant performance improvements with "_BUILTINS" if you do a lot of string operations. You can get good improvements for strings when compiling for any CPU model (even "any" :). At 6.7, you always get the definitions for _builtin_routines sucked in by virtue of apollo_$std.h, which the compiler always included. (The definitions are surrounded by #ifdef _BUILTINS, so saying "-def _BUILTINS" or "-D_BUILTINS" on the command-line simply enables them. Enabling them tells the code-generator that if it believes it can do better than a library-call, to go ahead and do so.) However, I believe that the 6.8 (cr1.0) compiler, which will include a new ANSI preprocessor, won't by default understand what to do with "_BUILTINS". I believe that in order to have the old _builtins_routines behaviour happen, that you'll either need to compile with the new "-nansi" (no ANSI behaviour) switch, or to specifically include <strings.h> and/or <math.h> include-files. Perhaps John Vasta can correct and/or supplement what I've said about the ANSI changes. -- >>"Aaiiyeeee! Death from above!"<< | (Steve) rehrauer@apollo.hp.com "Spontaneous human combustion - what luck!"| Apollo Computer (Hewlett-Packard)
system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson)) (09/22/90)
None of this nonsense would be necessary if the following suggestion, which I made to Apollo 2 years ago, had been acted on: 1) if the user specifies a "cpu" option, use it. 2) check an environment variable, called FLOAT at our site, to see what the default floating point compilation option should be. 3) use "cpu any" for m68k nodes. Note the 1) and 3) is exactly what happens now, to the great detriment of anyone who has either a M6888[12] or fpa (or other old fpu addon), but doesn't know how to make the compiler use it properly. It is especially painful from UNIX environments, since most people don't invoke 'f77' directly, but rather use 'make', and the syntax to set the Aegis options is more involved from 'f77' than from 'ftn'. Having an environment variable solves all the problems, and it should be set by the boot script AUTOMATICALLY to the correct option - no intervention by the SysAdmin to set it is needed, since 'config' knows what your system has. At our site, FLOAT is set in the .cshrc/.profile file depending on the node name, and EVERY [Mm]akefile HAS TO BE MODIFIED. This is RIDICULOUS, but the only way to get maximum performance out of our DN2500, DN4500/fpa and DN10000 systems (we recompile all floating point code for each environment). Since this approach outlined above is already in use by a competitor, who introduced it to help users cope with ~5 different cpu/fpu combinations (about what HP/Apollo has got now), I suspect it will never happen on HP/Apollo systems, but it should. -- Mike Peterson, System Administrator, U/Toronto Department of Chemistry E-mail: system@alchemy.chem.utoronto.ca Tel: (416) 978-7094 Fax: (416) 978-8775
rees@pisa.ifs.umich.edu (Jim Rees) (09/22/90)
In article <1990Sep21.172129.13644@alchemy.chem.utoronto.ca>, system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson)) writes:
None of this nonsense would be necessary if the following suggestion,
which I made to Apollo 2 years ago, had been acted on:
...
Having an environment variable solves all the problems, and it should be
set by the boot script AUTOMATICALLY to the correct option - no
intervention by the SysAdmin to set it is needed, since 'config' knows
what your system has.
Much as I hate the current state of affairs, this is unrealistic. I like
the environment variable but having the default be to generate code that is
guaranteed to work only on the node it was compiled on would flood the net
(and customer service) with complaints.
I would set it up as suggested, but comment out the EV setting in the "boot
script" (/etc/rc*). Then the sys admin could enable this "feature" at his
own peril. Otherwise the default would be 'cpu any'.
By the way, this can all be done (if somewhat slowly) by replacing /bin/cc
with a shell script.