Re: Optimizing in assembly language

"T.Shackell" <ts3@ukc.ac.uk> wrote in message
> I think a better approach and one that is currently used is to
> put little *chunks* of hand optimized ASM into a higher level language.
> This has many advantages over the scheme you suggest.


Alas, it confuses the HLL compiler's optimizer to no end and often the
assembly interface is at the procedure call level and this destroys
what little optimizations you gain in assembly. I've had much better
luck with slightly larger chunks of assembly code (generally, I
replace at the module level rather than the procedure level).


> - coders on the whole can deal with a smaller number of lines of code


Of course, I have several examples where it took *fewer* lines of code
to express the algorithm in assembly than in C/C++, so I don't
completely buy the party line that HLLs are always more efficient
because it takes fewer lines of code to express an algorithm. In
general this may be true, but code isn't "generally" written in
assembly so this is a dangerous statement to make about a specific
problem.


> - they can focus their optimizations to key areas


This is language independent.


> - most of the code is very portable only the ASM bits are not


Of course, splicing in lots of in-line assembly makes the code *less*
portable than putting the assembly all in one module.


> - small chunks of assembler are easier to understand than a whole program
> at an intermediate level.


Agreed. However, I'd suggest that a given algorithm, implemented in
the appropriate language for that algorithm, is going to be the
easiest to read and understand. Sometimes assembly is the most
appropriate implementation language for a given algorithm (which is
why some of my assembly code contained fewer lines of code than the
C/C++ code, assembly was more appropriate in that case).


> - the programmer can see what the compiler is doing by simply reverse
> engineering their own HLL code.
>
> In most cases speed is not so critical as to require *any* part of a
> program to be reduced into ASM let alone all of it! The uses for ASM
> that I have found have mainly been restricted to optimizing inner
> loops that the CPU spends a huge ammount of time in. Here writing the
> rest of the code in a higher level language and embedding blocks of
> assembly for critical points is clearly the right solution.


I must say that I rarely attempt to write fast assembly code.
Most of the time that I use use assembly it's because:
(1) It is the most appropriate language for implementing the algorithm.
(2) I need absolute control over the execution sequence (e.g., order of
          evaluation in an arithmetic expression with side effects).
(3) I'm doing it for fun.


Writing optimal code in *any* language is hard work. The best
optimizing compiler in the world isn't going to make up for sloppy
coding practices (even when using the best underlying algorithm).


Given that I don't pay attention to things like instruction
scheduling, register allocation, etc. (i.e., the things that
optimizers do a very good job of), it's quite amazing that my code
typically runs on par with the output of a compiler. But my assembly
code could probably run faster if it were run through some sort of
optimizer; hence my original question.


> Using ASM is a last resort, finding a better algorithm is always the
> better way to go.


Using any optimization technique is a last resort to finding a better
algorithm. Alas, better algorithms are usually difficult to come by
unless you've written some really stupid code to begin with; which, of
course, probably describes 80% of the code that's out there :-(.


> If *all* your code needs to be faster I would suggest you either:
> - use a better algorith or
> - raise the target spec of the machine to run it on


What happens when you're using the best known algorithm running on the
fastest machine you can afford?


Seriously, though, a factor of two's difference in running speed can
mean the difference between success and failure in the commercial
marketplace. Raising the target spec is cheating. If the
specifications call for a response in xxx.yyy seconds on a 500 MHz
machine, you don't meet specs by changing this to a 1GHz machine.


As we're seeing today, the average consumer has stopped buying the
fastest machine available, so the expectation that next year's
machines will be fast enough isn't a good bet anymore. Given the
troubles that CPU manufacturers are having boosting the speed of their
uniprocessor systems recently, I'd suggest that the days of this free
ride may be coming to a close.


> less than expert assembly programmers are not likely to be writing
> programs that need the extra speed. If they do then they should
> learn optimized assembly, most people will never need to.


There are two problems with this approach. First, why shouldn't the
machine be put to use to help out those who need to use assembly for
one reason or another (e.g., they need the control or space savings,
speed is a secondary consideration)?


Second, the claims that assembly is not portable is, strictly
speaking, not true. An 80x86 assembly program will run on many
different CPUs, say the Pentium, the Pentium II/III, the Pentium IV,
the Athlon, etc. As HLL proponents are fond of pointing out, code
that is optimized for one of these processors may be suboptimal on
another. With a HLL, all it takes is a recompile (plus, of course, a
new compiler) and your code is running fast on the other processor(s).
Why shouldn't assembly language programmers who need to work in
assembly language be able to do the same thing?


> > Many of the software engineering problems would remain (do you really
> > want to write a large amount of code in assembly?), but some of the
> > issues, like the appearance of new CPUs with their own idiosyncrases,
> > would diminish or go away entirely.
>
> many of the software engineering problems would be *worse*, instead of
> having mostly HLL with small ammounts of lower level languages mixed
> in you now have a medium level soup. This could be very hard to
> maintain.


You're assuming that such an enabling technology would encourage more
people to use assembly language rather than a HLL and that they would
code in assembly what they would otherwise code in C. While some of
this might happen, I just don't see this being a big deal. And in the
cases where it did happen, it would probably happen because there were
solid engineering or personal reasons for doing so. I could be wrong,
but I doubt that an optimizing assembler would spark a renaissance in
assembly language programming. It would simply be a tool that would
make maintenance of assembly code much easier (since, for example, you
wouldn't have to maintain different versions of the code for different
processors that have different optimization characteristics).




> It's a nice idea but I think what is currently done is more sensible.


No optimizations at all?
Force someone to use an inappropriate language because they can't
maintain the assembly code across all CPUs in a family?
I'm not sure I buy the line that "just use a HLL, it's better in the
long run." I'd rather let the software's designer weigh all the
options and make that decision on a case-by-case basis
as it pertains to their projects.
Randy Hyde

Return to the comp.compilers page.
Search the comp.compilers archives again.