On Sun, Apr 11, 2010 at 9:12 PM, Maho NAKATA <cha...@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%
I'm not sure if this is the exact issue, but it might be a point
of reference worth investigating:
http://lists.freebsd.org/pipermail/freebsd-hackers/2010-March/031004.html
Thanks,
-Garrett
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
