News Umverteilung der Aufgaben im Betriebssystem?

[Badewannenteste]

@ sturmel

das kann sein ...

 

[weissbrot]

das erinnert mich an:
Intel Polaris -> 80 Kerne
oder etwas aktueller:
48 Kerne -> x86 CPU

aber generell muss ich sagen, dass ein Umdenken durchaus mal angebracht ist. Nicht jetzt in 1-2 Jahren aber man sollte doch mal ein wenig weiter denken...

 

[Badewannenteste]

krass

gabs nicht noch nen größeren manycore-prozessor mit 128 kernen ?

der war aber nicht von amd oder intel ... mhm ich finde die news nicht =/

 

[Aral]

Ach Benny da haste so ein intressanten Artikel aufgepickt und dann nicht gescheit ins Deutsche uebersetzt bzw. die wichtigen Stellen rausgelassen. Sehr schade... 1 Stern von mir.
Der Original Artikel in Englisch is SEHR lesenswert!

 

[roker002]

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)...

Es ist wie oben beschrieben... das System merkt dass ein Programm viel ressourcen braucht. Deswegen wird ein ganzer kern zur verfügung gestellt. um das Programm schneller ablaufen zu lassen ohne wartezeiten und prioritätsschlangen.

Das größter problem stellt wirklich die anzahl der kerne. Man muss soo programmieren dass es nicht nur ab 4 Kerne alles flüssig ablaufen kann, sondern auch ab einen oder zwei Kernen.

Stellt euch vor, man hat 2 Systemlastige Programme gestartete und man hat nur 2 Kern zur verfügung. Das geht noch OK... man verteil die Programme auf 2 kerne, mit warteschlangen natürlich, da sonst kein anderer Programm ausgeführt werden kann, bis der Prozess beendet worden ist.
Was ist wenn man 3 Systemlastige Programme hat und nur 2 Kerne oder gar einen Kern.... das alles muss mitgedacht werden. Bis jeder mensch der einen PC hat einen Quadcore besitzt wird es noch min 10 Jahre dauern.

Die BSs mit Warteschlangen wie die heute existieren (natürlich muss ich einen Priorisierung zwischen den Prozessen und Warteschlangen erhalten werden) werden sicher bis zu 80% der Performance einbüßen da diese mit eine riesige Warteschlange arbeiten wodurch die Verarbeitung der Prozesse erheblich abgebremst wird.

Zwischen den Prozessen darf auch nicht gewechselt werden, da jedesmal der Cache in der CPU gespüllt wird, was für eine künstliche abbremmsung führt!

ich hoffe dass sich es mit dem neuen Kernel, egal ob MS oder UNIX, sich schneller durchsetzt (Multicore leistungsfähig BS meine ich)....


übrigens... meine Lokale Zeit ist erst 11 Uhr! nicht 3 Uhr nachts

 

[Funhubble]

Das hört sich immer wieder gut an ist aber dieses Problem ist doch längst jedem bekannt !!

Ist das gleiche wenn einer auf einer Tagung feierlich die ansicht vertritt daß das Öl ausgeht oder das Gras tatsächlich grün ist.....

 

[eSp!s0]

...
Stellt euch vor, man hat 2 Systemlastige Programme gestartete und man hat nur 2 Kern zur verfügung. Das geht noch OK... man verteil die Programme auf 2 kerne, mit warteschlangen natürlich, da sonst kein anderer Programm ausgeführt werden kann, bis der Prozess beendet worden ist.
Was ist wenn man 3 Systemlastige Programme hat und nur 2 Kerne oder gar einen Kern.... das alles muss mitgedacht werden. Bis jeder mensch der einen PC hat einen Quadcore besitzt wird es noch min 10 Jahre dauern...

Die 10 Jahre würde es ja in etwa sowieso dauern, bis die solch ein BS entwickelt haben. Von daher würde ich ich es auch gut finden, wenn man in diese Richtung geht und sehe da keine großen Probleme.

 

[Tulol]

Per Batch kann man doch jetzt schon Programmen einzelne Kerne zuweisen, wo ist hier das Problem?

Du hast da etwas nicht ganz verstanden.
Zur zeit behandelt das OS einen Multicore Prozessort ähnlich wie einen mit nur einem kern.
Dh. er teilt den laufenden Programmen Prozessorzeit zu.
Ob sich diese nun auf einzelne Threads über mehrere Prozessoren verteilen oder nicht ist letztendlich egal.

Was der 'feine' herr hier anspricht ist allerdings eine art "echtzeit System".
Es teilt einem Programm/Aufgabe einen ganzen Kern, einen Teil des Speichers etc "fest" zu.
Sprich, der Kern(prozessor) macht nichts anderes als dieses eine programm auszuführen.
Andere Programme haben während dessen keinen zugriff auf diesen kern.

