Date: Thu, 18 Mar 2004 22:16:58 +0100 From: Alexander Leidinger <Alexander@Leidinger.net> To: Scott Long <scottl@freebsd.org> Cc: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= <des@des.no> 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 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> <xzp8yhylzvr.fsf@dwp.des.no> <20040318145507.7acb75fc@localhost> <405A02DE.7000402@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 18 Mar 2004 13:13:18 -0700
Scott Long <scottl@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040318221658.3910c2eb>