[Veltliner]

It is great to read, that an 8-core MacPro is about to be officially announced.

I just wonder: to take advantage of multi-core processing, the software has to be able to keep multiple cores busy at the same time.

Do software developers have to completely rewrite software to make it ble to take advantage of multiple cores?

I wonder if current Final Cut Pro and other Mac software can already take advantage of multiple cores, or if this new MacPro would not have the "software-fuel" at this time to run at its best?

[Blasphemy]

I believe a lot of apple's software, such as itunes, quicktime pro, imovie, iDVD, etc., take advantage of multi-processors and multiple cores.

[CatOne]

Given that Macs have been shipping with multiple CPUs since 1997 or so, and writing software for multiple CPUs is exactly the same as writing it for multi-core CPUs (it's the same thing), code that has multiple threads and runs optimally on multiple CPUs is already out there, most everywhere.

[pyrite]

Originally Posted by Veltliner 

It is great to read, that an 8-core MacPro is about to be officially announced.

I just wonder: to take advantage of multi-core processing, the software has to be able to keep multiple cores busy at the same time.

Do software developers have to completely rewrite software to make it ble to take advantage of multiple cores?

I wonder if current Final Cut Pro and other Mac software can already take advantage of multiple cores, or if this new MacPro would not have the "software-fuel" at this time to run at its best?

does current mac software take advantage of multiple cores? yes. 8 cores? no, not really.. as you suspect, it does have to be specifically coded to distribute load amongst multiple threads.

coding apps for multiples cores/processors has been around for a while, but not to the extent of 8 threads per app, this is a direction i'm hoping more developers will take, it's clearly the future of hardware. something like Pro Tools optimized for 8+ threads would be amazing, but hardly any software will even support 4 threads atm.

with an 8 core mac pro on the horizon, surely mac software will start exploiting multi-core to a greater extent in the near future

[msuper69]

Even if an app is not multi-threaded, with 8 cpus, you can run 8 of them. Not too shabby.

[CatOne]

Originally Posted by pyrite 

does current mac software take advantage of multiple cores? yes. 8 cores? no, not really.. as you suspect, it does have to be specifically coded to distribute load amongst multiple threads.

coding apps for multiples cores/processors has been around for a while, but not to the extent of 8 threads per app, this is a direction i'm hoping more developers will take, it's clearly the future of hardware. something like Pro Tools optimized for 8+ threads would be amazing, but hardly any software will even support 4 threads atm.

with an 8 core mac pro on the horizon, surely mac software will start exploiting multi-core to a greater extent in the near future

Spawning 2 threads is the same as spawning 20. The tough part is writing thread-safe code and then creating the threads to let the app go its own way.

I suspect is is very, very unusual to code an app assuming 2 CPUs. I've written a couple "thread hot" applications and this never entered my mind. You create a thread pool or whatever, creating enough threads to make sense for your application (multi-threading even makes sense on a single CPU machine), and then let it go. So these apps will run better on a 2 CPU machine or an 8 CPU machine... there's no difference. And from an application POV, typically you want a UI thread and a processing thread... maybe a few processing threads if it's something you can parallelize.

[Chuckit]

Originally Posted by CatOne 

You create a thread pool or whatever, creating enough threads to make sense for your application (multi-threading even makes sense on a single CPU machine)

In cases where threading is an optimization rather than a requirement, I don't think this is true. Threading in these cases should actually be slightly slower on a single-CPU machine because you don't get any actual simultaneous processing but you do get some overhead from thread creation.

[mac128k-1984]

I wonder how many cores is too many. There's got to come a point where having so many cpus matters little to most of the apps, that is the processing needs of the application does not reach the processing potential of the multiple cpus

Even now, with my MacPro the majority of the time, only 1 or 2 cpus are being used heavily, I've yet to see 4 cpus being pegged over 80%. Now that's not to say there isn't a need but as the number of cpus increase on a given die, that need shrinks at somepoint it makes little sense. Is it 8 cores, 16, 32?

[Gossamer]

How about 80?

[Catfish_Man]

Originally Posted by mac128k-1984 

I wonder how many cores is too many. There's got to come a point where having so many cpus matters little to most of the apps, that is the processing needs of the application does not reach the processing potential of the multiple cpus

Amdahl's law - Wikipedia, the free encyclopedia

[mac128k-1984]

Wow, that's like way over my head

[mduell]

Originally Posted by mac128k-1984 

I wonder how many cores is too many. There's got to come a point where having so many cpus matters little to most of the apps, that is the processing needs of the application does not reach the processing potential of the multiple cpus

Even now, with my MacPro the majority of the time, only 1 or 2 cpus are being used heavily, I've yet to see 4 cpus being pegged over 80%. Now that's not to say there isn't a need but as the number of cpus increase on a given die, that need shrinks at somepoint it makes little sense. Is it 8 cores, 16, 32?

A couple months ago some Intel exec said they saw the sweetspot between 10 and 100.

With the software I use today, I could see 12-20 cores being useful. But I'm sure that figure will increase over the next few years.

[mac128k-1984]

Originally Posted by mduell 

A couple months ago some Intel exec said they saw the sweetspot between 10 and 100.

Of course he'd say that, he's in the business of selling cpus.

With the software I use today, I could see 12-20 cores being useful. But I'm sure that figure will increase over the next few years.

Really, what software is that? Clearly there is applications that can take advantage but I don't think there's too many apps that could use more then 4.

As others have quoted the application has to be written in such a way that has multiple threads that can execute independently and the ability to carve up an application into a number of threads where an 8 core computer can run seems to me pretty tough.

[Chuckit]

Originally Posted by mduell 

A couple months ago some Intel exec said they saw the sweetspot between 10 and 100.

With the software I use today, I could see 12-20 cores being useful. But I'm sure that figure will increase over the next few years.

Seriously, you routinely use an application that could max out 20 CPUs?

I somehow doubt that's true of most people, anyway.

[mduell]

Originally Posted by mac128k-1984 

Of course he'd say that, he's in the business of selling cpus.

Really, what software is that? Clearly there is applications that can take advantage but I don't think there's too many apps that could use more then 4.

As others have quoted the application has to be written in such a way that has multiple threads that can execute independently and the ability to carve up an application into a number of threads where an 8 core computer can run seems to me pretty tough.

Originally Posted by Chuckit 

Seriously, you routinely use an application that could max out 20 CPUs?

The point of the quote was that the folks in command of do see a practical limit to the number of cores for desktops; 100-1000 core general purpose chips aren't on the roadmap at Intel.

It's no one piece of software; both of you seem to have the idea that if one app can't use all the cores, the rest are wasted. The reality of modern computing (at least for me) is that my machine has a lot going on at the same time. Remember back to the days when you couldn't do anything else when burning a CD? Nowadays it's not uncommon to be rendering, encoding, burning a DVD, and playing a game while you wait for the rest to finish. I routinely have 5-20 applications running, at least a few of which are multithreaded and doing some processing in the background.

If your app has 4 threads today, it's unlikely that it's impossible for it to have 8, or 16, or 100. Does the performance scale linearly? Hell no. Are you still going to see better performance? Yes, along with better responsiveness due to free resources.

[FireWire]

Would it be hard for Apple to rewrite the kernel in order to do this automatically, like the BeOS did? It is my understanding that apps written for the BeOS had nothing particular to do to take advantage of multiple CPUs: the OS did everything itself.

Beside, could a programmer explain briefly what the procedure is to spawn multiple thread? My programming knowledge is limited and I can't figure out the complexity of spawning multiple threads.

[Edit] By looking at the output of the top command, it seems that many apps already make use of many threads, unless the #THread column doesn't represent the same thing..

[Chuckit]

Originally Posted by FireWire 

Would it be hard for Apple to rewrite the kernel in order to do this automatically, like the BeOS did? It is my understanding that apps written for the BeOS had nothing particular to do to take advantage of multiple CPUs: the OS did everything itself.

I don't know the technical details of BeOS, but I doubt it was any more true there than it is on OS X. Probably the system libraries were written to use multithreading wherever possible, which is exactly what Apple is doing these days.

Originally Posted by FireWire 

Beside, could a programmer explain briefly what the procedure is to spawn multiple thread? My programming knowledge is limited and I can't figure out the complexity of spawning multiple threads.

Spawning multiple threads is a lot more difficult than just writing normal code, because it creates all sorts of concurrency issues that just don't come up otherwise (e.g., one thread might be reading a variable at the same time another thread is writing to it).

But that's not the real reason people don't use threads more. The reason you can't just take any app and use threads to get mad speed increases is because not all code lends itself to threading. You have to be able to divide your program into several discrete tasks, none of which depend on each other. If one part of your program needs to complete before another can run, there's no point in threads because the parts can't run simultaneously anyway. Programs like renderers that need to perform an operation on many different pieces of data are good candidates for this; other programs, not necessarily so much.

[P]

Many apps are multithreaded today, but the problem is that the Cocoa Appkit isn't threadsafe, so the entire UI must be run off one thread if it is uses Cocoa. In practise, this becomes the main thread and any other require very little CPU time.

Carbon doesn't have this problem.

[Catfish_Man]

Originally Posted by FireWire 

Would it be hard for Apple to rewrite the kernel in order to do this automatically, like the BeOS did? It is my understanding that apps written for the BeOS had nothing particular to do to take advantage of multiple CPUs: the OS did everything itself.

BeOS did not do this. As far as anyone has been able to figure out so far it would require a better-than-human-level AI in the kernel.

Beside, could a programmer explain briefly what the procedure is to spawn multiple thread? My programming knowledge is limited and I can't figure out the complexity of spawning multiple threads.

The difficulty is in several areas. Here's a brief sampling:
1) As soon as you introduce another thread that is modifying any resource shared between threads, you suddenly have to work under the assumption that any shared resource can be modified at any time, unless *all* writes to it are locked, or unless you really understand which parts of the code may be running simultaneously and under what situations they modify each variable.
2) If you attempt to beat 1 by sprinkling locks around overenthusiastically, you run into the fact that each locked section is a non-parallel part of the program, so Amdahl's Law quickly kills your performance gain.
3) If a thread holding a lock needs to wait for a resource, the thread that provides that resource may get stuck waiting for the held lock. Result: spinning beachball until the app is killed.
4) Many algorithms inherently require data from the previous step to be able to run the next step. These cannot be run in parallel.

