Date: Tue, 10 Nov 2009 01:57:52 -0600 (CST) From: Scott Bennett <bennett@cs.niu.edu> To: chat95@mac.com Cc: bf1783@googlemail.com, freebsd-questions@freebsd.org Subject: math/atlas-devel build times (was Re: math/py-numpy vs. math/atlas-devel) Message-ID: <200911100757.nAA7vqJL009352@mp.cs.niu.edu>
next in thread | raw e-mail | index | archive | help
On Tue, 10 Nov 2009 15:41:05 +0900 (JST) Maho NAKATA <chat95@mac.com>
wrote:
>I'm willing to apply patches to atlas ports if available.
Thanks, Maho. It appears that the most critical change is to make
sure the tools can know that math/atlas and math/atlas-devel conflict
with each other, so that if one is already installed, the tools won't
try to install the other.
>I talked with Goto Kazushige (author of GotoBLAS), he told me
>that L2 cache handling on FreeBSD is very bad. It may be a reason
I would be very interested in knowing in detail why he thinks that.
The ATLAS build procedure, however, does use a very crude algorithm
for detecting the sizes of L1 and L2 caches that "detects" cache sizes
much smaller than they actually are. I think there are some ways of
correcting the "detected" sizes, but they involve editing source files
and making decisions that go way beyond anything that the FreeBSD ports
system is equipped to handle. Assuming cache sizes that are typically
1/2 or 1/4 of the actual sizes will quite naturally give less than optimal
results. It is worth noting, though, that this same algorithm for cache
size detection is used for building ATLAS on any operating system on i386
or amd64 architectures.
>why ATLAS build is so fragile. On Linux machines, it takes only 20 min or so.
>
As I wrote before, the sensitivity is based upon the variance of a
run times. The sample size is quite small, so any sizable differences in
even one or two run times can put the variance over the build procedure's
tolerance threshhold. On my machine, I always had to edit a source file
to increase the number of iterations of each test from 10 to either 100 or
1000 in order to get the sensitivity down to where occasional other activity
in the system wouldn't kill the ATLAS build. However, math/atlas-devel in
FreeBSD 7.2 surprised me by building cleanly with no such intervention
required, which pleased me greatly, of course. I don't know what the authors
changed to make this happen. In any case, the variance sensitivity problem
ought to be the same, regardless of operating system.
The ATLAS build procedure builds an unthreaded version of the library
on any system. If more than one logical/physical CPU is detected, it also
builds a threaded version. You didn't mention the system configuration that
can allegedly build ATLAS in only 20 minutes. I'm building it on a Dell
Inspiron XPS, which has a 3.4 GHz P4 Prescott CPU. The L1 caches are 64 KB
each, IIRC, and the L2 cache is 1 MB, but ATLAS's build procedure typically
decides that the L1 size is 16 KB or less and the L2 size is 256 KB. I have
hyperthreading enabled, so the build procedure sees two (logical) CPUs, but
the gains from the hyperthreading are very small in this situation. Building
ATLAS on a truly dual-cored system ought to give much shorter build times,
and building it on a Core i7 system ought to be tremendously faster with or
without enabling the i7's reputedly better implemented HT. The P4 Prescott
is now a very old chip model. (I bought this machine new five years ago.)
The last time I checked, the LINUX kernel still didn't know the
difference between logical CPUs and physical CPUs, so it's difficult to
see how its cache management in a HT environment could be any better than
FreeBSD's. Maybe LINUX has been updated to understand five-year-old
technology since I last checked, but that still should only make it closer
to FreeBSD's performance, not radically faster than FreeBSD.
Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet: bennett at cs.niu.edu *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good *
* objection to the introduction of that bane of all free governments *
* -- a standing army." *
* -- Gov. John Hancock, New York Journal, 28 January 1790 *
**********************************************************************
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200911100757.nAA7vqJL009352>