Slashdot Mirror

← Back to Stories (view on slashdot.org)

Open Source OS Benchmarking Competition

Posted by timothy on from the make-it-squeal-like-a-pig dept.

BenchmarkingFreak writes "OSnews is running a story about a new benchmarking competition: OSU Open Source Lab wanted to take the concept of benchmarking a little bit further with the Beaver Challenge 2004. In this competition they will be allowing a community of experts in each OS to tweak their configurations to ensure maximum performance. And they are running it all on wicked machines, just imagine... well you know."

3 of 314 comments (clear)

  1. A Cool Idea, But... by Hornsby · · Score: 4, Informative

    This is a really neat idea, and it's a long time coming; however, I wouldn't expect overly divergent results among Linux distributions. Afterall, they're all going to use the latest 2.4 and 2.6 kernel and comparable glibc versions(with maybe the exception of Debian), so the only speed difference should be in the compiler flags used to build the packages. I'm not trying to negate the coolness of this competition because it should give a good measure of performance between the BSD distros VS Linux distros, but don't be surprised when the Linux distros all show comparable results. As a footnote, I do expect Gentoo to come in the lead of the Linux distros having tried them all and found it the fastest in empircal testing...

    --
    A musician without the RIAA, is like a fish without a bicycle.
    1. Re:A Cool Idea, But... by Aardpig · · Score: 3, Informative

      It wouldnt take much to offer "up an running in 10 minutes" iso's to people with a default set of apps, portage & tree etc

      What, you mean like the 2-disk Live CD option offered by, erm, what's its name, Gentoo Linux? Sure, there's a bit of tweaking to do, but almost everything is precompiled. Too much for you? Then perhaps Gentoo's not for you.

      --
      Tubal-Cain smokes the white owl.
  2. Re:Hyper Threading by slamb · · Score: 4, Informative
    If you enable HT, you are cutting your L3 cache in half per "processor." So your 2.5Ghz Xeon with 512k cache turns into two 2.5ghz chips with 256k each.

    Interesting. That's not the reason for disabling HyperThreading that I've heard. I often hear people say it should be disabled unless you have a scheduler that supports HyperThreading well. There are lots of opportunities to go wrong when scheduling tasks on HT-enabled CPUs.

    For example, if you have one real processor and are running a high-priority task and a low-priority task, the low-priority task will get 50% of the processor time with a non-HT aware scheduler, since it says "well, I've got this processor free, so I might as well use it" when that's not really true. This problem is discussed more here.

    Similarly, if you've got several high-performance tasks and several real processors, you want to spread them out across as many real processors as possible to maximize parallelism.