Intel Haswell - AVX2 | FMA3 | 22nm

[amdfanuwe]

Da erkäre uns doch mal, warum 2012 zunehmend mehr Desktop Phenoms verkauft wurden als Bulldozers? (http://www.3dcenter.org/news/genauere-zahlen-zum-absatz-einzelnen-amd-prozessorenarchitekturen)

Erklär mal.
Seh nur, dass Phenom abnimmt über das Jahr und Phenom X4 auf Null ist für Q3/13 während Bulldozer über 2012 zunimmt.
Interessant finde ich an der Tabelle eigentlich, dass über die Hälfte der verkauften Desktop CPUs noch 2Kerner sind.
6 und 8 Kerner haben machen zusammen grad mal 5% der Desktopverkäufe aus.
.
EDIT :
.
Denke mal, das sieht bei Intel ähnlich aus, wozu also 6oder mehr Kerner entwickeln, wenns eh kaum gekauft wird.

 

[LehmannSaW]

Kommt mal bitte zurück zum Thema.

Spoiler

Es gibt in der Vergangenheit den Beweis, dass es NICHT an der Technik und NICHT an der Performance liegt, dass AMD keine Prozessoren verkauft. Es liegt nur am Nutzer, der diese Firma nicht will und diese Firma auch nicht empfiehlt.

Wieso der Nutzer zu dieser Entscheidung kam/kommt, ist eine andere Frage.
Ein Teil erklärt die EU Strafe, einen anderen Teil, das diese Firma kein Budget fürs Marketing hat/nutzt. Und einen dritten Teil, Vorurteile, da man früher ja nur Lizenz-Bau für Intel gemacht hat. Aber wieso genau, kann ich nicht beurteilen.

Selbst wenn AMD jetzt irgend etwas auf den Markt bringen würde, was schneller/besser als die Konkurrenz ist und den dementsprechenden Preis haben würde.
Wer würde es kaufen? Diese Frage sollte sich jeder mal ernsthaft stellen.

Ich schiele aktuell auf Atom und E Serie
Sorry fürs OT

Lehmann

 

[gruffi]

Ob Haswell nun 10 oder 20% mehr IPC hat hilft letztlich niemanden. Dieser kleine Sprung hilft nicht weiter, das neue Ideen, die bisher auf Grund von fehlender Rechenleistung nicht praktikabel sind, nun realisierbar sind.

Gut gesagt!

Da erkäre uns doch mal, warum 2012 zunehmend mehr Desktop Phenoms verkauft wurden als Bulldozers? (http://www.3dcenter.org/news/genauere-zahlen-zum-absatz-einzelnen-amd-prozessorenarchitekturen)

Auch wenn es nichts mit dem Thema zu tun hat, das geht aus der Übersicht genau wo hervor? Alles was ich dort sehe, der Absatz der Phenoms wird geringer, der Absatz vom Bulldozer wird grösser.

 

[LordAndrax]

@LehmannSaW
Klar hat Amd ein Budget fürs Marketing, siehe mal Ferrari.
Aber es müste mal Sinnvoll eingesetzt werden.
Ansonsten.
AMD stellt sich als selbst ein Bein, Trinity must ja unbedingt so spät kommen das man auf den i3 auflief.
Sockelunfung FM1 zu FM2.
Überhaupt zwei Sockel nötig.

 

[sompe]

@sompe
du verstehst den knackpunkt meiner aussage nicht.

BD kann doch nur über den Mehr-Takt mithalten (Vergleich zu LLano), und das wird ihm durch den schlechten 32nm Prozess zum Verhängniss. Hätte er eine höhere IPC, müßte man nicht mir +4Ghz arbeiten und hohen Verbrauch in Kauf nehmen. All das hat HSW (Vergleich zu Ivy) nicht, daher sehe ich die problematische Aussnutzung der Mehrkerne nicht als Problem an.

Das hatte ich sehr wohl verstanden aber wie ich zuvor bereits schrieb ist IPC nicht alles.
Frißt der CPU Part des Trinitys bei ähnlicher Rechenleistung (aktuelle Software) nicht ähnlich viel wie der des Llanos? Ist der Trinity bei der Nutzung der neuen Features (z.B. aktuell AES) nicht deutlich schneller?
Welche Architektur ist dann wohl Effizienter?

IPC ist schnell daher gesagt aber unter welchen Rahmenbedingungen sollen die Werte erzeugt werden? Soll die Leistung gemessen die der Prozessor erzielen kann oder das was veraltete Softwarestände davon nutzten?

 

[Family06Model0f]

Die Theoretiker sprechen von einem mittleren ILP (Instruction Level Parallelism) von 3, den der Code durchschnittlich hergibt. Ergo, es sind nicht mehr als 3 Instruktionen pro Takt so voneinander unabhängig dass eine Out-Of-Order Engine wirklich was bringt. Sehr viel höher kann auch Intel nicht kommen in Sachen IPC, egal wie sie sich verrenken.

Worauf beziehst Du Dich mit den 3 IPC? Wall 1993 sieht das ja bei schon bei alten Untersuchungen: "A number of studies [JW89, SJH89, TF70] dating back 20 years show that parallelism within a basic block rarely exceeds 3 or 4 on the average."). Bei den eigenen Untersuchungen wurden höhere Limits festgestellt: "Superscalar processing has been acclaimed as “vector processing for scalar programs,” and there appears to be some truth in the claim. Using nontrivial but currently known techniques, we consistently got parallelism between 4 and 10 for most of the programs in our test suite. Vectorizable or nearly vectorizable programs went much higher."

Dabei ist allerdings zu berücksichtigen, dass sich das auf MIPS bezieht und es somit mWn keine Load-Execute-Instruktionen gibt. HSW kann im Optimalfall demnach in einem Takt schon 7 Instruktionen abarbeiten (2xLoad+Ex=4 Ins + Store=1 Ins + Fused Branch=2 Ins). Für manche Algorithmen könnte da dennoch Luft nach oben sein. Und die Untersuchung ist schon 20 Jahre alt und kam vor ernsthaften OoO-CPUs raus; da kann sich der Erkenntnisstand noch ganz schön verschoben haben.

Wie hoch die erreichbaren Limits tatsächlich sind, wird uns wohl nur die Zeit zeigen. Aber Verbesserungsmögichkeiten scheinen noch zu existieren. Ich wollte am Anfang ja nicht mal glauben, dass die 4-fach Superskalarität des Core2 etwas bringt; seitdem ist die IPC aber schon um bis zu 50% gestiegen. Es bleibt also spannend.
.
EDIT :
.

HTT wird von Gen. zu Gen. immer mehr Transistoren verbrauchen, um immer weniger zu erreichen. HTT war aus der Not heraus geboren um den PIV attraktiver zumachen, in HTT würde ich nicht mehr als ein nettes Gimmik sehen.

Du kannst SMT betrachten wie Du willst, die Techniks ist allerdings ein ziemlich etablierter Trick, um sowohl Single- als auch Multithreadleistung zu optimieren. Die ersten Experimente wurden von IBM Ende der 60er mit der ACS-360 durchgeführt. IBM verwendet SMT standardmäßig seit POWER 5. Ist das dort ein "nettes Gimmick"? Das solltest Du IBM mal wissen lassen. Zugegeben, die meisten CPUs mit SMT haben den Markt nie erreicht (ACS-360 war nur ein Experiment, Alpha 21464 wurde ein Opfer des Itanium-Hype, Suns "Rock" war insgesamt ein Fehldesign), aber das ändert nichts an der Validität des Konzepts.

Und wo siehst Du einen steigenden Transistorverbrauch für SMT, bzw. inwiefern ist das ein Problem? Das Transistorbudget der CPUs, auch derer ohne SMT, steigt fortlaufend. Solange das Verhältnis der "SMT-Transistoren" zu der Transistorzahl des Kerns und seiner Komponenten nicht ansteigt, ist das kein Problem, sondern nur eine normale Entwicklung des steigenden Transistorbudgets.
.
EDIT :
.

Wenn ihr in den CB-Benchmarks einstellige Skalierungsunterschiede auswertet, solltet ihr den Turbo nicht vergessen, der vermutlich ohne HTT öfter anliegt.

Unwahrscheinlich, zumindest die Turbo-Implementierung des IVB ist... unbarmherzig. Ich habe meinen i5-3550 bei den ersten Tests mit Standardkühler bei Turbo-OC+4 und BCLK105 in IntelBurnTest bis auf 103° gekriegt, der Turbo ging nie runter (in CPU-Z immer ein Auge drauf gehabt). Wen Du den nicht in das Termal Throttling treibst (105° laut Hörensagen, das habe ich nicht hingekriegt ), bleibt der auf der Turbo-Frequenz. Ich kann mir nicht vorstellen, dass sich die Turbo-Implementierung der größeren Modelle anders verhält. Und CB geht nicht so sehr auf die Temparaturen, wenn ich mich recht entsinne; einen 3770K damit ins Throttling zu treiben dürfte schwierig sein.
.
EDIT :
.

Diese dämliche IPC-Diskussion ist komplett belanglos.
Auch mit dem IPC-schwachen Bulldozer kann man seinen "Workload" ohne Behinderungen erledigen.

Hm. Habe eben eine Runde Supreme Commander 2 auf Etched Desert mit Einheitenlimit auf 1000 gespielt. Die Spielgeschwindigkeit ging nach 20 Minuten total in die Hose, zwischenzeitlich wohl so Faktor <0,5, bis das durch das Ableben einiger Faktionen wieder erträglich wurde. Das Ganze auf einem i5-3550 mit 4,1GHz auf 1c/2c Load. Da ist mir die IPC und daraus resultierende Singlethread-Leistung aber alles andere als egal, wenn so eine Runde 10-20 min. länger dauern würde auf einem AMD-System.

Ob Haswell nun 10 oder 20% mehr IPC hat hilft letztlich niemanden. Dieser kleine Sprung hilft nicht weiter, das neue Ideen, die bisher auf Grund von fehlender Rechenleistung nicht praktikabel sind, nun realisierbar sind.

Wenn es alle 2 Jahre 15-20% Mehrleistung sind, dann hilft das aber mächtig über mehrere Jahre hinweg betrachet. Ich hatte beim Wechsel von Yorkfield->IVB bei einem selbstgeschriebenen Log-Parser in C# eine Beschleunigung von fast 100% (50+% durch IPC, Rest durch Takt); wenn sowas nicht hilft, dann weiß ich ehrlich gesagt nicht, was Du überhaupt als "hilfreich" definieren willst.

Und wenn man wirklich unglaublich viel Rechenleistung braucht, dann muss die auch in einem erträglichen Energieverbrauchsrahmen stattfinden können; da sind wir dann wieder bei der IPC, da i.A. niedrige IPC->hoher Stromverbrauch durch die benötigen hohen Taktraten, im Vergleich zu Architekturen die eine hohe IPC bereitstellen. Das hilft beim Schönreden von Bulldozer dann auch nicht wirklich.

 

[gruffi]

Du kannst SMT betrachten wie Du willst, die Techniks ist allerdings ein ziemlich etablierter Trick, um sowohl Single- als auch Multithreadleistung zu optimieren.

An der singlethreaded Performance ändert sich durch SMT konzeptionell erstmal nichts. Das nennt sich ja nicht grundlos SMT. Steigende singlethreaded Performance ist in dem Kontext maximal ein Nebeneffekt, zB durch verbreiterte interne Puffer. Puffer und dergleichen kannst du aber auch ohne SMT aufbohren.

Hm. Habe eben eine Runde Supreme Commander 2 auf Etched Desert mit Einheitenlimit auf 1000 gespielt. Die Spielgeschwindigkeit ging nach 20 Minuten total in die Hose, zwischenzeitlich wohl so Faktor <0,5, bis das durch das Ableben einiger Faktionen wieder erträglich wurde. Das Ganze auf einem i5-3550 mit 4,1GHz auf 1c/2c Load. Da ist mir die IPC und daraus resultierende Singlethread-Leistung aber alles andere als egal, wenn so eine Runde 10-20 min. länger dauern würde auf einem AMD-System.

Die Rückschlüsse sind für mich allerdings wenig logisch. Woher weisst du, dass zB ein besseres Einheiten- oder Speichermanagement nicht sinnvoller wäre als mehr IPC?

 

[sompe]

Ich würde mich eher fragen was rausgekommen wäre wenn alle Kerne genutzt worden wären.

 

[gruffi]

Das kommt natürlich noch hinzu und könnte man unter "besseres Einheitenmanagement" einordnen. Gerade sowas wäre prädestiniert für Multithreading.

 

[sompe]

Genau deshalb emfinde ich es als so unverständlich warum dort ausgerechnet bei Strategiespielen gespart wird. Da könnten selbst Intels dicke 6 kernige Brummer noch Sinn machen.

 

[Family06Model0f]

An der singlethreaded Performance ändert sich durch SMT konzeptionell erstmal nichts. Das nennt sich ja nicht grundlos SMT. Steigende singlethreaded Performance ist in dem Kontext maximal ein Nebeneffekt, zB durch verbreiterte interne Puffer. Puffer und dergleichen kannst du aber auch ohne SMT aufbohren.

Sorry, war schlampig formuliert. Ich dachte an die grundlegenden Designentscheidungen beim Entwurf einer Kernarchitektur. Bei einem SMT-Design kann man mehr Ressourcen in die Ausweitung der Ausführungsressourcen stecken, als es bei einem vergleichbaren nicht-SMT Design sinnvoll wäre. Auch wenn die Effektivität bei Ausführung von ST-Code relativ gering ist, wird die höhere Komplexität bei Entwurf/Design/Validierung durch den Anstieg der MT-Rechenleistung gerechtfertigt.

Insofern erlaubt es der Einsatz von SMT, höhere ST-Leistung zu erzielen, die bei einem nicht-SMT-Entwurf nicht zu rechtfertigen wäre. Vergleiche dazu auch die dicken Kerne von POWER7 und SPARC64 X. Mir sind schlichtweg keine Architekturen bekannt, die z.B. 4 FPUs hätten aber kein SMT. Somit ist es meines Erachtens nach SMT, welches in der Praxis CPUs mit massiver ST-Leistung erst ermöglicht.

Die Rückschlüsse sind für mich allerdings wenig logisch. Woher weisst du, dass zB ein besseres Einheiten- oder Speichermanagement nicht sinnvoller wäre als mehr IPC?

Eine bessere Einheitenverwaltung wäre sicherlich eine Lösung. Nur hatte der Entwickler GPG dafür kein Geld mehr, die waren froh, das Spiel überhaupt fertigstellen zu können. Updates wird es nicht mehr geben, und einen dritten Teil wohl auch nicht. Vergleichbare Strategiespiele in der Richtung gibt es auch nicht. Daher sind Steigerungen der ST-Leistung der einzige Weg, um eine bessere Spielbarkeit in SupCom2 zu erreichen. Das ist sehr ärgerlich, aber leider Teil der Realität. Und das gilt für etliche andere Software, nicht nur Spiele, genauso. Bis wirklich alle leistungskritische Software effizient breites Multitthreading unterstützt, wird es noch viele Jahre dauern. Und solange es keine Durchbrüche bei Taktfrequenz/Stromverbrauch gibt, wird hohe/steigende IPC damit für viele Anwender wichtig bleiben.

 

[sompe]

Interessante Sichtweise aber sind ebend jene Sparc und Power Prozessoren nicht auf Leistung getrimmt, bekommen ohnehin angepasste Software vorgesetzt und können so per SMT noch das letzte Fitzelchen Leistung aus dem Design quetschen?
Alles Faktoren von denen wir bei den PC Prozessoren bestenfalls träumen können.
Nicht vergessen die Leistung des Kerns mit SMT ist letztendlich wie die Leistung mehrerer Kerne multithreading Leistung. Bei dem 8 kernigen Power 7 kämen wir dann nämlich erst mit 32 Threads auf die volle Leistung.

 

[gruffi]

Insofern erlaubt es der Einsatz von SMT, höhere ST-Leistung zu erzielen, die bei einem nicht-SMT-Entwurf nicht zu rechtfertigen wäre.

Wieso sollte der nicht gerechtfertigt sein, wenn einem singlethreaded Performance wichtig ist? Ein Kern muss nicht auf maximale Effizienz getrimmt sein. Letztendlich ist es immer ein Abwägen von Kompromissen. Performance, Leistungsaufnahme, Taktbarkeit, Effizienz usw. Es gibt viele Faktoren, die Priorität haben können. Also ich sehe da nach wie vor keinen direkten Zusammenhang. SMT macht singlethreaded nicht schneller. SMT erhöht einfach die Auslastung durch Multithreading.

Vergleiche dazu auch die dicken Kerne von POWER7 und SPARC64 X. Mir sind schlichtweg keine Architekturen bekannt, die z.B. 4 FPUs hätten aber kein SMT.

Ich kenne ausser Bulldozer auch keinen x86 Prozessor, der 2 128-bit FMACs + 2 128-bit Integer Einheiten pro Kern besitzt, die alle einem einzelnen Thread zur Verfügung gestellt werden können. Trotzdem ist es kein singlethreaded Monster. Das eine hat mit dem anderen wenig zu tun. Entscheidender ist die Anbindung und die gesamte Pipeline. Viele EUs ist kein Exklusivmerkmal von SMT. Es ist ja auch nicht so, dass eine Architektur explizit für SMT entworfen wird. In der Vergangenheit wurde das später meist einfach hineingefrickelt. War beim DEC Alpha so, war bei Intel Core so und war auch beim IBM POWER so. Ich glaube, du zäumst das Pferd von der falschen Seite auf. Man entwickelt keine Architektur mit SMT, um hohe singlethreaded Performance zu erreichen. Hohe singlethreaded Performance war dann schon vorher gegeben durch eine entsprechend breit ausgelegte Pipeline. Bis man erkennt, dass so Ressourcen oft ungenutzt bleiben. SMT ist dann vermutlich die einfachste Lösung, um diese Ressourcen doch noch zu nutzen. Also nochmal, es ist in keinster Weise SMT notwendig, um hohe singlethreaded Performance zu erzielen. SMT "ermöglicht" auch keine hohe singlethreaded Performance. Dafür ist immer noch die grundlegende Pipeline verantwortlich. Generell würde ich eher sagen, dass jegliche Multithreading Technologie auf Kernebene erstmal nachteilig für singlethreaded Performance ist. Warum? Weil dadurch zusätzliche Logik ins Design kommt, um die Threads zu verwalten bzw zu steuern, was Latenz kosten kann. Und ob SMT die einzige Lösung ist, um effiziente single-/multithreaded Hybridkerne zu entwickeln, darf mehr als bezweifelt werden.

Eine bessere Einheitenverwaltung wäre sicherlich eine Lösung. Nur hatte der Entwickler GPG dafür kein Geld mehr, die waren froh, das Spiel überhaupt fertigstellen zu können.

Das kann doch aber keine Rechtfertigung sein. Das gleiche kann ich auch über Hardwarehersteller und Prozessoren sagen. Die hatten einfach keine Zeit, noch mehr für singlethreaded Workloads zu optimieren und waren froh, den Prozessor überhaupt fertig zu stellen. Also bevor man voreilig eine Seite kritisiert, sollte man erstmal genau überlegen, wo die Kritik wirklich angebracht ist. Wenn ein Softwarehersteller kein Geld mehr hat, ist das zwar schade. Nur darf das keine Rechtfertigung gegen die Weiterentwicklung von Software sein. Da muss ich dann einfach festhalten, Fehlplanung von Beginn an. Wer glaubt, seine Software immer noch so designen zu müssen wie vor 25 Jahren, hat einfach den Anschluss verpennt.

 

[Ge0rgy]

Seit wann ist Core 2 4-Fach superskalar? - wenn ich mich erinnere hatte er womöglich 4 decoder, aber keineswegs echte 4-fache OoO-Pipeline. (Er hatte auch fette caches und eine nahezu unfehlbare Sprungvorhersage, das trägt IMHO größeren Anteil an der IPC als die 4-Fach superskalarität)
Nebenbei bemerkt, du beziehst dich auf die real erreichte Performance die pro takt um 50% gesteigert wurde. Wenn man vorher aber grade mal bei rund 1 in der Praxis war, kann man 1,5 erreichen, ist noch weit vom theoretischen maximum entfernt und dabei hat man auch 50% gewinn.
Lies mal die Ausführungen von Agner Fog zum Thema Auslastung der Prozessoren, schlechtem Code usw.
Möglicherwiese mag mittlerweile durch bessere Compiler etc. das Limit etwas angehoben sein, aber das mit OoO versteh ich in dem Zusammenhang nicht wirklich.
Out-Of-Order dient doch überhaupt nur dazu die dem Code inhärente Parallelizität überhaupt nutzen zu können.
Die Befehle stehen alle hintereinander im Speicher, bei In-Order muss ich sie aber in genau der Reihenfolge abarbeiten, selbst wenn die halbe Pipeline wegen ungünstiger Positionierung Däumchen dreht.
OoO ermöglicht dem Prozessor die Riehenfolge "umzudrehen" und die Instruktionen die unabhängig voneinander sind, gleichzeitig zu verarbeiten, egal wie rum sie ankommen. (In einem gewissen Rahmen natürlich) Wenn aber nur ein geringer parallelizitätsgrad insgesamt herrscht, und man keine spekulative Ausführung oder ähnliche tricks verwendet, hilft die beste OoO - Pipeline bei skalarem code erstmal nichts, wenn jeder befehl direkt das ergebnis des vorhergehenden nutzen muss! - dann kann er nämlich erst ausgeführt werden wenn eben das ergebnis berechnet wurde, egal wie superdupermegaskalar die CPU arbeitet.
Hier gibt es also eine natürliche grenze, wenn man SIMD-Instruktionen usw. mal aussen vor lässt.
Memory Disambiguation hilft auch zu einem gewissen teil. Aber wer glaubt dass es ewig so weitergeht der irrt. Ob man 20% überhaupt als zugewinn bezeichnen will oder nicht ist eine ganz andere Sache... in manchen Wissenschaftszweigen wird mit "Größenordnungen" argumentiert, also verzehnfachungen etc. und alles darunter ist vernachlässigbar... nunja...
Aber das alles ist eine eher Theoretische Diskussion... und ich will auch keinem ans Bein pinkeln.
Intel schafft momentan eine IPC durchschnittlich von mehr als 2 Instruktionen pro Takt (hat dieses Messtool von opteron im anderen Thread mal ausgespuckt) und das ist eine durchaus respektable Leistung.
IMHO ist das aber viel eher eine Folge von ausgeklügelter Cachearchitektur und cleverer Sprungvorhersage/Prefetching usw. das genza "Fließband" das die Instruktionen ranschafft ist gut geölt. Deswegen funktioniert das so gut, nicht wegen 4-fach superskalar.

 

[Twodee]

http://live.cnet.com/Event/Intels_CES_2013_keynote

 

[isigrim]

Sieht wie ein kleiner Seitenhieb auf AMD bzw Rory aus.

 

[gruffi]

Och, Seitenhiebe gegen Intel kann AMD auch gut austeilen:

We are developing technologies with end users in mind
...
It is exciting to bring our leadership APU technologies to market including the industry’s first x86 quad-core SoC, while building on our leadership in graphics and gaming.

 

[isigrim]

Anand hat einen Teaser zur maximalen GPU-leistung von Haswell gepostet.
Dabei wird relativ sinnfrei nebeneinander ein frühes Haswell-Notebook-System (in einem Desktop-Gehäuse) gegen ein Notebook mit GT650M bei Dirt3 verglichen. Sinnfrei, weil hier keine Framerates zu sehen sind....es wir nur suggeriert, dass die GT3e so schnell sit wie eine GT650M. Sollte das zutreffen, wäre es natürlich schon bemerkenswert.
Aber so wie es präsentiert ist, dient es wohl mehr zur Steigerung der Klickzahlen als zur Information.
Für alle die sich jetzt einschießen: Ich finde es lustig, wie mit keinem Wort darauf eingegangen wird, dass AMD schon eine ziemlich gute integrierte GPU bei Llano und Trinity bietet, die offenbar mit Richland nochmal verbessert wird....aber bei AnandTech wird nur über Intel und Nvidia geredet.

 

[BavarianRealist]

... Ich finde es lustig, wie mit keinem Wort darauf eingegangen wird, dass AMD schon eine ziemlich gute integrierte GPU bei Llano und Trinity bietet, die offenbar mit Richland nochmal verbessert wird....aber bei AnandTech wird nur über Intel und Nvidia geredet.

War nicht anandtech einer der wenigen (oder gar der einzige?), der seinerzeit als erstes exklusiv mit den ersten Conroe-Samples bedient wurde?

 

[gruffi]

aber bei AnandTech wird nur über Intel und Nvidia geredet.

Wieso wundert dich das? Anandtech ist seit jeher eine Intel Werbeseite und dementsprechend kontra AMD eingestellt.

 

[isigrim]

Es wundert mich nicht, ich finde es lustig. Wundern tut mich in dieser Richtung inzwischen wenig.

 

[isigrim]

Ich hatte mir eigentlich vorgenommen, auf den erwarteten Beitrag von Dir nicht zu reagieren, aber ich muss zugeben, dass ich mich nicht zurückhalten kann. Ich dachte zudem, dass du etwas schneller bist.

1. Meine Intention ist wie an anderer Stelle bei Anandtech auch, dass man ohne solide Grundlage keine weitreichenden Hypothesen aufstellen oder Andeutungen machen sollte. Das ist eben kein Journalismus, wie er Anandtech würdig ist. Die leisten teils wirklich gute Arbeit und dann machen sie wieder so PR-Zeug.
2. Einzige Information ist, dass Haswell wohl Dirt 3 in High ohne AA in FullHD flüssig darstellen kann. Aber jetzt die Preisfrage: Wozu stellt man eine GT650 daneben? Wenn man das genannte zeigen wollte, könnte man die GT650M auch einfach weglassen oder?
3. Selbiges hat AMD gemacht, als sie ihr Temash-QuadTablet mit Dirt in FullHD gezeigt haben. Da gab´s kein Intel HD4000 Vergleichssystem, sondern nur das AMD Tablet. Oder auf was spielst Du mit deinem "Die suggerieren, dass ihre kleine Pups Tablet GPU die ULV HD4000 überholt." ("Pups-Tablet" zeigt übrigens mal wieder wie fein Du Dich ausdrücken kannst.)
4. Damit erledigt sich für mich auch mein Entsetzen gegenüber AMD, weil ich da nicht sehe, dass sie in der Richtung arbeiten. Aber Du darfst mir gerne Links zeigen, dann entsetze ich mich auch mit.
5. Der A10-4600M wäre wahrscheinlich wirklich "abgekackt", allerdings habe ich kein System damit da um das zu überprüfen. Aber zum einen dürfte er preislich nicht der Gegner der Intels mit GT3e sein, andererseits wäre wenn dann Richland das passende Pendant.
6. Ja, möglich, dass Trinity und Richland gegen GT3e "abkacken", aber da warte ich einfach mal unabhängige Messungen ab, bevor ich mich aufplustere und mehrmals Fäkalsprache benutze.

7. An der Stelle bei hothardware fällt mir nur auf, dass da interessanterweise bei Intel auf der CES genau die Konfigurationen bei der Tablet-Strommessung vorgeführt werden die vorher breit in dem Stromanalyse-Artikel bei Anandtech besprochen wurden. Ein Schelm wer böses dabei denkt und vielleicht meint, dass der Artikel bei Anandtech von Intel angestoßen / in Auftrag gegeben wurde.

Ich freue mich übrigens, dass auch Intel endlich erkannt hat, dass eine hohe Grafikleistung für die integrierten GPUs wichtig ist. Zumindest da hat AMD tatsächlich noch was bewirkt.

 

[gruffi]

@fluant

Wo suggeriert AMD, dass die kleine Pups ULV HD 4000 überholt wird? Wenn man glaubt, dass die HD 4000 bei niedrigen Taktraten irgendwem die Butter vom Brot zieht, ist man echt naiv. Bei Intel hat Cherry-Picking übrigens noch mehr Tradition. Da gab es in den letzten Jahren so viel, von versprochenen knapp 50% mehr Penryn Performance, wovon im Alltag gut 5% übrig blieb, bis hin zu gefakten "Live-Demos", die sich als vorgefertigte Videos entpuppten. Klar betreibt AMD auch Cherry-Picking. Wer aber genau hinschaut, dem wird idR die Testplattform samt Anwendungen mitgeliefert. Das findet man bei Intel entweder nur in Fussnoten oder wird gleich ganz verschwiegen. Und bei AMD bekommt man auch echte Live-Demos, ohne gefakte Schöndarstellerei. Also behaupte hier nicht solchen Käse, AMD wäre 3 Nummern schlimmer. Umgekehrt haut das schon eher hin.

"Pups-Tablet" zeigt übrigens mal wieder wie fein Du Dich ausdrücken kannst.

Naja, es zeigt vor allem einmal mehr seine irrationale Abneigung gegenüber AMD. Und lustig wird es dann, wenn er anderen fehlende Objektivität vorwirft. Aber gut, wer so subjektiv Anti-AMD eingestellt ist, dem muss Objektivität ziemlich subjektiv vorkommen.

Ich freue mich übrigens, dass auch Intel endlich erkannt hat, dass eine hohe Grafikleistung für die integrierten GPUs wichtig ist. Zumindest da hat AMD tatsächlich noch was bewirkt.

Kann nicht sein. Die Intel Fanboys erzählen uns doch immer, dass iGPU belanglos ist und nur die CPU zählt. Und die müssen es doch wissen.

 

[gruffi]

Ich sehe keine entsprechende News. Und ich bin auch kein Hellseher, um zu wissen, auf was du anspielst oder was du dir aus den Fingern saugst. Du bleibst also weiterhin eine Quelle schuldig. Und die Pups ULV HD 4000 zieht trotzdem niemandem die Butter vom Brot. Der HD 4000 fehlen schon mal 50% oder mehr der Performance der grossen AMD APUs. Wenn man bedenkt, dass Temash 1/3 an Shadern hat, dafür aber die effizientere GCN Architektur, und die Intel ULV Modelle im Takt beschnitten sind, ist es naiv zu glauben, die Pups ULV HD 4000 würde Temash einfach so hinter sich lassen können.

 

[y33H@]

Die 17W-ULVs boosten idR auf 1000+ MHz. Das reicht für AMDs 17W-Trinitys.