Introduction
With Intel set to launch its P4 dualies on the world at NAB 2001, it seems appropriate to catch up on AMD's 760MP, and then to move on from the subject for now.
The AMD 760MP - It's not out in stores yet. I have some information of sorts from WinHEC, but no product. Soon, but not soon enough. Well, that should make for a short column. Ain't you just a tad glad?
But, before we get to the 760MP I have a couple of things I need to get off my chest - threads. Indulge me, and let me drone on about what threads are, and some low order parallelism. I got such a bewildering array of commentary about multi-threaded applications that I feel like patronizing some of you. And just to show that I am not all pretentious Latin waffle, I will use Geekperanto, the universal language of Nerdism. As if that wasn't enough, I'm also going to take a little circuitous rant through the background of multi-CPU systems, and where this whole dualie thing, gosh darn it, got started. Then, some 760MP, and then, we can move on from dualie world, and join the land of the uniprocessored.
Okay, now there you have it in clear English, the tortuous path of my prose for this week. Is there anything to stop the bar chart addict from turning back right now? No, there isn't.
Parallelism
Creating a parallel program is not an easy task, and while bathing in the glow of healthy dualie debate, it occurred to me that with the exception of some of you more code warriorish types, there was some befuddlement going on when it comes to parallelism, which is what dualism is all about, right?
With an SMP system, you are probably dealing with the most basic of parallel systems. So, let's look at it from the point of view of the programmer. The programmer has an application, and he has identified a task within that program. In fact, the programmer has broken down the application into a number of defined tasks. Then, the programmer breaks down each task into a series of threads.
Point of order for code warriors- I am simplifying things here, and not going into an in-depth discussion differentiating processes, lightweight, heavyweight, and threads. It's not really a programming course, but should give everyone some grounding for the transaction coherency features of the 760MP, coming up later, after my self-indulgence.
So, what is computing if not read, write, fetch data, for the most part. No different for each thread in an application. Now, if you have threads in the operating system then it's pretty cool because, what you can do is have one thread working while another thread is delayed (waiting for an I/O port, perhaps) so, even in a uniprocessor environment, supporting multiple threads is a good way of handling concurrent operations. In an SMP system, for an application that is specifically optimized to run on multiple processors, one should assume that threads - reading, writing, fetching data - may actually be working on the same data, or be relying on the same set of variables as other threads, therefore requiring their CPU to be in contention for piece of memory with other threads' CPUs.
The CPU is just the physical place where the threads do their work.