Re: No need to optimize in assembly anymore

From: a (a_at_a.com)
Date: 05/26/04 

Date: Wed, 26 May 2004 17:58:07 +0000 (UTC)

I didn't say optimization is undesirable. In fact for a compiler it should
always be done. What I meant was that hand optimized code in assembly may
no longer be useful as it might run well for one processor but poorly for
another.

The only optimizations that will be useful are the high level ones that work
across CPU families such as loop unrolling, data alignment, function
inlining etc. - precisely the ones that a good compiler will perform.

Optimizations such as instruction rescheduling to prevent stalling the
pipeline and reorganisation of code for better use of cache will be
considered a waste of time as they will only work for a particular
processor.

Perhaps asssembly days are numbered?.....

DayStar.

"Ivan Korotkov" <koroNOSPAMtkov2@ztelDOT.ru> wrote in message
news:c88o65$rg7$2@news1.macomnet.ru...
> > Given that optimizing in assembly for one processor will have no effect
> (or
> > negative effect) on a different processor it seems that low level
> > optimization is becoming a waste of time. As processors become more
> > sophisticated and diverse in the way they execute code this trend is
> likely
> > to continue.
>
> Everything in our life is optimized for a particular entity. But
> optimization rules for all P6 CPUs are almost the same. For P4, PM and
> succeeding few models they might also be nearly the same. Each CPU family
> has similar architecture.
> Sometimes it's urgent to optimize for a concrete CPU. A friend of mine
(he's
> a physician) asked me to write a small program that modelates planet flaw
in
> 2-star system (famous 3-body problem). It had to run on a... Pentium (133
> MHz). Mathcad and other general math & engineering apps run VERY slowly
> compared to special-case programs (and especially on such a CPU) so I
wrote
> my own ODE solver. I'm not a specialist in optimizing for P5 and I relied
on
> compiler's optimizer (VC 7.1). The code actually rans faster with
> optimizations and this app has never run on any CPU but P5 (and, of
course,
> mine - but for testing purpose). Thus you can't say that optimization is
> always undesirable.
>
> Ivan
>
>

Relevant Pages

  • The never ending assembly vs. HLL war
    ... > branch instruction excluded is not particularly effective optimization. ... > CPU, chances are pretty good it *won't* be optimal on a different CPU. ... > discussing the futility of optimizing it in *assembler* when the ... careful and consider the code the compiler is emitting (and adjust your ...
    (comp.lang.asm.x86)
  • Re: Why are z/OS people reluctant to use z/OS UNIX?
    ... our compiler can take up a lot of memory and cpu. ... several choices of optimization levels, ...
    (bit.listserv.ibm-main)
  • Re: Critical Performance Issue - Help!
    ... various optimization levels or combinations of compiler flags. ... unless it's precipitating some sort of CPU pathology. ...
    (comp.programming)
  • Re: multiple threads scaling on multiple CPUs
    ... this message -- I had posted this on a GCC group and a suggestion was ... when I run a "debug" compile (i.e. without any optimization flags). ... Here is the general breakdown of user CPU usage ... the more optimized code is going to involve more clashes between ...
    (comp.programming.threads)
  • Re: How to profile a VC++ program?
    ... I will look at the multi-thread option, and change it and measure it. ... I tried other optimization options as well, like O1, Ox, or the debug ... It is CPU ... The gcc version of the program do not link with multi thread. ...
    (microsoft.public.vc.language)