Gavin Scott wrote:
>
> If you OCT stuff, then the CM% would go down a bit because the OCTed
> code will be faster than the original code, so the system will spend
> less time in that code.  But all the cpu that *is* used by an OCTed
> program should show up as CM in Glance and *not* NM.
>
> Further, OCTing a program does *not* make it an NM program.  It's just a
> CM program that happens to have some NM instructions attached to make
> the emulation process faster.  There should be *no* change in the number
> of CM/NM switches going on in an OCTed program vs. a raw CM program.
> Now certainly the *rate* of switches could change for the same reason
> that the CM% changed above, i.e. the OCTed code runs faster, thus
> allowing it to make more switches per second because it has to spend
> less time executing the CM instructions.  The total number of switches
> that happen during the lifetime of a process should be the same
> regardless of whether the program is OCTed or not.
 
Absolutely right and better expressing what I meant to say.
>
> That is of course unless Stan and I are both completely wrong about how
> this stuff works.
 
Of course you're not :-)
>
> As far as I know, the only downside to OCTing a program is that the new
> program will be much larger, thus eating up lots more memory, etc.
 
That might be the gotcha to the situation that I remember with the
CM Pascal Compiler octed. The system was in fact very small; might
have been a S932 with only 24 MByte of memory (release 2.05 or 2.1
at that time). Could be that OCTing the compiler just put a bit too
much memory pressure on the system, causing a higher page fault rate.
Could have been an OCTCOMP bug as well (I vaguely remember we had one
that caused a bit trouble in the 2.1 days, but we distributed the
version that came with 2.2 as a patch). Glance was not very much
installed on customer systems in that days.
 
Sorry for any potential confusion.
 
Goetz.