programm mit thread langsamer als ohne

[canonmclay]

Hi ihr,

wir haben in der schule als letzes Thema in Info ein Projekt zum Verteilten Rechnen gestartet und abgeschlossen. Da ich aber jetzt abi hab und mich geistig fit halten wollte, habe ich mich ein wenig in Threads eingearbeitet. Unser Programm funktioniert so, das ein Server an mehrere Rechner im Netzwerk auf denen ein Client Progri läuft einen md5-hash schickt, welcher vom Client dann Per Brute Force versucht wird zu lösen. Dabei rechnet ein Client immer ein bestimmtes Paket aus, welches vom Server vorgegeben wird. (Wie genau wir das gemacht haben erspare ich euch mal, hat ja nix mit dem Problem zu tun).

Nun mein Problem:
Üblicherweise dauert das Rechnen eines Paketes auf meinem Rechner ca 7 sek. Wenn ich jedoch die Rechen routine in einem gesonderten Thread auslagere, so dauert die Rechenzeit für ein Paket fast 20 sek. Weiß jemand woran das liegen könnte? (Sinn des ganzen ist, das ein Client auf einer Dual Core maschine 2 Pakete Gleichzeitig Rechnen soll. Das Problem des Verteilens auf einzelne Cores habe ich bereits gelöst.)
Achja: ein "Rechen-Paket" besteht aus 857.375 versch. Hashes die gebildet und mit dem zu knackenden verglichen werden. (hab i-wo gelesen, das bei "einfachen" Operationen (addition ect.) das mit threads immer länger dauert...)

Ich kann auch gerne den Code hochladen, wenn dies erforderlich ist :).

Gruß
McLay

[himitsu]

Eventuell wäre es auch gut, wenn du mal etwas Code zeigst, denn ohne kann keiner (von uns) sagen, wo du den Fehler bverbaut hast oder ob es einfach so ist und es unabdingbar langsamer werden mußte.

Ja, man kann duch Multithreading etwas langsamer machen.
> zusätzliche Synchronisation zwischen den Threads
> zu exzessives Synchronize mit dem Hauptthread
> mechanische Bremsen > wenn z.B. zwei gleichzeitig auf die Festplatte zugreifen, dann bremsen sie sich aus, da der Schreib-/Lesekopf viel Zeit verbraucht, um ständig zwischen den einzelnen Zugriffen hin- und herzuspringen.
> uvm.

[s.h.a.r.k]

Herzlich Willkommen in der DP.

Es kommt immer darauf an, wie du die Programmierung bei Threads vornimmst. Verwendest du viele Synchronisations-Methoden können sich Threads durchaus ausbremsen oder unter Umständen zu einem Deadlock führen. Ohne dir aber unterstellen zu wollen, dass das so der Fall ist, wäre ein minimales Beispiel, zur Not aber auch der ganze, notwendige Code, sinnvoll :)

-- EDIT: Wo war dieses mal der rote Kasten!? :grml:

-- EDIT2: Ich mag himitsus Liste auch noch eine ThreadedList hinzufügen, da das eine Bremse sein kann, die ich letzter Zeit häufiger gesehen habe.

[canonmclay]

So hier mal die Thread-Teile des Progamms:

Delphi-Quellcode:

type
  strx = string[40];

  knack = class(TThread)
  private
    nachicht:string;
    g:BOOLEAN;
    pw : STRING;
    flabel4,flabel5:Tlabel;
    suchwort:strx;
    ersterbuchstabe:string;

    fwort:Tedit;

    fcheck: TCheckBox;

    procedure DoVisualSwap1;
    procedure dovisualswap2;
    function knacke(temptext:STRING):STRING;
    { Private declarations }

  protected
     procedure Execute; override;
  public
    constructor create(anzeige1,anzeige2:Tlabel;wort:Tedit;servernachicht:STRING;check: TCheckBox);


  end;

procedure knack.DoVisualSwap1;   // anzeigen des gesendeten Buchstabens
BEGIN
  flabel4.caption:='Hash:' +suchwort;
  flabel5.caption:='Vorgegebene(s) Zeichen: "'+ersterbuchstabe+'"';
END;


procedure knack.dovisualswap2;  //Hier wird das gefundene PW übergeben
BEGIN
  fwort.text:=PW;
  fcheck.checked:= g;
