InvestorsHub Logo
icon url

UpNDown

05/30/03 10:00 AM

#5465 RE: j3pflynn #5420

j3pflynn, on SPEC intruction hotstop counts

UpNDown, for those ignorant among us, could you explain the significance of your SPEC link/info?

You're asking the ignorant (that's me) to do the explaining? :)

I posted the link because this board is a central index for things like this, even though not everything is relevant to everybody. So if I find something that relates to AMD or Opteron, I'll usually post a link.

The information given is basically a profile of instruction counts for gcc on Opteron while running various components of the SPEC benchmarks. This information can be used to see where the generated code from gcc is most heavily weighted during the SPEC runs. Given that, an inspired programmer can come up with AMD64-specific or general optimizations that can be included in the gcc code stream.

The SPEC codes themselves are not publicly available, but much can be discerned by a reverse assembly person with lots of interest (and time on their hands). I was that type of person once, and might be again once family responsibilities recede.

AMD is stuck on the compiler front. The Intel compilers are very heavily optimized for Intel architectures. By snapping up other compiler competitors, Intel has made it much more difficult for AMD to post top scores in SPEC contributions. AMD seem to have made the decision to support gcc as much as possible so that it will generate at least a medium-level of optimization for benchmarks. It's hard to see how gcc will ever reach the levels obtained by the single-minded obsession of the Sun and Intel compiler teams.

Perhaps the linked information is a preview of this. I'm sure if someone were to examine the code and come up with gcc improvements that give increased performance for Opteron under SPEC, AMD would be very supportive of that effort. The release of these basic internal profiles may help smoke such individuals out and help focus the effort.

What can I say? Some of us do crossword puzzles to keep our brains going. Others find the ins and out of getting absolutely the best performance that you can get from a chip an interesting challenge.

In this case, the assembler code is available. Someone could determine which hand-generated code would be optimal for each frequently-used function, then determine how gcc could be modified to produce code along similar lines. The more aggressive whole-program optimizations that have brought SPEC into disrepute will not be added to gcc (they are opposed on fundamental grounds by the compiler team), but much progress on general optimization and Opteron-specific optimization remains available.

The great thing about the open source aspect of this is that a cadre of programmers can be developed who will stay with it for a long, long time.