News Umverteilung der Aufgaben im Betriebssystem?

Benny

Lieutenant
Registriert
Apr. 2008
Beiträge
552
In den vergangenen Jahren stiegen am Prozessormarkt neben der Arbeitsgeschwindigkeit an sich auch die Anzahl der Prozessorkerne stetig an. So sind in vielen PCs inzwischen Dual- und Quad-Core-Prozessoren verbaut – Tendenz steigend.

Zur News: Umverteilung der Aufgaben im Betriebssystem?
 
Applaus. Endlich einer, der was aus Multicores holen will. Aber so wies aussieht, wird sich da mei M$ in der kommenden Zeit eh nix ändern...
Verbreitete Programme nutzen dzt nicht mehr als 2-4 Cores und das auch ned uuunbedingt effizient.
 
Das Problem bei der Sache ist leider das wir teilweise Technologie von vor 30 Jahren vor uns her schieben damit die Rechner überhaupt laufen.

Niemand traut sich die alten Zöpfe abzuschneiden weil man sonst den Heiligen Gral Abwärtskompatibilität auf dem Altar der Moderne opfern würde.

Wie war das, unsere CPUs können alle noch 16bit Real Mode und das nur aus einem Grund weil sonst das BIOS nicht funktionieren würde? Aber leider ist es so das wenn was wirklich Neues wollen das Alte so lieb wir es auch gewonnen haben hinter uns zurückgelassen werden muss. Einige hätten damit kein Problem, aber der Markt will halt den Zopf behalten mit allen Nachteilen die sich daraus ergeben.
 
Tia die Frage ist auch, wie es dann mit den jetzigen Programmen ausschaut. Ich denke doch das die Abwärtskompatiblität schwierig wird. Aber rein nach seiner Aussage wäre es doch eine Alternative zu den jetzigen System.
 
Ich bin kein Experte, aber im Open-source-Bereich könnte doch sowas Anklang finden. Abwärtskompatibilität wäre ja durch zig andere Distris gegeben.
 
Je mehr Kerne zur Verfügung stehen, und je weiter die Virtualisierung vorranschreitet, desto weniger spielt Abwärtskompatibilität eine Rolle.
Bereits jetzt sind bei den "großen" Win7 Versionen virtuelle XP mit dabei - das klappt problemlos und ist auch recht komfortabel.

Auf meinem Rechner läuft neben Win7 und dem virtuellen XP noch ein virtuelles Debian.

Ein Win10 könnte also ein neues Kernel haben, und hätte dann eben einen Win7, 8 und 9 Mode.

Leicht offtopic: Wenn Google recht behält, gibts ja aber in 3 Jahren eh keine Desktoprechner mehr, insofern ist das eh alles egal ;-)
 
Per Batch kann man doch jetzt schon Programmen einzelne Kerne zuweisen, wo ist hier das Problem?
Das Problem ist eher, dass kaum jemand vier Spiele gleichzeitig spielt, um seinen Quadcore auszureizen.

Meiner Ansicht nach muss ein Betriebssystem auch nicht mehr können, als Programme ausführen und die Hardware-Ressourcen anständig zu verteilen, alles Andere ist nur Spielkram und im Prinzip nichts anderes als Unterprogramme.
 
Ich weiß nicht ob diese Herangehensweise so wirklich sinnvoll ist. Angenommen ich besitze eine CPU mit sechs Kernen, so müsste ich mindestens sechs Programm öffnen damit diese überhaupt benutzt werden und jedes Programm für sich kann immer nur auf einen Kern zugreifen. Teilt man jedem Prozess einen Kern zu, so bräuchte man mindestens hundert Kerne.

Beim Parallel Computing erfolgt auch heute noch eine Einteilung in verschiedene Time Slices, dabei ist das Problem des Wartens auf Eingaben, Ausgaben oder andere Prozesse seit jeher ein Problem in der Datenverarbeitung und hat auch gar nix mit Parallel Computing zu tun. Vielmehr ist die große Preisfrage wie man verschiedene Prozesse in die Time Slices auf die verschiedenen Kerne so verteilt, dass kein Deadlock auftritt und sonstige Flaschenhälse vermieden werden können.

Die Verteilung von Programmen auf mehrere Kerne ist imho der richtige Weg. Jedem Prozess nun wieder einen Kern zu geben ist eher ein Schritt zurück. Im Besonderen muss auch dann wieder ein Rechteverwaltungssystem her, denn wann weiß ich, wann ich einen Kern freigeben kann?

