macOS Any programmers here taking advantage of multi-core technology?

[atlanticza]

So clock speeds haven't advanced much, but multi-core technology has. But there appears to be very few programs that exploit it (a spellchecker won't operate 4 times faster on a quad-core, for example).

So are there any gurus here exploiting this technology and what programs do take advantage of it (or is parallel programming mainly academic at the moment).

 

[jiminaus]

Parallel programming in increasing moving out of academia into the mainstream because of the reason you say. The future is not in faster cores, but more of them.

Why can't a spellchecker be multithreaded? Each thread takes on a chunk of the document. Or one thread takes on parsing, one thread takes on grammatical analysis, one thread takes on correction search. Perhaps not a 4x speed improvement, but it would be an improvement none the less.

There's lots of opportunity for parallelism that the average program won't think of, because their mental kit doesn't include parallel techniques. In fact, their mental kit will problem have a stick on it saying something like "beware of multiple threads! beware of the pitfalls!".

Programmers have to get used to multithreading and to start thinking in terms of multithreading. Similarly to how we had to start getting used to objects and to start thinking in objects.

 

[Nermal]

There's lots of opportunity for parallelism that the average program won't think of, because their mental kit doesn't include parallel techniques. In fact, their mental kit will problem have a stick on it saying something like "beware of multiple threads! beware of the pitfalls!".

There's a lot of truth there; I only have one app with multithreading and that's because the process in question took a couple of minutes to run. Typically I don't even think about using multithreading.

 

[jiminaus]

I only have one app with multithreading and that's because the process in question took a couple of minutes to run.

That kind of performance issue was and will remain the driver for multithreading. Even with Grand Central Dispatch, multithreading still have pitfalls.

I think right now, the smart programming isn't introducing multithreading, just because he can. But he will definitely have an eye towards multithreading when his setting up architectures/designs.

 

[subsonix]

First you need to have a "performance problem" for it to make sense at all. Why add complexity to an application that runs well within CPU margins on one core? I have used it to avoid locking up the main thread while waiting for some event, but never to parallelize computation to get better performance.

 

[xStep]

More people are learning about the advantages and Apple has made it somewhat easier. One app that is used by millions is about to see a boost. Apple is suppose to release Final Cut Pro X this month. It is expected to fully take advantage of multiple processors, the GPU and threads. It will be interesting to see the performance and how editors manage to test and take advantage of it.

Recently I was working on an iOS app that did some complicated drawing via touches. While rendering it would block the main thread and therefore the touch input count was low. I off loaded the rendering to a thread and gained back several more capture points. This was on an iPod touch which only has one processor. Still taking advantage of multi threading helped me gain more capture points and give more responsive feedback.

 

[MorphingDragon]

I do multi-threading for anything that isn't tied to the UI in programs. Unless I'm experimenting or trying to design an algorithm and need maximum feedback. You pretty much need to know if you're doing game programming.

I found using C# Threads and BackgroundWorker was a good intro. C# abstracts threads a nice high level and teaches thread safety well.

What we really need to wait for Implicit Parallelism though. The idea of programming in rules and relationships instead of statements, sequences and procedures and marking keypoints with timestamps. Sort of like building entire programs in SQL or LinQ (Its a Bad example but its the closest I can think of). JStar is an example of one of these programming languages.

 

[gnasher729]

So clock speeds haven't advanced much, but multi-core technology has. But there appears to be very few programs that exploit it (a spellchecker won't operate 4 times faster on a quad-core, for example).

So are there any gurus here exploiting this technology and what programs do take advantage of it (or is parallel programming mainly academic at the moment).

You don't have to be a guru, as long as you are happy with your application requiring Snow Leopard or better. Go to developer.apple.com, search for "blocks". Running stuff in separate threads with blocks is absolutely trivial.

 

[robbieduncan]

I have written stuff at work at automatically uses more CPUs are they become available. Move from a 2 CPU server to a 16 CPU server (which we did last year) and it automatically spreads the processing load for our overnight batch runs without reconfiguration or issue. It's able to sustain about 80% CPU usage across all 16 CPUs quite happily.

 

[subsonix]

That sounds very similar to what Grand Central Dispatch does.

 

[robbieduncan]

That sounds very similar to what Grand Central Dispatch does.

Yes. I am using the Java Concurrency APIs instead of GCD (which is not available in our non-Apple environment) but the end result is similar: a centralised queue structure to which tasks are assigned. The centralised system reads tasks off the queue and executes on an available thread and the results are returned to the correct place at the end of task execution. As long as you can break your total work down into sensibly sized chunks to submit as tasks it scales very well.

 

[danwilliams]

