Intel: Entwickler sollen für "tausende Kerne" planen

Prozessoren Die Softwarehersteller kämpfen derzeit noch damit, ihre Programme für die effektive Ausnutzung der Ressourcen von aktuellen Mehrkern-Prozessoren mit 2 oder mehr Cores aufzubereiten. Geht es jedoch nach Intel, müssten sie eigentlich schon viel weiter ... mehr...

Diese Nachricht vollständig anzeigen.

Jetzt einen Kommentar schreiben
 
Ist schon Krank. Die meiste Software schafft nichtmal mal 2 Kerne zu benutzen. Hier plant man tausende. Ich hab son bisschen das Gefühl es fehlt zur zeit die Inspiration für die Entwicklung. Man weis nicht wie es so recht weiter gehen soll.
 
@Kalimann: News gelesen?
 
@Zebrahead: Jap!
 
@Kalimann: Die Zukunft bei den Prozessorherstellern geht momentan in Richtung Multicore. Also anstatt das sich die Taktfrequenz immer mehr erhöht wie früher zu Zeiten von Pentium 4 und Konsorten, steigt nun die Anzahl Kerne. Da aber leider die wenigsten Softwareentwickler mit Multicore-Unterstützung programmieren, bleibt der imense Vorteil von eben diesen unbeachtet. Deswegen will Intel das sich die Softwareentwickler heute schon auf möglichst viele Cores einstellen. Bringt ja nichts wenn heute eine Firma auf Dualcore programmiert und in zwei Jahren, wenn die Software released wird, gibt es bereits Octacores mit HT. Intel braucht genauso wie wir Anwender die softwareseitige Unterstützung für möglichst viele Prozessorkerne um möglichst viel Leistung zu erhalten. Und deswegen fordert Intel die Softwareentwickler nun offiziell auf, dies zu tun. Es geht also nicht um fehlende Innovation oder das es "krank" ist, sondern darum dass die aktuellen Prozessoren einfach nicht richtig ausgenutzt werden können weil sie einfach von der Software falsch oder nicht optimal angesprochen werden, wodurch imenses Potential verschenkt wird.
 
So einfach wird das teilweise gar nicht. Da muss nicht nur die Anwendersoftware komplett umgestellt werden, sondern auch alle anderen Dinge wie das Betriebssystem. Bei manchen Anwendungen muss man aber schon suchen, um noch etwas zu finden, dass man auf einen anderen Kern übertragen kann.
 
@AGuther: News Gelesen?

Betriebssystem = Software
Microsoft = Softwarehersteller
Anwendungen bei denen man suchen muss wass man auf Kerne verteilen kann sind hier nicht gemeint. Oder meinst deine ICQ App wird auf nem 4- Kerner Schneller laufen?
Gemeint sind Hardcore Apps die nicht unbedingt für den Heimanwender bestimmt sind. Gemeint sind auch hier eher Softwarehersteller wie SAP und nicht EA Games :-)
 
Oh ich denke durchaus dass die Spielindustrie mit einbezogen wird. Kaum eine andere Anwendung braucht bei den Heimanwendern soviel Rechenleistung. Denken wir nur: Physik, KI, Netzcode, Grafik etc. da kommt was zusammen, vorallem weil bei KI und Physik wir uns erst ganz am Anfang befinden. Nicht umsonst unterstützt Supreme Commander bis 8 Kerne, bei den tausenden von Einheiten die er berechnen muss.
 
@crusher^2: Das Problem ist auch, das du Software mit den vom Betriebssystem bereitgestellten Programmierschnittstellen schreibst. Wenn schon diese nicht für so viele Kerne ausgelegt sind, wirst du Mühe haben, deine Software für so viele Kerne zu entwickeln.
 
@JTR: Trotzdem ist es effizient damit kann man nur entlasten .
 
@crusher²: Geh mal von SAP weg... bzw geh auf irgend ein ERP System... die laufen alle über Datenbanken - da macht der ApplicationServer die Arbeit :) nicht der Client :D
 
