Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!rutgers!cmcl2!stealth.acf.nyu.edu!brnstnd From: brnstnd@stealth.acf.nyu.edu Newsgroups: comp.lang.misc Subject: Re: Common subexpression optimization Message-ID: <5453:23:28:32@stealth.acf.nyu.edu> Date: 8 Feb 90 23:28:33 GMT References: <4561@scolex.sco.COM> <14214@lambda.UUCP> <2217@sunset.MATH.UCLA.EDU> <838.18:06:33@stealth.acf.nyu.edu> <2115@castle.ed.ac.uk> Reply-To: brnstnd@stealth.acf.nyu.edu (Dan Bernstein) Organization: IR Lines: 24 In article <2115@castle.ed.ac.uk> nick@lfcs.ed.ac.uk (Nick Rothwell) writes: > In article <838.18:06:33@stealth.acf.nyu.edu>, brnstnd@stealth writes: > >Piercarlo is entirely correct. If you care about ``information hiding'' > >and the ``purity'' of your code more than efficiency, you can't expect > >fast code. If you can't bear to put your original code in comments and > >write an efficient version with temporary variables, you don't deserve > >fast code. > > This is rubbish, check out the performance of New Jersey ML > (high-level functional language, efficient optimised native code > generation). Are you saying that your compiler is smarter than you are or just that it's not as lazy? Can it figure out, say, Knuth's algorithm for computing the delta2 table in Boyer-Moore string searching, starting from a dumb algorithm for the same job? Humans can optimize better than computers. This will be true for a long time. I chose the above example randomly, but it'll serve well enough as a goal that I won't live to see computers reach. ---Dan