Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > A Portable C Compiler

Reply
Thread Tools

A Portable C Compiler

 
 
jacob navia
Guest
Posts: n/a
 
      09-19-2007
Richard Heathfield wrote:
> Since I killfiled Mr Navia, people have stopped complaining at me for
> arguing with him all the time. I am not ungrateful for this. I have
> noticed, however, a marked increase in the rate with which *other people*
> are arguing with him.


Sniff, sniff....

 
Reply With Quote
 
 
 
 
jacob navia
Guest
Posts: n/a
 
      09-19-2007
Charlie Gordon wrote:
> "CBFalconer" <(E-Mail Removed)> a écrit dans le message de news:
> http://www.velocityreviews.com/forums/(E-Mail Removed)...
>> jacob navia wrote:
>> ... snip ...
>>> Each time you make a change in C you have to rebuild. for many
>>> projects, a change can affect a lot of files. Global changes that
>>> need a full recompilation are done not VERY often, but they are
>>> done...
>>>
>>> This means that a compiler that slows down the development process
>>> by just 30-60 seconds per build, it is taking between 15-30
>>> minutes per day to each developer...

>> To me, the requirement for such a long routine compile indicates
>> mis-organization. Normally you would only be modifying one source
>> file, and the rebuild should be limited to recompiling that and
>> relinking. Sometimes the associated .h file may need revision, and
>> then (rarely) the work can become considerably larger. So in
>> general the compilation should not be a problem, however the
>> linking may be.

>
> I suspect the project Jacob is talking about is actually mostly C++.
>


Yes, as I said the company uses C++

> Changing a class header file or a template causes a lot of recompilation,
> and g++ is notoriously slow.
>


The linker is VERY slow, and that hits you even when doing
a trivial change.
 
Reply With Quote
 
 
 
 
Charlie Gordon
Guest
Posts: n/a
 
      09-19-2007
"CBFalconer" <(E-Mail Removed)> a écrit dans le message de news:
(E-Mail Removed)...
> jacob navia wrote:
>>

> ... snip ...
>>
>> Each time you make a change in C you have to rebuild. for many
>> projects, a change can affect a lot of files. Global changes that
>> need a full recompilation are done not VERY often, but they are
>> done...
>>
>> This means that a compiler that slows down the development process
>> by just 30-60 seconds per build, it is taking between 15-30
>> minutes per day to each developer...

>
> To me, the requirement for such a long routine compile indicates
> mis-organization. Normally you would only be modifying one source
> file, and the rebuild should be limited to recompiling that and
> relinking. Sometimes the associated .h file may need revision, and
> then (rarely) the work can become considerably larger. So in
> general the compilation should not be a problem, however the
> linking may be.


I suspect the project Jacob is talking about is actually mostly C++.

Changing a class header file or a template causes a lot of recompilation,
and g++ is notoriously slow.

--
Chqrlie.


 
Reply With Quote
 
user923005
Guest
Posts: n/a
 
      09-19-2007
On Sep 19, 6:54 am, jacob navia <(E-Mail Removed)> wrote:
> Charlie Gordon wrote:
> > "CBFalconer" <(E-Mail Removed)> a écrit dans le message de news:
> > (E-Mail Removed)...
> >> jacob navia wrote:
> >> ... snip ...
> >>> Each time you make a change in C you have to rebuild. for many
> >>> projects, a change can affect a lot of files. Global changes that
> >>> need a full recompilation are done not VERY often, but they are
> >>> done...

>
> >>> This means that a compiler that slows down the development process
> >>> by just 30-60 seconds per build, it is taking between 15-30
> >>> minutes per day to each developer...
> >> To me, the requirement for such a long routine compile indicates
> >> mis-organization. Normally you would only be modifying one source
> >> file, and the rebuild should be limited to recompiling that and
> >> relinking. Sometimes the associated .h file may need revision, and
> >> then (rarely) the work can become considerably larger. So in
> >> general the compilation should not be a problem, however the
> >> linking may be.

>
> > I suspect the project Jacob is talking about is actually mostly C++.

>
> Yes, as I said the company uses C++
>
> > Changing a class header file or a template causes a lot of recompilation,
> > and g++ is notoriously slow.

