[gentoo-amd64] x86_64 optimization patches for glibc.

[gentoo-amd64] x86_64 optimization patches for glibc.

[Simon Strandman]

Hi!

Some binary distros like Mandrake and suse patches their glibcs with 
x86_64 optimized strings and an x86_64 optimized libm to improve 
performance.

I tried extracting those patches from an mandrake SRPM and add them to 
the glibc 2.3.5 ebuild. The x86_64 optimized strings patch built and 
worked perfectly and gave a large speedup as you can see below. But I 
couldn't get glibc to build with the libm patch because of unresolved 
symbols (and I'm no programmer so I have no idea how to fix that).

I found a small C program on a suse mailing-list to measure glibc memory 
copy performance:
http://lists.suse.com/archive/suse-amd64/2005-Mar/0220.html

With the glibc 2.3.5 currently in gentoo I get:
isidor ~ # ./memcpy 2200 1000 1048576
Memory to memory copy rate = 1291.600098 MBytes / sec. Block size = 1048576.

But with glibc 2.3.5 + amd64 optimized strings I get:
isidor ~ # ./memcpy 2200 1000 1048576
Memory to memory copy rate = 2389.321777 MBytes / sec. Block size = 1048576.

That's an improvement of over 1000mb/s! Suse 9.3 also gives about 
2300mb/s out of the box.

How about adding these patches to gentoo? Perhaps in glibc 2.3.5-r1 
before it leaves package.mask? I'll create a bugreport about it if you 
agree!

This .tar.bz2 contains the glibc directory from my overlay with the 
mandrake patches included in files/mdk, but the libm patches are 
commented out in the ebuild.
http://snigel.no-ip.com/~nxsty/linux/glibc.tar.bz2

-- 
Simon Strandman <simon.strandman@telia.com>

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] x86_64 optimization patches for glibc.

[Allan Wang]

On Sat, 2005-07-23 at 16:48 +0200, Simon Strandman wrote:
> With the glibc 2.3.5 currently in gentoo I get:
> isidor ~ # ./memcpy 2200 1000 1048576
> Memory to memory copy rate = 1291.600098 MBytes / sec. Block size = 1048576.
> 
> But with glibc 2.3.5 + amd64 optimized strings I get:
> isidor ~ # ./memcpy 2200 1000 1048576
> Memory to memory copy rate = 2389.321777 MBytes / sec. Block size = 1048576.
> 
> That's an improvement of over 1000mb/s! Suse 9.3 also gives about 
> 2300mb/s out of the box.

Hmm, I don't see much difference here.

before:
allan@aw ~ $ ./a.out 2420 1000 1048576
Memory to memory copy rate = 1110.198486 MBytes / sec. Block size =
1048576.

after:
aw allan # ./a.out 2420 1000 1048576
Memory to memory copy rate = 1154.922974 MBytes / sec. Block size =
1048576.

Allan

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] x86_64 optimization patches for glibc.

[Sean Johnson]

I just reproduced your results. After emerging glibc with your overlay I get:

Memory to memory copy rate = 2265.193604 MBytes / sec. Block size = 1048576.

I was getting ~1100 before.

Nothing has broken yet, but if it does, I'll be sure to post. :)

On 7/23/05, Simon Strandman <simon.strandman@telia.com> wrote:
> Hi!
> 
> Some binary distros like Mandrake and suse patches their glibcs with
> x86_64 optimized strings and an x86_64 optimized libm to improve
> performance.
> 
> I tried extracting those patches from an mandrake SRPM and add them to
> the glibc 2.3.5 ebuild. The x86_64 optimized strings patch built and
> worked perfectly and gave a large speedup as you can see below. But I
> couldn't get glibc to build with the libm patch because of unresolved
> symbols (and I'm no programmer so I have no idea how to fix that).
> 
> I found a small C program on a suse mailing-list to measure glibc memory
> copy performance:
> http://lists.suse.com/archive/suse-amd64/2005-Mar/0220.html
> 
> With the glibc 2.3.5 currently in gentoo I get:
> isidor ~ # ./memcpy 2200 1000 1048576
> Memory to memory copy rate = 1291.600098 MBytes / sec. Block size = 1048576.
> 
> But with glibc 2.3.5 + amd64 optimized strings I get:
> isidor ~ # ./memcpy 2200 1000 1048576
> Memory to memory copy rate = 2389.321777 MBytes / sec. Block size = 1048576.
> 
> That's an improvement of over 1000mb/s! Suse 9.3 also gives about
> 2300mb/s out of the box.
> 
> How about adding these patches to gentoo? Perhaps in glibc 2.3.5-r1
> before it leaves package.mask? I'll create a bugreport about it if you
> agree!
> 
> This .tar.bz2 contains the glibc directory from my overlay with the
> mandrake patches included in files/mdk, but the libm patches are
> commented out in the ebuild.
> http://snigel.no-ip.com/~nxsty/linux/glibc.tar.bz2
> 
> --
> Simon Strandman <simon.strandman@telia.com>
> 
> --
> gentoo-amd64@gentoo.org mailing list
> 
>

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] x86_64 optimization patches for glibc.

[Simon Strandman]

Allan Wang skrev:

>
>Hmm, I don't see much difference here.
>
>before:
>allan@aw ~ $ ./a.out 2420 1000 1048576
>Memory to memory copy rate = 1110.198486 MBytes / sec. Block size =
>1048576.
>
>after:
>aw allan # ./a.out 2420 1000 1048576
>Memory to memory copy rate = 1154.922974 MBytes / sec. Block size =
>1048576.
>
>Allan
>
>  
>
What kind och system do you have?

These are my spec:
AMD64 3500+ Winchester 2,2ghz
Asus A8N-SLI Deluxe (nforce4)
1024mb DDR dual channel

And emerge info:
isidor ~ # emerge info
Portage 2.0.51.22-r2 (default-linux/amd64/2005.0, gcc-3.4.4, 
glibc-2.3.5-r0, 2.6.12-ck3-r1 x86_64)
=================================================================
System uname: 2.6.12-ck3-r1 x86_64 AMD Athlon(tm) 64 Processor 3500+
Gentoo Base System version 1.6.13
dev-lang/python:     2.3.5
sys-apps/sandbox:    1.2.11
sys-devel/autoconf:  2.13, 2.59-r6
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5
sys-devel/binutils:  2.16.1, 2.16.91.0.1
sys-devel/libtool:   1.5.18-r1
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="amd64"
AUTOCLEAN="yes"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -march=athlon64 -fomit-frame-pointer -pipe -fno-ident"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config 
/usr/lib/X11/xkb /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -march=athlon64 -fomit-frame-pointer -pipe -fno-ident 
-fvisibility-inlines-hidden -fno-enforce-eh-specs"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks sandbox sfperms strict"
GENTOO_MIRRORS="http://snigel.no-ip.com/ http://mirror.pudas.net/gentoo 
ftp://ftp.rhnet.is/pub/gentoo/ 
ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror/ 
http://ftp.rhnet.is/pub/gentoo/"
LANG="sv_SE.UTF-8"
LC_ALL="sv_SE.UTF-8"
LDFLAGS="-Wl,-O1"
LINGUAS="sv"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="amd64 X aalib alsa artswrappersuid avi berkdb caps cdr crypt dga 
dlloader dvd dvdr dvdread encode f77 fbcon foomaticdb fortran gcj gif 
glibc-omitfp gnome gphoto2 gpm gtk gtk2 hal imlib ipv6 ithreads 
jack-tmpfs java javascript jpeg kdeenablefinal logitech-mouse lzw 
lzw-tiff mad mikmod mng mozilla mp3 mpeg ncurses nls nomalloccheck nptl 
nptlonly nvidia objc offensive oggvorbis opengl pdflib perl pic png pnp 
python qt quicktime readline samba sdl spell ssl svg tcpd threadstiff 
truetype truetype-fonts type1-fonts unicode usb userlocales 
visualization xine xml2 xmms xpm xv xvid zlib video_cards_nvidia 
linguas_sv userland_GNU kernel_linux elibc_glibc"
Unset:  ASFLAGS, CTARGET

-- 
Simon Strandman <simon.strandman@telia.com>

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] x86_64 optimization patches for glibc.

[Allan Wang]

On Sat, 2005-07-23 at 19:08 +0200, Simon Strandman wrote:
> Allan Wang skrev:
> 
> >
> >Hmm, I don't see much difference here.
> >
> >before:
> >allan@aw ~ $ ./a.out 2420 1000 1048576
> >Memory to memory copy rate = 1110.198486 MBytes / sec. Block size =
> >1048576.
> >
> >after:
> >aw allan # ./a.out 2420 1000 1048576
> >Memory to memory copy rate = 1154.922974 MBytes / sec. Block size =
> >1048576.
> >
> >Allan
> >
> >  
> >
> What kind och system do you have?
> 
Athlon64 3200+ Newcastle (overclocked to 2.4ghz)
2x corsair valueselect ram, running at 360mhz
dfi lanparty 250gb nforce3 ultra

My emerge --info:
Portage 2.0.51.22-r2 (default-linux/amd64/2005.0, gcc-3.4.4,
glibc-2.3.5-r0, 2.6.12-nitro5 x86_64)
=================================================================
System uname: 2.6.12-nitro5 x86_64 AMD Athlon(tm) 64 Processor 3200+
Gentoo Base System version 1.6.13
ccache version 2.4 [enabled]
dev-lang/python:     2.3.5, 2.4.1-r1
sys-apps/sandbox:    1.2.11
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6
sys-devel/binutils:  2.16.1
sys-devel/libtool:   1.5.18-r1
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="amd64 ~amd64"
AUTOCLEAN="yes"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=athlon64 -O3 -pipe -ffast-math"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib64/mozilla/defaults/pref /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/splash /etc/terminfo /etc/env.d"
CXXFLAGS="-march=athlon64 -O3 -pipe -ffast-math"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs autoconfig ccache distlocks prelink sandbox sfperms
strict"
GENTOO_MIRRORS="http://gentoo.mirrors.tds.net/gentoo
http://gentoo.ccccom.com http://gentoo.osuosl.org"
LANG="en_US.UTF-8"
LC_ALL="en_US.UTF-8"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage /usr/local/portage-mafteah"
SYNC="rsync://rsync6.us.gentoo.org/gentoo-portage/"
USE="amd64 X aalib alsa apache2 avi bash-completion bitmap-fonts bmp
bzip2 cairo cdb cdr crypt cups curl curlwrappers dba dvd dvdr dvdread
eds encode ffmpeg firefox flac foomaticdb gd gdbm gif gnome gpm
gstreamer gtk gtk2 hal howl imagemagick imlib innodb java jikes jpeg jpg
kde kdeenablefinal kernel_linux lzw lzw-tiff mad matroska memlimit
mikmod motif mozilla mp3 mpeg mpeg4 ncurses nls nptl nptlonly offensive
ogg oggvorbis openal opengl oss pam pcre pdflib perl php pic png
postgres python qt quicktime readline real ruby samba sdl session
sharedmem sockets spell sqlite ssl subversion svg tcpd theora tiff
truetype truetype-fonts type1-fonts unicode usb userlocales vhosts
vorbis xine xinerama xml xml2 xpm xv zlib"
Unset:  ASFLAGS, CTARGET, LDFLAGS, LINGUAS


Allan

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] x86_64 optimization patches for glibc.

[Jared Lindsay]

Wow, I did the same thing and got almost 1000MB higher :)

*emerges things*

