kruger@16bits.dec.com (Hart for CCCP chief in '88) (01/15/88)
I believe that performance gains, one way or the other, will be comparatively small. HOWEVER. It seems to me that the best way to incorporate automatic profiling is to put profiling data back in the code. Otherwise, every time you compile a new version, you have to apply the profiler AGAIN. Let the !@*&$^ profiler stuff it's suggestions back in the source with FREQUENCY. Then, the human can change it to reflect conditions about which the profiler knowns nada, and can also recompile infinitely, while still retaining previous profiler information. dov
dtj@hall.cray.com (Dean Johnson) (02/03/88)
The performance benefits of FREQUENCY in large scale architectures would likely be very slight. In more complex architectures with significant instruction buffers (such as supercomputers), jumps are very expensive and, unless you moved the less frequent block totally out of the flow of the program, you would be jumping around one of the blocks either way. If you moved the less frequent case out of the flow of the program, you would incur 2 jumps (to and from the block) to get back into the flow of the program, thus (atleast) doubling the cost of the less frequent case. There is potential for a small increase in performance by scheduling the most common case so that it would get in a few extra instructions before it had to jump, but it probably wouldn't be worth the hassle.
hansen@mips.COM (Craig Hansen) (02/04/88)
In article <3783@hall.cray.com>, dtj@hall.cray.com (Dean Johnson) writes: > The performance benefits of FREQUENCY in large scale architectures would > likely be very slight. In more complex architectures with significant > instruction buffers (such as supercomputers), jumps are very expensive > and, unless you moved the less frequent block totally out of the flow of > the program, you would be jumping around one of the blocks either way. > > If you moved the less frequent case out of the flow of the program, you > would incur 2 jumps (to and from the block) to get back into the flow of > the program, thus (atleast) doubling the cost of the less frequent case. However, even though it "doubles" the cost of less frequent case, if that case is sufficiently infrequent, it's a win. Take the following oversimplified model: assume the time for non-taken branch = 1 cycle time for taken branch = n cycles for an if-then-else clause that executes the "then" clause w/ frequency f: [we assume for an in-line if-then-else, that if the "then" clause is executed, you have one non-taken branch and one taken branch; if the "else" clause is executed, you have one taken branch, which falls through. For the out-of-line case, the "then" clause has two taken branches, and the "else" clause has one non-taken branch.] in-line cost = f*(1+n) + (1-f)*n = f+n out-of-line cost = f*2*n + (1-f)*1 = f*(2*n-1) + 1 out-of-line is better if: f*(2*n-1) + 1 < f + n ==> f*(2*n-2) < n - 1 ==> f < (n-1)/(2*n-2) [if n > 1] ==> f < 1/2 [if n > 1] So out of line execution of the "then" clause is better if: n < 1: f > .5 n = 1: same for any f n > 1: f < .5 For n > 1, the benefit is: f + n - f*(2*n-1) - 1 = f*(2-2*n) + n - 1 = 2*f*(1-n) - (1-n) = (1-n) * (2*f - 1) = (n-1) * (1 - 2*f) E.g.: f = .25, n = 4, in-line cost = 4.25, out-of-line cost is .25*7 + 1 = 2.75, average benefit is 1.5 cycles. -- Craig Hansen Manager, Architecture Development MIPS Computer Systems, Inc. ...{ames,decwrl,prls}!mips!hansen or hansen@mips.com 408-991-0234
aglew@ccvaxa.UUCP (02/09/88)
>The performance benefits of FREQUENCY in large scale architectures would >likely be very slight. In more complex architectures with significant >instruction buffers (such as supercomputers), jumps are very expensive >and, unless you moved the less frequent block totally out of the flow of >the program, you would be jumping around one of the blocks either way. Well, I would like to remove the really infrequent cases completely out of the flow of the program - at the very least to another page, so that I'm only getting pagefaults and cache misses due to instruction prefetch on code I really need to execute. I've traced several of the critical paths in UNIX, and well over half of the machine code produced is for paranoid cases that hardly ever happen: if( cond ) panic("cond"); Part of me wants to ifdef such code out, but naw, I wouldn't do that now... A good trace scheduling compiler, with manual and automatic profiling feedback, would be useful on a lot more than a VLIW machine. Andy "Krazy" Glew. Gould CSD-Urbana. 1101 E. University, Urbana, IL 61801 aglew@gould.com - preferred, if you have nameserver aglew@gswd-vms.gould.com - if you don't aglew@gswd-vms.arpa - if you use DoD hosttable aglew%mycroft@gswd-vms.arpa - domains are supposed to make things easier? My opinions are my own, and are not the opinions of my employer, or any other organisation. I indicate my company only so that the reader may account for any possible bias I may have towards our products.
franka@mmintl.UUCP (Frank Adams) (02/12/88)
In article <28200095@ccvaxa> aglew@ccvaxa.UUCP writes: |Well, I would like to remove the really infrequent cases completely |out of the flow of the program - at the very least to another page, |[Lots of code like:] | if( cond ) | panic("cond"); This sounds good, but for every such rule there is an exception. In this case, if "cond" is "page handling failure", I do *not* want to go to another page. -- Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Ashton-Tate 52 Oakland Ave North E. Hartford, CT 06108
aglew@ccvaxa.UUCP (02/18/88)
>In article <28200095@ccvaxa> aglew@ccvaxa.UUCP writes: >|Well, I would like to remove the really infrequent cases completely >|out of the flow of the program - at the very least to another page, >|[Lots of code like:] >| if( cond ) >| panic("cond"); > >This sounds good, but for every such rule there is an exception. In this >case, if "cond" is "page handling failure", I do *not* want to go to another >page. > >Frank Adams ihnp4!philabs!pwa-b!mmintl!franka >Ashton-Tate 52 Oakland Ave North E. Hartford, CT 06108 Which is why I want manual control over compiler optimizations from time to time.