Comments on: Multicore Programming: The Next Frontier?

By: Cory Isaacson

Cory Isaacson — Sat, 28 Feb 2009 19:46:50 +0000

This article makes very good points, for sure parallel processing and multi-threaded code is a real challenge. There is a new technique, Software Pipelines, which addresses this, taking advantage of multi-core technology without the low-level pain of multi-threaded programming. Using pipelines, service components can be run in parallel, without the service component itself being aware of the runtime environment.

Here is a link to the book I recently published on the subject if you are interested:

http://www.amazon.com/gp/aw/d.html/191-4626580-2453906?ie=UTF8&a=0137137974

By: Daniel Unchalo

Daniel Unchalo — Tue, 10 Feb 2009 17:49:47 +0000

The book “C# 2008 and 2005 threaded prorgamming” is really cool and it has great examples.
Highly recommended to every developer who want to learn multicore programming.

By: Daniel Unchalo

Daniel Unchalo — Wed, 21 Jan 2009 16:29:51 +0000

There is a new book about multicore programming with C# 2005 and 2008, by Packt Publishing. It sounds interesting. Look at this link http://www.packtpub.com/beginners-guide-for-C-sharp-2008-and-2005-threaded-programming/book

It sounds cool.

I’m interested in multicore and parallel programming. I’ll buy the book and I’ll post my coments somewhere.

By: Brian

Brian — Mon, 17 Nov 2008 14:57:42 +0000

[quote]Multicore doesn’t offer better energy efficiency and it doesn’t offer better performance for most applications. So what’s the selling point?[/quote]

Fragrate and frame rate. Megabucks go into improving the KDR (Kill/Death Ratio). This is gaming lingo, but applies to Military operations, and to Wall Street. We use supercomputers because we lack good parallel computers (and the supers are multiple parallel) to modle nuclear implosions and explosions, Wall Street does (and will increasingly) do the same to “milk the cow” (exploit the market) to the critical edge of not killing it.

By: ed

ed — Mon, 17 Nov 2008 00:10:12 +0000

One core is plenty for most applications. But dedicating a core to each application, or at least to some applications, is incredibly inefficient. Data centers are now dealing with that problem. Each server is running at a max of 15% utilization because everyone was afraid to load more than one Microsoft app and OS on a server because it wasn’t as robust as Unix or any of the mainframe or minicomputer OSes. Now they’re resorting to virtualization, which brings its own issues. Just lobbing the challenge to the software programmers isn’t helping. They’ve already concluded over four decades that they can’t solve it.

By: sebastien renaud

sebastien renaud — Fri, 14 Nov 2008 21:07:12 +0000

Really interesting subject, but as always, I fail to understand why people think a paradigm shift ( new programming model/language ) is necessary in order to take advantage of it. Humans think in sequential terms and cores execute in a sequential fashion ( if you abstract the multi-alu / instruction reordering stuff that have been the norm on in SINGLE core processors for a long while ). Bottom line is: I strongly agree with Gene Bushuyev you will always gain from structuring your sequential modules with clean and minimized interfaces. Taking advantages of multiple cores with that kind of code is much easier. I also agree with the fact that some application are more geared towards parallelism than others. However, who really needs to split up Word or Excel? Assuming that 16 cores CPUs are not too far off, a single core for each application seems good enough, no?

By: ed

ed — Fri, 07 Nov 2008 22:16:35 +0000

The bigger issue behind all of this is what’s going to be the impetus to buy new hardware–computers or otherwise–if it doesn’t offer better performance.

Car makers are in a bind now for the same thing. The rising price of gas (even if it has taken a dip, it will go back up) means the real focus is gas mileage. It’s great to step on the accelerator and feel real power, but the biggest selling point is fuel economy. That’s why rental car companies are charging extra money for hybrids.

Multicore doesn’t offer better energy efficiency and it doesn’t offer better performance for most applications. So what’s the selling point?

By: Gene Bushuyev

Gene Bushuyev — Fri, 31 Oct 2008 17:54:29 +0000

The article presents very good observations on both technical and programming challenges facing multi-core development. And if the hardware challenges, like memory performance, bus saturation, etc. may be solved in the near future, software problems will remain. The fact that human brain cannot multitask (medical fact) naturaly leads to software solutions that are sequential. Simply giving software developer a good thread library doesn’t change that, it’s still very hard for a person to reason in asynchronous, parallel manner. That results in software programs that are slow to develop, and debug, and that contain not only logical bugs, but also bugs, related to unpredictable thread counteraction.
On a positive side, working on our own event-driven GBL designer, I’ve found that partitioning a design to modules, which communicate only through signal interfaces and are not coupled otherwise, leads to quite natural parallelization. Event-driven architecture naturally allows a developer to reason about event-response decisions, not about sequential program flow.
Designs that are based on event-driven mechanism show amaizingly loose coupling and can be naturally parallelized without any extra efforts from a programmer.

By: John Gross

John Gross — Sun, 26 Oct 2008 10:08:44 +0000

Peter Robertson hits the nail on the head when he points out that most code that is being written for multi-core assumes a shared memory model, and because this entails use of reference (to avoid gratuitous movement of data), will not work in a distributed memory environment. And since it is generally agreed that the shared memory model is unlikely to scale past 8/16 cores, in about 3 or 4 years time, the industry is looking at another major upheaval.

Connective Logic’s Blueprint toolset provides a means of developing software that works with both memory models. In the shared memory case data is exchanged by reference, but when the same code runs on a cluster the data is transparently moved and cached. When it’s no longer referenced it’s garbage collected. The developer only ever sees a Single Virtual Process and mapping to actual physical processes is achieved using ‘late-accretion’, which does not impact on the ‘application’ code itself (see http://www.connectivelogic.co.uk).

By: Peter Robertson

Peter Robertson — Fri, 24 Oct 2008 10:27:15 +0000

Multicore is not the answer as it fails for at least three reasons.

1: It is hoping to make legacy code run faster by some automatic or semi-automatic
process. The reality is that existing sequential programs are doomed. We either
waste huge amounts of effort in dead ends that restrict progress by forever
looking backwards or we realise that new code written to a better model is what
eventually must dominate.

2: Processor complexity is growing out of control. It is a sad fact that computing
is the only area of engineering where “more complex” is considered “better”.
Multicore is a prime example. Even though a certain complexity is inevitable, it
should also be invisible. It seems that processor designers add new features with
little consideration of their effects on software (or if they do, it’s only for
existing software built to work round existing hardware deficiencies). For example,
should you really need >100 registers to program a transfer on one serial link
(sRIO on TI C6000 processors)? Are there no engineers with the knowledge and
courage to protest about such nonsense when they see it?

3: Multicore is a shared-resource architecture and as such cannot scale. Even if
existing multicore architectures were perfect, the needs of tomorrow will require
greater numbers of processors and we would end up right back where we are now. We
would be forced to add yet another ad hoc mechanism (such as building clusters of
multicores) that would lead us right back to rewriting software.

At some stage we will have no choice but to move to true distributed parallelism that
does not have these built-in limitations. There will still be hardware challenges, but
they and their solutions must not be directly visible to the underlying programming model.

Processors are essentially sequential; parallelism comes from having many of them.
Given this, existing programming languages, even though dreadful in many ways, are
widely known and adequate to express what happens on each processor. All that is needed
is an environment in which explicitly sequential, but independent, components can be
distributed over numerous processors. We would then have a chance that programs written
for such systems would survive and match the faster processors of the future.

Peter S. Robertson
3L Ltd