Path: utzoo!attcan!ncrcan!scocan!mark From: mark@sco.COM (Mark Chojnacki) Newsgroups: comp.arch Subject: Re: Inlining subroutines at link time Message-ID: <1990Jul6.122516.1402@sco.COM> Date: 6 Jul 90 16:25:16 GMT Organization: SCO Canada, Inc. (formerly HCR Corporation) Lines: 84 In article <1990Jul3.194348.21178@msuinfo.cl.msu.edu> riordanmr@clvax1.cl.msu.edu (Mark Riordan) writes: >I just came across a CDC NOS/VE manual describing a facility to >inline FORTRAN routines after compilation (essentially during linking). Actually, it's quite distinct from linking. As of NOS/VE 1.5.1 (released in December 1989), the Afterburner (as the utility is called) can handle FORTRAN Version 1, FORTRAN Version 2, CYBIL (CDC's OS implementation language), COBOL and C (only C/VE initially, CV2 when it becomes available). >I no longer have access to a NOS/VE system, so I don't know how well >this works, but it seems like a fairly unique feature to me. Have >you folks ever heard of a similar system? It works very well on CYBERs. There is a limit to how much you can afterburn a bound module, however... In article <9595@brazos.Rice.edu> preston@titan.rice.edu (Preston Briggs) writes: >There's a rumour that some Unix C compilers do similar things. >Generally though, it seems a waste, particularly for Fortran. >Consider the time spent in a subroutine versus a savings of two >instructions -- hardly worth the time to specify an extra compile flag. The CALLREL, CALLSEG and RETURN instructions on many CYBER 180 machines are expensive in terms of machine cycles. For call-intensive programs in any language on these machines, the Afterburner can be very beneficial. I know: I've seen it make very significant performance improvements to high-profile application programs. These were programs which derived very little benefit from conventional compile-time inlining. In article <2305@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: >I have difficulty seeing how a linker can inline, as register conflicts >must be avoided. If it can change the register allocations, it may, >however, do very well. The NOS/VE Afterburner (which is not a linker -- it is an object management tool which takes bound modules as input and produces bound modules as output) does, in fact, change register allocations to improve performance. >As for saving only two instructions, these instructions are likely to >be very time-consuming, usually at least partially blocking internal >parallelism. I far too many machines on which a transfer should be >considered a catastrophic instruction. You've hit the nail on the head. This is exactly the case with many of the existing CYBER 180 machines. Apparently, the CYBER 2000 has addressed this deficiency to some degree with faster CALL/RETURN instructions. I do not know to what degree they have been improved. In article <9629@brazos.Rice.edu> preston@titan.rice.edu (Preston Biggs) writes: >Since it's at link time, I assume (!) the linker simply substitutes >the procedure body (minus the return) for the call instruction. >Hence, 2 instructions saved. Arguments would still be passed >in registers or on the stack and registers would be saved and restored >as usual. More complex schemes would (possibly) be too complex and >expensive for link-time. At any rate, that's all that was promised >by his manual. Nope. See above. It also removes register saves and restores. >Paging effects and I-cache effects are difficult to determine in >advance. You get better locality with inlining, but you also get >bulkier code. Consider also the effect of inlining a very small routine >(a favorite choice). With the non-inlined version, the routine might >remain in cache (or paged in) for extended periods, perhaps being >called from many different call sites. In the inlined case, >each call site would have it's own copy and require more cache >lines or pages. Yes, it is clearly a user-mode CPU time vs. memory space tradeoff... >Best seems to be experimentation with your own . I second that. The problem is that many environments do not offer a tool like the Afterburner with which to experiment... Disclaimer: the above are my opinions and not necessarily my employer's... Mark Chojnacki, Network Applications, SCO Canada, Inc. (416) 922-1937 mark@sco.com (formerly HCR Corporation) or ..!uunet!scocan!mark Toronto, Ontario, Canada