At my work we have a image processing library written in C/C++. We use http://en.wikipedia.org/wiki/OpenMP. Once you locate your bottlenecks in your code, it is trivial to "multi-thread" a loop (assuming the loop can be multi-threaded).

Note that our library runs on multiple platforms. However, we have started to look at http://en.wikipedia.org/wiki/Opencl to help speed up our algorithms.

 

[mobilehaathi]

Parallel computing has been around for decades.

I wouldn't call myself a guru, but I multi-thread my code quite often. I don't, however, write consumer apps. All my coding is for simulations for my research.

If you open up Activity Monitor and look at the Threads column, you'll see many applications that spawn multiple threads, each of which can be concurrently executed on different cores (I won't get into threads blocking each other).

 

[SidBala]

I used to work for a lab that produced ultrasound visualization software. I used multi-threading very heavily. Almost all of our projects also use gpu computation. Infact, we did gpu computation even before gpgpu libraries like CUDA and openCL existed.

It makes a lot of sense if you are dealing with high performance code. But for other stuff, it is probably not worth the effort. A spell checker can very easily be multi-threaded. But even singly threaded, it might take less than half a second to execute. So it doest make sense to develop code that runs even faster when it already is very fast.

 

[kainjow]

I maintain(ed) an image converter program and moved it to GCD a while back. Saw some very nice consistent performance improvements, even when I had only tested it on a dual-core system.

 

[mif]

I use pthreads (x16) on ray-tracing. Supersample-anti-aliasing may be the next candidate for threading for me.

 

[holmesf]

So clock speeds haven't advanced much, but multi-core technology has. But there appears to be very few programs that exploit it (a spellchecker won't operate 4 times faster on a quad-core, for example).

So are there any gurus here exploiting this technology and what programs do take advantage of it (or is parallel programming mainly academic at the moment).

Single threaded performance is indeed plateauing. While it used to improve 100% every 1.5 years, now we're seeing 30%, and soon improvements will be negligible. The real paradigm shift will happen when the power wall starts prompting chip producers to actually decrease single threaded performance. This is bound to happen eventually because large out of order superscalar cores are not the most effective use of transistors or power.

Anyway, programmers hate parallel programming because it's wrought with challenges. Deadlock can occur when when there are circular dependencies which block threads from making forward progress (it happens all the time during development). Race conditions may occur when correct program behavior depends on the order in which threads execute (again, happens all the time). Even worse, these problems are hard to find because once you multithread an application execution becomes essentially non-deterministic. So far there are no adequate technologies that can address these problems.

There's been some nice recent trends, however, in parallel programming. OpenCL allows you to do parallel programming on the CPU or GPU in a way that will automatically scale in the future as hardware manufacturers add more cores. Grand Central Dispatch also automatically scales to use the correct number of threads for the system it is running on, and it makes parallel programming easier to do (compared to say pthreads) by enhancing the C programming language.

I'm very excited to start using Grand Central Dispatch on iOS, because I really expect future ARM designs to really pack on more cores rather than increasing single core performance much. The iPad 2 is of course dual core, and we can expect the next iPad to be 4 core (at least, if it wants to be competitive in that respect).

 

[holmesf]

I use pthreads (x16) on ray-tracing. Supersample-anti-aliasing may be the next candidate for threading for me.

You should try out Grand Central Dispatch on your ray tracer. Break up the rendering into square blocks. Then you can have GCD scale to the correct number of threads for the system automatically. Additional advantage: by breaking rendering up into square blocks and feeding the blocks to GCD queues it will automatically load balance the rendering for you. Second additional advantage: small square blocks are more friendly on the CPU cache.

 

[jiminaus]

Anyway, programmers hate parallel programming because it's wrought with challenges. Deadlock can occur when when there are circular dependencies which block threads from making forward progress (it happens all the time during development). Race conditions may occur when correct program behavior depends on the order in which threads execute (again, happens all the time). Even worse, these problems are hard to find because once you multithread an application execution becomes essentially non-deterministic. So far there are no adequate technologies that can address these problems.

I'm betting Apple's going to change that. I'm betting there going to do to multithreading like they did to thread management with GCD and they're doing to memory management with ARC.

But lots of pitfalls can be avoided now by using higher-level tools then the typical C programmer has. Things like multithreaded architectures and design patterns, multithreaded language support, and a multithreaded culture. Many of the common pitfalls are avoided in Ada because of these.

BTW By multithreaded architectures and design patterns, I don't mean building in parallelism, but architecting and designing the pieces to play well in parallel, particularly thread-interface design.

 

[mif]

Thanks, those are definitely improvements. I sliced the picture vertically and used the old multiprosessing services api to get the number of scheduled prosessors.