Wie spart man richtig Rechenzeit mit Threads?

Gigaz

Skym0sh0 schrieb:

Das ist doch derselbe Code nur dass die Locks auskommentiert sind. Und ganz klar ist dann auch, dass der Code schneller läuft. Weil es echt parallel ist und nicht wie bei deinem gelockten Beispiel sequentiell.

Zu deiner Anmerkung mit den Daten kopieren:
Ja, es kommt drauf an was für ein Problem du berechnest. Wenn in jedem Schritt alle Threads/Prozesse untereinander Kilo-/Mega-/Giga-byteweise Datenaustauschen müssen, dann wird das schlecht anders gehen. Wenn es aber nur (d)eine Implementierungsungenauigkeit ist, dann könnte man da auch drum herum kommen.

Aber das kommt auf das Problem an.

Der Unterschied zwischen beiden Programmen ist: ss ist in Version 2 ein Array vom Typ args und jeder Thread i bekommt sein eigenes ss[i]. Würde ich das nicht so machen, dann würden die Threads, während sie parallel laufen, miteinander wechselwirken und der Input wäre falsch. Allerdings muss ich auch meinen Input für die Funktion für jeden Thread kopieren, und das ist es, was ich nicht haben will.

Gigaz

Gast3 schrieb:

bitte nicht wieder deinen Quelltext posten - das ist keine Beschreibung und es ist auch einfach ein schlechtes Beispiel - oder verstehst du nur einfach nicht das ein Pointer auf deine Daten deine Kopieraktion unnötig macht?

Ich schätze, das war das Problem. Jetzt funktioniert das, was ich haben will. Hätte man drauf kommen können. Ich bedanke mich.

-printf ist nicht unbedingt Thread-Safe
-printf braucht laenger als das addieren
-moeglichst IO jeglicher Art in Rechen-Threads vermeiden

ich hoffe dein Code ist wirklich nur ein Test und deine reale Anforderung sieht voellig anders aus

dein

time_spent = (double)(end - begin);

ist ja nur die Zeit fuer das Thread-Erzeugen, erst nach der Join-Schleife kommt die Rechen-Zeit, die Zeit fuer 10x pthread_create wird wohl kaum bemerkbar sein

Gigaz

Also mein Programm funktioniert inzwischen im Wesentlichen.
Leider scheint der Gewinn an Rechenpower praktisch Null zu sein und ich verstehe einfach nicht, wieso. Ich habe 4 Kerne in meinem Rechner.

Das Programm berechnet, wie Licht an einem Schichtsystem reflektiert wird. Ich skizziere hier nur mal den Code:

typedef struct{
     Schichtdicken, Rauigkeiten, Optische Eigenschaften, Polarisation, usw.
        } RIpack;

typedef struct{
    double *Einfallswinkel
    RIpack *Input
    //Output
    double *R;
    } RI;

void* Reflektivitaet(void *arg){
Hier steht die Berechnung drin.
Dauer pro Ausführung ca. 1ms oder so, hängt stark vom Input ab.
}

int main(){

    RIpack Input_Paket
    Der Input wird gefüllt

    RI Thread_Paket[Threadzahl]
    Start der Zeitmessung

    für alle Threads i{
         Thread_Paket[i].Einfallswinkel=&Einfallswinkel[i]
         Thread_Paket[i].Input=&InputPaket
         Thread_Paket[i].R=&R[i]
         pthread_create (Thread+i, NULL, Reflektivitaet, (void*)&Thread_Paket[i])
     }

Threads wieder zusammenfügen
Ende der Zeitmessung

Die berechnete Reflektivität in ein Output-File schreiben.
}

Für das Ergebnis der Zeitmessung macht es leider absolut keinen Unterschied, ob ich die Threads noch innerhalb der Schleife wieder zusammenführe (Dann werden sie strikt nacheinander ausgeführt) oder ob sie parallel laufen. Das ist genau das Gegenteil von dem, was ich erwartet habe.

Aha

Gigaz

Gigaz schrieb:

Also mein Programm funktioniert inzwischen im Wesentlichen.
Leider scheint der Gewinn an Rechenpower praktisch Null zu sein und ich verstehe einfach nicht, wieso. Ich habe 4 Kerne in meinem Rechner.

Vergesst es wieder, ich bin dahinter gekommen. Das Zusammenfügen der Threads kostet in allen Fällen 10 Mal mehr Rechenzeit als die Berechnung der Reflektivität.

Skym0sh0

Wie schon mehrmals gesagt worden ist:

Parallelität lohnt sich erst ab einem gewissen Rechenaufwand. 1, 2 oder auch 50000 (mehr oder weniger atomare) Rechenoperationen gehen der CPU während dem Kaffeetrinken in der Badewanne immer noch zupp von der Hand.

Wenn dein sequentielles Programm deine Reflektionsberechnungen schon innerhalb von 2-3 Sekunden schafft, dann bringt es auch nix mit 10 Threads/CPUs/Kernen dadrauf zu kloppen. Das amdahl'sche Gesetz wäre an der Stelle vielleicht interessant und damit auch der Gustaffson.

Das Zusammenfügen der Threads kostet in allen Fällen 10 Mal mehr Rechenzeit als die Berechnung der Reflektivität.

wie in allen Post vorher schon geschrieben kommt es da nur auf die Details an - einfach Threads auf und fertig ist nicht die Lösung

aber mir fallen noch so Sachen auf:

was ist denn die Auflösung von clock()? weil du hier von Millisekunden sprichst
"Dauer pro Ausführung ca. 1ms"

wie sieht denn bitte jetzt mit den richtigen Daten dein ganzer, ablauffähiger Source aus - wenn du deine Daten einfach in zu kleine Happen zerlegst helfen dir die Threads null

falls du permanten Relefektionen berechnen willst kann du die Threads auch vorbereiten und ständig mit Daten fuellen - dann sparst du die Start-Zeit, verändert aber den Aufbau deines Programmes - und unbrauchbar wenn du nur ein paar Daten berechnen willst - warum willst du den überhaupt optimieren? oder sehen wir IMMER noch nicht deinen echten Datenumfang

ist das eine optimierte oder unoptimierte Version deines Programmes - schon zu viele Leute haben tagelang ihre Debug-Builds mit Benchmarks gequaelt

und noch viel wichtiger

sind das wirklich alles Zeiger in deinen Datenstrukturen, Cache-Misses/Alignment usw. können auch ganz schön kosten - da solltest du erstmal drann

Erst gibst echten Code mit Pseudo-Berechnung
=>(1)OHNE Angabe des Umfanges/Aufbaus deiner echten Daten/Algorithmus

dann gibt es Pseudo Code mit Pseudo-Berechnung
=>(2)OHNE Angabe des Umfanges/Aufbaus deiner Daten/Algorithmus

(3)OHNE die Angabe des Umfanges/Aufbaus deiner echten Daten/Algorithmus
kann hier keiner gute Tips geben - das ist wie so wie den PC von der Oma übers Telefon reparieren

deine Fragen/Antworten/Source wirken ein wenig bastellig und unkoordiniert - du beantwortest nicht eine einzige Frage sonder schreibst nur Statusupdates

Die ist: Willst du es schneller - oder ist dir das egal
falls du es schneller willst können wir
(4)OHNE die Angabe des Umfanges/Aufbaus deiner echten Daten/Algorithmus
leider nicht wirklich richtig helfen

Gigaz

Die Reflektivitäten zu berechnen ist tatsächlich nur ein Unterprogramm, sie sollen später auch an gemessene Daten gefittet werden können.
Ich dachte mir erst, ich gebe einfach jedem Datenpunkt seinen eigenen Thread, aber das war eine schlechte Idee, wie ich gelernt habe. Ich muss und kann auf einer viel höheren Ebene parallelisieren. Also ob du's glaubst oder nicht, mir hat dieser Thread und auch du schon sehr geholfen.

otze

Gigaz schrieb:

Also ob du's glaubst oder nicht, mir hat dieser Thread und auch du schon sehr geholfen.

