# MEncode-Prozesse gezielt auf CPU0/1 starten

## DarkSpir

Ich bin mir fast sicher, dass es nicht funktioniert, aber sicherheitshalber frag ich mal die Gurus.  :Smile: 

Kann ich beim Start eines Programms, welches nur eine CPU verwendet, ihm gezielt sagen, dass es nur auf CPU0 ausgeführt wird?

Hintergrund: Ich muss einen haufen Videos mit mencode von h264 auf xvid umcodieren, damit sie der DVD-Player meiner Freundin abspielen kann. Also for-Schleife machen und die Videos an einem langen Wochenende mal rödeln lassen. Bei einem Testlauf ist mir dann aufgefallen, dass mencode nur eine meiner beiden CPUs nutzt. Gut, das kann man dann kompensieren, indem man eben zwei mencodes parallel laufen lässt... aber dann möchte ich gezielt steuern, dass Prozess 1 auf CPU0 und Prozess 2 auf CPU1 gestartet wird, nicht dass dann am Ende zwei Prozesse jeweils zu 50% auf CPU0 laufen und CPU1 sich die Klöten schaukelt.  :Wink: 

Alternative: Ich glaube gesehen zu haben, dass ffmpeg ein thread-Flag hat und dementsprechend eine Mehrprozessorumgebung optimaler ausnutzen kann. Hat jemand einen Einzeiler für mich, bei dem aus einer Quell-avi mit h264 ein Ziel-avi mit xvid gemacht wird ohne den bereits in mp3 vorliegenden Ton anzufassen  (soll einfach nur mitkopiert werden)? Damit wär mir dann nämlich warscheinlich auch geholfen.

----------

## Anarcho

Das binden an eine spezielle CPU ist möglich, Stichwörter wären "CPU Affinity" und "CPU Sets".

Allerdings denke ich das sie in deinem Fall nicht nötig sind. Der Kernel sollte die Prozesse so auf beide Cores verteilen das beide optimal ausgelastet sind.

----------

## DarkSpir

kay, ich werds probieren.

Ich konnte mich daran erinnern, dass ich früher auf meiner alten Kiste (damals noch unter Windows... ach ja... damals.  :Smile:  ) DVDs zu xvid umcodiert habe. Damals hat er die Videos in gut 90 Minuten durchgefrühstückt. Mein Laptop hat jetzt knapp 130 Minuten gebraucht.

Okay, ich wollts wissen und hab den Test gemacht. Meine alte Kiste gegen mein Laptop.

Alte Kiste: AMD Athlon XP 2400+ (2GHz Takt), 1 GB Ram, Gentoo

Mein Laptop Intel Core2 Duo, 2,4 GHz Takt, 4 GB Ram, Gentoo

MEncoder raxelt auf dem Laptop das Video in 130 Minuten durch (auf einer CPU). Das SELBE Video mit den GLEICHEN Programmaufruf und Parametern und gedöhns rödelt auf meiner alten Kiste in 75 Minuten durch.

Ihr könnt euch grad nicht mein Gesichtsausdruck vorstellen...

Discuss.

----------

## firefly

 *DarkSpir wrote:*   

> kay, ich werds probieren.
> 
> Ich konnte mich daran erinnern, dass ich früher auf meiner alten Kiste (damals noch unter Windows... ach ja... damals.  ) DVDs zu xvid umcodiert habe. Damals hat er die Videos in gut 90 Minuten durchgefrühstückt. Mein Laptop hat jetzt knapp 130 Minuten gebraucht.
> 
> Okay, ich wollts wissen und hab den Test gemacht. Meine alte Kiste gegen mein Laptop.
> ...

 

Ich vermute mal das liegt daran, das die Festplatte in deinem Laptop langsamer, was den Durchsatz betrifft, ist als die Festplatte in deinem Desktop Rechner.

Um herauszufinden ob es daran liegt, könntest du das decodieren auf einem RAM-Laufwerk (tmpfs) testen.

----------

## oscarwild

 *DarkSpir wrote:*   

> Alte Kiste: AMD Athlon XP 2400+ (2GHz Takt), 1 GB Ram, Gentoo
> 
> Mein Laptop Intel Core2 Duo, 2,4 GHz Takt, 4 GB Ram, Gentoo
> 
> MEncoder raxelt auf dem Laptop das Video in 130 Minuten durch (auf einer CPU). Das SELBE Video mit den GLEICHEN Programmaufruf und Parametern und gedöhns rödelt auf meiner alten Kiste in 75 Minuten durch.

 

Bei der Differenz kann man die langsamere Notbuchplatte mit Sicherheit ausschließen.

Falls Du den Core2Duo mit einem 64Bit-System nutzt, liegt die Ursache sehr wahrscheinlich im xvid-Codec, der in aktueller Version verheerend langsam läuft.

Die letzte mir bekannte Version, die unter 64 Bit mit vernünftiger Geschwindigkeit arbeitet, ist xvid-1.1.0-r1. Probiers mal aus.

Gruß

OscarWild

----------

## Polynomial-C

```
taskset -c [#CPU] command [arg]
```

Man beachte, daß die CPUs mit 0 beginnen: CPU1=0, CPU2=1, CPU3=2, ...

Kombinieren ist auch möglich: 

```
taskset -c 0,2,5-7 command [arg]
```

taskset gehört zum sys-apps/util-linux Paket.

----------

## DarkSpir

 *oscarwild wrote:*   

