Subject: Re: Newbie: floating point optimization From: Erik Naggum <erik@naggum.no> Date: 19 Jan 2004 07:14:02 +0000 Newsgroups: comp.lang.lisp Message-ID: <3283485242706138KL2065E@naggum.no> * Christian Hofer | Using "the" sometimes increases the time for evaluation. It is permissible for an implementation to do run-time type-checking to ensure that THE forms are honest. They could continue to do this no matter what your speed optimize declarations are, but should turn them off if you specify (declare (optimize (safety 0))). | But on the other hand, using the "time"-function seems to be unreliable | anyway: it shows very different times for each evaluation. Modern computers do a lot of unannounced work, especially if they are active on any sort of network. Updating system timers is usually done in response to interrupts, and may take place with any latency that keeps the the clock accurate enough for comfort, so it is prudent for the user of timers to ensure that the timing granularity is coarse enough that values are trustworthy. This is why it is often a very good idea to repeat the operation that is to be timed a /huge/ number of times, or to use timer alarms that let you run at full speed for a period of time only to return the number of repetitions it managed to complete. Of course, the results obtained under such conditions are nowhere near the execution speed you can expect when performing the operation once or under wildly different conditions. For this reason, profiling is an art best left to experts or those willing to become experts, which will take a tremendous amount of time, investigation of hardware and the actually executed machine code, memory arrangement, etc. It is very easy to be attracted to the easily measured and to relegate the unmeasurable to «mystic noise». The more precise values you get from a measurement method, the more you have to brace yourself to resist the sexiness of apparent simplicity and elegance. Computers exhibit the placebo effect, too, and they will give you good results along any scale you use, so you have to be able to predict the results with inordinate precision and duly investigate any deviation from your meticulous predictions. If you only measure «something» and are happy with every positive development in the measured values, regardless of cause, you will end up with good measurement values of something that you would never have done. Performance tuning experts are very often subjected to code that has been «improved» by people who has done just about anything to shave off a millisecond here and a millisecond there with absolutely no regard for the performance of anything else, least of all the overall performance. | (I don't want to focus too much on optimization at the moment | generally, it's just that I don't want my homework to be ten times | slower than that of those who have used Java.) Well, you have at least figured out the optimal bait to entice Common Lisp programmers to come to your aid, but will you get your academic degree ten times faster if your homework is just as slow as the Java solution of your competitors in the rat race? (No need to answer. :) I suggest that you ignore performance completely and focus on two other properties that performance obsession tends to ignore completely: That it be /correct/, and that it not be /wasteful/. Waste indicates that you lack understanding, incorrect indicates that you lack attention to detail. High performance indicates a lucky match between you and the execution vehicle. For instance, one contributor here recently posted a function that inverted symbol names that was extremely wasteful, but which expressed the core idea very well. A quality implementation of this function would use both caching of the inverted result with the symbol and an efficient state machine that determined that it should not invert the string as soon as two characters with different case were detected. The Java crowd is actually extremely educational when it comes to this whole question of optimization. Sun developed a environment that was known to be slow as molasses, but then worked really hard at finding ways to make it run faster, while the applications were extremely hard to optimize for speed. These days, it takes even more effort to write a better-performing solution in C or C++ than to write it in Java, and it just isn't worth it, anymore. Of course, this means that instead of being employable as a highly rewarded performance tweaker in C or C++, you have to compete with a billion programmers in India and China who rely on the thousand or so developers of the run-time development. Let me connect premature and unnecessary optimization with a known evil that should at least work through the guilt-by-association mechanism: The reason we see so much spam is not that it works, but that it does not work. Those who engage in this crime believe that when they get a low response rate, the best solution is to increase the volume of spam so that they will get more responses. Locally, they optimize for more responses, but globally, they reduce the likelihood of being heard at all, increase the likelihood of /never/ getting a customer that might have bought their goods or services if they had discovered them on their own in a respectable advertising venue, and increase the cost of marketing for all marketers. There is, however, not a shred of doubt that those who engage in marketing through unwanted e-mail both rate their marketing strategy a success and optimize the only way they can measure. Had they been (a whopping lot) smarter, they would not have cared just about the number of sales they made, but about the global response rate to unwanted e-mail, which has dropped to less than one response in 10 million messages and will drop to less than one in a billion messages before the end of 2004 at current spam growth rates. This happens because those who engage in this crime actually receive responses from people who are so stupid they should be terminated on the spot, but what research has been done on that pathetic demographic has shown that they are the kind that needs to be fooled once before they get it, so the market for virgin fools is rapidly diminishing. The morale of this story is that if you optimize for the measurable quantity and ignore the unmeasured and maybe unmeasurable quantities, you end up annoying close to a billion people on the Internet. -- Erik Naggum | Oslo, Norway Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.