On 7/23/05, Allan Wang <allanvv@gmail.com> wrote:
> On Sat, 2005-07-23 at 19:08 +0200, Simon Strandman wrote:
> > Allan Wang skrev:
> >
> > >
> > >Hmm, I don't see much difference here.
> > >
> > >before:
> > >allan@aw ~ $ ./a.out 2420 1000 1048576
> > >Memory to memory copy rate = 1110.198486 MBytes / sec. Block size =
> > >1048576.
> > >
> > >after:
> > >aw allan # ./a.out 2420 1000 1048576
> > >Memory to memory copy rate = 1154.922974 MBytes / sec. Block size =
> > >1048576.
> > >
> > >Allan
> > >
> > >
> > >
> > What kind och system do you have?
> >
> Athlon64 3200+ Newcastle (overclocked to 2.4ghz)
> 2x corsair valueselect ram, running at 360mhz
> dfi lanparty 250gb nforce3 ultra
> 
> My emerge --info:
> Portage 2.0.51.22-r2 (default-linux/amd64/2005.0, gcc-3.4.4,
> glibc-2.3.5-r0, 2.6.12-nitro5 x86_64)
> =================================================================
> System uname: 2.6.12-nitro5 x86_64 AMD Athlon(tm) 64 Processor 3200+
> Gentoo Base System version 1.6.13
> ccache version 2.4 [enabled]
> dev-lang/python:     2.3.5, 2.4.1-r1
> sys-apps/sandbox:    1.2.11
> sys-devel/autoconf:  2.13, 2.59-r7
> sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6
> sys-devel/binutils:  2.16.1
> sys-devel/libtool:   1.5.18-r1
> virtual/os-headers:  2.6.11-r2
> ACCEPT_KEYWORDS="amd64 ~amd64"
> AUTOCLEAN="yes"
> CBUILD="x86_64-pc-linux-gnu"
> CFLAGS="-march=athlon64 -O3 -pipe -ffast-math"
> CHOST="x86_64-pc-linux-gnu"
> CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib64/mozilla/defaults/pref /usr/share/config /var/qmail/control"
> CONFIG_PROTECT_MASK="/etc/gconf /etc/splash /etc/terminfo /etc/env.d"
> CXXFLAGS="-march=athlon64 -O3 -pipe -ffast-math"
> DISTDIR="/usr/portage/distfiles"
> FEATURES="autoaddcvs autoconfig ccache distlocks prelink sandbox sfperms
> strict"
> GENTOO_MIRRORS="http://gentoo.mirrors.tds.net/gentoo
> http://gentoo.ccccom.com http://gentoo.osuosl.org"
> LANG="en_US.UTF-8"
> LC_ALL="en_US.UTF-8"
> MAKEOPTS="-j2"
> PKGDIR="/usr/portage/packages"
> PORTAGE_TMPDIR="/var/tmp"
> PORTDIR="/usr/portage"
> PORTDIR_OVERLAY="/usr/local/portage /usr/local/portage-mafteah"
> SYNC="rsync://rsync6.us.gentoo.org/gentoo-portage/"
> USE="amd64 X aalib alsa apache2 avi bash-completion bitmap-fonts bmp
> bzip2 cairo cdb cdr crypt cups curl curlwrappers dba dvd dvdr dvdread
> eds encode ffmpeg firefox flac foomaticdb gd gdbm gif gnome gpm
> gstreamer gtk gtk2 hal howl imagemagick imlib innodb java jikes jpeg jpg
> kde kdeenablefinal kernel_linux lzw lzw-tiff mad matroska memlimit
> mikmod motif mozilla mp3 mpeg mpeg4 ncurses nls nptl nptlonly offensive
> ogg oggvorbis openal opengl oss pam pcre pdflib perl php pic png
> postgres python qt quicktime readline real ruby samba sdl session
> sharedmem sockets spell sqlite ssl subversion svg tcpd theora tiff
> truetype truetype-fonts type1-fonts unicode usb userlocales vhosts
> vorbis xine xinerama xml xml2 xpm xv zlib"
> Unset:  ASFLAGS, CTARGET, LDFLAGS, LINGUAS
> 
> 
> Allan
> 
> --
> gentoo-amd64@gentoo.org mailing list
> 
>

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] x86_64 optimization patches for glibc.

[Allan Wang]

Perhaps it's because I'm using the pic use flag.. I'll try removing it
and see if it helps any. The patch is being applied, I just opened up
memcpy.S and the AMD stuff is there.

Allan

On Sat, 2005-07-23 at 11:11 -0700, Jared Lindsay wrote:
> Wow, I did the same thing and got almost 1000MB higher :)
> 
> *emerges things*
> 
> On 7/23/05, Allan Wang <allanvv@gmail.com> wrote:
> > On Sat, 2005-07-23 at 19:08 +0200, Simon Strandman wrote:
> > > Allan Wang skrev:
> > >
> > > >
> > > >Hmm, I don't see much difference here.
> > > >
> > > >before:
> > > >allan@aw ~ $ ./a.out 2420 1000 1048576
> > > >Memory to memory copy rate = 1110.198486 MBytes / sec. Block size =
> > > >1048576.
> > > >
> > > >after:
> > > >aw allan # ./a.out 2420 1000 1048576
> > > >Memory to memory copy rate = 1154.922974 MBytes / sec. Block size =
> > > >1048576.
> > > >
> > > >Allan
> > > >
> > > >
> > > >
> > > What kind och system do you have?
> > >
> > Athlon64 3200+ Newcastle (overclocked to 2.4ghz)
> > 2x corsair valueselect ram, running at 360mhz
> > dfi lanparty 250gb nforce3 ultra
> > 
> > My emerge --info:
> > Portage 2.0.51.22-r2 (default-linux/amd64/2005.0, gcc-3.4.4,
> > glibc-2.3.5-r0, 2.6.12-nitro5 x86_64)
> > =================================================================
> > System uname: 2.6.12-nitro5 x86_64 AMD Athlon(tm) 64 Processor 3200+
> > Gentoo Base System version 1.6.13
> > ccache version 2.4 [enabled]
> > dev-lang/python:     2.3.5, 2.4.1-r1
> > sys-apps/sandbox:    1.2.11
> > sys-devel/autoconf:  2.13, 2.59-r7
> > sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6
> > sys-devel/binutils:  2.16.1
> > sys-devel/libtool:   1.5.18-r1
> > virtual/os-headers:  2.6.11-r2
> > ACCEPT_KEYWORDS="amd64 ~amd64"
> > AUTOCLEAN="yes"
> > CBUILD="x86_64-pc-linux-gnu"
> > CFLAGS="-march=athlon64 -O3 -pipe -ffast-math"
> > CHOST="x86_64-pc-linux-gnu"
> > CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib64/mozilla/defaults/pref /usr/share/config /var/qmail/control"
> > CONFIG_PROTECT_MASK="/etc/gconf /etc/splash /etc/terminfo /etc/env.d"
> > CXXFLAGS="-march=athlon64 -O3 -pipe -ffast-math"
> > DISTDIR="/usr/portage/distfiles"
> > FEATURES="autoaddcvs autoconfig ccache distlocks prelink sandbox sfperms
> > strict"
> > GENTOO_MIRRORS="http://gentoo.mirrors.tds.net/gentoo
> > http://gentoo.ccccom.com http://gentoo.osuosl.org"
> > LANG="en_US.UTF-8"
> > LC_ALL="en_US.UTF-8"
> > MAKEOPTS="-j2"
> > PKGDIR="/usr/portage/packages"
> > PORTAGE_TMPDIR="/var/tmp"
> > PORTDIR="/usr/portage"
> > PORTDIR_OVERLAY="/usr/local/portage /usr/local/portage-mafteah"
> > SYNC="rsync://rsync6.us.gentoo.org/gentoo-portage/"
> > USE="amd64 X aalib alsa apache2 avi bash-completion bitmap-fonts bmp
> > bzip2 cairo cdb cdr crypt cups curl curlwrappers dba dvd dvdr dvdread
> > eds encode ffmpeg firefox flac foomaticdb gd gdbm gif gnome gpm
> > gstreamer gtk gtk2 hal howl imagemagick imlib innodb java jikes jpeg jpg
> > kde kdeenablefinal kernel_linux lzw lzw-tiff mad matroska memlimit
> > mikmod motif mozilla mp3 mpeg mpeg4 ncurses nls nptl nptlonly offensive
> > ogg oggvorbis openal opengl oss pam pcre pdflib perl php pic png
> > postgres python qt quicktime readline real ruby samba sdl session
> > sharedmem sockets spell sqlite ssl subversion svg tcpd theora tiff
> > truetype truetype-fonts type1-fonts unicode usb userlocales vhosts
> > vorbis xine xinerama xml xml2 xpm xv zlib"
> > Unset:  ASFLAGS, CTARGET, LDFLAGS, LINGUAS
> > 
> > 
> > Allan
> > 
> > --
> > gentoo-amd64@gentoo.org mailing list
> > 
> >
> 

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] x86_64 optimization patches for glibc.

[Brian Litzinger]

> On Sat, 2005-07-23 at 16:48 +0200, Simon Strandman wrote:
> > With the glibc 2.3.5 currently in gentoo I get:
> > isidor ~ # ./memcpy 2200 1000 1048576
> > Memory to memory copy rate = 1291.600098 MBytes / sec. Block size = 1048576.
> > 
> > But with glibc 2.3.5 + amd64 optimized strings I get:
> > isidor ~ # ./memcpy 2200 1000 1048576
> > Memory to memory copy rate = 2389.321777 MBytes / sec. Block size = 1048576.
> > 
> > That's an improvement of over 1000mb/s! Suse 9.3 also gives about 
> > 2300mb/s out of the box.

pre:
./memcpy 2000 1000 1048576
Memory to memory copy rate = 1302.701782 MBytes / sec. Block size = 1048576.

post:
./memcpy 2000 1000 1048576
Memory to memory copy rate = 2051.979980 MBytes / sec. Block size = 1048576.

AMD64 3200+ 2.0GHz
1024MB PC2700
Compaq R3240US
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] x86_64 optimization patches for glibc.

[Matt Randolph]

Simon Strandman wrote:

> Hi!
>
> Some binary distros like Mandrake and suse patches their glibcs with 
> x86_64 optimized strings and an x86_64 optimized libm to improve 
> performance.
>
> I tried extracting those patches from an mandrake SRPM and add them to 
> the glibc 2.3.5 ebuild. The x86_64 optimized strings patch built and 
> worked perfectly and gave a large speedup as you can see below. But I 
> couldn't get glibc to build with the libm patch because of unresolved 
> symbols (and I'm no programmer so I have no idea how to fix that).
>
> I found a small C program on a suse mailing-list to measure glibc 
> memory copy performance:
> http://lists.suse.com/archive/suse-amd64/2005-Mar/0220.html
>
> With the glibc 2.3.5 currently in gentoo I get:
> isidor ~ # ./memcpy 2200 1000 1048576
> Memory to memory copy rate = 1291.600098 MBytes / sec. Block size = 
> 1048576.
>
> But with glibc 2.3.5 + amd64 optimized strings I get:
> isidor ~ # ./memcpy 2200 1000 1048576
> Memory to memory copy rate = 2389.321777 MBytes / sec. Block size = 
> 1048576.
>
> That's an improvement of over 1000mb/s! Suse 9.3 also gives about 
> 2300mb/s out of the box.
>
> How about adding these patches to gentoo? Perhaps in glibc 2.3.5-r1 
> before it leaves package.mask? I'll create a bugreport about it if you 
> agree!
>
> This .tar.bz2 contains the glibc directory from my overlay with the 
> mandrake patches included in files/mdk, but the libm patches are 
> commented out in the ebuild.
> http://snigel.no-ip.com/~nxsty/linux/glibc.tar.bz2
>
There is a bug in the original memcpy.c that will cause a segfault if 
you don't pass it any parameters.  Here is a fixed version.  I've left 
everything else alone (except for a spelling correction).

// memcpy.c - Measure how fast we can copy memory

#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <string.h>

/* timing function */
#define rdtscll(val) do { \
     unsigned int a,d; \
     asm volatile("rdtsc" : "=a" (a), "=d" (d)); \
     (val) = ((unsigned long)a) | (((unsigned long)d)<<32); \
} while(0)

