EV67 optimized libc6.1
[Please keep debian-glibc in Cc: as I am not subscribed to debian-alpha] Hi alpha users! As requested a long time ago in the BTS (bug #229251), I have built an EV67 optimized version of the glibc. It uses EV67 specific instructions, but also optimized assembly code for the following functions: ffs, memchr, memcpy, memset, sqrt, strcat, strchr, strcpy, strlen, strncat, strncpy and strrchr. As I don't own an alpha machine I am asking here for some tests. I am looking for people having a machine with an EV67 compatible CPU, but *also* people having a machine with an *older* CPU. - For people having an EV67 compatible CPU, please install libc6.1-alphaev67 and verify it is used. You can see that using ldd, for example: 'ldd /bin/ls'. It should uses libraries from /lib/ev67/ Some benchmarking would be really nice to decide if this package is really useful or not. - For people having an *older* CPU, I would like you to test that those libraries are not used, because I am not really sure about the hwcap code. It could be a bit risky, so it may be a good idea to do that in a chroot. Basically, install libc6.1-alphaev67. If your system still work it's a good sign. Then use ldd to verify those libraries are not used. Note that in case of problem a rm -rf /lib/ev67 should make your system working again. The packages are available on http://people.debian.org/~aurel32/ev67 Good tests! Cheers, Aurelien -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: EV67 optimized libc6.1
Hello Can we ust this glibc also on EV6 cpu or really only EV67 ? Manu Aurelien Jarno a écrit : [Please keep debian-glibc in Cc: as I am not subscribed to debian-alpha] Hi alpha users! As requested a long time ago in the BTS (bug #229251), I have built an EV67 optimized version of the glibc. It uses EV67 specific instructions, but also optimized assembly code for the following functions: ffs, memchr, memcpy, memset, sqrt, strcat, strchr, strcpy, strlen, strncat, strncpy and strrchr. As I don't own an alpha machine I am asking here for some tests. I am looking for people having a machine with an EV67 compatible CPU, but *also* people having a machine with an *older* CPU. - For people having an EV67 compatible CPU, please install libc6.1-alphaev67 and verify it is used. You can see that using ldd, for example: 'ldd /bin/ls'. It should uses libraries from /lib/ev67/ Some benchmarking would be really nice to decide if this package is really useful or not. - For people having an *older* CPU, I would like you to test that those libraries are not used, because I am not really sure about the hwcap code. It could be a bit risky, so it may be a good idea to do that in a chroot. Basically, install libc6.1-alphaev67. If your system still work it's a good sign. Then use ldd to verify those libraries are not used. Note that in case of problem a rm -rf /lib/ev67 should make your system working again. The packages are available on http://people.debian.org/~aurel32/ev67 Good tests! Cheers, Aurelien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: EV67 optimized libc6.1
Emmanuel Kasper wrote: Hello Can we ust this glibc also on EV6 cpu or really only EV67 ? This is only ev67. This is the mentioned architecture in the bug report. I know almost nothing about alpha CPUs, but it seems EV67 is the CPU for which the gain would be significant. Bye, Aurelien Aurelien Jarno a écrit : [Please keep debian-glibc in Cc: as I am not subscribed to debian-alpha] Hi alpha users! As requested a long time ago in the BTS (bug #229251), I have built an EV67 optimized version of the glibc. It uses EV67 specific instructions, but also optimized assembly code for the following functions: ffs, memchr, memcpy, memset, sqrt, strcat, strchr, strcpy, strlen, strncat, strncpy and strrchr. As I don't own an alpha machine I am asking here for some tests. I am looking for people having a machine with an EV67 compatible CPU, but *also* people having a machine with an *older* CPU. - For people having an EV67 compatible CPU, please install libc6.1-alphaev67 and verify it is used. You can see that using ldd, for example: 'ldd /bin/ls'. It should uses libraries from /lib/ev67/ Some benchmarking would be really nice to decide if this package is really useful or not. - For people having an *older* CPU, I would like you to test that those libraries are not used, because I am not really sure about the hwcap code. It could be a bit risky, so it may be a good idea to do that in a chroot. Basically, install libc6.1-alphaev67. If your system still work it's a good sign. Then use ldd to verify those libraries are not used. Note that in case of problem a rm -rf /lib/ev67 should make your system working again. The packages are available on http://people.debian.org/~aurel32/ev67 Good tests! Cheers, Aurelien -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: EV67 optimized libc6.1
Aurelien Jarno wrote: > This is only ev67. This is the mentioned architecture in the bug report. > I know almost nothing about alpha CPUs, but it seems EV67 is the CPU for which the gain would > be significant. Maybe. Maybe not. What is the nature of the changes you made? What EV67 specific features did you use and where? Did you just recompile with "-march=ev67"? If you are using native byte/word instructions in your changes, those are supported back into the EV56 family. What you might want to do is test for the CPU's capabilities (i.e. bwx support, mvi support, cix support) individually rather than a blanket "if ev67 (do a) else (do b)" Just a suggestion. Jeff D -- Jeff Donsbach https://ecardfile.com/id/jeff.donsbach
Re: EV67 optimized libc6.1
Aurelien Jarno <[EMAIL PROTECTED]> writes: > As requested a long time ago in the BTS (bug #229251), I have built > an EV67 optimized version of the glibc. It depends on "tzdata", which doesn't seem to be available anywhere (http://people.debian.org/~aurel32/tzdata/ is 404). -- Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: EV67 optimized libc6.1
On Tue, Apr 11, 2006 at 12:05:41PM -0400, Donsbach, Jeff wrote: > Aurelien Jarno wrote: > > This is only ev67. This is the mentioned architecture in the bug > report. > > I know almost nothing about alpha CPUs, but it seems EV67 is the CPU > for which the gain would > > be significant. > > Maybe. Maybe not. What is the nature of the changes you made? What EV67 > specific features did you use and where? Did you just recompile with > "-march=ev67"? The libraries are built with -march=ev67 -mtune=ev67, but also the target is alphaev67-linux-gnu, which means that optimized assembly code is used for some functions (the one listed in my first mail). > If you are using native byte/word instructions in your changes, those > are supported back into the EV56 family. I don't know exactly. But you can have a look to the corresponding assembly codes in the glibc sources, in sysdeps/alpha/alphaev67/ > What you might want to do is test for the CPU's capabilities (i.e. bwx > support, mvi support, cix support) individually rather than a blanket > "if ev67 (do a) else (do b)" > Well this is not possible, the kernel only returns the CPU class, from the following list: ev4, ev5, ev56, pca56, ev6, ev67. Bye, Aurelien -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: EV67 optimized libc6.1
On Tue, Apr 11, 2006 at 09:00:52PM +0200, Falk Hueffner wrote: > Aurelien Jarno <[EMAIL PROTECTED]> writes: > > > As requested a long time ago in the BTS (bug #229251), I have built > > an EV67 optimized version of the glibc. > > It depends on "tzdata", which doesn't seem to be available anywhere > (http://people.debian.org/~aurel32/tzdata/ is 404). > Oops, I removed it from there, because I uploaded it to unstable. And you have just tried to find it during the lap of time between its removal from incoming.d.o and its apparition on the mirrors. If you use an up to date mirror, you will be able to simply to apt-get install it, now or in the very next hours. Bye, Aurelien -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: EV67 optimized libc6.1
Aurelien, You wrote: > Jeff Donsbach wrote: > What you might want to do is test for the CPU's capabilities (i.e. bwx > support, mvi support, cix support) individually rather than a blanket > "if ev67 (do a) else (do b)" > >Well this is not possible, the kernel only returns the CPU class, from the following list: ev4, >ev5, ev56, pca56, ev6, ev67. It may be too granular from a kernel API, but fyi, you can detect which instruction set extensions the chip supports using the Alpha's AMASK instruction with an inline assembly instruction or two. See this document about the MVI extension (http://www.alphalinux.org/docs/MVI-full.html#DetectingMVI). It has listing of what the other bits mean too (BWX, CIX, SQRT, etc) I haven't looked at your code changes yet, but I'll do so when I get some free moments of spare time. Hope this helps, Jeff D -- Jeff Donsbach https://ecardfile.com/id/jeff.donsbach
Re: EV67 optimized libc6.1
On Tue, Apr 11, 2006 at 12:32:43PM +0200, Aurelien Jarno wrote: > As requested a long time ago in the BTS (bug #229251), I have built > an EV67 optimized version of the glibc. It uses EV67 specific > instructions, but also optimized assembly code for the following > functions: ffs, memchr, memcpy, memset, sqrt, strcat, strchr, strcpy, > strlen, strncat, strncpy and strrchr. > As I don't own an alpha machine I am asking here for some tests. I am > looking for people having a machine with an EV67 compatible CPU, but > *also* people having a machine with an *older* CPU. > - For people having an EV67 compatible CPU, please install > libc6.1-alphaev67 and verify it is used. You can see that using ldd, > for example: > 'ldd /bin/ls'. It should uses libraries from /lib/ev67/ > Some benchmarking would be really nice to decide if this package is > really useful or not. > - For people having an *older* CPU, I would like you to test that those > libraries are not used, because I am not really sure about the hwcap > code. It could be a bit risky, so it may be a good idea to do that in > a chroot. Basically, install libc6.1-alphaev67. If your system still > work it's a good sign. Then use ldd to verify those libraries are not > used. Note that in case of problem a rm -rf /lib/ev67 should make your > system working again. > The packages are available on http://people.debian.org/~aurel32/ev67 Tested in a chroot on an ev56 system, 2.6.15 kernel. No problems, it continues to use /lib correctly. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: EV67 optimized libc6.1
Aurelien Jarno <[EMAIL PROTECTED]> writes: > - For people having an EV67 compatible CPU, please install > libc6.1-alphaev67 and verify it is used. You can see that using ldd, > for example: > 'ldd /bin/ls'. It should uses libraries from /lib/ev67/ It's not being used: [EMAIL PROTECTED]:/# dpkg -l libc6.1\* | grep ii ii libc6.1 2.3.6-6+ev67 GNU C Library: Shared libraries ii libc6.1-alphaev67 2.3.6-6+ev67 GNU C Library: Shared libraries (EV67 optim [EMAIL PROTECTED]:/# ldd /bin/ls librt.so.1 => /lib/librt.so.1 (0x0202c000) libacl.so.1 => /lib/libacl.so.1 (0x02056000) libselinux.so.1 => /lib/libselinux.so.1 (0x0207) libc.so.6.1 => /lib/libc.so.6.1 (0x0209a000) libpthread.so.0 => /lib/libpthread.so.0 (0x02214000) /lib/ld-linux.so.2 (0x0200) libattr.so.1 => /lib/libattr.so.1 (0x022be000) libdl.so.2.1 => /lib/libdl.so.2.1 (0x022d4000) libsepol.so.1 => /lib/libsepol.so.1 (0x022ea000) I'm not sure why... The library as such works, though: [EMAIL PROTECTED]:/# LD_LIBRARY_PATH=/lib/ev67 ldd /bin/ls librt.so.1 => /lib/ev67/librt.so.1 (0x0202c000) libacl.so.1 => /lib/libacl.so.1 (0x02056000) libselinux.so.1 => /lib/libselinux.so.1 (0x0207) libc.so.6.1 => /lib/ev67/libc.so.6.1 (0x0209a000) libpthread.so.0 => /lib/ev67/libpthread.so.0 (0x02226000) /lib/ld-linux.so.2 (0x0200) libattr.so.1 => /lib/libattr.so.1 (0x022d) libdl.so.2.1 => /lib/ev67/libdl.so.2.1 (0x022e6000) libsepol.so.1 => /lib/libsepol.so.1 (0x022fc000) [EMAIL PROTECTED]:/# LD_LIBRARY_PATH=/lib/ev67 ls bin dev homelibmnt proc sbin srv tmp var boot etc initrd media opt root src sys usr -- Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
