• Subject: Re: CISC to RISC - why not ?
  • From: "O'Connor, Peter H." <102736.3535@xxxxxxxxxxxxxx>
  • Date: Tue, 16 Dec 1997 11:40:26 -0500

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
+---
| 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
+---


This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].