30 Aug
2009
30 Aug
'09
5:01 p.m.
I have been performance tuning my TCP/IP stack mostly by looking at the
code and making educated guesses as to what needs to be fixed. I have
just wasted a day rewriting the IP checksum routine in assembler for a
few tenths of a percent improvement and I'm not terribly happy. :-)
Is there a sampling profiler available that will periodically record the
program counter and give me a histogram of what it finds when it is
done? I'm thinking of something like oprofile on Linux.
If it does not run in pure DOS but requires an emulation environment,
that is ok too. I just don't know what any of the options are.
Thanks,
Mike
31 Aug
31 Aug
3:40 p.m.
Michael B. Brutman wrote:
I have been performance tuning my TCP/IP stack mostly by looking at the
code and making educated guesses as to what needs to be fixed. I have
just wasted a day rewriting the IP checksum routine in assembler for a
few tenths of a percent improvement and I'm not terribly happy. :-)
#1 assembler optimization rule for old DOS apps: Keep everything in
registers. Memory accesses are really slow for everything 386 and
below. If you have to pass data to other blocks of code, try to do so
via registers instead of the stack.
#2 assembler optimization rule: inline code with macros where it makes
sense. A CALL on 8088 is 70 cycles (less penalty the more modern the
CPU gets, but still), plus it's that many less JMPs/RETs/etc.
Other helpful hints include:
- Smaller code is usually faster (see the "memory reads suck" rule)
- JMPs suck (they empty prefetch queue and flush caches) so try to make
the most common case in a comparison-and-jump the "fall-through" case
Is there a sampling profiler available that will
periodically record the
program counter and give me a histogram of what it finds when it is
done? I'm thinking of something like oprofile on Linux.
Turbo Profiler, although I've never tried profiling a TSR.
You can profile sections of code yourself by reading the 8253 timer both
before and after a block executes, then subtracting. Mail me if you'd
like some example code. The timer counts from 65535 down to 0 about
18.2 times every second; if the code you're profiling executes in less
than 55ms, then you can do your own microsecond-accurate timing.
--
Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/
Help our electronic games project: http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
A child borne of the home computer wars: http://trixter.wordpress.com/
1 Sep
1 Sep
2:49 a.m.
You can profile sections of code yourself by reading
the 8253 timer
both before and after a block executes, then subtracting. Mail me if
you'd like some example code. The timer counts from 65535 down to 0
about 18.2 times every second; if the code you're profiling executes
in less than 55ms, then you can do your own microsecond-accurate
timing.
A good reference on how to do this is in Michael Abrash's Graphics
Programming Black Book, Chapter three[1]. BTW, the whole book is great
reading if you are interested in x86 optimization in the [345]86-era.
Regards,
--Frej
[1] http://www.gamedev.net/reference/articles/article1698.asp
10:43 a.m.
On 1 Sep 2009 at 11:49, Frej Drejhammar wrote:
A good reference on how to do this is in Michael
Abrash's Graphics
Programming Black Book, Chapter three[1]. BTW, the whole book is great
reading if you are interested in x86 optimization in the [345]86-era.
I'm going to put my foot into it this time...
Using time-in and time-out counters may be fine for code where the
"hot spots" are known, but in a large complex application, that's
almost never the case. P-counter sampling (using a periodic
interrupt to obtain the value of the P counter and construct a
histogram) can point the problem areas up.
But in all of my own experience, the bit-twiddling sort of
optimization almost never yields results of the hoped-for magnitude.
For example, unrolling loops or scheduling instructions is fine for
compilers with automatic optimizers, but not for the programmer who
is going to hand-optimize. And the timing differences across an
entire family of CPUs often makes this counterproductive. (I can
probably still write out the scheduling for CDC 6600 instructions
from memory, as I've done a lot of this sort of
thing).
What matters most is the algorithm used. Converting 6 digit binary
numbers to decimal by repeatedly subtracting 10 is never going to be
faster, no matter how carefully optimized than using, say, the
Chinese remainder method.
Of course, thinking about one's methods is a lot harder than moving
instuctions around and potentially more disruptive.
For whatever it's worth,
Chuck
1:52 p.m.
Frej Drejhammar wrote:
I read the introductory chapters where he introduces his timing
technique. Jim Leonard also offered to send me a similar set of code,
which I am going to take him up on. But like Chuck pointed out, I'm
actually more interested in seeing where my time is being spent across
the entire application, not in just measuring a particular function.
The other idea that is starting to appeal to me more is to start adding
counters to my code. For example, if I add one counter to tell me how
many times I polled for new packets and I add another counter that tells
me how many times I actually found a new packet, then I have a rough
idea if I have a flow control problem or a CPU problem.
It's fascinating what we take for granted in a modern OS ...
Mike
You can
profile sections of code yourself by reading the 8253 timer
both before and after a block executes, then subtracting. Mail me if
you'd like some example code. The timer counts from 65535 down to 0
about 18.2 times every second; if the code you're profiling executes
in less than 55ms, then you can do your own microsecond-accurate
timing.
A good reference on how to do this is in Michael Abrash's Graphics
Programming Black Book, Chapter three[1]. BTW, the whole book is great
reading if you are interested in x86 optimization in the [345]86-era.
Regards,
--Frej
[1] http://www.gamedev.net/reference/articles/article1698.asp
5364
days inactive
5365
days old
4 comments
4 participants
participants (4)
-
cclist＠sydex.com -
frej.drejhammar＠gmail.com -
mbbrutman-cctalk＠brutman.com -
trixter＠oldskool.org