FYI, I was playing around with AIM7 on Linux-Origin last week, trying to
diagnose why performance was so bad. I didn't get very far, yet. Even
when I stripped the AIM7 subtests down to a single compute-bound test, I
wasn't seeing 'top' report that process as compute-bound.
A known standalone compute-bound program (i.e., a simple program that
just loops) does get seen by 'top' and 'vmstat' as compute-bound.
Multiple copies of that program do appear to property share the overall
available CPU cycles.
But there's something about the AIM environment that isn't behaving
well. AIM uses forked children and pipes for parent-child
communication. Perhaps it's something in there. Or perhaps the
stripped-down AIM is just executing each subtest within the
display-refresh time. I need to play with it more.
When I ran the same AIM7 workload that I typically run on an SMP i386
Kayak -- a workload that runs compute-bound -- I see pretty awful
performance on Origin. On my i386 (two 266-MHz PentiumII) my AIM7 peaks
at about 50 jobs/minute and stays fairly flat until 80 or 90 or so (when
it begins to thrash). On a 2-200Mhz O200 I see a peak below *10* (at
half the performance of the i386) and a huge falloff from there.
Something is clearly wrong.
John H.
|