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

nemesis wrote:
> you are into this for a long time, huh, dude? :)

This is the DOS 3 timeframe.  Before that, architectures were even more 
screwy in mainframes.

> if you didn't give up in the hard hairy days, it's certainly not today...

It's actually somewhat harder nowadays, in some ways. Now it's so easy that 
every bozo can build something that your boss thinks will save you time.

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> nemesis wrote:
> > you are into this for a long time, huh, dude? :)
>
> This is the DOS 3 timeframe.  Before that, architectures were even more
> screwy in mainframes.
>
> > if you didn't give up in the hard hairy days, it's certainly not today...
>
> It's actually somewhat harder nowadays, in some ways. Now it's so easy that
> every bozo can build something that your boss thinks will save you time.
>
> --
> Darren New, San Diego CA, USA (PST)
>    Serving Suggestion:
>      "Don't serve this any more. It's awful."

I don't know about other manufacturers, but the IBM OS/360 systems
had an overlay mechanism much like you described in your earlier post.
You described an overlay structure to the linkage editor, and it
linked your program. When your program ran, the modules were loaded into
the overlay areas when called.  I don't recall anything particularly screwy
about that.  At one time all our programs had to run in a maximum region
(memory) size of 250K.  When you ran on a real memory system with less than 1M
of memory, you did what you had to do.

Isaac.

Post a reply to this message

Clarence1898 wrote:
> I don't recall anything particularly screwy
> about that.  

The IBM OS/360 wasn't the one I was talking about. :-)

Some of the older HP machines had really funky hardware architectures. Stuff 
like a segment for each "object" and so on. Or the Burroughs B series. The 
sort of stuff you couldn't even run C on.

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

On 18/01/2011 07:24 PM, nemesis wrote:

> really?! What was it? An settable option for the compiler?

I think FactInt uses overlays. Go read the source code... :^)

Post a reply to this message