# transcode extrem langsam!  64bit ?

## nordlicht

Hallo

ich habe hier einen AMD 64 X2 2GHz mit 4 GB RAM auf einem ASUS A8N-SLI Deluxe.

Das sollte eigendlich ein schnelles System sein.

Bis vor kurzem hatte ich Archlinux 32BIT und wollte zwecks Tuning und wegen meines Spieltriebes zu Gentoo.

Bei Gentoo habe ich mich für 64 BIT eintschieden.

Was ich nicht verstehe ist, das das System beim "erstelen von Sicherheitskopien von nicht kopiergeschützten DVD" so langsam geworden ist.

Unter Arch hat eine DVD bei identischer Hardware ca 3 Stunden benötigt (xVid, 2-Pass)

Jetzt unter 64Bit dauert es plötzlich knapp 20 Stunden (zwanzig Stunden).

Wie ist das möglich? Transcode soll meines Wissens nach auf 64Bit schneller laufen.

Das System ist komplett auf aktuellen Stand.

Ist das Problem bekannt? was kann ich tun?

danke und Gruss

Christian

----------

## TheCurse

Bekannt ist auf jeden Fall, dass man gentoo schön "kaputtoptimieren" kann...

Kannst ja vielleicht mal die Ausgabe von emerge --info posten, vielleicht ist es ja irgendetwas offensichtliches. Ansonsten: Unter 64bin die selben Schalter für transcode genutzt?

Mit welchen USE-Flags hast du denn transcode kompiliert?

Gruß,

TheCurse

----------

## mv

 *TheCurse wrote:*   

> Bekannt ist auf jeden Fall, dass man gentoo schön "kaputtoptimieren" kann...

 

Bei allen Optimierungssachen (auch dem Unterschied 32Bit/64Bit) geht es (aufsummiert) normalerweise um 1-30 Prozent, nicht um den Faktor 6-7 wie hier. Da liegt irgendwas anderes im Argen. Möglich wäre vielleicht, dass ssl/ssl2 nicht aktiviert sind oder ein spezieller 32Bit-Assembler-Code unter 64Bit nur in C vorhanden ist, aber bei diesem Zeitunterschied erscheint mir selbst das unwahrscheinlich.

Von der Beschreibung ist unklar, was die Zeit schluckt: Geht es neu-kodieren auch so langsam, wenn die Daten nicht von DVD sondern unmittelbar von der Platte gelesen werden? Geht Kopieren der Daten bereits extrem langsam? Ist mencoder (von mplayer) auch ähnlich langsam? Tritt das Problem bei allen Codecs auf oder nur bei xvid? Oder ist gar die Soundkodierung die Bremse?

BTW: Sprichst Du wirklich von der xvid-Bibliothek? Ist die nicht i.W. von der libavcodec (etwa in ffmeg) abgelöst worden?

----------

## nordlicht

Moin moin

@TheCurse

```

loki64 chris # emerge --info

Portage 2.1.3.16 (default-linux/amd64/2007.0/desktop, gcc-4.1.2, glibc-2.6.1-r0, 2.6.22-gentoo-r8 x86_64)

=================================================================

System uname: 2.6.22-gentoo-r8 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+

Timestamp of tree: Fri, 02 Nov 2007 19:50:01 +0000

ccache version 2.4 [enabled]

app-shells/bash:     3.2_p17

dev-java/java-config: 1.3.7, 2.0.33-r1

dev-lang/python:     2.4.4-r6

dev-python/pycrypto: 2.0.1-r6

dev-util/ccache:     2.4-r7

sys-apps/baselayout: 1.12.9-r2

sys-apps/sandbox:    1.2.18.1-r2

sys-devel/autoconf:  2.13, 2.61-r1

sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10

sys-devel/binutils:  2.18-r1

sys-devel/gcc-config: 1.3.16

sys-devel/libtool:   1.5.24

virtual/os-headers:  2.6.22-r2

ACCEPT_KEYWORDS="amd64"

CBUILD="x86_64-pc-linux-gnu"

CFLAGS="-march=athlon64 -O2 -fomit-frame-pointer -pipe"

CHOST="x86_64-pc-linux-gnu"

CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config"

CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d"

CXXFLAGS="-march=athlon64 -O2 -fomit-frame-pointer -pipe"

DISTDIR="/usr/portage/distfiles"

FEATURES="ccache distlocks metada-transfer metadata-transfer nostrip sandbox sfperms strict unmerge-orphans userfetch"

GENTOO_MIRRORS="ftp://ftp.tu-clausthal.de/pub/linux/gentoo/ ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/ ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror/ http://ftp.uni-erlangen.de/pub/mirrors/gentoo ftp://ftp.uni-erlangen.de/pub/mirrors/gentoo ftp://ftp.join.uni-muenster.de/pub/linux/distributions/gentoo ftp://ftp.wh2.tu-dresden.de/pub/mirrors/gentoo http://mirrors.sec.informatik.tu-darmstadt.de/gentoo/ http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://ftp.gentoo.mesh-solutions.com/gentoo/ http://pandemonium.tiscali.de/pub/gentoo/ ftp://pandemonium.tiscali.de/pub/gentoo/ http://gentoo.mneisen.org/ ftp://ftp.mneisen.org/gentoo "

LC_ALL="de_DE.UTF-8"

LINGUAS="de en"

MAKEOPTS="-j3"

PKGDIR="/usr/portage/packages"

PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*"

PORTAGE_TMPDIR="/var/tmp"

PORTDIR="/usr/portage"

SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"

USE="3dnow 3dnowext X acl acpi alsa amd64 arts berkdb bitmap-fonts bluetooth bogofilter branding bzip2 cairo ccache cdr cli cracklib crypt css cups dar64 dbus divx dri dvb dvd dvdnav dvdr dvdread dynamic ecc eds encode esd evo exif fam ffmpeg firefox fortran gdbm german gif gimp gimpprint gnome gnome-print gnuplot gnutls gpgme gphoto2 gpm gs gstreamer gtk guile gzip hal iconv id3 id3tag idea imagemagick imap ipv6 java javascript jpeg jpeg2k jpg kde kerberos lame ldap libg++ libgcrypt libgda lm_sensors logrotate mad matroska mdb midi mikmod mime mmx mmxext mp3 mp4 mp4live mpeg mpeg2 mplayer mudflap musicbrainz mysql nautilus ncurses nls nptl nptlonly ntfs ntpl ntplonly nvidia nxclient obex ogg opengl openmp oss pam parport pcap pcapnav pcre pdf perl pidgin png postscript ppds pppd prediction python qt3 qt3support qt4 quicktime rar raw readline realmedia reflection reiserfs screen sdl session slang smartcard smp spell spl sse sse2 ssl svg taglib tagwriting tcpd tetex theora tiff transcode truetype truetype-fonts twolame type1-fonts udev unicode unzip usb uuencode vorbis webdav wireshark wma wmf wmp x264 xanim xfs xml xorg xv xvid zip zlib" 

ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" 

ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" 

KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" 

LINGUAS="de en" 

USERLAND="GNU" 

VIDEO_CARDS="apm ark chips cirrus cyrix dummy fbdev glint i128 i810 mach64 mga neomagic nv r128 radeon rendition s3 s3virge savage siliconmotion sis sisusb tdfx tga trident tseng v4l vesa vga via vmware voodoo"

Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY

```

