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.