Assembly subroutines !?
David Thomas Richard Given
Daniele Paccaloni <d...@bbs.infosquare.it> wrote:
>I am wondering how to include assembly subroutines to speedup C
>programs compiled with gcc under Linux.
>Is there a way to insert inline assembly into the C source (like on
>MSDOS Borland-C) ?
Basically, the compiler will do a better job optimising than a human can,
in a lot of cases --- just take a look at the kernel code and see how
*little* assembler there is in there. There just isn't any point.
--
-------------------------------------------------------------------------------
Why do people surf the Information Superhighway? Won't they get run over?
http://www-hons-cs.cs.st-andrews.ac.uk/~dg
Sun-Earther David Daton Given of Lochcarron
Christopher HILL
>Basically, the compiler will do a better job optimising than a human can,
>in a lot of cases --- just take a look at the kernel code and see how
>*little* assembler there is in there. There just isn't any point.
While compilers are getting better and better at optimizing code, a good
assembly language programmer can always equal or beat a compiler. This is
especially true for the x86 line of processors. To say otherwise is
foolish.
Christopher Hill
Aiea, Hawai`i (O`ahu)
Stacey Campbell
>While compilers are getting better and better at optimizing code, a good
>assembly language programmer can always equal or beat a compiler. This is
>especially true for the x86 line of processors. To say otherwise is
>foolish.
You may be making a valid point in a world without project deadlines,
bug lists, code that must be reused for the next slightly different
rev of a graphics chip, etc. but in the real world where code must ship,
and it must be fast, and it must be bug free, and it must be easily
modified for reuse, the above attitude will get you in a world of trouble.
That aside, do you seriously think that a `good' assembly language
programmer can keep a P5 or P6 pipeline busy in a useful way for any
substantial amount of code (e.g. the many large chunks of critical code
in an X DDX) better than the compiler writers at Intel who sat
cheek-by-jowl with the people that actually designed the chip?
Clearly the answer is `no'. To say otherwise shows you've never used an
optimizer that knows how to build good Pentium assembly and you've never
shipped a major software product with large areas of performance critical
code.
--
Stacey Campbell sta...@anyware-fast.com http://www.anyware-fast.com/stacey/
Have stuff identified at http://www.anyware-fast.com/stacey/animal.html
Alain Knaff
:In <4icune$p...@yantra.anyware-fast.com> sta...@yantra.anyware-fast.com (Stacey
:Campbell) writes:
:>That aside, do you seriously think that a `good' assembly language
:>programmer can keep a P5 or P6 pipeline busy in a useful way for any
:>substantial amount of code (e.g. the many large chunks of critical code
:>in an X DDX) better than the compiler writers at Intel who sat
:>cheek-by-jowl with the people that actually designed the chip?
:Yes, depending on your definition of 'good.' The typical output of,
:for example, MS VC++ 2.x and 4.0, as analyzed by Intel's Vtune product
^^
:and my company's PentOpt product, will show you how bad it is. I'm not
:going to get into a big debate over this, but unless you have actually
:looked at the compiler output, then you are just assuming that it
:must be good.
Yes, Micro$oft does produce shitty compilers. So what else is new?
Did you consider looking at the output of real compilers?
Alain
Glen Blankenship
> Certainly you can imagine some human being better or equal at
> optimizing than a compiler (the one designing the compiler, perhaps,
> but not necessarely...). But heck, these people cost more than the
> average compiler and are of course much slower. Your point seems
> pretty moot.
So? A good C++ programmer costs more and takes longer than a
drag-and-drop "interface generator". A skilled wood-carver
costs more and takes longer than a router and a set of trim templates.
A custom tailor costs more and takes longer than an off-the-rack
suit at Suits-R-Us.
High-quality hand-crafted materials cost more and take longer than chaep
mass-produced materials. So what else is new?
---
Glen Blankenship
obo...@netcom.com
gl...@pobox.com <--- Please note new permanent e-mail address
Paul Hsieh
> Mike Schmit <msc...@ix.netcom.com> wrote:
> :sta...@yantra.anyware-fast.com (Stacey Campbell) writes:
> :>That aside, do you seriously think that a `good' assembly language
> :>programmer can keep a P5 or P6 pipeline busy in a useful way for any
> :>substantial amount of code (e.g. the many large chunks of critical code
> :>in an X DDX) better than the compiler writers at Intel who sat
> :>cheek-by-jowl with the people that actually designed the chip?
You make it sound like you know squat about how Intel works with compiler
developers. Intel simply asks these compiler companies what they can and
cannot do, Intel in turn gives these compiler writing companies insights
into exactly how the instruction cache works, details about the branch
prediction algorithm and so on. The collusion is not to the extent that
code generated by compiers is completely unbeatable.
The results of this sort of collusion can be readily seen in the WATCOM
C/C++ compiler. Previous to the 386/486 generation of CPUs WATCOM's
compilers always emphasized code size, which in of itself gave hard to
match performance on 286s and below. With version 9.0 of their compiler
they had clearly already been working closely with Intel who told them
that size would not be nearly as much of a performance factor and this
is reflected in WATCOM's substantially larger (but still smaller than MS
or Borland) object code with version's 9.0 and up.
But all these 32 bit x86 optimization techniques are now a matter of record
and are well known. A skilled assembly coder should have no trouble out
doing even the best C/C++ optimizers.
> :Yes, depending on your definition of 'good.' The typical output of,
> :for example, MS VC++ 2.x and 4.0, as analyzed by Intel's Vtune product
> ^^
I don't know about the 2.x product, but the 4.0 object code doesn't look
all that bad from what I've sampled.
> :and my company's PentOpt product, will show you how bad it is. I'm not
> :going to get into a big debate over this, but unless you have actually
> :looked at the compiler output, then you are just assuming that it
> :must be good.
To be fair, compiler writers in a sense do get first crack at petal to
the metal performance optimizations whenever Intel comes out with a new
chip, since Intel gives them information in advance of their general
dissemination of such information. However once the specs are out there
(or once the chips become well understood) hand coded assembly will beat
compilers hands down.
> Yes, Micro$oft does produce shitty compilers. So what else is new?
> Did you consider looking at the output of real compilers?
MS's VC 4.0 is not as bad as you might think. I'm not sure what they've
been doing out there in Redmond, but all I know is that their compiler
is actually getting competitive. But the same thing still applies to
WATCOM C/C++ and DJGPP.
Example:
Suppose we have the follow C code:
#define min(a,b) (((a)>(b))?(b):(a))
[...]
a = min(a,b);
[...]
What kind of code is your compiler going to give you? If its bad
(read: Borland) it'll look like:
mov eax,[bp+$a]
mov ebx,[bp+$b]
cmp eax,ebx
jg $1
mov [bp+$a],eax
jmp $2
$1:
mov [bp+$b],ebx
$2:
If its good (I haven't tested, but I think DJGPP, WATCOM and MSVC40 will
all give the following) it'll look like:
cmp eax,ebx
jle short $1
mov eax,ebx
$1:
But where is the result stored you ask? Modern compilers try to keep
values around in registers as much as possible, which of course is a
good idea. But no compiler I know of will give the following:
sub ebx,eax
sbb edx,edx
and edx,ebx
add eax,edx
It takes a good coder (or an experienced one) to see this trick. It also
takes a fair amount of knowledge to know *why* the last coding sequence
executes more quickly than the previous two (on a P6 is should go more
than twice as fast on average.) If you don't see why, I'll give you a
hint: It has nothing to do with pipe-lining or register contention, but
it does have to do with something else I mentioned earlier in this post.
--
Paul Hsieh
q...@xenon.chromatic.com
What I say and what my company says are not always the same thing
Paul Hsieh
> Hi,
> >>>>> ch...@BIX.com (Christopher HILL) writes:
>
> Christopher> While compilers are getting better and better at
> Christopher> optimizing code, a good assembly language programmer can
> Christopher> always equal or beat a compiler. This is especially true
> Christopher> for the x86 line of processors. To say otherwise is
> Christopher> foolish.
>
> Certainly you can imagine some human being better or equal at
> optimizing than a compiler
You make it sound like we are rare.
> [...] (the one designing the compiler, perhaps,
> but not necessarely...).
How about the 10 people designing the compiler? Or people like me who
primary job function is to write high performance x86 driver code? What
about all those DEMO coders like Future Crew, Triton, Complex Media Labs.
Then there are people who write books about code optimization like Mike
Abrash, and Mike Schmidt (sp?). As good as it would make me feel, people
who can code circles around compilers are not as rare as you might think.
> [...] But heck, these people cost more than the average compiler and
> are of course much slower.
Mostly true. :) I might be able to debate you on the slower part, but
in all honesty I can whip out bad C-code a lot faster than good ASM
code.
> Your point seems pretty moot.
Don't tell that to my boss! He has this crazy notion that if I can make
the graphics display driver produce faster Benchmark numbers than our
competitors that our company will win over multi-million dollar contracts.
Glad I've fooled him for this long ...
> Code-optimizing: restricted environment,
You mean performance related tasks like 3D graphics and MPEG. Perhaps, you
are right. Database and COBOL programming must be the wave of the future
...
> [...] relatively small number of possibilities
Depends on what possiblities you are capable of seeing. In terms of
coding possibilities, the x86's perverted nature makes it a prime
candidate for creative optimization ideas. In terms of employment
possibilities ... well lets just say Southern California has a position
for just about any hacker worth his weight in Silicon.
> [...] - this reminds me of chess...
Chess has a small number of possibilities? You must be one of the self
righteous, frustrated go players.
Joe Buck
>While compilers are getting better and better at optimizing code, a good
>assembly language programmer can always equal or beat a compiler. This is
>especially true for the x86 line of processors. To say otherwise is
>foolish.
A good assembly language programmer can always beat a compiler GIVEN
SUFFICIENT TIME. In real life, with shrinking time-to-market and
competitive pressures, he/she isn't going to get that time, except
possibly for replacing small "hot spots" with assembly language code.
--
-- Joe Buck <jb...@synopsys.com> (not speaking for Synopsys, Inc)
Work for something because it is good,
not just because it stands a chance to succeed. -- Vaclav Havel
Massimo Campostrini
In article <4icune$p...@yantra.anyware-fast.com> sta...@yantra.anyware-fast.com (Stacey Campbell) writes:
> You may be making a valid point in a world without project deadlines,
> bug lists, code that must be reused for the next slightly different
> rev of a graphics chip, etc. but in the real world where code must ship,
> and it must be fast, and it must be bug free, and it must be easily
> modified for reuse, the above attitude will get you in a world of trouble.
In scientific computing, often a code has to run for a HUGE amount of
time on a machine. It is not unusual to have a large fraction of the
time spent in a tiny section of the code (less then 1%). Then it may
make sense to recode in assembler this tiny fraction.
To give you an example, back in the times when the Cray 1 was the
fastest computer, and its CPU time was outrageous expensive, and young
researchers' time was cheap (well, this is still true), I wrote a
3000-line Fortran numerical simulation code. Then I profiled it and
discovered that 45% of the time was spent in a 6-line subroutine. I
rewrote the routine in 200 lines of assembler, and it was 50% faster.
This routine survived until the last Cray YMP was retired; by that
time, my assembler was only 20% faster then Fortran, due to different
hardware and to compiler improvement, but it was still faster.
--
Massimo Campostrini,
Istituto Nazionale di Fisica Nucleare, Sezione di Pisa.
e-mail: ca...@sunthpi3.difi.unipi.it
WWW home page: http://www.difi.unipi.it/~campo/
Justin Rhys Thuryn McNutt
: ch...@BIX.com (Christopher HILL) writes:
: >While compilers are getting better and better at optimizing code, a good
: >assembly language programmer can always equal or beat a compiler. This is
: >especially true for the x86 line of processors. To say otherwise is
: >foolish.
: A good assembly language programmer can always beat a compiler GIVEN
: SUFFICIENT TIME. In real life, with shrinking time-to-market and
: competitive pressures, he/she isn't going to get that time, except
: possibly for replacing small "hot spots" with assembly language code.
For the last time, he said "a good assembly language programmer *can*
always equal or beat a compiler", not *should*. In other words, he
didn't say that everyone should just forget compilers and write assembly
all the time. He just said that humans can beat compilers.
Writing in C and letting the compiler do the work gives you faster
development, more reliability, and more portability. However, if you
want speed and you are shipping your product pre-compiled (DOS apps), it
might be well worth the time to recode parts of the program in assembly.
I believe one person already pointed out that his video decoder went from
20 to 28 frames per second after he recoded some of the routines. A 50%
increase in speed *is* significant.
You won't always see 50% increases in speed, I realize, but assembly
coded by humans *is* faster than assembly output from a compiler, but in
most cases it isn't as *cost effective*, which is, I believe what a lot
of people here are *really* griping about.
So can it drop now?
--
Westheimer's Discovery:
A couple of months in the laboratory can frequently save a couple of
hours in the library.
Don't let your mind wander -- it's too little to be let out alone.
Mike Schmit
>
>In <4idts8$i...@dfw-ixnews4.ix.netcom.com>, Mike Schmit <msc...@ix.netcom.com>
wrote:
>:Campbell) writes:
>:>That aside, do you seriously think that a `good' assembly language
>:>programmer can keep a P5 or P6 pipeline busy in a useful way for any
>:>substantial amount of code (e.g. the many large chunks of critical code
>:>in an X DDX) better than the compiler writers at Intel who sat
>:>cheek-by-jowl with the people that actually designed the chip?
>:Yes, depending on your definition of 'good.' The typical output of,
>:for example, MS VC++ 2.x and 4.0, as analyzed by Intel's Vtune
product
> ^^
>
>
not
>:going to get into a big debate over this, but unless you have
actually
>:looked at the compiler output, then you are just assuming that it
>:must be good.
>
>Did you consider looking at the output of real compilers?
I make no apologies for Microsoft. However, their VC++ scores very well
on all benchmarks I've seen. And, in reality, there is very little
difference among all the compilers. I've personally used BC++, Symantec
and MSVC. They are all about the same. Reportedly, Watcom's strength
is that it produces good FPU code.
Mike Schmit
-------------------------------------------------------------------
msc...@ix.netcom.com author:
408-244-6826 Pentium Processor Programming Tools
800-765-8086 ISBN: 0-12-627230-1
-------------------------------------------------------------------
Stephan F. Jou
>You may be making a valid point in a world without project deadlines,
>bug lists, code that must be reused for the next slightly different
>rev of a graphics chip, etc. but in the real world where code must ship,
>and it must be fast, and it must be bug free, and it must be easily
>modified for reuse, the above attitude will get you in a world of trouble.
[ snip ]
>Clearly the answer is `no'. To say otherwise shows you've never used an
>optimizer that knows how to build good Pentium assembly and you've never
>shipped a major software product with large areas of performance critical
>code.
I program on very large, commercial software projects and just yesterday we
identified a critical loop in our algorithm which I rewrote and
hand-optimized in assembly (optimized for Pentium pipelining). The end result
was a seven-fold speed increase over the compiler output.
While it's true that compilers are a lot better than they used to be,
especially in terms of global optimizations, it is a bit premature to say
that human-designed assembly has lost a place in software development, IMHO.
>--
>Stacey Campbell sta...@anyware-fast.com http://www.anyware-fast.com/stacey/
>Have stuff identified at http://www.anyware-fast.com/stacey/animal.html
Take care,
StEpHaN!
--
Stephan Jou | "The best thing for being sad," replied Merlyn,
ste...@synapse.net | beginning to puff and blow, "is to learn something."
Steph...@cognos.com | - T. H. White, _The Once and Future King_
ch...@wiloyee.shnet.org
: Hi,
:
: >>>>> In article <4ib716$q...@news2.delphi.com>,
: >>>>> ch...@BIX.com (Christopher HILL) writes:
:
: Christopher> While compilers are getting better and better at
: Christopher> optimizing code, a good assembly language programmer can
: Christopher> always equal or beat a compiler. This is especially true
: Christopher> for the x86 line of processors. To say otherwise is
: Christopher> foolish.
:
: Certainly you can imagine some human being better or equal at
: but not necessarely...). But heck, these people cost more than the
: average compiler and are of course much slower. Your point seems
: pretty moot.
it is my OPINION, that a good compiler creates better code than a good
assembler programmer if the assembler programmers does not
want to spend a lot of time on the code. But if a good assembler programmer
knows how to do it and takes this extra time (i am talking about hours or
days for one small subroutine), he will ace out every compiler on this
planet.
examples:
- which compiler uses waitstates after writes with respect to
weather the data goes to video ram or main memory? I did.
- why are most of the string and memory routines in gnu clib (memcpy, memcmp,
strlen, memset,..) written in assembler? this was really a lot of work for
them, because they support quite a lot of cpu's, and sometimes they have
to rewrite the assembler code because of changed linking
perhaps a very good assembler coder can even write better code than a
compiler on the fly (at least i think i can do this on mc68040, but i doupt
anybody can do it on a pentium).
dierk "chaos" ohlerich
Alain Knaff
:I make no apologies for Microsoft.
Hey, but it sure looks like you do :)
: However, their VC++ scores very well
:on all benchmarks I've seen.
How many ads for Micro$oft products were in the magazines where all
these benchmarks results were printed? Draw your own conclusion.
: And, in reality, there is very little
:difference among all the compilers. I've personally used BC++, Symantec
:and MSVC. They are all about the same. Reportedly, Watcom's strength
:is that it produces good FPU code.
^^^^^^^^
:
:
:Mike Schmit
:
:-------------------------------------------------------------------
:msc...@ix.netcom.com author:
:408-244-6826 Pentium Processor Programming Tools
^^^^^^^ :-)
:800-765-8086 ISBN: 0-12-627230-1
:-------------------------------------------------------------------
:
--
Linux - Where do you want to fly today ?
Windows 95 - Makes a grown man cry
Today I found a letter in my mailbox. On the envelope, it said "Gas Bill",
and I thought it was an excellent idea :)
Alain
Juha Laiho
>ch...@BIX.com (Christopher HILL) writes:
>>While compilers are getting better and better at optimizing code, a good
>>assembly language programmer can always equal or beat a compiler. This is
>>especially true for the x86 line of processors. To say otherwise is
>>foolish.
>
>A good assembly language programmer can always beat a compiler GIVEN
>SUFFICIENT TIME. In real life, with shrinking time-to-market and
>competitive pressures, he/she isn't going to get that time, except
>possibly for replacing small "hot spots" with assembly language code.
Well, given the size of the present programs (I believe you should know),
the lifetime of a programmer might become a limiting factor, too.. :-)
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GEEK CODE 3.0) GIT d- s+: a- C++ UH++++$ UL++++ P- L+++ E--- W+ N+++ !K w !O
!M V PS(+) PE Y+ !PGP t- 5? X? R tv- b+ DI? D+ G e+ h!>--- r++ y+
"...cancel my subscription to the resurrection!" (Jim Morrison)
Juergen Exner
A good assembly language programmer can always beat a compiler GIVEN
SUFFICIENT TIME. In real life, with shrinking time-to-market and
competitive pressures, he/she isn't going to get that time, except
possibly for replacing small "hot spots" with assembly language code.
Although I second this, I believe, shrinking time to market etc is not
the major drawback.
Of course everything that a genious compiler can do could be done by a
human assembly programmer at least as well as.
BUT as you already pointed out this requires a lot of time.
AND much more importent the capabilities of humans are restricted!
Think of large software with some 100.000 lines of code in a modern
high level language (and note, in this context I regard C as a nice
assembler, NOT a high level language!).
We only have very poor methods to deal with such large software in
high level languages.
To the very best of my will, I can't image how to deal with those
software written in assembler.
Assembler itself will cause a code explosion of maybe
factor 10 or 100 when counting lines of code.
And assembler has no support for large software.
Therefore the discussion is of very acadamic nature:
Assembler programs might be more efficient, but they are not effectiv.
I rememeber a little story about WW II: Someone proposed to heat up
the atlantic ocean up to 40 or 50 degrees to force the german
submarines to emerge to the surface where they could be defeated
easily.
This project would have been very efficient (really every submarine
would have to emerge) but as you can image, it won't be very
realistic. So it wasn't effectiv at all.
Greetings jue
Stacey Campbell
>I program on very large, commercial software projects and just yesterday we
>identified a critical loop in our algorithm which I rewrote and
>hand-optimized in assembly (optimized for Pentium pipelining). The end result
>was a seven-fold speed increase over the compiler output.
Just about the only part of my original article you didn't quote was the
part that qualifies my post by assuming you are using an optimizer that
knows how to keep a Pentium pipline busy; for example the Optimizing C
Compiler shipped by SCO.
Are you using a compiler with an optimizer specifically designed to create
fast code for a Pentium? If you are then I'd suggest you file a bug report.
If you aren't, then what's your point?
Christopher HILL
>>While compilers are getting better and better at optimizing code, a good
>>assembly language programmer can always equal or beat a compiler. This is
>>especially true for the x86 line of processors. To say otherwise is
>>foolish.
>You may be making a valid point in a world without project deadlines,
>bug lists, code that must be reused for the next slightly different
>rev of a graphics chip, etc. but in the real world where code must ship,
>and it must be fast, and it must be bug free, and it must be easily
>modified for reuse, the above attitude will get you in a world of trouble.
First of all, you have quoted me entirely out of context. At no point was
the question of why assembly language is being used was in question. The
only question was one of whether assembly language was capable of speed
equal to or greater than that of any compiled language.
>That aside, do you seriously think that a `good' assembly language
>programmer can keep a P5 or P6 pipeline busy in a useful way for any
>substantial amount of code (e.g. the many large chunks of critical code
>in an X DDX) better than the compiler writers at Intel who sat
>cheek-by-jowl with the people that actually designed the chip?
In a word: yes. In fact, if you happen to ask the Intel compiler writers
who sat "cheek-by-jowl" with the designers, I'm sure they will admit that,
while the compiler may be very good at filling both pipelines and
optimizing code in general, it is always possible to hand code assembly
language to perform at least as efficiently. (Or, at least, they will if
they have an honest bone in their body and a brain cell in their head.)
Try to realize that practicality and possibility are orthogonal issues.
Just because something is not practical doesn't mean it isn't possible.
Whether it is practical to do this for large amounts of code is not at
issue, though. I have long been a vocal proponent of high-level languages
for most development work, and only optimizing critical sections in
assembly language.
>Clearly the answer is `no'. To say otherwise shows you've never used an
>optimizer that knows how to build good Pentium assembly and you've never
>shipped a major software product with large areas of performance critical
>code.
Not the case at all (on all counts). In fact, your answer tends to indicate
very little experience writing optimized code yourself.
Christopher Hill
VP, Research & Development
The RINS Corporation
Christopher HILL
>Certainly you can imagine some human being better or equal at
>optimizing than a compiler (the one designing the compiler, perhaps,
>but not necessarely...). But heck, these people cost more than the
>average compiler and are of course much slower. Your point seems
>pretty moot.
It's not hard to imagine at all. I work with a number of people able to do
this every day. Sure, good programmers are hard to find, but they aren't
mythical beasts...
>Code-optimizing: restricted environment, relatively small number of
>possibilities - this reminds me of chess...
Ah yes... I guess you have a point. If I were to write some x86 assembly
code, it really would have a limited market---it would only run on, perhaps
80% of the world's (non-imbedded) computers, and that's a pretty restricted
environment :-^.
I can see your point if we were having this discussion about various breeds
of RISC chips, but since I only read the comp.lang.asm.x86 newsgroup, and
you have posted your message here, I think it is your argument that is
pretty moot.
Christopher HILL
>>While compilers are getting better and better at optimizing code, a good
>>assembly language programmer can always equal or beat a compiler.
>Only on small stretches of code. It is a waste of effort to code
>whole programs in assembler. It takes longer and doesn't really
>make the program any faster (the 10%/90% rule). In addition, using
>assembler makes future maintenance harder and throws portability
>out the window.
On any size stretch of code. Please, I'm not saying it is practical to do
so, only that it is possible.
>In my mind, assembler only makes sense in application code for small
>sections that are part of inner loops or are otherwise executed a
>large number of times during a run of the program.
For the most part I agree whole-heartedly. The few exceptions I can think
of all have to do with writing embedded or low-level code that has to deal
specifically with the underlying chip---things like operating systems,
device controllers, etc.
>For that it can make a lot of sense if portability isn't a priority
Absolutely.
Ales Pour
> That aside, do you seriously think that a `good' assembly language
> programmer can keep a P5 or P6 pipeline busy in a useful way for any
> substantial amount of code (e.g. the many large chunks of critical code
> in an X DDX) better than the compiler writers at Intel who sat
> cheek-by-jowl with the people that actually designed the chip?
> Clearly the answer is `no'. To say otherwise shows you've never used an
> optimizer that knows how to build good Pentium assembly and you've never
> shipped a major software product with large areas of performance critical
> code.
> --
> Stacey Campbell sta...@anyware-fast.com http://www.anyware-fast.com/stacey/
We're in linux newsgroup and my question is - where are such compilers?
I THINK like this:
There's GNU C. Using it brings you some advantages - you can find it
on many different platforms and it is available now and here. But
there's at least one disadvantage - it optimizes poorly. As we move towards
more advanced processors like P? and PPC, good optimizing compiler is
necessary. GNU C does a good job on simple 386|486.
(I saw some test results comparing performance of application on Sun
workstation compiled with GNU C and - don't remember the name - 'a native'
Sparc compiler AND THERE WERE DIFFERRENCES).
Have a nice day,
Ales
| Ales Pour |
| student at FEE CTU |
| Prague, Czech Republic |
| http://www.cvut.cz |
Darrell Jefferson
algorithms themselves. If I have a function that I want to write, and I
write it in C, and then rewrite it in assembler, I often change my
algorithm to take advantage of the strengths of the new language.
You are correct that the compiler produces a good rendition of your
C code -- but a good assembly programmer might not do things in quite
the same way. So you really can't compare apples to apples here -- the
human's goal is *not* to render the C code most efficiently into
assembly, but to solve the original coding problem.
The converse of this is also true. Somebody writing code in C who
has a very good understanding of the details of the language can often
produce C code which the compiler is better able to render efficiently.
But few C programmers worry over this kind of optimization because it
increases the development time -- and just because it is hard to do.
Not to mention the fact that it is likely to make the C code harder to
maintain.
I generally am fairly lazy about optimizing my C code. If I'm that
concerned with optimal code, then I use assembly to begin with.
//Darrell
Zsoter Andras
>(I saw some test results comparing performance of application on Sun
>workstation compiled with GNU C and - don't remember the name - 'a native'
>Sparc compiler AND THERE WERE DIFFERRENCES).
I have read the assembly instruction sequences generated by gcc and
a Sun compiler for SPARC. The code produced by the Sun compiler
clearly looks nicer and has fewer unnecessary instructions.
On the otther hand don't forget that the GNU-C is a very powerful dialect
of the C language which is available on many platforms. So if you
need something better that plain ANSI C and have some portability in
the same time, gcc is a good choice.
Andras
xian the desk lisard
. ch...@BIX.com (Christopher HILL) writes:
. >While compilers are getting better and better at optimizing code, a good
. >assembly language programmer can always equal or beat a compiler. This is
. >especially true for the x86 line of processors. To say otherwise is
. >foolish.
. A good assembly language programmer can always beat a compiler GIVEN
. SUFFICIENT TIME. In real life, with shrinking time-to-market and
. competitive pressures, he/she isn't going to get that time, except
. possibly for replacing small "hot spots" with assembly language code.
i'm going to make an audacious claim here.
interpreters are better than compilers, for the world approaching us.
ok... well, the above reason is the key, i believe. interpreters
reduce compilation time to 0, they are better able to live in
interactive environments with simple and effective tools to measure
performance (like profilers) and, if they are well designed, they can
allow the insertion of just these kinds of "hot spot" code exactly
where it's needed. for these days, these parts remain critical, but
processors now are so fast that the rest of the system can probably
tolerate the 33-50% slowdown that a good threaded interpreter can
impose. also, interpreters usually end up with much more compact code
images, and when cache size determines the speed of a program, the
added compactness of the interpretive code may well recover the
slowdown, esp. on riscs.
just a nice controversial thought to keep everyone happy |:>
--
xian the desk lisard -- cdah...@comp.brad.ac.uk
time's taught the killing game herself
NO i taught the killing game
first
xian the desk lisard
. Sure the compiler writers know how to keep the pipelines filled. A very good
. asm programmer also will know that. The difficult trick is designing an
. algorithm that converts an abstract code into assembly that will use those
. pipelines. It is *far* easier for the assembly programmer, because he knows
. exactly which instructions in which order he/she is dealing with, and what the
. context that they are in (what they are _actually_ doing). The compiler
. writer does not know these things, and has to consider a far more general
. case. That is far more difficult, and is why compilers lag behind people in
. optimisation.
. I don't know that much about optimizing programs, but I doubt that there is
. a great deal (there's probably some) of brute force calculations going on.
. That, accuracy and a good memory are the only things which computers have
. which are better than humans. Remember that.
actually, the memory of a human leaves that of a computer standing...
but anyway. the reason humans can code better assembler than
computers is the same reason humans can play better chess than
computers. humans have a brain which was custom-built to execute
non-deterministic algorithms. a human may or may not pick the right
track, but once s/he's picked it, s/he will probably stick to it a
hell of a lot better than a computer which has to deterministically
try everything. it's the quality called "intuition". don't rubbish
it; it's probably the one thing that will keep humans superior to
computers for a long time yet...
Holger Petersen
>non-deterministic algorithms. a human may or may not pick the right
>track
And s/he knows, which directions are mostly take, so to code the
branch only on the exceptions.
And then there are more processor-flags then (non-) ZERO: Cary,
Parity and perhaps more (half cary [1]).
Who remembers the use of the Parity-Flag in ALTAIR-BASIC (by Bil Gates!)
to save some Byte's/cycles - which broke with the advent of the Z80?!
Who still knows the Routine to output error-messages in the same place:
some sequence of innocent [Z80-Style] :
LD BC,3Exx
LD BC,3Eyy
where the '1234' and '1245' - Part was a LD A,xx - Instruction.
All error-exit's jumped into this sequence; first executing one
LD A,xx and then one or more LD BC,xxxx - Instructions.
Not really self-modifying, but ugly...
And I still dream of the RETURN on CONDITION - Codes of 8080/Z80
when assembling 8051 or 8088 - Code.
I know of a 8051-C-Compiler with support for the CARY-Flag.
Greetings, Holger
[*] the famous sequence to convert a nibble into an ASCII-Value
AND 0Fh
ADD 90h
DAA
ADC 40h
DAA
Is there any C-Code on any compiler which can re-produce this?
barrym
: In article <4icune$p...@yantra.anyware-fast.com>, Stacey Campbell wrote:
: >>While compilers are getting better and better at optimizing code, a good
: >>assembly language programmer can always equal or beat a compiler. This is
: >>especially true for the x86 line of processors. To say otherwise is
: >>foolish.
: >You may be making a valid point in a world without project deadlines,
: >bug lists, code that must be reused for the next slightly different
: >rev of a graphics chip, etc. but in the real world where code must ship,
: >and it must be fast, and it must be bug free, and it must be easily
: >modified for reuse, the above attitude will get you in a world of trouble.
: First of all, you have quoted me entirely out of context. At no point was
: the question of why assembly language is being used was in question. The
: only question was one of whether assembly language was capable of speed
: equal to or greater than that of any compiled language.
:
: >That aside, do you seriously think that a `good' assembly language
: >programmer can keep a P5 or P6 pipeline busy in a useful way for any
: >substantial amount of code (e.g. the many large chunks of critical code
: >in an X DDX) better than the compiler writers at Intel who sat
: >cheek-by-jowl with the people that actually designed the chip?
: In a word: yes. In fact, if you happen to ask the Intel compiler writers
: who sat "cheek-by-jowl" with the designers, I'm sure they will admit that,
: while the compiler may be very good at filling both pipelines and
: optimizing code in general, it is always possible to hand code assembly
: language to perform at least as efficiently. (Or, at least, they will if
: they have an honest bone in their body and a brain cell in their head.)
: Try to realize that practicality and possibility are orthogonal issues.
: Just because something is not practical doesn't mean it isn't possible.
: Whether it is practical to do this for large amounts of code is not at
: issue, though. I have long been a vocal proponent of high-level languages
: for most development work, and only optimizing critical sections in
: assembly language.
: >Clearly the answer is `no'. To say otherwise shows you've never used an
: >optimizer that knows how to build good Pentium assembly and you've never
: >shipped a major software product with large areas of performance critical
: >code.
: Not the case at all (on all counts). In fact, your answer tends to indicate
: very little experience writing optimized code yourself.
Most optimizations in assembly will be pretty short which means the
programmer is operating in "burst mode". The compiler is looking
at the overall view. I think that should be part of the equation,
also. I can do spectacular things, but not consistantly.
Barry
Steve Roome
If any of you folks out there who think compilers are better than humans
have written compilers then I can't blame you.
If I was going to write a program in language X (say C) and I had written
a compiler for this language then I should be able to write the C that the
compiler is going to turn into optimal code.
But, it does require an inside knowledge of how the compiler works.
If you don't know how the compiler works then joe bloggs is going to get
better results with assembler than any language, in that it will be more
efficient code (probably) although it may mean joe has to go and learn
assembler and then spend a couple of years coming to terms with 12398239
different mnemonics.
There is little point in writing large applications in assembler nowadays
anyway, when you can sell the same application as someone who assembled it
by hand three months (years probably =) ) earlier who cares if yours is
slower, by the time the hand optimised version comes out there will be some
sparkling new machine which your version runs faster on...
I'd personally rather write assembler though, it's way more interesting..
--
,-------------------------------------------------------------,
| Stephen Roome | ro...@cs.bris.ac.uk |
| Bristol, UK. | http://www.cs.bris.ac.uk/~roome/ |
'-------------------------------------------------------------'