News Intel: Core i7-7700K fällt unter die 300-Euro-Marke

[The Ripper]

Btw. versuche ich möglichst immer meine Programme in möglichst viele parallel laufende Aufgaben aufzusplitten weil die Hardware von heute bestens dafür vorbereitet ist und die steigerung der IPC seit Jahren eher stagniert

​Ab einer gewissen Anzahl von Kernen (die von Anwendung zu Anwendung unterschiedlich ist) ist der Verwaltungsoverhead fürs Management zwischen den Kernen so hoch, dass die hinzugekommene Leistung nicht mehr genutzt werden kann oder die verfügbare Gesamtnutzleistung für die Applikation sogar sinkt, d.h. der Kern verursacht mehr Overhead als er nutzt. Folglich würde die Applikation ab einer gewissen Anzahl von Kernen besser laufen, wenn sie aufhört mehr Kerne zu benutzen.


​Ist aber hier ein wenig aus der Luft gegriffen, da kaum jemand derartig viele Kerne im Computer hat...
(EDIT: eventuell auch nicht vgl. vorheriger Post)

​Mehr Infos unter:
https://stackoverflow.com/questions...-additional-cores-or-cpus-doesn-t-improve-the

 

[Pjack]

Multicore ist keine Notlösung sondern die Lösung für das Problem das sich IPC und Takt nicht unbegrenzt steigern lassen.

Du sagst es doch gerade selbst: man setzt auf mehr Cores/Threads, weil man bei IPC und Takt immer mehr an Grenzen stößt.
Dafür nimmt man Nachteile in Kauf, zB. der deutlich höhere Aufwand bei der Programmierung, dass Performance bei ungünstigen Softwareszenarios brachliegt usw.
Genau das definiert doch eine Notlösung. Wenn man die Wahl hätte, würde man natürlich lieber die IPC steigern.

 

[.Sentinel.]

@The Ripper
In Deinem Link ist ja eine weitere Perle diesbezüglich versteckt:
ftp://ftp.cs.utexas.edu/pub/dburger/papers/ISCA11.pdf

An alle Kernzahl ist alles und die Zukunft- Jünger: Durchlesen! Dann nochmal über das bis jetzt geschriebene nachdenken!

Da sieht man, dass da in normalen Programmszenarien ganz schnell schluss ist, mit effektiver Multicore- Nutzung, weil der Anteil an parallelen Code unglaublich hoch sein muss, dass man in vielkern- Szenarien über 8 Cores+SMT/HT irgendwelche Zuwächse erzielen kann.

Interessant auch, dass nach der Berechnung bei GPUs ab 4864 Kernen im 8nm Verfahren komplett Essig ist, mit nennenswerten Leistungszuwächsen.

@Pjack
Genau das!

Grüße
Zero

 

[Holt]

Das hier ist ein Forum, wer hier erwartet dass der durchschnittliche User und Schreiber tiefgründiges Fachwissen hat ist doch ziemlich naiv.

Das erwartet ich auch nicht, ich erwarte aber, dass diejenigen sich wenigstens selbst bewusst sind wo die Grenzen ihreres Wissens sind, denn es ist eben im Leben sehr wichtig zu Wissen was man nicht weiß! Dann wird man, wenn man was Gegenteiliges liest, auch nicht sofort mit irgendwelchem Schwachsinn gegenangehen, sondern erst googlen und schauen was nun richtig ist und dabei war lernen und den anderen die das richtige geschrieben haben, nicht auf den Wecker fallen und jede Diskussion zerstören, wie es hier in den Threads diese Forums leider zur Regel geworden ist. Dabei ist dieses hier mit "Mainboards und CPUs: Fachgespräche" überschrieben! Davon ist hier leider nur selten etwas zu bemerken.

Wenn du der große CPU Guru bist, warum hast du dann nicht deine eigene Seite, wo du korrekte Reviews veröffentlichst?

Weil ich dazu keine Lust habe und nichts machen muss, wozu ich keine Lust habe, denn ich habe meine Schäfchen im Trocknen und muss nicht versuchen Klicks im Netz zu generieren um ein paar Euro zu verdienen.

Multicore ist keine Notlösung sondern die Lösung für das Problem das sich IPC und Takt nicht unbegrenzt steigern lassen. Du verdrehst die Realität um 180°

Wäre es nicht so traurig, dann wäre es schon lustig wie du dir hier selbst widersprichst, denn wäre es möglich gewesen Takt und IPC immer weiter zu steigern, hätte man nicht auf Multicore CPUs ausweichen müssen um die Leistung weiter zu steigern. Dies hat nämlich viel mehr Aufwand bei der Programmierung und vor allem der Validierung der Software zur Folge und die Leistung skaliert trotzdem niemals perfekt über alle Kerne. Ganz davon abgesehen, dass gar nicht alles parallelisierbar ist.

Btw. versuche ich möglichst immer meine Programme in möglichst viele parallel laufende Aufgaben aufzusplitten weil die Hardware von heute bestens dafür vorbereitet ist

Dann wird dir aber auch nicht entgangen sein, dass der Start und das Ende eines Threads mit hohen Kosten an Rechenzeit verbunden sind und sich nur lohnt, wenn der neue Thread auch genug Arbeit ausführt um diese zu kompensieren. Ebenso erfordert es Absicherungen von gemeinsam genutzten Datenstrukturen und weitere Synchronisierungen, die dann immer wieder den einen oder anderen Thread ausbremsen, die SW skaliert dann noch schlechter über mehrere Kerne. Um dies zu reduzieren, Intel Features wie die TSX (Transactional Synchronization eXtensions) Befehle eingeführt und AMD Advanced Synchronization Facility vorgeschlagen, aber wohl bisher noch nicht implementiert.

 

[tek9]

@ZERO: Na siehst du es macht doch mehr Sinn zusätzliche Cores zu verbauen statt mit apothekerhaftem Eifer die IPC um ein paar Prozentchen zu steigern.

Btw geht deine Erkläreritis so langsam auf die Nerven.

Kannst du eigentlich programmieren?

 

[.Sentinel.]

@Holt

Ebenso erfordert es Absicherungen von gemeinsam genutzten Datenstrukturen und weitere Synchronisierungen, die dann immer wieder den einen oder anderen Thread ausbremsen, die SW skaliert dann noch schlechter über mehrere Kerne.

Wo wir wieder bei den verfluchten Race- Conditions wären, die die Multicore Programmierer oftmals an die Grenzen des Wahnsinns treiben und das Troubleshooting auf X Plattformen, auf denen alles laufen soll so verdammt schwer macht.

Nicht zuletzt deshalb schimpfen die User über viele Bugs und "unausgereifte Software":
http://www.electronicdesign.com/digital-ics/programming-survive-multicore-race-conditions

@tek9
Ich wiederhole mich:
Ich erkläre, dass ein Mehr an Cores nur eine nicht in allen Fällen Vorteile verschaffende Notlösung ist, weil man mit Taktung mit bestehenden Mitteln nicht mehr viel weiter kommt..
Es ist nicht der heilige Gral.

Ich habe nichts gegen eine Kernsteigerung einzuwenden. Der Generaleffekt einer Geschwindigkeitssteigerung wird mit jedem zusätzlichen Kern nur immer niedriger.

Die Meinung, die aber generell hier im Forum mehrheitlich vertreten ist ist: doppelt so viele Cores= doppelte Geschwindigkeit - Ansonsten ist die Software schlecht programmiert. Das ist nunmal grundweg falsch.

c# und .net und auf dem c64 Basic und Assembler (beides mit hohem Einrostfaktor)

Sorry für die ausschweifenden Erklärungen. Die braucht es aber um meinen Standpunkt bzw. die Fakten ans Licht zu holen... Ich kanns nicht besser komprimieren.

Grüße
Zero

 

[Holt]

Btw geht deine Erkläreritis so langsam auf die Nerven.

Das ist eine die einiges erklärt, aber wer das so sieht, sollte besser nicht in einem Forum wie diesem unterwegs sein.

Kannst du eigentlich programmieren?

Kannst Du es denn?

Wo wir wieder bei den verfluchten Race- Conditions wären, die die Multicore Programmierer oftmals an die Grenzen des Wahnsinns treiben und das Troubleshooting auf X Plattformen, auf denen alles laufen soll so verdammt schwer macht.

Wer mit Race- Conditions Probleme hat, hat vorher nicht aufgepasst und die Synchronisierungen und Absicherungen von gemeinsam genutzten Datenstrukturen falsch gemacht und es reicht eine zu unterlassen, um Probleme zu bekommen. Klar wird dies "gerne" gemacht, um mehr Performance zu bekommen und es passiert auch oft, wenn alten Code verwendet der eben nicht threadsafe ist, weil er zu einer Zeit entstanden ist, also es nicht üblich war multithreaded zu programmieren oder weil der Ersteller des Codes diese eben nicht berücksichtigt hat.

Es gibt leider viel mehr schlechte Programmierer als gute, damit muss man leben und die Tendenz fertige Pakete zu verwenden statt auch selbst was zu schreiben, wird auch immer größer. Nur weiß man dann nie welche Fehler der anderen man sich damit in sein Programm holt. Ich mache immer noch so viel selbst wie möglich, wobei sich über die Jahrzehnte natürlich auch eine ansehnliche Codebasis ausgebaut hat. Multithreaded programmiere ich nur die Teile meiner Programme wo es sich wirklich lohnt, eben um den Aufwand fürs Programmieren wie auch für das Debuggen gering zu halten und weil es am Ende an keinen Mehrwert bringt oder sogar langsamer ist, wenn ein Thread nur sehr kurz an einer Aufgabe rechnet und dabei womöglich noch mehrere Threads gemeinsame Daten nutzen die auch noch verändert werden.

@tek9
Ich wiederhole mich:

Sinnlos, auch er wird es nicht begreifen, weil es gegen die Linie geht die er fährt und wäre AMD die Firma mit den schnelleren Kernen und Intel würde mehr, aber langsamere Kerne bieten, wäre er mit Dir einer Meinung.

Der Generaleffekt einer Geschwindigkeitssteigerung wird mit jedem zusätzlichen Kern nur immer niedriger.

Das ist das Problem, die Performance eines einzelnen Programms wird nie genau linear zur Zahl der Kerne skalieren. Da auch im Betriebssystem nicht alles perfekt parallel ablaufen kann, z.B. bei der Verwaltung des RAMs, der Tasks oder des I/Os geht dies einfach nicht, kann auch die Leistung des gesamten Rechnern nie zu 100% mit mehr Kernen skalieren.

Bis zu wie vielen Kerne eine Anwendung skaliert, hängt sehr von der jeweiligen Anwendung ab. Um die Grenzen möglichst weit rauszuschieben, werden eben Dinge wie TSX implementiert, wobei Intel hier die Nase vorne hat und AMD nachziehen muss, zumal sie eben auch auf CPUs mit sehr vielen setzen, aber offenbar haben die knappen Resourcen eben nicht gereicht ASF schon zu implementieren, so banal ist das nun wirklich nicht und dürfte auch einige Transistoren und damit Leistung erfordern. Solche Details werden aber hier kaum beachtet und dürften den meisten die den Stillstand bei Intel beklagen, gar nicht bekannt sein, für Heimanwender ist dies ja auch eher nicht wirklich relevant, zumindest bisher.

Jetzt kommen aber auch für Heimanwender CPUs mit immer mehr Kernen und damit wird es immer wahrscheinlicher das sich auch beim Heimanwender Anwendungen (gerade auch Games) so wie in der rote Kurve des oberen Bildes verhalten:



Da steigt die Leistung nämlich irgendwann nicht mehr mit mehr Kernen, sondern fällt sogar ab. Die Synchronisierungen zwischen Threads und Absicherungen von gemeinsam genutzten Datenstrukturen mehrere Threads, sind nämlich teuer (kosten viel Zeit) und daher können da gar nicht so viele pro Sekunden gemacht werden. Wie viele pro Sekunde möglich sind, hängt dabei vom System ab, auch da gibt es Unterschiede, aber welcher Review analysiert sowas schon im Detail? Aber wer darüber Bescheid weiß, wundert sich seltener über bestimmte Benchmarkergebnisse.

Die Meinung, die aber generell hier im Forum mehrheitlich vertreten ist ist: doppelt so viele Cores= doppelte Geschwindigkeit - Ansonsten ist die Software schlecht programmiert. Das ist nunmal grundweg falsch.