@JTR: Bei Spielen ist es dann aber wiederum problematisch alle Subsysteme die du anführst synchron zu halten. Die Physikengine kann z.B. erst dann arbeiten wenn du per Eingabegerät den Befehl gibst ein Faß umzuschubsen oder so. Und die Grafikberechnung (z.B. die Beleuchtung) kann auch erst dann stattfinden wenn die Physikengine weiß wie das Faß fällt, denn erst dann steht fest wie es beleuchtet werden muß. Da haste schon wieder ne Sequentialität drin. Somit erfodert diese schienbare Parallelisierung einen enormen Kommunikationesaufwand der Subsysteme untereinander. Und DAS in den Griff zu kriegen ist das Hauptproblem an der ganzen Sache.
 
"Er gab allerdings zu, dass es oft schwer zu vermitteln sei, wie man die dadurch erreichbare Leistung anzuzapfen kann. " ... Ein Euro für den, der den Fehler findet. Der Euro ist von Winfuture zu entrichten :D ... Zum Thema: Wenn Intel mir erzählt wie man alle Prozesse parallelisieren können soll, dann will ich das gerne tun. Einfaches Beispiel: Wie soll ich x * y rechnen, wenn x das Produkt aus a * b ist? Da muß ich doch erst a * b = x rechnen, um dann mit x * y weitermachen zu können, oder? Beide Berechnungen kann man darum IMHO nicht parallel durchführen.
 
@DennisMoore: anzapfen :P HER MIT DE KOHLE!!!!!!!!
 
@DennisMoore: Und jetzt stell dir mal vor, du müsstest diese Berechnung für eine Auswertung von Daten 1000 mal durchführen. Beispiel:
Kunde 1: x = a*b | z = x*y
Kunde 2: x = a*b | z = x*y....usw.
Dort hättest du einen gravierenden Vorteil, wenn du jedem Kunden einen eigenen Thread zuteilst und diese wiederum auf verschiedene Kerne verteilt werden.
 
@trashcoder: Ja,aber auch nur dann. Diese Vorteile nutzen heute schon moderne Datenbanksysteme die solche Batchabläufe intern durcharbeiten. Außerdem war das nur ein winziges Beispiel. Man könnte das ja beliebig komplex machen. z.B. könnte eine Funktion erst dann ausgeführt werden wenn eine andere bereits fertig ist. Diese andere braucht für einen Durchlauf 30 Sekunden. Gleiches Problem, keine Lösung. Da hilft wirklich nur ein kompletter Umbau beider Funktionen, der wiederum nur dann Sinn macht wenn sich irgendetwas aus beiden Funktionen parallelisieren lässt.
 
Echtzeit-raytracing für homeanwender wir kommen :D
 
@SiTHiS: Das wird bestimmt kommen...
 
@SiTHiS: es kommt .. nicht heute oder morgen aber es kommt :P
 
...mit "Nehalem" auch schon die ersten 8-Kern-Chips... Korrektur: die ersten x86er 8-Kerner. Bei anderen Architekturen, PowerPC, SPARC, gibt es (native!) Octacores schon seit Ende 2006!!
 
@misthaufen: Werkelt ein solcher nicht auch in de PS3?
 
@misthaufen: Seit wann ist Nehalem ein 8-Kerner?
 
@TiKu: Nun ja das "beste" Modell das dann mal kommen wird soll 8 Kerne haben
 
Dann fang ich jetzt schon mal an, meine kleine Datenbankanwendung auf 1024 Threads aufzustocken.
 
@F98: und wenn AMD dann mit seinem 3- Kerner umme ecke kommt kannst deine Datenbank inne Tonne kloppen :-)
 
@crusher²: Ich hatte mal nen Apple mit 8 Kernen. Lecker! :-o
 
@Bösa Bär: Boahh, ich schmeiß mich gleich weg hier. :-))))) Bin jetzt mal gespannt, wer hier in den Keller muß.
 
