Bericht AMD Naples: Erste Benchmarks zur 32-Kern-CPU mit Octa-Channel-RAM

[Krautmaster]

@rockwell1080

würde mich nicht wundern wenn man dabei das AMD System auf dieselbe Anzahl Threads beschränkt hat wie das Intel System, drunter aber dennoch die vollen 64 Kerne arbeiten können (nur halt eben bei 88 Threads statt 128 Threads).

Sollten es auch wirklich 44 Kerne sein ist es wohl in erster Linie über den Takt und Ram Durchsatz zu erklären. Anandtech hat ja bereits dargestellt dass der Prozess hervorragend bis ~3 Ghz skaliert und dabei super effizient ist. Möglich dass AMD hier sogar weit mehr Takt fahren kann als Intel.

Zusammen mit der "alten" Boardwell Architektur (im Consumer Chip ~10-15% langsamer als Skylake) reicht das vermutlich in der Demo um Intel deutlich zu schlagen.

Auffallen tut auch dass die 44 Kerne + 1866 Mhz Ram kaum langsamer sind als die vollen 64 Kerne.

Cool wärs dennoch wenn AMD beim 2P aufmischt.

 

[VikingGe]

@Khalinator Crysis 1 könnte so ein System wohl theoretisch mit Software-Rendering flüssig darstellen. 64 Zen-Kerne bei 2.2 GHz hätten etwa 2.2 TFlops, das ist die Rohleistung von ner RX 460 - klar fehlt da einiges an Fixed Function-Hardware, die man auf Grafikkarten so findet, aber sollte ausreichen.

Mich würde auch mal interessieren, ob Intels SWR auf den Dingern läuft. Anwendungen für Software-Rasterizer existieren ja durchaus.

 

[fdsonne]

Das es von Intel auch einen wirklichen Wettbewerber der Skalierungstechnisch ein Dual Proessor System wäre die Xeon E5 Serie (u.a. zu finden in System X3650 Servern ab meine M4) wurde einfach ignoriert...

Nein, das hat schon einen tieferen Sinn das auf die NUMA Node Anzahl runter zu brechen.
Mal ein Beispiel, ich hab hier Systeme von 2P Westmere (6C, 72GB RAM, TrippleChannel SI pro Socket und NUMA Node) über Ivy 1P (12C, 192GB RAM, QuadChannel SI) bis zu 2P Broadwell (20C, 768GB RAM, QuadChannel SI pro Socket und NUMA Node)
Der Mailserver läuft mit 32GB und 4x vCPUs als VM (1P/4C) das bedeutet, das Westmere System müsste quasi die Hälfte des kompletten RAM eines Prozessors für diese eine VM bereit halten, denn jegliche Querzugriffe zwischen den Nodes sind sehr langsam und haben hohe Latenz. Habe ich nun 2x solcher VMs, habe ich ein Problem. Denn es passen zwar noch 32GB RAM in den Memory, aber beide VMs streiten sich dann um Prozessorzeit (unter Last), der Host wird also primär die zweite VM auf dem 2. Prozessor legen. Ein Nachteil ensteht dabei bei den Möglichkeiten zum Ressourcen Sharen. Man bindet quasi sehr hohe RAM Mengen an wenige VMs obwohl die CPU Cores nicht zwangsweise durch diese VM belegt werden müssen. So könnten bspw. weitere VMs ohne viel RAM aber recht hoher vCPU Last vorhanden sein. Man hätte dann ein Zuteilungsproblem.
Das gleiche hast du bspw. wenn du pro Core schaust, auf dem Westmere System wären 8x vCPUs pro VM nur mit 2P/4C möglich. Der Nachteil der auch daraus entsteht liegt beim Host, ein Zeitfenster für Rechenzeit so einer VM bedeutet es dürfen jeweils 4x Cores pro Socket zur selben Zeit!! keine Berechnungen ausführen damit so ein Zeitfenster überhaupt angefordert werden kann. Die VM wird also vergleichsweise träge weil alle Nase lang auf ein passendes Workload-Fenster gewartet werden muss. Würde man der VM hingegen 1P/8C geben, legte der Host das auf einen Prozessor und die Leistungsskalierung ist äußerst mau, da acht vCPUs sich zwangsweise sechs Cores teilen.
Lasse ich den Mailserver auf dem mit nur einem Sockel bestückten Ivy System laufen, kann ich das spielend abfedern. Denn dem einen NUMA Node ist aller RAM und alle Cores zugeteilt. Der Mailserver als VM nimmt fort also vom RAM und von Prozessor ohne ein künstliches Limit.

