On 2007-04-06 14:43, Nikolas Britton <nikolas.britton_at_gmail.com> wrote: >On 4/6/07, Ed Schouten <ed_at_fxq.nl> 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?Received on Fri Apr 06 2007 - 18:56:27 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:07 UTC