Simplicity's cunning deceit
The order in which you place your source lines will dictate how your application runs, and generally how well it works. Would you agree?
While it's correct per se, reality isn't quite as simple as one could mistakenly assume.
The basis for this claim is the complexity that is the computer you are sitting by. CPU, memory, pipelines and cache. It's an intricate collection intricate components. What this means for you, the programmer, is that you place your faith in those who've put it all together. And let's get just one thing into the open: they are doing a good job. Making this complex machinery work as you'd expect it to, even given code of (to say the least) varying quality, is truly an accomplishment. Obviously it's not just the merit of the hardware designers. Compiler programmers (among others) also deserve their moment of glory. You can do just about anything, in just about any order and fashion you see fit, and the compiler will find a way to optimize it. Sure; it breaks down occasionally, and there are bugs, but you produce your fair share of those as well.
One specific area of programming isn't quite that trivial. This may very well be where the most responsibility is placed upon the programmer, but it is also an area where compiler-, OS- and hardware designers spend much of their time "Making Your Crap Just Work". What field? Multi-threading, of course.
Usually, you just slap a few mutexes here and there, and it just works. Brillant. That's often the one and only advice you'll get when you move into threading; mutexes. With lower level languages, like C++ , it's not always enough, though. There are many perils you need to acquaint yourself with. Shared memory access. The order of said access. Instruction reorderings. Cache coherency. There's a lot of material to cover, and I suggest you take the time to familiarize yourself with it by reading through the articles listed below.
Posts
0 kommentarer:
Post a Comment