News Aktualisierte Intel-Desktop-Prozessor-Roadmap bis Ende 2013

Wahnsinn, wie stark CPUs im Desktop-HighEnd-Bereich stagnieren. Ein Glück setzt sich GPU Computing (OpenCL, CUDA, C++ AMP) immer mehr durch, was einen Performance-Boost mit sich bringt, vor dem CPUs vor Neid nur erblassen können... :freak:
 
misterk87 schrieb:
Das mag bei einigen Filtern zutreffen, bei einigen aber auch wieder nicht. Adobe ist da allgemein recht träge. Auch bei After Effects ging es erst mit 5 mal in richtung Multithreading.
Sry aber du kannst nicht irgendwas posten von wegen CPU scheiße für PS und dann kommst mit irgendwelchen Filtern die gehen sollen und welche die nicht gehen?! Was soll das? Vonm AfterEffects hast auch oben nicht gesprochen! Reine Rumtrollerei! Entweder ich kann was anhand von belastbraen Fakten belegen oder nicht. Wenn ich es nicht kann halt ich meine Mund! Im Übrigen ist es eh allgemein bekannt das PS sowie Gimp von hohen Takt profitieren. Wobei bei PS die Festplatten und die konfiguration des Rechners noch wchtiger sind wie lernen dürfte.

Also wenn man keinen Plan hat oder nur rummotzen will wie schlecht die Welt ist... bitte woanders.
Ergänzung ()

Huhamamba schrieb:
Wahnsinn, wie stark CPUs im Desktop-HighEnd-Bereich stagnieren. Ein Glück setzt sich GPU Computing (OpenCL, CUDA, C++ AMP) immer mehr durch, was einen Performance-Boost mit sich bringt, vor dem CPUs vor Neid nur erblassen können... :freak:
Render doch mal mit deiner Graka...lol. WO stagniert denn der High End Bereich? Trigate, 22nm wahrscheinlich 8 kerner für Normalsterbliche... . Das was immer hinetrherhinkt ist die Software die die ganzen Befehle nicht nutzen kann. Das ist Murks.
 
dirky8 schrieb:
Ergänzung ()

Render doch mal mit deiner Graka...lol.
Gerne, such's dir aus!

V-Ray RT - smallLuxGPU - Octane Render - & iRay - Indigo Renderer - Lightwave -
und als besonderes Schmankerl: :p


Im Vergleich zu den Leistungssprüngen im GPU-Segment sind die Fortschritte der CPU-Entwicklung trotzdem ein laues Lüftchen. Dass man die SSE-Befehlssätze jedoch stärker in die Software einbinden könnte, stimm ich dir zu. :)
 
Zuletzt bearbeitet:
Kann und will ich nicht unterschreiben. Geh mal 5 Jahre Zurück und schau was die CPUs so geleistet haben und vor allem was sie verbraucht haben. Klar ist ohne Zweilfel das sich Intel Zeit lassen kann mit den Entwicklungen die auf halde liegen. Ist leider so. Bei einem Quasi Monopol. Von einem Oligopol kann man ja im X86 Markt ja schon lange nnicht mehr sprechen. Nur sind die Entwicklungen kein laues Lüftchen. Grakas sind eine Option, nur wenn du dir die Videos anschaust... da rennen Kisten mit 8 GTX580(für alle, das ist keine Spielekiste und dkein SLI und Crysis läuft darauf auch nicht mit 1MIO FPS;))

Ander haben TEslas und und und verbaut.

Andererseits funzt das mit Grakas auch nur in Verbindung mit der passenden SW. So oder so. HAts ja Recht war auch nicht mehr ganz im Thema da ich mehr PS mache und videos schneide.
 
Wenn die Leistung stimmt wurd der i- 7-4770K gekauft.Finde es witzig,das Intel den i-7-3820 über dem 3770stellt der 3770 kostet mehr und leistet mehr.
 