Aber denk doch einmal an die Leute, die hier Zeit für dich opfern - je weniger informationen du gibst, desto mehr energie müssen sie investieren. Am Ende bleibt ihnen dann dein Name ein wenig schlechter in Erinnerung als er vorher war.

(5)OHNE die Angabe des Umfanges/Aufbaus deiner echten Daten/Algorithmus
kann dir keiner RICHTIG helfen - nur dein Datenumfang, Inhalt und Algorithmus ist entscheiden wie ein Performanzoptimierung aussieht - sei es jetzt mit Threads - aber trotzdem anderes als du es probierst oder auch einfach nur durch einen effizienteren Algorithmus, aber das scheint dich ja wirklich NICHT zu interessieren, oder du VERSTEHST es einfach nicht

btw: dein letzter Post enthielt wieder nur eine Statusberich - bisher 0 Antworten, sehr nervig

Gigaz

Ich finds ja nett dass ihr mir helfen wollt. Hier muss aber niemand Energie in irgendwas investieren, ihr macht das ist alles freiwillig. Also ist der Vorwurf, dass ich euch nerve oder eure Zeit verschwende, erstens unhöflich und zweitens völlig aus der Luft gegriffen. Ich wünsche einen guten Tag.

Skym0sh0

Jop, ich find den Vorwurf auch was halt los. Das schlimmste, was dir passieren kann ist, dass man dir sagt, dass dir nicht zu helfen ist ohne weitere Informationen. Und wer damit leben kann (was du ja offensichtlich kannst), dem passts. Und wer nicht, muss mehr Informationen rausgeben. Und gezwungen wird hier auch niemand etwas zu schreiben.

Oder gabs in den Nutzungsregeln 'ne Klausel ála "mindestens ein Beitrag pro Tag und Thread" ?

SeppJ

Skym0sh0 schrieb:

Oder gabs in den Nutzungsregeln 'ne Klausel ála "mindestens ein Beitrag pro Tag und Thread" ?

Nein, aber das was otze als Folge solchen Verhaltens prophezeite, nämlich dass man ganz schnell einen Ruf als Hilfsresistenter bekommt, stimmt.

Swordfish

wtf? ihr lest die Kacke noch?

hustbaer

Gigaz schrieb:

Hier muss aber niemand Energie in irgendwas investieren, ihr macht das ist alles freiwillig.

Rein objektiv vollkommen richtig. Psychologisch betrachtet aber eine totale Sackgasse.

Gigaz schrieb:

Also ist der Vorwurf, dass ich euch nerve oder eure Zeit verschwende, erstens unhöflich und zweitens völlig aus der Luft gegriffen.

Sorry, aber das ist einfach nur Blödsinn.
Ich habe aber nicht vor noch mehr meiner Zeit damit zu verschwenden zu versuchen es dir zu erklären. Ich weiss aus Erfahrung dass das wenig bringt. Denk nochmal drüber nach, vielleicht kommst du von selbst drauf wieso.

hustbaer

Skym0sh0 schrieb:

Wenn dein sequentielles Programm deine Reflektionsberechnungen schon innerhalb von 2-3 Sekunden schafft, dann bringt es auch nix mit 10 Threads/CPUs/Kernen dadrauf zu kloppen. Das amdahl'sche Gesetz wäre an der Stelle vielleicht interessant und damit auch der Gustaffson.

Wieso sollte man eine Berechnung die "nur" 2-3 Sekunden dauert (was auf die Rechenleistung heutiger Computer bezogen ja wohl eine kleine Ewigkeit ist) nicht durch Parallelisierung beschleunigen können?
Video-Decoder parallelisieren das Dekodieren einzelner Frames, das dauert weniger als 40ms. Funktioniert 1A.

Wieso sollte man eine Berechnung die "nur" 2-3 Sekunden dauert (was auf die Rechenleistung heutiger Computer bezogen ja wohl eine kleine Ewigkeit ist) nicht durch Parallelisierung beschleunigen können?

sehe ich auch kein Problem drinn - wir wissen nur eben immer noch nicht was die echte Datenmenge ist (was auch immer so schwer daran sein soll das kurz zu posten), daher ist die Kommunikation hier eher ein Ratespiel als Wissensvermittlung