END;


function knack.knacke(temptext:STRING):STRING;

VAR k,i,j:integer;
    abc:STRING;

BEGIN

   g:=false; //inititalisieren der Variablen

   suchwort:='';
   ersterbuchstabe:='';
   k:=0;

   ///Die empfangene Nachricht wird in Hash und Buchstaben zerlegt.
   ///suchwort = Hash vom Server
   ///k = anzahl der Buchstaben die der Server vorgibt
   for i := 1 to 36 do
     begin
      if (i<=33) and (i>1) then suchwort:=suchwort+temptext[i];
      if i=35 then k:=strtoint(temptext[35]);
     end;

   for j := 1 to k do
     begin
      ersterbuchstabe:=ersterbuchstabe+(temptext[35+j]);
      ///Die ersten vorgegebenen Buchstaben werden angegeben.
     end;

   synchronize(dovisualswap1);

   abc:='   ';//Das sind die ERSTEN Acsii-Zeichen (3x leer) mit denen begonnen wird

   while length(abc)<4 do
     begin
       if suchwort=MD5Print(MD5String(ersterbuchstabe+abc)) then
         begin
           g:=true;
           result:=abc;
           break;
         end; // if suchwort

       abc:=strhoeher(abc);
     end; // while

////^^^^Hier drüber wird abc immer eins nach oben gesetzt und davon der Hash gebildet.
////^^^^Wenn der Hash = dem gesendetem Hash dann abbrechen und dem Server das PW melden.

END;

constructor knack.create(anzeige1,anzeige2:Tlabel;wort:Tedit;servernachicht:STRING;check: TCheckBox);
BEGIN
 flabel4:=anzeige1;
 flabel5:=anzeige2;

 fcheck:=check;
 fwort:=wort;
 nachicht:=servernachicht;

 freeOnTerminate := True;
 inherited Create(False);
 Priority := tpHighest;
 SetThreadAffinityMaskByID(getcurrentthreadid,1);


END;


procedure knack.Execute;
VAR tmp : STRING;
    i,k:INTEGER;
begin

  pw:='';

  tmp:=knacke(nachicht);  //bearbeiten eines Rechenpaketes

  IF g THEN   //Wenn PW gefunden, dann wird das Passwort in die Variable PW gespeichert
    BEGIN
      k:=strtoint(nachicht[35]);
      FOR  i:=1 TO k DO PW:=pw+nachicht[i+35];
      PW:=pw+tmp;

      synchronize(dovisualswap2);   //Hier wird dann das PW übergeben
    END;



  { Place thread code here }
end;

es gibt auf noch eine thread done Procedure, aber ich denk die is eher nebensächlich:

Delphi-Quellcode:

procedure tform1.ThreadDone(Sender: TObject); //   beim fertigstellen des Threads wird  hier ggf. ein neuer gestartet
BEGIN                                         // Oder das gefundene PW übermittelt
  IF (checkbox1.checked AND clients.Active)
     THEN
       clients.Socket.SendText('| Das Passwort ist '+ edit3.text +' |')
     ELSE
     BEGIN
       //dec(anzahlthreads);
       clients.Socket.SendText('ich warte');  //anfordern des neues Paketes
     END;

END;

also an synchros hab ich halt nur eine am anfang und eine am ende des Threads. Des weiteren läuft das Programm erstmal nur mit einem Thread, also ohne Paralleles arbeiten, wie das Standartprogramm.
Mechanische Bremsen sind keine Vorhanden, da kein Festplattenzugriff erforderlich ist.

Ich lad mal ne Server Version, den normalen Client und den Thread Client komplett hoch, falls der Code oben nicht reicht, oder wer dran interessiert ist^^.

vielen dank für die schnelle Hilfe :)

Gruß McLay

[canonmclay]

keiner mehr ne idee :S

[ULIK]

Probiers halt mal aus, ob's an dem Synchronize liegt: Zeilen auskommentieren und dann messen.
Ansonsten: Probiers erst mal ohne Thread-Priority Spielereien und spendier dem Code am Beginn und am Ende der Execute Methode mal etwas Code zur Zeitmessung (GetTickCount)
Generell: nicht vermuten wo es langsam ist, sondern messen!

Grüße,
Uli

[jaenicke]