Weiß man schon Näheres zu Ivy-E? Im Enthusiast Segment wird man die TDP wohl kaum senken, ich hoffe auf 15-20% mehr Takt.
 
dirky8 schrieb:
Grakas sind eine Option, nur wenn du dir die Videos anschaust... da rennen Kisten mit 8 GTX580(für alle, das ist keine Spielekiste und dkein SLI und Crysis läuft darauf auch nicht mit 1MIO FPS;))
Naja, die 8 580 waren auch dafür nötig, um komplexe Szenen nahezu in Realtime rendern zu lassen, quasi als eine Art Machbarkeitsstudie. ;)
Mit meinen zwei 660 sollte ich für die finale Bildqualität bei solchen Szenen in FullHD Pi mal Daumen 30 bis 60 Sekunden an Renderzeit pro frame benötigen. Mit einer oder zwei HighEnd-CPUs, die preislich mindestens genauso stark zu Buche schlagen wie die GraKas, dürften es eher 10 bis 20 min pro frame sein.
Und die Schere wird in Zukunft meines Erachtens noch weiter auseinander klaffen. Eher kriegen wir bezahlbare Single-GPU-Karten mit 3k CUDA Cores und 6GB VRAM als bezahlbare CPUs mit 16 Kernen... ;)
 
Huhamamba schrieb:
Wahnsinn, wie stark CPUs im Desktop-HighEnd-Bereich stagnieren. Ein Glück setzt sich GPU Computing (OpenCL, CUDA, C++ AMP) immer mehr durch, was einen Performance-Boost mit sich bringt, vor dem CPUs vor Neid nur erblassen können... :freak:

Ich könnte auch was mit Intels Quicksync anfangen, mit Haswell wären noch mehr EUs vorhanden. In Verbindung mit CUDA dürfte das wohl ein Traumpaar werden, wenn die Software das mitmacht. Hab bei den aktuellen Preisen auch schon mal mit 16 GB RAM gerechnet und mit 32 GB kommt man auch nicht viel teurer weg.
 
gwuerzer schrieb:
Ich halte CB ganz einfach für eine sehr gute und seriöse Seite, meine "Klicks" bekommen sie dadurch, interessante und gut recherchierte Artikel auf einem hoch-qualitativen Niveau zu veröffentlichen. So macht das Lesen Sinn und Spaß. Darauf kommt es in der Praxis an, nicht auf irgendwelche Zitationsregeln. Diese machen Sinn im akademischen und wissenschaftlichen Bereich, wo es um Forschungsleistungen geht, wenn es um News aus der Welt von Computern und Technik geht, ist das in der Praxis ziemlich wurscht.


Was helfen würde, ist ein Computerbase Boykott der angeschissenen Seiten. Das heißt, es wird ab sofort Computerbase nicht mehr verlinkt. Entweder eine andere Seite verlinken, oder falls zur Abwechslung doch etwas exklusives kommt, den CB mimen und die Quelle eben nicht sauber benennen. Das wäre nur fair. CB hält es schließlich auch nicht für nötig. Den gemeinen Leser wie dir wird es nicht jucken, bist schließlich nicht betroffen.
 
Also ich würde Ralf555 zustimmen. Ganz unten rechts wo "Quellen" steht, müsste eigentlich nicht "Diverse" angeführt werden, sondern halt eine genaue Auflistung der Quellen. Zb "pconline". Ist einfach gute, journalistische (und auch wissenschaftliche) Praxis.
 
Mr.Seymour Buds schrieb:
Also ich würde Ralf555 zustimmen. Ganz unten rechts wo "Quellen" steht, müsste eigentlich nicht "Diverse" angeführt werden, sondern halt eine genaue Auflistung der Quellen. Zb "pconline". Ist einfach gute, journalistische (und auch wissenschaftliche) Praxis.