int main(int argc, char *argv[]) {
  int cpu_rate, num_loops, block_size, block_size_lwords, i, j;
  unsigned char *send_block_p, *rcv_block_p;
  unsigned long start_time, end_time;
  float rate;
  unsigned long *s_p, *r_p;

  if (argc != 4) {
    fprintf(stderr,
      "Usage: %s <cpu clk rate (MHz)> <num. iterations> <copy block 
size>\n",
           argv[0] );
    return 1;
  }

  cpu_rate = atoi(argv[1]);
  num_loops = atoi(argv[2]);
  block_size = atoi(argv[3]);

  block_size_lwords = block_size / sizeof(unsigned long);
  block_size = sizeof(unsigned long) * block_size_lwords;

  send_block_p = malloc(block_size);
  rcv_block_p = malloc(block_size);

  if ((send_block_p == NULL) || (rcv_block_p == NULL)) {
    fprintf(stderr, "Malloc failed to allocate block(s) of size %d.\n",
            block_size);
  }

// start_time = clock();
    rdtscll(start_time);

  for (i = 0; i < num_loops; i++) {
    memcpy(rcv_block_p, send_block_p, block_size);

// s_p = (unsigned long *) send_block_p;
// r_p = (unsigned long *) rcv_block_p;
//
// for (j = 0 ; j < block_size_lwords; j++) {
// *(r_p++) = *(s_p++);
// }
  }

// end_time = clock();
    rdtscll(end_time);

  rate = (float) (block_size) * (float) (num_loops) /
         ((float) (end_time - start_time)) *
         ((float) cpu_rate) * 1.0E6 / 1.0E6;

  fprintf(stdout,
    "Memory to memory copy rate = %f MBytes / sec. Block size = %d.\n",
    rate, block_size);

} /* end main() */


-- 
"Pluralitas non est ponenda sine necessitate" - W. of O.

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] x86_64 optimization patches for glibc.

[Matt Randolph]

Oh, and I take no responsibility for any damages to anyone or anything 
arising from the use of the revised memcpy.c or software produced from 
it.  It may contain further errors that I don't know about.

Matt Randolph wrote:

> There is a bug in the original memcpy.c that will cause a segfault if 
> you don't pass it any parameters.  Here is a fixed version.  I've left 
> everything else alone (except for a spelling correction).



-- 
"Pluralitas non est ponenda sine necessitate" - W. of O.

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] x86_64 optimization patches for glibc.

[Sean Johnson]

LOL! 

That must be for the folk that don't mind patching glibc, but will get
upset if memcpy does strange things. :)

On 7/23/05, Matt Randolph <mattr@erols.com> wrote:
> Oh, and I take no responsibility for any damages to anyone or anything
> arising from the use of the revised memcpy.c or software produced from
> it.  It may contain further errors that I don't know about.
> 
> Matt Randolph wrote:
> 
> > There is a bug in the original memcpy.c that will cause a segfault if
> > you don't pass it any parameters.  Here is a fixed version.  I've left
> > everything else alone (except for a spelling correction).
> 
> 
> 
> --
> "Pluralitas non est ponenda sine necessitate" - W. of O.
> 
> --
> gentoo-amd64@gentoo.org mailing list
> 
>

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] x86_64 optimization patches for glibc.

[Matt Randolph]

Sean Johnson wrote:

>LOL! 
>
>That must be for the folk that don't mind patching glibc, but will get
>upset if memcpy does strange things. :)
>  
>

You try to do a good turn and they laugh at you.  That'll teach me.

-- 
"Pluralitas non est ponenda sine necessitate" - W. of O.

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] x86_64 optimization patches for glibc.

[Ian McCulloch]

On Sat, 23 Jul 2005, Matt Randolph wrote:

> Sean Johnson wrote:
> 
> > LOL! 
> > That must be for the folk that don't mind patching glibc, but will get
> > upset if memcpy does strange things. :)
> > 
> > 
> 
> You try to do a good turn and they laugh at you.  That'll teach me.

Heh ;-)  I would like to see a version of memcpy.c that DOES do something 
malicious, without being completely obvious.  This isn't Windows, a 
seg-fault isn't going to take down the kernel, or corrupt the filesystem;)

Cheers
Ian
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] x86_64 optimization patches for glibc.

[Jared Lindsay]

Back on to a different subject...has anyone looked at the libm
section?  I am curious as to how much of a performance increase that
would add if we can get it working.

On 7/23/05, Ian McCulloch <ianmcc@physik.rwth-aachen.de> wrote:
> 
> 
> On Sat, 23 Jul 2005, Matt Randolph wrote:
> 
> > Sean Johnson wrote:
> >
> > > LOL!
> > > That must be for the folk that don't mind patching glibc, but will get
> > > upset if memcpy does strange things. :)
> > >
> > >
> >
> > You try to do a good turn and they laugh at you.  That'll teach me.
> 
> Heh ;-)  I would like to see a version of memcpy.c that DOES do something
> malicious, without being completely obvious.  This isn't Windows, a
> seg-fault isn't going to take down the kernel, or corrupt the filesystem;)
> 
> Cheers
> Ian
> --
> gentoo-amd64@gentoo.org mailing list
> 
>

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] x86_64 optimization patches for glibc.

[Simon Strandman]

Jared Lindsay skrev:

>Back on to a different subject...has anyone looked at the libm
>section?  I am curious as to how much of a performance increase that
>would add if we can get it working.
>
>  
>

Getting it to work seems easier said than done. :( Has anyone else tried 
compiling it? For me it always fails to build. I've tried upgrading 
binutils to 2.16.91.0.1 (same version as mdk cooker), building without 
the gentoo patches, building without omitfp, enabling as-needed, 
building without various configure options, using the libm patch from 
suse instead of mandrake and with higher or lower optimizations. It 
didn't even work when I manually unpacked and compiled glibc with only 
the libm patches and configure options --prefix=/usr/ 
--enable-add-ons=nptl. Checking out the latest glibc from the 2.3 stable 
branch via cvs and adding the patches to that didn't work either. I'm 
running out of ideas now!

Here is the error it fails with:

x86_64-pc-linux-gnu-gcc -Wl,-O1  -nostdlib -nostartfiles -r -o 
/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/libc_pic.os 
\
 -Wl,-d -Wl,--whole-archive 
/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/libc_pic.a
x86_64-pc-linux-gnu-gcc -Wl,-O1  -shared -Wl,-O1 \
  -nostdlib -nostartfiles \
   -Wl,-dynamic-linker=/lib64/ld-linux-x86-64.so.2 -Wl,-z,relro \
  -Wl,--verbose 2>&1 | \
  sed > 
/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/shlib.ldsT 
\
      -e '/^=========/,/^=========/!d;/^=========/d' \
      -e 's/^.*\.hash[  ]*:.*$/  .note.ABI-tag : { *(.note.ABI-tag) } &/' \
      -e 's/^.*\*(\.dynbss).*$/& \
         PROVIDE(__start___libc_freeres_ptrs = .); \
         *(__libc_freeres_ptrs) \
         PROVIDE(__stop___libc_freeres_ptrs = .);/'\
      -e 's/^.*\*(\.jcr).*$/& \
         PROVIDE(__start___libc_subfreeres = .);\
         __libc_subfreeres : { *(__libc_subfreeres) }\
         PROVIDE(__stop___libc_subfreeres = .);\
         PROVIDE(__start___libc_atexit = .);\
         __libc_atexit : { *(__libc_atexit) }\
         PROVIDE(__stop___libc_atexit = .);\
         PROVIDE(__start___libc_thread_subfreeres = .);\
         __libc_thread_subfreeres : { *(__libc_thread_subfreeres) }\
         PROVIDE(__stop___libc_thread_subfreeres = .);/'
mv -f 
/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/shlib.ldsT 
/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/shlib.lds
x86_64-pc-linux-gnu-gcc -Wl,-O1  -shared -static-libgcc -Wl,-O1  
-Wl,-z,defs -Wl,-dynamic-linker=/lib64/ld-linux-x86-64.so.2  
-B/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/csu/  

-Wl,--version-script=/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/libc.map 
-Wl,-soname=libc.so.6 -Wl,-z,relro -nostdlib -nostartfiles -e 
__libc_main -Wl,-z,now
-L/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl 
-L/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/math 

-L/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/elf 
-L/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/dlfcn 

-L/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/nss 
-L/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/nis 

-L/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/rt 
-L/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/resolv 

-L/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/crypt 
-L/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/nptl 

-Wl,-rpath-link=/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl:/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/math:/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/elf:/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/dlfcn:/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/nss:/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/nis:/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/rt:/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/resolv:/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/crypt:/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/nptl 

-o 
/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/libc.so 
-T 
/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/shlib.lds 

/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/csu/abi-note.o 
/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/elf/soinit.os 

/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/libc_pic.os 
/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/elf/sofini.os 

/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/elf/interp.os 
/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/elf/ld.so 
-lgcc
/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/libc_pic.os: 
In function `scalbn':
: undefined reference to `__copysign'
/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/libc_pic.os: 
In function `__scalbnf':
: undefined reference to `__copysignf'
/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/libc_pic.os: 
In function `__scalbnf':
: undefined reference to `__copysignf'
collect2: ld returned 1 exit status
make[1]: *** 
[/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/libc.so] 
Error 1
make[1]: Leaving directory `/var/tmp/portage/glibc-2.3.5/work/glibc-2.3.5'
make: *** [all] Error 2

I've looked through some of the other mandrake and suse patches but the 
only patch mandrake has that contains the word "copysign" is the gcc4 
patch. Using it makes the error slightly different but it still happens 
at the same place:

/usr/portage/distfiles/glibc.build/libc_pic.os: In function `__scalbn':
../sysdeps/ieee754/dbl-64/s_scalbn.c:61: undefined reference to `__copysign'
/usr/portage/distfiles/glibc.build/libc_pic.os: In function `__scalbnf':
../sysdeps/ieee754/flt-32/s_scalbnf.c:52: undefined reference to 
`__copysignf'
../sysdeps/ieee754/flt-32/s_scalbnf.c:58: undefined reference to 
`__copysignf'
collect2: ld returned 1 exit status


-- 
Simon Strandman <simon.strandman@telia.com>

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] x86_64 optimization patches for glibc.

[Jared Lindsay]

Well, I tried compiling the libm patch with the new version
(2.3.5-r1), but got the same error.  And I think I would get the same
error if I went through what you did...o.O

