Date: Mon, 19 Dec 2011 13:21:35 +0100 From: Andreas Nilsson <andrnils@gmail.com> To: "Samuel J. Greear" <sjg@evilcode.net> Cc: Adrian Chadd <adrian@freebsd.org>, "lev@freebsd.org" <lev@freebsd.org>, FreeBSD Stable Mailing List <freebsd-stable@freebsd.org>, Current FreeBSD <freebsd-current@freebsd.org>, "freebsd-performance@freebsd.org" <freebsd-performance@freebsd.org>, "O. Hartmann" <ohartman@zedat.fu-berlin.de>, Jeremy Chadwick <freebsd@jdc.parodius.com> Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server Message-ID: <-4802855903238902044@unknownmsgid> In-Reply-To: <CANY-Wm9-JTN0gvjoRv4XFMDaweoPSoZ4erTUto3Z-s1LxqGzhg@mail.gmail.com> References: <4EE1EAFE.3070408@m5p.com> <CAJ-FndDniGH8QoT=kUxOQ%2BzdVhWF0Z0NKLU0PGS-Gt=BK6noWw@mail.gmail.com> <4EE2AE64.9060802@m5p.com> <4EE88343.2050302@m5p.com> <CAFHbX1%2B5PttyZuNnYot8emTn_AWkABdJCvnpo5rcRxVXj0ypJA@mail.gmail.com> <4EE933C6.4020209@zedat.fu-berlin.de> <CAPjTQNEJDE17TLH-mDrG_-_Qa9R5N3mSeXSYYWtqz_DFidzYQw@mail.gmail.com> <20111215024249.GA13557@icarus.home.lan> <4EE9A2A0.80607@zedat.fu-berlin.de> <CAJ-VmomWnAvsVPcK0mfFECvFw_FKcja1m3NE9ue=TOkF%2Bx14Xg@mail.gmail.com> <CANY-Wm8jbtr3tiwdGQMDx8SVZKEBspGwTV7Q0wziYWsV%2Bf3BSQ@mail.gmail.com> <6140271.20111219122721@serebryakov.spb.ru> <CANY-Wm9-JTN0gvjoRv4XFMDaweoPSoZ4erTUto3Z-s1LxqGzhg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 19 dec 2011, at 12:50, "Samuel J. Greear" <sjg@evilcode.net> wrote: > 2011/12/19 Lev Serebryakov <lev@freebsd.org>: >> Hello, Samuel. >> You wrote 15 =D0=B4=D0=B5=D0=BA=D0=B0=D0=B1=D1=80=D1=8F 2011 =D0=B3., 16= :32:47: >> >>> Other benchmarks in the Phoronix suite and their representations are >>> similarly flawed, _ALL_ of these results should be ignored and no time >>> should be wasted by any FreeBSD committer further evaluating this >>> garbage. (Yes, I have been down this rabbit hole). >> Here is one problem: we have choice from three items: >> >> (1) Make FreeBSD looks good on benchmarks by "fixing" FreeBSD >> >> (2) Make FreeBSD looks good on benchmarks by "fixing" Phoronix >> (communication with them, convincing, that they benchamrks are unfare >> / meaningless, ets) >> >> (3) Lose [potential] userbase. >> >> You know, that these benchmarks are bad. I know. But potential (and >> even some current!) user doesn't. And it seems, that these benchmarks >> become popular over Internet. >> >> -- >> // Black Lion AKA Lev Serebryakov <lev@FreeBSD.org> >> > > Here is where you completely derail the train, let me paste again what > I said before. > > ... > Take the first test as an example, Blogbench read. This doesn't raise > any red flags, right? At least not until you realize that Blogbench > isn't a read test, it's a read/write test. So what they have done here > is run a read/write test and then thrown away the write results for > both platforms and reported only the read results. If you dig down > into the actual results, > http://openbenchmarking.org/result/1112113-AR-ORACLELIN37 -- you will > see two Blogbench numbers, one for read and another for write. These > were both taken from the same Blogbench run, so FreeBSD optimizes > writes over reads, that's probably a good thing for your data but a > bad thing when someone totally misrepresents benchmark results. > ... > > FreeBSD actually does _BETTER_ (subjectively) in this test than the > Linux system when you look at what is really going on. FreeBSD is > favoring writes, which is _GOOD_. FreeBSD does not need to be fixed, > the benchmarks need to be fixed to represent reality rather than > throwing half of the results in the trash. To be quite frank, "fixing" > FreeBSD to look good on this benchmark will make it a worse real-world > OS. But you guys go ahead and foot-shoot over these ridiculous > benchmarks all you want. > > Sam > I seem to remember that before ULE people were fleeing to Linux as the os to run apache on since 4BSD didn't scale all too well. That may have changed over time though. However ULE could perhaps be made aware technologies like turbo-boost, ie with few threads higher performance might be gained by utilizing all virtual cores on a physical core before spreading tasks to too different cores. Just my speculations though :) Regards Andreas Nilsson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?-4802855903238902044>