[Edit] By looking at the output of the top command, it seems that many apps already make use of many threads, unless the #THread column doesn't represent the same thing..

Most of those threads are not doing useful work (sleeping waiting for IO, running an infrequent background task, etc...).

[P]

Originally Posted by FireWire 

Would it be hard for Apple to rewrite the kernel in order to do this automatically, like the BeOS did? It is my understanding that apps written for the BeOS had nothing particular to do to take advantage of multiple CPUs: the OS did everything itself.

I think what BeOS did was to make the APIs fully threadsafe and then write the code in those libs so that it spawned new threads for many common tasks and then make sure that the threads running the interface had a higher priority so that the OS seemed responsive. Can Apple do that? Yes, by making a new API. It won't happen for all the old Cocoa apps.

[mduell]

Originally Posted by FireWire 

Would it be hard for Apple to rewrite the kernel in order to do this automatically, like the BeOS did? It is my understanding that apps written for the BeOS had nothing particular to do to take advantage of multiple CPUs: the OS did everything itself.

I saw a rumor less than a week ago that Apple had done this for Leopard... now if I could only find the rumor.

[CatOne]

Originally Posted by mduell 

I saw a rumor less than a week ago that Apple had done this for Leopard... now if I could only find the rumor.

I don't see how it's possible.