Naja, was du machst ist ja explizit nicht mehrere Threads parallel laufen zu lassen, sondern nach dem Ende eines Threads den nächsten Datensatz anzufordern.

Du rechnest also weiter hintereinander, nicht parallel, nur dass die Threadsynchronisierung dazukommt. Das kann nur länger dauern.

Zudem blitzen die Threads nur kurz auf, die sind bei mir in dem Beispielprogramm nach vielleicht einer Sekunde jeweils fertig. Das macht auch nicht ganz so viel Sinn.

Besser wäre, wenn du gleich mehrere Aufträge verteilst, damit der Thread auch ein bisschen was zu tun hat und außerdem auch mehrere Threads parallel laufen lässt. Stichwort Threadpool zum Beispiel.
Außerdem solltest du die Zuweisung an einen bestimmten Kern weglassen. Windows verteilt das in der Regel schon am besten alleine.

@ULIK:
Wozu ins Blaue daneben raten, wenn du im Quelltext doch schnell sehen kannst, dass erst in ThreadDone der nächste Datensatz angefordert wird usw.?

[ULIK]

Zitat:

Zitat von jaenicke (Beitrag 1105177)

@ULIK:
Wozu ins Blaue daneben raten, wenn du im Quelltext doch schnell sehen kannst, dass erst in ThreadDone der nächste Datensatz angefordert wird usw.?

Indem ich mir den Quellcode nur schnell am Morgen angeschaut hab? :wink:
Mir ging's eigentlich hauptsächlich darum, daß man bei Performanceproblemen halt erst mal messen sollte und wenn der TE schon die Synchronisation erwähnt, dann halt mal ausprobieren und schauen, ob es das ist.

Grüße,
Uli

[Uwe Raabe]

Delphi-Quellcode:

SetThreadAffinityMaskByID(getcurrentthreadid,1);

Dir ist schon klar, daß das Create im Kontext des Hauptthreads aufgerufen wird? Der obige Befehl wirkt sich somit lediglich auf den Hauptthread aus und nicht auf den des gerade erzeugten TThread-Objekts.

Du kannst aber auch mal testen, wie das Verhalten ist, wenn du die beiden Synchronize-Aufrufe auskommentierst. Damit könnte man eventuell die Thread-Synchronisation als Bremse ausschließen.

Nebenbei wichtig: welche Delphi-Version nimmst du?

[canonmclay]

Zitat:

Zitat von Uwe Raabe (Beitrag 1105218)

Delphi-Quellcode:

SetThreadAffinityMaskByID(getcurrentthreadid,1);

Dir ist schon klar, daß das Create im Kontext des Hauptthreads aufgerufen wird? Der obige Befehl wirkt sich somit lediglich auf den Hauptthread aus und nicht auf den des gerade erzeugten TThread-Objekts.

Du kannst aber auch mal testen, wie das Verhalten ist, wenn du die beiden Synchronize-Aufrufe auskommentierst. Damit könnte man eventuell die Thread-Synchronisation als Bremse ausschließen.

Nebenbei wichtig: welche Delphi-Version nimmst du?

>achso ich dachte man musst das im create nutzen... naja ich habs mal weggemacht
>auch das ausklammern der synchros hat keinen effekt auf die geschwindigkeit
>ich gurke auf einer version 6 rum...

Zitat:

Zitat von jaenicke (Beitrag 1105177)

Naja, was du machst ist ja explizit nicht mehrere Threads parallel laufen zu lassen, sondern nach dem Ende eines Threads den nächsten Datensatz anzufordern.

Du rechnest also weiter hintereinander, nicht parallel, nur dass die Threadsynchronisierung dazukommt. Das kann nur länger dauern.

Zudem blitzen die Threads nur kurz auf, die sind bei mir in dem Beispielprogramm nach vielleicht einer Sekunde jeweils fertig. Das macht auch nicht ganz so viel Sinn.

Besser wäre, wenn du gleich mehrere Aufträge verteilst, damit der Thread auch ein bisschen was zu tun hat und außerdem auch mehrere Threads parallel laufen lässt. Stichwort Threadpool zum Beispiel.
Außerdem solltest du die Zuweisung an einen bestimmten Kern weglassen. Windows verteilt das in der Regel schon am besten alleine.