Bei VMware kann man für solche Thematiken bspw. diverse Counter auslesen.

Um so mehr NUMA Nodes man hat, desto proplematischer wird der Spaß. Der Naples wäre also in so einem Konstrukt pro VM sinnigerweise auf 1/4 des halben Host RAMs beschränkt und eben auf 1/4 des physical Core Counts jeweils pro Socket.
Ein Single Node System skaliert dabei sogar noch auf 24 vCPUs (32 dann mit Skylake) und eben volle RAM Menge pro Socket, wobei das eher untypisch sein dürfte.
Das ganze lässt sich umgehen indem man Software nutzt die NUMA "versteht". Das heist unter anderem nicht von x-beliebigen Threads auf x-beliebige RAM Teile zugreifen, sondern pro Thread nur beschränkte Speicherbereiche zu nutzen, so dass eben das OS diese Verteilung auch hin bekommt.
Oder man erhöht einfach die RAM Menge pro NUMA Node, das geht aber ab einem gewissen Punkt nicht mehr. 8x NUMA Nodes und 4TB bedeutet pro Node 512GB. Wohl in Form von 4x128GB LRDIMM. Diese Riegel sind aber wenig Massentauglich bei fünfstelligen Beträgen pro Riegel... Gängig sind 16-64GB Riegel (L)RDIMM. Macht dann 64-256GB pro Node. So einem Host mit 16GB Riegeln vollsteckt macht zwar in Summe 512GB, mit VMs zu 64GB RAM tut es sich aber schon schwer

 

[Tekpoint]

AMD hat es wirklich drauf und lässt Intel endlich mal schwitzen Ich kauf mir ein AMD das steht fest jetzt

 

[Simon]

Warum sind die Hardwarekosten eine Randnotiz für 4TB Ram pro Server? Ober liege ich falsch das man solche Hardware zum virtualisieren nutzt? Wir nutzen 1,5TB Ram pro Server aktuell und da ist die Hardware keine Randnotiz...

Also nen ESXer mit 4 TB RAM bestücken, würde mir ja nicht in den Sinn kommen. Da läuft dann eher was in Richtung In-Memory-Datenbanken und/oder Analyse-Software drauf. Solange es keine einzelnen virtuellen Maschinen gibt, die 4 TB virtuellen RAM benötigen, halte ich das für Quatsch. Die Failure-Domain wäre mir dabei viel zu hoch.

Wenn die Farm 12 TB RAM besitzen soll, würde ich mich im Zweifelsfall statt 3 x 4 TB RAM Hosts eher für 6 x 2 TB RAM entscheiden. Nicht nur, weil die 128 GB LRDIMMs wie schon richtig erkannt abartig teuer sind, sondern weil ich bei Ausfall/Wartung einer Maschine nicht gleich auf 1/3 aller Ressourcen verzichten wollte. Wenn ich mir allein vorstelle, wie lange es dauert, einen Hypervisor mit 4 TB RAM zu Wartungszwecken zu evakuieren. Bei 10 Gig Ethernet dauert das schon über eine Stunde, also muss schon fast 40 Gbit/s (oder gar 100) Ethernet her, was die Infrastrukturkosten im Netzwerk nochmal zusätzlich erhöht. Den Aufpreis für zusätzliche CPU-Socket-Lizenzen muss man dann zwar in Kauf nehmen, dürfte sich aber in etwa ausgehen.

Aber das sieht jeder VMware-Consultant ein wenig anders, jedoch hab ich nach 10 Jahren vSphere gelernt, dass die Konsolidierung auch nicht zu weit getrieben werden sollte. Die auf dem Papier günstigste Lösung ist nicht immer die sinnvollste.

 

