As I wrote in my previous post, developers need to think about their abilty to surf the technology waves if they plan to remain devs going forward in time. In my 20-something years of working in development, I don't claim to have picked the right waves always - some things which are high on today's hype curve become tomorrow's monochrome monitor - quaint and obsolete.
So you need to take it on faith to some extent that some directions are throughly durable and crucial for the future, no matter what happens. But I have good news on this. Read on.
At this year's Software Enabling Summit, the clarion call continues to be: threading. The inescapable fact of the future is that the hardware we're running on is getting more cores. We have had Hyperthreading Technology for single CPUs for years now, which make your single processor look like two processors to the OS. Today's processors have two complete cores, which formalizes the trend. And no surprise, the trend in the future is for the hardware guys to give us more and more cores.
So what's true today will be more and more true in the future. What used to be the domain of server guys only, is now on our desktops: we now have true SMP (Symmetric Multi Processing) systems to play with. The reasons are simple: the chip guys need to move to multi-core or they wind up with chips that are too hot and take too much power.
Now the server guys have had this fun for more than 20 years in commercial software. I know - I worked at Sequent Computer Systems when we had one of the first commercially-viable SMP systems running with databases like Oracle and Ingres (remember them?). So more cores for them typically doesn't phase them too much.
But the rest of the development world has this interesting question - where do I focus my time? Do I spend it adding yet-another-feature that your customers are screaming for? Or do I carve out enough time to think through the threading issues and solve them? Here's the thing: if you wait to delay the inevitable, it will get to the point where your software is simply not interesting because the new features slow down performance without taking advantage of Moore's Law.
That is of course, the dirty little secret of software development. We usually don't worry so much about performance, because we count on Gordon Moore giving us more performance in every generation. But here's the catch: Moore's Law is about transistors at a given cost level, not about performance per se. Here's the message if you didn't catch it: You can't depend on Moore's Law helping your performance unless you thread your application. Single-thread performance is no longer guaranteed to double every two years.
So having decided to walk into this threading task, where do I go for a next step? Fortunately, the experts at Intel have preparred a whole host of tools, techniques and case studies to help you.
Your knowledge of your code's structure and architecture become really important here. This is totally unlike the task of porting code between operating systems or going from 32 to 64 bits. That stuff can be done by devs who don't really know your code or problem domain, frankly. There are key decisions which need to be made by someone who knows the architecture.
For example, if I thread my code, which threading technology do I choose? Java programmers have at least two threading packages to choose from. C++ and C# coders in the Microsoft have had several threading models to choose from like free threading and apartment threading. Intel has some interesting tools as well for expressing parallelism, like OpenMP and MPI.
Once you have expressed parallelism in your code, how do you check whether you did the threading correctly? This is the huge bugaboo of course for the idea of threading. Everyone has heard stories of the code which the developer thought was correct, but when you add another processor or the timing changes subtly and you wind up with deadlocks or data corruption. Fortunately, Intel is helping here with Thread Correctness and Threading Profiler tools, which are incredibly cool ideas.
Beyond simple correctness, did I choose the right place to parallelize? If I go at too granular a level, all of my performance boost will be eaten up by the overhead of managing synchronization between the threads. At too abstract a level, I won't get any boost either - there is a little thing called Amdahl's Law here which means that the amount of serial code limits the kind of boost you can get from parallelism.
We have tools, for example, like VTune. It will show where your code's hotspots are. But I saw an example at this Summit where making the hotspot parallel was a mistake - it's at too low a level. "You don't want to thread the hot spot, you want to thread the subtree which contains the hotspot." which was a quote from an expert in the room. Good advice. VTune hasa call-graph generator which shows where the subtree is. VTune also has a thread analyzer, which shows you how successful you are at your threading work.
Beyond that, though, you may still need to apply some tricky thinking, again which depends on knowledge of your algorithm. An example was given where work was evenly split between the threads by a simple 1..N distribution of work. But not all of the tasks were of equal size, so there were lots of "idle workers" waiting for something to do. A better approach was to assign the work to free threads in a round-robin manner, which resulted in excellent speedup.
By the way - all of this is really good news for you as a professional developer. Really it is! If the only way to take advantage of the future of computing requires deep knowledge of the algorithm and the problem, then this is a guaranteed future for you as a developer. After all, only you can really make the best decisions here for your software.
I hope you will try out some of these tools. Better than that though, convince yourself that you can become a bullet-proof developer through deciding to embrace the future rather than fight the future.
The opinions in this piece are mine alone and do not reflect the official position of Intel on products or strategies.