Guess it is a lost cause, for now :(

On 7/24/05, Simon Strandman <simon.strandman@telia.com> wrote:
> Jared Lindsay skrev:
> 
> >Back on to a different subject...has anyone looked at the libm
> >section?  I am curious as to how much of a performance increase that
> >would add if we can get it working.
> >
> >
> >
> 
> Getting it to work seems easier said than done. :( Has anyone else tried
> compiling it? For me it always fails to build. I've tried upgrading
> binutils to 2.16.91.0.1 (same version as mdk cooker), building without
> the gentoo patches, building without omitfp, enabling as-needed,
> building without various configure options, using the libm patch from
> suse instead of mandrake and with higher or lower optimizations. It
> didn't even work when I manually unpacked and compiled glibc with only
> the libm patches and configure options --prefix=/usr/
> --enable-add-ons=nptl. Checking out the latest glibc from the 2.3 stable
> branch via cvs and adding the patches to that didn't work either. I'm
> running out of ideas now!
> 
> Here is the error it fails with:
> 
> x86_64-pc-linux-gnu-gcc -Wl,-O1  -nostdlib -nostartfiles -r -o
> /var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/libc_pic.os
> \
>  -Wl,-d -Wl,--whole-archive
> /var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/libc_pic.a
> x86_64-pc-linux-gnu-gcc -Wl,-O1  -shared -Wl,-O1 \
>   -nostdlib -nostartfiles \
>    -Wl,-dynamic-linker=/lib64/ld-linux-x86-64.so.2 -Wl,-z,relro \
>   -Wl,--verbose 2>&1 | \
>   sed >
> /var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/shlib.ldsT
> \
>       -e '/^=========/,/^=========/!d;/^=========/d' \
>       -e 's/^.*\.hash[  ]*:.*$/  .note.ABI-tag : { *(.note.ABI-tag) } &/' \
>       -e 's/^.*\*(\.dynbss).*$/& \
>          PROVIDE(__start___libc_freeres_ptrs = .); \
>          *(__libc_freeres_ptrs) \
>          PROVIDE(__stop___libc_freeres_ptrs = .);/'\
>       -e 's/^.*\*(\.jcr).*$/& \
>          PROVIDE(__start___libc_subfreeres = .);\
>          __libc_subfreeres : { *(__libc_subfreeres) }\
>          PROVIDE(__stop___libc_subfreeres = .);\
>          PROVIDE(__start___libc_atexit = .);\
>          __libc_atexit : { *(__libc_atexit) }\
>          PROVIDE(__stop___libc_atexit = .);\
>          PROVIDE(__start___libc_thread_subfreeres = .);\
>          __libc_thread_subfreeres : { *(__libc_thread_subfreeres) }\
>          PROVIDE(__stop___libc_thread_subfreeres = .);/'
> mv -f
> /var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/shlib.ldsT
> /var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/shlib.lds
> x86_64-pc-linux-gnu-gcc -Wl,-O1  -shared -static-libgcc -Wl,-O1
> -Wl,-z,defs -Wl,-dynamic-linker=/lib64/ld-linux-x86-64.so.2
> -B/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/csu/
> 
> -Wl,--version-script=/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/libc.map
> -Wl,-soname=libc.so.6 -Wl,-z,relro -nostdlib -nostartfiles -e
> __libc_main -Wl,-z,now
> -L/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl
> -L/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/math
> 
> -L/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/elf
> -L/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/dlfcn
> 
> -L/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/nss
> -L/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/nis
> 
> -L/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/rt
> -L/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/resolv
> 
> -L/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/crypt
> -L/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/nptl
> 
> -Wl,-rpath-link=/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl:/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/math:/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/elf:/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/dlfcn:/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/nss:/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/nis:/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/rt:/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/resolv:/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/crypt:/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/nptl
> 
> -o
> /var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/libc.so
> -T
> /var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/shlib.lds
> 
> /var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/csu/abi-note.o
> /var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/elf/soinit.os
> 
> /var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/libc_pic.os
> /var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/elf/sofini.os
> 
> /var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/elf/interp.os
> /var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/elf/ld.so
> -lgcc
> /var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/libc_pic.os:
> In function `scalbn':
> : undefined reference to `__copysign'
> /var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/libc_pic.os:
> In function `__scalbnf':
> : undefined reference to `__copysignf'
> /var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/libc_pic.os:
> In function `__scalbnf':
> : undefined reference to `__copysignf'
> collect2: ld returned 1 exit status
> make[1]: ***
> [/var/tmp/portage/glibc-2.3.5/work/build-amd64-x86_64-pc-linux-gnu-nptl/libc.so]
> Error 1
> make[1]: Leaving directory `/var/tmp/portage/glibc-2.3.5/work/glibc-2.3.5'
> make: *** [all] Error 2
> 
> I've looked through some of the other mandrake and suse patches but the
> only patch mandrake has that contains the word "copysign" is the gcc4
> patch. Using it makes the error slightly different but it still happens
> at the same place:
> 
> /usr/portage/distfiles/glibc.build/libc_pic.os: In function `__scalbn':
> ../sysdeps/ieee754/dbl-64/s_scalbn.c:61: undefined reference to `__copysign'
> /usr/portage/distfiles/glibc.build/libc_pic.os: In function `__scalbnf':
> ../sysdeps/ieee754/flt-32/s_scalbnf.c:52: undefined reference to
> `__copysignf'
> ../sysdeps/ieee754/flt-32/s_scalbnf.c:58: undefined reference to
> `__copysignf'
> collect2: ld returned 1 exit status
> 
> 
> --
> Simon Strandman <simon.strandman@telia.com>
> 
> --
> gentoo-amd64@gentoo.org mailing list
> 
>

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] x86_64 optimization patches for glibc.

[Jeremy Huddleston]

[-- Attachment #1: Type: text/plain, Size: 2210 bytes --]

Hey,  I just finished reading through this thread.  I'm not as good
keeping up on the lists as I should be.

BUT... This sounds promising.  Unfortunately you send the email just
after I unmasked 2.3.5-r1, so it's not going to get in there, but it
could get into the next release with further testing.  Can you post both
patches to the bug, and I'll try to take care of getting the libm patch
to apply if nobody beats me to it.  Also be sure to report back the bug
number, so folks here can follow it too.

Thanks,
Jeremy

On Sat, 2005-07-23 at 16:48 +0200, Simon Strandman wrote:
> Hi!
> 
> Some binary distros like Mandrake and suse patches their glibcs with 
> x86_64 optimized strings and an x86_64 optimized libm to improve 
> performance.
> 
> I tried extracting those patches from an mandrake SRPM and add them to 
> the glibc 2.3.5 ebuild. The x86_64 optimized strings patch built and 
> worked perfectly and gave a large speedup as you can see below. But I 
> couldn't get glibc to build with the libm patch because of unresolved 
> symbols (and I'm no programmer so I have no idea how to fix that).
> 
> I found a small C program on a suse mailing-list to measure glibc memory 
> copy performance:
> http://lists.suse.com/archive/suse-amd64/2005-Mar/0220.html
> 
> With the glibc 2.3.5 currently in gentoo I get:
> isidor ~ # ./memcpy 2200 1000 1048576
> Memory to memory copy rate = 1291.600098 MBytes / sec. Block size = 1048576.
> 
> But with glibc 2.3.5 + amd64 optimized strings I get:
> isidor ~ # ./memcpy 2200 1000 1048576
> Memory to memory copy rate = 2389.321777 MBytes / sec. Block size = 1048576.
> 
> That's an improvement of over 1000mb/s! Suse 9.3 also gives about 
> 2300mb/s out of the box.
> 
> How about adding these patches to gentoo? Perhaps in glibc 2.3.5-r1 
> before it leaves package.mask? I'll create a bugreport about it if you 
> agree!
> 
> This .tar.bz2 contains the glibc directory from my overlay with the 
> mandrake patches included in files/mdk, but the libm patches are 
> commented out in the ebuild.
> http://snigel.no-ip.com/~nxsty/linux/glibc.tar.bz2
> 
> -- 
> Simon Strandman <simon.strandman@telia.com>


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-amd64] x86_64 optimization patches for glibc.

[Simon Strandman]

Done! Bug #100289
http://bugs.gentoo.org/show_bug.cgi?id=100289

Tell me if I need to provide any more information.

Jeremy Huddleston skrev:

>Hey,  I just finished reading through this thread.  I'm not as good
>keeping up on the lists as I should be.
>
>BUT... This sounds promising.  Unfortunately you send the email just
>after I unmasked 2.3.5-r1, so it's not going to get in there, but it
>could get into the next release with further testing.  Can you post both
>patches to the bug, and I'll try to take care of getting the libm patch
>to apply if nobody beats me to it.  Also be sure to report back the bug
>number, so folks here can follow it too.
>
>Thanks,
>Jeremy
>
>  
>

-- 
Simon Strandman <simon.strandman@telia.com>

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] x86_64 optimization patches for glibc.

[Jared Lindsay]

Sweet!  Here's to hoping this will be included in the official ebuilds :)

On 7/25/05, Simon Strandman <simon.strandman@telia.com> wrote:
> Done! Bug #100289
> http://bugs.gentoo.org/show_bug.cgi?id=100289
> 
> Tell me if I need to provide any more information.
> 
> Jeremy Huddleston skrev:
> 
> >Hey,  I just finished reading through this thread.  I'm not as good
> >keeping up on the lists as I should be.
> >
> >BUT... This sounds promising.  Unfortunately you send the email just
> >after I unmasked 2.3.5-r1, so it's not going to get in there, but it
> >could get into the next release with further testing.  Can you post both
> >patches to the bug, and I'll try to take care of getting the libm patch
> >to apply if nobody beats me to it.  Also be sure to report back the bug
> >number, so folks here can follow it too.
> >
> >Thanks,
> >Jeremy
> >
> >
> >
> 
> --
> Simon Strandman <simon.strandman@telia.com>
> 
> --
> gentoo-amd64@gentoo.org mailing list
> 
>

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] x86_64 optimization patches for glibc.

[Luke-Jr]

On Saturday 23 July 2005 18:44, Brian Litzinger wrote:
> > On Sat, 2005-07-23 at 16:48 +0200, Simon Strandman wrote:
> > > Memory to memory copy rate = 1291.600098 MBytes / sec. Block size =
> > > Memory to memory copy rate = 2389.321777 MBytes / sec. Block size =
> Memory to memory copy rate = 1302.701782 MBytes / sec. Block size =
> Memory to memory copy rate = 2051.979980 MBytes / sec. Block size =

Before: Memory to memory copy rate = 557.960449 MBytes / sec. Block size = 
After:   Memory to memory copy rate = 1120.773804 MBytes / sec. Block size = 

Anyone have a clue why I'm getting half what everyone else gets? o.O

Thanks.
-- 
Luke-Jr
Developer, Utopios
http://utopios.org/
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] x86_64 optimization patches for glibc.

[Olivier Crete]

On Mon, 2005-25-07 at 22:24 +0000, Luke-Jr wrote:
> On Saturday 23 July 2005 18:44, Brian Litzinger wrote:
> > > On Sat, 2005-07-23 at 16:48 +0200, Simon Strandman wrote:
> > > > Memory to memory copy rate = 1291.600098 MBytes / sec. Block size =
> > > > Memory to memory copy rate = 2389.321777 MBytes / sec. Block size =
> > Memory to memory copy rate = 1302.701782 MBytes / sec. Block size =
> > Memory to memory copy rate = 2051.979980 MBytes / sec. Block size =
> 
> Before: Memory to memory copy rate = 557.960449 MBytes / sec. Block size = 
> After:   Memory to memory copy rate = 1120.773804 MBytes / sec. Block size = 
> 
> Anyone have a clue why I'm getting half what everyone else gets? o.O

What kind of cpu/ram/motherboard do you have ?

-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer
x86 Security Liaison


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] x86_64 optimization patches for glibc.

[Brian Litzinger]

On Mon, Jul 25, 2005 at 10:24:46PM +0000, Luke-Jr wrote:
> On Saturday 23 July 2005 18:44, Brian Litzinger wrote:
> > > On Sat, 2005-07-23 at 16:48 +0200, Simon Strandman wrote:
> > > > Memory to memory copy rate = 1291.600098 MBytes / sec. Block size =
> > > > Memory to memory copy rate = 2389.321777 MBytes / sec. Block size =
> > Memory to memory copy rate = 1302.701782 MBytes / sec. Block size =
> > Memory to memory copy rate = 2051.979980 MBytes / sec. Block size =
> 
> Before: Memory to memory copy rate = 557.960449 MBytes / sec. Block size = 
> After:   Memory to memory copy rate = 1120.773804 MBytes / sec. Block size = 
> 
> Anyone have a clue why I'm getting half what everyone else gets? o.O

One of the arguments to memcpy is the clock rate in MHz of *your* CPU.
Did you adjust it appropriate for your system?

-- 
Brian Litzinger
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] x86_64 optimization patches for glibc.

[Luke-Jr]

On Monday 25 July 2005 22:38, Olivier Crete wrote:
> On Mon, 2005-25-07 at 22:24 +0000, Luke-Jr wrote:
> > On Saturday 23 July 2005 18:44, Brian Litzinger wrote:
> > > > On Sat, 2005-07-23 at 16:48 +0200, Simon Strandman wrote:
> > > > > Memory to memory copy rate = 1291.600098 MBytes / sec. Block size =
> > > > > Memory to memory copy rate = 2389.321777 MBytes / sec. Block size =
> > >
> > > Memory to memory copy rate = 1302.701782 MBytes / sec. Block size =
> > > Memory to memory copy rate = 2051.979980 MBytes / sec. Block size =
> >
> > Before: Memory to memory copy rate = 557.960449 MBytes / sec. Block size
> > = After:   Memory to memory copy rate = 1120.773804 MBytes / sec. Block
> > size =
> >
> > Anyone have a clue why I'm getting half what everyone else gets? o.O
>
> What kind of cpu/ram/motherboard do you have ?

