commercial c compilers vs free c compilers

M

Malcolm

Stephen Sprunk said:
No, the point was that a good programmer with a bad compiler will produce
faster code in the end than a bad programmer with a good compiler. At
best, a better compiler lets your programmers spend less time worrying
about low-level optimizations and more time worrying about using the right
algorithm (or playing with something like VTune).
I thought that your point was that speed of development was what matters.
Normally this is the case. The programmer who gets his code out in two days,
executing correctly, is normally doing a better job than the one who gets it
out in three days, running a little bit faster. Not always of course.

If you know that the compiler does a top-notch job on micro-optimisation,
you can write code so that it is easy to read rather than easy to compile.
This means fewer bugs, and bugs very often delay shipping and cause projects
to lose money.
 
S

Stephen Sprunk

Malcolm said:
I thought that your point was that speed of development was what
matters. Normally this is the case. The programmer who gets his
code out in two days, executing correctly, is normally doing a better
job than the one who gets it out in three days, running a little bit
faster. Not always of course.

In the shrink-wrap world, that's definitely true. In the embedded world,
efficiency is a do-or-die proposition because code efficiency dictates what
parts you need to use and what features you can offer -- bad code can cost
you millions by forcing you to use more expensive processors, more memory,
etc. and possibly price you out of the market.

Case in point: one of our coders spent a couple weeks working on tweaking
our product's code to improve performance, and managed to eliminate 55% of
the cycles on a very common operation that's executed thousands of times per
second. Now we have nearly a hundred MIPS more available to add new
features to existing products and it'll be that much longer before we need
to move on to the next CPU. Easily worth the time.

Likewise, our DSP code is written by some phenomenally smart guys, and they
manage to do things the DSP's vendor claims are impossible. Not by
micro-optimization, but by using smarter (and now patented) algorithms.
That work saves us tens of millions of dollars per year by allowing us to
buy a $5 DSP instead of the $20 one -- well worth the years of effort
they've spent (and continue to spend) tweaking things.
If you know that the compiler does a top-notch job on micro-optimisation,
you can write code so that it is easy to read rather than easy to compile.
This means fewer bugs, and bugs very often delay shipping and cause
projects to lose money.

That's the goal. The adage "it's easier to make correct code fast than make
fast code correct" has a lot of merit. We obsess about getting the code
right the first time, and customers notice. Unfortunately, that means
delays sometimes, but we've gotten to the point most customers don't even
test our products before rolling them out to users, because they know our
stuff works out of the box every time. You can't buy that kind of
marketing.

S
 
G

geletine

Stephen said:
Likewise, our DSP code is written by some phenomenally smart guys, and they
manage to do things the DSP's vendor claims are impossible. Not by
micro-optimization, but by using smarter (and now patented) algorithms.
That work saves us tens of millions of dollars per year by allowing us to
buy a $5 DSP instead of the $20 one -- well worth the years of effort
they've spent (and continue to spend) tweaking things.

Vendors want to sell customers the next best thing, any machine can
usually do more than whats the vendor advertises , its possible to use
a c64 to browse the internet, nobody would think so.
http://www.sics.se/~adam/contiki/
To run the new ms vista, consumers will need(according to ms min
specifications, and proberly an acceptible desktop experience ) a fast
computer , its written bloated on purpose so consumers have to buy a
new computer and at the same time buy a vista licence.
Vista is going to be plugged as the next must have product from
microsoft.
If vista was written well as far as optimization goes, vendors would
need a harder advertising campaign to sell there products...
 
K

Keith Thompson

Nils O. Selåsdal said:
I should perhaps add that a optimizing compiler is no substitute
for a good programmer - and often it's the speed of the programmer that
matters :)

A good programmer is also no substitute for an optimizing compiler.
 
B

Ben C

A good programmer is also no substitute for an optimizing compiler.

The first thing a good programmer with no optimizing compiler would do
is get hold of one, even it meant writing it.
 
D

Dann Corbit

Keith Thompson said:
A good programmer is also no substitute for an optimizing compiler.

The speed of the programmer and the speed of the compiler and the
optimization ability of the compiler are all irrelevant compared to the
behavior of the algorithm.

