From owner-freebsd-current@FreeBSD.ORG Fri Apr 6 20:56:27 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BD52A16A405 for ; Fri, 6 Apr 2007 20:56:27 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 39C6F13C45D for ; Fri, 6 Apr 2007 20:56:26 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (dialup137.ach.sch.gr [81.186.70.137]) (authenticated bits=128) by igloo.linux.gr (8.13.8/8.13.8/Debian-3) with ESMTP id l36KtW2l014646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 6 Apr 2007 23:55:40 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.13.8/8.13.8) with ESMTP id l36KtQV0036324; Fri, 6 Apr 2007 23:55:26 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.13.8/8.13.8/Submit) id l36KtPbS036323; Fri, 6 Apr 2007 23:55:25 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Fri, 6 Apr 2007 23:55:25 +0300 From: Giorgos Keramidas To: Nikolas Britton Message-ID: <20070406205524.GA34638@kobe.laptop> References: <20070405103708.GC842@turion.vk2pj.dyndns.org> <20070405.140109.39240822.imp@bsdimp.com> <20070406142326.GC6950@hoeg.nl> <20070406153500.GE6950@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.686, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.51, BAYES_00 -2.60, DNS_FROM_RFC_ABUSE 0.20) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: FreeBSD Current , Ed Schouten Subject: Re: Do we need this junk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 20:56:27 -0000 On 2007-04-06 14:43, Nikolas Britton wrote: >On 4/6/07, Ed Schouten wrote: >> Renaming a platform is the root of all evil. Think about the big >> amount of ports and source code that just check for $arch == "i386". >> That's the reason the i386 port is still named i386, though it >> doesn't even support i386 at all (got removed in 6.x). >> >>> The primary reason for doing this is optimization and simplification >>> of support / development. >> >> Indeed. You'll simplify development, because half of the developers >> is unable to run the bloody thing. Just run FreeBSD/amd64 if the >> legacy bits upset you. > > That's not true. If you look at the stats I posted over 58% of the > systems have SSE2 support, compared to the 20%* with 64-bit > capability. > > The legacy bits don't upset me, what upsets me is sacrificing > performance so we can support a minority of legacy systems. IIRC? we > could recode the Kernel for SSE2 math if the processor was guaranteed > to have that SSE2 instruction set. I am sure your intentions are good, and you really do believe that we have a huge performance increase to gain by using "SSE2 recoding", but are you *really* sure we have so much to gain from SSE2 instructions? Even if there _is_ a certain amount of speed which can be gained by building an optimized kernel, there are very good reasons why the default kernels shipped with the release CD-ROM images of FreeBSD are *not* optimized. > The problem with 64-bit FreeBSD is performance, on average its slower > than FreeBSD i386 and FreeBSD i386 is already quite slow without > custom optimizations. i.e. lots of recompiling... New users frequently > get themselves into a big mess because it takes years of knowledge > about FreeBSD internals to make it fast without breaking it. Rebuilding a complete, working, fully functional FreeBSD system is much much, really *very* much, easier than, say, building a custom Gentoo Linux installation and verifying that it still works as expected. The FreeBSD system itself provides all the tools and all the necessary bits to rebuild everything from source, so why is recompiling something such a big problem? There are also other systems out there, which ship with unoptimized binaries, because they value observability, debuggability and the availability of binary tracing, debugging, auditing and fixing. One of them is Solaris, which even runs with 32-bit binaries for utilities like /usr/bin/ls on 64-bit systems. Optimization and tuning is not the be-all, end-all, the ultimate target, and the life purpose of every single one of us. So, why should it be forced on all of us?