Review Re-Request: ATLAS, a fast implementation of BLAS and LAPACK

[Dominik 'Rathann' Mierzejewski]

On Thursday, 15 September 2005 at 22:02, Quentin Spencer wrote:
> Dominik 'Rathann' Mierzejewski wrote:
> 
> >On Wednesday, 14 September 2005 at 00:18, Quentin Spencer wrote:
> > 
> >
> >[...]
> > 
> >
> >>>Not quite so. You can put all x86 RPMs in one repo and yum will select
> >>>automatically the one matching your arch from them. Example:
> >>>
> >>>In an i386 repo, there are:
> >>>atlas-devel-0.1-1.i386.rpm
> >>>atlas-devel-0.1-1.pentium3.rpm
> >>>atlas-devel-0.1-1.pentium4.rpm
> >>>atlas-devel-0.1-1.athlon.rpm
> >>>
> >>>You have, let's say, an Athlon CPU.
> >>>yum install atlas-devel
> >>>will select atlas-devel-0.1-1.athlon.rpm for installation.
> >>>
> >>>That said, x86_64 (and PPC, of course) *are* different and cannot be put
> >>>in the same repo.
> >>>     
> >>>
> [...]
> 
> >>On the other hand, can the FE build system do that?
> >>   
> >>
> >
> >That I don't know, I've only just started playing with it on my
> >buildboxes. But I think it can, considering that we have kernel.i586,
> >kernel.i686 and kernel.athlon all built from the same src.rpm.
> >
> >>How to I write the spec file to handle all of that 
> >>correctly? Are there any example I can look at?
> >
> >kernel is one, glibc is another and openssl is yet another.
> 
> I'll look into this, but I might point out that all of the examples you 
> have given are in Core, which doesn't use the same build system (though 
> I understand that could change eventually). My understanding of the 
> Extras buildsys is that it just does the three base archs and there 
> isn't (yet) a way to so subarchitectures such as i686, pentium4, etc. 
> For a previous discussion on how to package all of this, see:
> http://www.redhat.com/archives/fedora-extras-list/2005-August/msg01024.html

Yes, I remember this thread. The last person in that thread wrote
something about hwcaps. I did some digging and there isn't much
documentation lying around. So, RTFS remains. I've found one nice
doxygen'd glibc source on-line here:
http://www.students.iscte.pt/lamb/doxygen-glibc/html/i386_2dl-procinfo_8h.html

I assume XMM and XMM2 are SSE and SSE2, respectively. AMD3D would be 3DNow!,
but according to, for example, gmp's spec, SSE2 libs go to %{_libdir}/sse2,
so I wonder where to find a list of these? Probably in glibc sources.

Indeed:
http://www.students.iscte.pt/lamb/doxygen-glibc/html/i386_2dl-procinfo_8c.html

That list is old, though. A current one (from glibc-2.3.5) contains:
    "fpu", "vme", "de", "pse", "tsc", "msr", "pae", "mce",
    "cx8", "apic", "10", "sep", "mtrr", "pge", "mca", "cmov",
    "pat", "pse36", "pn", "clflush", "20", "dts", "acpi", "mmx",
    "fxsr", "sse", "sse2", "ss", "ht", "tm", "ia64", "pbe"

So we'd be interested in sse and sse2 for pentium3 and pentium4,
respectively. Hmm... I remember seeing amd3d in earlier versions, I wonder
what happened to it. glibc 2.3.5's i386/dl-procinfo.h still lists
HWCAP_I386_AMD3D, so I wonder what's the deal here?

Anyway, I agree that for libs an approach exploiting hwcap may be the most
convenient, but this is orthogonal to packaging libs for different CPUs in
one or in several subpackages. For example, I wouldn't want to keep SSE
and SSE2 binaries if I can avoid it, because my CPU doesn't support those
and it'd be a waste of space.

> I might add that the approach I'm using here is exactly what Debian is 
> doing, which is the only other effort I'm aware of to package this for 
> wide distribution.

Well, Debian is... different. ;)

Regards,
R.

-- 
APT/YUM RPM repository for Fedora Core http://rpm.greysector.net/
mpg321, xmp, faad2, lame, mad, *mplayer*, rdesktop, tin, xvid, mks, mutt
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"