Genau das wäre ein seriöses Vorgehen. Wenn die Roadmap von pconline stammt oder woher auch immer CB das hat, dann muss genau der Link dort gefälligst verlinkt sein. Dabei spielt es keine Rolle, ob in news anno xx die Quelle verlinkt ist. Es geht hier nicht um eine Einzeltat, sondern um ein systematisches Vorgehen seitens Computerbase (im besonderen Volkers News), was System hat. Seit etwa 1-2 Jahre beobachte ich das mittlerweile. Das kann im schlimmsten Fall zur Abmahnung führen.
 
hamju63 schrieb:
CPU Leistungserhöhung wird wohl im gleichen Bereich sein, wie der Umstieg von Sandy auf Ivy (also kaum der Rede wert)
[...]

Das wird so nicht sein, zumindest nicht generell, allenthalben für Kinderzimmer-PCs und Kinderzimmer-Software (Spiele und Produktklausoftware). Die Unterschiede zwischen Sandy- und Ivy-Bridge waren marginal, zumindest aus der logischen Sicht. Technisch hatte sich einiges getan, was der TDP sowei der Schaltgeschwindigkeit der L1- und L2 Caches zugute kam. Hinzu kam noch ein Zufallsgenerator, den aber kaum jemand nutzt, wenn er nicht gerade intenisv MOnte-Carlo Simulationen auf beiden CPUs durchführt. Wenn ein Treiber für den neuen RNG existiert (FreeBSD und Linux haben einen solchen in den neuesten Kernel), kann man bis zu einem Faktor 15 schneller rechnen (geschätzt, ich habe auch schon 100x schneller festgestellt). Weil aber die Zufallsgenerator vielleicht weniger als 1 Prozent der Auführungszeiten des Codes ausmacht, fällt diese Nutzung nicht so sehr ins Gewicht.

Was Ivy-Bridge gegenüber Sandy-Bridge schneller gemacht hat, waren neue Fertigungstechniken mit schnelleren Transistoren - und immerhin konnte Intel im Schnitt ca. 10% bei gleicher Codebasis mehr aus dem Design holen - bei geringerem Energieumsatz.

twilight schrieb:
[...]
  • AVX2: doppelter Durchsatz für Integer Vektorcode
  • FMA: doppelter Durchsatz für typischen FP Code, sowie die Möglichkeit für legacy Code anstatt FMUL + FADD auch 2 FMUL pro Takt auszuführen
  • TSX: einfachere und deutlich schnellere Synchronisation von multitheaded Code
Das Problem ist, dass AVX2 und FMA zumindest ein Recompilieren und TSX sogar wesentliche Änderungen am Source Code benötigen und es üblicherweise Jahre dauert, bis solche Features Einzug in mainstream Applications erhalten. Für HSW wäre in extra Codepath nötig und kaum ein Hersteller liefert Binaries mit x verschiedenen Codepaths aus. (Ein Anfang wäre HSW, SNB, NHM sowie legacy für Core und darunter und für AMD bräuchte es auch noch mindestens Bulldozer und K10, was schon 6 verschiedene Codepaths wären.)

Codepaths: es wird nicht falscher oder richtiger, wenn Du Denglisch verwendest. Ich habe keine Probleme mit der Handhabung mehrerer Architekturen (Bulldozer, Sandy-/Ivy-Bridge) für hochoptimierte Software, es sind in der Regel keine eigenen Zweige nötig. Die Komplexität der Optimierungen hinsichtlich Ausführungspfade und Cachegrößen innerhalb einer CPU kann man intelligent handhaben - sofern man nicht BASIC oder anderen Unfug programmiert. Das beste und sicherlich eindringlichste Gegenbeispiel Deiner Aussage sind mathematische Bibliotheken wie gotoBLAS oder ATLAS: beim Bau dieser Bibliotheken wird die gegebene Architektur identifiziert und der verwendete Compiler angewiesen, entsprechenden optimierten Code zu erzeugen. Die Alternativpfade sind gar nicht so komplex.

