There may come a day when a compiled language can consistently beat a
good assembly programmer, but that language will never be C. It will
be a new language that has a radically new, high level way of specifying the
algorithm to the compiler, and that has complete control over the generated
code, including data structures.

To make my point, take a simple example.

Consider a fictitious processor that has an architecture with an indirect
addressing mode. That is, the address can be loaded in a register, and
that register be used to generate the address for data used in other instructions.

Now let's also posit that the processor can post-increment-by-one the
address registers used for indirect mode for free, but post-increment
by-two (or other higher values) is not free - i.e., it cost more
cycles.

Now let's say the algorithm to be coded is to sum the real and imaginary
parts of a complex array.

Our programmer, being ignorant of the processor architecture details,
writes the following code:

Check Intel's marketing for its C/C++ compiler.
I'm sure in there somewhere is how it detects
SOA/AOS requirements and reorders data, and
vectors it all using SSE2/3/4 for best effect.
I'm almost as sure that MS/VS will do the same.
All this even without #pragma hints. Since so
few will ever know asm well enough to beat a
current compiler, guru code (potentially) being
better than compiler code is pretty much moot.
Besides, this is more about knowing how to order
data, not a compiler/assembler thing. Had to yawn

Randy Yates wrote:

Randy,

I think that this debate can actually be thought of in a slightly more
general way. That is, rather than being the "C vs assembly debate" I
think you could think of this as the "Optimization vs Portability
debate". This would encompass not only C vs assembly, but also things
like drivers vs "integrated" code or OS vs simple scheduling (ISRs).

hel@40th.com wrote:

If you checked the marketing, you might have seen that Intel C++
implements complex data type auto-vectorization for SSE3, but requires
C99 syntax for that. Since you are cross-posting to c.l.f, you might
consider that some people would prefer to use Fortran rather than less
optimal asm hacks. Sorry if you are put off by flashbacks to the days
when people called Fortran functions from COBOL rather than do asm.
Beats me why people would rather use asm than embed C99 in C++ or C89.
Don't know whether you consider the

On Jul 29, 2:18 am, Randy Yates ieee.org> wrote:

gyansorova@gmail.com wrote:

On Jul 28, 3:18 pm, Randy Yates ieee.org> wrote:

One mistake that people often make is trying to compare for example
the efficiency of C code vs. assembler code for the same problem. This
is not the right comparison. You have to compare C vs. assembler code,
assuming that two equally competent programmers spend the same amount
of time writing the code.

I can write assembler code that is faster than equivalent C code. If
it takes me one day to write the C code, it takes me a week to write
the assembler code. In that week, I could have written much faster C
code. In two months, I could write equivalent assembler code that is
faster. In the same two months, I could write faster C code.

Jerry Avins wrote:

n had been 1 for decades. For most new hardware, it's now 2, and it's
already starting to change to 4.

- Logan

On Jul 28, 4:50 pm, Jerry Avins ieee.org> wrote:

and if instructions have conditionals in them, those would have to be
executed sequentially, despite the brawn, no?

r b-j

Jerry Avins wrote:

...

Until processors routinely execute any n instructions in parallel ...
^
Jerry