Do we need this junk?

Giorgos Keramidas keramida at
Fri Apr 6 20:56:27 UTC 2007

On 2007-04-06 14:43, Nikolas Britton <nikolas.britton at> wrote:
>On 4/6/07, Ed Schouten <ed at> 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?

More information about the freebsd-current mailing list