Ich selber experimentiere in einem astronomischen Modell mit der Verwendung von Vektoreinheiten für vektoralgebraische mathematische Funktionen. Jenachdem, wie weit man abstrahieren will, ist der Aufwand gering. Man selbst rückt allerdings ziemlich schnell an die Kliffkante der Optimierungssicherheit verwendeter Compiler. Aus diesem grund ist LLVM zunehmend mein bester Freund und für solche Probleme gibt es schließlich OpenCL - also auch hier sollte einsichtig sein, daß es keine nennenswerten Aufwendungen für Verzweigungen der Basis geben sollte. Das ist mir nicht einsichtig.

Solltest Du aber im Bereich Übersetzerbau tätig sein und das meinen, gebe ich Dir recht. Aber da ist es nunmal Tagesgeschäft, sich auf jede Feinheit der jeweiligen Architektur einzulassen.

Daneben sollte noch erwähnt werden, daß mit Haswell zwei neue Ausführungsblöcke (Ports) Einzug halten - die leider nur als Ganzzahleinheiten nutzbar sind. Wie Stiller in c't bereits schrieb, kann man damit wohl eine Steigerung des SMT-Durchsatzes erwarten. Letztlich profiztieren auch die FPUs davon, denn je schneller die Pipeline abgearbeitet werden kann, desto schneller kommen auch meine FPU Instruktionen an die Reihe.

Da Haswell einige Prefetch-Puffer nun doppelt so groß wie beim Vorgänger auslegt, ist der theoretische Durchsatz auch doppelt so hoch. Zwischen Sandy- und Ivy-Bridge hat sich hinsichtlich der Größe der internen Puffer wenig getan, aber der Sprung von Core-i7 Original zu Sandy-Bridge war bemerkenswert und in unseren Anwendungen deutlich(!) spürbar.

Ist TSX nicht ein chipinternes Design, das sich der Optimierung der Hardware-Threads widmet? Eine Optimierung an dieser Stelle wird eher Compilerbauer und Betriebssystemarchitekten interessieren, nicht aber den gemeinen Wald-Wiesen-BASIC/IDL/PERL/Python Skriptierer.

misterk87 schrieb:
Photoshop User profitieren davon im Prinzip garnicht, denn Photoshop rödelt momentan schön auf einem Kern herum. Beim Rendern zählt jeder Kern und wird auch zu 100% genutzt. Eine Verbesserung um 10% ist dann in dem Fall nicht zu unterschätzen.

Adobe Produkte, vor allem dieses Unding Photoshop, ist ein Paradebeispiel schlechter Software. Photoshop skaliert schlecht, lastet gerade mal maximal 4 Threads aus und die Einbettung von GPUGPU ist enttäuschend.

Huhamamba schrieb:
Wahnsinn, wie stark CPUs im Desktop-HighEnd-Bereich stagnieren. Ein Glück setzt sich GPU Computing (OpenCL, CUDA, C++ AMP) immer mehr durch, was einen Performance-Boost mit sich bringt, vor dem CPUs vor Neid nur erblassen können... :freak:


... allerdings auf Kosten der Flexibilität. Noch lange ist GPGPU nicht das, was es sein könnte. Das liegt vor allem daran, daß nVidia allen voran diesen "Markt" so lange wie möglich für sich dominieren möchte. Deren OpenCL Treiber im Graphiktreiber sind unterirdisch gemessen an dem, was Intel oder AMD zu leisten vermögen. AMD pflegt seine Software stiefmütterlich, fehlerhafte Treiber sowie eine mangelhafte plattformübergreifende breite Unterstützung (die Welt besteht nicht nur aus LinSux und Windoof) schieben AMD zunehmend ins Abseits - trotz der hervorragenden Hardware.

boxleitnerb schrieb:
Weiß man schon Näheres zu Ivy-E? Im Enthusiast Segment wird man die TDP wohl kaum senken, ich hoffe auf 15-20% mehr Takt.

