Xref: utzoo comp.arch:16970 comp.lang.misc:5104 Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!decwrl!bacchus.pa.dec.com!granite.pa.dec.com!mwm From: mwm@raven.pa.dec.com (Mike (Real Amigas have keyboard garages) Meyer) Newsgroups: comp.arch,comp.lang.misc Subject: Re: Compiler Costs Message-ID: Date: 6 Jul 90 19:54:58 GMT References: <1797@apctrc.UUCP> Sender: news@wrl.dec.com (News) Organization: Missionaria Phonibalonica Lines: 28 In-Reply-To: zrra07@backus's message of 5 Jul 90 14:36:56 GMT In article <1797@apctrc.UUCP> zrra07@backus (Randall R. Appleton) writes: In other words, if I take my average well written program, compiled with a good optimizing compiler, and re-write it in assembler, what sort of speedup should I expect to see? Lots of good answers, but everyone missed my favorite reason for compilers generating lousy code - they have a machine that's ill-matched to the language in question. The best example is to take a language that really expects there to be a stack, and compile it for a machine that doesn't have one. An excellent compiler will decide which routines aren't possibly recursive and compile them into code that doesn't use the stack, but other routines will have to simulate the stack in some (probably slow & ugly) manner. I never saw a compiler that smart, but it's been years since I worked on such a machine. Given that all routines are compiled as if they might be recursive, recoding in machine language in such a case - even if the coder is only moderatly competent - to use fixed memory locations for local variables and pass arguments in registers instead of doing those things on a fake stack can easily run an order of magnitude faster, and a factor of 2 smaller.