> naja ich wär erstmal froh, wenn das mit einem Thread vernünftig läuft, daher lasse ich bisher nur einen laufen ;)
> ich möchte ja, das erst nachdem ein Paket bearbeitet wurde, der Server kontaktiert wird, und ein neues Paket angefordert wird, demnach muss ich warten bis der thread fertig ist. Außerdem, macht eine threadsynchronisierung einen unterschied von fast 14 sek aus? :o
>Zu deinem PC: was für eine CPU hast du 0o. Im normalen Programm schaff ich ein Paket in ca. 7sek, mit einem Thread ca. 20 sek. (Dual - Core E6300 mit 1,86GHz, bei nem Kumpel 2,8GHz ca. 4 und 12 sek.). Von daher wenn ich die Pakete größer mache, dann muss ich ja 81.450.625 Schleifendurchgänge Rechnen, anstatt ca. 800.000 ... das dauert dann viel zu lange...

[shmia]

Mal so rein grundsätzlich:
Bei reinen Rechenthreads darf man maximal so viele Thread benützen, wie unabhängige CPU-Kerne im System vorhanden sind.
Beispiel:
4 logische Cores (Hypherthreading), 2 physische Cores
Hier darf man maximal 2 Rechenthreads verwenden.
Würde man 4 Threads verwenden, dann würde zwar jeder logische Core voll ausgelastet werden, die Gesamtperformance wäre aber schlechter als bei nur 2 Threads.

[canonmclay]

klingt logisch^^... ich hab ja 2 "echte" kerne... aber es fluppt halt nichtmal bei einem Thread :/

[SirThornberry]

Bei dir ist ganz klar das syncronize schuld.
Und wenn du nur einen Thread hast ist auch klar das es langsamer ist. Denn neben deinem einen Thread gibt es ja immer noch den Hauptthread der auch ab und an Rechenzeit braucht für die Darstellung etc.
Aber an deinem Quelltext ist ganz klar das Syncronize als Falschenhals auszumachen. Poste doch lieber Nachrichten an den Hauptthread oder stopf den Status in eine Variable die vom Hauptthread in Regelmäßigen Abständen abgefragt wird. Das ist alle mal schneller als ein syncronize.

[canonmclay]

synchro KANN gar nicht schuld sein, denn dann müsste das ja 14 sek brauchen um in dieser zeit 2 mal zu aktualisieren, und das wäre ein wenig viel oder?

Außerdem habe ich das testweise mal auskommentiert und es hat sich nichts verbessert...

der hauptthread kann ja gar nicht so viel ziehn, außerdem ist meine cpu auslastung (task manager) bei genau 50%, also müsste der hauptthread ja extrem viel ziehn, obwohl der ja gar nix macht...

[canonmclay]

so ich gebs auf^^... leider hat keiner der denkansätze mehr was ergeben (ich hab sogar meinen inkompetenten ex-infolehrer gefragt, der hat mich mit fragezeichen in den augen angeschaut, als ich was von Threads erzählt habe...)

fazit: ich versuch dieses Progi mit c++ und werde mich da mal einarbeiten ;)


vielen Danke für eure hilfe :-D

greez McLay

[Aphton]

Lol, du bist lustig.
Du denkst mit c++ wird das anders? Nicht die Programmiersprache ist schuld, sondern der, der sie falsch verwendet!

[ULIK]

Zitat:

Zitat von canonmclay (Beitrag 1105545)

so ich gebs auf^^... leider hat keiner der denkansätze mehr was ergeben (ich hab sogar meinen inkompetenten ex-infolehrer gefragt, der hat mich mit fragezeichen in den augen angeschaut, als ich was von Threads erzählt habe...)

fazit: ich versuch dieses Progi mit c++ und werde mich da mal einarbeiten ;)


vielen Danke für eure hilfe :-D

greez McLay

Hast Du denn jetzt schon mal die einzelnen Zeiten gemessen?! Wie lange [ms] z.B. braucht denn die Execute Methode?
Und vor allem: wie oft wird denn der Thread gestartet? Zähl das doch mal mit.


Grüße,
Uli

[canonmclay]

also für einen ganz durchlauf der knacke funktion werden ca. 18 sek benötigt.

die Zeit bis vor dem ersten synchro ist nicht messbar (zu klein, wird 0 ausgegeben)

die zeit für den ersten synchro ist 0,0004 sek