Im Desktop bereich macht ein Echtzeit System mit einem, zwei oder 4 kernen nicht viel sinn.
Aber der Mann da geht davon aus, das in absehbarer Zukunft die anzahl der kerne massiv ansteigen wird(so habe ich das jedenfalls verstanden)

 

[DarkMaddin]

also ich bin der meinung, es liegt gar nicht an den cpus, sondern an den festplatten. wenn ich grad was entpacke, dann ist die cpu auslastung vllt bei 20% aber logischerweise rödelt die festplatte wie blöd und das email programm braucht schonmal seine minute oder 2 bis es auf ist.
wenn also ssds richtig entwickelt sind und standardmäßig slc ssds erschwinglich werden, dann könnte man sich mehr auf die multicore unterstützung spezialisieren.

aber soweit ich mich erinnern kann, kann man den anwendungen doch im task manager einzelne kerne zuweisen oder nicht?

 

[Hypocrisy]

Ganz ehrlich - ich kann mich über Performance nicht beklagen.

Wenn ich meine Textverarbeitung starte und mein Virenscanner irgendwas beschließt, dann habe ich keine Wartezeit. Mehr als ein Quadcore (bzw. i7) ist derzeit wirklich nicht notwendig. Power-User natürlich ausgenommen.

 

[timurinamanu]

Also wen MS sowas durchzieht weiss ich schon jetzt was kommt:

Windows X premium: Voraussetzung 4 Kerne
BAsic: 2 Kerne
Professional: 6 Kerne

danach kommt wahrscheinlich noch, dass manche applikationen bei manchen nicht kompatibel sind( aber das ist ja inzwischen normal bei MS)

Das geilste ist sicher die Fehlermeldung:
Sie haben zwar 4 Kerne mit ausreichen leistung, aber sie brauchen für Professional 6 Kerne. Besorgen sie sich 2 weitere oder aktivieren sie Hyperthreading

 

[oldsqldma]

Man müsste die Kerne jewals nach der Thread-Last der Anwendung zuweisen.
Wenn ein Videokonverter 100 Threads offen hat, und neben bei nur 2 weitere Anwendungen mit 7Threads laufen, so kann man der Videokonvertierung ruhig 2-3 Kerne, falls vorhanden, zur Verfügung stellen und die beiden anderen Anwendungen auf einen gemeinsamen Kern packen.

Allerdings wird das mit der größen Ordnung eines BS schon schwerer, immerhin nuzt das BS auch selbst Ressourcen, was das ganze verkompliziert.

Kommt ja schon leicht an den Versuch ran, eine Optimierung für Prolog zu erstellen, welche sich an oft wiederholbaren Abläufen zur Optimierung orientiert.

 

[Fleshgrinder]

Immer dieses gejammer über Applikationen die unter Windows nicht lauffähig sind. Misstet mal eure Softwaresammlung aus, könnte ich Einfluss auf Microsofts Politik nehmen so würden Programme die nicht Windows Vista kompatibel sind - also nur XP oder älter - standardmäßig gar nicht installierbar sein!

Diese Programme sind nur Sicherheitslücken, Bremsen und führen dazu, dass Microsoft immer noch mehr Kompromisse bei ihren Betriebssystemen eingehen muss. Wenn du dir eine neue S-Klasse kaufst, erwartest du ja auch nicht, dass der Auspuff der S-Klasse von 1980 drauf passt.

EDIT: Also ich habe jetzt mal den Original Artikel gelesen, der Artikel hier bei Computerbase ist extrem ungenau und die wichtigsten Teil wurden völlig unterschlagen. Folgende Punkte von Dave Probert wurden so gar nicht erwähnt:

• Programme sollten bereits parallelisiert sein - eine Forderung die überall zu hören ist.
• Das Betriebssystem simuliert die Hardware als eine Art VM für die Programme - die Programme greifen also nicht direkt auf die Hardware zu und kein Programm erhält einen CPU Kern für sich ganz alleine.

Das sind imho die wichtigsten Punkte die im CB-Artikel fehlen. Da ist aber mehr, lest den Original Artikel wenn ihr Englisch beherrscht oder sonst bei Golem (ist auch genauer). Das ändert das Ganze natürlich drastisch und Herr Probert hat damit auch einen Ansatz gefunden der Sinn macht. Heutige CPUs von Intel gehen ja auch schon in diese Richtung durch Hyper-Threading, einfach so tun als hätte man viele, viele Kerne obwohl sie nicht existieren.

 