By a landslide, everything else pales in comparison.
 
D

Dann Corbit

Ian Collins said:
A good programmer is also an optimising programmer...

I disagree. The objective of the programmer should be to write code that is
the clearest to understand and easiest to debug and maintain.

Optimization belongs in the few hot-spots that (when profiled) are shown to
be the bits that prevent the final product from meeting the project
specifications for performance.

I agree wholeheartedly with Mike Lee's analysis:
1. The first law of optimzation is: DON'T DO IT.
2. The second law (for experts only) is DON'T DO IT YET.

And when it comes time where we absolutely have to optimize -- little tweaky
things and inline assembly should be an utter last resort, after all
attempts to improve the algorithm have failed.
 
K

Keith Thompson

Ian Collins said:
A good programmer is also an optimising programmer...

But not prematurely. A good programmer knows when to stand back and
let the compiler do its job.
 
I

Ian Collins

Dann said:
I disagree. The objective of the programmer should be to write code that is
the clearest to understand and easiest to debug and maintain.
That's pretty much how I interpreted optimising, I should have stressed
life cycle optimisation.

A good programmer will know how to spot a good algorithm and implement
it cleanly. If further optimisation is required, this code will be
easier to work with and improve.

An appropriate algorithm, well implemented better than a poor one
micro-optimised.
Optimization belongs in the few hot-spots that (when profiled) are shown to
be the bits that prevent the final product from meeting the project
specifications for performance.

I agree wholeheartedly with Mike Lee's analysis:
1. The first law of optimzation is: DON'T DO IT.
2. The second law (for experts only) is DON'T DO IT YET.

And when it comes time where we absolutely have to optimize -- little tweaky
things and inline assembly should be an utter last resort, after all
attempts to improve the algorithm have failed.
Agreed.
 
W

Walter Banks

Ben said:
The first thing a good programmer with no optimizing compiler would do
is get hold of one, even it meant writing it.

The best optimizing compiler in the world will not change a bubble sort
into a quick sort but can make the bubble sort the best that it can be.

Appropriate data types are the single most significant change a developer can do to optimize application code. Unsigned variables are less expensive than signed in many embedded systems.

Optimizing compilers in embedded systems
1) Help reduce EMI by allowing a lower clock speed to solve the same problem

2) Help reduce power requirements with lower clock speeds

3) Compilers are very good accountants managing reuse or RAM

4) More features same part or better all the needed features in a less expensive part

As a compiler vendor there are two ways to optimize standard test suite scores or optimize actual intended reference designs. The later approach will significantly improve compiler performance for the intended users.


w..
 
S

Simon Biber

Morris said:
A long time ago I wrote several thousand line program in Fortran that
had horrible spaghetti execution paths (with computed goto's,
arithmetic if, logical if, fuctions, etc) and did quite a bit of real,
integer, and mixed mode calculation - all to produce a single
one-digit numeric result. The compiler churned away for more than a
half hour and emitted three lines of assembly code. The first line did
a load register immediate with '7' (0x37, the correct result in
character form), the second line did a _branch_ to the resident
printer output routine, and the third line was 'END'. The program
would, as you might expect, exit when the printer routine executed its
RET instruction; and the system would flush the print buffer
automatically.

Would you call that a fast compiler or a slow compiler? [ It was DG
Fortran 5 if you're curious. ]

So I assume your program did not perform any input and its result was
completely deterministic? I'd call that one hell of an optimizer.
 
R

Richard Bos

Rarely if ever.
The speed of the programmer and the speed of the compiler and the
optimization ability of the compiler are all irrelevant compared to the
behavior of the algorithm.

By a landslide, everything else pales in comparison.

Definitely.

When my program is a day late, my users wait a day. That's only
significant when it runs into the months.
When my program is a second slow, my users take another swig from their
coffee. That's only significant when it runs into the minutes per order
or per page.

When my program crashes or destroys data, that's your hours wasted a day
right there.

Richard
 
A

av

i add a combination
A good programmer is also an optimising compiler
I disagree. The objective of the programmer should be to write code that is
the clearest to understand and easiest to debug and maintain.

for me it is enought that work well and not stress the poor cpu
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top