Slashdot Mirror


Byte Benchmarks Various Linux Trees

urbanjunkie writes: "Moshe Bar has an interesting article, essentially benchmarking the standard kernel (with aa VM) against the -ac kernel (with Rik's VM)." He also raises some very interesting points about how patches (and entire development trees) interact.

3 of 269 comments (clear)

  1. Re:Pournelle ? by netringer · · Score: 1, Offtopic
    I always thought he's a science-fiction author?
    He is.

    He also is(was?) the author of the "User's Column" in BYTE magazine.

    I haven't seen nor heard of him in the last decade, although I did talk to him on the phone once. (I did tech support and called him back.)
    --
    Ever dream you could fly? Get up from the Flight Sim. I Fly
  2. Re:what's the point? by Arandir · · Score: 3, Offtopic

    I'm using FreeBSD as a desktop OS at home and as a workstation at work. It's simply great!

    There are only two advantages I see to Linux that makes it a better "desktop" OS. First, they put DRI in the kernel. They're working on this now for FreeBSD, but there's a lot of resistance to keep userland stuff out of kernelland. If all you care about is running games, then FreeBSD is not it. Go get a PS2 or an XBox.

    Second, the popularity of Linux gives it a greater pool of developers to draw from. So Linux gets new device drivers faster. But you still will *not* get Linux shoehorned into this week's premium super buy at CompUSA. With Linux you have to wait around three months to get a driver for brand new hardware. With FreeBSD you have to wait about six months. If you buy computers more often than once every six months, stick with Linux. As for myself, I had no problems with FreeBSD on a stock Dell Optiplex GX240.

    In terms of desktop software, don't worry a bit about it. They're the same on both platforms. Identical. Staroffice, GNOME, KDE, Xmms, Gimp, Mozilla, etc.

    --
    A Government Is a Body of People, Usually Notably Ungoverned
  3. A suggestion by nusuth · · Score: 1, Offtopic
    I can't answer the kernel related part of your question, however a possible workaround is forcing future reads from active pages by preaccessing them. E.g, before starting on processing [N,N+K) cluster, read value(s) of N+K, N+2K, N+3K up to N+JK and write them back. For a suitable K,J pair, you should experience linear performance drop. A K=8000 and J=1 sounds reasonable to me.

    &ltspeculation> AFAIK kernel uses a hairy buddy system (but I did not check that myself), if that is the case, not whole memory is accessible in an arbitrary allocation sequence. So your analysis of exceeding 1024Megs of memory by less than 10 Megs is incorrect. You have to allocate progressively smaller page sizes that follow fibinocci(sp) series (or something like that, see your local kernel hacker for more info) if you want whole your data in memory. &lt/Speculation>

    --

    Gentlemen, you can't fight in here, this is the War Room!