@BäsaBär: Jo, die Birne, die ich eben aufgeschnitten habe, hat auch 8 Kerne. Mann, wie geht's dann erst bei einer Melone ab ?
 
@Niclas: Melone geht ab wie ein Zäpfchen! Wer gut schmiert - der gut fährt! *brüll*
 
@crusher²: Das man für den 3-Kerner aber auch einen dreieckigen Lüftersockel mit dazugehörigem dreieckigen Lüfter braucht, hatte ich schon damals bemängelt.
 
Jetzt trennt sich halt die Spreu vom Weizen auf dem Softwaremarkt. Die Zeiten der billigen Lösungen dürfte alsbald mal vorbei sein.
 
@JTR: Das Bezweifle ich mal.
 
@JTR: Sicher ... weil mein VLC zum DVD schauen unbedingt auf 8Kerne skalieren können muss? Oder ist MSOffice bald dem OOffice überlegen, weil WORD auf 100Kerne optimiert ist und der WRITER nicht? Bei Datenbanken und Videoschnitt geb ich dir Recht, aber bei allem Respekt ... bei den meisten Anwendungen ist das absolut "wurscht". Wenn denn mal Windows nicht weiter optisch überladen wird ...
 
Gähn, wie langweilig. Wer sich mit Parallelverarbeitung beschäftigt hat der weiß, dass es unter Umständen sogar massiv langsamer werden kann. je größer der Parallelisierungsgrad wird, umso größer wird in der Regel auch der Kommunikations- und Koordinationsaufwand. Zum Beispiel hatte die Connection Machine schon vor 25 Jahren 65000 Prozessoren. Das macht aber nur für massiv parallele Aufgaben Sinn. Diese sind aber sehr, sehr selten. Ein Beispiel für Menschen ohne Erfahrung mit Parallelität: Ich fahre mit 1 Auto von Hamburg nach München und brauche 6 Stunden. Wenn ich statt 1 Auto 1000 Autos nehme, dann werde ich nicht schneller ankommen, sondern langsamer, da ich Stau bekomme.
 
@timurlenk: Deshalb werden von Intel und AMD auch Wissenschaftler beschäftigt, die die Kommunikation für die Multi-CPUs verbessern soll.
 
@timurlenk: Nimm 5.000 Menschen. Auch wenn es eine gewisse Staugefahr gibt, könnte es mehr Sinn machen, 1.000 Autos parallel zu nutzen, als einen einzigen Wagen, mit dem Du jeweils nur 5 Personen gleichzeitig transportieren kannst (Lassen wir das Auto in diesem Fall einfach 999 Mal von M nach H zurückbeamen.) Sichelich kann ein SuperAuto, welches 1.000 Mal schneller ist, als die Einzelfahrzeuge mehr leisten, aber wir bekommen hier ein Problem mit den Beschleunigungswerten und dem Spritverbrauch bei solchen Geschwindigkeiten. __- PS: ein ICE wäre vielleicht eine Alternative, aber auch hier werden alle Passagiere parallel transportiert. Die anschließende Verteilung mit Taxis wird aber bleiben.
 
@Bösa Bär: Man kann zwar schneller Kommunikation entwickeln, aber am grundsätzlichen Problem ämndert das gar nichts. Wenn 1000 Leute an einer Sache arbeiten, dann musst Du mit 1000 Leuten reden. Das kann man nicht ändern. Je höher der Parallelsierungsgrad, umso höher dieser Aufwand.
 
@timurlenk: Sie werden die Verbesserungspotenziale ausschöpfen. Perfekt wird das nie. Da gebe ich Dir recht. In Sachen "Parallelisierung" bin ich auch nicht so bewandert wie Du. Ferner denke ich, das nur bestimmte Prozesse einer Parallelisierung bedürfen. Viele Threats können auch von Kern XY alleine berechnet werden.
 