[Millennium]

Originally Posted by Veltliner 

I just wonder: to take advantage of multi-core processing, the software has to be able to keep multiple cores busy at the same time.

Do software developers have to completely rewrite software to make it ble to take advantage of multiple cores?

Ultimately somebody does, yes. However, Apple has been pretty good about rewriting core parts of the OS to take advantage of multiprocessing (whether through multiple chips or a single multi-core chip or some combination of the two). By doing so, they provide a boost to all applications which use those parts of the OS.

Some applications can and should make changes particular to themselves, to take further advantage of multiprocessing. That's coming more slowly, because although taking advantage of multiprocessing doesn't necessarily have to be difficult, it requires a somewhat different way of thinking than many programmers are used to.

[Catfish_Man]

Originally Posted by mduell 

I saw a rumor less than a week ago that Apple had done this for Leopard... now if I could only find the rumor.

I saw a rumor that Apple had figured out how to manipulate time, and is planning on releasing the iSleep to get everyone an extra hour of sleep before work.

[mduell]

It was originally posted at MacOSRumors (who have a terrible track record), but their site is broken.

Mac on Intel paraphrased it:
For an application to take advantage of all that mult-core goodness, it needs to be well threaded. Yet, many apps out there are unthreaded or poorly threaded. It's Apple and Intel and Mac OS X v10.5 "Lepoard" to the rescue.

