I'd like to ask: for anyone here who's ever worked on a large C++ codebase, were assertions ever actually observed to be a noticeable detriment to performance? I'm sort of naively assuming that a good branch predictor would make their impact negligible, but I ain't exactly a system programmer.
That said, the typical large C++ codebase is probably losing a lot more performance to bad algorithms than it is to problems that generally are only measurable in micro-benchmarks. There's just something about C++ that makes a lot of people obsess over performance to a degree that doesn't even affect the mindset of most C hackers. And because your brain is so preoccupied with performance in the small, you often miss opportunities for performance in the large.
Unless, of course, you're a AAA game, in which case you're fine tuning at the individual instruction and cache line levels for your most inner loops. I'm sure there are other, similar use cases for C++, but desktop software probably isn't on that list outside of a key component or two.
I think this is the most important part:
Those micro-optimizations have exactly one place: the most inner loops. Nowhere else! In the larger scale, better algorithms and code readability provide more performance than micro-optimizations ever could.
Interesting observation. My first guess is that it is a lot easier in C++ to hide a stupid bottleneck, for example an object in a function call (which will call a copy constructor). So in the experience of a C++ dev, there are low hanging fruits. On the other hand in pure C it is a lot harder to hide this type of complexity and therefore C optimizations tend to be a lot more subtle.
I've seen math libraries where, for example, the invert-matrix function finishes with an assertion that the input matrix multiplied with the output matrix is the identity matrix. That's a reasonable enough test, but it means when you enable assertions you see a major performance hit.
Now those particular asserts aren't often turned on the default debug build, but turning them on will have a significant effect on performance.
Totally. Strangely enough, Founders at Work (http://www.amazon.com/Founders-Work-Stories-Startups-Problem...) is chock full of startup founders extolling the virtues of overwork. Is this some survivorship bias or does overwork in startups really lead to shipping sooner and achieving product/market fit faster?
It's never been my experience that sustained overwork of software developers leads to actual, measurable productivity increases due to the "two steps forward, one step back" phenomenon. Yeah, you can ship a feature "sooner" but it'll be buggy and disappointing to the end users (probably causing them to hesitate to pay - are you really achieving product/market fit with a buggy product?)
We encourage every developer to find a sustainable pace (it's different for everyone) with the guidance that it's almost always less than 50 hours a week. Why is it that software companies think that overworking software developers is a net positive?
Strategically used, overwork can provide benefit but it sounds like Starcraft was a year-long overwork, which is a disaster. Many of the "Founders at Work" stories glorify overwork and make it sound like it was part of the norm of the culture, so it seems like it was much longer than a few weeks.
Which is why I'm confused - either long-running overwork caused these companies to succeed, or it was not bad enough to cause them to fail?
Computer enthusiast, which are many amongst gamer, are just very eager of this kind of information, discovering it by a game you like that tells you 'check or do that to have a better gaming experience' must be a wonderful and exciting experience.
One idea that struck me: given the classical role of the operating system, doesn't this sound like something an OS should be able to provide?
I imagine an OS service that, if requested, sits in the background and does what that game code did, in order to detect those kinds of errors. Does any OS have this? It really seems semi-obvious, now ...
It seems that in the PC world there is very little functionality in place to detect, isolate, and nail down hardware issues. Or if it exist somewhere deep in the firmware, at least no standardized way to access it.
On the positive side, I was recently very surprised when Linux started to give errors about a certain CPU core after programs started hanging. Somehow one of my cores had failed without crashing the OS(!). After disabling that core in the BIOS with the next reboot the issues went away.
So there is some level of hardware problem detection and robustness in modern OSes, but maybe not enough.
A simple mem test like the article discussed is a nice test, but what if the comparison tables are corrupted? Then it would falsely claim the memory was bad, when it might be the network interface, hard drive, or bus!
if (someBool)
return A;
...
if (!someBool)
return B;
Just a note, he writes:
"Overheating: Computers don’t much like to be hot and malfunction more frequently in those conditions..."
So the piece of code they wrote performing computation and comparing to know good results that could find as much as 1% of broken systems (!!!) would probably not find anywhere near close that number nowadays: the CPU simply slows down if it overheats.
Not sure what happens when GPU overheat and if these too have now built-in protection and not sure if they were trying to detect faulty GPUs too.
Another common "symptom" was an aunt, uncle, friend of parents, calling and explaining that : "my computer works fine for a while then it doesn't work anymore"... And you'd go check their system, open it, and find a CPU full of dust (which TFA mentions).
Nowadays I don't get these calls anymore from those people : they're still using computers, but once their fans get clogged the system simply works at a slower speed and don't overheat anymore.
... at least, that's what my Nvidia GTX580 does!
Also, here's a blog post I wrote on how to get these games working on OSX 10.7+ using Windows builds and Wineskin (shameless plug) http://marzzbar.wordpress.com/2012/11/06/how-to-play-classic...
And great blog post! Thanks for that. I tried using wineskin for Starcraft before but got a little lost. I'll give your walkthrough a try. Sometimes I feel like playing a classic campaign to take a break from laddering on SC2.
In that moment, 2 things are almost certainly true:
1. The bug is in your code. 2. You are too tired/stressed/overfocused to see it.
So when I find myself in this state, I instantly stop working and go for a walk (or go home when its late enough).
Then, when rested, I tackle the problem again. I will find my bug, or, for the very rare case, find a way to prove that it really is the environment my code runs in.
But most importantly, I will have a sharp tool for the job.
http://www.codinghorror.com/blog/2008/03/the-first-rule-of-p...
There's nothing wrong with re-discovering things that other people had written about decades before. But discovering the wisdom of the ancients is also helpful.
A good strategy I have used is that the first job of a new hire is to "make a build machine" on his or her own machine. Just having new eyes go through the steps on a semi-regular basis catches alot of stuff.
On several occasions I've actually left the bugged lines out of my initial submission, because I thought they weren't important...