Newsgroups: comp.sys.amiga.advocacy
Subject: Re: Commodore and the Osborne Syndrome
From: lkoop@TIGGER.STCLOUD.MSUS.EDU (LaMonte Koop)
Date: 30 Jul 92 14:21:39 -0600
Reply-To: lkoop@TIGGER.STCLOUD.MSUS.EDU
Organization: St. Cloud State University, St. Cloud, MN

In article <1992Jul29.214807.15050@ctr.columbia.edu>, jerry@connection.prospect.com (Jerry Shekhel) writes:
>gblock@csd4.csd.uwm.edu (Gregory R Block) writes:
>>
>>: Oh, this is BS.  How much would it slow down the machine?  5%?  You wouldn't
>>: even notice that.  A slightly faster CPU would take care of the difference
>>: and then some.
>>
>>Memory protection can and generally DOES slow it down a HELL of a lot
>>more than 5%.  Try 58%.  That was using my friend's MP-added CD-RTOS
>>system.  That gives it MP and resource tracking.  And it was next
>>to unusable.  Sure, it had it, but it was next to unusable.  58,
>>Jerry.  That's enough to go from productive to unproductive in 13.8
>>seconds.
>>
>
>This is INSANE.  What CPU was this implemented on?  Did it have an on-board
>MMU like the 386 or the 68030?  There's NO WAY those CPUs would experience
>that much of a slowdown.  I have a 386, and DOS applications under OS/2
>(full MP) don't run noticeably slower than they do under native DOS.
>Benchmarks indicate a slowdown of a few percent, no more.

That is not a valid comparison.  Running DOS applications under OS/2 involves
a bit of trickery and memory protection is not fully utilized in this case.

I do suggest you review the basic concepts of memory protection via MMU.  The
hardware itself is RARELY the cause of the slowdown.  At most with modern
hardware you will see a wait state or two added to memory accesses (or perhaps
an occasionally longer wait when a full table search is needed).  The slowdown
is mainly seen in comparison to a non memory protected environment.  For 
example, an OS which in a non-memory protected environment might be able to
access system shared structures with ease, as could an application.  Under a
standard memory-protected setup, the methods to gain access to such structures
become more complicated, thus adding code and execution time.  Add that up if
many such structures are in use originally, and you see quite a slowdown from
this extra effort.

>Interesting.  And just how did you implement MP on a 68000?  If this was
>on a 68030 or a 68020+PMMU, maybe this indicates a flaw in the 68K line,
>because there sure isn't that much of a slowdown on the x86!

Memory protection on a 68000 is possible, though complex at best.  (Actually,
the best method would be to use two 68000s).  In any case, again, this is not
a flaw in the 680x0 series or a greatness in the 80x86 line, but rather a 
misunderstanding on your part of what actually creates the slowdown in question.
It is generally not the MMU overall, but the added complexity for various
OS/application operations.

>+-------------------+-----------------------+--------------------------------+
>| Jerry J. Shekhel  | Molecular Simulations | Time just fades the pages      |

                   ----------------------------------------
             LaMonte Koop -- SCSU Electrical/Computer Engineering
  Internet: lkoop@tigger.stcloud.msus.edu -OR- f00012@kanga.stcloud.msus.edu
               "You mean you want MORE lights on this thing???"
  ---------------------------------------------------------------------------
Newsgroups: comp.sys.amiga.advocacy