> can you explain what a "thread" is in an application please?
A thread is a "path of execution" within a program. In the old days, a CPU had one execution core, and a computer had one CPU. All programs were single threaded. For example, a program would execute step A followed by step B followed by step C, etc.
With the advent of multiple CPU computers, or multiple core CPUs, this resulted in a problem. The single execution path (A->B->C->etc) path would only execute on one CPU or one core leaving the others to sit idle. Background tasks in the OS would be able to utilize the idle CPU, but these tasks are small and don't take up much CPU resources. The extra CPUs/cores were basically wasted. If you ever watched the CPU utilization graphs in windows on a multi-core system, you see one CPU near 100% and the other near 0%. They may flip back and forth, or they may both go to 50%, but you almost never see both at 100%.
A good example to use to show the difference is loading a web page. In the single threaded model, you load the page, then you load the first image, then load the next image, etc, then finally you render the page. In a multi-threaded model, you load the page, then you spawn a bunch of threads to load all of the images at the same time, then once all the threads are done, you render the page.
To allow programs to utilize multiple CPUs/cores at the same time, threading was invented. A single program can now create multiple threads (execution paths) that run at the same time. So now, you might have A->B,B,B,B,B->C,etc where B are threads that can run on any number of available CPUs or cores. In a quake like game, B might be the code that controls how each enemy unit behaves.
Unfortunately, threaded code is very difficult to write and even harder to debug. Because of this, most programs are still single threaded. Some applications, such as video encoding, are very easy to thread (due to the nature of the task). As multi-core CPUs become more common, you will start to see more and more threaded applications, limited by the complexity of writing threaded code. (Apple came up with a very clever system to make writing threaded code extremely easy called Grand Central Dispatch that utilized run queues and 'blocks' rather than traditional threads.)
When we take the above back to dual vs quad cores... if your application is single threaded, which almost all of them are, then it doesn't matter if you have two cores or four cores, you are only going to utilize one of them. At that point, the chip with the faster cores will win... and dual cores are always faster than quad cores, per core, at a given price point.
-------------------- Just another spore in the wind.
|