Date: Fri, 23 Dec 2011 16:40:24 +0100 From: "O. Hartmann" <ohartman@zedat.fu-berlin.de> To: Martin Sugioarto <martin@sugioarto.com> Cc: freebsd-performance@freebsd.org, freebsd-current@freebsd.org, Igor Mozolevsky <igor@hybrid-lab.co.uk>, Daniel Kalchev <daniel@digsys.bg> Subject: Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server Message-ID: <4EF4A0E8.1050601@zedat.fu-berlin.de> In-Reply-To: <20111223154737.4e5da6de@zelda.sugioarto.com> References: <xf5fxrkpagw2qf65tk9y2njf.1324492907631@email.android.com> <4EF25468.9040204@gmail.com> <CAOjFWZ7%2Bx61QPB-cO5ppWwY-nCRFvs9P76H_SO%2BCSL41APLwsA@mail.gmail.com> <CADWvR2jVPkLrM686Xhk12U0poV7CCqB3LF_ZbTPTHFKjt%2BdP=g@mail.gmail.com> <4EF2C613.3020609@digsys.bg> <CADWvR2jQMcOrPEzU5Ug4TRp9hxvD6qOVTZYjqqozarA-%2B-DsQw@mail.gmail.com> <4EF3D68C.2060803@zedat.fu-berlin.de> <20111223074706.1afe4d26@zelda.sugioarto.com> <4EF4474B.3050203@digsys.bg> <20111223154737.4e5da6de@zelda.sugioarto.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig59B71D83F5A2078083DBFC0A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 12/23/11 15:47, Martin Sugioarto wrote: > Am Fri, 23 Dec 2011 11:18:03 +0200 > schrieb Daniel Kalchev <daniel@digsys.bg>: >=20 >> The -RELEASE things is just a freeze (or, let's say tested freeze) of = >> the corresponding branch at some time. It is the code available and=20 >> tested at that time. >=20 > Hi Daniel, >=20 > obviously performance is not a quality aspect, only stability. > =20 >> FreeBSD is not a distribution. It also compiles with the latest >> compiler=20 >> - LLVM. :) >=20 > I thought that the "D" in FreeBSD stands for "distribution". Yes, it's > ok that it compiles with LLVM. Does it also run faster in benchmarks? >=20 >> I find it amusing, that people want everything compiled with GCC 4.7, = >> which is still very much developing, therefore highly unstable and=20 >> (probably) full of bugs. >=20 > When you don't use the software don't complain that it is buggy, > because you won't find the bugs. You cannot always tell the others to > make everything perfect. As with GCC4.7, CLANG/LLVM is still considered "experimental" and definitely has some issues with CPU architectures beyond Core2. Personally, I compile everthing now with CLANG on FreeBSD 9.0/10.0 as far as I don't realise any conerns towards correctness and stability. Well, the GCC 4.7 came somewhere up and I picked it up, sorry. It is much easier to replace gcc 4.7 in this thread by 4.6.2, which is now considered stable and in production. And as some of the writers in this thread mentioned, the performance gain could be enormous since gcc 4.6 does support either core i7 architectures and its new facilities, the optimizer is aware of the core/uncore design an, maybe, of the three-folded cache levels. Is the legacy gcc 4.2 aware of that? I guess not, since it does not support architectures beyond Core2. I tried using gcc 4.6.2 from ports to compile world, but I failed. Simply replacing/setting CC, CXX and CPP isn't obviosuly enough. >=20 > I don't want to have everything compiled on $COMPILER. I want that > there is a reasonable quality. And for me quality is not only > stability, but also speed. Yes, agree. I think quality could inherit also a reasonable speed. Speed at all costs, even stability, is no option. Even for HPC systems, where jobs run uninetrupted for weeks or months (in our case). >=20 >> Many suggested that the Linux binaries be run via the FreeBSD Linux=20 >> emulation. Unchanged. >> There is one problem here though, the emulation is still 32 bit. With the usage of even 32bit Linux binaries you introduce all the mess you want to avoid by using FreeBSD. But it is very often recommended to use the so called Linuxulator. I'm happy to have this opportunity (I can not run FreeBSD binaries on some Ubuntu or Centos distros). But in some cases people of the FreeBSD community rely to much on this 32bit-limited option. I always prefer native BLOBs over emulated BLOBs. >=20 > I'm not talking about emulation. I don't use FreeBSD to run emulated > binaries. I (any many people) want efficient servers and eventually > desktops. You should not expect people to tune the system for speed, > when it's clear that default setting does not make any sense. People > will use default settings, because they trust developers that they > thought about balanced stability, security and performance. >=20 >> FreeBSD has safe default. >=20 > This is what I am talking about. Don't complain that the benchmark does= > not show efficience. No one is interested in tuning FreeBSD just for a > benchmark application. >=20 >> It is supposed to work out of the box on=20 >> whatever hardware you put it. As much as it has drives for that=20 >> hardware, of course. >> Once you have working installation, you may tweak it all the way you >> wish. >=20 > But if you don't tweak, you get a fair result in a benchmark. This is > what you will see as a user of the system. These are the default > settings, that means developers chose them as the BEST choice for the > system. Well, it is a very nice moce to have conservative settings to make FreeBSD stable for everyone intend to use it out of the box. But what I really miss is a certain, group of people dedicated to HPC and secure, stable tweak achieving that. The operating system is a nature and live. It is a balance of a limited resource. One can try to balance out every potential workload that can occur and the result is a very good allround syste, But in the server or HPC area, it might be necessary to push some parts in favor of some others. When computing, I do not need high USB performance, except a responsive keyboard. I/O and CPU performance is the main goal, but this seems the most difficult part. A file or network server, for instance, would balance more towards network I/O or delivering small data pieces instead of large streaming blocks of memory. I'm certain that the tweaks would differ for both scenarios. At home or at the desktop, the situation is more complicated, since people tend to use a lot of multimedia stuff and jumping audio is also not a very pleasant thing as stuck video. > =20 >> If your installation is pre-optimized, chances are it will crash all >> the time on you and there will be no easy way for you to fix, short >> of installing another "distribution". >=20 > Sorry, no. If optimization makes bugs appear, there are bugs in the > code (somewhere). And you will never find them when you hide them like > this. You will also never see many advances in performance. >=20 > -- > Martin Agree. Benchmarking could push a system towards its limits and reveal limits or bugs that make them crash. It is better to have them crash in a benchmark torture than in a data center delivering valuable data for business or in science, when the server crashes just before finishing a two month run due to some buffer problems ... oh --------------enig59B71D83F5A2078083DBFC0A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQEcBAEBAgAGBQJO9KDuAAoJEOgBcD7A/5N8i5UH/A0PFxhgokV/43lyNvbCsp2M +rLcZVKwnC4y8/ZudlRmR5PqjRdrhFQiBxKOVR1nEjPjL84wZGvwGj6d5xTzJL4x KXEV4R67jbtXeQCyEWlZuXwIRDLyDP0IcKb7QTx2+eqtLNZPdgIN73UiYkQi/iS4 aJ285fa9nK9SU3s8IpRMK1FcbTsUE7B1lOFiDH0RUEgClq+eI+BVQ4DitQejoT1v 0OO7mK4IPAsdSlmEFc9NvBY3cQtTIii+lACpFzIPXuggLUV1OE4XOSEOCTF3XBkz fZNHf/OQTUpiUT7PG2B4vYaa6PlLG822TBETfIxmQyLw9o+LTU7aZ8oxzasUecE= =1D13 -----END PGP SIGNATURE----- --------------enig59B71D83F5A2078083DBFC0A--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4EF4A0E8.1050601>