Only 70% of theoretical peak performance on FreeBSD 8/amd64, Corei7 920

[Antony Mawer]

This may well be the same sort of issue that was discussed in this thread here:

    http://lists.freebsd.org/pipermail/freebsd-hackers/2010-March/031004.html

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 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?
>
>
> Adrian
>
> 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 ]
>>
>> *Abstract*
>> 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.
>>
>> *Introduction*
>> 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..
>>
>> *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      : FLOPS           : percent in peak
>> FreeBSD : 32.0 GFlops     : 71%
>> Ubuntu  : 42.0-42.7GFlops : 93.8%-95.3%
>>
>> Thanks,
>> -- 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
>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
>>
> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
>