hubcap@hubcap.clemson.edu (Mike Marshall) (10/09/89)
Hi - A prof here is running benchmarks on everything that isn't tied down. He told me that his benchmark program ran on my DECstation 3100 as fast as it did on an IBM 3081 mainframe. But, he said, it took forever to compile. It compiles on our VAX-8810 running ULTRIX in about 20-30 seconds. On my workstation, it took about 8 minutes to compile. I am assuming that the reason that it takes so long on on my workstation can be attributed to the fact that RISC compilers have so much more work to do than "regular" compilers. Does my evaluation seem on the mark to you all, or is there probably more to it? -Mike hubcap@clemson.edu
mikem+@andrew.cmu.edu (Michael Meyer) (10/09/89)
The compile time on a Decstation is very dependent on the amount of memory in the machine. The compiler can consume VAST amounts of memory, and can cause the machine to thrash. With optimization turned on I have seen a c program take 2 hours to compile on an 8M Decstation, while it took only a few minutes on a 16M machine.
scs@itivax.iti.org (Steve Simmons) (10/10/89)
hubcap@hubcap.clemson.edu (Mike Marshall) writes: >He told me that his benchmark program ran on my DECstation 3100 as fast as >it did on an IBM 3081 mainframe. But, he said, it took forever to compile. >It compiles on our VAX-8810 running ULTRIX in about 20-30 seconds. On my >workstation, it took about 8 minutes to compile. Can you say "I/O Bandwidth"? I knew you could.... :-) Seriously, I/O bandwidth is what separates mainframes from workstations from minis. Compilation is I/O intensive, particularly if your compiler drives your 3100 into heavy swapping or paging. Retime those compilation tests and look at system times vs. wall clock time. I think you'll see some telling numbers. -- + Steve Simmons scs@itivax.iti.org + + Industrial Technology Institute Ann Arbor, MI. + + "Even a dog can shake hands." -- Warren Zevon +
lyndon@cs.AthabascaU.CA (Lyndon Nerenberg) (10/10/89)
In article <4152@itivax.iti.org> scs@itivax.iti.org (Steve Simmons) writes: >Seriously, I/O bandwidth is what separates mainframes from workstations >from minis. Compilation is I/O intensive, particularly if your compiler >drives your 3100 into heavy swapping or paging. Retime those compilation >tests and look at system times vs. wall clock time. I think you'll see >some telling numbers. Umm ... we just finished running some tests between a Sun 4/60 and a Sun 4/370. The NFS throughput between these machines (4/370 as server) was faster than our 785 gets to its LOCAL disks! (Ultrix 2.3 and RA81's). Of course my argument is predicated on the 785 being considered a mainframe :-) [ And the 4/60 not being considered one ... ] -- Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University {alberta,decwrl,lsuc}!atha!lyndon || lyndon@cs.AthabascaU.CA "I think every man should have a wife. You can't blame everything on the government." -- Jed Clampett
elgie@canisius.UUCP (Bill Elgie) (10/10/89)
In article <6709@hubcap.clemson.edu>, hubcap@hubcap.clemson.edu (Mike Marshall) writes: > A prof here is running benchmarks on everything that isn't tied down. > > He told me that his benchmark program ran on my DECstation 3100 as fast as > it did on an IBM 3081 mainframe. But, he said, it took forever to compile. > > It compiles on our VAX-8810 running ULTRIX in about 20-30 seconds. On my > workstation, it took about 8 minutes to compile. > > I am assuming that the reason that it takes so long on on my workstation > can be attributed to the fact that RISC compilers have so much more work > to do than "regular" compilers. > Does my evaluation seem on the mark to you all, or is there probably more > to it? I would say that there is more to it. While compilers on RISC systems may have to do "more work", I would say (based on the fact that we compile the same code frequently on both MIPS-based and VAX-based processors) that the ratio is less than 2:1 and often close to 1:1 . The major difference that you saw (8810 vs 3100) is more likely due to lack of memory. I would guess that you have somewhere between 8 and 12 meg in the 3100 and all the windowing software would take 6 meg or so of that. The 8810 probably had at least 64 meg. To illustrate, the following is an "excerpt" from a set of benchmarks that we ran recently. This shows average elapsed time per compile for 1-8 simul- taneous compiles. The MIPS M/120, which uses the same processor as the 3100, has 16 meg memory; the 8550 has 32. "O2" level optimization was used on the MIPS ("O1" would have run apx. 20% faster). System 1 compile 4 simult. compiles 8 simult. compiles MIPS M/120 102 360 804 VAX 8550 107 323 645 greg pavlov (under borrowed account), fstrf, amherst, ny
mjb@acd4.UUCP ( Mike Bryan ) (10/10/89)
In article <6709@hubcap.clemson.edu> hubcap@hubcap.clemson.edu (Mike Marshall) writes: >He told me that his benchmark program ran on my DECstation 3100 as fast as >it did on an IBM 3081 mainframe. But, he said, it took forever to compile. > >It compiles on our VAX-8810 running ULTRIX in about 20-30 seconds. On my >workstation, it took about 8 minutes to compile. > >I am assuming that the reason that it takes so long on on my workstation >can be attributed to the fact that RISC compilers have so much more work >to do than "regular" compilers. I've seen similar things here. I just recently compiled a set of programs on a MicroVAX II and a DECSystem 5400. Both systems have 16MB of memory; the MVII has an RA81, the 5400 has an RF71. Overall, the 5400 was faster by about a factor of 2.5. However, on one particularly large module (about 5000 lines), the compile time went up from 40 seconds to 50 minutes. Continuous "ps -axv" and "vmstat" commands showed that (1) the program "uopt" wanted 18 MB of memory, and was getting about 75% of system memory and 1% of the CPU time, and (2), the system was paging *extremely* heavily. Turning off optimization (the "-O" flag) caused the compile time to go back down to 30 seconds. It appears that once you reach a certain complexity in a program, the optimizer requires so much memory that your system starts thrashing madly. With all the new "wonderful" switches for "cc(1)", it would be nice to have one saying "optimize until you reach 'too much memory'". -- Mike Bryan, Applied Computing Devices, 100 N Campus Dr, Terre Haute IN 47802 Phone: 812/232-6051 FAX: 812/231-5280 Home: 812/232-0815 UUCP: uunet!acd4!mjb ARPA: mjb%acd4@uunet.uu.net "Did you make mankind after we made you?" --- XTC, "Dear God"