RAM: 2875MB/1002MB (286%) used (I didn't see swapping during the test, tho)
Motherboard: Asus K8V-SE
CPU: AMD Athlon(tm) 64 Processor 3200+ (2202.876 MHz)

On Tuesday 26 July 2005 02:54, Brian Litzinger wrote:
> One of the arguments to memcpy is the clock rate in MHz of *your* CPU.
> Did you adjust it appropriate for your system?

memtst 2200 1000 1048576

so, yes... unless it's expecting the "Intel equivalent" 3200 number...
-- 
Luke-Jr
Developer, Utopios
http://utopios.org/
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: x86_64 optimization patches for glibc.

[Duncan]

Luke-Jr posted <200507261540.06591.luke-jr@utopios.org>, excerpted below, 
on Tue, 26 Jul 2005 15:40:05 +0000:

> On Monday 25 July 2005 22:38, Olivier Crete wrote:
>> On Mon, 2005-25-07 at 22:24 +0000, Luke-Jr wrote:
>> > On Saturday 23 July 2005 18:44, Brian Litzinger wrote:
>> > > > On Sat, 2005-07-23 at 16:48 +0200, Simon Strandman wrote:
>> > > > > Memory to memory copy rate = 1291.600098 MBytes / sec. Block size =
>> > > > > Memory to memory copy rate = 2389.321777 MBytes / sec. Block size =
>> > >
>> > > Memory to memory copy rate = 1302.701782 MBytes / sec. Block size =
>> > > Memory to memory copy rate = 2051.979980 MBytes / sec. Block size =
>> >
>> > Before: Memory to memory copy rate = 557.960449 MBytes / sec. Block size
>> > = After:   Memory to memory copy rate = 1120.773804 MBytes / sec. Block
>> > size =
>> >
>> > Anyone have a clue why I'm getting half what everyone else gets? o.O
>>
>> What kind of cpu/ram/motherboard do you have ?
> 
> RAM: 2875MB/1002MB (286%) used (I didn't see swapping during the test, tho)
> Motherboard: Asus K8V-SE
> CPU: AMD Athlon(tm) 64 Processor 3200+ (2202.876 MHz)

Perhaps it has something to do with the layout of your memory (and BIOS
configuration), single-channel vs. dual-channel memory access?

I'm getting the same lower (550-ish pre- haven't tried the patch yet)
readings here.  However, I know I only have a single 512 meg stick slotted
for each of my two CPUs (dual Opteron), and I'm running NUMA mode, so the
memory is only being accessed at single-channel speeds.  I expect I'd
double those numbers if I had paired sticks operating in per-node
interleaved dual-channel mode.  If I turned off NUMA and set inter-node
interleaving as well, with 4 matched memory sticks, to get full
quad-channel 128-bit interleaving, I expect the numbers would rise
accordingly. (Of course, the latter would be at the expense of allowing
parallel threads running on each CPU independent but parallel access to
their own memory.  I can get dual channel without foregoing that, since
each node is dual-channel capable, but couldn't get quad-channel without
foregoing that independent parallel access, since quad-channel is
inter-node interleaved.)

Of course, that's just supposition, here.  If those with the 1100/2200
rates would confirm whether they are running in dual-channel memory mode,
as I suspect, and you confirm that you are running single-channel mode, as
I am, it'll pretty much confirm that supposition, however.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: x86_64 optimization patches for glibc.

[Raffaele BELARDI]

Duncan wrote:
>>>>
>>>>Anyone have a clue why I'm getting half what everyone else gets? o.O
>>>
>>>What kind of cpu/ram/motherboard do you have ?
>>
>>RAM: 2875MB/1002MB (286%) used (I didn't see swapping during the test, tho)
>>Motherboard: Asus K8V-SE
>>CPU: AMD Athlon(tm) 64 Processor 3200+ (2202.876 MHz)
> 
> 
> Perhaps it has something to do with the layout of your memory (and BIOS
> configuration), single-channel vs. dual-channel memory access?

I was thinking the same, but moore on the CPU side: the Asus K8V
supports only the 745pin Athon64, which has a single memory channel as
opposed to the 900+ pin (I don't remember the exact number) Athlon64 FX,
which includes dual memory channel.

raffaele
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] x86_64 optimization patches for glibc.

[ardour]

gcc-3.4.4
glibc-2.3.5-r1
kernel: 2.6.12-gentoo-r4 x86_64

system:
AMD Athlon(tm) 64 Processor 3000+
Asus K8V Deluxe SE
1024 MB ram (not sure which)

before (sys-libs/glibc-2.3.5-r1)
./memcpy 2002 1000 1048576
Memory to memory copy rate = 998.548340 MBytes / sec. Block size = 1048576.

after (sys-libs/glibc-2.3.5-r1 with glibc-2.3.3-amd64-string.patch):
./memcpy 2002 1000 1048576
Memory to memory copy rate = 2089.066895 MBytes / sec. Block size = 1048576.

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: x86_64 optimization patches for glibc.

[Michael Edwards]

Am Dienstag, den 26.07.2005, 19:02 +0200 schrieb Raffaele BELARDI:
> Duncan wrote:
> >>>>
> >>>>Anyone have a clue why I'm getting half what everyone else gets? o.O
> >>>
> >>>What kind of cpu/ram/motherboard do you have ?
> >>
> >>RAM: 2875MB/1002MB (286%) used (I didn't see swapping during the test, tho)
> >>Motherboard: Asus K8V-SE
> >>CPU: AMD Athlon(tm) 64 Processor 3200+ (2202.876 MHz)
> > 
> > 
> > Perhaps it has something to do with the layout of your memory (and BIOS
> > configuration), single-channel vs. dual-channel memory access?
> 
> I was thinking the same, but moore on the CPU side: the Asus K8V
> supports only the 745pin Athon64, which has a single memory channel as
> opposed to the 900+ pin (I don't remember the exact number) Athlon64 FX,
> which includes dual memory channel.
> 
> raffaele
I have here a DFI ut NF3 250GB Board, and the Results are equal to the
others:

1324.712769 MBytes Vs. 2465.333008 MBytes

AMD Athlon 64 Processor 3000+ (745pins) and two 512GB sticks.

Maybe there is something wrong with the Bios settings?

Michael Edwards

-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Re: x86_64 optimization patches for glibc.

[Duncan]

Michael Edwards posted
<1122400181.27862.10.camel@slackit.herz--aus--gold.de>, excerpted below, 
on Tue, 26 Jul 2005 19:49:41 +0200:

> AMD Athlon 64 Processor 3000+ (745pins) and two 512GB sticks.
> 
> Maybe there is something wrong with the Bios settings?

Terabyte of memory... <drools at the thought>

I think you mean two 512MB sticks.  <g>  (Or just call them half-gig
sticks, that works too, and is what I've started doing.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: x86_64 optimization patches for glibc.

[Sami Samhuri]

[-- Attachment #1: Type: text/plain, Size: 920 bytes --]

* On Tue Jul-26-2005 at 09:50:00 AM -0700, Duncan said:
[...]
> Of course, that's just supposition, here.  If those with the 1100/2200
> rates would confirm whether they are running in dual-channel memory mode,
> as I suspect, and you confirm that you are running single-channel mode, as
> I am, it'll pretty much confirm that supposition, however.

glibc-2.3.5 (patched)
gentoo-sources-2.6.12-r4
linux-headers-2.6.11-r2
2x Opteron 246 (2GHz)
2x 512M, on processor #0 (dual channel)

% ./a.out 2000 5000 1048576
Memory to memory copy rate = 1367.611206 MBytes / sec. Block size = 1048576.
% ./a.out 4000 5000 1048576
Memory to memory copy rate = 2822.960693 MBytes / sec. Block size = 1048576.

Since only 1 processor is used in this test I'm not sure which processor
speed I should use, and hence which result is accurate. In any case they
take the same amount of time, ~3.7s.

-- 
Sami Samhuri

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-amd64] Re: x86_64 optimization patches for glibc.

[Matt Randolph]

This is interesting.  Guess what effect cpu frequency scaling has on 
memcpy.  I wonder if the difference has to do purely with the cpu 
frequency, or if it's because the memory controller in on the die.

At 1800 MHz:
$ ./memcpy 1808 1000 1048576
Memory to memory copy rate = 1060.210815 MBytes / sec. Block size = 1048576.

At 1000 MHz:
$ ./memcpy 1005 1000 1048576
Memory to memory copy rate = 808.985352 MBytes / sec. Block size = 1048576.

This is an unpatched glibc, of course.

I've got a single 512MB stick of premium Corsair ram in it (the sister 
stick lives in another computer until prices drop, at which time I will 
buy another matched pair of the good stuff).

The fact that I'm using only one stick and I'm getting speeds similar to 
those using two, suggests to me that the strangely low numbers some 
people are getting are not explained away by their using only a single 
channel.

-- 
"Pluralitas non est ponenda sine necessitate" - W. of O.

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] x86_64 optimization patches for glibc.

[netpython]

Should i use -march=k8 or -march=athlon64 ? Or doesn't make any
difference? My CPU is a AMD64 3000+



On 7/23/05, Simon Strandman <simon.strandman@telia.com> wrote:
> Allan Wang skrev:
> 
> >
> >Hmm, I don't see much difference here.
> >
> >before:
> >allan@aw ~ $ ./a.out 2420 1000 1048576
> >Memory to memory copy rate = 1110.198486 MBytes / sec. Block size =
> >1048576.
> >
> >after:
> >aw allan # ./a.out 2420 1000 1048576
> >Memory to memory copy rate = 1154.922974 MBytes / sec. Block size =
> >1048576.
> >
> >Allan
> >
> >
> >
> What kind och system do you have?
> 
> These are my spec:
> AMD64 3500+ Winchester 2,2ghz
> Asus A8N-SLI Deluxe (nforce4)
> 1024mb DDR dual channel
> 
> And emerge info:
> isidor ~ # emerge info
> Portage 2.0.51.22-r2 (default-linux/amd64/2005.0, gcc-3.4.4,
> glibc-2.3.5-r0, 2.6.12-ck3-r1 x86_64)
> =================================================================
> System uname: 2.6.12-ck3-r1 x86_64 AMD Athlon(tm) 64 Processor 3500+
> Gentoo Base System version 1.6.13
> dev-lang/python:     2.3.5
> sys-apps/sandbox:    1.2.11
> sys-devel/autoconf:  2.13, 2.59-r6
> sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5
> sys-devel/binutils:  2.16.1, 2.16.91.0.1
> sys-devel/libtool:   1.5.18-r1
> virtual/os-headers:  2.6.11-r2
> ACCEPT_KEYWORDS="amd64"
> AUTOCLEAN="yes"
> CBUILD="x86_64-pc-linux-gnu"
> CFLAGS="-O2 -march=athlon64 -fomit-frame-pointer -pipe -fno-ident"
> CHOST="x86_64-pc-linux-gnu"
> CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config
> /usr/lib/X11/xkb /usr/share/config /var/qmail/control"
> CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
> CXXFLAGS="-O2 -march=athlon64 -fomit-frame-pointer -pipe -fno-ident
> -fvisibility-inlines-hidden -fno-enforce-eh-specs"
> DISTDIR="/usr/portage/distfiles"
> FEATURES="autoconfig distlocks sandbox sfperms strict"
> GENTOO_MIRRORS="http://snigel.no-ip.com/ http://mirror.pudas.net/gentoo
> ftp://ftp.rhnet.is/pub/gentoo/
> ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror/
> http://ftp.rhnet.is/pub/gentoo/"
> LANG="sv_SE.UTF-8"
> LC_ALL="sv_SE.UTF-8"
> LDFLAGS="-Wl,-O1"
> LINGUAS="sv"
> MAKEOPTS="-j2"
> PKGDIR="/usr/portage/packages"
> PORTAGE_TMPDIR="/var/tmp"
> PORTDIR="/usr/portage"
> PORTDIR_OVERLAY="/usr/local/portage"
> SYNC="rsync://rsync.gentoo.org/gentoo-portage"
> USE="amd64 X aalib alsa artswrappersuid avi berkdb caps cdr crypt dga
> dlloader dvd dvdr dvdread encode f77 fbcon foomaticdb fortran gcj gif
> glibc-omitfp gnome gphoto2 gpm gtk gtk2 hal imlib ipv6 ithreads
> jack-tmpfs java javascript jpeg kdeenablefinal logitech-mouse lzw
> lzw-tiff mad mikmod mng mozilla mp3 mpeg ncurses nls nomalloccheck nptl
> nptlonly nvidia objc offensive oggvorbis opengl pdflib perl pic png pnp
> python qt quicktime readline samba sdl spell ssl svg tcpd threadstiff
> truetype truetype-fonts type1-fonts unicode usb userlocales
> visualization xine xml2 xmms xpm xv xvid zlib video_cards_nvidia
> linguas_sv userland_GNU kernel_linux elibc_glibc"
> Unset:  ASFLAGS, CTARGET
> 
> --
> Simon Strandman <simon.strandman@telia.com>
> 
> --
> gentoo-amd64@gentoo.org mailing list
> 
>

-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: x86_64 optimization patches for glibc.

[Duncan]

netpython posted <3655f5d905072703096be71ed1@mail.gmail.com>, excerpted
below,  on Wed, 27 Jul 2005 10:09:35 +0000:

> Should i use -march=k8 or -march=athlon64 ? Or doesn't make any
> difference? My CPU is a AMD64 3000+

At this point, it makes absolutely no difference.  The two, along with
-march=opteron, and I think one or two other aliases, are internally set
to exactly the same thing in gcc.

There's a small chance that at some point in the future the hardware paths
of the current aliases will diverge enough to make splitting the alias a
possibility, but practically speaking, even if that /were/ to happen, the
new diverged version would very likely get a different name, so as to
preserve backward compatibility for all those who set their configuration
when they were all aliases.  Thus, the chance of there actually being a
difference between what is now treated exactly the same, is in reality,
/very/ small, a small chance on a small chance.  Odds of winning the
lottery or dieing in a car accident are likely far higher.

Here, I use -march=k8, simply because "k8" is a distinctive and short
enough string, it's easy to pick out in moving text, as the compile output
scrolls by, thus making it easier for me to verify my CFLAGS as part of
the settings fed to gcc as they fly by.  Other than that, it's entirely
arbitrary.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: x86_64 optimization patches for glibc.

[Duncan]

Simon Strandman posted <42E55ADB.8030201@telia.com>, excerpted below,  on
Mon, 25 Jul 2005 23:34:19 +0200:

> Done! Bug #100289
> http://bugs.gentoo.org/show_bug.cgi?id=100289
> 
> Tell me if I need to provide any more information.

For those following the thread here, but not keeping up with the bug,
testing reveals that at least one app, nano, crashes (when searching),
with the patches applied to glibc, until nano is remerged against the new
glibc. Yes, that means that the issue goes away with a remerge, but there
could be other apps similarly affected.

There are two factors making this *VERY* serious.  (1) nano just
happens to be the text editor used in the config file editing examples in
the installation handbook, so there are likely more Gentoo users for that
particular app than in the normal Linux using population.  (2)  The crash
/can/ mean it eats the file it was editing.

Taken together, that makes the issue a critical one indeed, particularly
since the users that are still using nano rather than having formed their
own preferences (ignoring for the moment those that have actually made an
informed decision to use nano, having tried other editors), are also
likely the ones not to have backups of their critical config files.

Additionally, where there's app crashing due to a change in glibc, there
are bound to be more.  Thus, integration of the patches is on hold for
now, and likely will be for some time, until something a bit safer, either
in strategy or in patches, can be devised.

Thus, anyone hoping to run these in an official Gentoo glibc should be
preparing to do their own glibc patching, with each new version, for
awhile.  Additionally, it could blacklist any further bugs you file, at
least until your whole toolchain and any misbehaving apps have been
remerged against the patched glibc.

Do note that any issues that might exist would seem to disappear once the
entire system is compiled against the patched glibc.  That's why SuSE can
get away with running the patch -- their entire amd64 release will have
been compiled against the patched glibc.  Thus, there are no known issues
with doing a stage-1 bootstrap with these patches, since by the time the
system is up and running, it'll all be compiled against the patched glibc.
Likewise, there are no known issues at this time, should one decide to
patch glibc, and then do an emerge --emptytree.  In any case, however,
doing your own glibc patching, regardless of what the patch is, is likely
to blacklist any bugs you may file.  That's something that may be
worthwhile to keep in mind.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: x86_64 optimization patches for glibc.

[Brian Hall]

Perhaps a USE flag could be created to enable the glibc patches, then a
emerge --newuse could recompile glibc and the problem apps (or
everything); maybe a mini-howto document would also be helpful.

I would certainly like an easy way to enable any "free" performance
boost I can get!

On Sun, 31 Jul 2005 07:24:55 -0700
Duncan <1i5t5.duncan@cox.net> wrote:

> Simon Strandman posted <42E55ADB.8030201@telia.com>, excerpted
> below,  on Mon, 25 Jul 2005 23:34:19 +0200:
> 
> > Done! Bug #100289
> > http://bugs.gentoo.org/show_bug.cgi?id=100289
> > 
> > Tell me if I need to provide any more information.
> 
> For those following the thread here, but not keeping up with the bug,
> testing reveals that at least one app, nano, crashes (when searching),
> with the patches applied to glibc, until nano is remerged against the
> new glibc. Yes, that means that the issue goes away with a remerge,
> but there could be other apps similarly affected.
> 
> There are two factors making this *VERY* serious.  (1) nano just
> happens to be the text editor used in the config file editing
> examples in the installation handbook, so there are likely more
> Gentoo users for that particular app than in the normal Linux using
> population.  (2)  The crash /can/ mean it eats the file it was
> editing.
> 
> Taken together, that makes the issue a critical one indeed,
> particularly since the users that are still using nano rather than
> having formed their own preferences (ignoring for the moment those
> that have actually made an informed decision to use nano, having
> tried other editors), are also likely the ones not to have backups of
> their critical config files.
> 
> Additionally, where there's app crashing due to a change in glibc,
> there are bound to be more.  Thus, integration of the patches is on
> hold for now, and likely will be for some time, until something a bit
> safer, either in strategy or in patches, can be devised.
> 
> Thus, anyone hoping to run these in an official Gentoo glibc should be
> preparing to do their own glibc patching, with each new version, for
> awhile.  Additionally, it could blacklist any further bugs you file,
> at least until your whole toolchain and any misbehaving apps have been
> remerged against the patched glibc.
> 
> Do note that any issues that might exist would seem to disappear once
> the entire system is compiled against the patched glibc.  That's why
> SuSE can get away with running the patch -- their entire amd64
> release will have been compiled against the patched glibc.  Thus,
> there are no known issues with doing a stage-1 bootstrap with these
> patches, since by the time the system is up and running, it'll all be
> compiled against the patched glibc. Likewise, there are no known
> issues at this time, should one decide to patch glibc, and then do an
> emerge --emptytree.  In any case, however, doing your own glibc
> patching, regardless of what the patch is, is likely to blacklist any
> bugs you may file.  That's something that may be worthwhile to keep
> in mind.
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Re: x86_64 optimization patches for glibc.

[Duncan]

Brian Hall posted <20050731085600.65fc8657.brihall@pcisys.net>, excerpted
below,  on Sun, 31 Jul 2005 08:56:00 -0600:

> Perhaps a USE flag could be created to enable the glibc patches, then a
> emerge --newuse could recompile glibc and the problem apps (or
> everything); maybe a mini-howto document would also be helpful.
> 
> I would certainly like an easy way to enable any "free" performance
> boost I can get!

Something like USE=dangerous-amd64-hack? <g>

(Seriously, there at least used to be a local use flag
USE=frickin-big-security-hole, or some such, on some app I can't remember
at the moment.  Turns out a teacher was using that app in his class as a
an example or something, so the dev left the ability to create it there,
but with a USE flag nobody in their right mind would normally enable.  I
wish I could remember what it was, but grepping use.local.desc for
anything that might be related doesn't seem to bring it up.  Perhaps the
app, or anyway the USE flag, has now been removed from portage?)

The use.local.desc description could point to the bug, which is IIRC what
the one above did, for those wanting more information about just why such
a USE flag exists, and just why someone might be persuaded to enable it.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Re: x86_64 optimization patches for glibc.

[Ben Skeggs]

Duncan wrote:

>Brian Hall posted <20050731085600.65fc8657.brihall@pcisys.net>, excerpted
>below,  on Sun, 31 Jul 2005 08:56:00 -0600:
>
>  
>
>>Perhaps a USE flag could be created to enable the glibc patches, then a
>>emerge --newuse could recompile glibc and the problem apps (or
>>everything); maybe a mini-howto document would also be helpful.
>>
>>I would certainly like an easy way to enable any "free" performance
>>boost I can get!
>>    
>>
>
>Something like USE=dangerous-amd64-hack? <g>
>
>(Seriously, there at least used to be a local use flag
>USE=frickin-big-security-hole, or some such, on some app I can't remember
>at the moment.  Turns out a teacher was using that app in his class as a
>an example or something, so the dev left the ability to create it there,
>but with a USE flag nobody in their right mind would normally enable.  I
>wish I could remember what it was, but grepping use.local.desc for
>anything that might be related doesn't seem to bring it up.  Perhaps the
>app, or anyway the USE flag, has now been removed from portage?)
>
>The use.local.desc description could point to the bug, which is IIRC what
>the one above did, for those wanting more information about just why such
>a USE flag exists, and just why someone might be persuaded to enable it.
>
>  
>
Are you talking about GAPING_SECURITY_HOLE?  If so, this flag is still
in use by the net-analyzer/netcat package.  It enables the "-E" (iirc) 
switch
which allows you to do something like:
       nc -l -p 12345 -E /bin/bash

This(or something close to it) would cause netcat to listen on port 12345,
and forward the person who connects to it a nice bash shell.

Ben.
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Re: x86_64 optimization patches for glibc.

[Jared Lindsay]

Yeah, netcat, hehe.

emerge -pv netcat
...
[ebuild  N    ] net-analyzer/netcat                                   
[110-r8]                       -GAPING_SECURITY_HOLE +crypt -ipv6
-static 107 kB

I would be interested in a USE flag for this glibc patch.

On 7/31/05, Ben Skeggs <darktama@iinet.net.au> wrote:
> Duncan wrote:
> 
> >Brian Hall posted <20050731085600.65fc8657.brihall@pcisys.net>, excerpted
> >below,  on Sun, 31 Jul 2005 08:56:00 -0600:
> >
> >
> >
> >>Perhaps a USE flag could be created to enable the glibc patches, then a
> >>emerge --newuse could recompile glibc and the problem apps (or
> >>everything); maybe a mini-howto document would also be helpful.
> >>
> >>I would certainly like an easy way to enable any "free" performance
> >>boost I can get!
> >>
> >>
> >
> >Something like USE=dangerous-amd64-hack? <g>
> >
> >(Seriously, there at least used to be a local use flag
> >USE=frickin-big-security-hole, or some such, on some app I can't remember
> >at the moment.  Turns out a teacher was using that app in his class as a
> >an example or something, so the dev left the ability to create it there,
> >but with a USE flag nobody in their right mind would normally enable.  I
> >wish I could remember what it was, but grepping use.local.desc for
> >anything that might be related doesn't seem to bring it up.  Perhaps the
> >app, or anyway the USE flag, has now been removed from portage?)
> >
> >The use.local.desc description could point to the bug, which is IIRC what
> >the one above did, for those wanting more information about just why such
> >a USE flag exists, and just why someone might be persuaded to enable it.
> >
> >
> >
> Are you talking about GAPING_SECURITY_HOLE?  If so, this flag is still
> in use by the net-analyzer/netcat package.  It enables the "-E" (iirc)
> switch
> which allows you to do something like:
>        nc -l -p 12345 -E /bin/bash
> 
> This(or something close to it) would cause netcat to listen on port 12345,
> and forward the person who connects to it a nice bash shell.
> 
> Ben.
> --
> gentoo-amd64@gentoo.org mailing list
> 
>

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Re: x86_64 optimization patches for glibc.

[Nuitari]

Same here for the USE flags.

I'm also starting to get used to these kinds of problems with mod_php & 
apache.

On Sun, 31 Jul 2005, Jared Lindsay wrote:

> Date: Sun, 31 Jul 2005 11:46:59 -0700
> From: Jared Lindsay <cinder.sub@gmail.com>
> Reply-To: gentoo-amd64@lists.gentoo.org
> To: gentoo-amd64@lists.gentoo.org
> Subject: Re: [gentoo-amd64] Re: Re: x86_64 optimization patches for glibc.
> 
> Yeah, netcat, hehe.
>
> emerge -pv netcat
> ...
> [ebuild  N    ] net-analyzer/netcat
> [110-r8]                       -GAPING_SECURITY_HOLE +crypt -ipv6
> -static 107 kB
>
> I would be interested in a USE flag for this glibc patch.
>
> On 7/31/05, Ben Skeggs <darktama@iinet.net.au> wrote:
>> Duncan wrote:
>>
>>> Brian Hall posted <20050731085600.65fc8657.brihall@pcisys.net>, excerpted
>>> below,  on Sun, 31 Jul 2005 08:56:00 -0600:
>>>
>>>
>>>
>>>> Perhaps a USE flag could be created to enable the glibc patches, then a
>>>> emerge --newuse could recompile glibc and the problem apps (or
>>>> everything); maybe a mini-howto document would also be helpful.
>>>>
>>>> I would certainly like an easy way to enable any "free" performance
>>>> boost I can get!
>>>>
>>>>
>>>
>>> Something like USE=dangerous-amd64-hack? <g>
>>>
>>> (Seriously, there at least used to be a local use flag
>>> USE=frickin-big-security-hole, or some such, on some app I can't remember
>>> at the moment.  Turns out a teacher was using that app in his class as a
>>> an example or something, so the dev left the ability to create it there,
>>> but with a USE flag nobody in their right mind would normally enable.  I
>>> wish I could remember what it was, but grepping use.local.desc for
>>> anything that might be related doesn't seem to bring it up.  Perhaps the
>>> app, or anyway the USE flag, has now been removed from portage?)
>>>
>>> The use.local.desc description could point to the bug, which is IIRC what
>>> the one above did, for those wanting more information about just why such
>>> a USE flag exists, and just why someone might be persuaded to enable it.
>>>
>>>
>>>
>> Are you talking about GAPING_SECURITY_HOLE?  If so, this flag is still
>> in use by the net-analyzer/netcat package.  It enables the "-E" (iirc)
>> switch
>> which allows you to do something like:
>>        nc -l -p 12345 -E /bin/bash
>>
>> This(or something close to it) would cause netcat to listen on port 12345,
>> and forward the person who connects to it a nice bash shell.
>>
>> Ben.
>> --
>> gentoo-amd64@gentoo.org mailing list
>>
>>
>
>
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: x86_64 optimization patches for glibc.

[Simon Strandman]

Duncan skrev:

>Simon Strandman posted <42E55ADB.8030201@telia.com>, excerpted below,  on
>Mon, 25 Jul 2005 23:34:19 +0200:
>
>  
>
>>Done! Bug #100289
>>http://bugs.gentoo.org/show_bug.cgi?id=100289
>>
>>Tell me if I need to provide any more information.
>>    
>>
>
>For those following the thread here, but not keeping up with the bug,
>testing reveals that at least one app, nano, crashes (when searching),
>with the patches applied to glibc, until nano is remerged against the new
>glibc. Yes, that means that the issue goes away with a remerge, but there
>could be other apps similarly affected.
>  
>

But changes to glibc usually breaks stuff and requires recompiling. 
Remember what happened when glibc 2.3.4.20041102 was marked stable? A 
lot of people got crashes and problems and needed to recompile or even 
reinstall. The switch to NPTL only in glibc 2.4 will cause this kind of 
problems too. So perhaps these patches could be added to the glibc 2.4 
snapshots (2.3.5.20050421 and 2.3.5.20050722) and 2.4 when it's released 
(if they are still relevant by then) because people will have to 
recompile then anyway. But a USE-flag is a good idea if they are added 
to a stable version!

-- 
Simon Strandman <simon.strandman@telia.com>

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: x86_64 optimization patches for glibc.

[Jan Jitse Venselaar]

[-- Attachment #1: Type: text/plain, Size: 1620 bytes --]

On Sunday 31 July 2005 16:24, Duncan wrote:
> Simon Strandman posted <42E55ADB.8030201@telia.com>, excerpted below,  on
>
> Mon, 25 Jul 2005 23:34:19 +0200:
> > Done! Bug #100289
> > http://bugs.gentoo.org/show_bug.cgi?id=100289
> >
> > Tell me if I need to provide any more information.
> Do note that any issues that might exist would seem to disappear once the
> entire system is compiled against the patched glibc.  That's why SuSE can
> get away with running the patch -- their entire amd64 release will have
> been compiled against the patched glibc.  Thus, there are no known issues
> with doing a stage-1 bootstrap with these patches, since by the time the
> system is up and running, it'll all be compiled against the patched glibc.
> Likewise, there are no known issues at this time, should one decide to
> patch glibc, and then do an emerge --emptytree.  In any case, however,
> doing your own glibc patching, regardless of what the patch is, is likely
> to blacklist any bugs you may file.  That's something that may be
> worthwhile to keep in mind.
>
As the reporter of the problem with nano, I'd like to make 1 correction to 
this report: Recompiling nano and its depencies did not fix the crashes. It 
just fixed the eating of the file. 
I did not recompile my entire system, but a crash of such a small and basic 
app as nano made me not want to do this outside of a chroot, which I 
currently do not have the means for. 
I reread my report, and I saw it was not clear that recompiling nano and its 
dependencies did not fix the crashes. Sorry for the confusion.

Jan Jitse

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-amd64] Re: Re: x86_64 optimization patches for glibc.

[Duncan]

Jan Jitse Venselaar posted <200508011105.14688.janjitse@gmail.com>,
excerpted below,  on Mon, 01 Aug 2005 11:04:38 +0200:

> As the reporter of the problem with nano, I'd like to make 1 correction to 
> this report: Recompiling nano and its depencies did not fix the crashes. It 
> just fixed the eating of the file. 

Thanks for the correction.

> I did not recompile my entire system, but a crash of such a small and basic 
> app as nano made me not want to do this outside of a chroot, which I 
> currently do not have the means for.

A rather good point.  Of course, some of us like living on the edge <g>,
but it's still something I'd not add as a dev, certainly not unless it was
linked to some sort of local
USE=this-might-kill-your-children-and-eat-their-flesh type of USE flag! <g>

(OK, s/children/files/, s/their-flesh/your-disk/, but you get the point...)

Never-the-less, I added the strings patch here, and have the new KDE 3.4.2
stuff at least, compiled against it...  Computing is my hobby; if I
wanted something that would predictably "just work", I'd be doing TiVos or
the like!  Much of the fun is the occasional breakage in mysterious ways,
never knowing quite when it'll happen, and the challenge of figuring out
how to get back to a working system, again!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Re: Re: x86_64 optimization patches for glibc.

[Duncan]

Ben Skeggs posted <42ED0D96.9030302@iinet.net.au>, excerpted below,  on
Mon, 01 Aug 2005 03:42:46 +1000:

> Are you talking about GAPING_SECURITY_HOLE?  If so, this flag is still
> in use by the net-analyzer/netcat package.  It enables the "-E" (iirc) 
> switch
> which allows you to do something like:
>        nc -l -p 12345 -E /bin/bash
> 
> This(or something close to it) would cause netcat to listen on port 12345,
> and forward the person who connects to it a nice bash shell.

That's the one!  I was grepping the lower case, so couldn't find it. 
Now I know why!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Re: x86_64 optimization patches for glibc.

[Karol Krizka]

On 8/1/05, Duncan <1i5t5.duncan@cox.net> wrote:
> Jan Jitse Venselaar posted <200508011105.14688.janjitse@gmail.com>,
> excerpted below,  on Mon, 01 Aug 2005 11:04:38 +0200:
> 
> > As the reporter of the problem with nano, I'd like to make 1 correction to
> > this report: Recompiling nano and its depencies did not fix the crashes. It
> > just fixed the eating of the file.
> 
> Thanks for the correction.
> 
I am just compiling my amd64 laptop from stage1 again, but this time I
applied the patches right in the beginning. Nano seems to run fine so
far (in chroot), so how do you get the crashes? I tried searching as
mentioned in the abose post.

> > I did not recompile my entire system, but a crash of such a small and basic
> > app as nano made me not want to do this outside of a chroot, which I
> > currently do not have the means for.
> 
> A rather good point.  Of course, some of us like living on the edge <g>,
> but it's still something I'd not add as a dev, certainly not unless it was
> linked to some sort of local
> USE=this-might-kill-your-children-and-eat-their-flesh type of USE flag! <g>
> 
> (OK, s/children/files/, s/their-flesh/your-disk/, but you get the point...)
> 
> Never-the-less, I added the strings patch here, and have the new KDE 3.4.2
> stuff at least, compiled against it...  Computing is my hobby; if I
> wanted something that would predictably "just work", I'd be doing TiVos or
> the like!  Much of the fun is the occasional breakage in mysterious ways,
> never knowing quite when it'll happen, and the challenge of figuring out
> how to get back to a working system, again!
> 
So if you wanted something to just work you would be running Linux on
TiVo? I think a intel computer would be better for that...

> --
> Duncan - List replies preferred.   No HTML msgs.
> "Every nonfree program has a lord, a master --
> and if you use the program, he is your master."  Richard Stallman in
> http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html
> 
> 
> --
> gentoo-amd64@gentoo.org mailing list
> 
> 


-- 
Cheers,
Karol Krizka

-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Re: Re: x86_64 optimization patches for glibc.

[Duncan]

Karol Krizka posted <ac342b0a0508011003686becfc@mail.gmail.com>, excerpted
below,  on Mon, 01 Aug 2005 10:03:13 -0700:

>> Never-the-less, I added the strings patch here, and have the new KDE 3.4.2
>> stuff at least, compiled against it...  Computing is my hobby; if I
>> wanted something that would predictably "just work", I'd be doing TiVos or
>> the like!  Much of the fun is the occasional breakage in mysterious ways,
>> never knowing quite when it'll happen, and the challenge of figuring out
>> how to get back to a working system, again!
>> 
> So if you wanted something to just work you would be running Linux on
> TiVo? I think a intel computer would be better for that...
> Never-the-less, I added the strings patch here, and have the new KDE 3.4.2
> stuff at least, compiled against it...  Computing is my hobby; if I
> wanted something that would predictably "just work", I'd be doing TiVos or
> the like!  Much of the fun is the occasional breakage in mysterious ways,
> never knowing quite when it'll happen, and the challenge of figuring out
> how to get back to a working system, again!
> 
So if you wanted something to just work you would be running Linux on
TiVo? I think a intel computer would be better for that...

No... perhaps I didn't choose a far out enough example.  I usually choose
a refrigerator or TV instead...  The point is, if I wanted something that
predictably "just worked", computing wouldn't be my hobby in the /first/
place, I'd have chosen something better known for its "just working"
qualities.

In point of fact, before I got my first PC (in fact, the /only/ whole PC I
ever got, a 486sx25 w/ the CPU soldered to the mobo, 4 meg RAM, and a 130
meg hard drive -- I just counted myself lucky to get a 486 over a 386), I
had two VCRs hooked up to my TV, such that I could watch previous shows
while recording the current nite's shows, allowing me to FF over the
commercials.   That, and I could rent movies and record them to the second
VCR while playing them from the first.  Interactivity was pretty much
limited to that FF button -- and hitting back when I overshot a bit.  Now,
I don't even own a TV (other than a tiny 2.5" TFT version, bought back in
the day..., that I have around somewhere, don't even know where...), as
I've grown to despise the lack of control one has over a TV program, and
the fact that the programmers must cater to their paying customers, the
advertisers, which in turn are happiest with the zombies easiest
programmed to buy their warez even when they are twice the cost or more of
the generic brand and even when they don't need them and can't really
afford them.  Thus, there's actually a DIS-incentive to program for the
discerning intellect -- those that actually /like/ to think, and can't be
so easily programmed to buy expensive stuff they don't need.

So... I've switched to a more interactive and intellectually rewarding
hobby, computers, and enjoy the challenges they sometimes present.  I
simply chose TiVos as the example above, because that'd be the modern
equivalent of the VCRs I was using before I got into computers.  While
personally significant, that choice of example was obviously less than
clear to those who have no way of knowing my history and who have a
different one of their own, and the usual TV or refrigerator example would
have been rather more effective at making my point.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Re: Re: x86_64 optimization patches for glibc.

[Matt Randolph]

Duncan wrote:

>I had two VCRs hooked up to my TV, such that I could watch previous shows
>while recording the current nite's shows, allowing me to FF over the
>commercials.   That, and I could rent movies and record them to the second
>VCR while playing them from the first.  Interactivity was pretty much
>limited to that FF button -- and hitting back when I overshot a bit.  Now,
>I don't even own a TV (other than a tiny 2.5" TFT version, bought back in
>the day..., that I have around somewhere, don't even know where...), as
>I've grown to despise the lack of control one has over a TV program, and
>the fact that the programmers must cater to their paying customers, the
>advertisers, which in turn are happiest with the zombies easiest
>programmed to buy their warez even when they are twice the cost or more of
>the generic brand and even when they don't need them and can't really
>afford them.  Thus, there's actually a DIS-incentive to program for the
>discerning intellect -- those that actually /like/ to think, and can't be
>so easily programmed to buy expensive stuff they don't need.
>
A little off topic, but I'll be brief:

The ReplayTV brand DVR (or is it PVR these days) would automatically 
skip over the commercials in pre-recorded shows.  I say "would" because 
this feature has been discontinued in the later models.  The last ones 
to have it were the 4000 and 4500 series models.  I rather enjoy being 
able to watch a typical thirty minute show in just over fifteen, knowing 
that I'm sticking it to the advertising nazis at the same time. 

It has happened on more than one occasion that people have been 
discussing some bit of pop-culture that originated in an ubiquitous 
commercial, and that I had no idea what they were talking about.  There 
have been blockbuster movies that came and went without my learning of 
their existence until much later, if at all (I never saw Titanic, for 
instance).

I'm not sure, but I believe one of the Linux based, home-brewed DVRs 
like MythTV has an automatic commercial skip feature too.

You may be missing out on those few shows that are actually well 
written.  On the other hand, it is probably better for your health to 
simply do without TV altogether.

I find it extremely entertaining that you (apparently) have Cox cable 
internet, and yet you have no TV to speak of.  More power to you.

-- 
"Pluralitas non est ponenda sine necessitate" - W. of O.

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] hijacked! :) television (was: x86_64 optimization patches for glibc.)

[Sami Samhuri]

[-- Attachment #1: Type: text/plain, Size: 1745 bytes --]

* On Tue Aug-02-2005 at 03:41:42 PM -0400, Matt Randolph said:
> Duncan wrote:
[...]
> >I've grown to despise the lack of control one has over a TV program, and
> >the fact that the programmers must cater to their paying customers, the
> >advertisers, which in turn are happiest with the zombies easiest
> >programmed to buy their warez even when they are twice the cost or more of
> >the generic brand and even when they don't need them and can't really
> >afford them.  Thus, there's actually a DIS-incentive to program for the
> >discerning intellect -- those that actually /like/ to think, and can't be
> >so easily programmed to buy expensive stuff they don't need.
> >
> A little off topic, but I'll be brief:
[...]
> You may be missing out on those few shows that are actually well 
> written.  On the other hand, it is probably better for your health to 
> simply do without TV altogether.
> 
> I find it extremely entertaining that you (apparently) have Cox cable 
> internet, and yet you have no TV to speak of.  More power to you.

I haven't had cable TV in years. I too despise advertisements. Most of
them are insulting at best. My ISP is the local cable provider, Shaw,
and they called me up to offer me $10/month cable television service.
The lady was shocked I didn't have cable, and even more shocked when I
asked why I would want to pay for commercials. (radio is free is it
not? greedy cable companies!) If I had the money for a nice HTPC and
a fine selection of channels then I would probably get cable. However, I
have no desire to sit and channel surf through piles of ads. As you
said, we are missing out on the _few_ shows that are well written. Not
to mention movies.

-- 
Sami Samhuri

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-amd64] hijacked! :) television (was: x86_64 optimization patches for glibc.)

