From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 Date: Mon, 5 May 2014 22:13:59 -0400 Message-ID: From: yan cui To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=20cf3036391d07f17a04f8b1cd46 Subject: [9fans] [GSOC] fast kernel compile Topicbox-Message-UUID: de627496-ead8-11e9-9d60-3106f5b1d025 --20cf3036391d07f17a04f8b1cd46 Content-Type: text/plain; charset=UTF-8 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. --20cf3036391d07f17a04f8b1cd46 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi guys,

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



Thanks, Yan=C2=A0
<= div>
--
Think big; Dream impossible; Make it happen.=C2=A0=C2= =A0
--20cf3036391d07f17a04f8b1cd46-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Tue, 6 May 2014 03:19:32 +0100 Message-ID: From: Charles Forsyth To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=047d7bb70882e1b06a04f8b1e014 Subject: Re: [9fans] [GSOC] fast kernel compile Topicbox-Message-UUID: de6a7bfa-ead8-11e9-9d60-3106f5b1d025 --047d7bb70882e1b06a04f8b1e014 Content-Type: text/plain; charset=UTF-8 On 6 May 2014 03:13, yan cui 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. --047d7bb70882e1b06a04f8b1e014 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= 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. Do= es 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 drive= rs and obsolete code is eventually discarded; and it would be fair to say t= hat device support is more limited, certainly compared to Linux.
--047d7bb70882e1b06a04f8b1e014-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Mon, 5 May 2014 22:35:37 -0400 Message-ID: From: yan cui To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=20cf3036391d65159804f8b21a82 Subject: Re: [9fans] [GSOC] fast kernel compile Topicbox-Message-UUID: de94c496-ead8-11e9-9d60-3106f5b1d025 --20cf3036391d65159804f8b21a82 Content-Type: text/plain; charset=UTF-8 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 : > > On 6 May 2014 03:13, yan cui 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. --20cf3036391d65159804f8b21a82 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Charles for the quick reply! It is really inte= resting.
Believe I can find more interesting things after digging deepe= r.


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. Do= es 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 i= mpossible; Make it happen.=C2=A0=C2=A0
--20cf3036391d65159804f8b21a82-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Mon, 5 May 2014 22:48:28 -0400 To: 9fans@9fans.net Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] [GSOC] fast kernel compile Topicbox-Message-UUID: de9d6bc8-ead8-11e9-9d60-3106f5b1d025 > 2014-05-05 22:19 GMT-04:00 Charles Forsyth : > > On 6 May 2014 03:13, yan cui 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 From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Tue, 6 May 2014 09:02:21 +0100 Message-ID: From: Charles Forsyth To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=f46d04138a25de70ad04f8b6aa20 Subject: Re: [9fans] [GSOC] fast kernel compile Topicbox-Message-UUID: deae970e-ead8-11e9-9d60-3106f5b1d025 --f46d04138a25de70ad04f8b6aa20 Content-Type: text/plain; charset=UTF-8 On 6 May 2014 03:19, Charles Forsyth 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. --f46d04138a25de70ad04f8b6aa20 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --f46d04138a25de70ad04f8b6aa20-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnold@skeeve.com Message-Id: <201405060838.s468c72Q018984@freefriends.org> Date: Tue, 6 May 2014 02:38:07 -0600 To: 9fans@9fans.net References: In-Reply-To: User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [9fans] [GSOC] fast kernel compile Topicbox-Message-UUID: deb54dec-ead8-11e9-9d60-3106f5b1d025 > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <201405060838.s468c72Q018984@freefriends.org> References: <201405060838.s468c72Q018984@freefriends.org> Date: Tue, 6 May 2014 09:49:26 +0100 Message-ID: From: Charles Forsyth To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=f46d040fa03c480bc504f8b7534d Subject: Re: [9fans] [GSOC] fast kernel compile Topicbox-Message-UUID: debd86a6-ead8-11e9-9d60-3106f5b1d025 --f46d040fa03c480bc504f8b7534d Content-Type: text/plain; charset=UTF-8 On 6 May 2014 09:38, wrote: > I think that "unaccountably" is a bit harsh. I was talking about kernels and kernel mechanisms. --f46d040fa03c480bc504f8b7534d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= 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.
--f46d040fa03c480bc504f8b7534d-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnold@skeeve.com Message-Id: <201405060854.s468sbDb024441@freefriends.org> Date: Tue, 6 May 2014 02:54:37 -0600 To: 9fans@9fans.net References: <201405060838.s468c72Q018984@freefriends.org> In-Reply-To: User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [9fans] [GSOC] fast kernel compile Topicbox-Message-UUID: decad360-ead8-11e9-9d60-3106f5b1d025 Charles Forsyth wrote: > On 6 May 2014 09:38, wrote: > > > I think that "unaccountably" is a bit harsh. > > > I was talking about kernels and kernel mechanisms. Fair enough then. Thanks, Arnold From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Tue, 6 May 2014 11:39:03 +0200 From: tlaronde@polynum.com To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20140506093903.GA483@polynum.com> References: Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.4.2.3i Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: [9fans] [GSOC] fast kernel compile Topicbox-Message-UUID: ded09a0c-ead8-11e9-9d60-3106f5b1d025 On Tue, May 06, 2014 at 09:02:21AM +0100, Charles Forsyth wrote: > On 6 May 2014 03:19, Charles Forsyth 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 http://www.kergis.com/ http://www.renaissance-francaise.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Tue, 6 May 2014 11:52:49 +0200 From: tlaronde@polynum.com To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20140506095249.GA749@polynum.com> References: <20140506093903.GA483@polynum.com> Mime-Version: 1.0 In-Reply-To: <20140506093903.GA483@polynum.com> User-Agent: Mutt/1.4.2.3i Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: [9fans] [GSOC] fast kernel compile Topicbox-Message-UUID: ded5d3fa-ead8-11e9-9d60-3106f5b1d025 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 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 http://www.kergis.com/ http://www.renaissance-francaise.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <20140506095249.GA749@polynum.com> References: <20140506093903.GA483@polynum.com> <20140506095249.GA749@polynum.com> Date: Tue, 6 May 2014 11:02:25 +0100 Message-ID: From: Charles Forsyth To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=f46d0442808c4afa5d04f8b858b6 Subject: Re: [9fans] [GSOC] fast kernel compile Topicbox-Message-UUID: dedbc292-ead8-11e9-9d60-3106f5b1d025 --f46d0442808c4afa5d04f8b858b6 Content-Type: text/plain; charset=UTF-8 On 6 May 2014 10:52, 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. --f46d0442808c4afa5d04f8b858b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= 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 im= plement suitable abstractions for different
parts of the graphics/browsing model, and implemented those in a modular w= ay, and surprisingly,
it got simpler and smaller. It's actually qu= ite hard to do with the browser, because the standard
specifications are not well-suited for either writing HTML or im= plementing it, so it's hard
to see what abstractions might actually be neede= d or would work.
--f46d0442808c4afa5d04f8b858b6-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Tue, 6 May 2014 09:34:42 -0400 To: 9fans@9fans.net Message-ID: <3da5967e36031cd6dea25d2afe030208@brasstown.quanstro.net> In-Reply-To: <201405060838.s468c72Q018984@freefriends.org> References: <201405060838.s468c72Q018984@freefriends.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] [GSOC] fast kernel compile Topicbox-Message-UUID: def5becc-ead8-11e9-9d60-3106f5b1d025 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Tue, 6 May 2014 09:35:39 -0400 To: 9fans@9fans.net Message-ID: In-Reply-To: References: <20140506093903.GA483@polynum.com> <20140506095249.GA749@polynum.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] [GSOC] fast kernel compile Topicbox-Message-UUID: defb597c-ead8-11e9-9d60-3106f5b1d025 > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <20140506093903.GA483@polynum.com> <20140506095249.GA749@polynum.com> From: =?UTF-8?B?QXJhbSBIxIN2xINybmVhbnU=?= Date: Tue, 6 May 2014 17:24:23 +0200 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] [GSOC] fast kernel compile Topicbox-Message-UUID: df01440e-ead8-11e9-9d60-3106f5b1d025 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. --=20 Aram H=C4=83v=C4=83rneanu From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <53690437.7070900@lynxline.com> Date: Tue, 6 May 2014 17:48:07 +0200 From: Oleksandr Iakovliev User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: 9fans@9fans.net References: <20140506093903.GA483@polynum.com> <20140506095249.GA749@polynum.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] [GSOC] fast kernel compile Topicbox-Message-UUID: df07f538-ead8-11e9-9d60-3106f5b1d025 On 05/06/2014 05:24 PM, Aram H=C4=83v=C4=83rneanu 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 ;) From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/signed; boundary="Apple-Mail=_A00AF0B8-F747-4553-A2AB-310183485C2E"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Anthony Sorace In-Reply-To: Date: Tue, 6 May 2014 11:51:18 -0400 Message-Id: <71FDFB64-A77C-4782-A401-3A7955183E98@9srv.net> References: <20140506093903.GA483@polynum.com> <20140506095249.GA749@polynum.com> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] [GSOC] fast kernel compile Topicbox-Message-UUID: df12b400-ead8-11e9-9d60-3106f5b1d025 --Apple-Mail=_A00AF0B8-F747-4553-A2AB-310183485C2E Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > 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. --Apple-Mail=_A00AF0B8-F747-4553-A2AB-310183485C2E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAlNpBP0ACgkQyrb52b5lrs4PdwCfWKC/uzVJzOqAZlnUXyNgkeFY lHoAoIJAukcwRkyh2Kl1YyNGX2trL/yL =YkfU -----END PGP SIGNATURE----- --Apple-Mail=_A00AF0B8-F747-4553-A2AB-310183485C2E-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Tue, 6 May 2014 11:53:53 -0400 To: 9fans@9fans.net Message-ID: <9649f7c165ef09ccfa226c97adbf3361@ladd.quanstro.net> In-Reply-To: <53690437.7070900@lynxline.com> References: <20140506093903.GA483@polynum.com> <20140506095249.GA749@polynum.com> <53690437.7070900@lynxline.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] [GSOC] fast kernel compile Topicbox-Message-UUID: df1aece2-ead8-11e9-9d60-3106f5b1d025 > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <398eee7e2ff4841bb4305c91286155c6@felloff.net> Date: Tue, 6 May 2014 19:39:04 +0200 From: cinap_lenrek@felloff.net To: 9fans@9fans.net In-Reply-To: <9649f7c165ef09ccfa226c97adbf3361@ladd.quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] [GSOC] fast kernel compile Topicbox-Message-UUID: df2721a6-ead8-11e9-9d60-3106f5b1d025 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