Entweder ist der Artikel nicht genau genug oder es hat einen guten Grund weshalb er bei Microsoft ziemlich alleine dasteht. ;)
 
Sturmel schrieb:
Je mehr Kerne zur Verfügung stehen, und je weiter die Virtualisierung vorranschreitet, desto weniger spielt Abwärtskompatibilität eine Rolle.
Bereits jetzt sind bei den "großen" Win7 Versionen virtuelle XP mit dabei - das klappt problemlos und ist auch recht komfortabel.

Auf meinem Rechner läuft neben Win7 und dem virtuellen XP noch ein virtuelles Debian.

Ein Win10 könnte also ein neues Kernel haben, und hätte dann eben einen Win7, 8 und 9 Mode.

Leicht offtopic: Wenn Google recht behält, gibts ja aber in 3 Jahren eh keine Desktoprechner mehr, insofern ist das eh alles egal ;-)

STOP!

das stimmt so nicht, da diese aussagen von google als solche NIE! getätigt wurde!

es ging dabei um ein ganz bestimmtes anwendungsgebiet, was zur zeit vermehrt zugriffe durch smartphones und tablet-pcs verzeichnet!

hierbei geht es vorrangig um anwendungen wie office, kleine bildbearbeitung, videoplayer, musik usw.!

von großen anwendungen oder gar einem generellem cloud-computing war da nie die rede.

es ging einfach darum, auch vom smartphone oder kleinen rechnern wie netbooks usw. auf programme mit größerer datenmenge und zuviel rechenaufwand für mobile devices zugreifen zu könne und damit zu arbeiten.

@ topic ... schade, dass man für so einen satz nach vorn nicht von der eigenen firma unterstützt wird!
 
balla balla schrieb:
Meiner Ansicht nach muss ein Betriebssystem auch nicht mehr können, als Programme ausführen und die Hardware-Ressourcen anständig zu verteilen, alles Andere ist nur Spielkram und im Prinzip nichts anderes als Unterprogramme.

Wenn nicht das OS, wer dann? Genau darum installierst du dir ja ein OS, damit es für dich die Ressourcen an die Unterprogramme verteilt. ;) Dazu zählt nun mal auch die Verteilung der Unterprogramme auf die verschiedenen Kerne der CPU, irgend woher muss der Input ja kommen.
 
Zuletzt bearbeitet:
Lässt sich doch sinnvoll regeln!

Quadcore:

1. Kern - arbeitet alle threads ab die im Hintergrund laufen
2. Kern - steht für die aktuelle Anwendung zur Verfügung
3. Kern - 2. Anwendung
4. Kern - 3. Anwendung

Aktive Fenster bekommen immer einen eigenen Kern.

Ein Quadcore hätte dann mindestens 3 Kerne für aufwendige Anwendungen(PC Spiel) zur Verfügung, wenn im Performance-Mode alle Windows Anwendungen wieder auf die 1. CPU zusammen gefasst werden.

McDaniel-77
 
McDaniel-77 schrieb:
1. Kern - arbeitet alle threads ab die im Hintergrund laufen
2. Kern - steht für die aktuelle Anwendung zur Verfügung
3. Kern - 2. Anwendung
4. Kern - 3. Anwendung

feine sache. kern 2-4 voll ausgelastet und kern 1 dümpelt bei 10% load rum, weils nix zu tun gibt.
da liegen genauso ressourcen brach.
um das effizient zu gestalten müssten dann 100 cores oder mehr zur verfügung stehen.
das das prioritätsmanagement immo nich das beste ist ist klar, aber für "1 programm 1 core" ist die hardware noch nciht bereit und ich denke bevor wir 100 kerne haben sind die intelligent genug die aufgaben in hardware zu verteilen und das os muss das nicht mehr erledigen (wenn man intels HT mal weiter denkt)...
 
Also wenn der Virenscanner gerade das System checken will während man die Textverarbeitung aufruft, wird das wohl seine Gründe haben. Ich finde es reichlich schwachsinnig so etwas als Argument zu nehmen, im Prinzip wird damit nur als "Problem" beschrieben, dass Prozesse mit höhere Priorität eine höhere Priorität haben, gäbe es so etwas nicht, hätten wir ein echtes Problem...