[Luke-Jr]

On Tuesday 02 August 2005 23:27, Sami Samhuri wrote:
> * On Tue Aug-02-2005 at 03:41:42 PM -0400, Matt Randolph said:
> > You may be missing out on those few shows that are actually well
> > written.  On the other hand, it is probably better for your health to
> > simply do without TV altogether.
> >
> > I find it extremely entertaining that you (apparently) have Cox cable
> > internet, and yet you have no TV to speak of.  More power to you.
>
> I haven't had cable TV in years. I too despise advertisements. Most of
> them are insulting at best. My ISP is the local cable provider, Shaw,
> and they called me up to offer me $10/month cable television service.
> The lady was shocked I didn't have cable, and even more shocked when I
> asked why I would want to pay for commercials. (radio is free is it
> not? greedy cable companies!) If I had the money for a nice HTPC and
> a fine selection of channels then I would probably get cable. However, I
> have no desire to sit and channel surf through piles of ads. As you
> said, we are missing out on the _few_ shows that are well written. Not
> to mention movies.

Can always download them... (assuming they're legally downloadable, if you 
prefer the assumption ;)
-- 
Luke-Jr
Developer, Utopios
http://utopios.org/
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] hijacked! :) television (was: x86_64 optimization patches for glibc.)

[Sami Samhuri]

