Le 18/01/2011 16:16, Invisible nous fit lire :
> As far as computer programming is concerned, writing programs which
> aren't single-threaded is a "hard problem". Oh, it depends on the task
> of course. But many programs are just really awkward to write in a way
> that utilises multiple cores.

Multiple jobs|tasks is a concept available to your desktop since 1984 (I
do not speak of mainframe) on an English home computer.
(single core, time slicing scheduler in the kernel)

Yet many programmers have still issue with a single program and its
sequential calls in Functional Programming.

And sometime the specifications themselves are just sequential.

And sometimes people have trouble with synchronisation & protection
mechanisms. (Why should I use a mutex to protect that shared array of
data ?)
> 
> Part of that is the design of the system, of course. The design worked
> OK when there was only one processor, but having several starts to
> stress the design assumptions. Multiple cores fight over available
> memory bandwidth, unified cache, and cache coherence.

Most of the time the issue is not about that fight, but the design (or
lack of it) for the program: the programmers start with a basic loop
with minimal functionality, then push in more patches & kludges to
extend it. Or when it goes parallel, it goes to the other extreme: every
single "object" get its own threads...

The time is long gone where a programmer would optimise a code (in
assembly) to fill in the cache just in time...

Post a reply to this message