[yummycandy]

Der Output von coreinfo sieht wirklich witzig aus

Spoiler

AMD Ryzen: ZD3601BAM88F4_40/36_Y
AMD64 Family 23 Model 1 Stepping 1, AuthenticAMD
HTT * Multicore
HYPERVISOR - Hypervisor is present
VMX - Supports Intel hardware-assisted virtualization
SVM * Supports AMD hardware-assisted virtualization
X64 * Supports 64-bit mode

SMX - Supports Intel trusted execution
SKINIT * Supports AMD SKINIT

NX * Supports no-execute page protection
SMEP * Supports Supervisor Mode Execution Prevention
SMAP * Supports Supervisor Mode Access Prevention
PAGE1GB * Supports 1 GB large pages
PAE * Supports > 32-bit physical addresses
PAT * Supports Page Attribute Table
PSE * Supports 4 MB pages
PSE36 * Supports > 32-bit address 4 MB pages
PGE * Supports global bit in page tables
SS - Supports bus snooping for cache operations
VME * Supports Virtual-8086 mode
RDWRFSGSBASE * Supports direct GS/FS base access

FPU * Implements i387 floating point instructions
MMX * Supports MMX instruction set
MMXEXT * Implements AMD MMX extensions
3DNOW - Supports 3DNow! instructions
3DNOWEXT - Supports 3DNow! extension instructions
SSE * Supports Streaming SIMD Extensions
SSE2 * Supports Streaming SIMD Extensions 2
SSE3 * Supports Streaming SIMD Extensions 3
SSSE3 * Supports Supplemental SIMD Extensions 3
SSE4a * Supports Streaming SIMDR Extensions 4a
SSE4.1 * Supports Streaming SIMD Extensions 4.1
SSE4.2 * Supports Streaming SIMD Extensions 4.2

AES * Supports AES extensions
AVX * Supports AVX intruction extensions
FMA * Supports FMA extensions using YMM state
MSR * Implements RDMSR/WRMSR instructions
MTRR * Supports Memory Type Range Registers
XSAVE * Supports XSAVE/XRSTOR instructions
OSXSAVE * Supports XSETBV/XGETBV instructions
RDRAND * Supports RDRAND instruction
RDSEED * Supports RDSEED instruction

CMOV * Supports CMOVcc instruction
CLFSH * Supports CLFLUSH instruction
CX8 * Supports compare and exchange 8-byte instructions
CX16 * Supports CMPXCHG16B instruction
BMI1 * Supports bit manipulation extensions 1
BMI2 * Supports bit manipulation extensions 2
ADX * Supports ADCX/ADOX instructions
DCA - Supports prefetch from memory-mapped device
F16C * Supports half-precision instruction
FXSR * Supports FXSAVE/FXSTOR instructions
FFXSR * Supports optimized FXSAVE/FSRSTOR instruction
MONITOR * Supports MONITOR and MWAIT instructions
MOVBE * Supports MOVBE instruction
ERMSB - Supports Enhanced REP MOVSB/STOSB
PCLMULDQ * Supports PCLMULDQ instruction
POPCNT * Supports POPCNT instruction
LZCNT * Supports LZCNT instruction
SEP * Supports fast system call instructions
LAHF-SAHF * Supports LAHF/SAHF instructions in 64-bit mode
HLE - Supports Hardware Lock Elision instructions
RTM - Supports Restricted Transactional Memory instructions

DE * Supports I/O breakpoints including CR4.DE
DTES64 - Can write history of 64-bit branch addresses
DS - Implements memory-resident debug buffer
DS-CPL - Supports Debug Store feature with CPL
PCID - Supports PCIDs and settable CR4.PCIDE
INVPCID - Supports INVPCID instruction
PDCM - Supports Performance Capabilities MSR
RDTSCP * Supports RDTSCP instruction
TSC * Supports RDTSC instruction
TSC-DEADLINE - Local APIC supports one-shot deadline timer
TSC-INVARIANT * TSC runs at constant rate
xTPR - Supports disabling task priority messages