[-- Attachment #1: Type: text/plain, Size: 1822 bytes --]

* On Thu Aug-04-2005 at 02:28:21 AM +0000, Luke-Jr said:
> On Tuesday 02 August 2005 23:27, Sami Samhuri wrote:
> > * On Tue Aug-02-2005 at 03:41:42 PM -0400, Matt Randolph said:
> > > You may be missing out on those few shows that are actually well
> > > written.  On the other hand, it is probably better for your health to
> > > simply do without TV altogether.
> > >
> > > I find it extremely entertaining that you (apparently) have Cox cable
> > > internet, and yet you have no TV to speak of.  More power to you.
> >
> > I haven't had cable TV in years. I too despise advertisements. Most of
> > them are insulting at best. My ISP is the local cable provider, Shaw,
> > and they called me up to offer me $10/month cable television service.
> > The lady was shocked I didn't have cable, and even more shocked when I
> > asked why I would want to pay for commercials. (radio is free is it
> > not? greedy cable companies!) If I had the money for a nice HTPC and
> > a fine selection of channels then I would probably get cable. However, I
> > have no desire to sit and channel surf through piles of ads. As you
> > said, we are missing out on the _few_ shows that are well written. Not
> > to mention movies.
> 
> Can always download them... (assuming they're legally downloadable, if you 
> prefer the assumption ;)

I've never looked into legally downloadable content. Do many producers
do that yet?

I have to say, as soon as they start mass-producing 5TB disks and I can
put 6 of those in a slick HTPC, I'm going to archive my movie collection
as well (music is archived, CD's are just for the discman now). If they
started selling downloadable DVDs I would buy those and burn the backup
discs myself.

I think this is getting a little too OT. Sorry list. :)

-- 
Sami Samhuri

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-amd64] hijacked! :) television (was: x86_64 optimization patches for glibc.)