die zeit für das durchlaufen der while schleife (damit man nicht umblättern muss hier nochmal der code... :) )

Delphi-Quellcode:

 queryperformancecounter(zeit1);
   abc:='   ';//Das sind die ERSTEN Acsii-Zeichen (3x leer) mit denen begonnen wird

   while length(abc)<4 do
     begin
       if suchwort=MD5Print(MD5String(ersterbuchstabe+abc)) then
         begin
           g:=true;
           result:=abc;
           break;
         end; // if suchwort

       abc:=strhoeher(abc);
     end; // while

  queryperformancecounter(zeit2);
  zeitberechnen((zeit2-zeit1),ges);
  showmessage(ges);

dauert ca. 18 sek. also muss hier ja der fehler liegen. Da diese Stelle aber 1 zu 1 übernommen wurde aus dem Programm ohne Threads, weiß ich halt echt nicht mehr weiter.


der thread wird einmal gestartet (hab mit process explorer nochmal nachgeschaut :) ), also an zu vielen threads wirds eher nicht liegen... und halt sobald er fertig gelaufen ist, wird der nächste angestoßen.


zu dem c++: ich wollt das erstens schon immer mal lernen (hab hier n einführungsbuch rumfliegen^^), und man kann damit auch dann das ganze für die grafikkarten (CUDA) programmieren ;). Zudem ist das denk ich mal ne ganz gute fingerübung mal n progri in eine andere sprache zu übersetzen :P. Zuletzt ist c++ in meinem späteren Beruf eher wichtig, als das anwenderorientierte delphi, von daher tue ich mir in dem Bereich direkt einen gefallen ;). Und außerdem, wenn das mit c++ besser läuft, werde ich versuchen (kA ob das geht, aber heutzutage ist ja alles möglich :P), die Rechenroutine mit den threads (wer weiß villt klappts damit ja doch besser :) ), mit dem Delphi projekt zu verbinden, sodass ich die Server - Client aplikation weiterhin nutzen kann, die ich extreeeeeemst praktisch finde bei delphi :). Außerdem keine sorge, ich werde auch weiterhin delphi nutzen, eben aufgrund der einfach zu gestaltenden oberflächen ;)

Zitat:

Zitat von Aphton (Beitrag 1105546)

Lol, du bist lustig.
Du denkst mit c++ wird das anders? Nicht die Programmiersprache ist schuld, sondern der, der sie falsch verwendet!

bevor ich mich auf die Anklagebank setzte und mir anhören muss, das ich zu doof bin das zu programmieren, bitte ich den ankläger um einen evtl. anderen Lösungsvorschlag :)

PS: JA ich mag smileys :P

[jaenicke]

Ich muss das mal mit Delphi 6 probieren. Denn mit Delphi XE kann ich keine nennenswerten Unterschiede zwischen den Versionen feststellen.

Kannst du das bitte einmal inkl. deiner Zeitmessung anhängen? Ich würde dann einmal einen virtuellen PC mit Delphi 6 nehmen und es heute Abend dort testen, vielleicht liegt es ja an der Delphiversion...

[Jumpy]

Zitat:

der thread wird einmal gestartet (hab mit process explorer nochmal nachgeschaut :) ), also an zu vielen threads wirds eher nicht liegen... und halt sobald er fertig gelaufen ist, wird der nächste angestoßen.

Ich hab mich in Threads bisher erst eingelesen und warte noch auf eine sinnvolle Aufgabe, das mal einzusetzen, aber obige Aussage kommt mir komisch vor.

Wenn (ausser dem Hauptthread) nur ein Thread da ist: Wo ist da der Sinn (außer man will Fortschrittsbalken steuern oder ähnl.) Müsste man denn nicht mindestens zwei machen, die parallel Arbeiten? Wie rechenintensiv müssen Aufgaben sein (nicht sehr, ich weiß, aber e bissle doch schon, oder?), dass Programmierung mit Threads trotz es Overheads effektiver wird als ohne?

[jaenicke]

Also erstens geht es auch darum, dass die GUI noch reagiert, aber in diesem Fall ist es nur ein Thread, weil er es damit erst einmal testen wollte, das hatte er glaube ich irgendwo schon geschrieben.

[canonmclay]

du nimmst mir die worte aus dem mund jaenike, besser hätte ichs nicht ausdrücken können ;)

