RE: CISC to RISC - why not ?

[Neil Palmer <npalmer@xxxxxxxxxxx>]

It's all a question of priority.  If the tasks Peter's code kicks off
are running at a lower priority than other work you want to run on the
system (and if this other work is interactive that's certain to be the
case, if it's batch you can change the priorities) then it should make
no difference.  Just because your 'CPU %' is 99.9% (or even better
'++++'    :-)  ) doesn't mean you can't run another job at a higher
priority than the 'hog' job/jobs and get your work done.
 
... Neil Palmer                                     AS/400~~~~~      
... NxTrend Technology - Canada     ____________          ___  ~     
... Thornhill, Ontario,  Canada     |OOOOOOOOOO| ________  o|__||=   
... Phone: (905) 731-9000  x238     |__________|_|______|_|______)   
... Cell.: (416) 565-1682  x238      oo      oo   oo  oo   OOOo=o\   
... Fax:   (905) 731-9202         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
... mailto:NPalmer@NxTrend.com          http://www.NxTrend.com


        -----Original Message-----
        From:   Al Barsa, Jr. [SMTP:barsa@ibm.net]
        Sent:   Tuesday, December 16, 1997 1:17 PM
        To:     O'Connor, Peter H.; INTERNET:MIDRANGE-L@midrange.com;
O'Connor, Peter H.
        Subject:        Re: CISC to RISC - why not ?

        Hi,

        Peter and I reserve the right to respectfully disagree with each
other.
        But he's still a great guy.

        Al

        At 11:40 AM 12/16/97 -0500, O'Connor, Peter H. wrote:
        >Message text written by INTERNET:MIDRANGE-L@midrange.com
        >
        >Al states about CISC to RISC object conversion :
        >
        >>The downside of that it that it could tend to flood a slower
CPU.  This is
        >essentially the design that Peter O'Connor uses with his PC
Accelerator
        >product.  It gets the job done with a significantly lower
elapsed time, but
        >by flooding the CPU with work, you can't do much of anything
else.  
        ><
        >
        >Well, Al is only partically correct!!!!!!!!  PC/Accelerator
uses an
        >asynchronous tasks to do object conversion in the background
and not the
        >IBM SBMJOB method.   The number of THREADS is different
depending on
        >processor and memory.  So on a slow processor, PC/Accelerator
would NOT use
        >as many threads.   Also, there are two methods,  restricted
state and
        >non-restricted state.  Non-restricted state, other jobs can be
done at the
        >same time.  Flooding the CPU is a perception.  If running the
system at
        >92-95% of CPU is Flooding, than about 75%  of the 400's are
flooded.   
        >
        >Seaboard Corp. in Shawnee Mission, Kansas did an upgrade using
        >PC/Accelerator on a replace-a-releae.  IBM's EUA calcuated that
the object
        >conversion would take 60.28 hours to run.   PC/Acceleator did
the job in 5
        >hours and 2 minutes!!!!!!!!!  That is a savings of 55 hours.
Remember, it
        >had to do files and program objects. Even if fooding did occur
which it did
        >NOT, that is not a bad savings, 55 hours.  I have printed
output  to
        >confirm those statistics.  If any one wants Seaboards telephone
number, let
        >me know.
        >
        >Al also states:
        >
        > < It gets the job done with a significantly lower elapsed
time, but by
        >flooding the CPU with work, you can't do much of anything
else.>
        >
        >Some how, Seaboard got over 1,000 damaged objects.
PC/Acceleator notified
        >them of the damage in some of the libraries.  Bob Babich told
me  that they
        >were able to restore from tape all the damaged objects at the
same time as
        >PC/Acceleator was converting the rest of the system!!!!!!!!!
If one goes
        >by the above quote from Al, Bob Babich would NOT of been able
to do all
        >that restoring while PC/Acceleator was working!!!!!  By the way
restoring
        >is a processor hog and if PC/Acceleator was using all the CPU,
Bob could
        >NOT of restored all those objects but he DID.  
        >
        >Using  Burlesque in PC/Acceleator, Bob was able to strip down
two large
        >libraries (6,234 & 7,371 programs).   PC/Acceleator was able to
do object
        >conversion of 22 libraries at the same time while Al/IBM's
method could
        >only do 2 large libraries at same time.  Burlesque works on
object
        >conversion 10 times faster.
        >
        >When I was out in Rochester testing  an unannounced OS release,
4
        >developers were working on some of my problems at the same time
I was
        >converting 210,000 programs in 1:45 minutes.  Not Bad!  If
nothing else
        >could be done these developers did not know it.  
        >
        >In most cases, by the time a consultant/CE/SE leaves the
computer room,
        >drives to the hotel and gets into bed.  PC/Acceleator has
finished up the
        >work.  It is also interesting that of the hundreds and hundres
of users,
        >know one has complained about so called FLOODING.  
        >
        >Al is correct 99% of the time.  However, he is NOT correct this
time.
        >
        >Peter H. O'Connor
        >PAE Inc.
        >7 Riverway Rd.
        >Salem, MA 01970-5343
        >978-744-8612(T)
        >978-745-7945(F)
        >e-mail 102736.3535@compuserve.com
        >
        >

        Al Barsa, Jr.
        Barsa Consulting, LLC
        400 > 390

        Phone:  914-251-9400
        Fax:    914-251-9406
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---