Only 70% of theoretical peak performance on FreeBSD 8/amd64,
lists at mawer.org
Mon Apr 12 13:58:20 UTC 2010
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"
More information about the freebsd-stable