@awolf: Es gibt Probleme, die sich parallelsieren lassen, wie 5000 Menschen die parallel nach München wollen. Aber leider lassen sich die meisten Probleme nur wenig parallelisieren: es gibt immer reichlich sequentielle Abschnitte. Also mein Problem war: 1 Person HH->M. Ein Auto kann braucht 6 Stunden. Mehr Autos helfen in dem Fall einfach nicht. Mehr Autos bremsen nur die Aufgabe. Falls es Dich interessiert, dann lies mal über massiv paralle Systeme und deren Probleme, z.B. Speicherzugriffe.
 
@Bösa Bär: Ja, natürlich ist jede Verbesserung gut und wünschenswert. Multicore-Systeme machen auch Sinn, da es immer eine kleine Anzahl Prozesse gibt, die parallel ausgeführt werden können. Nur ist das nicht viel. Ich persönlich würde schätzen, dass die Grenze so bei 16 Kernen für einfache Arbeitsplatzrechner liegt. Das ist aber eine subjektive Einschätzung und kann ich nicht mit Fakten untermauern. Nur für Spezialanwendungen, wie z.B. Strömungssimulationen, machen massiv parallele Systeme Sinn.
 
@timurlenk:
Du vergelichst da aber Äpfel mit Birnen.
Zitat:
Ich fahre mit 1 Auto von Hamburg nach München und brauche 6 Stunden. Wenn ich statt 1 Auto 1000 Autos nehme, dann werde ich nicht schneller ankommen, sondern langsamer, da ich Stau bekomme.
Ende:
Es würde mit einem bus zwar nicht schneller gehn, aber effizienter.
So ist es auch bei cpu's, einen single core auf die gleiche leistung zu bringen wie einen quad, würde mehr energie brauchen als ich bei einem quad an leistung verliere.
Ich kann diese fehlende leistung duch kerne wieder gut machen, spare im gegenzug aber energie und das ist das was sich rechnet.
 
@ mahoney2k2: Falsch: Ein Auto hat einen Spritverbrauch von 8 Litern, ein Bus von 20. Zudem ist er langsamer. Das gleiche gilt bei Single-Core und Multi-Core. Ein Single-Core mit größerer Taktzahl rechnet natürlich schneller als ein Mulit-Core mit geringerer Taktzahl - solange ich nur eine Aufgbae habe. Ein Multi-Core bringt mir erst etwas, wenn ich mehrere Aufgaben habe, die ich parallel abarbeiten kann. Mit Leistungsaufnahme hat die Unterscheidung Single/Multi erst einmal gar nichts zu tun. Das liegt gegenwärtig nur an einem neuen Design, welches extra darauf ausgelegt wurde und ist unabhängig von der Core-Zahl. Um auf das Beispiel zurückzukommen: Wenn 1000 Autos nach Münschen fahren, um insgesamt 1 Person hinzubringen, dann brauchen sie nicht weniger Sprit, als wenn 1 Auto nach München fährt um 1 Person hinzubringen.
 
@timurlenk: Lass doch mal den Autoquatsch weg. Das verdrehen dir hier eh alle. Machs möglichst einfach. Gehen wir mal in den Kindergarten. Wir wollen stille Post spielen und ein Kind (Funktion) sagt einem anderen Kind (anderer Funktion) der Reihe nach was es vom vorherigen Kind gehört hat weiter. Dies ist eine nicht parallelisierbare Aufgabe, denn das meinetwegen 20ste Kind kann dem 21sten nichts sagen bevor es nichts vom 19ten Kind gehört hat. Dies kann aber wiederum dem 20ten Kind nichts sagen wenn es vom 18ten Kind noch nichts gehört hat. Dies muß natürlich vorher was von 17ten Kind gehört haben ... und so weiter. Das ist doch eine (meiner Meinung nach) sequentielle Problemstellung die man nicht parallelisieren kann.
 
