Xavier writes:
> Their application was still running on CM mode (Pascal code) and was
> generating numerous CM to NM switches. On high activity period, those
> switches were more than 10,000 per sec (red zone begins by
> 800), inducing serious performance damages.

No, sorry, in my opinion that's nonsense.  There is nothing in CM to NM
switching that can be called "serious performance damages".  CM to NM
switching is simply a side effect of the fact that the programs are CM,
and the operating system is NM.  When the program makes an OS call it
will have to switch to NM in the process, and unfortunately(!) the
Measurement Interface records this in a counter and lets you see it (and
fixate on it).

10,000 CM to NM switches per second is *good* because it means your CM
programs are getting a lot of work done.  If you were to buy a system
that's ten times faster than your current system, and the switch rate
went up to 100,000/second, would you think that would provide even
*more* justification for switching to NM because 100,000 is way worse
than 10,000/second?

CM to NM switches are fast and do not require moving data between
stacks.  They are not *that* much slower than an ordinary procedure
call.  They add only a small overhead to CM programs (similar to the
fact that the CM programs are CM instead of NM in the first place).

CM programs have advantages over NM programs in terms of smaller code
size, smaller data size, and correspondingly better cache locality for
both code and data.

CM performance is very good on MPE, the CM to NM Switching does not
affect this, and there's really nothing wrong with running your whole
application in CM if you want/need to.

Sure, NM will be faster, but not *that* much faster in most cases, and
can be *slower* in some cases such as...

> They migrated their programs to NM mode (but not their data,
> still recorded in 16bits format in their DB). They gained
> better performance of course,

I don't think so...

> but for a short time : performances were soon as bad as
> before. The reason is, if CM to NM switches have been
> divided by nearly 4, NM to CM switches have exploded to
> 3,000 and more (red zone is by 200...),

NM to CM switches are probably 100 times slower than CM to NM switches
and *are* a source of significant performance penalties.  The
application may easily run significantly slower in NM if it has to
switch to CM than it ran in CM with the CM to NM switches.

If you cannot eliminate the NM to CM switching, you should go *back* to
the CM version of the application which is probably faster, uses less
memory, and will have less of an impact on the system.

The reason that NM to CM switching is "bad" is that all of the
parameters (record buffers, etc.) have to be *copied* from the NM stack
to the CM Stack, so you're looking at one or two extra data moves on
every call.

> inducing memory, paging, I/O and sometimes CPU bottlenecks.

Switching should not directly affect memory and paging activity.  The NM
programs will require more memory for both code and data than the CM
programs did though.

> Is there any trick to reduce the NM to CM switches ?

Sure, put the application back in CM where it was happy, or identify the
usage of CM operating system or user code that's causing the switching.

The question is, why is there NM to CM switching?  The fact that your NM
programs are using 16-bit alignment will not cause switching.  To get
switching you must either be doing it explicitly (to call SL routines
from NM) or you must be using some obscure operating system facility
(RIO files, etc.) that is still implemented in CM.  All Image database
operations are fully native mode and should not result in any switching
when called from an NM program no matter how the NM program is compiled.

> Do they have to necessarily migrate their data to 32bits format ?

No, this will have no effect on switching.  It will have a small effect
on performance, but one that should be overcome by being in NM versus
CM.

> Is this situation compatible to run on N4000/MPE 7.5 ?

Sure, nothing in this whole debate will be any different on 7.5 than on
any other MPE version.

G.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *