Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!edcastle!aipna!rjc From: rjc@uk.ac.ed.cstr (Richard Caley) Newsgroups: comp.lang.c Subject: Re: Help with casts Message-ID: Date: 27 Feb 91 07:01:52 GMT References: <1991Feb21.040145.8678@cec1.wustl.edu> <409@ceco.ceco.com> <339@smds.UUCP> <414@ceco.ceco.com> Sender: news@aipna.ed.ac.uk Organization: Center for Speech Technology Research Lines: 44 In-reply-to: garry@ceco.ceco.com's message of 23 Feb 91 17:26:53 GMT In article <414@ceco.ceco.com>, Garry Garrett (gg) writes: gg> Bear in mind that C is one of the hardest languages in the world gg> to optimize. For instance, in pascal the index of a for loop gg> cannot be referenced outside of that loop, thus the code can be gg> optimized by making that index a register variable. a) Whether you reference outside will not affect whether it can be made a regiser variable (though it might affect the advisability). b) it is amazingly trivial for the compiler to look and see if it is referenced outside. gg> You must explicitly ask the compiler to make a varible into gg> a register variable by declairing it as such. There is no way to do this. `register' is, at best, a hint. The compiler will stick what it likes into registers. gg> There are many reasons why C is harder to optimize, To coin the old phrase -- name three. The only ones which comes to mind are pointers and casts, both of which will only be a problem if you use them, so there is no loss. gg> so when you are programming in C, you must not count on an gg> optimizer to clean things up for you. If any of the trivial micro-optimisations which were listed in that article make any difference, I think someone needs to kick the compiler writer:-) Counting down rather than up is only faster if compare against 0 is faster on your machine. The compiler is more likely to knowthat than you. gg> Sorry, but my code is still faster. It's only faster if it runs faster, arguing about hypothetical (broken) compilers on hypothetical machines proves nothing. -- rjc@cstr.ed.ac.uk