Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Thread

RE: [lpc2000] GNU is slow!

RE: [lpc2000] GNU is slow!

2005-01-04 by Paul Curtis

Our testing reveals that GCC for ARM isn't that slow and is being
portrayed in a less-than-flattering light.  Michael has data on the
various ARM cores and their Dhrystone ratings.

Rgds,

--
Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
CrossWorks for MSP430, ARM, and now AVR processors   
Show quoted textHide quoted text
> -----Original Message-----
> From: Gus [mailto:gus_is_working@yahoo.com] 
> Sent: 04 January 2005 17:00
> To: lpc2000@yahoogroups.com
> Subject: [lpc2000] GNU is slow!
> 
> 
> 
> I found this. Any comments? Is GNU this bad?
> 
> http://www.keil.com/benchmks/carm_v0code.htm
> 
> 
> After all, it is free.
> 
> Gus
> 
> 
> 
> 
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 
> 
>

GNU is slow!

2005-01-04 by Gus

I found this. Any comments? Is GNU this bad?

http://www.keil.com/benchmks/carm_v0code.htm


After all, it is free.

Gus

Re: [lpc2000] GNU is slow!

2005-01-04 by Michael Johnson

Hi Gus,

We've tweaked the CrossWorks C library a bit and will be releasing it 
this week. Find attached html file that will appear on our web site shortly.

Regards
Michael

> Our testing reveals that GCC for ARM isn't that slow and is being 
> portrayed in a less-than-flattering light.  Michael has data on the 
> various ARM cores and their Dhrystone ratings.
>
> Rgds,
>
> --
> Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
> CrossWorks for MSP430, ARM, and now AVR processors  
>
> > -----Original Message-----
> > From: Gus [mailto:gus_is_working@...]
> > Sent: 04 January 2005 17:00
> > To: lpc2000@yahoogroups.com
> > Subject: [lpc2000] GNU is slow!
> >
> >
> >
> > I found this. Any comments? Is GNU this bad?
> >
> > http://www.keil.com/benchmks/carm_v0code.htm
> >
> >
> > After all, it is free.
> >
> > Gus
> >
> >
> >
> >
> >
> > 
> > Yahoo! Groups Links
> >
> >
> >
> > 
> >
> >
> >
> >
> >
>



[Non-text portions of this message have been removed]

RE: [lpc2000] GNU is slow!

2005-01-04 by Bill Knight

Also note the tests were performed running in Thumb (not ARM)
mode.  Also there is not comment about thumb-interworking.
gcc does not mix ARM and Thumb modes for a single C source file,
so there maybe some extra overhead with the thumb-interworking
code for gcc that is not needed by the other compilers.

It would have been nice if the code was just straight ARM mode
(but the results may not have been nearly so dramatic).

-Bill Knight
http://www.theARMPatch.com


On Tue, 4 Jan 2005 16:55:32 -0000, Paul Curtis wrote:

Our testing reveals that GCC for ARM isn't that slow and is being
portrayed in a less-than-flattering light.  Michael has data on the
various ARM cores and their Dhrystone ratings.

Rgds,

--
Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
CrossWorks for MSP430, ARM, and now AVR processors   
Show quoted textHide quoted text
> -----Original Message-----
> From: Gus [mailto:gus_is_working@...] 
> Sent: 04 January 2005 17:00
> To: lpc2000@yahoogroups.com
> Subject: [lpc2000] GNU is slow!
> 
> 
> 
> I found this. Any comments? Is GNU this bad?
> 
> http://www.keil.com/benchmks/carm_v0code.htm
> 
> 
> After all, it is free.
> 
> Gus

Re: GNU is slow!

2005-01-04 by Gus

what html? what is the link to it on your website.
I am trying to convince people here that GNU is not that bad and our 
purchace of CrossWorks was a great idea. You guys should do some 
tests and show some results.

By the way, nice job on the new website :-)

Gus

