I agree that Assembly should replace C code only when there are obvious and consistent performance gains.
Of course crappy assembly code is not good in terms of performance or program simplicity. Assembly must be written by passionate people who will gladly spend a few days writing and redesigning a short section of time critical code so that it runs as fast as can be. When you say that performance gains are rare I cannot agree. Just compare the frame rate of MAME and SPARCADE when running, for instance, PacMan and you'll get an idea of what can be done in assembly. Both emulators are highly optimized but SPARCADE is several times faster than MAME on every processor. ..and plex86 needs a speed improvement. Have you tried VMWARE or Win4Lin? VMARE runs well though it's quite memory hungry. Win4Lin runs Windows 98 actually faster than native speed. Why is plex86 behind? Isn't the aim of this project to get more people to run Linux by giving them a relaxed way of breaking free from their Windows dependency? Just my 2 cents. Joaquim Carvalho 3/8/2002 21:59:06, "Shannon C. Dealy" <[EMAIL PROTECTED]> wrote: >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 > > > >