Da gab es mal Gerüchte, daß Ivy-Bridge-E mit mehr Takt, gleicher Kernezahl wie bisher (6 Kerne) und etwa gleicher TDP daherkommen werde. Bis heute bin ich davon nicht ganz überzeugt, daß diese "Gerüchte" stimmen, denn auch im Enthusiastensektor gelten Profi-Regeln - stat brachial einfach nur den takt hochzusetzen, um dann mit dem schnellsten Single-Thread System angeben zu können, zählen intelligente Skalierbarkeit, also Profit aus zusätzlichen Kernen. Während man bereits offen darüber diskutiert, daß Ivy-Bridge-EX mit bis zu 15 Kernen erscheinen werde, die EP/EN Versionen bei 10 - 12 Kernen landen sollen, ist die Frage der kernezahl bei den UP Sockel Prozessoren dieser Klasse, also all das, was XEON E5-1600v2 heißen wird, noch offen. Persönlich hoffe ich sehr, daß es mindestens 8 Kerne bei 3,3 GHz werden, solange die TDP von 130 Watt max. nicht überschritten wird.

Gerade die für den Enthusiastenmarkt aus dem XEON-Profisektor "abgezweigte" LGA2011 E-Typen sind architektonisch, bis auf den Uncorebereich (IMC z.B.) identisch mit den großen Eisen, so daß gerade die E-Typen für den MAssenmarkt eine Art Indikator darstellen.

Um die vielen Kerne auch mit Daten füttern zu können, sollen die Ivy-Bridge-E Prozessoren einen verbesserten IMC erhalten, der drei statt zwei Speichermodule pro Kanal mit DDR3-1866 ansteuern können soll. Ich würde mich glücklich schätzen, wenn ein XEON E5-1600v2 mit 64GB (Voll-) Ausbau seinen RAM mit DDR3-1600 ansteuern könnte. Intel hat sich nun über ein Jahr Zeit gelassen, das Design des Ivy-Bridge auf professionelles Niveau zu heben, lassen wir uns mal überraschen, ob Chipzilla nur krummnasig Geld abschöpft oder auch etwas zur Verbesserung tut. Da ich meine private Workstation nun nach 5 Jahren Einsatz langsam ausmustern möchte und gerne auf eine Ivy-Bridge-XEON CPU setzen würde (Haswell wäre wegen der wirklich tollen Erweiterungen für numerische Software ideal, aber leider gibst das erst mal für Kinderspielzeuge ohne ECC und kleine Systemplatinchen).
 
mastermc51 schrieb:
Und das immer viel zitierte "Intel hat viel mehr Geld für Forschung und Entwicklung zu Verfügung" ....
wie war das beim "Athlon" ?
Da war AMD der Underdog und hatte Intel das fürchten gelehrt.
Es geht also!
Warum es jetzt nicht mehr geht auf einmal weiss wohl nur AMD selbst ...:o

Du hast vergessen, daß der Erfolg des Athlon64 nicht alleine auf AMDs Kappe ging, sondern auch damit zusammenhing, daß Intel damals mit dem Prescott im 90nm-Process die anvisierten Taktraten (auf die die Architektur ausgerichtet war) nicht annähernd erreichen konnte.
Es traf also ein sehr gutes AMD-Produkt auf ein maues Intel-Produkt.
Heute treffen halt gute AMD-Produkte auf deutlich bessere Intel-Produkte.

Ich freue mich darauf im Sommer mein Nehalem-System durch ein Haswell-System zu ersetzen. Es wird wohl ein i7-4770 werden, da die K-Reihen ja auf VT-d und TXT verzichten muß. Ich erwarte, daß das neue System gerade dann, wenn 8 Threads am Leistungsanschlag sind, dem alten sehr deutlich überlegen sein wird.
 
Zurück
Oben