On Fri, 8 Mar 2002, Joaquim Carvalho wrote:
> A few bits of this:
>
> mov [LIMIT1],eax
> mov bx,[LOWER esi] ; set LIMIT2 (ddata1 descriptor)
[snip]
> mov ebx,[Y esi]
>
> ...in the right places could do wonders for plex86 execution speed.
>
> Done right, assembly code can be several times faster than C.
>
> As this is an 80x86 only project, there's no reason why assembly
> can not be used.
>
> Small critical sections of the C source code can be commented
> out and replace by inline assembly.
[snip]
While I agree with you in principle, the overwhelming majority of assembly
code is done wrong, often results in slower code, and are far more likely
to introduce bugs (a large chunk of of my career has been spent fixing
"optimized" assembly language code that was slower than even a crappy C
compiler would generate). In addition, often simple optimizations of the
C code can get you the same performance gains. For the case of serious
processors (CISC/RISC 32 bit or larger) I have seen very few instances
where carefully optimized C code and a good compiler aren't within 1 to 2
percent of the best hand optimized assembly. Having said that, my take
for the general case of C v/s Assembly for this project would be to make
sure the algorithm is as well optimized as possible in C code, then if the
code section is performance critical to the system, try the assembly
approch and benchmark the code sections, C versus assembly on several
different processor variations with the C code compiled for each target
processor (such as K6, Duron, Athlon, Pentium III, Pentium IV, etc.).
If the assembly code consistently beats the C code by some significant
amount (a number I won't attempt to define because I'm not sure what it
would/should be), then by all means, we should go with the assembly code.
The cross CPU testing is important, because every cpu has timing
differences in at least some instructions and instruction combinations,
and if you improve the performance for everyone running Pentium III's at
the expense of performance for everyone running a Duron, then your
assembly language code has not really gained anything for the project
overall (unless of course someone wants to optimize it for every processor
variation).
Personally, at this point in the project, I think it is a waste of time to
work on performance optimization at the assembly language level, because
there is alot of other work to be done that could result in design changes
which might cause the section of code you just optimized to be discarded,
in which case all the time spent optimizing it was wasted.
Usually the best approach to new development goes something like this:
1 - Come up with a design
2 - Get it working
3 - Get it stable
4 - tune performance/resource utilization
There is always going to be some need to bounce back and forth in the
order above, but if you start doing things out of sequence consistently,
rather than just when it is really needed, it takes alot more work to get
the job done because you end up discarding work that has been done but
is now obsolete because of changes at the preceeding level.
FWIW.
Shannon C. Dealy | DeaTech Research Inc.
[EMAIL PROTECTED] | - Custom Software Development -
| Embedded Systems, Real-time, Device Drivers
Phone: (800) 467-5820 | Networking, Scientific & Engineering Applications
or: (541) 451-5177 | www.deatech.com