> Falls Du den Core2Duo mit einem 64Bit-System nutzt, liegt die Ursache sehr wahrscheinlich im xvid-Codec, der in aktueller Version verheerend langsam läuft.

 Guter Tipp, das klingt nach meinem System. Ich überleg grad was das Teil alternativ an Codecs frisst und ob ich dann einfach auch was Anderes als xvid nehmen kann. Sind dir noch andere Codecs mit Performance-Problemen unter 64Bit bekannt?

@Poly: Danke! Falls sich das nicht von selbst gescheit verteilt, greif ich darauf zurück.

Edit:

Also, zum Einen funktioniert das mit dem doppelten Aufruf. Der Kernel verteilt die beiden Prozesse problemlos auf die beiden CPUs ohne dass ich dabei nachhelfen muss. Trotzdem danke an Poly, der Aufruf wandert in meine Trickkiste für später.  :Smile: 

Und dann: Ich hatte xvid-1.1.3 auf meinem System, hab aber gesehen, dass es noch ein r3 dafür gab. Hatte aber dieselbe Performance. Dann hab ichs mit der 1.1.0-r1 probiert, die oscarwild da vorgeschlagen hat und meinen Glauben zurück erhalten.

Wo 1.1.3 die Datei mit 11 fps durchkaut, produziert die 1.1.0-r1 locker 50 fps. Holla, heute Nacht wird geraxelt!

Danke für die hilfe!

----------

## Aldo

 *DarkSpir wrote:*   

> Hat jemand einen Einzeiler für mich, bei dem aus einer Quell-avi mit h264 ein Ziel-avi mit xvid gemacht wird ohne den bereits in mp3 vorliegenden Ton anzufassen  (soll einfach nur mitkopiert werden)?

 

```
mencoder input.avi -ovc lavc -lavcopts vcodec=mpeg4:threads=4:vbitrate=999 -vf pp=lb:a/dr:a,hqdn3d=4:3:6 -oac copy -o output.avi
```

Xvid selbst (also der Codec) kann meines Wissesn kein Multithreading, aber mit o.a. Zeile klappt es.

----------

## DarkSpir

Aaah, sehr gut. Mein MEncoder-Job ist zwar jetzt durchgelaufen, aber ich habs in das Script aufgenommen fürs nächste Mal wo ich vielleicht nicht die Möglichkeit habe, zwei Jobs parallel auf zwei Verzeichnisse laufen zu lassen und so die CPUs komplett auszunutzen.

Tja, dafür ergab sich heute früh ein anderes Problem. Übers Wochenende hat jemand den Portage-Tree überarbeitet und media-libs/xvid-1.1.0* raus genommen. Im Moment gibt es nur Version 1.1.3 und 1.1.3-r3 und die haben beide das Performance-Problem unter amd64. Da ich aber alles größer als 1.1.0-r3 in package.mask maskiert habe, krieg ich jetzt natürlich den Fehler, dass zu xvid entweder keine ebuilds existieren oder alle maskiert sind.

Was tut man in solch einer Situation?

----------

## Finswimmer

 *DarkSpir wrote:*   

> Aaah, sehr gut. Mein MEncoder-Job ist zwar jetzt durchgelaufen, aber ich habs in das Script aufgenommen fürs nächste Mal wo ich vielleicht nicht die Möglichkeit habe, zwei Jobs parallel auf zwei Verzeichnisse laufen zu lassen und so die CPUs komplett auszunutzen.
> 
> Tja, dafür ergab sich heute früh ein anderes Problem. Übers Wochenende hat jemand den Portage-Tree überarbeitet und media-libs/xvid-1.1.0* raus genommen. Im Moment gibt es nur Version 1.1.3 und 1.1.3-r3 und die haben beide das Performance-Problem unter amd64. Da ich aber alles größer als 1.1.0-r3 in package.mask maskiert habe, krieg ich jetzt natürlich den Fehler, dass zu xvid entweder keine ebuilds existieren oder alle maskiert sind.
> 
> Was tut man in solch einer Situation?

 

In sein lokales Overlay kopieren. Die alten Ebuilds solltest du noch im Internet finden, oder unter /var/db/

Tobi

----------

## DarkSpir

Hmm, okay. Hab ich jetzt gemacht. Allerdings ist das auch nur ne Lösung für mich. Ich bin aber mit Sicherheit nicht der Einzige mit dem Problem eine 64Bit-Umbegung zu haben und jetzt quasi gezwungen zu sein die aktuellste xvid zu benutzen. Wie sähe denn die Lösung für die Anderen aus?

Ich habe ein bisschen gegoogelt, im xvid stecken ziemlich viele Funktionen, die direkt in Assembler geschrieben sind und somit am C-Compiler vorbei laufen, aber wohl aufgrund der manuellen Optimierung mehr Performance liefern. Auf meiner alten Gurke (x86) jagt er mir im Compile-Vorgang 34 asm-Dateien durch den Assembler, auf meinem Core 2 Duo (x86_64) sinds gradmal ne Handvoll. Der Codec ist so lahm, weil es schlicht keine Assembler-Optimierung für 64Bit-Architekturen gibt, bzw keiner eine geschrieben hat. Okay, jetzt haben wir zumindest die Ursache des Problems und kommen somit auf ein Weiteres: Meine Assemblerkenntnisse sind seit über 10 Jahren eingestaubt und bestenfalls rudimentär.  :Smile: 

Edit:

Mir kam grad noch ne andere Idee. Theoretisch kann ich 32Bit-Code auf meinem Rechner ausführen (sofern der Kernel dafür passend gebaut ist, aber das is ja eine Frage von einem schnellen make menuconfig && make && make modules_install inklusive cp und reboot). Kann ich irgendwie xvid und mplayer zusätzlich als x86 bauen (sofern die dazu notwendigen Bibliotheken ebenfalls als x86 vorliegen)?

----------