Bei so etwas sollte man bitte nicht an Betriebsystemebene ansetzen sondern bei den Anwendungen. Wenn diese mehrere Threads haben (was ja teilweise schon der Fall ist) kann eine Multicore-CPU durchaus gut ausgelastet werden..
 
anderes Problem ist, dass das, wenn ich den Artikel auch auf Golem richtig verstanden habe, mehr oder weniger das momentan genutzte System ist.
Und das heisst, dass da andauernd wieder umhergeschoben werden muss, welcher Kern jetzt grade mal was macht . .
Wenn ich so in meine Taskleiste gucke, dann alt+tabbe ich gerade durch 18 verschiedene Fenster.
Davon viele mit jeweils 10 eigenen unter-tabs und so weiter . . Soll heissen, da würde jede Sekunde MEHRFACH die Priorität gewechselt werden. Und dadurch entstehen Wartezeiten.
 
mehre cores, mit schwächerer leistung, würde aber dazu führen das man viel mehr paralleisieren muss, wo es ja heute schon probleme gibt für mehr als 4 threads Anwendungen zu programmieren.
 
Meriana schrieb:
mehre cores, mit schwächerer leistung, würde aber dazu führen das man viel mehr paralleisieren muss, wo es ja heute schon probleme gibt für mehr als 4 threads Anwendungen zu programmieren.

naja logisch ist es ein problem ...
die OS sind nicht dafür ausgelegt, die software zum teil auch nicht ...

folge: diverese programme und spiele versagen den dienst -> bsp: der neue intel gulftown!
da war es besonders toll zu sehen bei mind. 1 spiel! ( auch wenn ihr rumjammer, dass spiele keine referenz sind, es hätte jede normale anwendung genauso crashen können! )
 
Meriana schrieb:
mehre cores, mit schwächerer leistung, würde aber dazu führen das man viel mehr paralleisieren muss, wo es ja heute schon probleme gibt für mehr als 4 threads Anwendungen zu programmieren.

Soweit ich mitreden kann, wäre es doch dann egal für wieviele Threads programmiert wird, weil jedes Programm EINEN Kern vom BS zugewiesen bekommt und nicht alle.
 
1.) Das Problem an der Verteilung ist, dass es nicht einfach 4 Prozesse gibt, die je eine CPU belegen. In der Realität gibt es 70 Prozesse mit insgesamt 500 Threads, wovon 498, einer der Virenscanner ist, der im Hintergrund ein bisschen dran scannt und einer macht die gesamte Arbeit. Hier ist sehr wohl das Problem, dass man diesen Thread parallelisieren muss und in mindestens 4 aufteilen, die alle gleichmäßig arbeiten. Die 498 Threads die nichts tun waren noch nie das Problem und werden es auch nie sein.

2.) Das Problem an der Parallelisierung ist, dass es erstens Alogorithmen gibt, die sich nicht parallelisieren lassen bzw. viel Code würde sich zwar parallelisieren lassen, man würde aber durch die Synchronisierung so viel verlieren und sich so viele mögliche Bugs eintreten, dass das alles nicht mehr praktikabel ist. Hier wäre ein guter Ansatzpunkt für künftige Betriebssysteme diese Performance zu verbessern.
Ein weiteres Problem ist, dass man in den seltensten Fällen einen Codeteil hat, der viel rechnet. Man hat mehrere Unferfunktionen, die in Summe viel Zeit kosten. Eine Parallelisierung auf unterer Ebene in der Bibliothek z.B. ein Zugriff auf das Dateisystem, ein einfaches SQL Kommando etc. ist nicht komplex genug, als dass sich eine Parallelisierung lohnen würde. Auf oberer Ebene würde sich die Arbeit durch das Ganze Programm ziehen, statt lokal in einer gut getesteten Standardbibliothek zu halten. Hier wäre der Aufwand für die Tests meistens viel zu hoch und man würde sich eine Menge möglicher Bugs eintreten. Gerade Bugs in Bezug auf Threads sind sehr gefährlich, da sie meistens nicht reproduzierbar sind, geschweige denn dass man die Ursache in der Entwicklungsumgebung mit Breakpoints finden könnte. Oft scheitert es auch daran, dass man Ressourcen verwendet, die nicht parallelisierbar sind z.B. eine TCP Verbindung kann nicht von 2 Threads gleichzeitig verwendet werden.