EIST - Supports Enhanced Intel Speedstep
ACPI - Implements MSR for power management
TM - Implements thermal monitor circuitry
TM2 - Implements Thermal Monitor 2 control
APIC * Implements software-accessible local APIC
x2APIC - Supports x2APIC

CNXT-ID - L1 data cache mode adaptive or BIOS

MCE * Supports Machine Check, INT18 and CR4.MCE
MCA * Implements Machine Check Architecture
PBE - Supports use of FERR#/PBE# pin

PSN - Implements 96-bit processor serial number

PREFETCHW * Supports PREFETCHW instruction

Maximum implemented CPUID leaves: 0000000D (Basic), 8000001F (Extended).

Logical to Physical Processor Map:
**-------------- Physical Processor 0 (Hyperthreaded)
--**------------ Physical Processor 1 (Hyperthreaded)
----**---------- Physical Processor 2 (Hyperthreaded)
------**-------- Physical Processor 3 (Hyperthreaded)
--------**------ Physical Processor 4 (Hyperthreaded)
----------**---- Physical Processor 5 (Hyperthreaded)
------------**-- Physical Processor 6 (Hyperthreaded)
--------------** Physical Processor 7 (Hyperthreaded)

Logical Processor to Socket Map:
**************** Socket 0

Logical Processor to NUMA Node Map:
**************** NUMA Node 0

No NUMA nodes.

