2012-05-09 9 views
11

Ich habe ein Multithread-Mergesorting-Programm in C und ein Programm für Benchmark-Tests mit 0, 1, 2 oder 4 Threads. Ich habe auch ein Programm in Python geschrieben, um mehrere Tests durchzuführen und die Ergebnisse zu aggregieren.C-Programm ist schneller als Python-Subprozess

Die seltsame Sache ist, dass, wenn ich den Python ausführen, die Tests immer in etwa der Hälfte der Zeit im Vergleich zu laufen, wenn ich sie direkt in der Shell ausführen.

Zum Beispiel, wenn ich das Testprogramm selbst mit 4 Millionen ganzen Zahlen laufen zu sortieren (die letzten beiden Argumente sind die Samen und Module zum Erzeugen von ganzen Zahlen):

$ ./mergetest 4000000 4194819 140810581084 
0 threads: 1.483485s wall; 1.476092s user; 0.004001s sys 
1 threads: 1.489206s wall; 1.488093s user; 0.000000s sys 
2 threads: 0.854119s wall; 1.608100s user; 0.008000s sys 
4 threads: 0.673286s wall; 2.224139s user; 0.024002s sys 

Mit dem Python-Skript:

$ ./mergedata.py 1 4000000 
Average runtime for 1 runs with 4000000 items each: 
0 threads: 0.677512s wall; 0.664041s user; 0.016001s sys 
1 threads: 0.709118s wall; 0.704044s user; 0.004001s sys 
2 threads: 0.414058s wall; 0.752047s user; 0.028001s sys 
4 threads: 0.373708s wall; 1.24008s user; 0.024002s sys 

Das passiert, egal wie viele ich sortiere, oder wie oft ich es betreibe. Das Python-Programm ruft den Tester mit dem Unterprozessmodul auf und parst und aggregiert die Ausgabe. Irgendwelche Ideen, warum das passieren würde? Python optimiert irgendwie die Ausführung? Oder bremst es etwas, wenn ich es direkt führe, was mir nicht bewusst ist?

Code: https://gist.github.com/2650009

+10

Können Sie uns den Python-Code zeigen? – NPE

+3

... und der C-Code auch. Oder stellen Sie zumindest einen Zeiger auf den Code auf GitHub oder ähnlichem. –

+7

Liegt es daran, dass die Ausführung der Shell dazu führt, dass das Programm unverhältnismäßig lange auf die Konsole druckt? Versuchen Sie, 'stdout' auf'/dev/null' umzuleiten und sehen Sie, ob sich dadurch die Situation ändert. –

Antwort

2

Es stellte sich heraus, ich habe sys.maxint an den Unterprozess als Modul für die Generierung von Zufallszahlen übergeben. C schnitt die 64-Bit-Ganzzahl ab und interpretierte sie als vorzeichenbehaftet, dh -1 im Zweierkomplement, so dass jede Zufallszahl dadurch modifiziert wurde und zu 0 wurde. Das Sortieren der gleichen Werte scheint ungefähr die Hälfte zu dauern viel Zeit als Zufallsdaten.

0

dies in einer Shell-Skript Umwickeln wird wahrscheinlich die gleiche Wirkung. Wenn ja, ist es die Konsole Operationen

+0

Wrapping in einem Bash-Skript hatte keine Wirkung - immer noch doppelt so langsam wie in Python. Welche Konsolenvorgänge würden die Leistung so sehr beeinträchtigen? – scry

+0

Die Pufferung der Ausgabe. Ich denke, dass Sie das Python-Skript veröffentlichen müssen, damit jeder eine Chance hat, das zu lösen. –