--- In lpc2000@yahoogroups.com, Michael Johnson <mpj@r...> wrote:
> Hi Gus,
> 
> We've tweaked the CrossWorks C library a bit and will be releasing 
it 
> this week. Find attached html file that will appear on our web 
site shortly.
> 
> Regards
> Michael
> 
> > Our testing reveals that GCC for ARM isn't that slow and is 
being 
> > portrayed in a less-than-flattering light.  Michael has data on 
the 
Show quoted textHide quoted text
> > various ARM cores and their Dhrystone ratings.
> >
> > Rgds,
> >
> > --
> > Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
> > CrossWorks for MSP430, ARM, and now AVR processors  
> >
> > > -----Original Message-----
> > > From: Gus [mailto:gus_is_working@y...]
> > > Sent: 04 January 2005 17:00
> > > To: lpc2000@yahoogroups.com
> > > Subject: [lpc2000] GNU is slow!
> > >
> > >
> > >
> > > I found this. Any comments? Is GNU this bad?
> > >
> > > http://www.keil.com/benchmks/carm_v0code.htm
> > >
> > >
> > > After all, it is free.
> > >
> > > Gus
> > >
> > >
> > >
> > >
> > >
> > > 
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > > 
> > >
> > >
> > >
> > >
> > >
> >
> 
> 
> 
> [Non-text portions of this message have been removed]

RE: [lpc2000] Re: GNU is slow!

2005-01-04 by Paul Curtis

Mike,

This group will strip attachments. 

GUS, Dhrystone is *heavily* slanted to the performance of strcmp,
strcpy, and structure copy (aka memcpy).  Very heavily.  It's not a
particularly good performance metric, as everybody knows, but it exists.
As such, Dhrystone figures are almost meaningless, because in an
embedded system Dhrystone ratings may differ if your strings are held in
FLASH rather than RAM (just as a "for instance").

We reckon that Keil benchmarked with a baggy libc implementation which
makes it big, and we don't understand any of the numbers Keil produced
for GCC, they're way out to lunch.

Rgds,

--
Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
CrossWorks for MSP430, ARM, and now AVR processors  
Show quoted textHide quoted text
> -----Original Message-----
> From: Gus [mailto:gus_is_working@...] 
> Sent: 04 January 2005 17:46
> To: lpc2000@yahoogroups.com
> Subject: [lpc2000] Re: GNU is slow!
> 
> 
> 
> what html? what is the link to it on your website.
> I am trying to convince people here that GNU is not that bad 
> and our purchace of CrossWorks was a great idea. You guys 
> should do some tests and show some results.
> 
> By the way, nice job on the new website :-)

Re: GNU is slow!

2005-01-04 by sig5534

>> I found this. Any comments? Is GNU this bad?

Ya know, it is really getting funny how hard these guys with the 
proprietary compilers are trying to convince people that their $XXXX 
price tags are worth it.  The market is falling out from under them 
and they know it.  It appears they are staking their whole sales 
pitch on the idea of better optimized code than GNU.

Well I have two things to say about that:

(1) I used several of these proprietary compilers, and I ran into 
serious bugs.  It matters little how good some optimization is when 
the damn compiler has serious bugs.  Who cares about optimization.  I 
need a compiler that works - period.  

I ended up dumping the proprietary compilers and moved my code to 
GNUARM.  I got up an running on that in a couple days, and it is now 
giving me results that make sense and are predictable.

(2) After doing embedded projects for 25 years, usually in asm, I 
can't even remember that many times where I even cared much about 
optimization.  I just wanted the code to work and fit in the 
available ROM.  Optimization may matter on some projects, but the 
fact is most of the time it is largely unimportant.  It's certainly 
no good for debugging.

GNU is good enough to compile Linux on many different platforms.  The 
focus is on reliability.  I appreciate that.

About the only proprietary compiler that I would put big money out to 
buy is ARM ADS.  Other than that I'll stick with GNUARM.

Chris.

Re: [lpc2000] Re: GNU is slow!

2005-01-04 by Leon Heller

----- Original Message ----- 
Show quoted textHide quoted text
From: "sig5534" <sig5534@...>
To: <lpc2000@yahoogroups.com>
Sent: Tuesday, January 04, 2005 7:12 PM
Subject: [lpc2000] Re: GNU is slow!


