Was manche wieder von euch schreiben...
Hoffentlich kann ich es jetzt mal richtig zusammenfassen:
- Wir können damit rechnen das wir in Zukunft eine immer stärker werdende Paralleität (an Cores) zu erwarten haben.
- Unsere derzeitigen Konzepte (ja auch Linux/Unix) gehen aber durch Threads eher von einer geringen Paralellität (leichtgewichtige Threads damit der Wechsel nicht teuer wird, ein Wechsel der auf vielen Kernen doch garnicht nötig wäre) aus.
Moderne Programme versuchen ja zurzeit bestimmte Dinge in Threads aufzuteilen um eine bessere Auslastung zu erreichen. Nachteile sind klar:
- Administrativer Overhead (Scheduler)
- Coding Probleme (Race Conditions)
Jetzt gehen wir halt mal einen Schritt weg und sagen... hmm wir haben hier 8 - 16 Kerne und wahrscheinlich wird die Anzahl der laufenden Anwendungen auch in diesem Bereich skalieren (Heimanwender). Warum überlassen wir also nicht einem Programm einfach komplett einen Kern.
Vorteile:
- geringer Aufwand (kein kompliziertes Scheduling mit verhungerten Prozessen möglich)
- höhere Performance(keine teuren Kontextwechsel zum Sichern der Register usw.)
Nachteile:
- geringere Parallelität
Vorallem wären dann ja auch wirklich die verschiedenen Ringe in der x86 Architektur unnötig, denn was der Prozess auf seinem Kern anrichtet hat ja erstmal keinerlei Auswirkungen auf das System. Kritisch werden erst Dinge wie I/O und halt Speicherzugriff, wobei moderne Prozessoren ja mit einem Sack voll Features daherkommen. Wenn es also jetzt möglich wäre einen riesigen Speicherblock dazu zu werfen und durch eine für alle CPUs zentrale MMU Zugriffe auf fremde Speicher zu untersagen... es könnte im Heimbereich aufjedenfall einen Leistungsschub geben.
Vom Coding her wird es sogar erheblich einfacher für die Programmier:
- Speicherverwaltung ändert sich eigentlich garnichts, wenn ich mit Ptr arbeite muss ich immernoch aufpassen, wenn nicht ist es auch egal :)
- Es gibt keine Race Conditions, ich muss nicht mehr Multithreading debuggen, Locks und Mutex werden wegfallen. (komplett auf den Heimanwender bezogen)
- Nachteile könnten sich wenn in Servern ergeben, da dort das Threading immernoch leichtgewichtig genug ist um Vorteile bei vielen kleinen Anfragen zu liefern. Aber da werden sich dann mit der Zeit entsprechende Möglichkeiten rauskristallisieren dies in den eigenen Programmen wieder zu ermöglichen.
Im Großen also eigentlich eine gute Idee. Jetzt wegen der Linux Unix Geschichte:
Auch Linux Unix kennen Kernel/Userspace, dort wird aber weniger Gebrauch vorallem vom Kernel selber davon gemacht. Der Linuxkernel ist halt IMMER im Kernelspace: ein Modul stirbt -> PANIC (tolle Architektur :p). Die Unicies haben Probleme mit Dingen wie BIG KERNEL LOCK: Grund für die Abspaltung von Dragonfly BSD, wobei afaik die Freebsdler da nachziehen, nur die Openbsdler sind da wohl mit der Performance weit unter Möglichkeit. Wie weit jetzt aber etwas skaliert hängt rein von der Anwendung ab, ich bin in der Lage für Linux Programme zu Schreiben die auf einem 1024 Core System schlechter performen als auf einem Single Core. Also bitte auch hier gilt nicht einfach nur nachblubbern.
Aha, du schlägst also vor alle Programme in Zukunft seriell auszuführen, damit sie nur auf einer CPU laufen?
Vor allem sinnvoll bei OpenMP/MPI-Programme die sehr von paralleler Ausführung profitieren.
Und was hindert einen Core auf dem ein bösartiges Programm läuft nun daran deine Festplatte mit Nullen zu überschreiben?
1) für den Consumer Bereich JA
2) MPI im Consumer Bereich? NEIN
3) habe ich geschrieben das IO kontrolliert werden muss? Leider wohl nicht genug, also ja IO muss sicherlich überwacht werden.
wodar schrieb:
--------------------------------------------------------------------------------
> Vorteile:
> - geringer Aufwand (kein kompliziertes Scheduling mit verhungerten
> Prozessen möglich)
Wenn man für jede Anwendung/Thread nen Core hat, verhungert beim normalen Konzept auch nichts und was da dann kompliziert sein soll, versteh ich auch nicht.
> - höhere Performance(keine teuren Kontextwechsel zum Sichern der Register
> usw.)
Kontextwechsel werden nur durchgeführt, wenn es notwendig ist - also mehrere Threads um einen Core kämpfen. Fällt also nur der Overhead für das Nachschauen in der Warteschlange an, den ich jetzt mal nicht als sooo hoch einschätzen würde, da im beschriebenen Fall immer nur ein Thread pro Core aktiv ist.
> Nachteile:
> - geringere Parallelität
Wenn man mal annimmt, dass, wie von einigen prognostiziert, die CPU- und GPU-Architektur verschmelzen, dürfte man in Zukunft Probleme bekommen, z.B. bei Spielen. Bei Video/Audio-En/Decoding oder Grafikbearbeitung dürfte es auch mau aussehen.
> Kritisch werden erst Dinge
> wie I/O und halt Speicherzugriff, wobei moderne Prozessoren ja mit einem
> Sack voll Features daherkommen. Wenn es also jetzt möglich wäre einen
> riesigen Speicherblock dazu zu werfen und durch eine für alle CPUs zentrale
> MMU Zugriffe auf fremde Speicher zu untersagen... es könnte im Heimbereich
> aufjedenfall einen Leistungsschub geben.
Wenn man ne MMU hat, die eh alle Speicherzugriffe kontrolliert, kann man auch gleich bei der Seitenverwaltung bleiben.
> Vom Coding her wird es sogar erheblich einfacher für die Programmier:
> - Speicherverwaltung ändert sich eigentlich garnichts, wenn ich mit Ptr
> arbeite muss ich immernoch aufpassen, wenn nicht ist es auch egal :)
> - Es gibt keine Race Conditions, ich muss nicht mehr Multithreading
> debuggen, Locks und Mutex werden wegfallen. (komplett auf den Heimanwender
> bezogen)
> - Nachteile könnten sich wenn in Servern ergeben, da dort das Threading
> immernoch leichtgewichtig genug ist um Vorteile bei vielen kleinen Anfragen
> zu liefern. Aber da werden sich dann mit der Zeit entsprechende
> Möglichkeiten rauskristallisieren dies in den eigenen Programmen wieder zu
> ermöglichen.
Ich kann auch in Python/Java/whatever programmieren, da ist auch vieles einfacher, aber schneller wird es dadurch nicht unbedingt.
Also ich weiß ja nicht...
Ich habe gerade geguckt.. hier laufen 32 Prozesse.
Warum brauche ich denn da soviele CPUs?
Die meisten dieser Prozesse brauchen praktisch überhaupt keine CPU Zeit.. nur ne Hand voll.
Es würde hier absolut garnichts bringen wenn ich mir hier nun 4 Cores reinpappe.. oder 8.. oder 16.. oder mehr. Der PC wird kein Stück schneller werden dadurch. Vll noch eher gebremst, da die Taktrate oft reduziert wird um Abwärme zu verringern.
Ich begrüsse natürlich Parallelität, allerdings sehe ich keinen wirklichen Nutzen darin, wenn es nichts bringt.
Und kommt mir nicht mit Videos kodieren. Das ist ein Spezialgebiet und wer das tun will kauft sich auch den passenden PC dazu.
Ich behaupte auch garnicht, dass jeder eine Multicore-CPU braucht - Browser, IM und bisl Office laufen auch noch wunderbar auf nem 5 Jahre alten Single-Core.
Ich behaupte, dass das vorgeschlagene Design ein netter Gedanke ist, aber im Vergleich zum Status Quo die Nachteile überwiegen.
Äh kleiner Zusatz:
Die Frage ist auch nicht, ob man mehr Cores wirklich braucht. Man wird mehr bekommen, da einzelne Cores nicht mehr wesentlich "schneller" werden und man in Sachen Geschwindigkeit eigentlich nur noch mit Parallelität weiterkommt. Beim Thema Stromsparen mag es anderst aussehen.
Die Schlüsselfrage in den nächsten Jahren ist, wie hole ich aus einer Multi/Manycore-CPU das Optimale heraus, wenn ich denn wirklich mal Leistung brauche.
Es geht hier vornehmlich um die Speicherverwaltung. Dein Vorschlag pro Programm einen Core bringt dabei eigentlich nichts, denn die Programme würden immer noch auf einen gemeinsamen Speicher zugreifen. Du brauchst immer noch den Speicherschutz gegen die Prozesse auf den anderen Prozessoren und Du musst auch immer noch auf Betriebssystemroutinen zugreifen und diese mit den anderen Prozessen teilen. Wenn z.B. ein Interupt von einem Bussystem ausgelöst wird, dann bremst das eben auch die anderen Anwendungen. Das kann man in modernen OS gar nicht verhindern.
Außerdem unterscheidest Du anscheinend Threads und Prozesse nicht. Bei mir laufen gerade nur wenige von mir gestartete Anwendungen, trotzdem aber ca. 30 Prozesse mit zusammen mehr als 200 Threads - und dabei bin ich gerade nicht sonderlich aktiv. Prozesse sind dabei Ressourcenfresser und Threads eher Ressourcenschoner, da sie parallel im gleichen Adressraum ablaufen. Du willst die Nebenläufigkeit abschaffen, was wohl kaum durchsetzbar sein dürfte. Die Anwender würden Dir die SOftware als nutzlos um die Ohren hauen. Bei mir hat zum Beispiel Firefox gerade 22 Threads, Skype 25, Word und Freecommander 7, Paint.Net 13, ... und das machen die nicht nur um die Software komplizierter zu machen.
Was der Wissenschaftler nun vorgeschlagen hat ist, dass große Teile des OS in die Anwendungen verlagert werden. Diese also eine eigene Ressourcenverwaltung implementieren. Dadurch würde die Parallelverarbeitung massiv steigen, man hätte genau das Gegenteil von Deinem Vorschlag. Dadurch würde die Anwendungen um ein Vieles komplexer, aber die Leistung würde durch die Parallelisierung steigen - zumindest theoretisch.
lalelu schrieb:
--------------------------------------------------------------------------------
> wodar schrieb:
> ---------------------------------------------------------------------------
> -----
> > Vorteile:
> > - geringer Aufwand (kein kompliziertes Scheduling mit verhungerten
> > Prozessen möglich)
>
> Wenn man für jede Anwendung/Thread nen Core hat, verhungert beim normalen
> Konzept auch nichts und was da dann kompliziert sein soll, versteh ich auch
> nicht.
Naja als Programmierer kannst du ja nicht davon ausgehen wo deine Threads wann ausgeführt werden. Außerdem stimmt wenn Cores > = Anwendungen wird auch nichts verhungern, aber brauch ich dann überhaupt noch einen Scheduler der verschiedene Prioritätsstufen kennt und je nach Prozess diese dann verwaltet. Die Berechnung des Schedulings war bei 2000 und XP nicht so leicht und auch bei den Linuxern gab es da mal immer wieder was neues, weil einfach das Thema nicht so einfach ist.
> > - höhere Performance(keine teuren Kontextwechsel zum Sichern der
> Register
> > usw.)
>
> Kontextwechsel werden nur durchgeführt, wenn es notwendig ist - also
> mehrere Threads um einen Core kämpfen. Fällt also nur der Overhead für das
> Nachschauen in der Warteschlange an, den ich jetzt mal nicht als sooo hoch
> einschätzen würde, da im beschriebenen Fall immer nur ein Thread pro Core
> aktiv ist.
Jo.. wofür brauch ich dann Ring 0 - 3 auf der CPU + den Scheduler? Genau hier setzt doch die Überlegung von dem MS Typen an. Wenn wir soviele Cores haben, warum schleppen wir etwas mit, was von einem anderen Ausgang ausgeht und vielleicht dann fehlmanaged?
> > Nachteile:
> > - geringere Parallelität
>
> Wenn man mal annimmt, dass, wie von einigen prognostiziert, die CPU- und
> GPU-Architektur verschmelzen, dürfte man in Zukunft Probleme bekommen, z.B.
> bei Spielen. Bei Video/Audio-En/Decoding oder Grafikbearbeitung dürfte es
> auch mau aussehen.
Kannst du das mal bitte etwas detaillierter Ausführen? Mein letzter Stand ist eigentlich das GPUs verdammte hochspezialisierte Numbercruncher sind die massiv parallel arbeiten.
> > Kritisch werden erst Dinge
> > wie I/O und halt Speicherzugriff, wobei moderne Prozessoren ja mit einem
> > Sack voll Features daherkommen. Wenn es also jetzt möglich wäre einen
> > riesigen Speicherblock dazu zu werfen und durch eine für alle CPUs
> zentrale
> > MMU Zugriffe auf fremde Speicher zu untersagen... es könnte im
> Heimbereich
> > aufjedenfall einen Leistungsschub geben.
>
> Wenn man ne MMU hat, die eh alle Speicherzugriffe kontrolliert, kann man
> auch gleich bei der Seitenverwaltung bleiben.
Jein, habs vorhin nochmal nachgelesen im Sinne von Singularity machts sogar noch viel emhr Sinn. Da dort alles zu compile Zeit festgelegt ist bräuchte das Ding nichtmal ne MMU.
> > Vom Coding her wird es sogar erheblich einfacher für die Programmier:
> > - Speicherverwaltung ändert sich eigentlich garnichts, wenn ich mit Ptr
> > arbeite muss ich immernoch aufpassen, wenn nicht ist es auch egal :)
> > - Es gibt keine Race Conditions, ich muss nicht mehr Multithreading
> > debuggen, Locks und Mutex werden wegfallen. (komplett auf den
> Heimanwender
> > bezogen)
> > - Nachteile könnten sich wenn in Servern ergeben, da dort das Threading
> > immernoch leichtgewichtig genug ist um Vorteile bei vielen kleinen
> Anfragen
> > zu liefern. Aber da werden sich dann mit der Zeit entsprechende
> > Möglichkeiten rauskristallisieren dies in den eigenen Programmen wieder
> zu
> > ermöglichen.
>
> Ich kann auch in Python/Java/whatever programmieren, da ist auch vieles
> einfacher, aber schneller wird es dadurch nicht unbedingt.
Naja Locks und Mutex sparst du dir damit nicht, ich glaube die einzige Sprache die da wirklich was bringen könnte wäre Erlang, aber dafür bin ich etwas weit vom Thema weg.
Gerlion schrieb:
--------------------------------------------------------------------------------
> Es geht hier vornehmlich um die Speicherverwaltung. Dein Vorschlag pro
> Programm einen Core bringt dabei eigentlich nichts, denn die Programme
> würden immer noch auf einen gemeinsamen Speicher zugreifen. Du brauchst
> immer noch den Speicherschutz gegen die Prozesse auf den anderen
> Prozessoren und Du musst auch immer noch auf Betriebssystemroutinen
> zugreifen und diese mit den anderen Prozessen teilen. Wenn z.B. ein
> Interupt von einem Bussystem ausgelöst wird, dann bremst das eben auch die
> anderen Anwendungen. Das kann man in modernen OS gar nicht verhindern.
Nein den Speicherschutz brauchst du bei einer Compilezeit abhängigen Contracts nicht mehr. Ist mir auch erst später eingefallen, ist aber ein Prinzip aus Singularity (anderes MS Forschungsprojekt). Zusammen mit dem Channelkonzept ist es nicht möglich auf anderen Speicher zu kommen. Zack fällt der Speicherschutz weg. Warum bremst denn ein Interrupt alle Prozessoren aus? Ich hab leider keine Implementierungsdetails hier, aber es wäre schon sehr sehr unsinnig wenn wegen eines Interrupts z.b. vom Zeitgeber jeder Prozessor seine Arbeit unterbrechen würde und in die Routine springen würde oder?
Naja Interprozesskommunikation und so seh ich auch den Aufruf von Betriebssystemroutinen erfolgt dann halt über Cores.
> Außerdem unterscheidest Du anscheinend Threads und Prozesse nicht. Bei mir
> laufen gerade nur wenige von mir gestartete Anwendungen, trotzdem aber ca.
> 30 Prozesse mit zusammen mehr als 200 Threads - und dabei bin ich gerade
> nicht sonderlich aktiv. Prozesse sind dabei Ressourcenfresser und Threads
> eher Ressourcenschoner, da sie parallel im gleichen Adressraum ablaufen. Du
> willst die Nebenläufigkeit abschaffen, was wohl kaum durchsetzbar sein
> dürfte. Die Anwender würden Dir die SOftware als nutzlos um die Ohren
> hauen. Bei mir hat zum Beispiel Firefox gerade 22 Threads, Skype 25, Word
> und Freecommander 7, Paint.Net 13, ... und das machen die nicht nur um die
> Software komplizierter zu machen.
Threads bringen Probleme beim Debuggen und beim Programmieren, Threads vervielfachen das Fehlverhalten eines Programms, außer du nutzt viele Locks. Dann ist aber der Gewinn eher marginal. Ja stimmt Threads sind beim Speicherverbrauch schonender, das Problem ist aber das Threads beim Scheduling alles verkomplizieren. Statt das der Scheduler 30 Programme auf 2 Cores verteilen darf sind es aufeinmal 200. Was war denn der Sinn von Threads, das Aufgaben "simuliert" Parallel gefahren werden. So steht es sogar noch in vielen Büchern. Aber bald haben wir genug Cores, dann können wir Dinge die wirklich Parallel laufen können eigenständig laufen lassen. Was für einen Vorteil haben dann noch Threads, außer die Speicherersparnis? Ich will die Nebenläufigkeit nicht abschaffen, aber vereinfachen. Es gibt IPCs das funktioniert super, aber mit Threads wirds noch viel lustiger, wir teilen uns einen Speicherbereich und schießen uns ins Knie. Keine Ahnung wie oft bei dir der Firefox schon abgestürzt ist, bei mir oft genug ;).
Ich sag nicht das Threading nicht Vorteile hat, wenn gilt Progs > Cores, aber in dem Fall Progs <= Cores ist es einfach ein falscher Ansatz der sogar Ressourcen verschwendet.
> Was der Wissenschaftler nun vorgeschlagen hat ist, dass große Teile des OS
> in die Anwendungen verlagert werden. Diese also eine eigene
> Ressourcenverwaltung implementieren. Dadurch würde die Parallelverarbeitung
> massiv steigen, man hätte genau das Gegenteil von Deinem Vorschlag. Dadurch
> würde die Anwendungen um ein Vieles komplexer, aber die Leistung würde
> durch die Parallelisierung steigen - zumindest theoretisch.
Falls benötigt ein eigener Scheduler, aber wieviele Programme brauchen das, wieivel macht das durchschnittliche Programm Parallel? WIRKLICH Parallel, Word, Firefox, sind diese Implementierungen sinnvoll gelöst?
wodar schrieb:
--------------------------------------------------------------------------------
> Naja als Programmierer kannst du ja nicht davon ausgehen wo deine Threads
> wann ausgeführt werden. Außerdem stimmt wenn Cores > = Anwendungen wird
> auch nichts verhungern, aber brauch ich dann überhaupt noch einen Scheduler
> der verschiedene Prioritätsstufen kennt und je nach Prozess diese dann
> verwaltet. Die Berechnung des Schedulings war bei 2000 und XP nicht so
> leicht und auch bei den Linuxern gab es da mal immer wieder was neues, weil
> einfach das Thema nicht so einfach ist.
>
> Jo.. wofür brauch ich dann Ring 0 - 3 auf der CPU + den Scheduler? Genau
> hier setzt doch die Überlegung von dem MS Typen an. Wenn wir soviele Cores
> haben, warum schleppen wir etwas mit, was von einem anderen Ausgang ausgeht
> und vielleicht dann fehlmanaged?
Ich muss mir mal das Singularity-Zeug anschauen, aber ich bezweifle momentan, dass man Anwendungen wirklich davon abhalten kann Unfug zu treiben. Der Compiler kann viel versuchen, wenn man im nachhinein mit (dis-)assembler arbeitet.
> Kannst du das mal bitte etwas detaillierter Ausführen? Mein letzter Stand
> ist eigentlich das GPUs verdammte hochspezialisierte Numbercruncher sind
> die massiv parallel arbeiten.
Ich kann das gerade nicht zitieren, aber die Richtungen sind imho im Moment recht ersichtlich.
CPU: von einem/wenigen mächtigen Core(s) (z.B. C2D) zu vielen einfachen Cores (z.B. Intel Larrabee, Intel SCC mit 48 pentium1 cores)
GPU: von vielen einfachen rechenoperationen um geometrien&texturen zu berechnen zu immer komplexeren Cores die inzwischen auch in double-precision,atomare Operation usw. rechnen können.
Ist natürlich bisher alles nur Vermutung.
> Naja Locks und Mutex sparst du dir damit nicht, ich glaube die einzige
> Sprache die da wirklich was bringen könnte wäre Erlang, aber dafür bin ich
> etwas weit vom Thema weg.
Erlang hab ich gefressen. Sprachen bei denen der Index der Elemente mit 1 anfängt, sind mir suspekt. ;)
lalelu schrieb:
--------------------------------------------------------------------------------
> wodar schrieb:
> ---------------------------------------------------------------------------
> -----
> > Naja als Programmierer kannst du ja nicht davon ausgehen wo deine
> Threads
> > wann ausgeführt werden. Außerdem stimmt wenn Cores > = Anwendungen wird
> > auch nichts verhungern, aber brauch ich dann überhaupt noch einen
> Scheduler
> > der verschiedene Prioritätsstufen kennt und je nach Prozess diese dann
> > verwaltet. Die Berechnung des Schedulings war bei 2000 und XP nicht so
> > leicht und auch bei den Linuxern gab es da mal immer wieder was neues,
> weil
> > einfach das Thema nicht so einfach ist.
> >
> > Jo.. wofür brauch ich dann Ring 0 - 3 auf der CPU + den Scheduler? Genau
> > hier setzt doch die Überlegung von dem MS Typen an. Wenn wir soviele
> Cores
> > haben, warum schleppen wir etwas mit, was von einem anderen Ausgang
> ausgeht
> > und vielleicht dann fehlmanaged?
>
> Ich muss mir mal das Singularity-Zeug anschauen, aber ich bezweifle
> momentan, dass man Anwendungen wirklich davon abhalten kann Unfug zu
> treiben. Der Compiler kann viel versuchen, wenn man im nachhinein mit
> (dis-)assembler arbeitet.
Kanns wirklich nur empfehlen, das Einstiegspaper waren glaub nur 20 Seiten. Aber da war schon viel lustiges im Sinne von der Entwickler muss zur Programmierzeit Dinge festlegen und kann dann nachher nicht mehr ausbrechen. Naja die Idee ist ja das ganze dann noch mit Manifest Dateien (Files die alles bündeln) und ein bisschen Crypto hieb und stichfest zu machen :).
> > Kannst du das mal bitte etwas detaillierter Ausführen? Mein letzter
> Stand
> > ist eigentlich das GPUs verdammte hochspezialisierte Numbercruncher sind
> > die massiv parallel arbeiten.
>
> Ich kann das gerade nicht zitieren, aber die Richtungen sind imho im Moment
> recht ersichtlich.
> CPU: von einem/wenigen mächtigen Core(s) (z.B. C2D) zu vielen einfachen
> Cores (z.B. Intel Larrabee, Intel SCC mit 48 pentium1 cores)
>
> GPU: von vielen einfachen rechenoperationen um geometrien&texturen zu
> berechnen zu immer komplexeren Cores die inzwischen auch in
> double-precision,atomare Operation usw. rechnen können.
>
> Ist natürlich bisher alles nur Vermutung.
Ja gut, aber das heißt doch nur das wir erheblich schneller mit Cores >= Programme/Threads rechnen können. Sprich die Überlegungen von dem MS Typen sind genau jetzt relevant, denn wenn wir wirklich bald einen Prozessor mit 512 Cores haben, wovon vielleicht 200 mit Graphik beschäftigt sind ist die Frage nach dem Scheduling wirklich interessant.
> > Naja Locks und Mutex sparst du dir damit nicht, ich glaube die einzige
> > Sprache die da wirklich was bringen könnte wäre Erlang, aber dafür bin
> ich
> > etwas weit vom Thema weg.
>
> Erlang hab ich gefressen. Sprachen bei denen der Index der Elemente mit 1
> anfängt, sind mir suspekt. ;)
Okay, DAS wusste ich noch nicht :D.
wodar schrieb:
--------------------------------------------------------------------------------
> Threads bringen Probleme beim Debuggen und beim Programmieren, Threads
> vervielfachen das Fehlverhalten eines Programms, außer du nutzt viele
> Locks. Dann ist aber der Gewinn eher marginal. Ja stimmt Threads sind beim
> Speicherverbrauch schonender, das Problem ist aber das Threads beim
> Scheduling alles verkomplizieren. Statt das der Scheduler 30 Programme auf
> 2 Cores verteilen darf sind es aufeinmal 200. Was war denn der Sinn von
> Threads, das Aufgaben "simuliert" Parallel gefahren werden. So steht es
> sogar noch in vielen Büchern. Aber bald haben wir genug Cores, dann können
> wir Dinge die wirklich Parallel laufen können eigenständig laufen lassen.
> Was für einen Vorteil haben dann noch Threads, außer die Speicherersparnis?
> Ich will die Nebenläufigkeit nicht abschaffen, aber vereinfachen. Es gibt
> IPCs das funktioniert super, aber mit Threads wirds noch viel lustiger, wir
> teilen uns einen Speicherbereich und schießen uns ins Knie. Keine Ahnung
> wie oft bei dir der Firefox schon abgestürzt ist, bei mir oft genug ;).
> Ich sag nicht das Threading nicht Vorteile hat, wenn gilt Progs > Cores,
> aber in dem Fall Progs <= Cores ist es einfach ein falscher Ansatz der
> sogar Ressourcen verschwendet.
Wenn du z.B. OpenMP benutzen kannst, sind Threads eine schöne Sache. Man benutzt OpenMP ja häufig, um Schleifen zu parallelisieren die auf unabhängigen Datenfeldern arbeiten. Da hat man dann (meist) auch keinen Stress mit Locks. Ich will auch nicht die sequ. Ausführung totreden und alles mit Threads machen, aber für leistungshungrige Anwendungen wird man imho nicht mehr um Parallelität herumkommen.
> Falls benötigt ein eigener Scheduler, aber wieviele Programme brauchen das,
> wieivel macht das durchschnittliche Programm Parallel? WIRKLICH Parallel,
> Word, Firefox, sind diese Implementierungen sinnvoll gelöst?
Ein Thread kann ja auch abstürzen ohne die restliche Anwendung mitzureißen. Wenn man es anständig macht, kann man z.B. verhindern, dass Flash wieder den ganzen Browser mitnimmt.
lalelu schrieb:
--------------------------------------------------------------------------------
> Wenn du z.B. OpenMP benutzen kannst, sind Threads eine schöne Sache. Man
> benutzt OpenMP ja häufig, um Schleifen zu parallelisieren die auf
> unabhängigen Datenfeldern arbeiten. Da hat man dann (meist) auch keinen
> Stress mit Locks. Ich will auch nicht die sequ. Ausführung totreden und
> alles mit Threads machen, aber für leistungshungrige Anwendungen wird man
> imho nicht mehr um Parallelität herumkommen.
Jupp wobei wirklich viele leistungshungrige Anwendungen hast du ja im normalen Consumerbereich garnicht. Nur warum jetzt ein z.B. Word/Firefox sowas braucht verstehe ich nicht.
Ein SQL Server... Mathematica, halt was viel schnell durchrechnen muss, oder viel gleichzeitig macht, dort wirds interessant.
> Ein Thread kann ja auch abstürzen ohne die restliche Anwendung mitzureißen.
> Wenn man es anständig macht, kann man z.B. verhindern, dass Flash wieder
> den ganzen Browser mitnimmt.
Dadurch das Threads ja gerade den Speicher nicht trennen seh ich sowas immer kritisch. Woher weißt du das Flash nicht doch vor dem Tod mal fix in einen Ptr Unsinn reingeschrieben hat. Du machst damit ja Angriffe möglich.
Wenn jedes Programm sterben würde wenn was unvorhergesehenes passiert wäre es nicht so schlimm wie wenn es dann mit veränderten(vielleicht sogar absichtlich) manipulierten Daten/Code etwas macht was du garnicht mehr kontrollieren kannst.
Ich sehe einfach wenig Sinn darin alles zu Parallisieren was möglich ist.
Der Grundgedanke ist eigentlich garnicht so dumm.
Viele Programme nutzen nunmal kein MultiCore, werden es wahrscheinlich auch nie brauchen, für die ist eine Isolierung auf einen Kern optimal.
Aber das wird wohl erst ein Thema wenn wir bei 100 oder 200 Kernen angekommen sind ;-)
>> Ich behaupte auch garnicht, dass jeder eine Multicore-CPU braucht - Browser, IM und bisl Office laufen auch noch wunderbar auf nem 5 Jahre alten Single-Core.
So siehts aus - mir reicht mein jetziger PC, die Zeiten wo ein Neukauf/Aufrüsten etwas bringt sind für die meisten User vorbei
Das hatte ich mir schon öfter gedacht. Bei jeder neuen Prozessorgeneration wieder, eigentlich reicht ja die Leistung. Und dann kam irgendein Programm, was doch mehr wollte. Meist irgendwelcher Multimedia-Schnickschnack, zuletzt der FullHD-Trend.
Ein Anwendungsbereich wären bestimmt Echtzeitsysteme.
Man könnte einen Core speziell für Echtzeitaufgaben z.B. in der Automatisierungstechnik freigeben,
während die anderen Cores weiter wie bisher vom Kernel verwaltet werden.
Beispiel Internet: Werbung braucht mittlerweile mehr Prozessorleistung wie der eigentliche Inhalt. NoScript+AdBlock machen den "alten" PC wieder so schnell wie ein neuerer wär.
Und bei Flash-Videos liegt es daran das vorhandene Hardware bisher nicht genutzt wurde. Das Flash-Video in VLC abgespielt braucht nur Bruchteile der CPU wie es Adobe-Flash bräuchte.
Bei mir kommen YouTube-Videos, wie zu erwarten, auf die gleiche CPU-Auslastung wie im VLC. Weil der auch die von dir gepriesene Hardwareunterstützung nicht besitzt.
Werbung auf Internetseiten hat die unangenehme Angewohnheit die eigentlichen Informationen zu verdecken, deswegen surfe ich prinzipiell ohne. Aber gegen FullHD dürfte Flash selbst auf einen Mac mit Intel-Grafik, nur eine jämmerliche Erscheinung sein.
Kommentare: 247 | letzter Beitrag 01:02 Uhr
Kommentare: 214 | letzter Beitrag 01:20 Uhr
Kommentare: 212 | letzter Beitrag 01:02 Uhr
Kommentare: 145 | letzter Beitrag 23.05. 14:08
Kommentare: 139 | letzter Beitrag 01:03 Uhr
E-Mail an news@golem.de
Via hat mit dem "APC" ein Konzept für einen Android-PC auf Basis eines sehr kleinen Mainboards vorgestellt. Dieses Board mit vorinstalliertem Android 2.3 sowie Treibern für Maus und Tastatur soll nur 49 US-Dollar kosten.
Die freie IT-Infrastruktur-Monitoring-Lösung Zabbix ist in der Version 2.0 erschienen. Zabbix konkurriert unter anderem mit der ebenfalls freien Lösung Nagios.
Mit "Webmaker" startet Mozilla ein neues Programm, das Millionen von Webnutzern in Webmacher verwandelt. Am 23. Juni 2012 beginnt dazu die Sommer-Code-Party mit weltweiten Veranstaltungen.
Der weltgrößte PC-Hersteller HP will 8 Prozent seiner Beschäftigten loswerden. Besonders betroffen ist die Enterprise Services Group.
Googles Betriebssystem Android verletzt Oracles Patente nicht. So das eindeutige Urteil der Jury im Rechtsstreit zwischen Oracle und Google.
Das Aussehen der Facebook-Profile könnte sich demnächst ändern. Während die ganze Welt den Börsenstart des Unternehmens verfolgt, arbeitet Facebook heimlich, still und leise an einem Redesign der Chronik.