Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!sun-barr!decwrl!amdcad!nucleus!tim From: tim@nucleus.amd.com (Tim Olson) Newsgroups: comp.arch Subject: Re: Integer/Multiply/Divide on Sparc Message-ID: <28673@amdcad.AMD.COM> Date: 8 Jan 90 15:38:10 GMT References: <158@csinc.UUCP> <787@stat.fsu.edu> <42701@lll-winken.LLNL.GOV> <788@stat.fsu.edu> <42737@lll-winken.LLNL.GOV> <5842@ncar.ucar.edu> <34058@mips.mips.COM> <28594@amdcad.AMD.COM> <85593@linus.UUCP> Sender: news@amdcad.AMD.COM Reply-To: tim@amd.com (Tim Olson) Organization: Advanced Micro Devices, Inc., Austin, Texas Lines: 27 Summary: Expires: Sender: Followup-To: In article <85593@linus.UUCP> bs@gauss.UUCP (Robert D. Silverman) writes: | Huh? I don't see multiple modulus operations in the loop below. I see ONE. | How can one modulus operation inside a loop "over-emphasize" integer | modulus? Because it occurs at a much higher frequency in this loop than is "normally" found in most programs. In our collection of benchmark programs, out of 50K C lines (85K assembly lines) there were 104 integer division/modulo operations (most were integer division) -- about 0.1%. This is a static measurement -- I don't have the dynamic frequency handy, but it is also small. | :and spends roughly 75% of its time performing the "%" operation. | | This is exactly my point! The fact that one operation takes 75% of the run | time for a loop with about 20 operations indicates how badly SPARC does | division. Most programs may not do a lot of division, but when a program | DOES require it, the performance of the SPARC is a joke. Not just on SPARC -- it spends this amount of time on many architectures. It is very hard to greatly speed up division (although the TI guys seem to have done it). Division will usually be slower than other arithmetic operations by an order of magnitude. -- Tim Olson Advanced Micro Devices (tim@amd.com)