@timurlenk: eure autogeschichte ist quatsch. das problem beim multi-core aufgaben ist schlicht und einfach der zugriff auf kritische abschnitte. sprich dinge die nicht unabhängig voneinander ausgeführt werden können ohne sich gegenseitig zu stören oder das resultat einer operation zu verfälschen: da muss man dann halt wege finden wie die threads auf mehreren prozessoren miteinander "kommunizieren" können -> siehe http://de.wikipedia.org/wiki/Mutex
 
@DennisMoore: Für dieses Problem gibt es eine ganz einfache Lösung. Das Ergebnis ist zwar nicht mehr mit "stille Post" vergleichbar, aber funktioniert. Kind 1 übermittelt einfach Kind 2 und Kind 3 die "Post", die die Information wieder an Kind 4 und 5 weitergeben. Schon befindet sich die Information parallel oder wenn man es anders weiterführt sogar in Baumstruktur. Man kann und sollte so programmieren, dass man Sequenzen vermeidet. Die programmatischen Techniken gibt es schon "ewig". Manchmal, und da gebe ich dir recht, gibt es Abläufe, die lassen sich nicht einfach parallelisieren, aber prinzipiell ist das immer möglich. Die interessante Aufgabe für die Multicore Entwicklung ist nun die, die Anzahl dynamisch zu halten, denn dann können diese schwer parallelisierbaren Abläufe nicht mehr so einfach behandelt werden (wie vielen Kindern übermittle ich nun die "Post"?).
 
@dandjo: Das geht nicht, weil Kind 3 abhängig von der Info von Kind 2 ist. Wenn du das am Anfang splittest, machst du alles doppelt. Dann müßte es Kind 2 2x geben. Einmal in der ersten Reihe und einmal in der zweiten Reihe. Genauso Kind 3,4,5,6, .... Damit erreichst du also nix, außer einfach alles doppelt zu machen und so die Auslastung scheinbar zu erhöhen. Wär genauso als wenn ich mathematisch in einer Schleife 1+2+3+4+5+6 ... + 999998 + 999999 rechne. Es ist schon von der Anlage eine Kette und muß auch eine bleiben. Und wenn du dir mal heutigen Assemblercode anguckst wirst du viele Operationen sehen, die auf vorhergehenden Ergebnissen beruhen und somit nicht parallelisiert werden können. @Lord eAgle: Diese Kommunikation schmälert wiederum die Effizienz, weil sie erheblichen Overhead erzeugt.
 
@ DennisMoore: Ich fanf mein Beispiel gut um zu verdeztlichen, dass viele Kerne nicht unbedingt einen Vorteil bringen. Aber Dein Beispiel ist auch schön um Sequenzialität zu verdeutlichen. Wenn wir daraus das 'Ich packe meinen Koffer'-Spiel machen, dann ist klar, dass auch eine Baumstruktur nicht hilft. Ich kann meinen Koffer nicht packen, bevor nicht der vorhergehende etwas reingepackt hat.
 
@DennisMoore: Sicher geht das. Klar, wenn Kind 2.1 und 2.2 die gleiche Information voll verarbeiten entsteht Overhead. Was ich meinte ist, dass sich Kind 2.1 und 2.2 die Arbeit teilen können und sich am Ende zusammensetzen und die Lösung zusammenführen. Das ist das Prinzip der Gruppenarbeit, wenn du so möchtest. Die programmatischen Techniken gibt es, wie gesagt, schon länger, man ist eben auf eine fixe Anzahl von Kernen beschränkt (nicht dynamisierbar).
 
@dandjo: Es gibt aber Arbeiten die man sich nicht teilen kann. So einfach wie du dir das mit dem Aufsplitten machst ist es in der Regel einfach nicht. Die Regel ist nämlich die, dass verschiedene Threads nicht auf derselben Datengrundlage arbeiten können, sondern auf Teilergebnisse anderer Threads angewiesen wären. Wenn du nun mit Gewalt versuchst zu parallelisieren was eigentlich nicht zu parallelisieren ist, dann hast du 2 Probleme. Ein Thread wartet immer auf irgendeinen anderen Thread um ein Teilergebnis zu bekommen mit dem er selber weiterrechnen kann -> Auslastung geht in den Keller. Die Synchronisierung dieser "Warten -> Arbeiten -> Warten -> Nachfragen ob Ergebnis schon da ist"-Aktionen drückt nochmal auf Performance und Effizienz.
 
