> Bill Stoddard wrote: > > > > Please lets not go overboard with these types of optimizations. This could get >out of > > control quickly. Having code that is easy to read, understand and maintain is >-much- more > > important than saving a a few extra cycles. > > In a previous job where I had a lot of low level hardware profiling information > available, we found that on average, instructions which incurred cache misses > took something like 26 times longer to execute than instructions which didn't > miss. That difference is likely to grow as CPUs get faster relative to main > memory. There is a fair amount of research and development in > feedback-directed compilation techniques to automate such optimizations. For > example, http://www.research.ibm.com/journal/sj/372/schmidt.html . > > But since this bothers people, I will move the infrequently executed > instructions back into the hot path. > > Greg >
I am not against restructuring the code to be more friendly to instruction caches and I am not dogmatically opposed to judicious use of goto, however... The use of goto in this case exceeds my pain threshold by a substantial margin. This approach taken to its logical conclusion would yield unsupportable code. Bill