@mv

meines wissens nach benutzt dvd::rip die xvid lib.

Die Systemlast von transcode geht laut top auf 110%. Könnte das evtl bedeuten das die CPu versucht den task auf beide Kerne zu verteilen sich dann aber nur mit aufeinander warten vertut? Muß ich evtl transcode schon beim compilieren sagen dass ich zwei kerne habe? Gibt es einen dualcoreflag?

gruss

christian

----------

## Josef.95

Hallo nordlicht

Hast du mal überprüft ob deine vier Gig Ram auch erkannt,genutzt werden?

```
# grep MemTotal /proc/meminfo
```

viel Glück

MfG  josef.95

----------

## nordlicht

Moin

ja, alles wir erkennt.

Die 4GB waren der Hauptgrund auf 64Bit zu wechseln...

```

loki64 chris # grep MemTotal /proc/meminfo

MemTotal:      4048200 kB

```

@mv

es scheint an xvid zu liegen!

mit ffmpeg als mpeg4 codieren geht viel schneller, ca 22 fps gegen 4fps bei xvid

----------

## mv

 *nordlicht wrote:*   

> es scheint an xvid zu liegen!

 

Ich habe mir gerade mal das ChangeLog von xvid angesehen: Die letzte Änderung ist (von einem Sicherheitspatch mal abgesehen) von 2005. Damals hat man noch nicht so gut gewusst, wie man für den x86_64 am günstigsten optimiert (zumindest wurde mir gesagt, dass die libavcode-Leute am Anfang damit enorme Probleme hatten), und sehr viel von dem Code ist in x86-Assembler geschrieben (obwohl es auch einige x86_64-Assembler-Dateien gibt). Ich kann mir gut vorstellen, dass die Optimierung des xvid-Codes für den x86 deutlich ausgereifter ist, wenngleich mich dieser enorme Unterschied schon sehr erstaunt.

Dem Datum nach scheint es wohl wirklich so zu sein, dass die xvid-Entwicklung zugunsten von libavcodec eingestellt wurde - aber ich lasse mich gerne von jemandem mit genaueren Informationen belehren.

----------

## disi

Ich kann dir leider auch nicht sagen woran es liegt aber aus Erfahrung habe ich etwa folgende Werte mit xvid und xvid4

die erste Phase dauert etwa 45min und die zweite dann so 1 - 1,5 Std.

Eine gesamte dvd dauert bei mir etwa 2,5 bis 3 Std.

Mein System ist aehnlich amd 4600+ und nur 2 gb ram alles auf 64bit compiliert (ausser flash natuerlich).

Nimmst du dvd:rip fuer die Einstellungen? Rippst du "on the fly" oder schreibst du erst auf Platte?

welchen "nice" level stellst du ein bei dvdrip? Ich nehme 0 anstatt 19 wie standard.

----------

## gimpel

Ich würde mal -msse3 zu den CFLAGS hinuzufügen. transcode benutzt das hier wie es aussieht.

Nicht dass du damit wieder von 20h auf 3h kommst, aber generell unterstützt der Prozessor das.

Auf dem X2 5600+ mit amd64 System hier braucht transcode für 1h45min Film mit 2-Pass FFMPEG decoding ca. 50-60 Minuten. Beide cores sind dabei recht gleichmäßig ausgelastet, obwohl transcode nur einen thread hochfährt.

Rechne ich den Film mit ffmpeg direkt um, muss ich ffmpeg ein -threads 2 mitgeben, sonst wird nur ein core ausgelastet.

Wenn das bei dir nicht tut, dass bei transcode mit einem thread beide cores verwendet werden, dann starte transcode explizit mit 2 threads.

----------

