Re: [9fans] fast compilers

Re: [9fans] fast compilers

[rog]

mirtchov@cpsc.ucalgary.ca wrote:
> to quote:
[...]
> > > gcc 3.2.1 is TWICE AS SLOW as gcc 2.95, and the more recent development
[...]
> I wish the plan9 compiler was 100% free.  It's blazingly fast.

the inferno version of the plan 9 C compiler, which is almost
identical to the plan 9 version, is distributed under the same
license as gcc.

  cheers,
    rog.

Re: [9fans] fast compilers

[Charles Forsyth]

i found it far easier and faster doing the powerpc and Fairchild
Clipper ports (long gone) using the balance of work in Ken's structure
than anything else i've worked with, including my own compilers
producing either text or binary.  (that's not to say ?[acl] couldn't
be improved at all, or made easier to follow and port.)

much of the advantage and speed in porting is because
only the linker really knows the binary encoding for
a particular architecture, which isolates one of the messiest
and most tedious parts.  (it's a good modular split in my experience.)
architectures that have got span- or context-dependent instructions
are much easier to handle that way.  otherwise, the compiler
or assembler--sometimes both!--end up having to duplicate
work the linker does or second-guess it.

the assembler's trivial (i often do that first to get a good feel for the architecture).
with the powerpc it was a little more work because i had to decide
what to do about all those peculiar instructions.

for a load/store architecture, it's fairly easy to get the C compiler generating
reasonable code quickly.  on the other  hand, i'm glad i didn't
need to deal with the non-load/store ones implemented (eg, x86).

for most architectures, the linker is an opcode table that drives instruction selection,
a small addressing mode classifier, and an assembler that's
a big switch statement.

i also found it easier to do the linker and produce its input
than to have to have the compiler generate
correct assembly-language text or to have to deal with typically
bizarre and equally ill-documented object and executable file formats.

in use, i actually like having all the platforms use the same dataflow syntax and order
when i write assembler support.  i make fewer mistakes moving between them.

one practical nuisance, which can i suppose be  underestimated,
is that you can't trivially recycle existing assembly-language
code (although i've had to deal with several platforms that had several
different assembly languages anyway), and it's a challenge given
the documentation to work out the mapping for some of the peculiar
ones (see powerpc comment above).

Re: [9fans] fast compilers

[bwc]

[-- Attachment #1: Type: text/plain, Size: 473 bytes --]

I find the external assembler and linker to be simpler than the plan 9 *[cal] suite.
It seems more modular, easier to understand all the components.  I also find
it easy to port an assembler to a new machine than it is to mess with the internal
compiler stuff in the plan 9 C set of programs.

Was Ken's compiler an expirment in a new way of doing things?  If so
what was the verdict?  I enjoy using the compiler, but is it the
best way to do compilers?

 Brantley

[-- Attachment #2: Type: message/rfc822, Size: 3433 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 220 bytes --]

it's a good piece of work, and at one time
it even had a go at implementing some of the Plan 9 extensions,
but it still requires an external assembler and linker
in the old style (in all the incarnations i've seen).

[-- Attachment #2.1.2: Type: message/rfc822, Size: 1679 bytes --]

From: Scott Schwartz <schwartz@bio.cse.psu.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] fast compilers
Date: Tue, 08 Apr 2003 02:11:15 -0400
Message-ID: <20030408061115.28990.qmail@g.bio.cse.psu.edu>

Dan asks:
| I should note, however, that building compilers akin to Plan 9's C
| compiler shouldn't really be too hard; why hasn't anyone done it yet?

Does lcc qualify?
 http://www.cs.princeton.edu/software/lcc/

Re: [9fans] fast compilers

[Dan Cross]

> | I should note, however, that building compilers akin to Plan 9's C
> | compiler shouldn't really be too hard; why hasn't anyone done it yet?
>
> Does lcc qualify?
>  http://www.cs.princeton.edu/software/lcc/

lcc is very nice, but was ham-strung for many years by lack of a `long
long' type.  Lcc 4 fixes that, but the license terms are even worse
than for gcc.

	- Dan C.

Re: [9fans] fast compilers

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 220 bytes --]

it's a good piece of work, and at one time
it even had a go at implementing some of the Plan 9 extensions,
but it still requires an external assembler and linker
in the old style (in all the incarnations i've seen).

[-- Attachment #2: Type: message/rfc822, Size: 1679 bytes --]

From: Scott Schwartz <schwartz@bio.cse.psu.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] fast compilers
Date: Tue, 08 Apr 2003 02:11:15 -0400
Message-ID: <20030408061115.28990.qmail@g.bio.cse.psu.edu>

Dan asks:
| I should note, however, that building compilers akin to Plan 9's C
| compiler shouldn't really be too hard; why hasn't anyone done it yet?

Does lcc qualify?
 http://www.cs.princeton.edu/software/lcc/

Re: [9fans] fast compilers

[Scott Schwartz]

Dan asks:
| I should note, however, that building compilers akin to Plan 9's C
| compiler shouldn't really be too hard; why hasn't anyone done it yet?

Does lcc qualify?
 http://www.cs.princeton.edu/software/lcc/

Re: [9fans] fast compilers

[Dan Cross]

> [...]

Aww hell, that was supposed to go to de Raadt alone.

	- Dan C.

Re: [9fans] fast compilers

[Dan Cross]

> To: rog@vitanuova.com
> Cc: 9fans@cse.psu.edu
      ^^^^^
> Subject: Re: [9fans] fast compilers
> From: Theo de Raadt <deraadt@cvs.openbsd.org>
>
> and since it is gpl, we cannot, and will not switch to it.
>
> i have tried to make this clear to various people, in an attempt to
> convince them that a bigger picture view would be good.  if it was bsd
> licensed, everyone could use it, and we would have some competition
> for gcc.  we would try to improve it -- we would try to switch to it.
>
> but if it is gpl, we will not.
>
> > mirtchov@cpsc.ucalgary.ca wrote:
> > > to quote:
> > [...]
> > > > > gcc 3.2.1 is TWICE AS SLOW as gcc 2.95, and the more recent development
> > [...]
> > > I wish the plan9 compiler was 100% free.  It's blazingly fast.
> >
> > the inferno version of the plan 9 C compiler, which is almost
> > identical to the plan 9 version, is distributed under the same
> > license as gcc.
> >
> >   cheers,
> >     rog.
> >

9fans isn't appropriate for discussions related to the licensing of
software components and their inclusions in other operating systems.
Please, keep this stuff off-list.  (In this case, Rog should have
known better.)

I should note, however, that building compilers akin to Plan 9's C
compiler shouldn't really be too hard; why hasn't anyone done it yet?
With the oodles of BSD programmers out there, I'd have thought it'd
have been done years ago.

	- Dan C.

Re: [9fans] fast compilers

[Theo de Raadt]

and since it is gpl, we cannot, and will not switch to it.

i have tried to make this clear to various people, in an attempt to
convince them that a bigger picture view would be good.  if it was bsd
licensed, everyone could use it, and we would have some competition
for gcc.  we would try to improve it -- we would try to switch to it.

but if it is gpl, we will not.

> mirtchov@cpsc.ucalgary.ca wrote:
> > to quote:
> [...]
> > > > gcc 3.2.1 is TWICE AS SLOW as gcc 2.95, and the more recent development
> [...]
> > I wish the plan9 compiler was 100% free.  It's blazingly fast.
>
> the inferno version of the plan 9 C compiler, which is almost
> identical to the plan 9 version, is distributed under the same
> license as gcc.
>
>   cheers,
>     rog.
>

Re: [9fans] fast compilers

[Robin KAY]

jkw@eecs.harvard.edu wrote:

> The Intel folks have managed to produce an ia32 compiler
> that is much faster than gcc and yet much more interested
> in highly optimized code than the Plan 9 cc, so I'm not sure
> I buy this argument. :-/

Don't forget that gcc targets many more architectures than just IA32.
Abstraction (e.g. the RTL layer) must cost it in terms of performance.

--
Wishing you good fortune,
--Robin Kay-- (komadori)

Re: [9fans] fast compilers

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 29 bytes --]

enough guys, take it offline.

[-- Attachment #2: Type: message/rfc822, Size: 1878 bytes --]

From: Dan Cross <cross@math.psu.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] fast compilers
Date: Fri, 04 Apr 2003 20:47:54 -0500
Message-ID: <200304050147.h351lsL01499@augusta.math.psu.edu>

> > No, it probably has to do with belaboring the obvious.
>
> obvious to most of us, I wouldnt have even bothered responding except
> for having someone who was "not sure they buy this argument".

Perhaps you shouldn't have bothered either way.

	- Dan C.

Re: [9fans] fast compilers

[Dan Cross]

> > No, it probably has to do with belaboring the obvious.
>
> obvious to most of us, I wouldnt have even bothered responding except
> for having someone who was "not sure they buy this argument".

Perhaps you shouldn't have bothered either way.

	- Dan C.

Re: [9fans] fast compilers

[Andrew]

On Fri, Apr 04, 2003 at 07:59:45PM -0500, Dan Cross wrote:
> In article <20030405003114.GA24752@thefrayedknot.armory.com> you write:
> >it (big often equals slow) is a common enough occurence that you'd think
> >I wouldnt have to defend myself on it, apparently not.
>
> No, it probably has to do with belaboring the obvious.

obvious to most of us, I wouldnt have even bothered responding except
for having someone who was "not sure they buy this argument".

Re: [9fans] fast compilers

[Dan Cross]

In article <20030405003114.GA24752@thefrayedknot.armory.com> you write:
>it (big often equals slow) is a common enough occurence that you'd think
>I wouldnt have to defend myself on it, apparently not.

No, it probably has to do with belaboring the obvious.

	- Dan C.

Re: [9fans] fast compilers

[Andrew]

On Fri, Apr 04, 2003 at 07:28:38PM -0500, William Josephson wrote:
> On Fri, Apr 04, 2003 at 04:14:49PM -0800, Andrew wrote:
> > ie plan9, which is great in that respect afaik). I can cite plenty of
> > examples of large software projects that are unreasonably bulky and slow
> > if you'd like... mozilla, xfree86, glibc...all much too large and far
> > too slow.
>
> Proof by example? :-p
it (big often equals slow) is a common enough occurence that you'd think
I wouldnt have to defend myself on it, apparently not.

Re: [9fans] fast compilers

[William Josephson]

On Fri, Apr 04, 2003 at 04:14:49PM -0800, Andrew wrote:
> ie plan9, which is great in that respect afaik). I can cite plenty of
> examples of large software projects that are unreasonably bulky and slow
> if you'd like... mozilla, xfree86, glibc...all much too large and far
> too slow.

Proof by example? :-p

Re: [9fans] fast compilers

[Andrew]

On Fri, Apr 04, 2003 at 06:07:24PM -0500, jkw@eecs.harvard.edu wrote:
> On Fri, Apr 04, 2003 at 03:02:34PM -0800, Andrew wrote:
>
> > I dont think gcc 3.2.1 is twice as slow as 2.95 (3.2.2 has been released
> > as a side note). I will not deny that it seems a bit slower than 2.95
> > but not to any very noticable degree. It is worth pointing out that
>
> That's because gcc was slow as a dog to begin with ;-)
>
> > were added (pentium4 and athlon to name a few). I think the big push
> > towards 3.x was to add support for newer architectures. They've also
> > hit the stumbling block of complexity. It seems to be a rule that the
> > bigger and more complex programs get the speed at which they will run
> > becomes increasingly slower. There are tons of features in gcc, omit the
>
> The Intel folks have managed to produce an ia32 compiler
> that is much faster than gcc and yet much more interested
> in highly optimized code than the Plan 9 cc, so I'm not sure
> I buy this argument. :-/
>
Im not saying specifically that gcc is slow _because_ it has it makes
optmized code, i actually never said it made optimized code, although it
claims to, and seems to do fairly well in most cases. All i said was that
gcc has tons of features. I was also saying that bigger software seems
to degrade in performance (therefore smaller software is the way to go,
ie plan9, which is great in that respect afaik). I can cite plenty of
examples of large software projects that are unreasonably bulky and slow
if you'd like... mozilla, xfree86, glibc...all much too large and far
too slow.

Re: [9fans] fast compilers

[jkw]

On Fri, Apr 04, 2003 at 03:02:34PM -0800, Andrew wrote:

> I dont think gcc 3.2.1 is twice as slow as 2.95 (3.2.2 has been released
> as a side note). I will not deny that it seems a bit slower than 2.95
> but not to any very noticable degree. It is worth pointing out that

That's because gcc was slow as a dog to begin with ;-)

> were added (pentium4 and athlon to name a few). I think the big push
> towards 3.x was to add support for newer architectures. They've also
> hit the stumbling block of complexity. It seems to be a rule that the
> bigger and more complex programs get the speed at which they will run
> becomes increasingly slower. There are tons of features in gcc, omit the

The Intel folks have managed to produce an ia32 compiler
that is much faster than gcc and yet much more interested
in highly optimized code than the Plan 9 cc, so I'm not sure
I buy this argument. :-/

Re: [9fans] fast compilers

[Andrew]

> to quote:
>
> > > gcc 3.2.1 is TWICE AS SLOW as gcc 2.95, and the more recent development
> > > are
> > > even SLOWER.
> >
> > What is making successive versions of GCC slower?
>
> I'm not exactly sure.  My theory would be that in their zeal for
> trying to get gcc to catch up to commercial compilers in quality of
> output, they have paid much less attention to ensuring the compiler
> itself is fast.
>
> Sigh.
>
> I wish the plan9 compiler was 100% free.  It's blazingly fast.
>
> And as a developer, I want a fast compiler more than I want fast output.
>

I dont think gcc 3.2.1 is twice as slow as 2.95 (3.2.2 has been released
as a side note). I will not deny that it seems a bit slower than 2.95
but not to any very noticable degree. It is worth pointing out that
between the two versions several new architectures, mostly intel based,
were added (pentium4 and athlon to name a few). I think the big push
towards 3.x was to add support for newer architectures. They've also
hit the stumbling block of complexity. It seems to be a rule that the
bigger and more complex programs get the speed at which they will run
becomes increasingly slower. There are tons of features in gcc, omit the
frame pointer? unsigned bit fields? merge constants between objects? you
can do just about anything you want with it, heck the manual is 8249
lines! I think therein lies the catch22.

it looks like in plan9 as a general rule the designers remembered the
complexity rule, and kept everything small and fast. so no wild crazy
shotgun approach to options. for better or for worse.

Andrew

[9fans] fast compilers

[andrey mirtchovski]

I know theo de raadt is a controversial person, but i found this post of his
interesting:

http://www.netsys.com/openbsd-tech/2003/02/msg00064.html

to quote:

> > gcc 3.2.1 is TWICE AS SLOW as gcc 2.95, and the more recent development
> > are
> > even SLOWER.
>
> What is making successive versions of GCC slower?

I'm not exactly sure.  My theory would be that in their zeal for
trying to get gcc to catch up to commercial compilers in quality of
output, they have paid much less attention to ensuring the compiler
itself is fast.

Sigh.

I wish the plan9 compiler was 100% free.  It's blazingly fast.

And as a developer, I want a fast compiler more than I want fast output.