Eben und es wird oft genug geschrieben, aber dann trotzdem nicht angenommen, sonst sich über Erkläreritis aufgeregt.

 

[EKD]

Ich hab mir jetzt mal die letzten Seiten durchgelesen und sehe als größtes Problem in dieser Diskussion, dass einige User ziemlich persönlich werden anstatt sachlich zu debattieren. Bei mir führen solche Posts bspw. dazu, dass ich sie nicht mehr ernst nehme.

Ich weiß auch nicht alles und wenn ich sehe dass der andere recht hat, dann gebe ich das auch zu. Meine Meinung tue ich trotzdem gern kund, dafür sind Foren da.

Was die Multicore-Geschichte angeht, denke ich auch, dass sie die Leistung nicht beliebig in die Höhe stapeln können (Takt) und deshalb in die Breite gehen (Cores). Spiele und Anwendungen gibt es dafür mittlerweile genug, auch wenn der Programmieraufwand insgesamt steigen dürfte. Die Konsolen machen es vor, die niedrig getakteten PS4/XboxOnes benutzen jeweils 8 Kerne, um die Aufgaben auszulagern und dadurch die Spieleleistung zu optimieren. Die meisten großen Entwickler werden sich voraussichtlich daran ausrichten, was auch wiederum Folgen für den PC hat (Fokus auf Multicore -> Witcher 3, GTA5, etc.)

Ich sehe auch bei Grafikkarten diesen Trend, Volta ist laut Nvidia das momentane Maximum, was sich rausholen lässt. Danach wird wohl eine Verkleinerung in Sachen Fertigung fällig sein bzw. eine noch bessere Optimierung/Architektur, was sich aber nicht unbegrenzt fortführen lassen wird. Sollte bei den Quantencomputern nicht irgendwann ein Durchbruch erzielt werden, ist irgendwann bei CPUs und Grafikkarten einfach "Schluss" (physikalische Grenze) und Multi-Core bzw. Multi-Die das Maß der Dinge. Anschließend wird es hauptsächlich darum gehen, die Kommunikation zwischen diesen Einheiten zu verbessern und damit dann die Produkte zu bewerben.

 

[Juri-Bär]

Wer auf Coffee Lake wartet, wird sich keinen 7700K kaufen, den hat der vermutlich schon, wenn es jemand ist der immer die neuste CPU haben will.

Solche Leute haben jetzt Haswell oder Skylake und warten auf Coffee Lake, wie werden wohl kaum beim 7700K wegen ein Euro Preisnachlass schwach.

Ich finde diese interessegeleitenten Argumentationen, die sich am gleichen Tag handfest widersprechen, ja immer goldig. Wie denn nun: hat der KaffeeSee-Patient den i7-7700K auf jeden Fall schon oder lässt er ihn ganz klar aus?

Ansonsten liest man hier Programmier-Debatten auf äußerst mäßigem Niveau.

Natürlich ist es Stand heute so, dass Game-Programmierer Mühe haben, mehr als 8 Cores sinnvoll zu verwenden, so dass der Quad mit HT meist zum Zocken auskömmlich ist. Ob das künftig so bleibt oder sich ändert, ist doch aber für die Frage, dass der i7-7700K auch für "nur" 300 € keine vernünftige Kaufoption ist, völlig unerheblich.

Leute mit dem nötigen Kleingeld haben auch schon vor Ryzen den Mainstream-i7 mit 4 Kernen links liegen lassen und 'was besseres, auch mit geringer Singlecoreleistung, genommen. Inzwischen braucht man dank Ryzen weniger Kleingeld, um eine vernünftige CPU anzuschaffen. Da beißt die Maus doch keinen Faden ab, dass es für einen Zocker ziemlich Banane ist, ob er einen i7-7700 (mit oder ohne K), einen i7-6700
(mit oder ohne K), einen i7-4790 (mit oder ohne K) oder einen R5-1400/1500X einsetzt - nur das letztere nur gut die Hälfte kosten. In wenigen Konstellationen hat der Zocker dann Vorteile vom Hexa- oder Octacore mit HT. Wenn das Kleingeld da ist oder der günstige AMD-Preis vorliegt, spricht natürlich auch nichts dagegen, die zu nehmen.