Date: Mon, 12 Apr 2010 23:58:17 +1000 From: Antony Mawer <lists@mawer.org> To: Adrian Chadd <adrian@freebsd.org> Cc: Maho NAKATA <chat95@mac.com>, freebsd-stable@freebsd.org Subject: Re: Only 70% of theoretical peak performance on FreeBSD 8/amd64, Corei7 920 Message-ID: <h2yea2d4a5b1004120658xba353f17w894d33e08558f3ea@mail.gmail.com> In-Reply-To: <t2ud763ac661004120231q44e9a4f7z5c0f11a31725deb@mail.gmail.com> References: <20100412.131213.4959786962516027.chat95@mac.com> <t2ud763ac661004120231q44e9a4f7z5c0f11a31725deb@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This may well be the same sort of issue that was discussed in this thread h=
ere:
http://lists.freebsd.org/pipermail/freebsd-hackers/2010-March/031004.ht=
ml
In short, the Core i7 CPUs have a feature called "TurboBoost" where
the clock speed of one or more cores is boosted when other cores are
idle and in a C2 or C3 sleep status ... if the appropriate power
saving mode isn't active on the system (which I don't think FreeBSD
does by default?), the idle cores are never put into the appropriate
power saving state, and as a result TurboBoost never kicks in...
It _may_ be that Ubuntu configures this correctly whereas FreeBSD does
not (out of the box)?
Of course it may be something else entirely, but worth checking out...
--Antony
On Mon, Apr 12, 2010 at 7:31 PM, Adrian Chadd <adrian@freebsd.org> wrote:
> Of course, what would be helpful is actually figuring out what is
> going on rather than some conjecture. :)
>
> With what he said, tweaking memory allocation under FreeBSD and/or
> linux would change the performance characteristics and either validate
> or disprove his assumptions?
>
>
> Adrian
>
> On 12 April 2010 12:12, Maho NAKATA <chat95@mac.com> wrote:
>> Hi FreeBSD developers,
>> [the original article in Japanese can be found at
>> http://blog.goo.ne.jp/nakatamaho/e/b5f6fbc3cc6e1ac4947463eb1ca4eb0a ]
>>
>> *Abstract*
>> I compared the peak performance of FreeBSD 8.0/amd64 and Ubuntu 9.10 amd=
64 using dgemm
>> (a linear algebra routine, matrix-matrix multiplication).
>> I obtained only 70% of theoretical peak performance on FreeBSD 8/amd64 a=
nd
>> almost 95% on Ubuntu 9.10 /amd64. I'm really disappointed.
>>
>> *Introduction*
>> I'm a friend of Gotoh Kazushige, the principal developers of GotoBLAS. H=
e told me that
>> FreeBSD is not suitable OS for scientific computing or high performance =
computing. He says
>> (in Japanese and my translation):
>>
>>> I guess FreeBSD does page coloring, but I don't think FreeBSD considers=
very large cache
>>> size which recent CPU has. Support of a very large cache on Linux is st=
ill not very will
>>> sophisticated, but on *BSDs, its worst; they uses too fine memory alloc=
ation method,
>>> so we cannot expect large continuous physical memory allocation.
>>> Moreover, process scheduling is not so nice as *BSD employs an algorith=
m that
>>> changes physical CPUs in turn instead of allocating one core for such k=
ind of jobs.
>>> Take your own benchmark, and you'll see..
>>
>> *Result*
>> Machine: Core i7 920 (42.56-44.8Gflops) / DDR3 1066
>> OS: FreeBSD 8.0/amd64 and Ubuntu 9.10
>> GotoBLAS2: 1.13
>>
>> dgemm result
>> OS =A0 =A0 =A0: FLOPS =A0 =A0 =A0 =A0 =A0 : percent in peak
>> FreeBSD : 32.0 GFlops =A0 =A0 : 71%
>> Ubuntu =A0: 42.0-42.7GFlops : 93.8%-95.3%
>>
>> Thanks,
>> -- Nakata Maho http://accc.riken.jp/maho/ , http://ja.openoffice.org/
>> =A0 Nakata Maho's PGP public keys: http://accc.riken.jp/maho/maho.pgp.tx=
t
>>
>>
>>
>>
>> _______________________________________________
>> freebsd-stable@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org=
"
>>
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?h2yea2d4a5b1004120658xba353f17w894d33e08558f3ea>