Hi Eric,
Like most machines with multiple processors, on the 3000 if you
have a single process ready to run, it will run on one processor.
If you have 16 processors, it won't help...your *one* process will
run on *one* processor. It might be processor #1 now, and a second
from now (perhaps after an interrupt occurs) it might be on
processor #9 ... but that's irrelevant.
A single process runs on a single CPU at a time. This is true on
every realworld computer, except for parallel processor machines...and
they require very specialized programming to utilize (in effect,
if you have a 1024-CPU parallel computer, you're running 1024 processes
at the same time).
Now, if you say "what about threads", replace "process" with "thread"
in the above if you're dealing with kernel threads, otherwise ignore it.
(I.e., in a system with kernel threads, the lowest "dispatchable" entity
is a thread, not a process. A thread can run on a single processor.
If you have 16 CPUs, and only one thread ready to run...
only one of those 16 CPUs will be working on the thread.)
> hey, anyone, i need help.
> surely with all the tech people here, someone can make a better guess than
> me.
I thought I saw some answers posted to your original question.
> > We have a site with a 995-400 that has a monthly program that takes 24
> > hours to run when running all by itself, no other jobs or users. I am
> > being told that on the 995-400, each running program gets a single
> > cpu while the program runs, and the other 3 cpus are idle. They use
If your job looks like:
!run foo
!run fum
!run fie
then *of course* fum and fie won't run until foo finishes. And that's
to be expected, if fum uses data produced by foo, and if fie uses data
produced by fum.
Now, if you have control over the source code and design of foo/fum/fie,
then it may be possible to get some multiprocessing going.
For example, if foo is producing a flat file of records that fum then
processes, you could try:
1) create a message file, FOOOUT, used to hold records written by foo
(which will be read by fum)
2) create & activate foo (see CREATEPROCESS intrinsic, or, if using
a tool like MPEX, try: RUN foo;...; GOON (or ;NOWAIT?)
3) run fum
Now, as foo writes each output record to FOOOUT, fum will read it and
work on it. If fum is faster (per record) than foo, it'll usually
be waiting on a read from the message file (this is fine, and is why
message files were chosen). If fum is significantly slower than foo,
and the message file files up, then foo will be blocked until some records
are "eaten" from the message file by fum ... this is also good.
Similarly, you could overlap fum/fie with the same technique.
In short, if the application design and data flow allows it, then in the
above example, there's no reason you couldn't have 3 CPUs busy at once
(one running foo, one running fum, and one running fie)
> > the other 3 are at 0%. They want me to split the program up into 2 or
> > more programs that they can run simultaneously, so that the other
> > cpus get used and the program will finish in half or less time.
> >
> > This doesn't sound correct to me.
Actually, that may be quite feasible, depending upon what your program
is doing.
For example, let's say you have a programm called FRED, which is
reading every entry in a 4 GB detail data set, and for each entry
doing some work. Your program probably does:
FRED:
open database
serially read through data set
work on each entry found.
you could change it to:
FRED:
start a child process, FRED_JR.
activate FRED_JR (stay awake yourself)
open database (shared)
Determine capacity of data set, call it n.
serially read entries 1 through n/2
work on each entry found.
wait for FRED_JR to finish.
FRED_JR:
open database (shared)
Determine capacity of data set, call it n.
serially read entries n/2 + 1 through n. through n/2
work on each entry found.
obviously, some careful thought must be used. For example, if the
data set is capable of dynamic expansion, you probably want to
pass the value of "n" to FRED_JR, so both FRED and FRED_JR agree
on who is doing what entries.
BTW, this is the same type of thinking you'd be doing on a Unix system...
the primary differences are cosmetic in nature, not fundamental.
(On Unix, you could use fork() to start FRED_JR (but not on MPE/iX with
POSIX, because of the use of IMAGE); and on Unix FRED would generally
not have to wait for FRED_JR to complete.)
> > I have read articles concerning multi-cpu processors that indicate
> > the Operating system divides up instructions between the available cpus
> > automatically.
You're talking about research machines (at best), not practical usable
existing commerical computers.
> > Is the HP different in this respect? anyone know?
No...the HP is like (nearly) every other available multiple CPU machine
on the market in this respect. It's different in one respect: it's
more reliable :)
--
Stan Sieler [log in to unmask]
http://www.allegro.com/sieler.html
|
