From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4616 invoked by alias); 15 Dec 2002 23:46:22 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 4138 invoked from network); 15 Dec 2002 23:45:01 -0000 Received: from unknown (HELO neon-gw.transmeta.com) (63.209.4.196) by sources.redhat.com with SMTP; 15 Dec 2002 23:45:01 -0000 Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id PAA13697; Sun, 15 Dec 2002 15:44:44 -0800 Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1) id xma013695; Sun, 15 Dec 02 15:44:35 -0800 Received: from home.transmeta.com ([10.8.17.140]) by deepthought.transmeta.com (8.11.6/8.11.6) with ESMTP id gBFNicR27054; Sun, 15 Dec 2002 15:44:38 -0800 (PST) Date: Sun, 15 Dec 2002 16:09:00 -0000 From: Linus Torvalds To: =?iso-8859-1?Q?Pop_S=E9bastian?= cc: Momchil Velikov , , Subject: Re: source mgt. requirements solicitation In-Reply-To: <20021215221558.GA15374@gauvain.u-strasbg.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2002-12/txt/msg00844.txt.bz2 On Sun, 15 Dec 2002, Pop S=E9bastian wrote: > > > > I may be wrong. But I'm yet to hear a more credible explanation for > > this simple fact. > > > Maybe it's true because for writing compiler optimizations one > should have some knowledge in mathematics. Naah. It's simple - kernels are just sexier. Seriously, I think it's just that a kernel tends to have more different _kinds_ of problems, and thus tend to attract different kinds of people, and more of them. Compilers are complicated, no doubt about that, but the complicated stuff tends to be mostly of the same type (ie largely fairly algorithmic transformations for the different optimization passes). In kernels, you have many _different_ kinds of issues, and as a result you'll find more people who are interested in one of them. So you'll find people who care about filesystems, or people who care about memory management, or people who find it interesting to do concurrency work or IO paths. That is obviously also why the kernel ends up being a lot of lines of code. I think it's about an order of magnitude bigger in size than all of gcc - not because it is an order of magnitude more complex, obviously, but simply because it has many more parts to it. And that directly translates to more pieces that people can cut their teeth on. > Maybe we're wrong but the percentage of mathematicians who contribute > to GCC could be slightly bigger than for LK. I don't think you're wrong per se. The "transformation" kind of code is just much more common in a compiler, and the kind of people who work on it are more likely to be the mathematical kind of people. It's not the only part of gcc, obviously (I think parsing is underrated, and I'm happy that the preprocessing front-end has gotten so much attention in the last few years), but it's one of the bigger parts. And people clearly seek out projects that satisfy their interests. Linus