Logical Processor to Cache Map:
*--------------- Data Cache 0, Level 1, 32 KB, Assoc 8, LineSize 64
*--------------- Instruction Cache 0, Level 1, 64 KB, Assoc 4, LineSize 64
*--------------- Unified Cache 0, Level 2, 512 KB, Assoc 8, LineSize 64
*--------------- Unified Cache 1, Level 3, 16 MB, Assoc 16, LineSize 64
-*-------------- Data Cache 1, Level 1, 32 KB, Assoc 8, LineSize 64
-*-------------- Instruction Cache 1, Level 1, 64 KB, Assoc 4, LineSize 64
-*-------------- Unified Cache 2, Level 2, 512 KB, Assoc 8, LineSize 64
-*-------------- Unified Cache 3, Level 3, 16 MB, Assoc 16, LineSize 64
--*------------- Data Cache 2, Level 1, 32 KB, Assoc 8, LineSize 64
--*------------- Instruction Cache 2, Level 1, 64 KB, Assoc 4, LineSize 64
--*------------- Unified Cache 4, Level 2, 512 KB, Assoc 8, LineSize 64
--*------------- Unified Cache 5, Level 3, 16 MB, Assoc 16, LineSize 64
---*------------ Data Cache 3, Level 1, 32 KB, Assoc 8, LineSize 64
---*------------ Instruction Cache 3, Level 1, 64 KB, Assoc 4, LineSize 64
---*------------ Unified Cache 6, Level 2, 512 KB, Assoc 8, LineSize 64
---*------------ Unified Cache 7, Level 3, 16 MB, Assoc 16, LineSize 64
----*----------- Data Cache 4, Level 1, 32 KB, Assoc 8, LineSize 64
----*----------- Instruction Cache 4, Level 1, 64 KB, Assoc 4, LineSize 64
----*----------- Unified Cache 8, Level 2, 512 KB, Assoc 8, LineSize 64
----*----------- Unified Cache 9, Level 3, 16 MB, Assoc 16, LineSize 64
-----*---------- Data Cache 5, Level 1, 32 KB, Assoc 8, LineSize 64
-----*---------- Instruction Cache 5, Level 1, 64 KB, Assoc 4, LineSize 64
-----*---------- Unified Cache 10, Level 2, 512 KB, Assoc 8, LineSize 64
-----*---------- Unified Cache 11, Level 3, 16 MB, Assoc 16, LineSize 64
------*--------- Data Cache 6, Level 1, 32 KB, Assoc 8, LineSize 64
------*--------- Instruction Cache 6, Level 1, 64 KB, Assoc 4, LineSize 64
------*--------- Unified Cache 12, Level 2, 512 KB, Assoc 8, LineSize 64
------*--------- Unified Cache 13, Level 3, 16 MB, Assoc 16, LineSize 64
-------*-------- Data Cache 7, Level 1, 32 KB, Assoc 8, LineSize 64
-------*-------- Instruction Cache 7, Level 1, 64 KB, Assoc 4, LineSize 64
-------*-------- Unified Cache 14, Level 2, 512 KB, Assoc 8, LineSize 64
-------*-------- Unified Cache 15, Level 3, 16 MB, Assoc 16, LineSize 64
--------*------- Data Cache 8, Level 1, 32 KB, Assoc 8, LineSize 64
--------*------- Instruction Cache 8, Level 1, 64 KB, Assoc 4, LineSize 64
--------*------- Unified Cache 16, Level 2, 512 KB, Assoc 8, LineSize 64
--------*------- Unified Cache 17, Level 3, 16 MB, Assoc 16, LineSize 64
---------*------ Data Cache 9, Level 1, 32 KB, Assoc 8, LineSize 64
---------*------ Instruction Cache 9, Level 1, 64 KB, Assoc 4, LineSize 64
---------*------ Unified Cache 18, Level 2, 512 KB, Assoc 8, LineSize 64
---------*------ Unified Cache 19, Level 3, 16 MB, Assoc 16, LineSize 64
----------*----- Data Cache 10, Level 1, 32 KB, Assoc 8, LineSize 64
----------*----- Instruction Cache 10, Level 1, 64 KB, Assoc 4, LineSize 64
----------*----- Unified Cache 20, Level 2, 512 KB, Assoc 8, LineSize 64
----------*----- Unified Cache 21, Level 3, 16 MB, Assoc 16, LineSize 64
-----------*---- Data Cache 11, Level 1, 32 KB, Assoc 8, LineSize 64
-----------*---- Instruction Cache 11, Level 1, 64 KB, Assoc 4, LineSize 64
-----------*---- Unified Cache 22, Level 2, 512 KB, Assoc 8, LineSize 64
-----------*---- Unified Cache 23, Level 3, 16 MB, Assoc 16, LineSize 64
------------*--- Data Cache 12, Level 1, 32 KB, Assoc 8, LineSize 64
------------*--- Instruction Cache 12, Level 1, 64 KB, Assoc 4, LineSize 64
------------*--- Unified Cache 24, Level 2, 512 KB, Assoc 8, LineSize 64
------------*--- Unified Cache 25, Level 3, 16 MB, Assoc 16, LineSize 64
-------------*-- Data Cache 13, Level 1, 32 KB, Assoc 8, LineSize 64
-------------*-- Instruction Cache 13, Level 1, 64 KB, Assoc 4, LineSize 64
-------------*-- Unified Cache 26, Level 2, 512 KB, Assoc 8, LineSize 64
-------------*-- Unified Cache 27, Level 3, 16 MB, Assoc 16, LineSize 64
--------------*- Data Cache 14, Level 1, 32 KB, Assoc 8, LineSize 64
--------------*- Instruction Cache 14, Level 1, 64 KB, Assoc 4, LineSize 64
--------------*- Unified Cache 28, Level 2, 512 KB, Assoc 8, LineSize 64
--------------*- Unified Cache 29, Level 3, 16 MB, Assoc 16, LineSize 64
---------------* Data Cache 15, Level 1, 32 KB, Assoc 8, LineSize 64
---------------* Instruction Cache 15, Level 1, 64 KB, Assoc 4, LineSize 64
---------------* Unified Cache 30, Level 2, 512 KB, Assoc 8, LineSize 64
---------------* Unified Cache 31, Level 3, 16 MB, Assoc 16, LineSize 64

Logical Processor to Group Map:
**************** Group 0

Achso, ist natürlich auch von hier: https://forums.anandtech.com/threads/ryzen-strictly-technical.2500572/#post-38770528

 

[Loopman]

Nein, das hat schon einen tieferen Sinn...

Nein, hat es nicht. Du vergleichst 2 komplett unterschiedliche Einsatzbereiche miteinander. Da kannst du noch so blumig deine Texte schreiben

