Re: OpenBSD seems Much Faster Than FreeBSD -- Why?

Hi Timmy,

On Wed, 30 Jan 2008 03:01:43 -0500, Timmy wrote:

What I don't get is this source based speed.

Not that I've got any particular reason to doubt your impressions, but
you've offered exactly zero support for claims of one being faster than
the other, or at what, or even any suggestion that the same tasks were
being compared. So you must expect some scepticism.

LFS and Gentoo should be
fast because you spent days compiling the system from source, same with
FBSD.

Well, that's not necessarily the case, any more. Once upon a time, in
the 386/486/Pentium days [and even more so for the members of the RISC
families] there were good reasons for doing target-specific
optimization. This is *much less* the case with today's processors,
because their multi-issue out-of-order nature, and sophisticated cache
tweaks, pretty much do most of the fine-tune scheduling that you could
want at run time. Sure, some numerical code can do with tweaking and
ultra-optimization, but most operating-system code benefits from staying
small (to get the most benefit from the i-cache) and not doing anything
dumb. What I'm getting at, is that compiling from source is, these days,
almost never because you want extra performance (there's none to be had),
but usually because (a) it's easier in some way, (b) you want to have the
source on hand so that you can debug easily, or (c) you're running odd-
ball software on odd-ball hardware that no-one else cares about.

My point was, OpenBSD is the fastest O/S that I've used, and I
didn't have to spend hours compiling. Don't know about you, but I'm
starting to wonder about all of these source based O/S.

You are right to wonder. But relax: you can get FreeBSD *and* the ports
collection (most of it, anyway) in binary too. Be happy!

[point: when you say you tweaked the compiler flags, did you do stuff
like forcing in-lining, or loop unrolling? On a *lot* of OS-style code,
those are actually pessimizations.]

Cheers,

--
Andrew
.

Relevant Pages

  • Re: VB6 crashes after writing exe
    ... VB.exe to crash after compiling and writing the exe. ... Code that for some reason has a flaw that the compiler can not digest. ... the exe file. ... best thing to do is look careful at Your code and see where it could be ...
    (microsoft.public.vb.general.discussion)
  • Re: Forth input line buffered, why?
    ... whether interpreting or compiling waits for the user to type ... The main reason is that it's often desirable to manage the input stream while you're in it. ... I have seen implementations that compile a command line before executing it, in order to be able to use things like IF and DO in the command line, but I think executing before the user is finished typing would be very hard to get used to. ...
    (comp.lang.forth)
  • Re: Program Fails When Parameter Fixed Constants are Changed (F77) ??
    ... routine that aren't able to be resolved by the linker. ... for this _MIGHT_ be you're not compiling the module which now contains ... A reason for that could be as simple as you ... cause a link error. ...
    (comp.lang.fortran)
  • Re: Forth input line buffered, why?
    ... whether interpreting or compiling waits for the user to type ... Is there a reason for this, ... apart from avoiding the output getting mixed up with the input? ... emulate the buffer if in ANS mode. ...
    (comp.lang.forth)