Das größte Problem ist, dass natürlich auch Softwarefirmen von denen es nahezu unendlich viele gibt, mehr auf wirtschaftlichkeit achten als Intel. Intel hat ein monopol mit AMD und via geschaffen dessen sich keiner verschließen kann, Die Frage ist nicht, nehm ich nun von 1million verschiedenen Anbietern ne CPU, sondern nur von diesen dreien (wobei man VIA auch wech lassen kann 3%MA)

Deswegen ist gute Software leider rar gesäht....Multicore ist ne tolle Sache, doch sie erfordert Zeit und sehr viel Geld, Geld was keiner hat und auch keiner ausgeben will um den Gewinn zu maximieren....

Ich wette die realisieren die neuen 1000kern CPUs in 3D Architektur :_), dann hate jetzt son riesenblock, den man einfach aufs Systemboard knüppelt, wasserkühlung inklusive, hrhr
 
Aus Programmierersicht kann das doch eigentlich nicht so schwer sein. Habe zwar keine Ahnung vom OS-Aufbau und wie die Programme arbeiten aber rein theoretisch sollte es doch so aussehen können: Lese Anzahl kerne aus -> Schleife mit anzahl der Kerne -> Ein Vorgang an Kern abgeben -> zum nächsten Kern wechseln und Vorgang abgeben -> usw. bis alle durch sind und dann goto start() und nochmal von vorn. Ist das so schwer? Ich weiss es nicht, aber anscheinend schon, denn wie die Tage ja mitgeteilt wurde, ist Windows im Kern schon lange nicht mehr in der Lage die aktuellen Technologien voll zu unterstützen. Deswegen wird ja eben auch das Geschrei lauter Windows einer kompletten Überholung zu unterziehen und nicht die alten Scripte weiter zu schleppen, auf das sie noch älter werden. Ich frage mich, wie weit die Hardware schon wäre, wenn die Software es zuließe.
 
@Hawk18x:
Richtig und wenn man mal damit angefangen hat, besitzt man bald auch ein gutes wissen, baucht dadurch nicht länger und zudem wird es bald bibliotheken geben die so etwas dam programmierer vereinfachen, etwas anderes wäre es wenn es im cpu integriert eine schnitstelle geben würde die dieses automatisiert.
Da sollten sich die grossen zwei mal gedanken machen.
 
@Hawk18x: hihi, Du hast genau das interessante weggelassen. Welchen Vorgang willst Du abgeben? Hier mal eine Aufgabe für Dich: Ich möchte die Fibonacci-Zahlen bis 1.000.000 berechnen. Eine Fibonacci-Zahl berechnet sich aus der Summe der beiden vorhergehenden Zahlen. Also 1, 1, 2 (=1+1), 3 (=1+2), 5 (=2+3), 8 (=3+5), 13 (=5+8), ... Zeig mir bitte wie ich da was parallel berechne.
 
@ timurlenk: Du hast völlig recht, daß man diese Aufgabe, wie verschiedene andere mathematische Berechnungen nicht parallel rechnen kann. Heute bricht bei einen Single-Core schon der parallel laufende Mediaplayer ein, wenn ich mit dem Windows Taschenrechner 'nur' die Fakultät von knapp Unendlich berechne. In Zukunft wird solch eine Berechnung keine andere Anwendung tangieren, denn jeder Task, der heute per Multitasking läuft, bekommt einen eigenen Kern, dessen Takt er beliebig anpassen kann. Stell Die einmal vor, bei der Berechnung der Mandelbrotmenge (Apfelmännchen) für jeden Bildschirmpunkt einen eigenen Prozessor zur Verfügung zu haben. Man könnte die Parameter in Realtime ändern, und könnte die neuen Berechnungen in FPS messen. Apfelmännchen: http://www.th-soft.com/software/wincigd.zip
 