[d-Raven-b]

Schön das hier einige fordern, alte Zöpfe abzuschneiden und veraltete Technik auf dem Altar des Fortschritts zu opfern.
Schön und gut, aber wenn ich mich erinnere, welches Theater ausgebrochen ist, als sich Microsoft erlaubt hat DX10 nur ab Vista auszugeben! Die Foren waren gefüllt mit Hass-Threads.

Microsoft wird sich hüten die Abwärtskompatibilität zu opfern..

 

[blitzkid138]

ich versteh schon warum der alleine da steht... sowie das hier steht würde das wahrscheinlich erst bei 64 oder 128 Kernen Sinn machen... also wenn man jetzt mal bei PC Betriebssystemen ist... weil da kommt es extrem auf echt zeit an... und da kommt man mit 2 oder 4 Kernen einfach nicht um das durch wechseln drumherum ...(deswegen ist die Zeitscheibe bei Server Betriebssystemen ja auch größer)
Die Leute die Software entwickeln sollte sich erst mal auf Multithreading konzentrieren, wobei sich das mittlerweile ja schon gebessert hat, so schwer ist das ja auch wirklich nicht ...

 

[Eisenfaust]

Witzig - bei Microsoft ist also jetzt, 10 Jahre später, der Paradigmenwechsel angekommen. Für was hält sich dieses Unternehmen eigentlich? Erfinder des Computerbetriebssystemes? Herr Tanenbaum täte gut daran eine Neuauflage seines Standardwerkes ins Leben zu rufen und dort einige Aspekte neuerer Denkansätze aufzunehmen, die seit geraumer, nicht unerheblicher Zeit im BSD-Umfeld kultiviert werden und worden sind. Vielleicht kommt das dann auch bei Microsoft an.

 

[erazzed]

[...] Für was hält sich dieses Unternehmen eigentlich? [...]

Aha, ok, fassen wir mal zusammen:

Derzeit wird von allen Consumer-Betriebssystemen im Grunde die selbe Methode eingesetzt, wie Hardwareressourcen (im speziellen Prozessorkerne) verteilt werden und inwiefern mehrkenoptimierte Anwendungen diese Ressourcen nutzen können.

Nun gibt es bei MS einen Engineer, der in dieser eingesetzten Methode keine Zukunft sieht und versucht einen komplett neuen, zukunftsorientierten Ansatz zu entwickeln. Seinen Ansatz hat er bei einem Vortrag an einer Uni vorgestellt.

So, und jetzt erklär mir doch bitte noch einmal wie du zu deiner Aussage im zitierten Post kommst?

Ich habe immer den Eindruck 90% der Kommentatoren hier lesen nur die Überschrift + den ersten Satz des Artikels und springen dann direkt zum "REPLY"-Button um irgendeinen Nonsens zu schreiben. Besonders auffällig ist das immer bei News wo Stichworte wie "Microsoft" und "EA" usw. vorkommen

 

[Stryke707]

Eisenfaust hat schon recht dieser Pradigmenwechsel war schon lange absehbar. Allerdings gehen die Bedürfnisse der User auch immer weiter auseinander.
Vom (im Moment) Hexacore bis zum Atom, vielen Usern reicht die momentane Leistung auch völlig. Intel hat ja auch schon länger Forschungsgruppen für genau dieses Problem ins Leben gerufen siehe zb die oben verlinkte News zum 48-core Experiment.
Auch bei Polaris war das bekannt, wenn man nicht einen Weg findet die Taktschraube anzuziehen hat man eigentlich kaum andere Möglichkeiten zumindest sind mir keine bekannt.

 

[TRixxY]

Endlich mal ein vernünftiger Ansatz....diese ganze Quad/Octacorediskussionen hier im Forum sind mir langsam zuwieder. Ich hab mich gerade letzte Woche ganz bewusst wieder für einen DualCore entschieden, die Leistung reicht dicje, denn nur wenige Anwendungen nutzen mehr als 2 Kerne, hier gilt immer noch GHz vor Kernen, da die Aufgaben nicht sinnvoll verteilt werden können.

 

[Magellan]

Hmm der Artikel hier bei CB sagt etwas völlig anderes aus als im Original wirklich gemeint war :/

Das wesentliche war doch dass nicht das OS andauernd speicher und zeitscheiben auf den cores verteilen (und umverteilen) soll so dass prozesse immer wieder auf die zuteilung durch das os warten.
Statt dessen sollen die Programme unter einander kommunizieren und so eine optimale verteilung der virtuellen resourcen aushandeln welche dann im großen und ganzen fest bleibt so dass der einzelne prozess wirklich durchlaufen kann und nicht ständig wartet.