From owner-cvs-src@FreeBSD.ORG Thu Mar 18 13:17:45 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A591516A4CE; Thu, 18 Mar 2004 13:17:45 -0800 (PST) Received: from mailout04.sul.t-online.com (mailout04.sul.t-online.com [194.25.134.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3636143D39; Thu, 18 Mar 2004 13:17:20 -0800 (PST) (envelope-from Alexander@Leidinger.net) Received: from fwd11.aul.t-online.de by mailout04.sul.t-online.com with smtp id 1B44tC-0004H8-0B; Thu, 18 Mar 2004 22:17:18 +0100 Received: from Andro-Beta.Leidinger.net (XVzPBOZfwe-RQLC2w-lQmwKxBH6bsPvWionMtXjQCKKJOv8DF6BFUV@[80.131.124.200]) by fmrl11.sul.t-online.com with esmtp id 1B44t1-0VgkRU0; Thu, 18 Mar 2004 22:17:07 +0100 Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) i2ILGxD3041749; Thu, 18 Mar 2004 22:16:59 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from Magellan.Leidinger.net (netchild@localhost [127.0.0.1]) i2ILGw1l004719; Thu, 18 Mar 2004 22:16:58 +0100 (CET) (envelope-from Alexander@Leidinger.net) Date: Thu, 18 Mar 2004 22:16:58 +0100 From: Alexander Leidinger To: Scott Long Message-Id: <20040318221658.3910c2eb@Magellan.Leidinger.net> In-Reply-To: <405A02DE.7000402@freebsd.org> References: <200403122136.i2CLaCm9096276@repoman.freebsd.org> <20040315033213.GA40858@dragon.nuxi.com> <20040315180324.0fa39609@Magellan.Leidinger.net> <20040318002208.GC2541@dragon.nuxi.com> <20040318162358.3f57aef3@Magellan.Leidinger.net> <20040318172827.GB41559@dragon.nuxi.com> <20040318131238.12142bf1@localhost> <20040318145507.7acb75fc@localhost> <405A02DE.7000402@freebsd.org> X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Seen: false X-ID: XVzPBOZfwe-RQLC2w-lQmwKxBH6bsPvWionMtXjQCKKJOv8DF6BFUV@t-dialin.net cc: Tom Rhodes cc: src-committers@freebsd.org cc: cvs-src@freebsd.org cc: cvs-all@freebsd.org cc: obrien@freebsd.org cc: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= Subject: Re: cvs commit: src/share/mk bsd.cpu.mk bsd.dep.mk bsd.lib.mk bsd.sys.mk src/sys/conf files kern.mk kern.pre.mk kmod.mk src/sys/dev/aic7xxx/aicasm Makefile X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2004 21:17:45 -0000 On Thu, 18 Mar 2004 13:13:18 -0700 Scott Long wrote: > First of all, while the project has a license to run icc on a cluster > computer and release the outputed binaries, does that mean that the > project can distribute icc in the base system, or on one of the release > cd's? My understanding is 'no'. This is true. > So let's say that I hack up the release makefiles so that they use icc, > and produce an icc-optimized release. What's the first thing that many > people do right after they install their system? They compile a new > kernel. Since icc isn't available to them when they do this, they've > lost the benefit of what was distributed on the CD. - I know people, which only run GENERIC. - icc is available for free But I agree with you. > Now this all assumes that release CD's are built on cluster machines. > In fact, none of them are for any architecture. I, and the others who > build the other arches, usually build them on local hardware so that we > can QA the results before uploading them to ftp-master. So unless we > all get icc licenses for our local machines, using it isn't going to > happen. The difference between the free non-commercial version and the commercial version isn't technical. So you could compile it with non-commercial version and nobody would be able to notice it. Besides this, we have an unlimited license. It's not bound to any hardware. So if the person of re@ which does the ia32 build wants to use icc to build a release, he can have the license file and use it to build FreeBSD. But this point is unimportant, as we're far away from being able to build a release with icc. ATM it's just the kernel. > Also, I don't know if David's concerns about icc having different > behaviour on Intel vs AMD chips are true, but I generally trust him on > these matters since it's his job (both real job and project job) to > know. It's also within the realm of possibilities for Intel. So this > is yet another strike against using it in a release. I agree that a "release for the masses" shouldn't be compiled with icc. But nobody talked about replacing our gcc compiled release. > I think I mentioned this before, but a nice compromise would be to put > a set of icc-compiled binaries in an obvious location on the ftp and > web sites, and encourage people to try them on their already-installed > systems. Maybe someday we could even have enough computing horsepower > to do on-demand kernel compiles for people. Nobody prohibits to compile an additional release iso for a specific processor. If we approve the use on e.g. a P4, and someone uses it on something else, he's on his own. The same applies to AMD processors too, if we specify a specific piece of software as optimized for an Athlon and not usable on e.g. a P4, nobody is allowed to moan if he runs it on a P4 and has problems with it. As already told, if someone (e.g. AMD) sponsors a license for a compiler which produces better code than gcc for ia32 hardware (or only for AMD processors), I will happily spend the same amount of effort as I did with icc. My work on this is not animated by a "pro-Intel" attitude. I have an Athlon-XP in my desktop system, an Mobile-Athlon in my laptop and an old Celeron (400 MHz) in my server in the basement (this makes it 2:1 for AMD so far). I also have a P4, but I got it because I had it on the donations page to be able to test icc on FreeBSD where icc is supposed to outperform gcc very easy. Without icc, I wouldn't have the P4. Being able to use a different compiler to compile FreeBSD has several advantages. I'm sure I don't need to list them here. A little sidenote: So far I only heard about complaints regarding icc v8. I haven't heard about problems with icc v7. So far only icc v7 is able to produce a working kernel. V8 is not as mature as v7 in my eyes. I thrust David when he says AMD has identified several issues with icc, but not every issue may be because of malicious intent. I don't want to rule out malicious intent, but if AMD is willing to share small programs with me which exhibit the problems, I'm willing to test them on the Athlon-XP I own (and on the P4). And as the commercial license includes support, I'm also willing to file problem reports for issues I can reproduce. When they tell me, they aren't interested in fixing bugs with non-Intel CPUs, we will know more about the politics involved. Since AMD isn't working in the compiler business, there shouldn't be much concerns here (as long as other compiler vendors can get access to the same tests). Bye, Alexander. -- I will be available to get hired in April 2004. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7