...jedoch hab ich nach 10 Jahren vSphere gelernt, dass die Konsolidierung auch nicht zu weit getrieben werden sollte. Die auf dem Papier günstigste Lösung ist nicht immer die sinnvollste.

So sieht es aus. Viele sehen oder verstehen die Kosten und Nachteile auf den Nebenschauplätzen nicht.

 

[Ground0]

Naja bzgl. Tot von AMD im Servermarkt. Sie waren nie Tot, einfach nur nicht die Leistung geliefert. Für günstige 64 Core Server in einer Farm mit niedrigem TDP hatten Sie immer was im Angebot. Habe gerade selbst das Vergnügen eine Cloud Umgebung mit 512 Cores aufzubauen. für ca 80'000 CHF was mit Intel nicht für diesen Preispunkt möglich gewesen wäre.

Jeder Server besteht aus 4* Opteron 6366HE(ältere 6262HE) + 128GB oder 64GB per CPU.Das teuerste an den Servern Einzelkomponenten waren noch die X540 Intel 10GBit Netzwerkkarten. Darauf sind jeweils mehrere Java Applikationen (Apache/Tomcat/MySQL) Welche sehr gut mit dedizierten Core reagieren. Da hier das wechseln zwischen den VM's auf den Cores entfällt.

Da in dem Bereich aber leider meistens auf Intel gebaut wird da diese im Normalfall einfach nur mehr Leistung liefern. Für Cloud und VM Farmen baue ich schon länger nur auf AMD, P/L mäßig für solche Szenarien ungeschlagen.

Da freue ich mich persönlich schon auf den Naples darf ich ja jetzt endlich auch sagen :-) (NDA)

 

[Atent123]

Höflich formuliert so ernüchternd wie die unabhängigen Tests gezeigt haben gegenüber dem, ja nennen wir es mal "Lügen", was AMD vorher vollmundig versprochen hat.
Und auch hier wird, wenn man schon jetzt die Anzahl der Kerne und den RAM Ausbau streicht, auch "nur" ein herankommen an Intel übrig bleiben.

Tut mir leid wo hat AMD den bitte gelogen ?
Die Software ist halt noch nicht wirklich Ryzen kompatibel und die Biose brauchen updates. Das sind Kinderkrankheiten.

 

[Pana]

Davon vier Stück in einem Server und Windows Server 2016 Datacenter kostet dann rund 90.000 Euro - pro Server

 

[Krautmaster]

davon ein halber auf AM4 wäre doch was gewesen. Mit Quadchannel und bis 8 DDR Slots. Und nicht erst 2019 sondern demnächst.
16 Kerne / 32 Threads. Sollte bei ~3 Ghz easy machbar sein da der Prozess bis dahin sehr effizient rennt. Außerdem spart sich - was viele hier ja vergessen, AMD die GPU. Und die macht schon bei Kaby Lake ja schnell halbe DIE Size aus.

 

[YoWoo]

Du meinst die von CB? Da müsste eh mal nachgebessert werden:
http://semiaccurate.com/forums/showpost.php?p=284541&postcount=7807

Bei welcher Firma arbeitest du denn, wenn ihr schon auf Naples umsteigt, und da scheint ja AMD gut aufgestellt zu sein, wenn ihr gleich zu Beginn wechselt. Mehr darfst du ja sicherlich nicht sagen?

 

[haha]

umso verwunderlicher das ryzen dann gegenüber naples gradmal dualchannel hat. könnte man sicherlich auf quadchannel aufstocken und dennoch 4 speicherbänke belassen. sollte für jeden home user ausreichend sein.

Das ist schon korrekt so. 4 Ryzen Dies werden wohl den Napples bilden und das Speicherinterface eines jeden Ryzen Dies wird dabei wohl rausgeführt. Also 4x2 = 8.

 

[pipip]

16 Kerne / 32 Threads. Sollte bei ~3 Ghz easy machbar sein da der Prozess bis dahin sehr effizient rennt. Außerdem spart sich - was viele hier ja vergessen, AMD die GPU. Und die macht schon bei Kaby Lake ja schnell halbe DIE Size aus.

 