According to Mac OS Rumors, Leopard, which is expected to be unveiled at August's World Wide Developers Conference, is expected to contain code co-developed with Intel that helps break up tasks into multiple threads, allowing them to better utilize these new multi-core systems. At present, it's the very rare applicaion that benefits at all from more than four processor cores. Diminishing returns. According to the article, this new thread splitting code allows standard applications to take full benefit of 16 cores, each core getting an approximately equal slice of the work at hand. The effect works nearly as well for 32 cores.

[Catfish_Man]

At best MOSR is drastically misinterpreting real data. More likely though, they're doing their usual thing, which is making up less believable and less funny stuff than Crazy Apple Rumors Site.

Not that there aren't perfectly legit techniques for increasing parallelism (runahead threads, behind the scenes threading in system APIs, etc...), they just aren't magic pixie dust like MOSR seems to think.

[Veltliner]

Would there be some type of software, that lended itself more to multi-threading than other?

An editing program for example, like FinalCutPro. How would "the work" be given to the different cores?

Divide every frame into several work zones across the whole clip?

Or give one frame to the first core, the second to the second core... and so on, and after the eight frame to the eight core the ninth frame would be given to the first core again - like domino?

Or is multi-threading rather for number crunching?

I hope not. HD video and multimedia applications could use a speed boost.

[Catfish_Man]

Originally Posted by Veltliner 

Would there be some type of software, that lended itself more to multi-threading than other?

Very much so. 3D rendering is one that's great for multithreading.

An editing program for example, like FinalCutPro. How would "the work" be given to the different cores?

Divide every frame into several work zones across the whole clip?

Or give one frame to the first core, the second to the second core... and so on, and after the eight frame to the eight core the ninth frame would be given to the first core again - like domino?

One issue you run into with video is that frames often depend on the ones that came before them. That said, I'm betting there are plenty of opportunities for parallelism in Final Cut*, and I'm sure Apple already takes advantage of them.

*for example a relatively primitive way of parallelizing effects would be to take the whole chunk of frames between each keyframe and assign it to a processor to render effects on, since afaik keyframes shouldn't have dependencies**.

**note: IANAVCE (I Am Not A Video Codec Expert), I may be wrong about keyframes

[CatOne]

Originally Posted by Veltliner 

Would there be some type of software, that lended itself more to multi-threading than other?

An editing program for example, like FinalCutPro. How would "the work" be given to the different cores?

Divide every frame into several work zones across the whole clip?

Or give one frame to the first core, the second to the second core... and so on, and after the eight frame to the eight core the ninth frame would be given to the first core again - like domino?

Or is multi-threading rather for number crunching?

I hope not. HD video and multimedia applications could use a speed boost.

Absolutely some types of software lend themselves to multithreading better than others. The key is that, to get optimal performance, threads must be independent... there cannot be dependencies between the things that are going on.

Let's take a simple example (and in large part forget about algorithms, because for example if you want to add the numbers 1 to 1000 the answer is actually 1000*1001/2 ;-) Anyway, so let's say we want to add the numbers 1 to 1000. One way is just to add 1+2+3+4+...1000. This will take 1000 add operations. This takes a while.

Another option is to break the task down into chunks. Let's say you create 10 "threads," and one adds the numbers 1 through 100. The next 101 through 200. And so on, the final one doing 901 through 1000. Then you add them all together. Assuming that happens fully in parallel, you only have to do 110 operations (the 10, plus then adding the results of all 10). Roughly 10 times faster. Very parallelizable.

Video tends to be the same way -- if you apply an effect to a 10 minute clip... no reason you can't do it largely in parallel... as you can chop up the clip, do the effects, and you end up with one modified clip.

Now some things do NOT lend themselves to parallelization so much... if you have threads that actually DEPEND on each other, then one thread has to stop and wait for another thread to produce a specific result before it can continue. This reduces efficiency a lot... I think in general if you get > say 75% efficiency (say you add 4 CPUs, and it's 3x as fast), you're doing quite well. The trend tends to be pretty efficient for 2 CPUs, and usually drops off for > 4 CPUs as it's tough to divide work into segments that are all truly independent.

Interestingly, what's true about threads is also true in some way about multi-machine parallelization. Where instead of using one machine with lots of CPUs to solve a problem, you use lots of machines instead, and share memory spaces between them. This is how Apple's > 1000 node "Supercomputer" at Virginia Tech works. It's very very good at solving a few very specific kinds of problems, those that are VERY parallelizable.