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 <adr...@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 <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% >> >> 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@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" >> > _______________________________________________ > 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" > _______________________________________________ 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"