3.) Bei steigender Parallelisierung (Many Core) wird der Speicher ein immer größeres Problem. Die Bandbreite kann beim RAM beliebig erhöht werden, indem die Anbindung breiter wird, jedoch die Latenz kann nicht gesenkt werden. Da eine starre Zuordnung von Speicher zu Prozess in einer CPU auch nicht sinnvoll ist, muss es Wege geben, parallele Zugriffe zu ermöglichen. Dies könnte z.B. passieren, indem der Cache pro Kern stärker fokusiert wird und der RAM in mehrere Bereiche geteilt wird. Es wäre z.B. möglich jeden Chips getrennt zu adressieren. Hier kann es zwar auch zu Überschneidungen kommen, die Wahrscheinlichkeit ist aber geringer. AMD hat diesen Versuch schon mit einzelnen Modulen mit Ganged vs. Unganged Mode unternommen.

4.) Bei halbwegs vernünftiger Verwendung ist die CPU in Desktop Rechnern nicht die bremsende Komponente, sondern die IO Zugriffe. Ein Virenscanner, der ohne brauchbare Prioritätsvergabe die Festplatte komplett auslastet, um den wöchentlichen Full Scan zu machen ist die Hölle.
In vielen Fällen ist es jedoch nicht einmal die Hardware selbst, was durch SSDs in Zukunft verbessert werden könnte, sondern das IO System an sich. Es werden im Hintergrund Unmengen an Zugriffen auf die Registry durchgeführt bzw. auf das Dateisystem (Cache), ohne die Dateien selbst zu lesen. Jeder dieser Zugriffe ist zumindest ein Context Switch d.h. ein Prozess gibt die CPU ab und wartet auf die Antwort des Systems.
Hier könnte man ansetzen, dass einige Zugriffe durch Events gelöst werden und nicht durch Polling. Das typische Problem ist ein Dienst, der Änderungen an der Config auch ohne Neustart übernehmen soll. Dieser kann ständig die Registry abfragen. Hier müssten Methoden eingeführt werden, einen Empfänger automatisch zu benachrichtigen und das Ganze in einer Form, dass es der normale 0815 Programmierer, der die Windows API nicht auswendig kennt auch benutzen kann.

5.) Ein weiteres Performanceloch sehe ich beim Booten des Rechners bzw. allgemein beim Starten von Programmen. Hier werden Unmengen an dlls geladen, Einstellungen verarbeitet etc., was vielen Fällen gar nicht notwendig ist, aber auf manchen PCs sehr wohl benötigt wird. Hier muss die "Load on first use" Philosophie noch weiter ausgebaut werden, dass Dienste erst gestartet werden, wenn diese benötigt werden bzw. dlls erst geladen werden, wenn sie wirklich gebraucht werden, Konfigeinstellungen nur verarbeitet werden, wenn der Teil der Software auch benötigt wird z.B. würde es bei ICQ reichen, wenn die Verbindung zum Server aufgebaut wird. Der Rest kann geladen werden, falls eine Nachricht kommt bzw. man selbst das User Interface öffnet. Oft wird die Quickstart Funktion auf wenigen Rechnern dringend benötigt, auf anderen Rechnern wird die Software selbst nie angerührt.
 
@Badewannenteste: Du hast das Zwinkern übersehen ;-)

Ansonsten ist der Text hier auf Computerbase viel zu kurz und damit ungenau - Probert geht mit seinen Ansätzen weit in die Zukunft. Er denkt da nicht an Quad.- oder Hexacores, sondern eben eher in Größenordnungen von einigen Dutzend Cores.
Dann, so meint er, sei dass jetzige System, in dem jedem Programm vom Kernel Ressourcen zugewiesen werden nicht mehr sinnig.
Wenn ich ihn recht verstanden habe befürchtet er, dass das Kernel verwaltungstechnisch gar nicht in der Lage wäre, die Cores auszulasten.
Stattdessen soll das Betriebssystem Teile der Ressourcenverwaltung aufgeben und die Programme sollen das selbst übernehmen - das meint eben das "jedes Programm ein Kern".

Es geht also sowieso nicht um Windows8 oder 9 - und natürlich gibts Leute (bei M$) die das anders sehen.
Es ist eine Idee, basierend auf einer möglichen technischen Entwicklung.
 
Zurück
Oben