[9fans] [GSOC] fast kernel compile

[9fans] [GSOC] fast kernel compile

[yan cui]

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

Hi guys,

    Recently, I use plan 9 system a lot to familiar with the kernel
development environment. To my surprise, plan 9 has a rather fast
kernel compilation time compared to modern operating systems such as Linux
or Solaris. Instead of digging much into the kernel code, I post the
question here. Does the speed come from its good design or insufficient
kernel support?



Thanks, Yan

--
Think big; Dream impossible; Make it happen.

[-- Attachment #2: Type: text/html, Size: 620 bytes --]

Re: [9fans] [GSOC] fast kernel compile

[Charles Forsyth]

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

On 6 May 2014 03:13, yan cui <ccuiyyan@gmail.com> wrote:

> Instead of digging much into the kernel code, I post the question here.
> Does the speed come from its good design or insufficient kernel support?


it's a bit of both: the compiler suite is much faster; the kernel source is
less than the size of their include files; old drivers and obsolete code is
eventually discarded; and it would be fair to say that device support is
more limited, certainly compared to Linux.

[-- Attachment #2: Type: text/html, Size: 773 bytes --]

Re: [9fans] [GSOC] fast kernel compile

[yan cui]

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

Thanks Charles for the quick reply! It is really interesting.
Believe I can find more interesting things after digging deeper.


Yan




2014-05-05 22:19 GMT-04:00 Charles Forsyth <charles.forsyth@gmail.com>:

>
> On 6 May 2014 03:13, yan cui <ccuiyyan@gmail.com> wrote:
>
>> Instead of digging much into the kernel code, I post the question here.
>> Does the speed come from its good design or insufficient kernel support?
>
>
> it's a bit of both: the compiler suite is much faster; the kernel source
> is less than the size of their include files; old drivers and obsolete code
> is eventually discarded; and it would be fair to say that device support is
> more limited, certainly compared to Linux.
>



--
Think big; Dream impossible; Make it happen.

[-- Attachment #2: Type: text/html, Size: 1480 bytes --]

Re: [9fans] [GSOC] fast kernel compile

[erik quanstrom]

> 2014-05-05 22:19 GMT-04:00 Charles Forsyth <charles.forsyth@gmail.com>:
> > On 6 May 2014 03:13, yan cui <ccuiyyan@gmail.com> wrote:
> >
> >> Instead of digging much into the kernel code, I post the question here.
> >> Does the speed come from its good design or insufficient kernel support?
> >
> > it's a bit of both: the compiler suite is much faster; the kernel source
> > is less than the size of their include files; old drivers and obsolete code
> > is eventually discarded; and it would be fair to say that device support is
> > more limited, certainly compared to Linux.

simplicity, taken to heart, is really powerful.

- erik

Re: [9fans] [GSOC] fast kernel compile

[Charles Forsyth]

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

On 6 May 2014 03:19, Charles Forsyth <charles.forsyth@gmail.com> wrote:

> the kernel source is less than the size of their include files


also, quite a bit that is unaccountably still in other kernels ("because
Unix did it exactly that way in the 1970s on a PDP-11")
is in user space or across a network in Plan 9. of course, that's balanced
by browsers now easily rivalling the kernels you mention for complexity and
certainly size, with their brutalist programming architectures.

[-- Attachment #2: Type: text/html, Size: 830 bytes --]

Re: [9fans] [GSOC] fast kernel compile

[arnold]

> also, quite a bit that is unaccountably still in other kernels ("because
> Unix did it exactly that way in the 1970s on a PDP-11")

I think that "unaccountably" is a bit harsh. There is A  L O T of old
Unix software that still just compiles and works out of the box on
Linux, Solaris, *BSD.  There is a lot of value to that, when what you
care about is getting your work done (KTBR - Keep The Business Running).

I well understand that this community is less concerned about that,
but this community should also be open minded enough to understand
those kinds of concerns.

Arnold

Re: [9fans] [GSOC] fast kernel compile

[Charles Forsyth]

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

On 6 May 2014 09:38, <arnold@skeeve.com> wrote:

> I think that "unaccountably" is a bit harsh.


I was talking about kernels and kernel mechanisms.

[-- Attachment #2: Type: text/html, Size: 450 bytes --]

Re: [9fans] [GSOC] fast kernel compile

[arnold]

Charles Forsyth <charles.forsyth@gmail.com> wrote:

> On 6 May 2014 09:38, <arnold@skeeve.com> wrote:
>
> > I think that "unaccountably" is a bit harsh.
>
>
> I was talking about kernels and kernel mechanisms.

Fair enough then.

Thanks,

Arnold

Re: [9fans] [GSOC] fast kernel compile

[erik quanstrom]

On Tue May  6 04:39:11 EDT 2014, arnold@skeeve.com wrote:
> > also, quite a bit that is unaccountably still in other kernels ("because
> > Unix did it exactly that way in the 1970s on a PDP-11")
>
> I think that "unaccountably" is a bit harsh. There is A  L O T of old
> Unix software that still just compiles and works out of the box on
> Linux, Solaris, *BSD.  There is a lot of value to that, when what you
> care about is getting your work done (KTBR - Keep The Business Running).

my experience is the opposite.  basic c library functions have been built
into the compiler, and the types have changed.

- erik

Re: [9fans] [GSOC] fast kernel compile

[tlaronde]

On Tue, May 06, 2014 at 09:02:21AM +0100, Charles Forsyth wrote:
> On 6 May 2014 03:19, Charles Forsyth <charles.forsyth@gmail.com> wrote:
>
> Of course, that's balanced
> by browsers now easily rivalling the kernels you mention for complexity and
> certainly size, with their brutalist programming architectures.

And it is even not a problem reserved to Plan9. On a NetBSD, I tried to
compile chrome. The PC had even not enough _memory_ to link the thing...

--
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                      http://www.kergis.com/
              http://www.renaissance-francaise.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] [GSOC] fast kernel compile

[tlaronde]

On Tue, May 06, 2014 at 11:39:03AM +0200, tlaronde@polynum.com wrote:
>
> On Tue, May 06, 2014 at 09:02:21AM +0100, Charles Forsyth wrote:
> > On 6 May 2014 03:19, Charles Forsyth <charles.forsyth@gmail.com> wrote:
> >
> > Of course, that's balanced
> > by browsers now easily rivalling the kernels you mention for complexity and
> > certainly size, with their brutalist programming architectures.
>
> And it is even not a problem reserved to Plan9.

To explain in my answer the link with the Plan9: browsers are so
huge beast nowadays, that the lack of a "modern" browser on Plan9
will rapidly become a problem for others than Plan9 since these
things are so huge and complex and need so many pieces than even on Unix
like systems, one may not be even able to link the thing.

--
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                      http://www.kergis.com/
              http://www.renaissance-francaise.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] [GSOC] fast kernel compile

[Charles Forsyth]

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

On 6 May 2014 10:52, <tlaronde@polynum.com> wrote:

> like systems, one may not be even able to link the thing.


Recently I saw that the source of the underlying engine for (I think)
Chrome had roughly
halved in size. I'm not sure if that's the same version as the you've got.
They'd done trendy things like devise and implement suitable abstractions
for different
parts of the graphics/browsing model, and implemented those in a modular
way, and surprisingly,
it got simpler and smaller. It's actually quite hard to do with the
browser, because the standard
specifications are not well-suited for either writing HTML or implementing
it, so it's hard
to see what abstractions might actually be needed or would work.

[-- Attachment #2: Type: text/html, Size: 1221 bytes --]

Re: [9fans] [GSOC] fast kernel compile

[erik quanstrom]

> Recently I saw that the source of the underlying engine for (I think)
> Chrome had roughly halved in size.  I'm not sure if that's the same
> version as the you've got.  They'd done trendy things like devise and
> implement suitable abstractions for different parts of the
> graphics/browsing model, and implemented those in a modular way, and
> surprisingly, it got simpler and smaller.  It's actually quite hard to
> do with the browser, because the standard specifications are not
> well-suited for either writing HTML or implementing it, so it's hard
> to see what abstractions might actually be needed or would work.

that, and they gave up on being compatable with apple's webkit.

- erik

Re: [9fans] [GSOC] fast kernel compile

[Aram Hăvărneanu]

Plan 9 compilers are fast, Unix compilers are slow. Plan 9 compilers
compile less because the philosophy regarding #include files is
different. Plan 9 programs (including the kernel) are small, Unix
programs are large.

The Plan 9 kernel has less lines of code than Unix configure scripts.
The question is not why does Plan 9 compile so quickly, is what
catastrophe happened in Unix making everything so slow and large.

-- 
Aram Hăvărneanu

Re: [9fans] [GSOC] fast kernel compile

[Oleksandr Iakovliev]

On 05/06/2014 05:24 PM, Aram Hăvărneanu wrote:
> The question is not why does Plan 9 compile so quickly, is what
> catastrophe happened in Unix making everything so slow and large.

Well, you know there is a lot of noise for linux kernel about keeping it
compatible for even very old versions of apps binaries, while in
reality, linux apps binaries are very rare to be executed even from one
distro to another...

Same story that happens to ms to keep compatibility for dos, then for
first win apis, then for second, then oops 640KB is not enough ;)

Re: [9fans] [GSOC] fast kernel compile

[erik quanstrom]

> Well, you know there is a lot of noise for linux kernel about keeping it
> compatible for even very old versions of apps binaries, while in
> reality, linux apps binaries are very rare to be executed even from one
> distro to another...

most of the 2ed binaries still run on modern 386 kernels.
(that's what 20 years?)  i'd be curious if anyone can find a
linux binary from that time frame that can be run on a 3.x
kernel.  double super bonus for dynamicly linked executables.

- erik

Re: [9fans] [GSOC] fast kernel compile

[cinap_lenrek]

plan9 also has /n/dump, which is great to find out if
and when suff has regressed. :)

having self contained program binaries is great.

--
cinap

Re: [9fans] [GSOC] fast kernel compile

[Anthony Sorace]

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

> that, and they gave up on being compatable with apple's webkit.

It's not just about compatibility: they shrunk the scope of the
problem they're trying to solve by quite a bit. WebKit aims to be a
sort of general-purpose web rendering engine; Blink (Google's
fork) is much more closely targeting Chrome & friends.


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 169 bytes --]