@timurlenk: die Fibonacci-Zahlen sind das perfekte Beispiel, danke dafür. Das Beispiel, warum parallelisieren genial ist: f_n ist nämlich nicht nur f_{n-1} + f-{n-2} sondern auch 1/sqrt(5) * (((1+sqrt(5))/2)^n - ((1-sqrt(5))/2)^n) und jetzt der Punkt: der "dumme" Programmierer handelt sich Datenabhängigkeiten ein, andere prallelisieren das Problem zur Berechnung mit beispielsweise 3.000.000 Recheneinheiten (zugegebenerweise steigt der arithmetisch logische Aufwand mit n immernoch stark an (2*n Multiplikationen), aber selbst die ließen sich auch noch parallelisieren, wenn man will. Entscheidend jedenfalls ist, dass viel zu viele Programmierer schlicht nur sequentiell denken [können/wollen] und jetzt der schwerste Schock für alle Programmierer: real world is parallel.
 
@ TPW1.5: Hihi, da hab ich ja wirklich das perfekte Beispiel erwischt. Ich bin leider kein Mathematiker und wusste nicht, dass es eine Formel für die Fibonacci-Zahlen gibt. Ich habe also erst mal ein Problem, dass erst einmal durch mehrere Prozessoren nicht optimiert werden kann (my way). Da stimmen meine Aussagen dann alle. Nun gibt es aber bei manchen Problemen die Möglichkeit durch Gehirnschmalz (dank den Mathematikern de Moivret, Binet, Euler, Bernoulli) das Problem so zu ändern, so dass eine parallele Verarbeitung möglich ist. Leider dürften sich wenige mit solchen Leuten messen können. Schon solch simple Dinge wie Sortieren von Zahlen erfordert etwas Hinschmalz, wenn man das parallel machen will. Die meisten Probleme sind aber deutlich komplexer oder enthalten sehr oft sequentielle Abschnitte. Beispiel: Eingabe muss vor der Berechnung erfolgen.
 
@awolf: Jedem Task einen eigenen Kern ist nur für die Theorie interessant. Meinst Du Prozesse, dann wäre das noch sinnvoll, für Threads nicht. Da Threads sich einen Adressraum teilen, würden verteilte Threads einen hohen Kommunikationsaufwand bedingen, da verschiedene Prozessoren gleichzeitig auf die gleichen Daten zugreifen. Durch das Caching würdest Du große Probleme bekommen, es sei denn alle teilen sich einen Cache, der dann aber einen Flaschenhals darstellt. Das gleiche Problem hast Du mit Speicher, Du könntest nur anfangen auch verteilten Speicher jedem einzelnen Prozessor zuzuweisen. Bei einer Verteilung von Threads bekommst Du aber dann die Hölle an Kommunikation. Zusammenfassend kann man sagen, dass eine Verteilung von Threads mit heutigen Technologien in der Regel keinen Sinn macht. Eine Verteilung von Prozessen schon. Einen Wechsel von Multi-Threaded-Programmen zu Multi-Prozessed-Programmen bringt aber die Nachteile der Prozesse wie langsameren Prozesswechsel. Nicht umsonst hat auch Linux inzwischen das Thread-Konzept übernommen. Fazit: Pralllelisierung ist ein sehr kompliziertes Thema und ich wage immer noch zu bezweifeln, dass 1000 Kerne für einen Arbeitsplatz sinnvoll sind.
 
@timurlenk: und vor der eingabe muss der pc gestartet sein. und davor muss man ihn zusammenbauen.
 
ich dachte die mondlandung hätten wir schon hinter uns?
 
schwachsinnig... winamp braucht 1 core, antivir 1 core, browser 1 core, so nun hab ich noch 20 core frei, für was? 20 ungenutzte core? leerlauf? ganz klasse, als hätten wir keine zeit dafür zu warten das das eine programm ne halbe sek rechenpower benutzt und dann das andere programm abgearbeitet wird, wer diese beispielrechnung nicht versteht braucht auch nich zu kommentieren
 
@hardcore:
Mein komment, wenn du keine 20 core's brauchst, dann kauf dir keinen.
Wenn man sie aber brauchen kann....
 
@hardcore: Stimmt, in meinem Dualcore sind sind so gut wie nie beide Kerne ausgelastet. Kann man sehr schön monitoren. Wenn ich es schon selten schaffe 2 Cores auszulasten, dann wird das bei 1000 Cores nicht besser.
 
@hardcore: Hast Du bereits die parallel laufenden Prozesse eines frisch ausgelieferten VISTA gezählt? Das OS muß komplett neu programmiert werden, wenn wirklich jeder Prozeß unabhängig auf einem eigenen Kern laufen soll. Es gibt viel zu tun. Auch Dein ANTIVIR muß neu programmiert werden, wenn Du Dir keinen Flaschenhals einfangen möchtest.
 
Man sollte mal den Programmierer von uns Menschen befragen, denn der hat das Problem bereits gelöst. Zumindest bei den meisten Leuten... :-))
 
