User: Password:
|
|
Subscribe / Log in / New account

You missed the point

You missed the point

Posted Mar 26, 2008 22:41 UTC (Wed) by sylware (guest, #35259)
In reply to: whatever by elanthis
Parent article: Striking gold in binutils

Anything that makes dependent a system tool on more than the complexity of a C compiler should
be trashed, period. Why? This is my limit for containement of the size/complexity of the
system software stack. I won't go any further.

As you perfectly put forward, a C++ compiler, even a non optimizing one, is hell on earth to
code compared to a C compiler.

A linker as a system C++ program would damage the size/complexity of the system software
stack.

My conclusion is horribly simple:gold has to go to trash and its coder should work on speeding
the properly (namely C) coded ld (oprofile?).






(Log in to post comments)

What a narrow-minded viewpoint!

Posted Mar 26, 2008 22:55 UTC (Wed) by felixfix (subscriber, #242) [Link]

I don't have a list, but I am sure you use tools every day that were developed in some
language other than C. Perl and Python come to mind, but at any rate, restricting your tool
chain to C-based code is not possible nowadays.  It isn't just narrow-minded to want that, it
is burying your head in the sand to pretend it is possible.

You missed the point

Posted Mar 27, 2008 0:47 UTC (Thu) by ncm (subscriber, #165) [Link]

If sylware thinks he understands Gcc's C compiler, it can only be because he hasn't looked at
it in a long, long time.

You missed the point

Posted Mar 27, 2008 0:49 UTC (Thu) by epa (subscriber, #39769) [Link]

gcc has an extremely complex codebase.   Your argument would seem to suggest replacing it with
a simpler C compiler such as pcc, in order to reduce the total complexity of the 'system
software stack'.

Similarly you should be running Minix or another kernel that is simple enough  one person can
read and understand all the code.  And I assume you have no truck with the horribly baroque
autoconf/automake/libtool rat's nest.

From what I've read, gold is much simpler than the overly-general ld implementation it
substitutes for.  Of course, part of this simplicity is because it is written in a
higher-level language.  Often this is a worthwhile tradeoff - after all the compiler only has
to be written and debugged once.  Were this not the case, all programs would be in assembly.

You missed the point

Posted Mar 27, 2008 2:12 UTC (Thu) by elanthis (guest, #6227) [Link]

Your argument makes no sense.  The C++ compiler stack is part of GCC, and the C++ portions of
the compiler make up such a small percentage of the complexity of the rest of the stack as to
be not worthy of mentioning.  Plus, I'm fairly sure (might be wrong) that the current versions
of GCC have merged the C and C++ parsers.

The complexity of C++ does not mean that you get huge, unwieldly compilers.  It just means
that you have trouble implementing the spec 100% accurately.  It's no different some a
protocol like HTTP.  HTTP (esp v1.1) is actually pretty hard to get fully implemented
correctly.  A lot of HTTP servers get it wrong, as do a lot of clients, and thus there are
certain combinations of HTTP server and client that just don't work together.  Despite this, a
fully correct HTTP server or client implementation is still pretty short, sweet, and easy to
read.  HTTP doesn't force ugly code, it's just not as simple a protocol as one might think it
is.  You can think of C++ the same way.  It doesn't require that much extra effort on top of C
to write a compiler for, but it trying to make sure you cover 100% of the spec is harder than
you might think given how very little C++ adds to the C language.

You missed the point too

Posted Mar 27, 2008 2:31 UTC (Thu) by sylware (guest, #35259) [Link]

If I need to rewrite from scratch a non optimizing C compiler it's easy. Look at tcc, and I
have plenty of students who had the "small and simple" project of writing a C compiler. Of
course, when we bring C++ on the table, you hear "insane", "crazy", "far to complex" etc... I
was refering to *that* complexity, not the current complexity of the best utra-super
optimizing compiler which is gcc.

You missed the point too

Posted Mar 27, 2008 11:04 UTC (Thu) by nix (subscriber, #2304) [Link]

But a random C compiler reimplementation isn't capable of compiling most of the other parts of
the stack in any case. GCC can be compiled with just about anything that supports ISO C, but
you'll need to reproduce a lot of GCC's (largely undocumented) foibles and language extensions
before you can compile, say, the Linux kernel with it.

I don't really see why the complexity of the *compiler* is relevant anyway. It's not as if GCC
is going to abruptly go away or stop working, so its complexity doesn't negatively impact you
at all.

You missed the point too

Posted Mar 28, 2008 17:20 UTC (Fri) by landley (subscriber, #6789) [Link]

Actually, I'm working on making tinycc (a project derived from tcc) compile the rest of the
stack, including the kernel.  I have rather a lot of work left to do, of course. :)

http://landley.net/code/tinycc

I find gold interesting, but not useful in my case because tinycc's linker is built-in.  (I'm
reorganizing the code to work as a "swiss army knife" executable ala busybox, but that's not
in -pre2.  Maybe -pre3.)

As for the kernel, the linux-tiny project is working on getting that more modular so we need
to select less of it...

Rob

You missed the point

Posted Mar 27, 2008 19:17 UTC (Thu) by tjc (guest, #137) [Link]

> I'm fairly sure (might be wrong) that the current versions
> of GCC have merged the C and C++ parsers.

The C parser was rewritten in gcc 4.1, and I *think* its still separate from the C++ parser.

You missed the point

Posted Mar 28, 2008 22:25 UTC (Fri) by nix (subscriber, #2304) [Link]

Yes. It's not separate from the *Objective C* parser.

(The similarity is that, like the C++ parser, the C parser has now made 
the transition from bison to a hand-rolled parser.)

You missed the point

Posted Mar 27, 2008 4:59 UTC (Thu) by artem (subscriber, #51262) [Link]

Well then you should really stay away from the programming for some time already.

Guess what the language is used for the tools used in designing computer chips?

(for reference, see http://www.research.att.com/~bs/applications.html, scroll down to the
bullet labeled 'Intel')

You missed the point

Posted Mar 27, 2008 5:50 UTC (Thu) by lysse (guest, #3190) [Link]

colorForth? ;)

You missed the point

Posted Mar 27, 2008 7:37 UTC (Thu) by pr1268 (subscriber, #24648) [Link]

Google has written a memory allocator library (to compete with the Glibc 2.3 equivalent, ptmalloc2), in C++.

Now, my understanding of the memory allocator is that this is a library whose run-time efficiency should be unquestioned. This is code that interfaces with the kernel nearly continuously. Accordingly, C++ would not have been my first choice of programming language in which to implement this (I would have chosen C, but don't mind me--I've never written a memory allocator before!).

But, Google's allocator library appears to have improved performance over the incumbent Glibc ptmalloc2 in certain scenarios, according to the graphs near the bottom of that page. And to think this was accomplished with C++ (I'm assuming that the Glibc ptmalloc2 is written in C, but I do ask someone to correct me if I'm wrong).

You missed the point

Posted Mar 27, 2008 11:05 UTC (Thu) by nix (subscriber, #2304) [Link]

Actually the memory allocator largely interfaces with itself and its userspace callers. Its
interface with the kernel is restricted to the occasional sbrk() and mmap() calls.

You missed the point

Posted Mar 28, 2008 3:45 UTC (Fri) by pflugstad (subscriber, #224) [Link]

Also, TCMalloc doesn't return memory to the kernel at all, while GNU libc's does.  

You missed the point

Posted Mar 27, 2008 5:49 UTC (Thu) by lysse (guest, #3190) [Link]

How dare you be this dismissive of *anyone's* work without an alternative to offer? Especially
on that flimsiest of pretexts, ideology?

You want something done *your* way, do it yourself. Otherwise, take what you're offered.
Telling someone that they have to junk what they've done is bad enough when they're only as
far as having it working; when they're handily trouncing what they aim to replace, telling
them that their replacement isn't "good enough" - because their choice of implementation
language doesn't satisfy *your aesthetic tastes* - only exposes *you* as the fool you are.

(Unfortunately, yours is the voice of the majority, and humanity is doomed.)

Being dismissive of another's work

Posted Mar 28, 2008 0:02 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

How dare you be this dismissive of *anyone's* work without an alternative to offer?

The way I read it, sylware did offer an alternative: classic binutils 'ld'. He says even as slow as it is, it's better because of the C++ issue.

You want something done *your* way, do it yourself. Otherwise, take what you're offered.

Surely you don't mean that. We all take a third option all the time: do without.

Being dismissive of another's work

Posted Mar 28, 2008 22:30 UTC (Fri) by nix (subscriber, #2304) [Link]

Doing without a linker? Neat trick! ;}

Being dismissive of another's work

Posted Apr 3, 2008 3:42 UTC (Thu) by lysse (guest, #3190) [Link]

Doing without is a subclass of doing it yourself.

You missed the point

Posted Mar 27, 2008 10:59 UTC (Thu) by nix (subscriber, #2304) [Link]

Um, ld's *algorithms* are wrong, and the wrongness is deeply embedded. The only way to speed
it up as much as gold is is to rewrite it from scratch.

Ian did that, and preferred to do it in C++.

Feel free to rewrite it yourself, in whatever language you prefer. When you make something
faster and easier to maintain than gold, come back to us.

Good point!

Posted Mar 27, 2008 15:31 UTC (Thu) by pr1268 (subscriber, #24648) [Link]

Agreed. If you choose C over C++ merely because C++ is "slow", "bloated", or "inefficient" then don't complain any further until you've rewritten all your applications in assembly language! Then we'll talk about efficient code.

Now, if you choose C over C++ because you're more comfortable, familiar, or experienced at it, then fine, but don't start making unsubstantiated generalizations about how C++ is slow, bloated, inefficient, etc. C++ isn't nearly as bloated or slow as it might have been a number of years ago. And, the Gold linker may improve this even further.

You missed the point, again.

Posted Apr 2, 2008 17:56 UTC (Wed) by sylware (guest, #35259) [Link]

You are missing the point full throttle, reread my posts.

You missed the point, again.

Posted Apr 2, 2008 19:51 UTC (Wed) by nix (subscriber, #2304) [Link]

Ah, the last refuge of the erroneous.

Sorry, the onus is on *you*: you're the one making the exaggerated claims.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds