Archiv verlassen und diese Seite im Standarddesign anzeigen : Intel - 15 GHz im Jahr 2010 - Intels Sicht 2002
AnarchX
2009-12-31, 10:43:45
Speed is the essence
Desktop processors to hit 15GHz by 2010, says Intel
Users can expect to see the processing speed of Intel's desktop processors hit 15GHz by 2010, while chips powering wireless devices and PDAs (personal digital assistants) will reach 5GHz, according to the chip maker's chief technology officer.
The 15GHz desktop chip, some five times as fast as the company's soon-to-be-launched 3GHz Pentium 4 processor, will pack one billion transistors, said Pat Gelsinger (pictured), vice president and chief technology officer of Intel as he delivered a keynote address to the company's Intel Developer Forum Japan conference in Tokyo today. [...]
http://www.pcadvisor.co.uk/news/index.cfm?newsid=2823
Mit 1 Mrd. Transistoren hat man Gulftown und Thuban doch ziemlich genau getroffen. Aber mit der Taktrate hat sich doch ziemlich verschätzt, was aber frühzeitig offensichtlich wurde.
Die Leistung konnte man dank vernünftigerer Architekturkonzepte doch im gewünschten Maß steigern: http://www.anandtech.com/bench/default.aspx?p=99&p2=93
Die Leistung dürfte teilweise deutlich mehr als Faktor 5 angestiegen sein. Dafür wären bei einer 15GHz-Cpu so gut wie keine keine großen Softwareoptimierungen nötig gewesen. So muss man eben neue Programmiermethoden entwickeln und anwenden. Die 15GHz wären so wahrscheinlich nicht der schnellere aber der billigere weg gewesen (rein hypothetisch).
Aber mit der Taktrate hat sich doch ziemlich verschätzt, was aber frühzeitig offensichtlich wurde.
Es sieht mir nicht danach aus, als ob sich wer verschätzt hätte, vielmehr nahm alles eine andere Entwicklung als geplant!
Wir dürfen nicht den Fehler machen und die Taktraten mit heutiger Technologie auf Netburst zurückführen, das wäre ein fataler Fehler. Ich denke mit der 32nm Fertigung wären problemlos Taktraten im Bereich vieler GHz möglich. Das wahre Potential kennen wir ja gar nicht, weil es noch keiner so richtig ausprobiert hat!
Netburst selbst ist ja längst überholt, die Technologie ist bestimmt schon 10-13 Jahre alt. Würde man einen Prozessor von grundauf designen, wäre der sicherlich besser als Netburst, aber es lohnte sich ja nicht diesen Weg zu gehen, wie es scheint [vielleicht wars auch ein zu großes Risiko].
Die ersten Pentium 4 mit dem Codenamen Willamette liefen mit Taktfrequenzen von 1,4 und 1,5 GHz und kamen im November 2000 auf den Markt.
Was vielmehr interessant wäre, ob es damals schon den Plan gegeben hat, Mehrkernprozessoren zu bauen, als das ganze noch nicht absehbar gewesen ist.
Das Problem der hohen Leckströme wäre geblieben. Das ist kein Designproblem des P4 sondern eines, dass sich aus der Fertigung im <100nm ergibt. Wäre das Problem schon bei 180nm oder früher aufgtreten wäre der P4 nie so erschienen.
Wenn man sich ansieht wie sich neuere cpus (65, 45, 32nm) bei extrem oc verhalten kann man dort nur noch marginale Fortschritte bei der maximal möglichen Taktrate feststellen.
no6ody
2009-12-31, 12:22:33
Das Problem der hohen Leckströme wäre geblieben. Das ist kein Designproblem des P4 sondern eines, dass sich aus der Fertigung im <100nm ergibt. Wäre das Problem schon bei 180nm oder früher aufgtreten wäre der P4 nie so erschienen.
Wenn man sich ansieht wie sich neuere cpus (65, 45, 32nm) bei extrem oc verhalten kann man dort nur noch marginale Fortschritte bei der maximal möglichen Taktrate feststellen.
Das kann man sowieso nicht vergleichen. Wenn dann muesste es wirklich die gleiche Architektur in den verschiedenen Strukturgroessen geben.
Man koennte sicherlich auch CPUs herstellen, die einfach auf eine hohe Taktrate getrimmt sind.
Das hat man doch mit dem Prescott versucht indem man noch zusätzliche Stufen in der Pipeline hinzugrfügt hat und gleichzeitig einen kleineren Fertigungsprozess benutzt hat (65 statt 90nm).
Das hätte theoretisch ein enormes Taktpotenzial bedeuten müssen.
Am Ende hat man es gerade mal auf 3.8 Ghz gebracht (mit dem Prescottnachfolger!) und das von 3.2 Ghz des Northwood aus.
Bei den Highendmodellen musste man auf den Gallatin ausweichen, weil der zusätzliche lvl3 Cache deutlich mehr gebracht hat als die Taktratensteigerungen hergaben.
die Abschätzung gilt ja nur für Netburst, zum Glück hat Intel das Design in die Tonne gekloppt und sich Richtung Effizienz orientiert
Hoffen wir das AMD wieder nachzieht und der Bulldozer mit 2.5Ghz so schnell wie ein Deneb mit 4Ghz ist
Der Prescott war allerdings nur eine weiterentwicklung und keine neue Architektur, das sollte man auch sehen.
Außerdem hat Intel auch nen 4.26 GHz P4 für Dell geliefert gehabt, möglich wäre da bestimmt noch was gewesen.
Die aktuelle Architektur erreicht auch schon sehr hohe Werte, erst kürzlich gab es einen neuen Rekord, 6,92 GHz mit einem Core i5 Duo. Das ist gemessen an der Tatsache, das die Architektur nicht auf Taktrate ausgelegt ist, schon ziemlich weit über Standard und gerade mal der Anfang [32nm]
Vielleicht hat Prescott die 64-Bit-Anflaschung das Genick gebrochen? Das Taktpotenzial war damals nicht das Problem, sondern die Verflustleistung und der anfangs mäßige (da mit hohen Leckströmen behaftete) 90nm-Prozess.
Die 65nm Prescotts (=Cedar Mill) konnten mit ~ 1.2V weit über 4 Ghz schaffen und haben dabei nicht mal soooo viel Energie verheizt. Im Vergleich zum C2D war die Leistung allerdings auch nicht überragend.
Genau das meinte ich vorhin der i5 erreicht kaum mehr als ein 45nm PhenomII.
Wäre sowas beim Wechsel von 180nm auf 130nm (Willamette->Northwood) passiert wäre Das ein Supergau gewesen.
Vielleicht hat Prescott die 64-Bit-Anflaschung das Genick gebrochen? Das Taktpotenzial war damals nicht das Problem, sondern die Verflustleistung und der anfangs mäßige (da mit hohen Leckströmen behaftete) 90nm-Prozess.
Die 65nm Prescotts (=Cedar Mill) konnten mit ~ 1.2V weit über 4 Ghz schaffen und haben dabei nicht mal soooo viel Energie verheizt. Im Vergleich zum C2D war die Leistung allerdings auch nicht überragend.
Eher der A64, der mit 2.6 GHz und mit weniger Verlustleistung fast das gleiche erreicht hat. Und die damals langsam aufkommenden PentiumM-Desktopboards auf denen man das Gleiche mit 2.4 Ghz geschafft hat (und der hatte noch eine wesentlich schlechtere IPC als der Core2).
Leonidas
2009-12-31, 13:07:55
Irgendwo in diesem Forum schwirren auch noch tolle Roadmaps rum wie von Nehalem als P4-Fortsetzung mit Taktraten bis zu 10 GHz im Jahr 2007 oder so ;)
Eher der A64, der mit 2.6 GHz und mit weniger Verlustleistung fast das gleiche erreicht hat.
Ende 2000 = 2003
Da liegt schon ein haufen Zeit zwischen, insbesondere in der Entwicklung. Würde man das gleiche Beispiel auf andere Bereiche wie Grafikkarten übertragen, wären die alten immer hoffnungslos unterlegen...
Zeit ist ebenfalls wichtig, wenn es um Technologien geht. Manche Erfahrungen müssen auch erst gemacht werden, bevor gewisse Fehler vermieden werden können. Wer weiß schon, was morgen ist? Das war jetzt ist, muss nicht ewig bleiben, vielleicht sehen wir irgendwann ähnliche Probleme und Grenzen und dann gehts wieder von vorn los.
Avalox
2009-12-31, 13:30:45
Die 15GHz wären so wahrscheinlich nicht der schnellere aber der billigere weg gewesen (rein hypothetisch).
Doch ganz sicher wäre es der schnellere Weg gewesen.
Die Effizienz der Parallelisierung erreicht ja bei weiten nicht die Effizienz der reinen Takterhöhung.
Es ist schlicht eine physikalische Barriere aufgetreten, mit welcher nicht gerechnet wurde, eine Barriere welche sich als nachhaltiges Hindernis heraus gestellt hat.
Auch eine hyptetische 15GHz CPU hätte die IPC erhöhen können und auch an einer 15GHz CPU hätte man mehrere Kerne parallelisieren können.
Jeglicher Fortschritt dort unterliegt allein der Wirtschaftlichkeit und der technischen Fertigkeit.
Und eben die technische Fertigkeit ist limitiert worden, durch die zumindest momentan nicht technisch zu beherrschende physikalisch Barriere.
Es wäre besser, wenn wir heute 15GHz CPUs hätten zweifelsfrei. Aber wir haben keine 15GHz CPUs also müssen wir uns mit ineffektiver Parallelisierung rumschlagen. Das Mooresche Gesetz ist eingehalten worden, aber um eben einen Preis.
Was so oder so gekommen wäre, aber dann wäre es eben erst bei der 40GHz CPU in ein paar Jahren gekommen.
Intel hat das aber schon ein paar Stufen länger durchgezogen als nötig war um zu erkennen das Das Konzept nicht aufgeht.
Schon allein deshalb, weil Sie ja trotzdem gutes Geld damit verdient haben.
Das ist aber ein ganz anderes Thema.
Doch ganz sicher wäre es der schnellere Weg gewesen.
Die Effizienz der Parallelisierung erreicht ja bei weiten nicht die Effizienz der reinen Takterhöhung.
Es ist schlicht eine physikalische Barriere aufgetreten, mit welcher nicht gerechnet wurde, eine Barriere welche sich als nachhaltiges Hindernis heraus gestellt hat.
Auch eine hyptetische 15GHz CPU hätte die IPC erhöhen können und auch an einer 15GHz CPU hätte man mehrere Kerne parallelisieren können.
Jeglicher Fortschritt dort unterliegt allein der Wirtschaftlichkeit und der technischen Fertigkeit.
Und eben die technische Fertigkeit ist limitiert worden, durch die zumindest momentan nicht technisch zu beherrschende physikalisch Barriere.
Es wäre besser, wenn wir heute 15GHz CPUs hätten zweifelsfrei. Aber wir haben keine 15GHz CPUs also müssen wir uns mit ineffektiver Parallelisierung rumschlagen. Das Mooresche Gesetz ist eingehalten worden, aber um eben einen Preis.
Was so oder so gekommen wäre, aber dann wäre es eben erst bei der 40GHz CPU gekommen.
Wenn es gar keine physikalischen Barrieren gäbe wäre die CPU mit der höchsten IPC immer die beste.;)
Avalox
2009-12-31, 13:43:40
Wenn es gar keine physikalischen Barrieren gäbe wäre die CPU mit der höchsten IPC immer die beste.;)
Die CPU ist am besten, welche eine hinreichende Performance für die geringsten Kosten erreicht.
Auch heute könnte man weit schnellere CPUs bauen, als alles was wir kennen. Diese wären nur eben so teuer, dass man damit keinen Massenmarkt bedienen kann.
Die physikalische Barriere, welche Netburst zum Opfer gefallen ist nicht absolut.
Voller Vertrauen auf ihr Fertigungstalent wollte man eine Architektur haben, welche Erfolge in der Fertigungstechnologie sofort umsetzen kann. Kleine DIE, progressives auf Taktprobleme optimiertes Design.
Intel postulierte die vergangene Entwicklung einfach in die Zukunft und ging damit baden, weil eben genau die erhofften Taktsteigerungen trotz immer kleinerer Herstellungsprozesse nicht möglich waren.
Naja im HPC-Markt wäre das Geld wohl schon vorhanden.
Aber dort setzt man eigentlich schon immer auf eine möglichst hohe parallelisierbarkeit.
StefanV
2009-12-31, 14:03:37
Das kann man sowieso nicht vergleichen. Wenn dann muesste es wirklich die gleiche Architektur in den verschiedenen Strukturgroessen geben.
P4 5xx -> 600 bzw PD 8xx -> 9xx.
Bei AMD die ganzen S939 K8 (Hammer, Newcastle, Venice, Winchester (Ex) ist etwas anders), bzw auch Phenom -> Phenom 2 und eben die Core2s...
Ein kleinerer Fertigungsprozess bringt also schon was, nur eben nicht (mehr) wirklich viel...
=Floi=
2009-12-31, 16:07:07
ihr habt immer den gleichen denkfehler in der paralelisierung!
mit mehr cores und mehr threads kann man auch erheblich mehr software gleichzeitig laufen lassen bzw. an mehreren problemen gleichzeitig rechen.
ich finde den aktuellen weg wesentlich besser und die performance pro core ist trotzdem gestiegen. wenn sich das ganze im verhältnis bleibt, dann ist der aktuelle weg sicherlich der bessere.
ihr habt immer den gleichen denkfehler in der paralelisierung!
mit mehr cores und mehr threads kann man auch erheblich mehr software gleichzeitig laufen lassen bzw. an mehreren problemen gleichzeitig rechen.
ich finde den aktuellen weg wesentlich besser und die performance pro core ist trotzdem gestiegen. wenn sich das ganze im verhältnis bleibt, dann ist der aktuelle weg sicherlich der bessere.
Was meinst du mit "mehr Software laufen lassen?".
Ich habe mit einem 4X3Ghz im Vergleich soviel Rechenzeit zur Verfügung wie mit einem 12GHz Singlecore abzüglich des Threadverwaltungsaufwandes und noch viel weniger wenn die einzelnen Threads auf die Ergebnisse des jeweils anderen warten müssen und deshalb warten muss.
(es sei denn er kann in der Zwischenzeit was Anderes tun, was wiederum die Aufgabe des Schedulers des BS ist und nichts mit irgendwelchen Hardwarekonzepten zu tun hat).
SavageX
2009-12-31, 16:21:50
Jein. Wenn sich ein einzelner Kern mit vielen Prozessen herumschlagen muss werden die Kontextwechsel schnell lästig.
Jein. Wenn sich ein einzelner Kern mit vielen Prozessen herumschlagen muss werden die Kontextwechsel schnell lästig.
Das kommt auf den Prozessor an.
Der P4 hatte eben eine extrem lange Pipeline, in der jeglicher Abbruch/Änderung etc. doppelt weh tut als in einer kürzeren.
Außerdem kann man solche Problemen mit Techniken wie HT oder virtuellen Kernen entgegenwirken.
Jein. Wenn sich ein einzelner Kern mit vielen Prozessen herumschlagen muss werden die Kontextwechsel schnell lästig.
Es vergehen Mio. Cycles zwischen Context-Switches und es wird auch nur das gescheduled was gerade aktiv ist.
Außerdem hätte man auch mit nur einem Core wohl trotzdem die gleiche Cache-Größe und somit entfällt auch der Nachteil durch Cache-Trashing.
Der P4 hatte eben eine extrem lange Pipeline, in der jeglicher Abbruch/Änderung etc. doppelt weh tut als in einer kürzeren.
Die Pipeline wird durch den Context-Switch nicht "abgebrochen". Und selbst wenn wäre das nichtmal im Entferntesten ein Performance-Problem.
=Floi=
2009-12-31, 17:28:25
wenn ein programm einen prozessor komplett auslastet dann steht das ganze system. das kennt doch jeder noch von den singlecore prozessoren.
mit multicore kann ich auch mehrere aufwendige programme laufen lassen und brauche dafür nicht mehrere rechner. bei zeitkritischen anwendungen "hängt" auch nichts. ich sehe das als größeren vorteil. wenn genug cores vorhanden sind, dann ist es kein problem, wenn einer mit der verwaltung der andere beschäftigt ist... Es sollte so sogar effizienter und energiesparender sein, weil eben ein langsamer mehrkernprozessor sparsamer sein kann wie ein schneller mit weniger kernen und hoher verlustleistung.
wenn ein programm einen prozessor komplett auslastet dann steht das ganze system.
Nein. Dann steht Windows, weil es in der Hinsicht nicht gerade optimal designed ist. Wahrscheinlich gibt es einen Big Kernel Lock.
wenn ein programm einen prozessor komplett auslastet dann steht das ganze system. das kennt doch jeder noch von den singlecore prozessoren.
mit multicore kann ich auch mehrere aufwendige programme laufen lassen und brauche dafür nicht mehrere rechner. bei zeitkritischen anwendungen "hängt" auch nichts. ich sehe das als größeren vorteil. wenn genug cores vorhanden sind, dann ist es kein problem, wenn einer mit der verwaltung der andere beschäftigt ist... Es sollte so sogar effizienter und energiesparender sein, weil eben ein langsamer mehrkernprozessor sparsamer sein kann wie ein schneller mit weniger kernen und hoher verlustleistung.
Nur konnte das bei nem P4, wegen HT, nie passieren.
Botcruscher
2009-12-31, 17:34:35
wenn ein programm einen prozessor komplett auslastet dann steht das ganze system. das kennt doch jeder noch von den singlecore prozessoren.
Der Taskmanager wirkt wahre Wunder.:rolleyes:
Rohleistung bleibt Rohleistung und ich würde einen 16GHz SC klar vor dem 4GHz Quad (Milchmädchenrechnung) vorziehen. Multicore ist eine teure und umständliche Krücke weil der Takt nicht drin ist, mehr nicht.
Nur konnte das bei nem P4, wegen HT, nie passieren.
Doch, konnte es. Nämlich wenn ein Programm beide Threads 100% auslastet.
Das ganze sieht man sehr gut, wenn man z.B. Linpack laufen lässt. Kaum ist die CPU unter Last bekommt es der Windows-Kernel nicht mehr fertig DNS-Abfragen vom Browser zu bearbeiten. Dinge die keine Kernel-Calls brauchen sind davon aber unberührt, sie bekommen eben ihren Timeslot ab.
Eigentlich sollte man Microsoft dafür schlagen, dass sie das im Jahr 2009 immer noch nicht hinbekommen haben. Linux macht da seit 2.6 überhaupt keine Zicken mehr. Selbst auf einem Uniprozessor-System ist es fast immer reaktiv.
Wahrscheinlich ist es ihnen jetzt aber erst recht egal, weil ja sowieso jeder Multicore-Systeme hat.
Exxtreme
2009-12-31, 17:42:58
ihr habt immer den gleichen denkfehler in der paralelisierung!
mit mehr cores und mehr threads kann man auch erheblich mehr software gleichzeitig laufen lassen bzw. an mehreren problemen gleichzeitig rechen.
ich finde den aktuellen weg wesentlich besser und die performance pro core ist trotzdem gestiegen. wenn sich das ganze im verhältnis bleibt, dann ist der aktuelle weg sicherlich der bessere.
Ein 15 GHz SC-Prozessor wäre wohl die weit bessere Alternative als ein niedriger getakteter QC.
Bei mehreren Kernen steigt der Kommunikations-/Synchronisationsaufwand, vieles lässt sich nicht sinnvoll parallelisieren etc.
Doch, konnte es. Nämlich wenn ein Programm beide Threads 100% auslastet.
Das ganze sieht man sehr gut, wenn man z.B. Linpack laufen lässt. Kaum ist die CPU unter Last bekommt es der Windows-Kernel nicht mehr fertig DNS-Abfragen vom Browser zu bearbeiten. Dinge die keine Kernel-Calls brauchen sind davon aber unberührt, sie bekommen eben ihren Timeslot ab.
Eigentlich sollte man Microsoft dafür schlagen, dass sie das im Jahr 2009 immer noch nicht hinbekommen haben. Linux macht da seit 2.6 überhaupt keine Zicken mehr. Selbst auf einem Uniprozessor-System ist es fast immer reaktiv.
Wahrscheinlich ist es ihnen jetzt aber erst recht egal, weil ja sowieso jeder Multicore-Systeme hat.
"nie" war eine nicht zu Ende gedachte Formulierung. Was ich eigentlich meinte ist das:
Gäbe es die Takt-Barriere nicht, und hätte man mit dem Takt-Spielchen weitergemacht, hätte es auch die heutige Multi-Core-optimierte Software nicht gegeben. 1 oder höhstens 2 Threads wären die Norm.
Ich erinnere mich recht gut wie der Northwood sich damals angefühlt hat. Weil es damals kaum Software gab, die mehrere Threads nutzte, war es praktisch unmöglich das System in die Knie zu zwingen.
Man muss aber auch zugeben dass, das Multicoredesign auch einige Vorzüge bietet. Unter anderem ist es relativ einfach die Rechenleistung zu erhöhen durch zusätzliche Kerne.
Bei einem Singlecore wäre man allein von der Fertigungstechnik und der IPC.
Natürlich immer unter der Voraussetzung das die Aufgaben auch irgendwie paraellelisierbar sind.
"nie" war eine nicht zu Ende gedachte Formulierung. Was ich eigentlich meinte ist das:
Gäbe es die Takt-Barriere nicht, und hätte man mit dem Takt-Spielchen weitergemacht, hätte es auch die heutige Multi-Core-optimierte Software nicht gegeben. 1 oder höhstens 2 Threads wären die Norm.
Ich erinnere mich recht gut wie der Northwood sich damals angefühlt hat. Weil es damals kaum Software gab, die mehrere Threads nutzte, war es praktisch unmöglich das System in die Knie zu zwingen.
Das lag daran dass es schlicht so gut wie nichts gab, mit dem man beide Kerne auslasten konnte.
Und wie Coda schon gesagt hat ist es ein Designfehler im Betriebssystem, wenn es bei hoher Auslastung nichtmehr reagiert.
Das lag daran dass es schlicht so gut wie nichts gab, mit dem man beide Kerne auslasten konnte.
Und wie Coda schon gesagt hat ist es ein Designfehler im Betriebssystem, wenn es bei hoher Auslastung nichtmehr reagiert.
Ja, das sag ich doch.
Stimmt ich sollte das mit Lesen mir noch einmal ansehen. XD
Ja, das sag ich doch.
Ist nur leider falsch.
Das Problem bei Single Core Systemen ist die Interruptsteuerung. Ein DVD-LW was eine fehlerhafte DVD liest, kann jedes OS auf einem PC blockieren. Dies ist per Design so.
Daher kommen auch die großen Vorteile des HT bzw. DCs CPUs, da sie nicht (so einfach) blockiert werden können.
mfg
Naja im HPC-Markt wäre das Geld wohl schon vorhanden.
Aber dort setzt man eigentlich schon immer auf eine möglichst hohe parallelisierbarkeit.
Und hier kommt die von Avalox angesprochene Wirtschaftlickeit zu tragen.
Zudem will ich noch sahen, das beide Wege, zumindest für mich Vor und Nachteile bringen.
Einerseits, vergöttere ich jeden 3 Tag meinen Quadcore, seitdem es 4-Kerner gibt. Neben Renderaufgaben die jeden Tag anfallen, kann ich nebenbei ungestört modeln, Musik laufen lassen oder einfach da neben, nochmal FIFA oder PES anschmeißen und mit meinen Arbeitskollegen ne gepflegte Runde zocken. Einfach immer wieder wunderschön.
Andererseits wird es schnell nervig sobald unparallesierbare Aufgaben anfallen. Partikelsysteme (pFlow oder particular von Trapcode zB) werden schnell zu einem Krückstock.
Hier wären 15GHz wohl ein wahrer Traum.
Wenn ich zwischen beiden Wegen whlen dürfte, würde ich mit Sicherheit wieder zu einem MultiCore greifen.
Warum?
Weil es zu diesem Zeitpunkt, zu diesem Preis keine alternative S-CPU geben würde, wie ein hochgezüchteter i7.
Wenn die Entwicklung so verlaufen wäre, wie es die Roadmap sagt, so würde ich trotzdem zu einer M-CPU greifen.
Ich kann hier die Lasten immer so verstellen wie ich das möchte. Wenn ich rendern will, weise ich einfach 2 der CPUs dazu und teile die anderen anders auf. Für eine Singlecorelösung müsste hier schon eine ähnliche Prozessstruktur geben, damit es attraktiver wird.
mfg
StefanV
2009-12-31, 18:35:35
Das Problem bei Single Core Systemen ist die Interruptsteuerung. Ein DVD-LW was eine fehlerhafte DVD liest, kann jedes OS auf einem PC blockieren. Dies ist per Design so.
Das ist leider falsch.
Denn es betrifft nur DVD-ROMs, die am verlängerten AT-Bus hängen, nicht SCSI Laufwerke!
Das Problem bei Single Core Systemen ist die Interruptsteuerung. Ein DVD-LW was eine fehlerhafte DVD liest, kann jedes OS auf einem PC blockieren
Man kann auch Interrupts re-entrant programmieren. Ansonsten gäbe es keine Real-Time-Betriebssysteme.
Man kann auch Interrupts re-entrant programmieren. Ansonsten gäbe es keine Real-Time-Betriebssysteme.
Realtime heißt aber nur, das der jeweilige Task/Codeabschnitt spätestens zum Zeitpunkt X fertig ist, nicht mehr nicht weniger. Dies läßt sich auch mit (zeitweise) deaktivierten Interrupts machen. Polling gibt es afaik in aktueller Standdardtechnik nicht.
@StefanV das DVD-LW war nur ein Beispiel, jedes Gerät was Interrupts auslösen kann, welcher eine höhere Priorität haben, als das OS kann es blockieren. Da ist es egal ob es SCSI, IDE, PCI oder sonst was ist.
Das CD/DVD ist nur ein sehr bekanntes Beispiel.
Realtime heißt aber nur, das der jeweilige Task/Codeabschnitt spätestens zum Zeitpunkt X fertig ist, nicht mehr nicht weniger.
Nein, tut es nicht. Realtime-Betriebssystem garantieren eine vorgegebene Latenz bei Systemaufrufen und Scheduling.
@StefanV das DVD-LW war nur ein Beispiel, jedes Gerät was Interrupts auslösen kann, welcher eine höhere Priorität haben, als das OS kann es blockieren. Da ist es egal ob es SCSI, IDE, PCI oder sonst was ist.
Ein Interrupt blockiert nicht. Nur der Interrupt-Handler blockiert, wenn er will.
Es gibt auch keine Interrupts die "eine höhere Priorität haben, als das OS". Jeder Interrupt-Handler liegt in Ring-0-Kernel-Code.
Und hier kommt die von Avalox angesprochene Wirtschaftlickeit zu tragen.
Zudem will ich noch sahen, das beide Wege, zumindest für mich Vor und Nachteile bringen.
Einerseits, vergöttere ich jeden 3 Tag meinen Quadcore, seitdem es 4-Kerner gibt. Neben Renderaufgaben die jeden Tag anfallen, kann ich nebenbei ungestört modeln, Musik laufen lassen oder einfach da neben, nochmal FIFA oder PES anschmeißen und mit meinen Arbeitskollegen ne gepflegte Runde zocken. Einfach immer wieder wunderschön.
Andererseits wird es schnell nervig sobald unparallesierbare Aufgaben anfallen. Partikelsysteme (pFlow oder particular von Trapcode zB) werden schnell zu einem Krückstock.
Hier wären 15GHz wohl ein wahrer Traum.
Wenn ich zwischen beiden Wegen whlen dürfte, würde ich mit Sicherheit wieder zu einem MultiCore greifen.
Warum?
Weil es zu diesem Zeitpunkt, zu diesem Preis keine alternative S-CPU geben würde, wie ein hochgezüchteter i7.
Wenn die Entwicklung so verlaufen wäre, wie es die Roadmap sagt, so würde ich trotzdem zu einer M-CPU greifen.
Ich kann hier die Lasten immer so verstellen wie ich das möchte. Wenn ich rendern will, weise ich einfach 2 der CPUs dazu und teile die anderen anders auf. Für eine Singlecorelösung müsste hier schon eine ähnliche Prozessstruktur geben, damit es attraktiver wird.
mfg
Tjo, bei einer hypothetischen SC 15GHz CPU könntest du halt im Task-Manager die Priorität des Renderers auf sehr niedrig stellen, und schon hast du genug Power für all die anderen Sachen. ;)
Tjo, bei einer hypothetischen SC 15GHz CPU könntest du halt im Task-Manager die Priorität des Renderers auf sehr niedrig stellen, und schon hast du genug Power für all die anderen Sachen. ;)
:)
Ha, natürlich. Das geht auch.
Das ist mir aber etwas zu "verschwommen". Ich denke aber mal das es irgendwann auch da etwas angenehmer gestaltet weren würde, würde man diesen Weg noch weiter gehen.
Mir gefällt das an und abschalten der Kerne schon ziemlich gut. Es ist eifach klar was genau weggeht und was noch da ist.
mfg
:)
Mir gefällt das an und abschalten der Kerne schon ziemlich gut. Es ist eifach klar was genau weggeht und was noch da ist.
mfg
Aber es ist ineffizient ;)
Man kann es drehen und wenden wie man will. Taktsteigerung heißt - bei rein rechenleistungsabhängigen Anwendungen - 100%ige Skalierung und einfachste Ressourcenallokation. Ich hätte auch lieber 15 GHz als 4 Kerne.
=Floi=
2010-01-01, 13:21:54
das stimmt leider beides nicht! es muß nicht ineffizienter sein und ein chip skaliert nicht (immer) 100% mit dem takt mit.
das stimmt leider beides nicht! es muß nicht ineffizienter sein und ein chip skaliert nicht (immer) 100% mit dem takt mit.
Ja wenn Etwas nicht rechenleistungslimitiert ist.
Aber dann bringt der Multicore auch nicht mehr sondern die Perepherie (z.B Speicher) muss angepasst werden.
das stimmt leider beides nicht! es muß nicht ineffizienter sein und ein chip skaliert nicht (immer) 100% mit dem takt mit.
Eine Applikation wird auf einem SC mit der gleichen effektiven Leistung (und gleichen Infrastruktur) immer schneller laufen als auf einem MC. Daran gibt es nichts zu rütteln.
Aber es ist ineffizient ;)
Man kann es drehen und wenden wie man will. Taktsteigerung heißt - bei rein rechenleistungsabhängigen Anwendungen - 100%ige Skalierung und einfachste Ressourcenallokation. Ich hätte auch lieber 15 GHz als 4 Kerne.
Programme Skalieren NIE zu 100% mit dem Takt da Cache, Ram, Festplatte etc. immer noch bremsen. Ein Athlon mit 2,6Ghz war keine 30% schneller als einer mit 2Ghz. Real Lagen 15% - 20% Unterschied dazwischen, also 50% bis 66%.
Eine gut Parallelisierte Software kann aber 100% Skalierung schaffen.
Supreme Commander ist ein schönes Beispiel wir ein Dualcore mehr als 100% schneller ist als ein SC.
Windows hat schon über 50 Threads (Linux ist es ähnlich) die müssen immer im Cache um kopiert werden beim Single Core ist das gravierend.
Ich bin entsetzt das hier im Forum noch Leute der Meinung sind das ein SC mit doppelten Takte besser ist das ein DC!
Das mag heute sein, wenn die Software noch nicht für Multicore ausgelegt ist langfristig ist aber der Multicore schneller und effizienter. Auch wenn es keine Elektromigration gäbe!
Ihr würden auch eine Grafikkarte mit einem Shader vorziehen, solange der Takt höher ist?!
Auch eine IPC Steigerung ist sehr schwer. Ich bin immer wieder überrascht wie Klug einige meine zu sein und die dumm die Mitarbeiter bei Intel und AMD etc. sein sollen.
Programme Skalieren NIE zu 100% mit dem Takt da Cache, Ram, Festplatte etc. immer noch bremsen.
Wenn das bremst, dann bremst es auch einen Multi-Core. Woher die Rechenleistung in der CPU kommt die dadurch gebremst wird ist für diese Bottlenecks doch völlig irrelevant.
Und natürlich skalieren Programme 100% mit dem Takt, wenn sie vollständig aus dem Cache laufen. Bei Multi-Cores hast du aber noch zusätzlich das Problem des Synchronisationsoverheads. Das entfällt bei Single-Cores vollständig. Das Multi-Core besser skaliert als doppelt so hoher Takt ist völlig Blödsinn. Das pure Gegenteil ist der Fall. Schau dir mal Amdahl's Law an.
Ich bin entsetzt das hier im Forum noch Leute der Meinung sind das ein SC mit doppelten Takte besser ist das ein DC!!
Die einzige Aussage die getroffen wird, ist dass ein doppelt so hoch getakteter Single-Core bei einer Applikation schneller wäre. Wer das nicht bezweifelt hat etwas grundsätzlich nicht verstanden.
Dass ein Multi-Core heute aus praktischen Gründen "besser" ist, ist eine völlig andere Geschichte.
Ihr würden auch eine Grafikkarte mit einem Shader vorziehen, solange der Takt höher ist?!
Nein. Hat keiner behauptet. Grafik ist inhärent parallelisierbar und transparent auf viele Kerne skalierbar. Das kannst du überhaupt nicht mit CPUs vergleichen.
Auch eine IPC Steigerung ist sehr schwer. Ich bin immer wieder überrascht wie Klug einige meine zu sein und die dumm die Mitarbeiter bei Intel und AMD etc. sein sollen.
Das hat auch nie jemand behauptet. Es gibt sehr gute Gründe für Multi-Cores. Die Aussage war nur, dass Single-Cores effizienter wären, wenn man den Takt wie früher skalieren könnte.
Eine gut Parallelisierte Software kann aber 100% Skalierung schaffen.
Das hängt eben stark von der Software ab.
Windows hat schon über 50 Threads (Linux ist es ähnlich) die müssen immer im Cache um kopiert werden beim Single Core ist das gravierend.
Warum sollte ein hypothetischer Singlecore weniger Cache haben?
Ich bin entsetzt das hier im Forum noch Leute der Meinung sind das ein SC mit doppelten Takte besser ist das ein DC!
In welchen Foren ist man denn anderer Meinung?
Das mag heute sein, wenn die Software noch nicht für Multicore ausgelegt ist langfristig ist aber der Multicore schneller und effizienter. Auch wenn es keine Elektromigration gäbe!
Gäbe es keine Elektronenmigration etc. die starke Taktanstiege bei kleineren Strukturen verhindern würden würde man überhaupt nicht in dem Stil auf Multicore optimieren.
Ihr würden auch eine Grafikkarte mit einem Shader vorziehen, solange der Takt höher ist?!
Da 3d Rendering eine sehr gut paraellisierbare Aufgabe ist, ist es dort weniger schlimm. Trotzdem geht sowohl im Grafikkartentreiber als auch in der Hardware selbst sehr viel Zeit und Geld drauf um dieEinheiten möglichst gut auszulasten.
Auch eine IPC Steigerung ist sehr schwer. Ich bin immer wieder überrascht wie Klug einige meine zu sein und die dumm die Mitarbeiter bei Intel und AMD etc. sein sollen.
Bist Du dir sicher das du den Thread von Anfang an gelesen hast?
Es gibt keine Alternative zu Multicore wegen den besagten physikalischen Grenzen.
Also muss man sich damit abfinden.
Ändern kann das Niemand. Auch keine schlauen Mitarbeiter von Intel ,AMD oder Sonstwem.
Mal blöd gefragt als Laie: Bei der Taktfrequenz ist man ja schon an physikalische Grenzen gestoßen, und bei der Erhöhung der Cores wird man auch irgendwann auf Grenzen stoßen. Nur, was will man dann an diesem Punkt noch machen, um schnellere CPUs zu bauen?
Avalox
2010-01-01, 19:15:36
Nur, was will man dann an diesem Punkt noch machen, um schnellere CPUs zu bauen?
Erstmal die einzelnen Kerne nicht nur nebeneinander, sondern auch übereinander zu bauen.
roidal
2010-01-01, 20:07:49
Mal blöd gefragt als Laie: Bei der Taktfrequenz ist man ja schon an physikalische Grenzen gestoßen, und bei der Erhöhung der Cores wird man auch irgendwann auf Grenzen stoßen. Nur, was will man dann an diesem Punkt noch machen, um schnellere CPUs zu bauen?
Andere Materialien welche nochmals eine Taktsteigerung zulassen und verbesserte Architekturen sollten da eventuell auch nochmal eine bessere Performance bieten.
Zum Beispiel Siliziumcarbid:
http://de.wikipedia.org/wiki/Siliziumcarbid
Botcruscher
2010-01-01, 20:55:35
Erstmal die einzelnen Kerne nicht nur nebeneinander, sondern auch übereinander zu bauen.
Die Komplexität der Verdrahtung ist ein Horror und die Kühlung nahezu unmöglich. Das Thema ist älter als die Tesarom.
Tigerchen
2010-01-02, 06:09:15
Mal blöd gefragt als Laie: Bei der Taktfrequenz ist man ja schon an physikalische Grenzen gestoßen, und bei der Erhöhung der Cores wird man auch irgendwann auf Grenzen stoßen. Nur, was will man dann an diesem Punkt noch machen, um schnellere CPUs zu bauen?
Braucht man die denn? Zum spielen? Mittlerweile lassen sich viele neue Spiele auch mit Mittelklasse CPU`s hervorragend spielen. Mein nächster Rechner wird sicher kein HighEnd Bolide werden.Eher was mit Micro ATX wo alles außer der Grafikkarte OnBoard ist. Viele denken heute so. Micro ATX ist voll im Trend. Und damit auch CPU`s die vielleicht nicht allerschnellsten sind sich aber auch in engen Gehäusen problemlos kühlen lassen.
Übertakter und High-End Nerds werden sich in ein paar Jahren in der Ecke wiederfinden wo auch die wenigen HiFi Freaks sind.
Schiere Rechenleistung wird also in Zukunft eher auf dem Servermarkt gebraucht und in den Supercomputern. Das ist aber für mich eher uninteressant.
Übertakter und High-End Nerds werden sich in ein paar Jahren in der Ecke wiederfinden wo auch die wenigen HiFi Freaks sind.
Komisch, dank AMDs BE-Modelle ist eher genau das Gegenteil passiert!
Schiere Rechenleistung wird also in Zukunft eher auf dem Servermarkt gebraucht und in den Supercomputern. Das ist aber für mich eher uninteressant. Womit begründest du das? Weil DU keine Rechenleistung brauchst?
Weil Er es sich halt nicht vorstellen kann.
Aber Das ist auch nicht die Aufgabe des Verbrauchers.
Die Komplexität der Verdrahtung ist ein Horror und die Kühlung nahezu unmöglich. Das Thema ist älter als die Tesarom.
Es wird noch dran geforscht und umsetzen ließe es sich sicher, die Frage ist nur, ob das der effektivste Weg ist.
http://www.heise.de/newsticker/meldung/IBM-stapelt-Siliziumchips-166474.html
http://www.news.at/articles/0951/543/257816/3d-mikroprozessoren-realitaet-forscher-kerne-leistung (mit integrierter Kühlung, was immer das heißt).
PS: Nicht die Taktrate war die physikalische Grenze, sondern vielmehr die leistungsaufnahme... die extremübertakter haben schon mehr als 8 GHz rausgekitzelt (mit Reserven ;D ) http://www.golem.de/0708/54088.html
Avalox
2010-01-02, 12:39:28
Es wird noch dran geforscht und umsetzen ließe es sich sicher
Jep, das dauert auch noch viele Jahre. Was auch kommen wird ist, dass der Hauptspeicher in die CPU wandern wird.
Was auch kommen wird ist, dass der Hauptspeicher in die CPU wandern wird.
Sehr unwahrscheinlich, weil 1. zu viele Transistoren und 2. die Fertigungsprozesse für Speicher anders sind als bei CPUs aufgrund der vielen Kondensatoren.
roidal
2010-01-02, 13:23:59
Sehr unwahrscheinlich, weil 1. zu viele Transistoren und 2. die Fertigungsprozesse für Speicher anders sind als bei CPUs aufgrund der vielen Kondensatoren.
An Punkt 2 arbeitet Intel schon, und hat auch schon erste Ansätze.
Tigerchen
2010-01-03, 09:58:54
Komisch, dank AMDs BE-Modelle ist eher genau das Gegenteil passiert!
Womit begründest du das? Weil DU keine Rechenleistung brauchst?
AMD liefert auch mit den BE`s kein HighEnd sondern bezahlbare Mittelklasse.
Eine Meinung muß man nicht begründen. Ich sehe was am Markt passiert und sehe was mein Umfeld so treibt und ziehe meine Schlüsse. Sei ehrlich zu dir selbst der PC ist doch nichts besonderes mehr. Die Zeit der Nerds ist genauso vorbei wie die der Mantafahrer.
AMD liefert auch mit den BE`s kein HighEnd sondern bezahlbare Mittelklasse.
Eine Meinung muß man nicht begründen. Ich sehe was am Markt passiert und sehe was mein Umfeld so treibt und ziehe meine Schlüsse. Sei ehrlich zu dir selbst der PC ist doch nichts besonderes mehr. Die Zeit der Nerds ist genauso vorbei wie die der Mantafahrer.
Mhm! du hast geschrieben: "Übertakter und High-End Nerds werden sich in ein paar Jahren in der Ecke wiederfinden wo auch die wenigen HiFi Freaks sind."
ok, die BE-Modelle falle nicht unter HighEnd, aber es sind Übertakter-CPU, welche Übertakter-Nerds ansprechen. Und solange sie bezahlbar sind wie heute, werden sie gekauft. AMD ist doch erst mit den BE-Modellen wieder nach oben gekommen.
Tigerchen
2010-01-03, 15:26:06
Mhm! du hast geschrieben: "Übertakter und High-End Nerds werden sich in ein paar Jahren in der Ecke wiederfinden wo auch die wenigen HiFi Freaks sind."
ok, die BE-Modelle falle nicht unter HighEnd, aber es sind Übertakter-CPU, welche Übertakter-Nerds ansprechen. Und solange sie bezahlbar sind wie heute, werden sie gekauft. AMD ist doch erst mit den BE-Modellen wieder nach oben gekommen.
Halten wir also mal fest. Wir sind an einem Punkt angekommen wo eine Übertakter CPU gerne mitgenommen wird. Schon heute brauchen die meisten Spiele aber keine CPU die nun bis letzten Hertz übertaktet werden muß um einen ruckelfreien Spielespaß zu erleben. Vor ein paar Jahren war das noch ganz anders. Als 1998 Unreal erschien gierte jeder nach schnelleren CPU`s um mal mehr als 25fps zu erleben. Man tat alles um das zu erreichen. Gerade in den letzten Jahren verspürt man diesen Leidensdruck immer weniger. Das ist so. Außer bei Nerds wie Tombman. Die wird es immer geben,sind aber kein Masstab. Darum denke ich daß der Fokus in Zukunft auf kleinere, leicht zu kühlende und stromsparende Rechner liegen wird. Und nicht mehr so sehr auf brachiale Rechenleistung um jeden Preis. Nicht umsonst sind ja Micro-ATX Platinen voll im Trend.
Micro Atx sind nur doch nur kleiner.. Ich sehe da nur eine Tendenz weg von großen Gehäusen und kleinen Wohnzimmertauglichen HTPCs.
(del)
2010-01-04, 02:01:24
Als 1998 Unreal erschien gierte jeder nach schnelleren CPU`s um mal mehr als 25fps zu erleben.Dafür hab ich mir damals aber die VooDoo2 geholt und sie mit selbstgebauter Kühlung mit 110Mhz gefahren...
Gerade in den letzten Jahren verspürt man diesen Leidensdruck immer weniger.Nur die Beweggründe haben sich geändert. Heute trägt man nicht dick auf, damit es erträglicher wird, sondern damit es noch doller wird :tongue: Vom Einkern Athlon64 auf E8400 wegen Lightroom umgestiegen, echt fein. Auf 3.7Ghz übertaktet, extra super fein. Man will nach 10 Minuten auch nie wieder zurück. Eher noch weiter nach Vorn.
Darum denke ich daß der Fokus in Zukunft auf kleinere, leicht zu kühlende und stromsparende Rechner liegen wird. Und nicht mehr so sehr auf brachiale Rechenleistung um jeden Preis.Das kann vielleicht für einen mittleren 32nm Intel gelten (der relativ leicht zu kühlen, aber trotzdem immernoch "brachial" schnell ist), aber nicht für seinen Kompagnon,Schon heute brauchen die meisten Spiele aber keine CPU die nun bis letzten Hertz übertaktet werden muß um einen ruckelfreien Spielespaß zu erlebendie Grafikkarte.
Nicht umsonst sind ja Micro-ATX Platinen voll im Trend.Die sind im Trend weil sich mittlerweile jeder einen HTPC baut. Vorzugsweise mit einem Athlon II X2 240e und nicht mit dem Atom...
vBulletin®, Copyright ©2000-2025, Jelsoft Enterprises Ltd.