@Absolon: Vergleiche einmal die Leistung von Frauen (Parallelbetrieb) mit den Fähigkeiten von Männern. Er kann sicherlich schneller ein spezielles Problem erledigen, während Frau in der Küche, drei Gerichte gleichzeitig kocht, gelegentlich im Kochbuch nachliest, auf das Kind aufpaßt, und nebenbei seelenruhig mit ihrer Freundin telefonieren kann.
 
Also um ein Programm für Multi-Cores zu optimieren - es in viele Threads zu zerlegen, ist im Anfangsstadium der Entwicklung ein sehr hoher Planungsaufwand nötig. Häufig greifen Threads auf die selbe Ressource zu und müssen aufeinander warten oder oft ist für eine Berechnung ein bestimmtes Zwischenergebnis nötig, also entsteht wieder eine Zeit in der ein Thread warten muss. Ausserdem entstehen wiederum viele Fehlerquellen wie ein Life- oder Dead-Lock. Ich glaube irgendwie nicht, dass es für eine Software-Entwicklungsfirma wirtschaftlich ist, einen so hohen Entwicklungsaufwand zu betreiben und die Software dann für 79 EURO zu verkaufen. Für viele Ingeniere wäre dies bestimmt eine gern angenommene Herausforderung, aber da ziehen einem die BWLer von oben einen Strich durch die Rechnung ...
 
@heidiho: Man müßte diese Problematik IMHO im Compiler lösen und nicht in der Programmierung selber. Der Compiler müßte den Code analysieren und sehen wo er auf mehrere Cores ausscheren kann und wo nicht. Aber ich bezweifel auch im gleichen Satz dass man so einen Compiler überhaupt bauen kann, weil es ja eine sehr sehr komplexe Sache ist Code für Multicoresysteme zu erzeugen.
 
Grand Central ist so eine Technologie, für mehrere Prozis. "achselzuck"
 
Uii. Ich seh grad das MS schon kräftig dabei ist das .NET Framework für mehrere Kerne aufzumotzen. http://tinyurl.com/6chb9b
Kommentar abgeben Netiquette beachten!

Intels Aktienkurs in Euro

Intel Aktienkurs -1 Jahr
Zeitraum: 1 Jahr

Beiträge aus dem Forum

Weiterführende Links

WinFuture Mobil

WinFuture.mbo QR-Code Auch Unterwegs bestens informiert!
Nachrichten und Kommentare auf
dem Smartphone lesen.

Folgt uns auf Twitter

WinFuture bei Twitter

Interessante Artikel & Testberichte

WinFuture wird gehostet von Artfiles