3. Prozessor richtig auslasten

Prozessor richtig auslasten

  • Administrator

    Pikkolini schrieb:

    An dem Betriebssystem wird es wohl kaum liegen, oder doch?

    Das ist durchaus eine meiner Vermutungen. Allerdings werden wohl auch noch andere Komponenten abweichen. Du kannst nicht auf zwei völlig unterschiedlichen Computern Messungen durchführen und dann nur die CPU vergleichen. Es ist schon schwierig genug auf dem gleichen Computer sinnvolle Messungen zu erzielen. Das was du gemacht hast, bringt überhaupt gar nichts. Es dürfte ziemlich schwer werden, die genaue Ursache zu ermitteln.

    Grüssli

    0
  • X

    Hallo

    In deinem Beispiel sind die Berechnung von einander unabhängig. Für möglichst parallele Ausführung sollte während der Berechnung möglichst kein System-Call (egal ob IO oder Mutex) ausgeführt werden

    (Pseudo-)Code sagt mehr als 1000 Worte:

    //Pseudo-Code:
void worker_proc(DataType * ptr, int begin, int end)
{
  for(int i = begin, i < end; ++i)
  {
    ptr[i] = do_something(ptr[i]);
  }
}
...
DataType myData[10000];
...
ThreadType thread1 = thread_create(&worker_proc, myData, 0, 2500);
ThreadType thread2 = thread_create(&worker_proc, myData, 2500, 5000);
ThreadType thread3 = thread_create(&worker_proc, myData, 5000, 7500);
ThreadType thread4 = thread_create(&worker_proc, myData, 7500, 10000);
thread_join(thread1);
thread_join(thread2);
thread_join(thread3);
thread_join(thread4);
...
fwrite(myData, sizeof(DataType), sizeof(myData) / sizeof(DataType), outputFile);
...

    Ich will OpenMP nicht grundsätzlich schlechtreden, aber ob es für jeden Algorithmus und jede Situation die beste Lösung automatisch findet, wage ich zu bezweifeln. Die Anzahl der Threads hängt von den CPUs ab, die man aber unter den meisten Systemen auch auslesen kann.

    cu

    PS: Die Implementierung der iostreams auf MSVC benutzt locks bei jedem einzelnen geschriebenen Zeichen (->unerträglicher Overhead). Ich kenne zwar die Implementierung der Mutexe unter Windows nicht, aber jeder Kernel-Call auf einer CPU kann die anderen CPUs anhalten. Durch die Verwaltung von 8 Kernen statt etwa nur 2 braucht das Umschalten im Scheduler vielleicht wirklich mehr Zeit ist daher unter Umständen langsamer ... aber es ist seeeehhhr schwer genau zu wissen was wirklich passiert ... alles nur Spekulation 😃

    Fazit: Wenn man eine IO-Operation mit einem einzigen Aufruf durchführen kann, dann immer gleich so machen und nicht jedes einzelne Byte schreiben..., und was Windows anbelangt: Jede Version ist irgend wie anders :p. Auf der 64-bit Maschine muss dein 32-bit Programm erst durch einen eigenen Kompatibilitätslayer durchrufen, bei XP geht's direkt 😉

    0
  • ?

    Pikkolini schrieb:

    An dem Betriebssystem wird es wohl kaum liegen, oder doch?

    Was glaubst Du denn "wo" das Multithreading realisiert wird? Richtig im Betriebssystem (Kernel). Ist es daher zu erwarten das das Betriebssystem Einfluß auf das Verhalten des Multithreasding hat? Aber sowas von...

    0

  • loks schrieb:

    Was glaubst Du denn "wo" das Multithreading realisiert wird? Richtig im Betriebssystem (Kernel). Ist es daher zu erwarten das das Betriebssystem Einfluß auf das Verhalten des Multithreasding hat? Aber sowas von...

    Ja das ist klar aber
    1. Habe ich nur ganz selten Multithreading benutzt, kann man aber auch aus meinen vorherogen Posts rauslesen
    2. Wieso sollte Microsoft Windows 7 so verkorksen, dass irgendwelche Programme deswegen nicht mehr so schnell laufen, wie z.B. auf Windows XP? Ich denke aber, dass es an dem 64-Bit System liegt.

    So ich wollte das jetzt so wie xor realisieren, und habe mir die Threads die boost Library genommen. Allerdings spuckt der Linker im den Fehler aus, dass er die Datei "libboost_thread-vc100-mt-s-1_43.lib" nicht finden kann, obwohl ich die libs richtig gelinkt habe (egal ob Debug oder Release). Das liegt aber daran, dass diese Datei nicht exisitiert sondern nur diese hier:
    libboost_thread-vc100-mt-1_43.lib
    libboost_thread-vc100-mt.lib
    libboost_thread-vc100-mt-gd-1_43.lib
    libboost_thread-vc100-mt-gd.lib

    Boost habe ich installiert, indem ich die bjam.exe einfach ausgeführt habe.
    Liegt der Fehler jetzt daran, dass boost nicht richtig installiert wurde, und ich das nochmal stundenlang neu installieren muss, oder gibt es eine andere Erklärung und Lösung dafür?

    0
  • L

    Ich kenne mich mit Windows überhaupt nicht aus, nehme aber an, dass das zusätzliche "s" im Namen auf "static hindeutet. Linkst du denn statisch? Hast du eine statische Version von boost-thread erstellt?

    0

  • Ja ich linke es statisch, und dadurch, dass nur statische libs erstellt wurden und im sourcecode nichts von dynamischen libs steht, denke ich mal, dass ich auch die statische Version erstellt habe.
    Allerdings hatte ich bei der Installation in der Konsole einiger Fehler, die ich bis jetzt ignoriert hatte. Vielleicht liegt es daran. Außerdem habe ich gelesen, dass boost standardmäßig nur minimal installiert wird, damit es schneller geht. Ich versuche es jetzt mal komplett zu installieren.

    0

  • Hmm, ich habe es jetzt so gemacht, wie ich beschrieben habe und das Problem ist das selbe. Ich habe genau die lgeichen Dateien bekommen wie vorher. Kann jemand mal bitte erklären, wie er die boost lib installiert hat? Wäre echt nett und vielleicht sehe ich dann, was noch gefehlt / nicht gestimmt hat.

    0
  • ?

    loks schrieb:

    Pikkolini schrieb:

    An dem Betriebssystem wird es wohl kaum liegen, oder doch?

    Was glaubst Du denn "wo" das Multithreading realisiert wird? Richtig im Betriebssystem (Kernel). Ist es daher zu erwarten das das Betriebssystem Einfluß auf das Verhalten des Multithreasding hat? Aber sowas von...

    Wie wärs mal mit Fakten?

    0

  • So, ich habe jetzt nochmal ein paar Parameter bei der Installation geändert und jetzt habe ich auch die statischen Libs. Andere Alternative wäre natürlich gewesen, die einfach dynamisch zu linken.

    0

  • Ich habe nochmal 2 Fragen :p

    1. Nachdem ich Boost eingebunden habe, spuckt der Debugger immer das hier aus:

    Eine Ausnahme (erste Chance) bei 0x7c812afb in Random.exe: Microsoft C++-Ausnahme: boost::exception_detail::clone_impl<boost::exception_detail::bad_alloc_> an Speicherposition 0x0012feec..
Eine Ausnahme (erste Chance) bei 0x7c812afb in Random.exe: Microsoft C++-Ausnahme: [rethrow] an Speicherposition 0x00000000..

    Das Programm funktioniert trotzdem.
    Wie bekomme ich das weg, oder kann man das problemlos ignorieren?

    2. Kann man einem Thread bestimmte Werte übergeben.
    Einen Thread erstellt man ja so:

    void thread() 
{ 
    std::cout << 1 << std::endl; 
} 

int main() 
{ 
  boost::thread t(thread); 
  t.join(); 
}

    (kurz aus highscore.de kopiert)
    Dabei können in Zeile 8 keine Parameter übergeben werden. Wie kann ich einem Thread dennoch bestimme Werte übergeben?

    0
Anmelden zum Antworten