Re: Altivec in baseline for ppc64?
Le mardi 13 juillet 2021 à 21:04 +0200, John Paul Adrian Glaubitz a écrit : > On 7/13/21 1:55 PM, Sébastien Villemot wrote: > > The wiki page that synthesizes architecture specificities indicates > > that Altivec is included in the baseline for the ppc64 port: > > https://wiki.debian.org/ArchitectureSpecificsMemo#ppc64 > > > > However my understanding is that this port supports any powerpc64 CPU, > > including some that don’t have Altivec (e.g. POWER4 or POWER5). This is > > also what the main wiki page for PPC64 says: > > https://wiki.debian.org/PPC64 > > > > Can someone please clarify the situation? > > The ppc64 originally used the ppc64 baseline including AltiVec e.g PowerPC970, > (64-Bit PowerMac). However, the previous port maintainer decided he wanted to > support embedded systems such as the PowerPC E5500 which does not support > AltiVec. Thanks for this clarification. I have updated the architectures wiki page accordingly. > > (I’m asking because I’m the maintainer of the openblas package, and > > knowing whether Altivec is available or not, and more generally what is > > in the baseline, is essential for proper packaging). > > Please go ahead and enabled AltiVec as I don't think it makes much sense to > use BLAS > on machines without any SIMD support. If any user complains about > compatibility issues, > please feel free to bring up the issue here again. I think I disagree with this idea. OpenBLAS can be pulled in by chains of dependencies, even for users who do not even know what BLAS is. Violating the baseline can lead to hard-to-understand crashes. Since I think that reliability is more important than performance, I prefer to strictly respect the baseline in the binary package. However note that locally recompiling OpenBLAS is a supported and documented procedure, for those who want to take full advantage of their hardware. Regarding the kernel that is currently built in the official binary, I could do with some help to determine which one is the best. You can see the list of kernels at this address: https://salsa.debian.org/science-team/openblas/-/tree/master/kernel/power Each KERNEL.* file lists a bunch of source files, many of which are assembly files. Currently, I use POWER4 for ppc64 and PPCG4 for powerpc, but I’m unsure that those are the right choice. I want a kernel that respects the baseline, but still taking advantage of all that is in the baseline. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Re: Altivec in baseline for ppc64?
Le mardi 13 juillet 2021 à 20:06 +0200, Mathieu Malaterre a écrit : > On Tue, Jul 13, 2021 at 7:21 PM Sébastien Villemot > wrote: > > Le mardi 13 juillet 2021 à 18:56 +0200, Mathieu Malaterre a écrit : > > > > > > On Tue, Jul 13, 2021 at 2:04 PM Sébastien Villemot > > > wrote: > > > > > > > > The wiki page that synthesizes architecture specificities indicates > > > > that Altivec is included in the baseline for the ppc64 port: > > > > https://wiki.debian.org/ArchitectureSpecificsMemo#ppc64 > > > > > > > > However my understanding is that this port supports any powerpc64 CPU, > > > > including some that don’t have Altivec (e.g. POWER4 or POWER5). This is > > > > also what the main wiki page for PPC64 says: > > > > https://wiki.debian.org/PPC64 > > > > > > > > Can someone please clarify the situation? > > > > > > > > (I’m asking because I’m the maintainer of the openblas package, and > > > > knowing whether Altivec is available or not, and more generally what is > > > > in the baseline, is essential for proper packaging). > > > > > > I do not believe that you can do much as a packager. You cannot assume > > > anything on the target arch. You need to do the same thing as ffmpeg > > > is doing for avx2/sse4 on amd64, you need to do runtime detection. So > > > unless upstream is doing something very clever you cannot compile blas > > > using any of the fancy altivec instructions :( > > > > > > The man page for ld.so mentions something about optimized libraries > > > (search for "/usr/lib/sse2/"), but this is currently not in use in > > > Debian (AFAIK). > > > > Actually OpenBLAS has its own runtime detection mechanism, which is > > used to select the best linear algebra kernel for the current CPU > > (those kernels are mainly written in assembly, and take advantage of > > available ISA extensions). This mechanism is used on several archs, > > including ppc64el (so at runtime, OpenBLAS chooses between a POWER8 and > > a POWER9 kernel; there is even a POWER10 kernel already available). > > > > However, I cannot enable this mechanism on ppc64 and powerpc, because > > the runtime detection only works for POWER6 and above, and my > > understanding is that for these two ports the baseline is lower. Hence > > on these two archs, only one kernel is included in the package binaries > > (currently POWER4 for ppc64 and PPCG4 for powerpc). For optimal > > performance, users should recompile OpenBLAS locally (as indicated in > > the package description and in README.Debian). > > There are plenty of people on this mailing list that could test/verify > that. Is there a quick way to check that your openblas package is > compiled correctly for ppc32 and ppc64 (like a verbose mode) ? Did you > do any experiment on perotto.debian.net ? perotto.debian.net is POWER8, so it’s clearly well above the baseline. The package runs fine there, but that does not tell anything about baseline violation. Verifying that the package compiled fine and passed its testsuite on build daemons does not give any information about baseline violation either, because buildds are probably above the baseline as well. FYI, the most recent build logs are there: https://buildd.debian.org/status/package.php?p=openblas=experimental (there is a problem with powerpc in experimental; but the version in sid compiled). If nobody has the relevant knowledge, then the only option is to test the package on the oldest possible hardware. The easiest way to test it is to recompile it locally (since this will exercise the testsuite). Note that nobody complained for years about the situation of openblas on powerpc and ppc64. So maybe that’s a sign that the current setting is fine (either the baseline is respected, or nobody uses the package). -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Re: Altivec in baseline for ppc64?
Hi Mathieu, Le mardi 13 juillet 2021 à 18:56 +0200, Mathieu Malaterre a écrit : > > On Tue, Jul 13, 2021 at 2:04 PM Sébastien Villemot > wrote: > > > > The wiki page that synthesizes architecture specificities indicates > > that Altivec is included in the baseline for the ppc64 port: > > https://wiki.debian.org/ArchitectureSpecificsMemo#ppc64 > > > > However my understanding is that this port supports any powerpc64 CPU, > > including some that don’t have Altivec (e.g. POWER4 or POWER5). This is > > also what the main wiki page for PPC64 says: > > https://wiki.debian.org/PPC64 > > > > Can someone please clarify the situation? > > > > (I’m asking because I’m the maintainer of the openblas package, and > > knowing whether Altivec is available or not, and more generally what is > > in the baseline, is essential for proper packaging). > > I do not believe that you can do much as a packager. You cannot assume > anything on the target arch. You need to do the same thing as ffmpeg > is doing for avx2/sse4 on amd64, you need to do runtime detection. So > unless upstream is doing something very clever you cannot compile blas > using any of the fancy altivec instructions :( > > The man page for ld.so mentions something about optimized libraries > (search for "/usr/lib/sse2/"), but this is currently not in use in > Debian (AFAIK). Actually OpenBLAS has its own runtime detection mechanism, which is used to select the best linear algebra kernel for the current CPU (those kernels are mainly written in assembly, and take advantage of available ISA extensions). This mechanism is used on several archs, including ppc64el (so at runtime, OpenBLAS chooses between a POWER8 and a POWER9 kernel; there is even a POWER10 kernel already available). However, I cannot enable this mechanism on ppc64 and powerpc, because the runtime detection only works for POWER6 and above, and my understanding is that for these two ports the baseline is lower. Hence on these two archs, only one kernel is included in the package binaries (currently POWER4 for ppc64 and PPCG4 for powerpc). For optimal performance, users should recompile OpenBLAS locally (as indicated in the package description and in README.Debian). I am however not sure that my current choices for the ppc64 and powerpc baselines are optimal, hence this thread. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Altivec in baseline for ppc64?
Hi, The wiki page that synthesizes architecture specificities indicates that Altivec is included in the baseline for the ppc64 port: https://wiki.debian.org/ArchitectureSpecificsMemo#ppc64 However my understanding is that this port supports any powerpc64 CPU, including some that don’t have Altivec (e.g. POWER4 or POWER5). This is also what the main wiki page for PPC64 says: https://wiki.debian.org/PPC64 Can someone please clarify the situation? (I’m asking because I’m the maintainer of the openblas package, and knowing whether Altivec is available or not, and more generally what is in the baseline, is essential for proper packaging). -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Re: Bug#954031: [Sbcl-devel] Bug#954031: sbcl: Please allow building with clisp on currently unsupported architectures
Le mercredi 01 avril 2020 à 16:56 +0200, John Paul Adrian Glaubitz a écrit : > On 4/1/20 4:51 PM, Sébastien Villemot wrote: > > > FWIW, sbcl builds fine for me on mipsel if clang is used as the C > > > compiler, > > > I'll file a separate bug report for that. > > > > I have mixed feelings about this. I am worried by the fact that those > > architectures are not really supported upstream. Hence, if by chance we > > manage to compile SBCL on one of those mostly-unsupported archs, I > > don’t know how we would be able to deal with regressions that could > > appear in the future, and that would block testing migration for > > supported archs. > > First of all, testing migration is only affected if: > > a) a package previously built fine on a certain architecture > b) the architecture in question is one of the release architectures > (this does not apply for alpha, hppa, ppc64, riscv64) > > So, the currently only candidate for this scenario is mipsel and I think this > is a risk that is bearable, in particular since upstream considers 32-bit mips > one of the supported architectures unlike alpha and hppa. There is also armel that you added recently (I don’t know how supported it is by upstream). > In the worst case, you will have to file a removal bugs for sbcl on mipsel > if upstream is really unwilling to fix the build issue on mipsel which I don't > think is the case. I have had a lot of interaction with Doug Kratzman from > sbcl upstream and he is usually very responsive. > > I will help with the package in any case. Note that several reverse build-dependencies of sbcl (e.g. pgloader) would have to be removed as well. In any case, thanks for your commitment to helping with portability. I’m going to apply the patch attached to the present bug in the next upload. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Re: Bug#954031: [Sbcl-devel] Bug#954031: sbcl: Please allow building with clisp on currently unsupported architectures
Hi, Le mercredi 01 avril 2020 à 16:43 +0200, John Paul Adrian Glaubitz a écrit : > On 3/16/20 1:16 AM, John Paul Adrian Glaubitz wrote: > > sbcl has partial support for alpha, hppa, mips*, ppc64 and riscv64 > > and if we try to build sbcl on any architecture using clisp, we will > > be able to provide upstream with a build log of sbcl on any architecture > > that might be supported in the future (like ppc64 and riscv64) or > > was previously supported and is currently broken (like alpha and hppa). > > > > The attached patch enables building with clisp on all unsupported > > architectures. > > Any chance we can get this implemented for the next upload? > > FWIW, sbcl builds fine for me on mipsel if clang is used as the C compiler, > I'll file a separate bug report for that. I have mixed feelings about this. I am worried by the fact that those architectures are not really supported upstream. Hence, if by chance we manage to compile SBCL on one of those mostly-unsupported archs, I don’t know how we would be able to deal with regressions that could appear in the future, and that would block testing migration for supported archs. What’s your view on this? Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
ATLAS on PowerPC
[please keep the bug in Cc:, I’m not subscribed to the list] Dear PowerPC porters, As a co-maintainer of atlas, I intend to force a specific PowerPC CPU architecture when the package is built on buildds (in order to fix #680096). Atlas gives me the following options: POWER3, POWER4, POWER5, POWER6, POWER7, PPCG4, PPCG5. I would like to know which one of these is the most generic architecture, so that the atlas package thus modified will work on all supported machines. I guess this is either POWER3 or PPCG4, but it is unclear to me which one is more generic. Or maybe none of the two encompasses the other, in which case I would like to know which one would be the best choice from your point of view. BTW, if you could answer the same question concerning the ppc64 and powerpcspe ports, that would be great. Thanks a lot, -- Sébastien Villemot Researcher in Economics Debian Maintainer http://www.dynare.org/sebastien Phone: +33-1-40-77-84-04 - GPG Key: 4096R/381A7594 pgpg6sfouilbT.pgp Description: PGP signature
Re: Bug#680096: ATLAS on PowerPC
brian m. carlson sand...@crustytoothpaste.net writes: POWER3 is 64-bit. But still POWER3 is supported by the 32-bit powerpc port: http://www.debian.org/releases/stable/powerpc/ch02s01.html.en#id522279 PPCG4 is 32-bit, but it requires the use of Altivec instructions, which G3 processors do not have. So the answer is that neither of these is acceptable by default. My understanding is that POWER3 does not have Altivec, so it may therefore be the best option. Is there a reason that you cannot use the defaults of the compiler? Yes, it has to do with the Atlas build system which does CPU detection and timings at compile time, and which is quite intricate (to say the least). -- Sébastien Villemot Researcher in Economics Debian Maintainer http://www.dynare.org/sebastien Phone: +33-1-40-77-84-04 - GPG Key: 4096R/381A7594 pgpODDG5YWQXl.pgp Description: PGP signature
Re: Bug#680096: ATLAS on PowerPC
Lennart Sorensen lsore...@csclub.uwaterloo.ca writes: On Wed, Jul 04, 2012 at 09:39:37PM +0200, Sébastien Villemot wrote: My understanding is that POWER3 does not have Altivec, so it may therefore be the best option. Unless of course it has other instructions that the G4 doesn't have. Looking again at Atlas build-system (in CONFIG/src/atlcomp.txt), it is clear that POWER3 is the less specific. In particular it gets no CPU-specific GCC flags, contrary to G4 (which gets -maltivec -mabi=altivec -mcpu=7400 -mtune=7400). So I am going to enforce POWER3. Thanks everyone for your feedback. -- Sébastien Villemot Researcher in Economics Debian Maintainer http://www.dynare.org/sebastien Phone: +33-1-40-77-84-04 - GPG Key: 4096R/381A7594 pgpcySfXSG73Z.pgp Description: PGP signature
