|
|
Microbenchmarks are evil. Ya, I said it. Folks spend hours in tight loops measuring things trying to find out the "best way" to do something and forget that while they are changing 5ms between two techniques they've missed the 300ms Database Call or the looming N+1 selects issue that has their ORM quietly making even more database calls. Fun with Microbenchmarks!
|
|
|
|
|
Terrence Dorsey wrote: Folks spend hours in tight loops measuring things trying to find out the "best way" to do something
Really? I mean, really?
In my experience when anyone dares to wonder aloud if a pice of code could be done more efficiently, There's a barrage of an out-of-context "Premature Optimization is the Root of All Evil!" raining down on a poor guy wanting to learn.
They always claim "folks spend hours squeezing useless microseconds." Without even as much as anecdotical evidence. Optimization is the new goto.*
I think this mantra is an excuse to ignore performance questions - because the "first make it run, then make it fast" is based on an assumption that fails on modern hardware: that performance problems are isolated. Wondering if something can be made faster is the best way to demystify the compiler, especially for people who never used low-level languages.
[edit] Oh wait, Scott just had to pull a "I'm not a witch" defense before doing some microoptimizations.
*) which is appropriate only because of the original source of the quote.
|
|
|
|
|
|
There was a time where you could significantly improve the memcpy of the standard libraries. More than one, actually - and sometimes it even did matter.
With the move towards more-RISCiesque instruction timings, looping and unrolling would improve over REP MOVSD especially for large blocks.
With the move to better optimizers, an inlined loop could omit alignment arithmetics, and use SIMD instructions.
So it depends when and what for that guy did it
|
|
|
|
|
|
_beauw_ wrote: So are you saying that on the new Intel chips, REP MOVSx is
actually slower than an unrolled loop?
I honestly don't know for todays processors, but around the early Pentiums, indeed. Some mix of branch prediction, unrolling and instruction pairing I guess. Intel and AMD were throwing their resources on the most frequent instructions, pairing and branch prediction, so the more complex ones had to take a back seat. That's what I meant with the "more RISCIeque" instruction set: improving the throughput for simple instructions.
_beauw_ wrote: By SIMD I presume you mean MMX / SSE / SSE2 / 3DNow! instructions, right?
Yes. And no, REP MOVs is not one of them, though it could be. I got out of assembly stuff at the time SSE was gaining wide support, but - again, IIRC - using MMX to load and store 64 bits at once was like magic.
My point being that if the guy you know is *ahem* not 15 anymore, and he isn't doing that now without good reason, he's not as crazy as it might sound today.
And some habits die hard. I only recently gave up my "file header decorations" that are clearly from the time before source control.
|
|
|
|
|
peterchen wrote: I honestly don't know for todays processors It still is, but the details have changed (non-temporal stores, prefetching hints)
|
|
|
|
|
Pretty soon we'll have people writing video encoders in C# (with LINQ of course), and much bawwwing about how it can't possibly be made any faster without violating the religion of the authors will ensue when people start complaining that it's two orders of magnitude slower than x264.
Or has this already happened?
Huh, optimize cash[sic] usage you say? What does switching the order of these loops have to do with my financials?
What is SSE? Some sort of utility company[^]?
There's also enough wrong with his benchmark that he's ironically right about one thing: some people should not be micro-optimizing.
|
|
|
|
|
One of the fundamental truths of software development is that you have to write code, but one of the biggest fallacies is the idea that writing code is your job. When I first started out as a software developer, I fell into that trap - writing code is a powerful thing, its empowering, you feel like you are productive and you are accomplishing things. However, what I have learned over the years is the real truth of the matter. The truth that the job of a software developer is to write as little code as possible. Other things being equal, a simpler program is better than a more complex one.
|
|
|
|
|
Terrence Dorsey wrote: The truth that the job of a software developer is to write as little code as possible
Is sounds like you need to get a Gov't grant to investigate this most obvious of statements. Where is the icon.
Next they will be telling us that we need to create solution!
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Terrence Dorsey wrote: Other things being equal, a simpler program is better than a more complex one.
That depends on the situation otherwise bubblesort would be the ultimate sorting algorithm. Of course software should be as simple as possible but also as complex as needed. If you need a faster, but more complex algorithm than you should follow the needs and implement it. If it isn't needed use the simplier one.
But before implementing the simplier one better ask: is the simplier one needed or can we use another tool we already have.
------------------------------
Author of Primary ROleplaying SysTem
How do I take my coffee? Black as midnight on a moonless night.
War doesn't determine who's right. War determines who's left.
|
|
|
|
|
Ah, another opportunity to quote this, slide 25[^]:
Can code metrics predict the post release fault rates?
We thought so but...
- Most metrics increase with code size
- code size is repsonsible for all the signal
|
|
|
|
|
JavaScript has gone a long way since its birth in 1995. A hard way for sure, full of misunderstanding, misuse and ignorance. But times have changed, since the last five years JavaScript has been gaining more and more attention. With more attention, more developers are actually using JavaScript, using it for many different purposes and enjoying its beauty. Classical "Ugly Duckling" story, if you ask me. 10 uses for JavaScript that are different from the common "in browser" ones.
|
|
|
|
|
Now that you understand the basic idea behind arithmetic, let's take a look at a simple easy-to-understand example that puts into practice what we just learned... If the authors of computer programming books wrote arithmetic textbooks...
|
|
|
|
|
What would you say if I told you that I could put you in charge of the biggest LEGO set you have ever seen, giving you access to more than 8 trillion blocks. Oh, and you wouldn’t even have to move from your seat? Well, that’s exactly what Google has done. Play with LEGO online, then place your creation on a real Aussie landmark.
|
|
|
|
|
Google scientists created one of the largest neural networks for machine learning by connecting 16,000 computer processors, which they turned loose on the Internet to learn on its own. Presented with 10 million digital images found in YouTube videos, what did Google’s brain do? What millions of humans do with YouTube: looked for cats. The neural network taught itself to recognize cats, which is actually no frivolous activity. In a Big Network of Computers, Evidence of Machine Learning
|
|
|
|
|
*cough*
Some people just never learn.
|
|
|
|
|
We present the first large-scale analysis of hardware failure rates on a million consumer PCs. We find that many failures are neither transient nor independent. Instead, a large portion of hardware induced failures are recurrent... Among our many results, we find that CPU fault rates are correlated with the number of cycles executed, underclocked machines are significantly more reliable than machines running at their rated speed, and laptops are more reliable than desktops. Blue survey of death.
|
|
|
|
|
I love scripting and am quite frustrated by what apps don’t support scripting (or support it poorly). But when I go through my script folder I find that I really don’t have that many scripts. If a big scripting proponent like me doesn’t use scripting nearly as much as he thought what does that say about 90% of people? AppleScript is (almost) dead. Will anyone (except uberdorks) care?
|
|
|
|
|
Are you part of a software development team that's recently moved to GitHub? Where some team members are excited to use git for source control but you're more comfortable with Subversion? The good news is that you can all use the tools you already enjoy - GitHub repositories can be accessed from both Git and Subversion (SVN) clients. Now you can commit without making a commitment.
|
|
|
|
|
Google's simulated human brain trains itself find cats on YouTube[^]
As intelligent as computers continue to get, it's still a lot of work for them to perform tasks many humans do on a regular basis--like, say, enjoying cat videos on YouTube. In an attempt to bridge that gap, scientists from Google's X laboratory created a simulated human brain by putting 16,000 computer processors together and having them browse around the Internet, learning facts about the world as they went. And the simulated human brain successfully found YouTube's cats. ...
|
|
|
|
|
The term Modern Perl can mean a couple of things to different people. Sometimes it means those two different different things to the same people. It depends on context. That’s a joke for the Perl programmers. The definitive Perl book is now up to date with the way that the best Perl programmers now program Perl.
|
|
|
|
|
Bazinga?
Leonardo Paneque
|
|
|
|
|
It's a technical term.
Director of Content Development, The Code Project
|
|
|
|