Re: [OT: This is not the thread you're looking for. You can goaboutyour business. Move along, move along.]

From: Mok-Kong Shen (mok-kong.shen_at_t-online.de)
Date: 07/26/03 

Date: Sat, 26 Jul 2003 01:59:54 +0200

Simon G Best wrote:
>
> Mok-Kong Shen wrote:
> >
> > Simon G Best wrote:
> >
> [...]
> > I countered your
> > point about interprocessor communication.
>
> Where? Please give a reference to the post in which you countered it.

I like to reproduce the details of our debate about that
below:

Best: So, you're still ignoring the stuff about interprocessor
communications, etc.

Shen: There are interprocessor communication when a code
runs on a number of processors and there are data to
be exchanged, i.e. I/O. That means the theoretically
achievable performance is generally not achievable by
such a code and in fact most codes can't achieve the
peak performance. But, though a good mix of different
codes, the I/O time of one taks could be concurrent to
the processing time of another task, thus making the
average performance better. This is similar to the
case where one has only a single processor with
a number of tasks doing time-sharing.

Best: If a supercomputing job is saturating, say, interprocessor
communications resources, running additional supercomputing jobs
wouldn't help. ..........

Shen: As I said, this is a load-balancing problem. The issue
is well-known in CS. How could a machine both be
'saturated' and run at 4% of its peak performance?
There are known problems of getting good performance
in parallel computing that drive down the average
figure in comparison to the case of mono-processor.
But that extreme 4% is in my view clearly due to the
exclusiveness of the class of problems that are allowed
(for whatever reasons) to be run on the hardware. ........

Best: On what is your view based? The 4% figure could be due
to the nature of the problems for which that supercomputer is
intended. If so, the "exclusiveness of the class of problems
that are allowed" could very well be *justified* by that 4% figure!

Shen: That could be when only that kind of problems are run.
Now the 4% means that most processors are idle most
of the time. During that time other problems that
are cpu-intensive (some number-crunching tasks could
occupy cpu for a long time without I/O) could be
scheduled. This would make a better overall utilization,
isn't it?

>
> [...]
> >>No doubt you'll reply again, so answer me this: what's special about the
> >>sorts of massively-parallel supercomputers that John Savard mentioned?
> >>Was it the processors themselves? Or was it how they're interconnected
> >>to form a single unit?
> >
> > This once again shows that you barely know about the
> > subject of supercomputing and only wants to argue
> > for arguing's sake.
> [...]
>
> What's the answer to my question?

The massively parallel systems have a comparatively
large number of processors. There are algorithms
that have sections that could be done in parallel
and are thus able to exploit such architecture.
The processors could communicate fairly efficiently,
since they are near to one another. An algorithm
that could be parallelized may use some or all
available processors of such a computer. The number
may vary during the course of the run. There is
normally some policy of the computing centre determining
the maximum number of processors (out of the total
available number) a given job may use. Note that a
sequential algorithm (trivially) may also run on such a
hardware, i.e. on one single processor. How to get a
good mix of jobs (of different nature), allocating
to them the appropriate number of processors, such
that the hardware has a satisfactory total performance
is an issue that requires quite some knowledge and
experience and is usually decided under the supervision
of an expert of the computing centre.

Have I given enough information to satisfy your question?

M. K. Shen

are allocated to a job is usually subject to

Relevant Pages
Loading