>
>>> I found this. Any comments? Is GNU this bad?
>
> Ya know, it is really getting funny how hard these guys with the
> proprietary compilers are trying to convince people that their $XXXX
> price tags are worth it.  The market is falling out from under them
> and they know it.  It appears they are staking their whole sales
> pitch on the idea of better optimized code than GNU.
>
> Well I have two things to say about that:
>
> (1) I used several of these proprietary compilers, and I ran into
> serious bugs.  It matters little how good some optimization is when
> the damn compiler has serious bugs.  Who cares about optimization.  I
> need a compiler that works - period.
>
> I ended up dumping the proprietary compilers and moved my code to
> GNUARM.  I got up an running on that in a couple days, and it is now
> giving me results that make sense and are predictable.
>
> (2) After doing embedded projects for 25 years, usually in asm, I
> can't even remember that many times where I even cared much about
> optimization.  I just wanted the code to work and fit in the
> available ROM.  Optimization may matter on some projects, but the
> fact is most of the time it is largely unimportant.  It's certainly
> no good for debugging.
>
> GNU is good enough to compile Linux on many different platforms.  The
> focus is on reliability.  I appreciate that.
>
> About the only proprietary compiler that I would put big money out to
> buy is ARM ADS.  Other than that I'll stick with GNUARM.

When I worked at Racal Comms the software engineers in our group gave up 
with the very expensive compiler they were supposed to use because it had so 
many bugs and used gcc instead. They didn't tell anyone about it and our 
manager was rather shocked when someone told him what they were using, some 
months later.

Leon 



-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.298 / Virus Database: 265.6.7 - Release Date: 30/12/2004

Re: GNU is slow! / generates larger code

2005-01-04 by lpc2100_fan

Hi,

given that you have "unlimited" memory resources, and you do not need
to optimize the last 20-50% performance out of your application, GNU
is probably a great solution. In my opinion you do have unlimited
memory if you migrate an 8-bit application using 8k code into a 32-bit
ARM device with 64K code or more. Also you performance is almost
unlimited compared to the 8-bit device, why bother with optimizations?
If you however need to fit your code into a 32kbytes memory because
you will manufacture 10000, 100k or more of the same device, it does
make a difference to buy a 32k or a 64k device. The offset might be
just 50 cent but multiplied with 100k it adds up. The same is true for
performance. If you need to run the micro 30% faster to get the same
performance, you eat up 30% more (battery?) power. 

My experience with GNU tools is limited, did some benchmarks (we
prefer propriety tools) but the libraries suck! Using libs blows up
the code to multiples of propriety compilers, it also slows down the
performance to a factor of way below 50% of other compilers during
extensive usage of lib-functions. General code outside libs was about
20-30% larger than e.g. ARM ADS generated code. More difference when
using Thumb and ARM mixed code.

Using the LPC2000 in the small packages, 48 or 64 pins leaves you with
limited resources in memory. Making the best use of this memory is not
going to happen with the GNU compiler. 

If you are however doing a project that needs to have minimal
investment and can deal with a living being like the GNU compiler (how
many releases in 12 months?) constantly migrating your code or being
left behind, the GNU compiler is probably your best solution.
btw. my salary is not paid by one the of the compiler vendors ;-)

Buying a prop. compiler    -xxx $
Saving memory space        +xxx $
Being 20-30% faster        +xxx $
Calling the 1-800 support number of the compiler vendor -> priceless

Cheers, Bob

RE: [lpc2000] Re: GNU is slow!

2005-01-04 by Paul Curtis

Chris, 

> >> I found this. Any comments? Is GNU this bad?
> 
> Ya know, it is really getting funny how hard these guys with 
> the proprietary compilers are trying to convince people that 
> their $XXXX price tags are worth it.  The market is falling 
> out from under them and they know it.  It appears they are 
> staking their whole sales pitch on the idea of better 
> optimized code than GNU.

