3 ms·
IO is a huge one, most apps aren't CPU bound, they are IO bound. Those that aren't IO bound are latency bound. Those that are CPU bound are usually IO/latency b
by fleitz 14y ago
IO is a huge one, most apps aren't CPU bound, they are IO bound. Those that aren't IO bound are latency bound. Those that are CPU bound are usually IO/latency bound on memory.
If one can keep a modern Core i7 busy crunching numbers they are a God amongst mere mortals.
- zobzu 14y agoif you over engineer stuff enough, don't worry, it'll crunch numbers in loop for a while ;) Last script I wrote - in about 20 lines of actual bash calling C programs which I know are well written, was performing the analysis of a 400meg file in about 15s. File was in fs cache (you know, Linux has an actual decent fs cache, unlike some other kernels..). Anyway, I then realized 2 people coded the same script already, one using perl, one using python. I sort of expected those would be slow, overengineered and what not after a quick look at the code. Then I decided I couldn't bad mouth stuff like this (even if I'm generally just telling this to myself) without giving it a chance. python took 50s, perl took about 2 min (yeah given perl's performance with strings, I was rather surprised, this must have been pretty poorly done). Each of these programs had about 500 lines of code (!!!). Ridiculous. Unfortunately, that's seems to be the standard these days. And I find this to be a perfect example, regardless of the language. No thinking => spend a long time writing a program with "nice classes" and stuff => its magnitudes slower than a non-optimized but properly designed program is. Thinking about proper design, knowing how your language, runtime, libs, kernel works at least in the big lines => (much) quicker to write the program => decently fast, and you have more time to make it even faster now.