Re: Emulator, Inc

[mjmahon@aol.com (Michael J. Mahon)]

MagerValp wrote:

>>>>>> "BP" == Bryan Parkoff <nospam@nospam.com> writes:
>
>BP> I have read Darek's website at http://www.emulators.com/. Darek is
>BP> an emulated programmer and he told me that he claims that C/C++
>BP> language is the WRONG languge for Emulator Project. He says that
>BP> he focuses at assembly language for best optimization and
>BP> performance. It is almost impossible for me to tell since he has
>BP> been programming for over 17 years. He always disagrees with many
>BP> programmers for general Emulation.
>
>The speed difference between assembly code and C/C++ depends on the
>cpu architecture, the compiler, and the problem. There's no given
>answer. Unless the compiler and/or the cpu architecture is braindead,
>the gains from rewriting a routine in assembler is tends to be some-
>where betweem 10% and 200%, depending on what you're trying to imple-
>ment. The drawback is of course that writing it in assembler is, in
>general, slower and more bug prone than writing it in a high level
>language. So what you do is you write the application in C/C++,
>analyze the code, and the rewrite the routines that would benefit the
>most from it in assembler. In an emulator, this is typically the video
>code and the CPU emulation. Writing the rest of the application, like
>the user interface, in assembler is usually just a waste of develop-
>ment time.

I generally agree with the intent of this post, but modern, highly-
parallel processor architectures have brought some new issues
into the mix.

A Pentium 4 can have over a hundred instructions "in flight" at
one time, with their actual commit rate dependent upon many
dynamic factors, as well as the obvious data dependencies.

A _very good_ optimizing compiler can generally beat a _good_
hand coder in dealing with a complex parallel architecture--just
because a computer can simulate the parallel execution better
than a good coder (think chess).

On the other hand, a _very good_ coder, with lots of inside info
on the detailed architecture of a chip, can usually do better
than a _pretty good_ optimizing compiler, and can occasionally
do spectacularly better.

When working on the inner loop of the execution engine or the
video engine, extreme attention to detail, targeting a particular
model of processor, might deliver an improvement in execution
speed of several times.

Remember that incorrectly predicted branches will utterly
derail the parallel execution, and unscheduled cache misses
will interlock it for many, many cycles.  Getting just one thing
wrong in a tight loop can cost you a factor of ten or more.

Optimal execution on a highly parallel processor is an exercise
in gamesmanship of a very high order.  This, plus the fact that
near-optimal execution on one model of a processor is often
pretty bad on the previous and next models, tends to push even
skilled M/L coders toward higher-level languages.

(BTW, most commercial compilers are _not_ "pretty good"
optimizers--they're "pretty bad".)

-michael

Check out amazing quality sound for 8-bit Apples on my
Home page:  http://members.aol.com/MJMahon/