[Simh] SIMH performance
Michael Bloom
mabloom at dslextreme.com
Fri Mar 2 20:23:21 EST 2012
It is known that SIMH uses a lot of CPU time, apparently when it has no
work to do.
I used strace to capture 10 seconds worth of system calls from SIMH on a
(2 core) machine with 4800 bogomips per core.
The simulation was pdp11/73 running 2.11BSD
In ten seconds, there were 35610 calls into the kernel, averaging about
356 per second.
During those 10 seconds,there were many unsuccessful calls:
23526 read calls requesting one byte and returning 0 bytes
5990 accepts calls returning EAGAIN,
5990 recv calls returning EAGAIN
-----
35606 unsuccessful calls
and a few successful calls:
1 read call that returned 1024 bytes,
1 write call returning 4096 bytes
100 gettimeofday calls returning 0 (SUCCESS)
2 lseek calls returning 0
-----
104 calls were successful, less than 3% of all calls
There is a lot of spinning apparently going on. What would be the
downside of issuing select calls or FIONREAD ioctls in the thread(s)
doing IO? Or perhaps sleeping until the highest resolution clock
expires and having file descriptors generate SIGIO if IO becomes
possible during the interim?
You could use, for example, sigsuspend() with a signal mask that says
to sleep until either a high resolution timer (higher than your desired
clock resolution) expires or until a SIGIO indicates that i/o is
available. In the latter case, you could use select() to tell which fd
or fds io is possible on.
Alternately, you could use the timeout argument of select(), and not
have to deal with SIGIO at all. select would return either after a
timeout, or when one of the file descriptors specified is ready.
Perhaps useful, to provide examples, might be GNU emacs, which has been
using means such as these (or whatever method is available on the host
system) to perform I/O without wasted cycles, since the mid 1980's.
Note: by it's very nature, strace slows things down. Without it, there
would have been more calls, both successful and unsuccessful.
Schrodinger's Penguin, anyone?
More information about the Simh
mailing list