>
> The linker is VERY slow, and that hits you even when doing
> a trivial change.


GCC is totally irrelevant as far as linking is concerned. The speed
of linking for PCC or any other compiler will not be any different at
all, since both PCC and GCC are going to perform exactly the same link
step using exactly the same linker. The link step is performed by the
operating system's linker, and so the speed of the link won't change
at all unless a compiler vendor supplies its own linker. Microsoft
does that, but then again, they also wrote the operating system for
their compiler so no great surprise there.

I believe that this has all been explained to you before. I think
that you are deliberately being thick here.

 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      09-19-2007
user923005 said:

> On Sep 19, 6:54 am, jacob navia <(E-Mail Removed)> wrote:


<snip>

>> The linker is VERY slow, and that hits you even when doing
>> a trivial change.

>
> GCC is totally irrelevant as far as linking is concerned. [...]
>
> I believe that this has all been explained to you before. I think
> that you are deliberately being thick here.


Hanlon's Razor applies.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
 
Reply With Quote
 
Richard
Guest
Posts: n/a
 
      09-19-2007
A N Other <(E-Mail Removed)> writes:

> On 18 Sep 2007 at 22:32, Rui Maciel wrote:
>> jacob navia wrote:
>>> Yeah, if it compiles C it is of no much use, I know.
>>>
>>> But maybe it *could* be that *some* people *like* C you see?

>>
>> Sarcasm aside, no one has ever stated that no one liked C. As this very
>> thread is taking place in a newsgroup dedicated to the C programming
>> language, that insinuation is rather amusing. Were you trying to fan the
>> flames?

>
> Gee, do you reckon? Jacob's whole modus operandi in this group is to be
> completely unreasonable, get people really riled up, and then when they
> react he plays the victim - "everyone's picking on me!"


That is not what I have seen.

>
> Look at this thread. It serves absolutely no purpose except for Jacob to
> spread a load of FUD about gcc.
>
> Jacob obviously thinks the world owes him a living because he took
> someone else's compiler, knocked up a pretty GUI IDE to go with it, and
> repackaged it as a commercial product. It's clear from his postings to
> this group over several years that he doesn't have the first beginnings
> of a clue about C - he's not just a social pariah, he's technically
> inept to go with it.


Hmm. I see a certain pattern emerging in your style.

>
> This group would be a better place if Jacob would stop posting to it and
> leave us all in peace.


Who is "us"?
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      09-19-2007
user923005 wrote:
> On Sep 19, 6:54 am, jacob navia <(E-Mail Removed)> wrote:
>> Charlie Gordon wrote:
>>> "CBFalconer" <(E-Mail Removed)> a écrit dans le message de news:
>>> (E-Mail Removed)...
>>>> jacob navia wrote:
>>>> ... snip ...
>>>>> Each time you make a change in C you have to rebuild. for many
>>>>> projects, a change can affect a lot of files. Global changes that
>>>>> need a full recompilation are done not VERY often, but they are
>>>>> done...
>>>>> This means that a compiler that slows down the development process
>>>>> by just 30-60 seconds per build, it is taking between 15-30
>>>>> minutes per day to each developer...
>>>> To me, the requirement for such a long routine compile indicates
>>>> mis-organization. Normally you would only be modifying one source
>>>> file, and the rebuild should be limited to recompiling that and
>>>> relinking. Sometimes the associated .h file may need revision, and
>>>> then (rarely) the work can become considerably larger. So in
>>>> general the compilation should not be a problem, however the
>>>> linking may be.
>>> I suspect the project Jacob is talking about is actually mostly C++.

>> Yes, as I said the company uses C++
>>
>>> Changing a class header file or a template causes a lot of recompilation,
>>> and g++ is notoriously slow.

>> The linker is VERY slow, and that hits you even when doing
>> a trivial change.

>
> GCC is totally irrelevant as far as linking is concerned. The speed
> of linking for PCC or any other compiler will not be any different at
> all, since both PCC and GCC are going to perform exactly the same link
> step using exactly the same linker.


If they do that, it would be really stupid.
The linker of GNU is very slow.

But I am not saying that GCC is responsible for the flaws of ld,
even if is in the same tool chain. It was just a remark about the
speed of the link step.