Ich hab jetzt mal eine Version mit den Zeitmessungen um die while schleife angehangen. Wenn die Zeitmessung woanders stattfinden soll, einfach

Delphi-Quellcode:

queryperformancecounter(zeit1);

//...code...

queryperformancecounter(zeit2);
zeitberechnen((zeit2-zeit1),ges);
showmessage(ges); //Anzeige

benutzen :)

könnte das villt auch ein betriebssystem Problem sein? Also ein mit Delphi 6 kompiliertes Projekt auf einer Win 7 64 Maschine...

[ULIK]

Also, hab es gerade mal in einer VM mit Delphi 7 und unter Windows 2000 laufen lassen: Große Unterschiede haben beide Varianten nicht gezeigt: beides dauerte pro Durchlauf so um die 11 Sekunden.
Was das Ganze aber auf Clientseite sehr beschleunigt hat: FastMM einbinden! Dadurch ist die Laufzeit auf knapp 6 Sekunden runter. Und nachdem ich das Ganze auch noch durch den Profiler gejagt hab: die MD5 Unit ist diejenige, wo die Zeit verbraten wird (in den Stringoperationen dort).

Was die unterschiedlichen Laufzeiten betrifft: stopp auf deinem Rechner doch mal alle Rechenzeitfresser: MP3 und Videosoftware oder Chats (oder was Du sonst noch so am Laufen hast). Hat das denn eine Auswirkung?


Grüße,
Uli

[canonmclay]

kannst du villt die von dir Kompilierten dateien hochladen? fänd ich super, dann kann ich das mal hier ausprobieren... dann sollte ich mir mal ggf. ne neue delphi version zulegen ;) ... gibt es sowas für schüler für lau :P ?

[ULIK]

FastMM: Click auf den Namen in meinem letzten Betrag und Du wirst auf die FastMM Seite geleitet. FastMM funktioniert auch mit Delphi 6!
Hochladen geht heute nicht mehr: VM hat schon Feierabend :wink:

[canonmclay]

also das einbinden der unit hat auch bei mir 6 sek gebracht :O danke dafür!

Das die md5 unit die Zeit zieht, war zu erwarten, da dort ja der hash gebildet wird, was ja eine sehr rechenintensive aufgabe ist (zumindest bei 800.000 mal pro paket...)

[jaenicke]

Zitat:

Zitat von canonmclay (Beitrag 1105689)

kannst du villt die von dir Kompilierten dateien hochladen? fänd ich super, dann kann ich das mal hier ausprobieren...

Die mit XE kompilierten Versionen liegen im Anhang (als 7zip, da zip oder rar mehr als doppelt so groß wäre...).
Auf diesem nicht ganz so starken PC hier: Laufzeit ca. 3 Sekunden, dabei 0,1 Sekunden langsamer beim Thread.

Zitat:

Zitat von canonmclay (Beitrag 1105689)

dann sollte ich mir mal ggf. ne neue delphi version zulegen ;) ... gibt es sowas für schüler für lau :P ?

Nein, aber es gibt die XE Starter für nur 150€ und die Schülerversionen (die keine Weitergabe der Exen erlauben, auch nicht als Freeware) für ab ca. 100€.

[canonmclay]

ich glaube ich seh ein licht am horizont :coder2: :

es liegt warscheinlich am compiler. Ich habe mal den Original Client benutzt (ich habe in der schule den Server geschrieben, den client habe ich dann mit den Threads erweitert) und daher immer mit meinem alten Delphi 6 neu Kompeliert. Wenn ich nämlich den Original Client benutze, schafft mein rechner ein Paket in 4 sek. Kompiliere ich den Original - Client neu, so benötigt dieser dann auch genau die gleiche zeit, wie der Thread Client. :wall::wall::wall:

oh man so viel :S

danke fürs hochladen jaenicke =), damit klappts bei mir Perfekt!


ebenfalls vielen vielen dank für die vielen Konstruktiven Vorschläge!! :D

greez McLay

[jaenicke]

Noch so nebenbei: Shortstrings sind veraltet und nur aus Kompatibilitätsgründen (zu Delphi 1) noch da. Deshalb lassen sich deine Programme auch nicht direkt ohne Änderungen mit XE kompilieren. Nimm besser richtige Strings soweit möglich. ;-)