Only 70% of theoretical peak performance on FreeBSD 8/amd64,
chat95 at mac.com
Mon Apr 12 23:24:41 UTC 2010
I think this is not the case. I tested TurboBoost on/off on Ubuntu, GotoBLAS
achieved 95% of theoretical perfomance for both cases.
and http://blog.goo.ne.jp/nakatamaho/e/86c0f4ac529fd5b530454ed795e6b466 (written in Japanese, tho)
From: Antony Mawer <lists at mawer.org>
Subject: Re: Only 70% of theoretical peak performance on FreeBSD 8/amd64, Corei7 920
Date: Mon, 12 Apr 2010 23:58:17 +1000
> This may well be the same sort of issue that was discussed in this thread here:
> 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...
> On Mon, Apr 12, 2010 at 7:31 PM, Adrian Chadd <adrian at 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?
>> On 12 April 2010 12:12, Maho NAKATA <chat95 at mac.com> wrote:
>>> Hi FreeBSD developers,
>>> [the original article in Japanese can be found at
>>> http://blog.goo.ne.jp/nakatamaho/e/b5f6fbc3cc6e1ac4947463eb1ca4eb0a ]
>>> I compared the peak performance of FreeBSD 8.0/amd64 and Ubuntu 9.10 amd64 using dgemm
>>> (a linear algebra routine, matrix-matrix multiplication).
>>> I obtained only 70% of theoretical peak performance on FreeBSD 8/amd64 and
>>> almost 95% on Ubuntu 9.10 /amd64. I'm really disappointed.
>>> I'm a friend of Gotoh Kazushige, the principal developers of GotoBLAS. He 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 still not very will
>>>> sophisticated, but on *BSDs, its worst; they uses too fine memory allocation method,
>>>> so we cannot expect large continuous physical memory allocation.
>>>> Moreover, process scheduling is not so nice as *BSD employs an algorithm that
>>>> changes physical CPUs in turn instead of allocating one core for such kind of jobs.
>>>> Take your own benchmark, and you'll see..
>>> 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 : FLOPS : percent in peak
>>> FreeBSD : 32.0 GFlops : 71%
>>> Ubuntu : 42.0-42.7GFlops : 93.8%-95.3%
>>> -- Nakata Maho http://accc.riken.jp/maho/ , http://ja.openoffice.org/
>>> Nakata Maho's PGP public keys: http://accc.riken.jp/maho/maho.pgp.txt
>>> freebsd-stable at freebsd.org mailing list
>>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
>> freebsd-stable at freebsd.org mailing list
>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
> freebsd-stable at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
More information about the freebsd-stable