[Arm Suwarnaratana]

[-- Attachment #1: Type: text/plain, Size: 2207 bytes --]

I have 3 channels in english.... and 34234029348 spanish channels. If i want 
to switch from CBS to NBC i have to go outside to turn my yagi : (.

On 8/4/05, Sami Samhuri <sami@no-eff-eks.com> wrote:
> 
> * On Thu Aug-04-2005 at 02:28:21 AM +0000, Luke-Jr said:
> > On Tuesday 02 August 2005 23:27, Sami Samhuri wrote:
> > > * On Tue Aug-02-2005 at 03:41:42 PM -0400, Matt Randolph said:
> > > > You may be missing out on those few shows that are actually well
> > > > written. On the other hand, it is probably better for your health to
> > > > simply do without TV altogether.
> > > >
> > > > I find it extremely entertaining that you (apparently) have Cox 
> cable
> > > > internet, and yet you have no TV to speak of. More power to you.
> > >
> > > I haven't had cable TV in years. I too despise advertisements. Most of
> > > them are insulting at best. My ISP is the local cable provider, Shaw,
> > > and they called me up to offer me $10/month cable television service.
> > > The lady was shocked I didn't have cable, and even more shocked when I
> > > asked why I would want to pay for commercials. (radio is free is it
> > > not? greedy cable companies!) If I had the money for a nice HTPC and
> > > a fine selection of channels then I would probably get cable. However, 
> I
> > > have no desire to sit and channel surf through piles of ads. As you
> > > said, we are missing out on the _few_ shows that are well written. Not
> > > to mention movies.
> >
> > Can always download them... (assuming they're legally downloadable, if 
> you
> > prefer the assumption ;)
> 
> I've never looked into legally downloadable content. Do many producers
> do that yet?
> 
> I have to say, as soon as they start mass-producing 5TB disks and I can
> put 6 of those in a slick HTPC, I'm going to archive my movie collection
> as well (music is archived, CD's are just for the discman now). If they
> started selling downloadable DVDs I would buy those and burn the backup
> discs myself.
> 
> I think this is getting a little too OT. Sorry list. :)
> 
> --
> Sami Samhuri
> 
> 
> 


-- 
chicken goes cluck cluck, cow goes moo, leamer goes phh phh how bout you?

[-- Attachment #2: Type: text/html, Size: 2660 bytes --]

Re: [gentoo-amd64] Re: x86_64 optimization patches for glibc.

[Simon Strandman]

Jan Jitse Venselaar skrev:

>As the reporter of the problem with nano, I'd like to make 1 correction to 
>this report: Recompiling nano and its depencies did not fix the crashes. It 
>just fixed the eating of the file. 
>I did not recompile my entire system, but a crash of such a small and basic 
>app as nano made me not want to do this outside of a chroot, which I 
>currently do not have the means for. 
>I reread my report, and I saw it was not clear that recompiling nano and its 
>dependencies did not fix the crashes. Sorry for the confusion.
>
>Jan Jitse
>  
>
I have a theory about the nano problem. Could you please try with nano 
1.2.5 instead and see if it still craches?

I believe this might be a bug in nano 1.3.X and not a problem with the 
amd64 strings patch, it just exposes the bug. Nano 1.3.8 running under 
Suse 9.3 suffers from exactly the same problem (craching when 
searching). But if I downgrade it to 1.2.5 it's completly stable. And 
1.3.X is actually the unstable development branch of nano while 1.2.X is 
the stable so it could very well contain bugs.

-- 
Simon Strandman <simon.strandman@telia.com>

-- 
gentoo-amd64@gentoo.org mailing list