The internal structure of that linker is quite involved, doing several
passes to find constructors, then putting them in an automatically
generated C file, then compiling that (yes, they compile C code
within the link step!!) and then (and only THEN) linking the whole
mess.

The speed of gcc *is* important within the linker since the
linker compiles C code when linking.



I was completely surprised when I discovered that.


> The link step is performed by the
> operating system's linker, and so the speed of the link won't change
> at all unless a compiler vendor supplies its own linker. Microsoft
> does that, but then again, they also wrote the operating system for
> their compiler so no great surprise there.


The OS supplies no linker under windows, That's why I had to write one.
>
> I believe that this has all been explained to you before. I think
> that you are deliberately being thick here.
>


You take a remark as "ld is slow" and just suppose that I am blaming
gcc. No I am not. But... see above
 
Reply With Quote
 
Charlie Gordon
Guest
Posts: n/a
 
      09-20-2007
"jacob navia" <(E-Mail Removed)> a écrit dans le message de news:
46f12bc2$0$27392$(E-Mail Removed)...
> Charlie Gordon wrote:
>> "CBFalconer" <(E-Mail Removed)> a écrit dans le message de news:
>> (E-Mail Removed)...
>>> jacob navia wrote:
>>> ... snip ...
>>>> Each time you make a change in C you have to rebuild. for many
>>>> projects, a change can affect a lot of files. Global changes that
>>>> need a full recompilation are done not VERY often, but they are
>>>> done...
>>>>
>>>> This means that a compiler that slows down the development process
>>>> by just 30-60 seconds per build, it is taking between 15-30
>>>> minutes per day to each developer...
>>> To me, the requirement for such a long routine compile indicates
>>> mis-organization. Normally you would only be modifying one source
>>> file, and the rebuild should be limited to recompiling that and
>>> relinking. Sometimes the associated .h file may need revision, and
>>> then (rarely) the work can become considerably larger. So in
>>> general the compilation should not be a problem, however the
>>> linking may be.

>>
>> I suspect the project Jacob is talking about is actually mostly C++.
>>

>
> Yes, as I said the company uses C++
>
>> Changing a class header file or a template causes a lot of recompilation,
>> and g++ is notoriously slow.
>>

>
> The linker is VERY slow, and that hits you even when doing
> a trivial change.


Your digression on compile times is completely irrelevant to C.
I'm not saying gcc is fast, tinycc is *much* faster and includes the linking
phase too, but your example is irrelevant. C++ projects take a toll on
developpers ? We all know that, we prefer C.

For those who care about build speed, there is a very effective tool called
ccache.

--
Chqrlie.


 
Reply With Quote
 
Peter J. Holzer
Guest
Posts: n/a
 
      09-20-2007
On 2007-09-18 21:51, Rob Kendrick <(E-Mail Removed)> wrote:
> On Tue, 18 Sep 2007 23:31:30 +0200, jacob navia wrote:
>> Of course, only one file is rebuilt. But there is always the link step,
>> what is not fast really, specially with BIG projects.

>
> Woah, 10 minutes of *linking* ? I think it's time you investigate making
> your build system suck less.


I've seen link times in excess of an hour for reasonably-sized programs
(OpenSSH in this case). The +O4 option on the HP ANSI-C compiler causes
global optimization on the whole executable, which can of course only be
done at link time. Of course nobody would use +O4 on an HP system during
the normal edit-compile-test cycle. That's strictly for release
candidates (unless you are looking for a bug which only manifests itself
at that optimization level).

hp


--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | (E-Mail Removed) |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Most portable compiler: llvl llc or pcc or gcc rtl? Ir. Hj. Othman bin Hj. Ahmad C Programming 22 10-19-2012 07:34 PM
Portable (as in literally) C++ compiler/IDE? gordon.is.a.moron@gmail.com C++ 5 03-12-2007 11:19 PM
Portable Python - free portable development environment ! perica.zivkovic@gmail.com Python 7 01-13-2007 11:19 AM
portable (VHDL) vs. non-portable (altera LPM) approaches to signed computations Eli Bendersky VHDL 1 03-01-2006 02:43 PM
Compiler Error Message: The compiler failed with error code 128. Yan ASP .Net 0 07-21-2003 10:49 PM



Advertisments