"Codenamed Kenstfield (Core 2) and Clovertown (Xeon), Intel's new quad-core processors will dramatically increase the amount of processing power you can have in a single system. Given that the Mac Pro features two LGA-771 sockets, you could theoretically drop two Clovertown processors in there and you'd have an 8-core Mac Pro. Without a doubt Apple will release a quad-core version of the Mac Pro, either by the end of this year or early next year, but are users who buy the Mac Pro today missing out? While we're still a couple of months away from being able to test a retail Clovertown CPU in the Mac Pro, we wanted to see if the current engineering samples of the chip would work."
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2005-10-13
Most desktop apps don't even use up a single core at full speed, so there is no reason to make them multithreaded. The only apps that should be are those that are easily parallelized and take huge amounts of computing power like rendering, etc., and apps that have intensive tasks that can block the UI for a while. These are often I/O bound activities since a lot can be done very quickly in the cpu.
Sure, you could make Notepad multithreaded, but what is the point? This way you can run 8 seperate apps and they each get their own core instead of running 8 apps with 100 threads all vying for attention on 8 cores.
Member since:2005-07-06
You're thinking too much like an engineer and too little like a sales guy. While your point is correct, I can see many companies adding multithreating to their apps simply so they can brag about it in their sales litterature. Sure it will add bugs, but it will also let you sell more uppgrades to people who don't really understand the pros and cons of multithreading.
Member since:2005-07-06
Most desktop apps don't even use up a single core at full speed, so there is no reason to make them multithreaded. The only apps that should be are those that are easily parallelized and take huge amounts of computing power like rendering, etc., and apps that have intensive tasks that can block the UI for a while. These are often I/O bound activities since a lot can be done very quickly in the cpu.
Oh, au contraire.
If the routine that you need to call is, essentially, more expensive than the creation of the thread, and can run independently (i.e. it's doesn't have to stall while waiting on some other component), then why the heck not fork a thread and run it in parallel?
There's obviously some reasonable level of granularity where this will occur, but with mutli-core machines becoming more common, multi-threaded operations gain just that much more over not using them.
Because now, even for small tasks, you get the benefit of code running simultaneously, and your code performance scales far faster than a single CPU.
That means, in this example, IDEs can now be more responsive. There's no reason that you have to only thread CPU intensive tasks. If I have a single meta task that requires, say, 4 independent steps, and those steps are expensive enough to warrant threading, then I'm going to get those 4 steps done twice as fast on a 2 core machine, and 4 times as fast on a 4 core machine. Regardless of clock rate.
Certainly multi-threaded programming is more difficult than single threaded programming. Threads have their own overhead that boils all the way down in to the kernels scheduler. You have to deal with synchronization issues, etc.
But, before, when the predominant machine was a single core design, the only reason to create a thread was for the potential abstraction benefits they provide, or simply to get "background" processing.
Now with multi-core machines becoming generally available and common, there is a pure performance motivation above and beyond the other benefits of threads.
Multi-core machines will make everyday programs perform better in the future as developers begin to adopt and leverage the architecture more and more.
Member since:
2005-07-24
> Even something like a modern IDE can take advantage of multiple cores. One thread for handling keyboard input, one handling syntax formatting, one handling autocompletion, one compiling your code in the background, etc.
And ten extra developers per thread to debug the new, hugely complicated app that has problems that no one can seem to figure out.
Get ready for the buggiest software in computing history, courtesy of Intel's and AMD's need for a new marketting strategy to sell us new processors.
Personally, I think that while you can come up with places that multicore can help desktop performance, most desktops apps don't really lend themselves to multi-threading. You're going to end up with one thread doing the work, and all the other (7?) threads just doing a bit here and there that the user will never notice... until the app crashes due to some synchronization problem.
What I really don't understand is why people here, who should know better, are seemingly just eating this multi-core marketting propaganda up, uncritically.
Edited 2006-09-13 23:26