two-pot screamer dot com

From Slashdot | Old-School Coding Techniques You May Not Miss

Premature optimizations (Score:5, Informative)

by IntentionalStance (1197099) on Thursday April 30, @03:29AM (#27769343)

This is one of my favourite quotes:

“The First Rule of Program Optimization: Don’t do it. The Second Rule of Program Optimization (for experts only!): Don’t do it yet.” – Michael A. Jackson

That being said, when I hit the experts only situation I can usually get 2 orders of magnitude improvement in speed. I just then have to spend the time to document the hell out of it so that the next poor bastard who maintains the code can understand what on earth I’ve done. Especially given that all too often I am this poor bastard.

Re:Quicksort (Score:5, Insightful)

by fractoid (1076465) on Thursday April 30, @10:07AM (#27772217)
Homepage

Um, I’m pretty sure quicksort is still the go-to sort simply because it’s the implementation that’s built into almost every single programming environment. Then again honestly, I’d say that from the point of view of a pragmatic programmer… it doesn’t matter. There’s a built-in fuction (whether it’s qsort() in the C standard library, or Arrays.Sort() in Java, or whatever) that will take your array and return it, sorted. If your app runs too slow and you profile it and it turns out the speed problem is in the sorting AND you can’t find a better algorithm that doesn’t depend so much on sorting… THEN you look at optimising it. Never forget the two cardinal rules of optimising:

1) Don’t optimise.
2) (Experts only:) Optimise later.

Or as I once read it eloquently expressed:
1) Make it work.
2) Make it work right.
3) Make it work fast.

Re:Some, not all… (Score:5, Insightful)

by Aceticon (140883) on Thursday April 30, @04:46AM (#27769753)

Maybe you guys are frozen in time – or maybe you’re some kind of elitist-coder types.

From where I stand, the most relevant optimizations have to do optimizing the data flows between systems – the most typical of which are appServer-database and GUI-appServer and between storage and memory. We’re talking about shaving hundreds of miliseconds, maybe even seconds per-operation: not nanoseconds.

Even if you work in standalone, small size applications, were knowing the basic principles of algorithms can be more important, hand-coding your own is not only useless (there are plenty of libraries out there with good implementations) it’s actually counter productive (it introduces a complex piece of code which is often not properly tested and might be even slower than the library ones)

Understanding the basic principles = important.
Being able to code your own = only important for those who never evolved beyond just-a-coder.

Self-modifying code has been a lose for a decade. (Score:5, Informative)

by Animats (122034) on Thursday April 30, @12:59AM (#27768465)
Homepage

Self-modifying code

Yup, I actually write asm code.. plus he mentions “modifying the code while it’s running”.. if you can’t do that, you shouldn’t be wielding a debugger.

Code that generates code is occasionally necessary, but code that actually modifies itself locally, to “improve performance”, has been obsolete for a decade.

IA-32 CPUs still support self-modifying code for backwards compatibility. (On most RISC machines, it’s disallowed, and code is read-only, to simplify cache operations.) Superscalar IA-32 CPUs still support self-modifying code. But the performance is awful. Here’s what self-modifying code looks like on a modern CPU:

Execution is going along, with maybe 10-20 instructions pre-fetched and a few operations running concurrently in the integer, floating point, and jump units. Alternate executions paths may be executing simultaneously, until the jump unit decides which path is being taken and cancels the speculative execution. The retirement unit looks at what’s coming out of the various execution pipelines and commits the results back to memory, checking for conflicts.

Then the code stores into an instruction in the neighborhood of execution.
The retirement unit detects a memory modification at the same address as a pre-fetched instruction. This triggers an event which looks much like an interrupt and has comparable overhead. The CPU stops loading new instructions. The pipelines are allowed to finish what they’re doing, but the results are discarded. The execution units all go idle. The prefetched code registers are cleared. Only then is the store into the code is allowed to take place.

Then the CPU starts up, as if returning from an interrupt. Code is re-fetched. The pipelines refill. The execution units become busy again. Normal execution resumes.

Self-modifying code hasn’t been a win for performance since the Intel 286 (PC-AT era, 1985) or so.
It might not have hurt on a 386. Anything later, it’s a lose.

This entry was posted on Monday, May 25th, 2009 at 6:22 am and is filed under Scrapbook. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.