sauer@auschs.UUCP (Charlie Sauer) (11/21/88)
I had hoped to just sit back and watch this discussion, but...
- there seems to be little distinction between the original machine
and the upgrades last year and this year
- there are some key points which have been insufficiently noticed in the
discussion, e.g., the role of optimizing compilers
- there have been some significant inaccuracies, e.g., with respect to
the implementation and impact of the VRM. (Contrary to one assertion,
the VRM is not half assembly code, but mostly PL.8 and C. Though the
VMI has negative impact in some applications, in many cases that is more
than compensated for by the benefits of the paging code in the VRM and the
real time capabilities in the VRM.)
So, I'll try to provide some perspective.
The main reason, in my opinion, that the original machine seemed/was slow
when it appeared in Spring of '86 is that the design decisions were made,
for the most part, with the plan that the machine ship in Winter of '84.
If we had been able to hold that plan, then it would have seemed much faster.
The main limitations in performance in the machine when released were
- the compilers, both for AIX and 4.2/RT, had very little optimization
capability. Thus they violated a fundamental concept of RISC, that
of exploiting the processor with highly optimizing compilers. In
AIX 1.1, we began providing global optimizing C and Fortran compilers
based on pcc/f77 but incorporating HCR's Portable Code Optimizer. In
87, a C compiler based on the PL.8 compiler (the "Advanced C Compiler")
became available as an AIX option. Correspondingly, the Metaware High C
compiler became available with 4.2/RT and 4.3/RT. These compilers
provided roughly 2 to 1 improvements in performance in many applications.
- there was no built in floating point hardware and the optional floating
point accelerator was not very fast
- the disk controller used a ST-506 interface and had no DMA capability
Though the I/O bus was only 16 bits, it had a number of implementation
enhancements over the AT bus, e.g., 32 bit burst/buffering extensions, and that
bus is not used the main memory bus, so I don't think that bus is a major
bottleneck in the machine. It is able to sustain more than 2 megabytes/sec in
DMA transfers, and that is adequate for most applications on a machine of that
processor speed.
The original processor was a 6 MHz NMOS implementation. It had several
instructions which were multiple cycle but should have been one cycle,
and was not able to pipeline loads and stores with virtual memory enabled.
On our standard internal CPU kernel, it comes in at 2.1 MIPS.
Last year we started shipping a new processor implementation which reduces
the above cited multiple cycle instructions to single cycle instructions,
is able to pipeline loads and stores with virtual memory enabled, and
has a number of other minor improvements. The 10 MHz CMOS implementation
of that chip comes in at 4.5 MIPS on the above cited kernel. Primarily
due to memory shortages, we were unable to provide adequate quantities of
machines with that processor until early this year. In July we started
shipping machines with a 12.5 MHz version of the new implementation.
Though these machines are not as fast as some high end workstations,
we think they are very competitive in price/performance, as do others.
See David Wilson's dollar/Khornerstone ratings in the May Unix Review,
for example.
Besides reimplementing the processor and providing optimizing compilers,
we provided a 20MHz 68881 standard with the 10 MHz CMOS processor and
provided an optional floating point accelerator using the ADSP 3210 and 3221.
With the 12.5 MHz machines, the standard floating point unit is based
on those parts. We also started providing DMA controllers for both
ESDI and SCSI disks, with caching on the controller cards.
For those that care, RT models 10, 15, 20 and 25 have the 6 MHz NMOS processor.
The 115 and 125 have the 10 MHz CMOS processor, and the 130 and 135 have
the 12.5 MHz CMOS processor.
Those are the machines that we have shipped. I think it is well known that
we are working on follow on machines which support the Micro-Channel.
Other than that, I don't think much is publicly known about those machines,
so I won't say anything more about them now.
--
Charlie Sauer IBM AES/ESD, D75/802 uucp: cs.utexas.edu!ibmaus!sauer
11400 Burnet Road 822: @CS.UTEXAS.EDU:sauer@ibmaus.uucp
Austin, Texas 78758 aesnet: sauer@auschs
(512) 823-3692 vnet: SAUER at AUSVM6sauer@auschs.UUCP (Charlie Sauer) (11/30/88)
Since my previous posting, I've received several mail requests to post
benchmark results. Here's what I have so far from the group responsible
for running various benchmarks:
RT PERFORMANCE
___________________________________________________________________
| | | | | |*DHRY- | WHETSTONES| LINPACK |
| MODEL | | | | | STONES| KWHETS | KFLOPS |
| | | |FLOAT| |_________________________________
| |PROC |MHZ |POINT|NOTE| | SP | DP | SP | DP |
___________________________________________________________________
|RT 025 |ROMP | 5.9| FPA | | 4000 | 985 | 730 | 196 | 118 |
| 125 |APC |10.0| FPA2| 1 | 8300 |1893 |1733 | 400 | 360 |
| 125 |APC |10.0| FPA2| 2 | 8300 |1893 |1733 |1040 | 700 |
| 135 |APC |12.4| * | 1 | 10400 |2298 |2087 | 490 | 410 |
| 135 |APC |12.4| * | 2 | 10400 |2298 |2087 |1210 | 810 |
___________________________________________________________________
* DHRYSTONE = V1.1 W/ ADVANCED C COMPILER
1. LINPACK PERFORMANCE = UNROLLED BLAS
2. LINPACK PERFORMANCE = CODED BLAS
--
Charlie Sauer IBM AES/ESD, D75/802 uucp: cs.utexas.edu!ibmaus!sauer
11400 Burnet Road 822: @CS.UTEXAS.EDU:sauer@ibmaus.uucp
Austin, Texas 78758 aesnet: sauer@auschs
(512) 823-3692 vnet: SAUER at AUSVM6butcher@g.gp.cs.cmu.edu (Lawrence Butcher) (12/01/88)
Mr. Sauer's benchmark people should be aware that the current version of the Dhrystone benchmark is version 2.0. Version 1.1 numbers are not timely. We have a bunch of RT's. We use the Metaware High C compiler version 1.4R, fall back to pcc when mc generates incorrect code, and run MACH. The Dhrystone numbers Mr. Sauer quotes are so far from the ones that I measure here that I wonder if we are measuring different things. If any reader can get their RT to run the benchmark significantly faster than I can, please send me mail. We would love to know what to do to get a C compiler that doubles the speed of our programs. My measured Dhrystone numbers (Dhry 2.0) are (roughly): 2191 for the (RT, ROMP, 6150, Model 025, at 6 MHz) using mc 3176 for the 6152 using mc 3551 for the (APC, 6151, 125, at 10 MHz) using pcc 4474 for the (APC, 6151, 125 at 10 MHz) using mc The following are my personal feelings only. The 025, running the software available to me, is about as fast as a SUN 3/50 while running the Dhrystone program. However my experience is that an 025 machine with 4 megs of RAM, a disk, and MACH, is totally useless. It cannot run X10, an xterm, and a single outgoing telnet at the same time. Yes, I am saying that it is not as useful as a terminal. A diskless Sun 3/50 running SUN OS 3.5, suntools, emacs, and pcc is comfortable. The 125 is about as fast as a SUN 3/60, again running the software we have here. High end 80386 and middle-end 68030 systems should be about twice as fast as the 3/60. I also have access to a MIPS M500 running at 8 MHz. It Dhrystones at 12000+. This number may be hard for others to verify, because I don't think that MIPS makes 8 MHz chips any more. The Performance Semi version of the R3000 is available at 16, 20, and 25 MHz. This chip is commercially available and there is a C compiler available for it which generates correct code. Of course we shouldn't use the the existence of a fast MIPS processor to try to predict the speed of future IBM machines. Just the speed of MIPS machines. I am disappointed that there is no version of GCC for the RT. IBM could allocate one person to do a port and give away the results, but it seems that they would rather have a company sell a compiler without source. The APA8 display was a joke, and I am disappointed that IBM believes they fixed things with the APA16 display. Although both look great on a desk when they are shut off, both are too small to use for editing. I am disappointed with the IBM 2-button mouse. It takes tremendous force to push the buttons. We had an informal contest and only one person here could hold both buttons down while lifting the mouse off the table. (For people who have not had the pleasure of using the IBM mouse, you hold both buttons down at once to emulate holding the middle button down on a real mouse). I absolutely cannot believe that the keyboard clicks when you hit the shift or control key. I wish that the caps lock key and the control key were the same size so we could switch the key caps. Thank you someone for that layout. Everyone here rebinds CTRL to the right place. And the ESC key?? I am disappointed that the RT expansion bus is an AT bus. The AT form factor limits the size of peripheral cards, and limits the power they have available. Ever heard of an SMD controller for the AT?? 16 line serial line card?? These problems will be worse with smaller MCA cards. We will throw away the RT boxes when they are obsolete. We will NOT throw away the SUN 3/160 boxes when the 3/160 is no longer interesting. Many of the things that I dislike about the RT could be fixed in the future. Today we give APC's to people who cannot afford SUNs. We give old RT's to people to punish them :-) Lawrence Butcher @g.gp.cs.cmu.edu --
jk3k+@andrew.cmu.edu (Joe Keane) (12/01/88)
> The APA8 display was a joke, and I am disappointed that IBM believes they > fixed things with the APA16 display. Although both look great on a desk when > they are shut off, both are too small to use for editing. The APA16 card looks quite good with a Moniterm or AED monitor (even if it doesn't do clipping in microcode). --Joe
pgc+@andrew.cmu.edu (Paul G. Crumley) (12/02/88)
Hello, After reading so many interesting statements about the RT/PC family of processors I feel I should add my few cents worth too! I have been a user of RT/PC family processors from the beginning of the product. We had some RT/PC prototypes and have had one of everything here at the ITC since. I have used both the 4.2 and 4.3 derived UNIX(tm) and AIX. I also have experience with SUN and uVax equipment. A couple of observations from previous complaints: 1) keyboard click: This is controlled by the MACH device drivers. If you don't like the way the click works tell the MACH people. 2) bad code generation under HC: I have used a number of versions of HC. Even at this time, after many releases, HC still does a miserable job of generating code. I have watched the HC compiler (with the -O switch set!) - move arguments passed in registers to other other registers for no reason. - store locals on the stack even when plenty of registers are available. - fail to remove parts of the prolog and epilog not needed when a routine never calls a function. - recalulate values in loops. - save more registers than needed upon entering a routine. - you get the idea..... None of these mistakes even takes into account the need to have a compiler for a delayed fetch/store machine that understands the importance of ording operations to keep the memory subsytem from causing waits. In general, HC seems primitive compared to the compilers available under AIX. My experience has been that the AIX compilers do a substantiallly better job of code generation. These compilers understand optimizations like careful register allocation, eliminated parts of the prolog/epilog that are not needed for a particular routine, ordering fetches and stores, inlining certain functions, etc. I don't doubt that much of the performance of RT/PCs running AOS can be gobbled up by HC's code generation. I have found that I can routinely do better than HC in optimizing the generated code. This is not true for the PL/.8 based compilers and the AIX compiler. I'm sure IBM realizes how important good compiler technology is to RISC processors and will continue to provide high-perforance compilers under the AIX operating system. 3) lack of useful support and service people from IBM: Perhaps our IBM representatives are superior to most IBM employees. I have gotten reliably good results from the sales and service people. 4) "state of the art"ness of the RT/PC: In general, I have found the RT/PC to be a very good machine from all aspects including cost/performance, reliability, repairability, keyboard layout, display (the 6155 is too small but the Moniterm(tm) is fine), availability of many I/O functions because of the use of an AT compatible bus, power, noise, ... It could always be better but as a person that has to help support RT/PCs at the hardware level I have found them very easy to deal with. 5) AIX: Having used some of the early versions of AIX on old RT/PCs I must agree that the original system was a real dog. (wuff, wuff) Newer versions of AIX on APC hardware are quite respectable. The AIX operating system also has a number of facilities and features not available in the AOS software. I have been able to port fairly complex software from AOS to AIX and back by only changing the Make files and a couple #ifdefs. (complex is software that uses the IP network, accesses hardware directly, uses X, etc.) Though some may consider the installation procedures for AIX to be a real pain, I find the ability to install and reconfigure device drivers on a running system, hardware error logging, support for vendor hardware, etc. in AIX to be very helpful in installing and maintaining a system. The VRM is a source of much debate. I have not found it to get in the way very often but know it can hurt system performance in some situations. I personally believe that many of the performance problems experienced by users of the AOS system are caused by inadequate compilers (though HC 2.0 is due any day now...). All things considered, I have found the RT/PC to be a very well designed hardware base. The AOS system is a very nice version of BSD flavor UNIX and AIX is a more robust system that is getting more compabible with the BSD world with each new release. Best Regards, Paul G. Crumley ITC/CMU
karish@denali.stanford.edu (Chuck Karish) (12/02/88)
>The 025, running the software available to me, is about as fast as a SUN 3/50 >while running the Dhrystone program. However my experience is that an 025 >machine with 4 megs of RAM, a disk, and MACH, is totally useless. It cannot >run X10, an xterm, and a single outgoing telnet. I don't know about MACH, but this mix of jobs runs fine on an 025 running AIX. X response is a bit sluggish, but not unbearably so. >I absolutely cannot believe that the keyboard clicks when you hit the shift >or control key. I wish that the caps lock key and the control key were the >same size so we could switch the key caps. Thank you someone for that >layout. Everyone here rebinds CTRL to the right place. And the ESC key?? The shift and control keys click under ACIS (4.3), but not under AIX. I don't think they clicked under earlier versions of the BSD system. Something is probably wrong with the ACIS tty driver. Chuck Karish ARPA: karish@denali.stanford.edu UUCP: {decvax,hplabs!hpda}!mindcrf!karish USPS: 1825 California St. #5 Mountain View, CA 94041
njs@scifi.UUCP (Nicholas J. Simicich) (12/03/88)
In article <3736@pt.cs.cmu.edu> butcher@g.gp.cs.cmu.edu (Lawrence Butcher) writes: >Mr. Sauer's benchmark people should be aware that the current version of the >Dhrystone benchmark is version 2.0. Version 1.1 numbers are not timely. > >We have a bunch of RT's. We use the Metaware High C compiler version 1.4R, >fall back to pcc when mc generates incorrect code, and run MACH. The >Dhrystone numbers Mr. Sauer quotes are so far from the ones that I measure >here that I wonder if we are measuring different things. If any reader can >get their RT to run the benchmark significantly faster than I can, please >send me mail. We would love to know what to do to get a C compiler that >doubles the speed of our programs. > (.....) > >The 025, running the software available to me, is about as fast as a SUN 3/50 >while running the Dhrystone program. However my experience is that an 025 >machine with 4 megs of RAM, a disk, and MACH, is totally useless. It cannot >run X10, an xterm, and a single outgoing telnet at the same time. Yes, I am >saying that it is not as useful as a terminal. A diskless Sun 3/50 running >SUN OS 3.5, suntools, emacs, and pcc is comfortable. The 125 is about as >fast as a SUN 3/60, again running the software we have here. High end 80386 >and middle-end 68030 systems should be about twice as fast as the 3/60. At IBM T.J. Watson Research, we have a number of RT's running Mach. A simple C program running CPU bound with a working set of around 300k running niced makes it impossible to do any other work on the machine. This does not happen on either the AOS or AIX machines we have. The operating system seems to be the sole difference I can come up with. I believe that the Mach operating system runs well on a number of other machines and suspect that it is simply a matter of tuning. I typically run X 10, GNUemacs, outgoing telnets under Xterm, and so forth. I also have other people logging in to my system through telnet, am the server for some DS style remote mounts, and so forth. Admittedly, I have more memory and an APC. But I first brought up AIX on a 3 meg 025, and it was servicable, just a tad slow. (.....) >I am disappointed that there is no version of GCC for the RT. IBM could >allocate one person to do a port and give away the results, but it seems >that they would rather have a company sell a compiler without source. As far as I knew, someone in Project Athena has had a working code generator for GCC since last year, but that there were (at the time) technical reasons why the code generated was incorrect, even though it generated the correct results. Something about the granularity on the intermediate code pass. I have no idea what the current status is. (.....) >I am disappointed with the IBM 2-button mouse. It takes tremendous force >to push the buttons. We had an informal contest and only one person here >could hold both buttons down while lifting the mouse off the table. (For >people who have not had the pleasure of using the IBM mouse, you hold both >buttons down at once to emulate holding the middle button down on a real >mouse). I believe that there is a great deal of similiarity between the IBM RT mouse and the older Microsoft mice. The mechanisms seem to be similar, as does the button pushing force. I can hold the buttons down while using the mouse and lifting it off of the table surface, and frequently do, since I allocate the cover of a Usenix 4.2 manual as my mouse surface. Then again, I have large hands. People can pick up a Microsoft mouse and judge for themselves. Personally, I think that one button is the right number of buttons on the mouse. But this doesn't fit the X model. >I absolutely cannot believe that the keyboard clicks when you hit the shift >or control key. I wish that the caps lock key and the control key were the >same size so we could switch the key caps. Thank you someone for that >layout. Everyone here rebinds CTRL to the right place. And the ESC key?? Neither can I, as mine doesn't click when I push ctrl or shift. But I run AIX. The clicking is under software control, not hardware control, so I suspect that this is a problem with MACH or the AOS porting base again. I won't comment on key placement. >I am disappointed that the RT expansion bus is an AT bus. The AT form factor >limits the size of peripheral cards, and limits the power they have available. >Ever heard of an SMD controller for the AT?? 16 line serial line card?? I use the Anvil Systems Stallion 16 line card. It has a 186 on it, and all of the cooking and stuff is offloaded to the card. Communication to the card is at the ioctl()/read()/write() level. Requires a special I/O driver, of course, which is available from Anvil for AIX. This is not a product endorsement. At the Unix Expo, I saw a lot of 16 line serial cards that ran on the AT bus, as well as some that fit in the smaller form factor of the MCA bus card. Of course, they required special connectors. We sell a SCSI adapter, but not an SMD adapter, as far as I know, although I understand that you can get conversion cards. >These problems will be worse with smaller MCA cards. We will throw away the >RT boxes when they are obsolete. We will NOT throw away the SUN 3/160 boxes >when the 3/160 is no longer interesting. Throw one my way? I'll be glad to drive over and pick it up. :-) >Many of the things that I dislike about the RT could be fixed in the future. >Today we give APC's to people who cannot afford SUNs. We give old RT's to >people to punish them :-) > > Lawrence Butcher @g.gp.cs.cmu.edu >-- I believe that you are correct in your assessment: the problems are fixable. Some are already fixed, in that I think that the 19 inch Megapel is enough real-estate to edit on, and that other problems you mentioned are being fixed, through our efforts and through the efforts of third parties. I also believe that at least some of these problems you mention are software related, perhaps even Mach specific, and that the RT can't be blamed for them. Since this has gotten away from comp.arch, I've directed followups to comp.sys.ibm.pc.rt. -- Nick Simicich --- uunet!bywater!scifi!njs --- njs@ibm.com (Internet)
rick@pcrat.UUCP (Rick Richardson) (12/03/88)
In article <3736@pt.cs.cmu.edu> butcher@g.gp.cs.cmu.edu (Lawrence Butcher) writes: >Mr. Sauer's benchmark people should be aware that the current version of the >Dhrystone benchmark is version 2.0. Version 1.1 numbers are not timely. > >My measured Dhrystone numbers (Dhry 2.0) are (roughly): > >2191 for the (RT, ROMP, 6150, Model 025, at 6 MHz) using mc >3176 for the 6152 using mc >3551 for the (APC, 6151, 125, at 10 MHz) using pcc >4474 for the (APC, 6151, 125 at 10 MHz) using mc Looking back on the last list of 1.1 results I put together, it seems pretty clear the Sauer's "Advanced C" numbers are running with all possible optimization turned on. Which makes them pretty much useless as an indication of anything other than that the optimizer people have been at work. Dhrystone 2.1 is not as easily fooled by optimizers. How about posting some 2.1 numbers for the record? -- Rick Richardson | JetRoff "di"-troff to LaserJet Postprocessor|uunet!pcrat!dry2 PC Research,Inc.| Mail: uunet!pcrat!jetroff; For anon uucp do:|for Dhrystone 2 uunet!pcrat!rick| uucp jetroff!~jetuucp/file_list ~nuucp/. |submission forms. jetroff Wk2200-0300,Sa,Su ACU {2400,PEP} 12013898963 "" \d\r\d ogin: jetuucp
rpd@RPD.MACH.CS.CMU.EDU (Richard Draves) (12/05/88)
In article <447@scifi.UUCP> njs@scifi.UUCP (Nicholas J. Simicich) writes: >At IBM T.J. Watson Research, we have a number of RT's running Mach. A >simple C program running CPU bound with a working set of around 300k >running niced makes it impossible to do any other work on the machine. >This does not happen on either the AOS or AIX machines we have. The >operating system seems to be the sole difference I can come up with. >I believe that the Mach operating system runs well on a number of >other machines and suspect that it is simply a matter of tuning. I know of one performance gotcha with Mach on RTs. The RT MMU only allows sharing of segments. Mach VM is more general and allows sharing of pages. However, it should still notice when what is being shared is in fact an entire segment (notably, text segments) and use a common segment to implement the sharing. However, it doesn't do this. (The interface between the machine-independent and machine-dependent VM code makes it difficult to figure out that this is possible/desirable.) Instead, each address space is composed of different segments. Because the RT architecture only allows a page to be in one segment at a time, when a process uses a shared page it may take a "translation fault" which moves the page into the right segment. These faults are pretty expensive; on a Model 25 RT they take more than a millisecond. For example, every time our csh runs a command about 80 of these faults occur. Rich Sanzi recently greatly improved the translation-fault handling time, but it is still an unfortunate performance hit. I dug out my copy of Dhrystone 1.1 and tried to reproduce Sauer's numbers. Sauer Draves Model 25 4000 3270 Model 125 8300 7855 Model 135 10400 9765 I used hc2.1d and ran the tests single-user. Problems with VM don't explain the discrepancies. (I wonder why the Model 25 number is especially far off?) Is there some compiler better than hc2.1d? Do AIX and AOS get different numbers? Rich Draves --
dyer@spdcc.COM (Steve Dyer) (12/05/88)
Just FYI, in running Dhrystone 2.1, here are a few figures for the
model 25 and model 125 under the latest September AOS 4.3 with the
stock "cc" (some rev of "hc" which I am not sure of), another version
of "hc" (older I hope): "hc1.4", and "pcc". The same binary images
were run on both.
Model 25 Model 125
hc hc1.4 pcc hc hc1.4 pcc
No Reg 3075 2201 1623 7264 --- 3333
Reg 3075 2201 1831 7281 3685
I didn't bother with rerunning the hc1.4 on the APC.
Just more evidence that a good compiler is critical for this machine.
If Sauer's numbers are to be believed, it's a shame that the AIX C compiler
technology is not available to the AOS group in Palo Alto (and therefore to us).
You can compare these results with an Intel Inboard 386/AT at 16mhz
& 64kb cache running under SCO XENIX 386 2.2.3: 4587 (no reg), 4893 (reg).
--
Steve Dyer
dyer@harvard.harvard.edu
dyer@spdcc.COM aka {harvard,husc6,linus,ima,bbn,m2c,mipseast}!spdcc!dyernjs@scifi.UUCP (Nicholas J. Simicich) (12/05/88)
In article <3764@pt.cs.cmu.edu> rpd@RPD.MACH.CS.CMU.EDU (Richard Draves) writes: .............. >I dug out my copy of Dhrystone 1.1 and tried to reproduce Sauer's numbers. > Sauer Draves >Model 25 4000 3270 >Model 125 8300 7855 >Model 135 10400 9765 > >I used hc2.1d and ran the tests single-user. Problems with VM don't explain >the discrepancies. (I wonder why the Model 25 number is especially far off?) >Is there some compiler better than hc2.1d? Do AIX and AOS get different >numbers? .............. I haven't asked Charlie, but I suspect that he would have used the Advanced C Compiler under AIX for his figures. I haven't compared the compilers, personally. This is a totally different compiler with totally different numbers, I presume. Charlie? -- Nick Simicich --- uunet!bywater!scifi!njs --- njs@ibm.com (Internet)
friedl@vsi.COM (Stephen J. Friedl) (12/06/88)
In article <628@pcrat.UUCP>, rick@pcrat.UUCP (Rick Richardson) writes:
< [...]
< Which makes them pretty much useless as an indication
< of anything other than that the optimizer people have been
< at work.
<
< Dhrystone 2.1 is not as easily fooled by optimizers. How
< about posting some 2.1 numbers for the record?
This looks like the traditional battle between the people
who make tank armor and those who make anti-tank weapons...
--
Stephen J. Friedl 3B2-kind-of-guy friedl@vsi.com
V-Systems, Inc. attmail!vsi!friedl
Santa Ana, CA USA +1 714 545 6442 {backbones}!vsi!friedl
Nancy Reagan on my new '89 Mustang GT Convertible: "Just say WOW!"sauer@auschs.UUCP (Charlie Sauer) (12/06/88)
In article <471@scifi.UUCP>, njs@scifi.UUCP (Nicholas J. Simicich) writes: > I haven't asked Charlie, but I suspect that he would have used the > Advanced C Compiler under AIX for his figures. I haven't compared the > compilers, personally. This is a totally different compiler with > totally different numbers, I presume. Charlie? Yes, it was the Advanced C Compiler, with AIX 2.2, that was used for those numbers, as a footnote (Advanced C, which implies AIX) in the posting indicated. -- C.H. Sauer IBM Advanced Workstations Div. uucp: cs.utexas.edu!ibmaus!sauer 11400 Burnet Road, D75/802 822: @CS.UTEXAS.EDU:sauer@ibmaus.uucp Austin, Texas 78758-2502 aesnet: sauer@auschs (512) 823-3692 vnet: SAUER at AUSVM6
clarke@acheron.UUCP (Ed Clarke) (12/06/88)
From article <2213@spdcc.COM>, by dyer@spdcc.COM (Steve Dyer): > Just more evidence that a good compiler is critical for this machine. > If Sauer's numbers are to be believed, it's a shame that the AIX C compiler > technology is not available to the AOS group in Palo Alto (and therefore to us). I believe that the pl.8 compiler was designed first; then the hardware was designed to fit it (really!). The first machine was a wire-wrapped 74S ttl monster ( not cmos ) that was continuously changed as improvements were made to the compiler design. I have a (tiny) piece of it in my closet at work ( grabbed it out of the trash can ). -- Ed Clarke uunet!bywater!acheron!clarke