[Schnitz]

Anhang anzeigen 611087

Sorry, den konnt ich mir nicht verkneifen ^^

In Spielen sieht es leider weniger gut aus - speziell mit aktiviertem SMT. Dieses erweist sich, wie auch die Inter-CCX-Kommunikation, häufig als Bremse. Hier muss AMD mit guter Dokumentation und gutem Support die Entwickler überzeugen, auf ihre Architektur einzugehen, dann könnte die Spieleleistung auf mittlere bis lange Sicht einen größeren Sprung machen. Spannend ist das nach wie vor gute Abschneiden in Crysis 3

Quelle: http://www.pcgameshardware.de/Ryzen-7-1800X-CPU-265804/Tests/Test-Review-1222033/

Ja und wie!

 

[Krautmaster]

ja so muss, Ich mein das Cluster is ja da

-> need in my Workstation!

 

[YforU]

davon ein halber auf AM4 wäre doch was gewesen. Mit Quadchannel und bis 8 DDR Slots. Und nicht erst 2019 sondern demnächst.

Auf einem gemeinsamen Sockel mit APUs welche effektiv über kaum mehr als 1/4 der I/O Kapazitäten verfügen (gegenüber 2* Zeppelin) ist das weder wirtschaftlich noch sinnvoll (Mainboard Design) umsetzbar.

16 Kerne / 32 Threads. Sollte bei ~3 Ghz easy machbar sein da der Prozess bis dahin sehr effizient rennt. Außerdem spart sich - was viele hier ja vergessen, AMD die GPU. Und die macht schon bei Kaby Lake ja schnell halbe DIE Size aus.

Als Vergleich eignet sich hier eher Broadwell-DE da ebenfalls ein SoC. Zeppelin ist für 8C/16T ohne GPU übrigens nicht gerade klein und der Transistor Count spricht auch für sich. Auf AM4 (als Ryzen, Summit Ridge) ist ziemlich viel deaktiviert. Neben PCIe Lanes, CPU/GPU Interconnects auch 10GbE.

 

[AMINDIA]

.....
16 Kerne / 32 Threads. Sollte bei ~3 Ghz easy machbar sein da der Prozess bis dahin sehr effizient rennt. Außerdem spart sich - was viele hier ja vergessen, AMD die GPU. Und die macht schon bei Kaby Lake ja schnell halbe DIE Size aus.

Wo ist in diesem Text der Zusammenhang zwischen einen 4C/8T Prozessor für den Desktop und einen 16C/32T Server Prozessor? Genau, keiner. Was bedeutet dann also dein Beitrag?
Was Krautmaster nicht sagt, viele aber wissen, auch der 16C/32T Xeon hat keine IGP.

Interessant wäre noch, wie sich der Turbo bei Kaby Lake auswirkt, wenn dessen IGP unter Vollast steht. Damit dieser komische Krautmaster Vergleich irgendwie eine Berechtigung findet.

 

[Sunjy Kamikaze]

Höflich formuliert so ernüchternd wie die unabhängigen Tests gezeigt haben gegenüber dem, ja nennen wir es mal "Lügen", was AMD vorher vollmundig versprochen hat.
Und auch hier wird, wenn man schon jetzt die Anzahl der Kerne und den RAM Ausbau streicht, auch "nur" ein herankommen an Intel übrig bleiben.

Wo is sie denn nur.. Die Mauer wenn man sie braucht

Find ich richtig gut was AMD hier so abliefert und freue mich jetzt schon auf die Zen+ Cores.


is das Teil hier wirklich Passive gekühlt? Das kann ich fast nich glauben

 

[pgene]

Auf jeden Fall ein spannendes Produkt, dennoch wird AMD es schwer haben. Viele setzten in der Branche lieber auf Bewertes, die meisten IT-Veranwortlichen gehen eher selten Risiken getrau dem Motto, "Was der Bauer nicht kennt das frisst er nicht".
Man will sich einfach nicht vorwerfen lassen das Software XY "vielleicht wegend er AMD CPU!?" nicht läuft oder immer mal wieder abrauscht, etc.