Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 12 Apr 2010 17:31:05 +0800
From:      Adrian Chadd <adrian@freebsd.org>
To:        Maho NAKATA <chat95@mac.com>
Cc:        freebsd-stable@freebsd.org
Subject:   Re: Only 70% of theoretical peak performance on FreeBSD 8/amd64,  Corei7 920
Message-ID:  <t2ud763ac661004120231q44e9a4f7z5c0f11a31725deb@mail.gmail.com>
In-Reply-To: <20100412.131213.4959786962516027.chat95@mac.com>
References:  <20100412.131213.4959786962516027.chat95@mac.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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@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 amd6=
4 using dgemm
> (a linear algebra routine, matrix-matrix multiplication).
> I obtained only 70% of theoretical peak performance on FreeBSD 8/amd64 an=
d
> 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 c=
omputing. 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 sti=
ll not very will
>> sophisticated, but on *BSDs, its worst; they uses too fine memory alloca=
tion 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 ki=
nd 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 =A0 =A0 =A0: FLOPS =A0 =A0 =A0 =A0 =A0 : percent in peak
> FreeBSD : 32.0 GFlops =A0 =A0 : 71%
> Ubuntu =A0: 42.0-42.7GFlops : 93.8%-95.3%
>
> Thanks,
> -- Nakata Maho http://accc.riken.jp/maho/ , http://ja.openoffice.org/
> =A0 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-unsubscribe@freebsd.org"
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?t2ud763ac661004120231q44e9a4f7z5c0f11a31725deb>