The demise of proprietary compiler vendors has long been prophesized,
but doesn't happen.  There are always users for whom GNU products are
not a good fit for one reason or another.  Just like in any other walk
of life, you choose a particular path to fit your needs and free or open
source software is not a good fit for all users.

> Well I have two things to say about that:
> 
> (1) I used several of these proprietary compilers, and I ran 
> into serious bugs.  It matters little how good some 
> optimization is when the damn compiler has serious bugs.  Who 
> cares about optimization.  I need a compiler that works - period.  

Every compiler has problems, period.  Every compiler can be improved, it
follows from the halting problem,  and is the unpinning of the Permanent
Employment Lemma for compiler engineers.  Formally validating a compiler
for correctness is well beyond the resources of many companies (and even
defeats the UK's MOD), especially for a language like C, and C++ is an
order of magnitude more complex.  There are, however, formally validated
compilers for subsets of strictly-typed languages but these are not
usually the type of language and compiler many users would freely
choose.

The GNU compiler for ARM has bugs, just like every other compiler, it's
a fact of life which follows from the inherent complexity of building a
compiler from a natural language specification.

--
Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
CrossWorks for MSP430, ARM, and now AVR processors

Re: [lpc2000] Re: GNU is slow!

2005-01-04 by Richard

At 11:55 AM 1/4/2005, Leon Heller wrote:
>...
>When I worked at Racal Comms the software engineers in our group gave up
>with the very expensive compiler they were supposed to use because it had so
>many bugs and used gcc instead. They didn't tell anyone about it and our
>manager was rather shocked when someone told him what they were using, some
>months later.

I don't know what this says about expensive or GNU expensive, but it sure 
sounds like a major problem with the team. :-)


// richard (This email is for mailing lists. To reach me directly, please 
use richard at imagecraft.com)

Re: [lpc2000] Re: GNU is slow!

2005-01-05 by Michael Anburaj

For those who are interested.

I have numbers from running Dhrystone (Clipping from a
larger table, ran on various processor architectures &
boards).

It compares SDT against gcc 3.4.0 (GNU-ARM) on
LPC1206.
http://www.geocities.com/michaelanburaj/downloads/dhry_lpc.gif

For those who are not aware of SDT: SDT is a older
tools used by ARM. ADS should follow along the same
numbers as SDT.

Also I have stack size comparison by running uCOS-II
Example#2 code (which estimates stack usage of all the
active tasks).
http://www.geocities.com/michaelanburaj/downloads/ucos_ex2.txt

I use both gcc & ARM tools (ADS & SDT) heavily. Gcc
(for ARM/THUMB) is not bad at all!


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

Re: [lpc2000] Re: GNU is slow! -- Dhry numbers

2005-01-05 by Michael Anburaj

For dhry/sec, multiply the DMIPS with 1757 in the
following table (Dhrystone Version 2.1 on LPC2106
h/w),

http://www.geocities.com/michaelanburaj/downloads/dhry_lpc.gif

-Mike.

--- Michael Anburaj <embeddedeng@...> wrote:

> For those who are interested.
> 
> I have numbers from running Dhrystone (Clipping from
> a
> larger table, ran on various processor architectures
> &
> boards).
> 
> It compares SDT against gcc 3.4.0 (GNU-ARM) on
> LPC1206.
>
http://www.geocities.com/michaelanburaj/downloads/dhry_lpc.gif
> 
> For those who are not aware of SDT: SDT is a older
> tools used by ARM. ADS should follow along the same
> numbers as SDT.
> 
> Also I have stack size comparison by running uCOS-II
> Example#2 code (which estimates stack usage of all
> the
> active tasks).
>
http://www.geocities.com/michaelanburaj/downloads/ucos_ex2.txt
> 
> I use both gcc & ARM tools (ADS & SDT) heavily. Gcc
> (for ARM/THUMB) is not bad at all!
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam
> protection around 
> http://mail.yahoo.com 
> 



		
__________________________________ 
Do you Yahoo!? 
Meet the all-new My Yahoo! - Try it today! 
http://my.yahoo.com

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.