Slaphead time...

Whilst diagnosing something fishy in dtrace the other week
(why xcalls are so slow), I was going to write that its obvious:
when running in a VM, things are slower.

I got distracted, and have been chasing up issues and breakages in dtrace.

Nigel - such a great person for feeding back breakage and issues,
was asking me why I was spending so much time on the teardown code.
Its rare that people do "dtrace -n fbt:::" and they get what they deserve.
I said, well, it has to be safe.

He then said, well, the figures in my prior blog didnt add up: I was
quoting a great achievement of ~10s to teardown, and he was seeing
sub-second teardowns. *On Real Hardware*.

Duh!

So, I just checked. My 10s teardown is about 0.5s on a Pentium Core 2.33GHz
machine:

218.620320647 #0 teardown start 1322505021.895618798 xcalls=90677 probes=423796
218.680320738 #0 teardown done 0.60000091 xcalls=181282 probes=291

So, double Duh! I also checked the tick-1 test:

$ dtrace -n '
	int cnt_1ms, cnt_1s;
	tick-1ms {
	        cnt_1ms++;
	        printf("%d %d.%09d", cnt_1ms, timestamp / 1000000000, 
			timestamp % (1000000000));
	        }
	tick-1s { cnt_1s++;
	        printf("tick-1ms=%d tick-1s=%d", cnt_1ms, cnt_1s);
		cnt_1ms = 0;
	        }
	tick-5s {
	        printf("the end: got %d + %d\n", cnt_1ms, cnt_1s);
	        exit(0);
	        }
'

And I get around 980 x 1ms ticks per second, vs around 250 x 1ms on a
VirtualBox VM (running on an i7 2630 chip).

So, there we have it. Proof that a VM is slower -- very significantly
in some areas, and one must be very careful to attribute performance
in a VM to anything like real world. (Its not really surprising -
playing with timers or doing cross-cpu interrupts, has to be mediated
by the host VM). These dtrace tests are extreme and so amplify the weakness
of a guest VM.

So, I have partially wasted my time in doing these optimisations, but
actually, they are useful, allowing me to refine the port to Linux, but
also to look for and find, potential issues which might show up after
a much longer period of soak testing on real hardware.

Now...off to fix the next bug....

Post created by CRiSP v10.0.18a-b6115