AMD Nieuwsdiscussietopic - Deel 38

[Verwijderd]

Astennu schreef op maandag 29 januari 2018 @ 08:44:
[...]


Ryzen heeft 2667 MHz memory support. Alles daar boven is OC. kortom als 2667 werkt is het geen defect.
Ik heb genoeg cpu's gezien die 3200MHz niet zo maar doen (weer andere halen 34xx of zelfs 36xxMHz). Een andere CPU er in en het werkt ineens wel. Type geheugen chips en moederbord maken ook verschil je kan met een ander bord zo een stapje verder komen. Voor de beste resultaten moet je Samsung B-Die geheugen hebben,

Ik verwacht dat dit met de Ryzen 2 serie weer een stuk beter gaat worden. Dit zie je al terug bij de APU's die 2933MHz support hebben. Dus de kans dat die 3200 gaan halen is weer een stuk groter.

Ik ben erg benieuwd naar de snelheid van deze Refreshes. 15% er bij moet mogelijk zijn gezien de tweaks en de hogere clock speeds.

En dan volgend jaar Zen2 (Ryzen 3xxx) daar ben ik nog veel meer in geïnteresseerd.

Dan hopen dat hynix, samsung, etc geen onderscheid meer maakt. Is nu ern beetje hopenloos

[The Chosen One]

Veel problemen zijn al gepatched al weet ik niet hoe zich dat verhoud tussen/met alle moederborden.
Van beide kanten zal dat nu wel veel beter zijn (lijkt me) met Ryzen 2xxx.


In de praktijk zit de problemen meer in de prijs.
Het idee is om een 32 GB setje te nemen met de upgrade. €460,- voor 1 die ik op het oog heb/had. €377 nog in september wat ik zo snel ff zie. Ik denk dat ik maar moet proberen om een DDR4 setje te lenen of huren van iemand.

Maar ja dat is algemeen bekend nu met ram en gpu's (al is die gelukkig voorzien).

[ Voor 7% gewijzigd door The Chosen One op 29-01-2018 13:23 ]

[dylan111111]

The Chosen One schreef op maandag 29 januari 2018 @ 13:22:
Het idee is om een 32 GB setje te nemen met de upgrade. €460,- voor 1 die ik op het oog heb/had. €377 nog in september wat ik zo snel ff zie. Ik denk dat ik maar moet proberen om een DDR4 setje te lenen of huren van iemand.

Wow, dat is pittig, zelf heb ik voor CMD64GX4M8A2400C14 (momenteel @2993mhzC14 1.35V) +-500,- nieuw betaald.

[Astennu]

DaniëlWW2 schreef op maandag 29 januari 2018 @ 11:26:
@Astennu misschien nog wel meer. We lijken tussen de 5 en 10% IPC te krijgen met Ryzen 2, daarnaast nog hogere clocks. Zeker omdat de volledige meltdown patch van W10 en microcode voor Intel toch een paar procent kost gaat het heel interessant worden waar Ryzen 2 uitkomt.

Uiteraard zullen een aantal sites de benchmarks volledig verpesten, maar zelfs dan is het nog interessant hoe de verhoudingen komen te liggen.

---

Verder laat de OEM's en de laptops toch lopen. Echt, geef ze een kans.
Alle OEM's zijn Epyc al ingedoken want geweldig, en ze zien zelf ook wel in dat Ryzen of Raven Ridge niet slecht is. Ze moeten die chips wel kunnen kopen en zelf verkopen en daar lijkt het probleem te zitten. Verder moeten ze het platform testen, moet AMD bewijzen dat het stabiel is, wat relaties opbouwen etc. Voor OEM's zal AMD onderhand meer een startup zijn die er al vijftig jaar is dan een bestaande partner. Natuurlijk hebben ze daar zelf een hand in gehad door het aannemen van die omkoping door Intel, maar dat is verder niet relevant meer. Het gaat om nu, niet tien jaar geleden.

Dit alles kost gewoon tijd. Je mag gaan klagen in de zomer als er nog steeds niks is.

Waar baseer je dat op dat het misschien 10% IPC is? ik heb het niet over Zen2 maar over Ryzen 2 welke gewoon Zen 1 is + een paar kleine tweaks. Ik heb alleen dingen gelezen over memory latency tweaks en dan hogere clocks.
Meer is natuurlijk altijd mooi maar ik verwacht niet te veel verschil qua IPC. Game performance zou hier en daar wel meer kunnen stijgen door dat memory latency daar een grote bottelnek is.
Maar als ze 10-12% halen inc de clockspeeds vind ik het al heel wat. 10% hogere clocks =! 10% betere prestaties.

Ik ben benieuwd volgende maand.

[Astennu]

Verwijderd schreef op maandag 29 januari 2018 @ 13:06:
[...]


Dan hopen dat hynix, samsung, etc geen onderscheid meer maakt. Is nu ern beetje hopenloos

Dat maakt bij intel ook uit maar daar liggen de grenzen wat anders.
Ik verwacht wel dat ze het verschil kleiner kunnen maken

[DaniëlWW2]

Astennu schreef op maandag 29 januari 2018 @ 13:45:
[...]


Waar baseer je dat op dat het misschien 10% IPC is? ik heb het niet over Zen2 maar over Ryzen 2 welke gewoon Zen 1 is + een paar kleine tweaks. Ik heb alleen dingen gelezen over memory latency tweaks en dan hogere clocks.
Meer is natuurlijk altijd mooi maar ik verwacht niet te veel verschil qua IPC. Game performance zou hier en daar wel meer kunnen stijgen door dat memory latency daar een grote bottelnek is.
Maar als ze 10-12% halen inc de clockspeeds vind ik het al heel wat. 10% hogere clocks =! 10% betere prestaties.

Ik ben benieuwd volgende maand.

De "Ryzen 2600" leak vertaalt zich niet een op een qua clockspeeds. De scores wijzen op IPC gain. Verder is IPC geen statisch gegeven maar gebaseerd op instructiesets. Ik ga zelf eerder uit van gemiddeld 5% ish, maar er zat volgens mij ook wat bij dat meer aangaf.

[Verwijderd]

Jongens, kunnen wij alsjeblieft niet meedoen aan het verkrachten van de term IPC en spreken over iets als performance/MHz of iets dergelijks?
IPC betekent letterlijk wat de afkorting zegt, hoeveel instructies je kan uitvoeren met cyclus van de klokt. Dat op zichzelf zegt natuurlijk niets aangezien de ene instructie de andere niet is, liever 50 instructies met 2,2 keer zoveel resultaat dan 100 instructies met 1 keer zoveel resultaat.
Ja, ik weet dat AMD er ook aan mee deed tegen beter weten in.

Astennu schreef op maandag 29 januari 2018 @ 08:44:
En dan volgend jaar Zen2 (Ryzen 3xxx) daar ben ik nog veel meer in geïnteresseerd.

Jij en ik!
Hopelijk zijn tegen die tijd de RAM-prijzen weer enigszins richting normaal en is de 'mining'-zeepbel geknapt want qua CPU wordt dat waarschijnlijk het ideale moment om in te stappen. Veel kinderziektes zijn verdwenen, de tweede generatie van een nieuwe architectuur, een aanzienlijk kleinere node die geschikter is voor desktop-CPU's (niet getuned op RAM/SSD-gebruik). Het enige minpuntje is dat EUV nog niet gebruikt kan worden voor productie op die schaal en dat ze daarom met aanzienlijk meer lagen moeten werken, dat laat de nodige ruimte om bij Zen3 weer een grote sprong te maken.

Maar als ze 10-12% halen inc de clockspeeds vind ik het al heel wat. 10% hogere clocks =! 10% betere prestaties.

Toelichting?
Ik denk dat jij gelijk hebt dat het niet lineair schaalt (omdat 10% verschil in output van de CPU meer dan 10% verschil in output van de GPU kan opleveren) maar ik ben benieuwd naar jouw redenatie. Helaas hebben de reviewers de kans laten liggen om de gamingperformance voor Intel te vergelijken bij meerdere klokfrequenties tussen 4,0 en 5,3 GHz. , dat had hele interessante data opgeleverd die hun artikels/video's vlak voordat Ryzen2 er komt en de reviews van Ryzen2 sterk zouden kunnen verbeteren. Voor mij ligt het heel erg voor de hand om dat te testen. Zeker op het moment dat je opmerkt - dat moeten zij toch hebben opgemerkt - dat 25% in klokfrequentie gemiddeld resulteert in 10% extra FPS of zo. Dan weet je dat je niet die 5,0 GHz of zo nodig hebt en zou je moeten uitzoeken waar wel de grens ligt.

DaniëlWW2 schreef op maandag 29 januari 2018 @ 11:26:
Uiteraard zullen een aantal sites de benchmarks volledig verpesten

Neem daar maar vergif op in aangezien het patchen van van alles (microcode en BIOS in ieder geval, besturingssysteem afhankelijk van...) opt-in is.

Verwijderd schreef op maandag 29 januari 2018 @ 13:06:
[...]


Dan hopen dat hynix, samsung, etc geen onderscheid meer maakt. Is nu ern beetje hopenloos

Dat zal verschil blijven maken zolang Samsung beter geheugen maakt. Dat is bij Intel niet anders, alleen is bij Intel momenteel de compatibiliteit beter waardoor de bodem hoger ligt en je het verschil niet merkt als normale gebruiker wanneer je bijvoorbeeld 3200 MT/s RAM koopt en het op die klokfrequentie instelt met default timings. Meer tijd gehad om de microcode en de UEFI's te tunen en meer tijd gehad om latjes te testen? Mogelijk een betere geheugencontroller? Moeilijk te zeggen.

[ Voor 16% gewijzigd door Verwijderd op 29-01-2018 14:46 ]

[Dennism]

Verwijderd schreef op maandag 29 januari 2018 @ 14:38:

Neem daar maar vergif op in aangezien het patchen van van alles (microcode en BIOS in ieder geval, besturingssysteem afhankelijk van...) opt-in is.

Windows 7, 8.1 en 10 zijn in ieder geval Opt-Out, Linux voor zover ik weet ook, al kan dat mogelijk van distributie afhangen. Red Hat is indergeval Opt-out volgens hun eigen support documenten.

Onder Windows zal de Microcode in ieder geval voorlopig Opt-In blijven, onder linux voorzie ik wel distributies die ook daar voor Opt-Out zullen gaan, Red Hat deed dit in het verleden wel altijd, maar ik kan me goed voorstellen dat ze hier eerst een periode Opt-In gaan tot dat echt zeker is dat alles stabiel is. VMware zal ook voor Opt-Out gaan voor zover bekend (was bij de teruggetrokken patch ook al zo).

Ben wel benieuwd wat deze partijen met de AMD microcode gaan doen zodra deze beschikbaar komt, ik heb deze ook nog niet gezien.

[Verwijderd]

Dennism schreef op maandag 29 januari 2018 @ 16:04:
[...]


Windows 7, 8.1 en 10 zijn in ieder geval Opt-Out, Linux voor zover ik weet ook, al kan dat mogelijk van distributie afhangen. Red Hat is indergeval Opt-out volgens hun eigen support documenten.

Bij Windows 7 kies je zelf of dat je updates installeert. Erger dan dat, InSpectre geeft aan dat deze versie van Windows (Windows 7 Home Premium) geen benul heeft van het Meltdown- en Spetre probleem. Ik zal de letterlijke tekst citeren.

This 64-bit version of Windows is not aware of either the Spectre or Meltdown problems…

This system’s hardware has not been updated with new features required to allow its operating system to protect against the Spectre vulnerabilities and/or to minimze their impact upon the system’s performance.

Ik heb gisteren de laatste potentieel relevante updates geïnstalleerd (alle, niet enkel de "belangrijke"), ik had al alle aanbevolen updates geïnstalleerd. Momenteel staan er weer 6 in de rij, ik installeer die nu, ik verwacht niet dat het verschil maakt.
Het enige wat ik kan bedenken dat er fout gaat is dat ik Windows 7 SP1 heb in plaats van Windows 7 SP2 maar dat mag geen verschil maken, als dat zo is dan gaat er iets verkeerd bij MS.
Hoe dan ook, het punt was dat je niet automatisch beschermd bent tegen Meltdown en Spectre voor zo ver MS en Intel (de i5-750 komt allicht niet aan de beurt voordat hackers erachter zijn gekomen hoe ze die kwetsbaarheden benutten, als Intel die al ooit gaat patchen waar ik mijn twijfels over heb) dat al doen. Wat je leest is 1 ding, ik kan in de praktijk uitproberen hoe het werkt voor Windows 7. Als latere updates het systeem wel beveiligen dan zal ik het laten weten maar vooralsnog hebben de updates niets gedaan om mijn systeem met Windows 7 Home Premium te beveiligen tegen Meltdown.

Ik ga nu maar eens de laatste 6 updates die beschikbaar zijn gekomen (na de updates van gisteren) installeren, zien wat het resultaat is. Ik verwacht dat het geen verschil maakt maar als het onverwacht wel verschil maakt dan zal ik deze reactie wijzigen.

edit
Inmiddels alle updates bijgewerkt (niets meer in de lijst). Ik kwam erachter dat een registersleutel ontbreekt die MS eist in verband met anti-virussoftware terwijl ik geen anti-virus software had of heb geïnstalleerd bij deze installatie anders dan Defender en Malwarebytes. Registersleutel toegevoegd maar nog geen update.

[ Voor 15% gewijzigd door Verwijderd op 29-01-2018 17:19 ]

[dcm360]

Dennism schreef op maandag 29 januari 2018 @ 16:04:
[...]


Windows 7, 8.1 en 10 zijn in ieder geval Opt-Out, Linux voor zover ik weet ook, al kan dat mogelijk van distributie afhangen. Red Hat is indergeval Opt-out volgens hun eigen support documenten.

Onder Linux hangt het denk ik met name af van hoe het beleid ten opzichte van closed-source binaries is. Distributies met een minder strict beleid zullen waarschijnlijk opt-out hebben, en degenen met een stricter beleid variaties van opt-in, losse repo of handmatig installeren.

[Verwijderd]

dcm360 schreef op maandag 29 januari 2018 @ 16:37:
[...]

Onder Linux hangt het denk ik met name af van hoe het beleid ten opzichte van closed-source binaries is. Distributies met een minder strict beleid zullen waarschijnlijk opt-out hebben, en degenen met een stricter beleid variaties van opt-in, losse repo of handmatig installeren.

Dat is een can of offtopic worms die erom smeekt om geopend te worden. Iets met dat je idealistische principes ook te ver door kan voeren, hoewel ik Stallman zijn gedrevenheid waardeer. Als iedereen zulke idealen zou hebben dan zouden we in een heel andere wereld leven.

Ontopic, het punt was dat je niet zomaar automatisch een tegen Meltdown beschermde Windows hebt en dat dit straks relevant wordt voor de vergelijkingen tussen Intel en Ryzen2. Welke reviewer heeft wel al deze patches en updates en welke niet? Ik voorspel alvast dat de meeste reviewers er niet eens iets over melden, ik hoop dat ik ongelijk krijg.

[ Voor 27% gewijzigd door Verwijderd op 29-01-2018 17:31 ]

[Dennism]

Verwijderd schreef op maandag 29 januari 2018 @ 17:28:
[...]

Dat is een can of offtopic worms die erom smeekt om geopend te worden. Iets met dat je idealistische principes ook te ver door kan voeren, hoewel ik Stallman zijn gedrevenheid waardeer. Als iedereen zulke idealen zou hebben dan zouden we in een heel andere wereld leven.

Ontopic, het punt was dat je niet zomaar automatisch een tegen Meltdown beschermde Windows hebt en dat dit straks relevant wordt voor de vergelijkingen tussen Intel en Ryzen2. Welke reviewer heeft wel al deze patches en updates en welke niet? Ik voorspel alvast dat de meeste reviewers er niet eens iets over melden, ik hoop dat ik ongelijk krijg.

Ik verwacht dat het grotendeels tegen die tijd wel "opgelost" zal zijn, ieder OS zal gepatched zijn, en tegen die tijd zullen moederborden verwacht ik gewoon af fabriek standaard komen met de AMD en Intel Microcode verwerkt in de Uefi zodat je enkel via een eventuele Opt-Out het uit zal zetten (in ieder geval op Windows, linux mogelijk afhankelijk per distro, maar dat zie je sowieso al niet al te vaak in reviews). En als reviewers al niet naar MCE instellingen kijken, verwacht ik zeker niet dat ze naar zulke zaken zullen kijken om dit actief uit te zetten

dcm360 schreef op maandag 29 januari 2018 @ 16:37:
[...]

Onder Linux hangt het denk ik met name af van hoe het beleid ten opzichte van closed-source binaries is. Distributies met een minder strict beleid zullen waarschijnlijk opt-out hebben, en degenen met een stricter beleid variaties van opt-in, losse repo of handmatig installeren.

Ik zou eigenlijk juist verwachten dat juist de distributies met een minder strict beleid voor Opt-In gaan, Red Hat als toch een vrij conservatieve variant is gewoon Opt-Out, als in alle fixes staan aan (voor variant 2 uiteraard nog wel Microcode nodig, deze zal Red Hat in ieder geval initieel niet meeleveren in de distributies). Zie bijv. https://access.redhat.com/articles/3311301

Architectural Defaults
By default, each of the 3 tunables that apply to an architecture will be enabled automatically at boot time, based upon the architecture detected.

Intel Defaults:

pti 1 ibrs 1 ibpb 1 -> fix variant#1 #2 #3
pti 1 ibrs 0 ibpb 0 -> fix variant#1 #3 (for older Intel systems with no microcode update available)

AMD Defaults:
Due to the differences in underlying hardware implementation, AMD X86 systems are not vulnerable to variant #3. The correct default values will be set on AMD hardware based on dynamic checks during the boot sequence.

pti 0 ibrs 0 ibpb 2 -> fix variant #1 #2 if the microcode update is applied
pti 0 ibrs 2 ibpb 1 -> fix variant #1 #2 on older processors that can disable indirect branch prediction without microcode updates

[ Voor 37% gewijzigd door Dennism op 29-01-2018 19:24 ]

[DaniëlWW2]

Iets anders en echt op AMD en techniek gericht. AMD heeft stilletjes een nieuwe versie van hun geoptimaliseerde compiler uitgebracht voor Zen. De oorspronkelijke deed maar weinig, kijken of dat nu wat meer gaat zijn. Dit is uiteindelijk ook een stukje van de puzzel voor AMD tegenover de industriestandaard Intel waar alle compilers van de afgelopen jaren omheen gebouwd zullen zijn.

https://www.phoronix.com/...&px=AMD-AOCC-1.1-Released
https://www.phoronix.com/...item=amd-ryzen-aocc&num=1

Nu wachten we op benches.

[Dennism]

DaniëlWW2 schreef op maandag 29 januari 2018 @ 21:44:
Iets anders en echt op AMD en techniek gericht. AMD heeft stilletjes een nieuwe versie van hun geoptimaliseerde compiler uitgebracht voor Zen. De oorspronkelijke deed maar weinig, kijken of dat nu wat meer gaat zijn. Dit is uiteindelijk ook een stukje van de puzzel voor AMD tegenover de industriestandaard Intel waar alle compilers van de afgelopen jaren omheen gebouwd zullen zijn.

https://www.phoronix.com/...&px=AMD-AOCC-1.1-Released
https://www.phoronix.com/...item=amd-ryzen-aocc&num=1

Nu wachten we op benches.

Ben wel benieuwd of we straks ook verschillende binaries krijgen dan bij closed source (windows) software. Anders verwacht ik niet dat dit in alle markten impact zal gaan hebben helaas.

[dcm360]

Dennism schreef op maandag 29 januari 2018 @ 18:48:
[...]
Ik zou eigenlijk juist verwachten dat juist de distributies met een minder strict beleid voor Opt-In gaan, Red Hat als toch een vrij conservatieve variant is gewoon Opt-Out, als in alle fixes staan aan (voor variant 2 uiteraard nog wel Microcode nodig, deze zal Red Hat in ieder geval initieel niet meeleveren in de distributies). Zie bijv. https://access.redhat.com/articles/3311301

Ik denk dat we wel hetzelfde zeggen, je gebruikt alleen niet dezelfde schaal als dat ik doe. Het wel of niet meeleveren van closed source binaries (wat ik gebruikte als schaal) is niet hetzelfde als het updatebeleid (waar jij op lijkt te duiden). Op mijn schaal verwacht* ik Red Hat als toch wat meer commerciële dan als ideologische partij ook in in het opt-out-kamp of anders op zijn minst met een eenvoudige opt-in, en blijkbaar is het het eerste.
*Eigenlijk ben ik niet zo bekend met het Linux-ecosysteem aan de Red Hat-kant. Ik neig zelf nogal naar (Open)Suse en voor de rest kom ik enkel Debian en afgeleiden daarvan tegen

[DaniëlWW2]

Dennism schreef op maandag 29 januari 2018 @ 22:04:
[...]


Ben wel benieuwd of we straks ook verschillende binaries krijgen dan bij closed source (windows) software. Anders verwacht ik niet dat dit in alle markten impact zal gaan hebben helaas.

Voor mij persoonlijk ben ik alleen maar geïnteresseerd in implementatie in game engines.
Het valt behoorlijk op dat pre 2015 games regelmatig onverklaarbare verschillen laten zien tussen Intel en Ryzen. Dan wordt gezegd dat Ryzen slecht is voor gaming, en einde verhaal. Dat is natuurlijk onzin omdat een CPU uiteindelijk niks meer is dan een veredelde rekenmachine. Ga je daar code op draaien die minder efficiënt is dan zal die CPU minder uit kunnen rekenen in een bepaald tijdsframe.

2015/2016 games zijn een beetje mixed en 2017 titels laten nauwelijks nog verschillen zien buiten de magische "7% IPC" bij gelijke clockspeeds. Zijn er ook nog games die beter draaien op een R5 dan een i5 quadcore puur vanwege multithreading. Dan is er nog CiV 6 die als AMD optimised gewoon beter draait. Ik vraag me vooral af waar Ryzen echt toe in staat is met optimalisaties. Ik vermoed dat er meer inzit dan we nu hebben gezien omdat het platform zo jong is. In dat opzicht gaat Ryzen 2 ook interessant worden als het gaat om benchmarks. Als het goed is dan zal Ryzen ook opnieuw getest worden, en ik vraag me af of er merkbare verschillen zijn.

Dan voor zaken zoals AutoCAD is het echt nodig dat er een AMD compiler komt. Daar lijkt Ryzen een gat van 20%+ te hebben en dat is gewoon optimalisatie problematiek. Het probleem is dat het AutoCAD is, en die hebben volgens mij niet de reputatie vooruitstrevend te zijn met ontwikkelingen in computertechniek.

[Dennism]

@DaniëlWW2

Ik vraag me eigenlijk af hoe dat gaat, want voor zover ik het altijd begrepen heb (ben zeker geen programmeur) kun je optimaliseren in de geschreven code en door bepaalde optimaliseerde compilers te gebruiken (bijv. de Intel compiler wanneer je optimaliseert voor Intel). Ik meende echter altijd dat je maar 1 compiler kan gebruiken voor een bepaald stuk software, tenzij je meerdere versie's van de binaries wil hebben, dan kan je uiteraard meedere malen compileren.

Ik zie echter nog niet direct games (of software als Autocad) ineens uitkomen met Game_A_AMD.exe en Game_A_Intel.exe of Autocad_AMD.exe en Autocad_Intel.exe en meer van dit bij closed source windows software.

Ik kan me echter wel voorstellen dat als jij je eigen linux distro met applicaties bij elkaar compileert en je hebt een Ryzen systeem dat je dan alles gaat compileren met de AMD compiler als deze optimaal blijkt te zijn.

[DaniëlWW2]

@Dennism ik weet het dus ook niet, maar ik vermoed dat je het vanaf het niveau van de game engine zou kunnen splitsen. Die zou in staat moeten zijn om de CPU te herkennen en dan naar de correcte compiler te gaan. Voordat je bij de API komt splitsen er wel meer dingen af. Zo lijkt AMD Primitive Shaders zo als als een apart renderpath te willen gaan activeren. Pin me er alleen niet op.

AMD lijkt in ieder geval meer in te zetten op een fork van bestaande compilers met Zen optimalisaties. Wederom wachten op de benches. 1.0 bracht hooguit enkele procenten, misschien doet 1.1 wat meer.

Natuurlijk is de beste oplossing dat je voor een applicatie met algemene compiler hebt en op microcode optimaliseert. Dat lijkt alleen niet te gebeuren als je bepaalde games of applicaties ziet. Sinds de totale dominantie van Intel vanaf 2011, en de constante iteratie van ringbus zal elke compiler onderhand zijn geoptimaliseerd voor Intel ringbus. Er is geen alternatief. Ik vermoed ook dat dit mede verklaard waarom Skylake-X zo "zwak" presteert.

Ik vertik het verder om te geloven dat het probleem bij de CPU zelf ligt. Daarvoor zijn de variaties veel te groot tussen applicaties, afgezet tegen Intel CPU's en eigenlijk onverklaarbaar. Voor zover ik weet word een relatief nieuwe instructieset zoals AVX2, of überhaupt iets anders dan 128bit instructie ook niet veel gebruikt. AVX2 zou een verschil kunnen verklaren omdat de FPU's van Zen beduidend minder efficiënt zijn met 256bit instructies. Het probleem is dat AVX2 pas bij Haswell kwam, en de tijdspanne dan niet klopt omdat er tijd zit tussen AVX2 introductie op hardware en gebruik door software.

---

Dan duikt Adobe lekker even op dat ze lightroom eens multithreaded maken.
nieuws: Adobe claimt prestatiewinst van 30 tot 65 procent bij Lightroom-update

Dus ook eentje voor de benchmarks om eens te kijken wat Zen nu doet.

[ Voor 9% gewijzigd door DaniëlWW2 op 30-01-2018 14:59 ]

[Sp3ci3s8472]

Dennism schreef op dinsdag 30 januari 2018 @ 14:29:
@DaniëlWW2

Ik vraag me eigenlijk af hoe dat gaat, want voor zover ik het altijd begrepen heb (ben zeker geen programmeur) kun je optimaliseren in de geschreven code en door bepaalde optimaliseerde compilers te gebruiken (bijv. de Intel compiler wanneer je optimaliseert voor Intel). Ik meende echter altijd dat je maar 1 compiler kan gebruiken voor een bepaald stuk software, tenzij je meerdere versie's van de binaries wil hebben, dan kan je uiteraard meedere malen compileren.

Ik zie echter nog niet direct games (of software als Autocad) ineens uitkomen met Game_A_AMD.exe en Game_A_Intel.exe of Autocad_AMD.exe en Autocad_Intel.exe en meer van dit bij closed source windows software.

Ik kan me echter wel voorstellen dat als jij je eigen linux distro met applicaties bij elkaar compileert en je hebt een Ryzen systeem dat je dan alles gaat compileren met de AMD compiler als deze optimaal blijkt te zijn.

Dat klopt, je zal dus waarschijnlijk per architectuur een andere library moeten compileren. Althans, ik denk dat dit zo zal gaan.
Wat ook kan is een compiler gebruiken die kijkt naar de architectuur van de cpu en op basis daarvan een slag optimalisaties uitvoerd. Dan gebruik je dus geen Intel of AMD compiler maar GCC of Clang. Ik ben een verwende c# programmeur in mijn hobby tijd dus ik weet bar weinig van het compilen zelf af.
Als Intel of AMD zelf optimalisaties aan die twee projecten toevoegd dan zou dat dus ideaal zijn.

[DaniëlWW2]

Sp3ci3s8472 schreef op dinsdag 30 januari 2018 @ 15:17:
[...]


Dat klopt, je zal dus waarschijnlijk per architectuur een andere library moeten compileren. Althans, ik denk dat dit zo zal gaan.
Wat ook kan is een compiler gebruiken die kijkt naar de architectuur van de cpu en op basis daarvan een slag optimalisaties uitvoerd. Dan gebruik je dus geen Intel of AMD compiler maar GCC of Clang. Ik ben een verwende c# programmeur in mijn hobby tijd dus ik weet bar weinig van het compilen zelf af.
Als Intel of AMD zelf optimalisaties aan die twee projecten toevoegd dan zou dat dus ideaal zijn.

AMD AOCC is dus gebaseerd op LLVM en Clang. Ze optimaliseren bestaande compilers dus voor Zen.
https://www.phoronix.com/...&px=AMD-AOCC-1.1-Released

---

Iets anders. Ik bedacht me net opeens dat AMD vandaag met de Q4 resultaten zou moeten komen.

[ Voor 5% gewijzigd door DaniëlWW2 op 30-01-2018 16:00 ]

[winwiz]

[ Voor 50% gewijzigd door winwiz op 30-01-2018 23:27 ]

[Dennism]

Wel lekker als hij daar gelijk heeft, je zal maar exclusive boardpartner zijn......

Vanuit AMD snap ik het wel, maar als consument of (gaming kaart) boardpartner zou ik er niet vrolijk van worden..... Misschien dat die Radeon Rebellion toch nog komt, maar dan op een andere manier dan verwacht

[ Voor 19% gewijzigd door Dennism op 31-01-2018 00:18 ]

[Psyonara]

Neem het ze niet kwalijk maar het is wel zonde. Hopelijk over tijd dat het wel toegankelijker wordt en naja anders zou ik zeggen dat ze hier nu mooi de tijd voor nemen en misschien Next Gen dat ze daar back on track zijn.

Misschien ook beter competitive vs Nvidia.
Ben allang blij dat ze ook weer groeien op CPU gebied, denk wel AMD hun moeilijkte tijd achter hun hebben. ( naja hoop het )

[madmaxnl]

Als AMD ze zelf verkoopt vangen ze er blijkbaar aanzienlijk meer op. Zoals de directe verkoop van videokaarten aan kut mining bedrijven. En natuurlijk de verkoop van hun Instinct videokaarten. Dit ligt in lijn met de geruchten dat de eerste AMD videokaarten op 7nm, Instinct videokaart zullen zijn.

[Verwijderd]

winwiz schreef op dinsdag 30 januari 2018 @ 23:26:
[video]

Ik had het gisterochtend bekeken, ik heb er geen melding van gemaakt omdat hij niet met iets nieuws komt. Hij stelt vast dat er in Australië nagenoeg geen RX-kaarten worden verkocht (d'uh) en dat er wel 'professionele' kaarten worden verkocht, dat wisten we al. Hij speculeert dat AMD zoveel mogelijk GPU's laat maken en zo'n groot mogelijk deel hiervan verkoopt voor professionele kaarten. Zijn aanname dat AMD zoveel mogelijk GPU's laat maken trek ik in twijfel. Ik denk dat AMD met opzet lang niet zoveel GPU's laat maken als wat mogelijk zou zijn omdat ze problemen willen voorkomen wanneer de mining zeepbel knapt. Ryan Smith merkte dit laatst ook op op Twitter. Nu de voorraad beperken maar voor een flink hogere marge verkopen levert momenteel net zo veel geld op maar als straks de mining zeepbel knapt dan wordt de tweedehandsmarkt minder overspoeld door tweedehands kaarten, aldus de theorie.

[ Voor 12% gewijzigd door Verwijderd op 31-01-2018 07:32 ]

[Dennism]

Verwijderd schreef op woensdag 31 januari 2018 @ 07:29:
[...]

Ik had het gisterochtend bekeken, ik heb er geen melding van gemaakt omdat hij niet met iets nieuws komt. Hij stelt vast dat er in Australië nagenoeg geen RX-kaarten worden verkocht (d'uh) en dat er wel 'professionele' kaarten worden verkocht, dat wisten we al. Hij speculeert dat AMD zoveel mogelijk GPU's laat maken en zo'n groot mogelijk deel hiervan verkoopt voor professionele kaarten. Zijn aanname dat AMD zoveel mogelijk GPU's laat maken trek ik in twijfel. Ik denk dat AMD met opzet lang niet zoveel GPU's laat maken als wat mogelijk zou zijn omdat ze problemen willen voorkomen wanneer de mining zeepbel knapt. Ryan Smith merkte dit laatst ook op op Twitter. Nu de voorraad beperken maar voor een flink hogere marge verkopen levert momenteel net zo veel geld op maar als straks de mining zeepbel knapt dan wordt de tweedehandsmarkt minder overspoeld door tweedehands kaarten, aldus de theorie.

Vraag is alleen, hoelang kan er nog gesproken worden van een mining bubble, dit begint aardig op een permanente situatie te lijken tenzij overheden naast China echt gaan doorzetten en mining, het bezit en de handel in Crypto juridisch echt aan banden gaan leggen omdat regulatie goed niet mogelijk is (wat natuurlijk veelal weer het doel van Crypto coins is).

[Verwijderd]

Dennism schreef op woensdag 31 januari 2018 @ 07:59:
[...]


Vraag is alleen, hoelang kan er nog gesproken worden van een mining bubble

Ja, dat vraag ik me nu al een paar maanden af. Het begint steeds meer op de beursen te lijken. Daar slagen ze erin om de zeepbel enkele decennia op te blazen alvorens die echt knapt (voor die tijd wat dipjes maar dat is in die analogie eerder wat lucht wat eruit loopt dan knappen), knappen zal het en het gaat niet leuk zijn wanneer dat gebeurt, erger dan na 2008.
Aan de andere kant is er een markt voor wat die 'mining'kaarten doen maar de vraag is welk deel van de groei wordt veroorzaakt door die markt en welk deel van de groei wordt veroorzaakt door de zeepbel en de parasieten die speculeren (grafische kaarten opkopen om ze duurder te verkopen).

Momenteel is natuurlijk niet het grootste deel van het probleem dat individuën thuis minen, het grootste deel van het probleem zijn die miningfarms in China, Ijsland, de USA, Canada...
Daarnaast wat factoren die het mogelijk nog wat erger maken maar niet meer dan dat; kerstaankopen, de groei van de chinese consumentenmarkt en internetcafés, de hoge RAM-prijzen (smartphones, mogelijk ook kartelvorming)...
Ik verwacht eveneens niet al te veel heil van regulatie in dit geval, in het algemeen ben ik een voorstander van regulering maar ik vrees dat het voor 'mining' weinig verschil maakt aangezien die mensen elders verder gaan als het nodig is. Tenzij genoeg landen tegelijkertijd komen met dergelijke regulering.

Hoe dan ook, ik denk dat AMD nog steeds de kat uit de bomen kijkt want wanneer weet je dat dit nog jarenlang aanhoudt? Zelfs als het jarenlang aanhoudt zijn de gamers de pineut want zo snel kan je de productie niet voldoende verhogen.
Ik hoop dat ze die kaarten braaf recyclen voor de koper en andere grondstoffen.

[ Voor 19% gewijzigd door Verwijderd op 31-01-2018 08:21 ]

[foppe-jan]

Kerstaankopen en mogelijk een verwachting bij AIB vendors dat Nvidia binnen niet al te lange tijd met een nieuwe generatie komt, waardoor ze niet al te veel willen inkopen. (En volgens Steve van GN zijn gddr5-prijzen naar AIBs toe met 20-30$ gestegen, itt normaliter circa 5$ per kwartaal.)

Daarnaast bestaat de kans bij AMD dat MI25-verkopen onverwacht goed gaan (gegeven dat ze nog steeds in de ontwikkelfase zitten van hun software stack -- zie earnings call transcript), en dat dit consequenties heeft voor RX-toelevering.

[ Voor 29% gewijzigd door foppe-jan op 31-01-2018 10:04 ]

[DaniëlWW2]

Maar earnings call Q4 2017. Weer winst, dat is ook een fijn voor AMD.

Er speelt alleen meer mee bij deze getallen. SoC viel wat tegen in Q4. Ik vermoed dat console orders wat weg zijn gezakt, andere SoC chips ook wat. Epyc misschien ook wat omdat veel servers besteld zullen zijn. Q1/Q2 2018 kan daar weer anders zijn als de eerste resultaten van Meltdown duidelijk worden in bestellingen.

---

De groei in Computing and Graphics is wel opvallend te noemen. Eerst even heel bot. AMD verdient helemaal niet extra per unit sold aan de miners. AMD ontvangt bestellingen voor GPU's van de AIB's, levert deze voor afgesproken prijzen en dat is het. Dat zijn kwartaalafspraken over prijzen en volumes. Het zijn de AIB's die de kaarten direct verkopen aan miners, en de winsten opstrijken. Een klein deel blijft over en gaat de detailhandel in waar de prijzen enorm worden opgeblazen door importeurs/groothandel.

Dat is wat er gebeurd met Polaris 10. Vega 10 is een totaal ander beestje. We horen nu al maanden over tekorten aan chips. Daar is een heel goede reden voor. Ten eerste is Steve/HardwareUnboxed zijn video dus niet accuraat. Die chips gaan naar Apple en de Instinct MI25 lijn, dan Radeon Pro wat overblijft gaat naar Vega FE. De AIB's krijgen (vrijwel) niks.

Technerdgasm legde het beter uit in de comments dan ik daar deed. Kennelijk verkoopt Apple ongeveer 300K iMac Pro's per kwartaal. Dat zijn dus 300K Vega 10 chips. Ga je "quick en dirty" naar een wafer calculator en een 484mm die, dan kom je op ongeveer 110 chips per wafer uit. Yields zullen slecht zijn. Een redelijk positieve schatting van 70% yields (ik denk dat het wel eens een stuk slechter kan zijn) komt dan neer op bijna 1300 wafers per maand voor alleen Apple. Dan moet er nog HBM2 en interposers komen. Dat is enorm voor RTG begrippen voor zo'n grote chip. Zomaar een productie-uitbreiding voor Vega 10 zie ik dan ook niet gebeuren.

Wat niet naar Apple gaat, gaat naar klanten zoals Baidu want die bestellen MI25's. Dan zijn er nog Radeon Pro verkopen, en wat er over blijft gaat naar Vega FE. In plaats van misschien $200 te verdienen met de verkoop van een Vega chip aan een AIB, en er zelf verlies op te maken, verkoopt AMD die chips gewoon aan miners voor $1500 met een kaart eromheen gebouwd. Verdient AMD er ook nog goed aan. Dat is waarom er geen RX Vega's zijn.

Qua winsten betekent dit dat AMD alleen flink zal verdienen aan de verkoop aan Baidu, Radeon Pro en miners. Baidu deden ze al in Q3, dus dat zal niet veel veranderd zijn. Aan Apple zullen ze niet veel verdienen. Dat maakt niet echt uit omdat AMD een enorme hoeveelheid wafers afneemt voor het Apple contract. Dat betekent dat ze makkelijker voldoen aan de contracten met GoFlo. Verder verkopen ze hun chips eens. Kennelijk kochten mensen de Polaris 10 chips ook niet voordat de miners begonnen, dus voor AMD is het geweldig dat iemand hun chips een koopt...

---

Dan is er nog een bericht van Lis Su:
https://twitter.com/markhachman/status/958472203703496704

Ze lopen dus nog steeds niet aan tegen productielimieten bij GoFlo. Het probleem lijkt eerdere GDDR5 en HBM2 te zijn. HBM2 voor Vega, GDDR5 voor Polaris 10. Verder geeft ze hier aan dat het probleem niet bij AMD ligt. AIB's bestel maar extra chips hoor, wij kunnen zo leveren. Dat gaan die AIB's niet snel doen omdat zei het risico lopen als ze besteld hebben. Verwacht dus ook geen magische oplossing voor de miners, los van een instorting. Die is ook onwaarschijnlijk aan het worden omdat er te veel cryptocoins zijn. Dit lijkt een permanent verschijnsel te gaan worden. Is dat zo, en hebben de AIB's dit door, dan gaan ze meer chips bestellen. Polaris 10 chips, want die Vega's, die krijgen ze niet.

---

Maar de echte klapper hier is denk ik Zen. Ik denk dat het grootste deel van de omzetgroei uit Zen is gekomen. Natuurlijk zijn het nog steeds geen Intel aantallen, maar adoptie van Ryzen door gamers, of TR voor workstations zit denk ik wel goed. Het zijn natuurlijk niet de bedragen per unit die een Vega FE, laat staan een Instict MI25 oplevert, maar het zal een gestage bron van inkomsten zijn. Nu is het een kwestie van inventaris opschonen voor Ryzen 2, vandaar de prijsdalingen. Ondertussen bouwt AMD denk ik ook weer flink voorraad op, voor Ryzen 2 en Raven Ridge. Ik denk dat de winst daarom "maar" $85 miljoen was.

[Enchantress]

Het is in ieder geval winst en geen verlies.

Wat ik me afvraag, is als de AIB’s geen chips bestellen ivm de mining hype, waarom verkoopt AMD dan niet zelf de kaarten? (Eventueel met een goede koeler dan heb je in mijn ogen meer winst.)

[DaniëlWW2]

Enchantress schreef op woensdag 31 januari 2018 @ 13:16:
Het is in ieder geval winst en geen verlies.

Wat ik me afvraag, is als de AIB’s geen chips bestellen ivm de mining hype, waarom verkoopt AMD dan niet zelf de kaarten? (Eventueel met een goede koeler dan heb je in mijn ogen meer winst.)

Omdat je niet bepaald een productielijn op kan zetten en die chips kan produceren in een week. Als het kon, dan had AMD het natuurlijk allang gedaan. Ze hadden gewoon de reference RX470/480 gepakt, chip zelf underclocked en verkochten ze voor MSRP direct aan miners. AMD blij, miners blij, gamers blij.

Helaas is het zo dat van wafer naar functionele chip maanden duurt. Voor CPU's hoef je alleen maar de chip op een substraat te zetten, IHS, leuk doosje en in het geval van AMD een niet waardeloze stock koeler erbij en verkopen. Dat duurt al drie maanden van wafer naar product. Een GPU is heel wat complexer.

Verder heb je AMD hun financiële situatie wel eens gezien?
Ze kunnen niet opeens bergen aan GPU's gaan maken en deze vervolgens niet verkopen. Zeker omdat GDDR5 snel duurder is geworden is het een risico. Stel dat het AMD nu $180 kost om een reverence RX480/580 8GB te maken. We weten eigenlijk al dat er 100.000 Vega 10 chips naar alleen Apple gaan. Stel die miners willen bij elkaar zo'n 200.000 chips per maand. Nou dat kost dus $36 miljoen per maand voor alleen de productiekosten in dit speculatieve voorbeeld. Je plant per kwartaal, en toen stortte de vraag in. En kwartaalverlies want je hebt bestellingen voor een paar maanden uitstaan op het moment van een crash...

Dat is het dilemma voor AMD. De financiële positie van AMD is zo zwak dat ze een risico van enkele miljoenen niet kunnen nemen. Nvidia kan het doen, maar willen de AIB's ook? Als de hele crypto industrie gereguleerd was, dan zouden grote miners direct bij AMD aankloppen en AMD gewoon bestellingen aannemen. Aan de andere kant, als het gereguleerd was met de huidige koersen dan zou ik als AMD zijnde gewoon zelf gaan minen en de aanvoer van nieuwe kaarten keihard afknijpen.

---

Maar dit hoort eigenlijk allemaal in het GPU topic, niet CPU.

[ Voor 3% gewijzigd door DaniëlWW2 op 31-01-2018 13:59 ]

[Werelds]

DaniëlWW2 schreef op woensdag 31 januari 2018 @ 13:46:
[...]

Helaas is het zo dat van wafer naar functionele chip videokaart maanden duurt. Voor CPU's hoef je alleen maar de chip op een substraat te zetten, IHS, leuk doosje en in het geval van AMD een niet waardeloze stock koeler erbij en verkopen. Dat duurt al drie maanden van wafer naar product. Een GPU videokaart is heel wat complexer.

FTFY - grafische kaart mag ook

Wel de correcte termen gebruiken. Een CPU en GPU zijn beide chips. Verschil is dat een GPU pas bij ons (de consument) komt als deze op een PCB zit waarop deze is verbonden met display outputs, stroom voorziening, koeler, geheugen (met uitzondering van de HBM producten uiteraard).

GPU's kan AMD zo zonder meer verkopen hoor, los van fabricage kosten is dat zelfs goedkoper dan CPU's. Je hebt er dan alleen niet zo veel aan als eindgebruiker

offtopic:
En nee, het is verdorie ook geen "VGA kaart" zoals ik soms nog wel eens zie. Ik heb volgens mij godverdomme al 15 jaar geen VGA-gerelateerd product meer gebruikt. En daarvoor was het SVGA en XGA, die dan wel nog via D-Sub naar buiten kwamen. Want zo heet die stekker, niet VGA

[DaniëlWW2]

Werelds schreef op woensdag 31 januari 2018 @ 16:30:
[...]

FTFY - grafische kaart mag ook

Wel de correcte termen gebruiken. Een CPU en GPU zijn beide chips. Verschil is dat een GPU pas bij ons (de consument) komt als deze op een PCB zit waarop deze is verbonden met display outputs, stroom voorziening, koeler, geheugen (met uitzondering van de HBM producten uiteraard).

GPU's kan AMD zo zonder meer verkopen hoor, los van fabricage kosten is dat zelfs goedkoper dan CPU's. Je hebt er dan alleen niet zo veel aan als eindgebruiker

offtopic:
En nee, het is verdorie ook geen "VGA kaart" zoals ik soms nog wel eens zie. Ik heb volgens mij godverdomme al 15 jaar geen VGA-gerelateerd product meer gebruikt. En daarvoor was het SVGA en XGA, die dan wel nog via D-Sub naar buiten kwamen. Want zo heet die stekker, niet VGA

He, doe eens niet zeg. (had het druk en totaal geen behoefte aan gebruik van correcte terminologie )
Verder is het vanaf nu gewoon weer een VGA hoor.

[Help!!!!]

Hier nog een stukje over ram als limiting factor:

https://www.anandtech.com...ion-ram-a-limiting-factor

En earningscall editorial:

https://www.pcper.com/rev...nger-Expected-Q4-Earnings

[ Voor 30% gewijzigd door Help!!!! op 31-01-2018 18:36 ]

[Dennism]

Ben trouwens wel benieuwd waar dat 300k cijfer per kwartaal voor iMac Pro's vandaan komt, of zijn dat nog ramingen? Die machine is namelijk amper een week of 6 op de markt

En ook vraag ik me het nog steeds af of het wel zo handig je trouwe AIB (en dan zeker de AMD exclusieve) partners (en de consumenten) zo te behandelen. Stel dat je ze ooit nog weer nodig hebt..... Korte termijn is het allemaal zeer begrijpelijk vanuit AMD, maar lange termijn moet ik nog maar even zien...

[dcm360]

Wel raar dat AMD dan zelf aangeeft dat ze prima meer chips kunnen leveren? Misschien zijn de AIB's toch wat minder trouw, en kopen weinig in omdat ze moeite hebben om de chips te kunnen combineren met geheugen. Op dat punt ga je als AMD uiteraard wel grote volumes aan Apple leveren, als die er blijkbaar geen problemen mee heeft en dus wel chips wil afnemen.

[Verwijderd]

foppe-jan schreef op woensdag 31 januari 2018 @ 10:03:
Kerstaankopen en mogelijk een verwachting bij AIB vendors dat Nvidia binnen niet al te lange tijd met een nieuwe generatie komt, waardoor ze niet al te veel willen inkopen.

Dat beweerde Steve van GN inderdaad. Ik geloof er niets van (dat hun verwachtingen realistisch zijn, Steve zal dit vast wel zijn verteld), voor mei-augustus gaan wij niet Volta Ampère zien en ik zou zelfs niet verbaasd zijn als we die niet voor het einde van het jaar gaan zien. Waarom zou Nvidia? Pascal verkoopt hartstikke goed en met die 'mining'gekte kan je eerst nog achterover leunen en de 1,5 jaar ouder GPU's verkopen voor meer dan toen ze er net waren.

dcm360 schreef op woensdag 31 januari 2018 @ 21:02:
Wel raar dat AMD dan zelf aangeeft dat ze prima meer chips kunnen leveren?

Tenzij AMD bewust niet meer GPU's levert omdat ze niet nog een keer het slachtoffer willen worden van een crashende 'mining'mart en zo en netto geld verliezen en vaste gamingklanten verliezen. AMD heeft er alle belang bij juist bewust minder GPU's te leveren dan dat ze kunnen leveren totdat die 'mining'-storm gaat liggen. Het probleem is nu dat het jaren zou kunnen gaan duren voordat het zo ver is...

Er worden naar verluidt door AIB/AIC-partners hele ladingen kaarten direct aan miningfarms etc. verkocht en deze professionele 'miners' hebben zelfs een opdracht gegeven aan TSMC voor een gigantisch groot aantal kaarten. De vraag is welke bedrijven dit wel en niet doen maar het is zeker dat het gebeurt.

[ Voor 42% gewijzigd door Verwijderd op 31-01-2018 23:56 ]

[foppe-jan]

Verwijderd schreef op woensdag 31 januari 2018 @ 23:44:
[...]

Dat beweerde Steve van GN inderdaad. Ik geloof er niets van (dat hun verwachtingen realistisch zijn, Steve zal dit vast wel zijn verteld), voor mei-augustus gaan wij niet Volta Tesla zien en ik zou zelfs niet verbaasd zijn als we die niet voor het einde van het jaar gaan zien. Waarom zou Nvidia? Pascal verkoopt hartstikke goed en met die 'mining'gekte kan je eerst nog achterover leunen en de 1,5 jaar ouder GPU's verkopen voor meer dan toen ze er net waren.

Tja, maar wat nou als Nvidia's AIB partners niet (denken te) kunnen vertrouwen op wat ze van Nvidia horen mbt releasedates van nieuwe architecturen? Dat kan ze prima terughoudend maken om al te grote volumes in te kopen, waardoor het nu lijkt alsof 'zelfs' NV uitverkocht is (waarvan iedereen verwacht/weet dat die in veel groter volume geproduceerd worden), terwijl dat gewoon is omdat ze nog niet hebben kunnen reageren op de enorme vraagexplosie sinds december.

[Verwijderd]

foppe-jan schreef op woensdag 31 januari 2018 @ 23:51:
[...]

Tja, maar wat nou als Nvidia's AIB partners niet (denken te) kunnen vertrouwen op wat ze van Nvidia horen mbt nieuwe architecturen? Dat kan ze prima terughoudend maken om al te grote volumes in te kopen, waardoor het nu lijkt alsof 'zelfs' NV uitverkocht is (waarvan iedereen verwacht dat die in veel groter volume geproduceerd worden), terwijl dat gewoon is omdat ze nog niet hebben kunnen reageren op de enorme vraagexplosie sinds december.

Of de AIC-partners speculeren er lustig op los zoals wij dat doen en hun vermoeden is niet op meer gebaseerd dan dat er meestal <=1,5 jaar zit tussen twee generaties. We weten niet wat ze exact hebben verteld aan Steve, wij weten enkel hoe Steve het uitlegde, uitleg via-via klopt vaak niet meer 100% omdat veel mensen slecht zijn in het parafraseren zonder iets aan de inhoud te veranderen of niet 100% begrepen wat werd bedoeld. Hoe dan ook, ik geloof niet dat we de komende maanden al Ampère gaan zien, op zijn vroegst vanaf mei maar ik neig meer naar het einde van het jaar.

[foppe-jan]

Ampere.

[Verwijderd]

foppe-jan schreef op woensdag 31 januari 2018 @ 23:55:
Ampere.

Ja, een verspreking.

[dcm360]

Verwijderd schreef op woensdag 31 januari 2018 @ 23:44:
[...]

Tenzij AMD bewust niet meer GPU's levert omdat ze niet nog een keer het slachtoffer willen worden van een crashende 'mining'mart en zo en netto geld verliezen en vaste gamingklanten verliezen. AMD heeft er alle belang bij juist bewust minder GPU's te leveren dan dat ze kunnen leveren totdat die 'mining'-storm gaat liggen. Het probleem is nu dat het jaren zou kunnen gaan duren voordat het zo ver is...

Er worden naar verluidt door AIB/AIC-partners hele ladingen kaarten direct aan miningfarms etc. verkocht en deze professionele 'miners' hebben zelfs een opdracht gegeven aan TSMC voor een gigantisch groot aantal kaarten. De vraag is welke bedrijven dit wel en niet doen maar het is zeker dat het gebeurt.

In dat geval is het vrij onhandig van de topvrouw van een beursgenoteerd bedrijf om aan de media een verhaal te verkopen dat haaks zou staan op de realiteit die jij voorstelt. Het is voor de rest ook nog een plausibel verhaal, want dat geheugen lastig te krijgen is wordt ook wel bevestigd door de huidige prijzen.
En ik zou het waarderen als je reageert op hele alinea's in plaats van 1 zin er uit te pakken. Nu voel ik me deels een vastgelopen grammafoonplaat omdat ik in mijn reactie een deel herhaal van wat ik al zei

[Verwijderd]

Ik citeer juist bewust die ene zin om duidelijk te maken waarop ik reageer.

Die theorie komt niet van mij, die komt van invloedrijke journalisten zoals Ryan Smith. Wat je er ook van denkt, het is een bekend feit dat AMD de vorige keer geld verloor door de 'mining', ze zouden gek zijn als ze nu dezelfde fout zouden maken. Gamers vinden het niet leuk maar bedrijfskundig gezien heeft AMD geen andere keuze dan momenteel de verkoop te beperken en de prijs te verhogen op wat ze wel verkopen, zolang je gelooft dat de zeepbel binnen een jaar of zo wel weer eens een keer knapt. En daar zit nu het probleem, het lijkt erop dat die niet meer zo snel knapt dus moeten ze iets nieuws bedenken, ofwel blijvend meer laten produceren en verkopen met het risico dat je veel verlies lijdt als die zeepbel toch knapt ofwel op de een of andere manier ervoor zorgen dat gamingkaarten niet gebruikt kunnen worden voor 'mining', het laatste is erg moeilijk.

Er zijn aanwijzingen dat deze theorie klopt. Net toen de zeepbel leek te beginnen knappen kregen de AIC-partners Vega-GPU's en een paar weken later toen de zeepbel weer fors was opgeblazen kwamen er nauwelijks nog nieuwe Vega-kaarten bij de winkels. Niet alleen dat, we weten inmiddels dat AMD inmiddels niet of nauwelijks nog referentiekaarten voor Vega verkoopt terwijl ze aangaven daarmee te zijn gestopt voor de custom-Vega-kaarten maar die komen nog nauwelijks de winkels binnen. Nee, dit gaat niet alleen om klanten die in 1 keer 100 kaarten kopen, het gaat om winkels die zelf ook bijna geen AMD-kaarten kunnen kopen. Dan kan je nog speculeren of dat al die kaarten van de AIC-partners direct naar miningfarms gaan of dat de AIC's bijna geen GPU's krijgen.

Ik heb nog niets gehoord van het nieuws van vandaag. Su zal niet liegen, de vraag is voor mij of dat mensen haar woorden juist hebben geïnterpreteerd, dat heb ik in het verleden al vaak verkeerd zien gaan (ook hier) dus ik wil het uit de eerste bron vernemen in plaats van af te gaan op andere mensen die haar iets hoorden zeggen over hoorden van iemand die haar iets hoorden zeggen.

[ Voor 132% gewijzigd door Verwijderd op 01-02-2018 00:44 ]

[The Source]

Iemand had mij getagged maar kan niets vinden..

Anyway

Prijzen zullen in komende weken / maanden enkel nog maar hoger worden:
- Mining lijkt niet te stoppen te zijn
- Memory prijzen blijven omhoog gaan, mobile business...
- USD/EURO (nu voordelig voor euro, maar als dat stabliseerd betalen wij zo weer 5 tot 6% meer)
- Chinese New Year (mensen vertrekken naar familie in binnenland en komen veel niet terug, cost of labour gaat dan omhoog)
- Onderdelen prijs verhoging

AMD kan zeggen dat ze genoeg GPUs kunnen produceren maar zonder geheugen heb je er niets aan. Ik heb voor de lancering al gezegd dat HBM de limiting factor gaat worden, dat ze er nooit markt aandeel mee kunnen pakken. Daarnaast heb ik ook gezegd dat Vega tot eind 2017 niet goed te verkrijgen zou zijn ivm een grote OEM klant (apple dus), gok maar dat die wel geleverd krijgt Ik lag al dubbel toen al die AMD en sommige AIBs hun custom kaarten aan het aankondigen waren... tot op heden helaas pinda kaas. En de VGA shortage (en VEGA) blijft zeker de eerste helft van dit jaar, redenen zie hierboven.

Beter nog het is best mogelijk dat de shortage en nog veel hogere prijzen wel eens heel 2018 kunnen blijven duren. Al die miners die 1 jaar of 2 jaar geleden in GPU's hebben geinvesteerd zullen hebben aardig verdient en zullen bij de volgende GPU lancering hun mining rigs weer willen updaten. NV en AMD zullen asap GPUs op een kleiner productie proces willen introduceren want dat betekent ongeveer een halvering van hun kosten per die, dus meer marge.

Dus als je een GPU zoekt, koop ASAP en zeur niet over de prijs, gaat enkel erger worden.

Wat kunnen we hier aan doen? Erg weinig. Wij verkopen het liefst gaming kaarten aan gamers want die kopen over 2 jaar weer MSI. Miners kopen wat ze kunnen krijgen voor de laagste prijs. Beter nog aan de miners waar we direct aan verkopen verkopen we enkel mining SKU's maar er zijn genoeg distributeurs en resellers die wel bv gaming kaarten aan miners verkopen, helaas niet te controleren en beheren. NV / AMD zouden speciale mining drivers kunnen maken die enkel op mining kaarten draaien en het kreupal maken op GeForce/etc kaarten. Iedeeen zijn altijd welkom

[foppe-jan]

Klopt niet, want kijkt niet naar platform kosten, maar toch grappig: https://www.pcgamesn.com/...per-cryptocurrency-mining

Daarnaast een vraagje :als Intel in q42017 100m cpus heeft verzet, en dat slechts een deel is van de ~20% die jaarlijks wordt vervangen, welk deel daarvan kan amd dan overnemen bij maximale productie eigen fabs?

[dcm360]

Verwijderd schreef op donderdag 1 februari 2018 @ 00:12:
Ik citeer juist bewust die ene zin om duidelijk te maken waarop ik reageer.

Waarmee je uiteindelijk alleen reageert op mijn stellingname en niet op de gegeven argumenten. Dat discussieert niet echt fijn

[Enchantress]

The Source schreef op donderdag 1 februari 2018 @ 17:27:


Wat kunnen we hier aan doen? Erg weinig. Wij verkopen het liefst gaming kaarten aan gamers want die kopen over 2 jaar weer MSI. Miners kopen wat ze kunnen krijgen voor de laagste prijs. Beter nog aan de miners waar we direct aan verkopen verkopen we enkel mining SKU's maar er zijn genoeg distributeurs en resellers die wel bv gaming kaarten aan miners verkopen, helaas niet te controleren en beheren. NV / AMD zouden speciale mining drivers kunnen maken die enkel op mining kaarten draaien en het kreupal maken op GeForce/etc kaarten. Iedeeen zijn altijd welkom

Mooi marketing`s praatje.

Als MSI aan miners grootte hoeveelheden ''gaming'' videokaarten kan verkopen, doen ze dat maar al te graag.

[Verwijderd]

- weg -

[ Voor 100% gewijzigd door Verwijderd op 01-02-2018 20:53 ]

[dcm360]

Ik ga het niet eens lezen op deze manier Pak mijn alinea als geheel of niet, ik ben er wel klaar mee.

Oke, met reactie op hieronder omdat ik er niet nog een post aan vuil wil maken: Je begon weer met quote van de eerste zin met een reactie daarop. Leuk, maar die zin is niet meer dan een opener die ik vervolgens ga onderbouwen. Vervolgens zie ik zinnen van mij die opgehakt zijn met lap tekst eronder. Op die manier krijg ik het idee dat je enkel op flarden in wil gaan en niet op de essentie.

[ Voor 65% gewijzigd door dcm360 op 01-02-2018 21:03 ]

[Verwijderd]

Ook goed.
Ik zal het kort houden, ik had naar mijn indruk op heel jouw alinea gereageerd. Een volgende keer beter.
De essentie was voor mij dat er slechts 1 reden is waarom er nu geen grafische kaarten te krijgen zijn voor een normale prijs voor gamers: de 'miners'. Al de rest is niet relevant in deze context. De hogere prijs van het geheugen is triviaal, €20-30 maakt gewoon weinig uit op prijzen van €250 en hoger en de RAM is prima te leveren, er is geen tekort voor die bedrijven. AMD kan inderdaad meer GPU's laten produceren maar ofwel wil AMD dat niet doen ofwel worden ze niet afgenomen, waarschijnlijk meer het eerste. Jij ging naar mijn mening in op bijzaken in deze kwestie, de kern is de 'mining', dat is wat heel die markt overhoop heeft gegooid voor de grafische kaarten en het ziet er naar uit dat het zelfs jaren kan duren voordat die vraag daalt omdat er belachelijk veel virtuele 'munten' zijn. Uiteindelijk zal ofwel de 'mining' gestopt moeten worden voor gaming-kaarten ofwel zal de productie structureel fors omhoog moeten en verneuken we het milieu nog meer voor deze onzin. Voor de RAM heeft het inderdaad met de mobiele telefoons te maken, al die mensen die na een paar of zelfs ieder jaar - sick - hun telefoontje upgraden...
Niet de enige oorzaak (ook bijv. de groeiende vraag in enkele grote landen zoals China en India, mogelijk ook enige kartelvorming) maar dat speelde een grote rol, alleen is het voor de grafische kaarten vooralsnog betrekkelijk onbelangrijk.

The Source schreef op donderdag 1 februari 2018 @ 17:27:
Iemand had mij getagged maar kan niets vinden..

Ik gaf aan dat jij in augustus al waarschuwde dat de grafische kaarten duurder zouden worden met enkele tientjes. Volgens mij had jij het zelfs over €20-30.
Ik ben het met jou eens dat het de komende maanden erger gaat worden, de RAM-prijzen zullen pas in de tweede helft van het jaar gaan dalen en voor 2019 zullen ze niet richting normaal gaan, om nog maar te zwijgen over €70 voor 16 GB.
De goede oude tijd.
Wat betreft de 'mining', niemand kan voorspellen hoe dat verder gaat maar het lijkt er helaas op dat dit een structureel probleem is.

Naar het schijnt gaan we binnen kort duurdere PCB's krijgen doordat koper duurder wordt. Dat kan er ook nog wel bij. Al die jaren dat Intel een monopolie had gebeurde er weinig geks, AMD brengts ons de octacore voor een normale prijs en bam, alle shit komt tegelijkertijd.

The Source schreef op donderdag 1 februari 2018 @ 17:27:
Beter nog aan de miners waar we direct aan verkopen verkopen we enkel mining SKU's maar er zijn genoeg distributeurs en resellers die wel bv gaming kaarten aan miners verkopen, helaas niet te controleren en beheren. NV / AMD zouden speciale mining drivers kunnen maken die enkel op mining kaarten draaien en het kreupal maken op GeForce/etc kaarten. Iedeeen zijn altijd welkom

Is het niet veel te gemakkelijk voor de 'miners' om die BIOS te flashen en er een BIOS/driver op te plaatsen waarmee je wel kan minen met die kaart? Hoe goed is dat te beveiligen tegen een groep mensen die met speels gemak tientallen hackers en topprogrammeurs kunnen inhuren om dit voor hen op te lossen?

Enchantress schreef op donderdag 1 februari 2018 @ 20:22:
[...]

Mooi marketing`s praatje.

Als MSI aan miners grootte hoeveelheden ''gaming'' videokaarten kan verkopen, doen ze dat maar al te graag.

Hij reageert hier nu als een forumlid om ons te informeren en niet als een marketingmedewerker van MSI, dat stel ik op prijs. We weten dat het momenteel gebeurt dat AIB/AIC-partners grote aantallen kaarten direct aan miners verkopen, of dat MSI wel of niet een van die bedrijven is dat is volgens mij niet bekend. Steve (GamersNexus) gaf aan dat een aantal bedrijven meer brood ziet in de gamers dan in de miners, niet enkel omdat de gamers trouwere klanten zijn maar ook omdat je aan de gamers ook andere hardware kan verkopen. Denk bijvoorbeeld aan Asus die ook een mooie 1440p-monitor kan verkopen aan iemand die een voor 1440p-gaming geschikte kaart koopt. Verder denk ik dat hij een realistisch beeld schets, het zal de komende maanden enkel erger worden en ook die bedrijven die liever aan gamers verkopen kunnen er weinig aan doen, het is aan AMD en Nvidia om op de een of andere manier de performance van die kaarten te gimpen voor minen en met aparte mining-kaarten te komen, dat laatste heeft waarschijnlijk pas zin als het eerste is gedaan want nu kopen ze ook alles op wat ze kunnen krijgen, ook de Nvidia-kaarten en ook die Nvidia-kaarten die helemaal zo geschikt zijn voor mining (1080 Ti), voor zo ver wij het weten.

[ Voor 92% gewijzigd door Verwijderd op 01-02-2018 21:21 ]

[Verwijderd]

Het lijkt erop dat meer kernen en meer threads meer waard is bij dit spel dan een hogere klokfrequentie. Een teken aan de wand voor wat we de komende jaren gaan zien? Bij "standard quality" zie je hetzelfde patroon maar hier is het duidelijker, in de beide gevallen zijn Gimpworks-features uitgeschakeld om de bottleneck bij de CPU te leggen.

De vraag is dan nog waarom ded 8700k het qua minima verliest van de 1600X. Zou het kunnen komen doordat de Ryzen-CPU's meer cache hebben? SMT vs HT lijkt geen rol te spelen aangezien het uitschakelen van SMT de FPS verhoogt. Zelf zou ik dit spel liever spelen met een 1600X en een 1080 Ti dan met een 8700k en een 1080 Ti, liever lagere gemiddeldes en hogere minima bij deze verhouding. Dat lagere gemiddelde merk je waarschijnlijk niet, de hogere minima wel. Dat het dichter bij elkaar ligt doet het meer vloeiend aanvoelen. Naar mijn mening wint de 1600X het dan ook van de 8700k in dit geval.

Nog even iets anders, de prijs van de AS Rock Taichi begint langzaamaan richting normaal te gaan in Nederland in vergelijking met de USA en Asus vs. AS Rock. Sinds het begin betaalde je voor de Asus Prime Pro X370 in Nederland minder in € dan in de USA in $ (nu €140 vs. $160), de Taichi kostte hier €240 en in de USA $200. Nu is de prijs voor de Taichi in Nederland gezakt naar €200, komende van €210-220. Nog steeds wat te duur in vergelijking met Asus maar het is aan het verbeteren.

[ Voor 67% gewijzigd door Verwijderd op 03-02-2018 18:01 ]

[foppe-jan]

offtopic:
als het inderdaad klopt dat de Iphone X productie gehalveerd wordt (van 40 naar 20m), scheelt dat ten minste 20M*64/256GB aan nand chips die worden opgeslokt. Best wat SSDs.

[ Voor 7% gewijzigd door foppe-jan op 04-02-2018 15:01 ]

[Sp3ci3s8472]

foppe-jan schreef op zondag 4 februari 2018 @ 14:57:

offtopic:
als het inderdaad klopt dat de Iphone X productie gehalveerd wordt (van 40 naar 20m), scheelt dat ten minste 20M*64/256GB aan nand chips die worden opgeslokt. Best wat SSDs.

Dat zal ook voor geheugen gelden, meer ruimte in de fabs om geheugen voor ons te maken .

[DaniëlWW2]

Sp3ci3s8472 schreef op maandag 5 februari 2018 @ 14:07:
[...]


Dat zal ook voor geheugen gelden, meer ruimte in de fabs om geheugen voor miners te maken .

FTFY.

[foppe-jan]

Sp3ci3s8472 schreef op maandag 5 februari 2018 @ 14:07:
[...]


Dat zal ook voor geheugen gelden, meer ruimte in de fabs om geheugen voor ons te maken .

vast wel wat, maar de X heeft maar 3gb ram (anders gaat ie te lang mee enzo, daar kost dat ding niet genoeg voor), dus dat is 'maar' ~3.75M 16gb kitjes.

[Verwijderd]

DaniëlWW2 schreef op maandag 5 februari 2018 @ 14:16:
[...]


FTFY.

Ik weet niet hoe dat werkt bij Samsung in de fabs (of dat ze dezelfde apparatuur gebruiken voor die chips als voor het geheugen), in die context merk ik maar even op dat Samsung naar verluidt nu ook is begonnen met die ASIC-dingen te maken voor miners.
https://cointelegraph.com...-positive-news-for-miners
https://www.extremetech.c...ips-mining-cryptocurrency
https://qz.com/1195205/sa...or-cryptocurrency-mining/

Dat gezegd hebbende, of dat het wel of niet botst met het geheugen, Samsung en Hynix - volgende op Samsung - hebben aangekondigd meer DDR4 te gaan maken in 2018, Samsung heeft aangekondigd dat we in de tweede helft van 2018 lagere prijzen mogen verwachten (t.o.v. wanneer, S1 2018 of 2017?) en de Chinezen zijn een beetje lastig, ze onderzoeken pricefixing en hebben inmiddels een deal gesloten met Samsung dat Samsung een fabriek zou bouwen in China, de Chinezen staan te springen om ook op grote schaal geheugen te maken, mogelijk stimuleert dit Samsung en Hynix om wat meer te produceren of de prijs te verlagen.
https://www.electronicswe...s-memory-pricing-2018-01/ (hoe het begon)
https://www.digitimes.com/news/a20180202VL200.html (de uitkomst, voor nu)
Vanzelfsprekend is er nu dan ook het nodige gedoe met beschuldigingen van patent-schending. Dat is overigens een redelijk veel voorkomend iets in de technologie-sector, Intel heeft dat in het verleden (jaren 90 als ik me niet vergis) ook gedaan.
https://seekingalpha.com/...micron-technology-serious (als je het niet kan lezen: Javascript blokkeren ).
http://www.iam-media.com/...40-499a-80ab-8c0f71f76af3

De theorieën over hoe de prijzen gaan verlopen verschillen (d'uh) maar het wordt aangenomen dat we in 2019 lagere prijzen gaan zien. De vraag is hoe snel het gaat gaan en of dat de prijzen nog voldoende zakken (terug naar de prijzen van 2016) voordat DDR5 op gang komt en hiermee DDR4 minder populair maakt.

[ Voor 61% gewijzigd door Verwijderd op 05-02-2018 17:25 ]

[foppe-jan]

Uhoh.
https://www.kitguru.net/c...ed/?PageSpeed=noscript%27

Apparently, the biggest reason for this price increase is a shortage in 12-inch, 300mm wafers, which are traditionally used to build processors, graphics chips and RAM. Given that GPU prices have already risen to ridiculous heights due to crypto-mining, this is an additional blow to DIY PC builders.

Last year when SUMCO revealed its own price hikes, the company estimated that global wafer demands will rise to 6.6 million per month by 2020. Hopefully by then, we’ll see production increase but for the time being, it looks like we will be stuck with price hikes as demand outstrips supply.

[Verwijderd]

Spijtig dat ze niet duiden waardoor het tekort aan wafers is ontstaan. Als ik een gokje waag, met slechts 2 bedrijven...

Ik ga het nog wat erger maken, de koperprijs is aan het stijgen en zal vermoedelijk nog fors verder stijgen in 2018/2019, dat heeft als gevolg dat de kostprijs van alle PCB's, CPU's, GPU's, monitors...stijgt.
Ik heb wat informatie opgezocht en gerekend, een computer bevatte volgens Silicon Valley Toxics Coalition in of net voor 2006 ongeveer 2,2 kg. aan koper en ik kom voor koper prijzen tegen van tegen de 4 pond per kg.
http://europe.autonews.co...d-lead-to-copper-shortage
Ik meen mij te herinneren dat tegelijkertijd de productie wat aan het verminderen is in plaatsen waar het veel vandaan kwam.
Zo'n CPU kost naar verluidt minder dan €100 om te produceren en slechts een deel van de kosten zit in de aankoop van de wafer. De kosten worden vooral veroorzaakt doordat je in grote ruimtes langdurig dat spul moet laten liggen terwijl je allerlei chemische reacties uitvoert om materiaal te verwijderen, metalen te laten hechten etc.

Het is wrang dat in al die jaren dat Intel de markt verziekte zulke zaken minder gebeurden terwijl net nu AMD de martkt weer wat in beweging heeft gekregen (6/8 kernen voor de dekstop is nu normaal, 4 kernen voor de laptop is de ondergrens aan het worden) we al die ellende tegelijkertijd krijgen.

offtopic:
Een voorbode voor wanneer het echt onder druk komt te staan zo gauw de olie te schaars wordt?

[Help!!!!]

More EPYC Servers: Dell Launches 1P and 2P PowerEdge for HPC and Virtualization

[Sp3ci3s8472]

Help!!!! schreef op dinsdag 6 februari 2018 @ 17:39:
More EPYC Servers: Dell Launches 1P and 2P PowerEdge for HPC and Virtualization

Dell is een grote partij, goed nieuws voor AMD. Volgens mij een hele tijd geleden dat er AMD servers waren...ook al zou AMD maar 10% van de markt afsnoepen van Intel dan is dat gigantisch. Dat zou ze best moeten lukken met dat Meltdown en Spectre geneuzel.

[DaniëlWW2]

foppe-jan schreef op maandag 5 februari 2018 @ 22:26:
Uhoh.
https://www.kitguru.net/c...ed/?PageSpeed=noscript%27


[...]

Ik heb dus even lopen graven wat een 300mm wafer nu schijnt te kosten. Tja, ik kwam op een vernietigende $3. Ik betwijfel of het een groot probleem gaat zijn, zeker omdat AMD gewoon een jaarcontract met GF heeft met vaste afname en prijzen.

Help!!!! schreef op dinsdag 6 februari 2018 @ 17:39:
More EPYC Servers: Dell Launches 1P and 2P PowerEdge for HPC and Virtualization

Dat zat ook al even in de pijplijn, maar daar is Dell dan ook eindelijk met AMD serverchips. Dell is natuurlijk altijd een beetje traag als het om AMD chips gaat, Dat weten we allemaal, maar nu hebben ze de boodschap ook door.
AMD hoopt op 5% marktaandeel dit jaar te komen in de servermarkt. Zit kennelijk $21 miljard in die markt, dus 5% ($1.050.000.000 omzet) zou best wel aardig voor een eerste vol jaar zijn.

[Help!!!!]

^
Marktaandeel is denk ik alleen niet perse 1 op 1 te vertalen naar omzet.

Komend van nul naar 5% in een jaar is volgensmij geen slecht resultaat. Hopelijk gaat het lukken.

[Dennism]

DaniëlWW2 schreef op dinsdag 6 februari 2018 @ 20:49:


Dell is natuurlijk altijd een beetje traag als het om AMD chips gaat

Behalve Threadripper natuurlijk, die hadden ze exclusief

[DaniëlWW2]

Dennism schreef op dinsdag 6 februari 2018 @ 21:52:
[...]


Behalve Threadripper natuurlijk, die hadden ze exclusief

Nu je het zo zegt inderdaad ja. AMD heeft Dell nu gewoon omgekocht.

[foppe-jan]

http://www.tomshardware.c...amd-benchmarks,36457.html

Dell is already shipping the new PowerEdge 14G servers to early access customers, so detailed documentation is already available online. AMD tells us it has a strong supply of silicon and Dell has a strong inventory of systems ready for shipment. Dell EMC and AMD will unveil the new systems in Beijing today.

[Dennism]

foppe-jan schreef op dinsdag 6 februari 2018 @ 23:18:
http://www.tomshardware.c...amd-benchmarks,36457.html

[...]

Dat is inderdaad ook wel als Dell, wachten tot ze daadwerkelijk kunnen leveren en dan pas lanceren. Die hebben zeer regelmatig dat een product dat gelanceerd wordt ook vrij wel direct leverbaar is, itt HPE waar je soms na de aankondiging nog weken moet wachten tot je kan bestellen.

[roy-t]

Dennism schreef op dinsdag 30 januari 2018 @ 14:29:
@DaniëlWW2

Ik vraag me eigenlijk af hoe dat gaat, want voor zover ik het altijd begrepen heb (ben zeker geen programmeur) kun je optimaliseren in de geschreven code en door bepaalde optimaliseerde compilers te gebruiken (bijv. de Intel compiler wanneer je optimaliseert voor Intel). Ik meende echter altijd dat je maar 1 compiler kan gebruiken voor een bepaald stuk software, tenzij je meerdere versie's van de binaries wil hebben, dan kan je uiteraard meedere malen compileren.

Ik zie echter nog niet direct games (of software als Autocad) ineens uitkomen met Game_A_AMD.exe en Game_A_Intel.exe of Autocad_AMD.exe en Autocad_Intel.exe en meer van dit bij closed source windows software.

Ik kan me echter wel voorstellen dat als jij je eigen linux distro met applicaties bij elkaar compileert en je hebt een Ryzen systeem dat je dan alles gaat compileren met de AMD compiler als deze optimaal blijkt te zijn.

Ik zag dat hier nog geen programmeur op gereageerd had. Misschien is het wel leuk om mijn inzichten hierover te lezen.

Net als met alles was vroeger alles simpler. Je schreef een stukje C++ code en de compiler hakte dit in kleine instructies die de processor direct kon uitvoeren. Een optimizing compiler probeert zo gunstig mogelijke instructies te bedenken door de code grondig te analyseren. Bijvoorbeeld door speciale instructies op de CPU te gebruiken om veel werk in een keer te doen (meerdere getallen bij elkaar op te tellen), de conditie in een lus te simplificeren doordat hij bereneerd heeft dat een getal altijd een bepaalde waarde zal hebben, of zelfs hele stukken code te verwijderen omdat ze niks doen, of omdat ze nooit uitgevoerd kunnen worden.

Aangezien zowel de Intel als AMD processor dezelfde standaarden volgen geld in 99% van de gevallen dat als een compiler iets sneller maakt op 1 processor, dit ook sneller is geworden op een andere merk processor. In sommige gevallen heeft een processor extra instructies (zoals een tijdje met SSE2/3) die gebruikt kunnen worden als ze aanwezig zijn om iets ineens heel veel sneller te doen. Maar qua dit soort low-level features ontlopen AMD en Intel elkaar niet veel op dit moment (dacht ik zo).

Natuurlijk zijn er wel subtiele verschillen. Misschien dat AMD processoren gevoeliger zijn voor het ophalen van data uit het geheugen dan Intel processoren (voorbeeld, geen idee of het echt waar is). In dat geval kan de compiler, alleen op hele specifieke momenten dat deze keuze gemaakt kan worden, er voor kiezen om een roete te kiezen die net wat gunstiger is voor de ene processor dan voor de andere.

Maar nu wordt het natuurlijk pas echt ingewikkeld. Zowel Intel als AMD processoren zijn eigenlijk geen echte x86 processoren. Ze snappen x86 maar vertalen dit on-the-fly naar hun eigen instructie-set die de echte hardware snapt. (RISC achtig). Deze vertaler is eigenlijk ook weer een mini compiler. En, hoewel deze geen globaal overzicht heeft over de code, kan deze wel kleine optimalisaties maken. Deze vertaal-unit wordt ook steeds geavanceerder. Hierdoor wordt de invloed van een optimizing compiler die bepaalde micro-afwegingen maakt die misschien iets beter uitpakken voor een bepaald merk lastiger te berekenen.

Nu terug naar de compiler. Je zou je code base compleet in tweeen kunnen delen en een AMD.exe en een Intel.exe hebben. Maar dat is natuurlijk erg veel werk, je programma wordt er een stuk groter van, en je mist eigenlijk 90% van de code. Jouw code is maar een klein deel van de code die uitgevoerd wordt door de processor. Alle libraries die je gebruikt (Windows libaries, frameworks, etc...) zijn al gecompileerd met een andere compiler en daar heb je zelf geen invloed op. (Tenzij je diehard je eigen kernel, en elke library, en elk programma compileert op Linux natuurlijk).

Dus zou het kunnen dat met een speciale compiler je programma op een AMD processor net een heel klein beetje sneller is. Ja: maar dan wel een heel erg klein beetje.

Dit is natuurlijk ook tegendraads t.o.v. waar we met zijn allen naartoe gaan: code die overal draait, ipv code die heel specifiek aan 1 processor gebonden is. Grappig is, dat talen zoals Java en C#, omdat ze pas vertaald worden naar instructies tijdens het draaien, meer informatie hebben over het systeem en in theorie dus betere optimalisaties kunnen maken. Specifiek voor jouw unieke processor.

Fun fact: vroeger was de Intel compiler zo veel beter dan de rest dat compileren met de Intel compiler je het snelste programma voor op een AMD processor opleverde .

[ Voor 4% gewijzigd door roy-t op 07-02-2018 15:12 ]

[DaniëlWW2]

@roy-t Interessant. Verder zie ik dat ik het wel redelijk goed begrepen had hoe dit werkt.
Toch blijft staan dat sommige games of applicaties bizar onderpresteren. Opvallend was ook dat een game die echt heel erg was, RoTR is gepatched en toen was Ryzen opeens zeer competitief. Het kan dus gewoon wel. Veel recente games draaien ook goed op Ryzen.

Verder zit wel een verschil in cache allocatie tussen Intel en AMD. Intel CPU's zijn inclusief met cache en schuiven cachebestanden die zijn opgeslagen in de L1 of L2 door naar L3 waardoor de CPU snel een bestand uit de L3 terug kan grijpen. Zen haar L3 is victim cache en zal langzamer zijn als er data teruggehaald moet worden. Staat tegenover dat Zen meer L1 en L2 heeft per core en die zijn natuurlijk wel dedicated.

Een ander punt met de L3 cache is thread awareness van het programma. Omdat Zen bestaat uit twee CCX units, eigenlijk twee CPU's die aan elkaar zijn verbonden op een die, kan een CPU core van een CCX, de L3 van een andere CCX gebruiken als de L3 van de ene CCX al vol is. Combineer dit met applicaties die regelmatig van core wisselen, en dan ook tussen de twee CCX units wisselen, en dan ga je inleveren op prestaties. Dat zal ook heel wat verklaren, maar ik vermoed dat dit het niet alleen is.

Waarom? Nou Skylake-X. Daar is Intel ook met victimcache gaan werken, en veel grotere L1 en L2. Prestaties in gaming waren niet best. Vanwege de mech architectuur van Skylake-X zal het langer duren om van L2 naar L3 te gaan, maar wat Skylake-X liet zien was soms wel erg veel prestatieverlies.

[roy-t]

DaniëlWW2 schreef op woensdag 7 februari 2018 @ 15:52:
@roy-t Interessant. Verder zie ik dat ik het wel redelijk goed begrepen had hoe dit werkt.
Toch blijft staan dat sommige games of applicaties bizar onderpresteren. Opvallend was ook dat een game die echt heel erg was, RoTR is gepatched en toen was Ryzen opeens zeer competitief. Het kan dus gewoon wel. Veel recente games draaien ook goed op Ryzen.

Bedankt .

En ik geloof je helemaal. Optimalisatie is zeker mogelijk. Maar ik denk dat dit soort grote wist niet komt door een andere compiler te gebruiken.

Als developer kun je op een high-level niveau naar de code kijken en precies die bottleneck voor het ene systeem meten en oplossen. Als developer heb je veel meer vrijheid dan de compiler, je kunt gedrag aanpassen, en je hebt een beter macro overzicht van de code. Compilers mogen het gedrag nooit aanpassen en kunnen vaak maar kleine stukjes overzien.

Wat dat betreft is het altijd het fijnste als hardwaremakers de developers wat hardware geven om op te testen. Hoe diverser de hardware waar op je test, hoe beter. Zo zie je snel dat op de ene computer iets net niet lekker werkt en op de andere computer juist weer wel en kun je er voor zorgen dat je een generieke oplossing gebruikt die op beide computers werkt. Want helaas zijn computers tegenwoordig zo complex dat het voorspellen van bottlenecks steeds lastiger wordt. Dus zoals altijd meten (testen) is weten.

En elke developer wil graag dat hun software lekker draait op alle computers. Dus zolang de tijd en hardware er is zal daar naar gekeken worden. Maar op een gegeven moment moet software ook af zijn helaas

[ Voor 30% gewijzigd door roy-t op 07-02-2018 17:10 ]

[enchion]

Maw als intel een "saboterende" compiler zou maken dan zouden het duizend speldenprikken zijn die op 1000 verschillende regionen van de CPU van AMD iets minder lekker werken, ipv 1-3 grote fouten die bv de cache of een ander deel volledig weg te laten, zoals bv bewust de floatingpoint unit extra taken te geven door sommige integers als floats te behandelen ?

[roy-t]

enchion schreef op woensdag 7 februari 2018 @ 17:15:
Maw als intel een "saboterende" compiler zou maken dan zouden het duizend speldenprikken zijn die op 1000 verschillende regionen van de CPU van AMD iets minder lekker werken, ipv 1-3 grote fouten die bv de cache of een ander deel volledig weg te laten, zoals bv bewust de floatingpoint unit extra taken te geven door sommige integers als floats te behandelen ?

Als je integers als floats behandeld dan veranderd het gedrag (rekenen met floating point getallen is niet exact). Dit zou iedereen meteen door hebben en een regelrechte ramp zijn voor applicaties met financiële gegevens.

Het bewust saboteren door extra of inefficiënte instructies te gebruiken is lastig te bewijzen. Door extra instructies te injecteren is een Intel processor ook trager of verbruikt deze meer stroom². Dus dat lijkt me niet de juiste weg. Maar soms zal de compiler een keuze moeten maken tussen A of B, als A sneller is op AMD en B sneller is op Intel dan zou ik als Intel natuurlijk altijd B kiezen. Het is immers de Intel Compiler.

Maar dat er expres gehandicapt wordt door de Intel compiler geloof ik niet. Iedereen kan zien wat voor output de Intel compiler oplevert gegeven de input en de output compilers worden vaak¹ geanalyseerd juist om te kijken of je code sneller te maken. (Soms schrijf je code die langzamer is dan verwacht en door de output van de compiler te bekijken kom je er dan achter dat deze een bepaalde optimalisatie niet kon doen, door je algoritme aan te passen kan dit dan wel).

Verder is het natuurlijk ook zo dat Intel maar 1 van de vele compilers heeft die er zijn. LLVM is een heel erg sterk backend dat voor meerdere talen gebruikt wordt en voor C/C++ (vaak code waar je veel performance wil) is er GCC en Microsoft's bij Visual Studio meegeleverde compiler (misschien wel de meest populaire). Al deze compilers hebben als hoofddoel snelle programma's maken en zijn niet gebonden aan een processor fabrikant.

¹ Met vaak bedoel ik hier door mensen die code schrijven die echt snel moet zijn, voor
99% van de programmeurs is dat helemaal niet zo boeiend

² Sommige compilers kunnen tegenwoordig ook optimaliseren voor stroom gebruik, door simpelere instructies te gebruiken houden ze een groot deel van de chip in slaap stand, niet het snelste maar als je geen haast hebt wel goed voor je batterij

[ Voor 17% gewijzigd door roy-t op 07-02-2018 17:32 ]

[DaniëlWW2]

roy-t schreef op woensdag 7 februari 2018 @ 17:04:
[...]


Bedankt .

En ik geloof je helemaal. Optimalisatie is zeker mogelijk. Maar ik denk dat dit soort grote wist niet komt door een andere compiler te gebruiken.

Als developer kun je op een high-level niveau naar de code kijken en precies die bottleneck voor het ene systeem meten en oplossen. Als developer heb je veel meer vrijheid dan de compiler, je kunt gedrag aanpassen, en je hebt een beter macro overzicht van de code. Compilers mogen het gedrag nooit aanpassen en kunnen vaak maar kleine stukjes overzien.

Wat dat betreft is het altijd het fijnste als hardwaremakers de developers wat hardware geven om op te testen. Hoe diverser de hardware waar op je test, hoe beter. Zo zie je snel dat op de ene computer iets net niet lekker werkt en op de andere computer juist weer wel en kun je er voor zorgen dat je een generieke oplossing gebruikt die op beide computers werkt. Want helaas zijn computers tegenwoordig zo complex dat het voorspellen van bottlenecks steeds lastiger wordt. Dus zoals altijd meten (testen) is weten.

En elke developer wil graag dat hun software lekker draait op alle computers. Dus zolang de tijd en hardware er is zal daar naar gekeken worden. Maar op een gegeven moment moet software ook af zijn helaas

Ik denk ook dat hardware variatie het grootste probleem is. Bij de launch van Ryzen zag je bijvoorbeeld ook heel rare (lees waardeloze) resultaten met een Ryzen CPU, een Nvidia GPU en DX12. Geen idee of Nvidia dat al gefixed heeft. Dat heeft mede bijgedragen aan het idee dat Ryzen slecht is voor gaming, terwijl dat niet zo is. Zo heb je wel meer dingen. Zen lijkt erg goed te zijn in onverwachte zeer zware loads op te vangen. Framerates in games zijn vaker merkbaar stabieler met minder drops dan vergelijkbaar geclockte Intel CPU's. Visa versa zijn de Intel's beter in absolute maxima, en iets beter in gemiddelden. Dat lijkt vooral op de cache structuur te hangen. Zen heeft veel meer cache om zaken op te vangen terwijl Intel is efficiënter in cache toewijzen aan cores.

Dan was er nog de situatie van AMD. Na Bulldozer waren ze helemaal weg uit de preformance CPU markt. Het werd een Intel "ringbus" only show. Als er maar een CPU architectuur is met kleine iteraties, dan ga je hierop focussen. Dat lijkt me niet meer dan normaal. Toen verscheen Zen opeens. Zen is eigenlijk terug naar de basis van Phenom II, en dan nog wat meer richting Intel. Qua basaal ontwerp gingen CPU architecturen toch al richting elkaar tussen Nehalem en Phenom II, en Zen is weer een volgend stapje. Natuurlijk niet identiek, verre van, maar wel in basale ontwerpfilosofie en stijl. Rekencore met ALU's en FPU's, relatief kleine L1, dubbele grote L2, vrij veel L3. De verschillen tussen een Sky/Kaby/Coffee Lake aan de ene kant, en Zen aan de andere kant zijn veel kleiner dan bijvoorbeeld Pentium IV en Athlon of C2D en Phenom.

Maar een voorbeeld van goede executie is Civilisation VI. Game is AMD sponsored en kwam eind 2016 uit. Die game draait opvallend goed op Ryzen CPU's tot het punt dat ik vermoed dat ze een engineering sample Ryzen systeem hadden staan voor de optimalisatie voor de release.

Maar jij zegt dus eigenlijk meer dat in het stadia voor compiling de code al geoptimaliseerd moet zijn? Daar kan ik zo inkomen. Ik blijf een Alpha. Kan dingen signaleren en analyseren maar zeer diepgaande kennis over codering zit er (nog) niet in bij mij.

[Dennism]

@roy-t Ben het met Daniel eens, interessante posts en eigenlijk inderdaad ook al een beetje zoals ik verwachtte, net als Daniel.

@DaniëlWW2 Ik denk dat het op dat laatste inderdaad grotendeels neerkomt, een compiler kan zoals Roy aangeeft uiteraard wat helpen, maar kan zoals ik het ook van onze programmeurs begrijp van een drol geen goud maken om het zo maar even te zeggen.

[ Voor 49% gewijzigd door Dennism op 07-02-2018 18:52 ]

[Sp3ci3s8472]

roy-t schreef op woensdag 7 februari 2018 @ 17:24:
[...]
Maar dat er expres gehandicapt wordt door de Intel compiler geloof ik niet. Iedereen kan zien wat voor output de Intel compiler oplevert gegeven de input en de output compilers worden vaak¹ geanalyseerd juist om te kijken of je code sneller te maken. (Soms schrijf je code die langzamer is dan verwacht en door de output van de compiler te bekijken kom je er dan achter dat deze een bepaalde optimalisatie niet kon doen, door je algoritme aan te passen kan dit dan wel).

Tegenwoordig niet meer, er is een tijd geweest waar dat wel gebeurde. Als een CPU wel SSE instructies maar niet de GenuineIntel flag had dan werden deze niet gebruikt.
http://www.agner.org/optimize/blog/read.php?i=49
https://techreport.com/ne...r-cripple-amd-performance

[Verwijderd]

DaniëlWW2 schreef op woensdag 7 februari 2018 @ 15:52:
Waarom? Nou Skylake-X. Daar is Intel ook met victimcache gaan werken, en veel grotere L1 en L2. Prestaties in gaming waren niet best. Vanwege de mech architectuur van Skylake-X zal het langer duren om van L2 naar L3 te gaan, maar wat Skylake-X liet zien was soms wel erg veel prestatieverlies.

Skylake-X roept bij mij de vraag op of dat die mensen die roepen dat Intel-CPU's nog meer zouden presteren bij dezelfde klokfrequentie niet full of shit zijn. Immers ging Intel met Skylake-X met hun mesh-netwerk en grotere hoeveelheid L3-cache dezelfde kant op als AMD met Ryzen. Je moet wel appels met appels vergelijken, een monolitische CPU vs. een mutli-die CPU...
Nu is het best mogelijk dat Intel nog jarenlang monolithische octacores met een ringbus en diezelfde cache-structuur gaat maken maar het ligt m.i. meer voor de hand dat Intel ook multidie-CPU's gaat introduceren omdat ze anders meer kosten hebben.

[roy-t]

DaniëlWW2 schreef op woensdag 7 februari 2018 @ 18:06:
[...]

Maar jij zegt dus eigenlijk meer dat in het stadia voor compiling de code al geoptimaliseerd moet zijn? Daar kan ik zo inkomen. Ik blijf een Alpha. Kan dingen signaleren en analyseren maar zeer diepgaande kennis over codering zit er (nog) niet in bij mij.

Je kunt met algoritmen inderdaad veel verder komen dan met compiler optimalisaties. Maar het zijn allemaal belangrijke stappen en in veel gevallen bieden deze optimalisaties dus voor beide merken veel winst

Sp3ci3s8472 schreef op woensdag 7 februari 2018 @ 18:56:
[...]


Tegenwoordig niet meer, er is een tijd geweest waar dat wel gebeurde. Als een CPU wel SSE instructies maar niet de GenuineIntel flag had dan werden deze niet gebruikt.
http://www.agner.org/optimize/blog/read.php?i=49
https://techreport.com/ne...r-cripple-amd-performance

Klopt, dat was echt waardeloos. Geeft wel mooi aan dat een compiler maken die de ander benadeeld goed opvalt.

[ Voor 34% gewijzigd door roy-t op 08-02-2018 09:05 ]

[DaniëlWW2]

Verwijderd schreef op woensdag 7 februari 2018 @ 22:55:
[...]

Skylake-X roept bij mij de vraag op of dat die mensen die roepen dat Intel-CPU's nog meer zouden presteren bij dezelfde klokfrequentie niet full of shit zijn. Immers ging Intel met Skylake-X met hun mesh-netwerk en grotere hoeveelheid L3-cache dezelfde kant op als AMD met Ryzen. Je moet wel appels met appels vergelijken, een monolitische CPU vs. een mutli-die CPU...
Nu is het best mogelijk dat Intel nog jarenlang monolithische octacores met een ringbus en diezelfde cache-structuur gaat maken maar het ligt m.i. meer voor de hand dat Intel ook multidie-CPU's gaat introduceren omdat ze anders meer kosten hebben.

Zen lijkt meer op "Ringbus" dan Skylake-X hoor. Skylake-X heeft verder juist L3 cache opgegeven voor veel meer L2.

[Werelds]

Ook waard om te vermelden dat juist als het om caches gaat, er op code niveau veel beter geoptimaliseerd kan worden dan door de compiler. Als je de hardcore optimalisaties in sommige encoders of engines bekijkt, zul je zien dat er heel veel "geshuffled" wordt om er voor te zorgen dat bepaalde dingen in L1 blijven plakken. Een compiler zou dat in theorie ook kunnen, maar je zit dan te kijken naar een niveau van analyse dat vaak niet gewenst is omdat dat ook heel makkelijk tegendraads kan werken.

[Verwijderd]

DaniëlWW2 schreef op donderdag 8 februari 2018 @ 10:01:
[...]


Zen lijkt meer op "Ringbus" dan Skylake-X hoor. Skylake-X heeft verder juist L3 cache opgegeven voor veel meer L2.

https://www.anandtech.com...n-to-consumers-for-1999/3
With Skylake-X, this cache arrangement changes. When Skylake-S was originally launched, we noted that the L2 cache had a lower associativity as it allowed for more modularity, and this is that principle in action. Skylake-X processors will have their private L2 cache increased from 256 KB to 1 MB, a four-fold increase. This comes at the expense of the L3 cache, which is reduced from ~2.5MB/core to 1.375MB/core.
...
With such a large L2 cache, the L2 to L3 connection is no longer inclusive and now ‘non-inclusive’. Intel is using this terminology rather than ‘exclusive’ or ‘fully-exclusive’, as the L3 will still have some of the L3 features that aren’t present in a victim cache, such as prefetching. What this will mean however is more work for snooping, and keeping track of where cache lines are. Cores will snoop other cores’ L2 to find updated data with the DRAM as a backup (which may be out of date). In previous generations the L3 cache was always a backup, but now this changes.

The good element of this design is that a larger L2 will increase the hit-rate and decrease the miss-rate. Depending on the level of associativity (which has not been disclosed yet, at least not in the basic slide decks), a general rule I have heard is that a double of cache size decreases the miss rate by the sqrt(2), and is liable for a 3-5% IPC uplift in a regular workflow. Thus here’s a conundrum for you: if the L2 has a factor 2 better hit rate, leading to an 8-13% IPC increase, it’s not the same performance as Skylake-S. It may be the same microarchitecture outside the caches, but we get a situation where performance will differ.
...

Jij hebt gelijk, met de kanttekening dat het arbitrair is wat L2 en L3 wordt genoemd en dat dit tussen de generaties wat kan verschuiven, ik was in de war met L2. Al geldt hetzelfde principe voor wat Intel wijzigde in vergelijking met wat AMD deed met Ryzen, daar ging het mij om.
Ja, Ryzen nadert de ringbus meer dan Skylake-X maar ook Ryzen zit er m.i. redelijk ver van verwijderd.

[Sp3ci3s8472]

Maandag overigens de launch van de 2200G en de 2400G. Dan verloopt de NDA voor de reviews ook. Ben benieuwd, nu nog fatsoenlijke mini itx bordjes met HDMI 2.0.

Snap overigens niet dat fabrikanten niet doorhebben dat dat een gewilde combinatie zou zijn...

@The Source
Heeft MSI hiervoor iets op de planning staan? Zover ik begrijp kan dit bord het niet
MSI B350I Pro AC.

[ Voor 47% gewijzigd door Sp3ci3s8472 op 09-02-2018 23:28 ]

[Dennism]

Sp3ci3s8472 schreef op vrijdag 9 februari 2018 @ 23:23:
Maandag overigens de launch van de 2200G en de 2400G. Dan verloopt de NDA voor de reviews ook. Ben benieuwd, nu nog fatsoenlijke mini itx bordjes met HDMI 2.0.

Snap overigens niet dat fabrikanten niet doorhebben dat dat een gewilde combinatie zou zijn...

@The Source
Heeft MSI hiervoor iets op de planning staan? Zover ik begrijp kan dit bord het niet
MSI B350I Pro AC.

Ik verwacht zodra de nieuwe serie chipsets komen dat de bordjes daarop gebaseerd wel HDMI 2.0 zullen hebben, al zullen er mogelijk ook wel een paar 300 serie bordjes met een nieuwe revisie komen met HDMI 2.0 als dat technisch mogelijk is.

Ben eigenlijk wel benieuwd waarom de huidige bordjes geen HDMI 2.0 hebben, is dat een chipset limitatie? Je zou n.l. eigenlijk verwachten dat het grootste deel van de support in het grafische deel van APU zit, de fysieke aansluiting is hetzelfde dus eigenlijk vreemd dat de huidige serie bordjes het niet heeft.

[sdk1985]

DaniëlWW2 schreef op woensdag 7 februari 2018 @ 18:06:
[...]


Ik denk ook dat hardware variatie het grootste probleem is. Bij de launch van Ryzen zag je bijvoorbeeld ook heel rare (lees waardeloze) resultaten met een Ryzen CPU, een Nvidia GPU en DX12. Geen idee of Nvidia dat al gefixed heeft. Dat heeft mede bijgedragen aan het idee dat Ryzen slecht is voor gaming, terwijl dat niet zo is. Zo heb je wel meer dingen. Zen lijkt erg goed te zijn in onverwachte zeer zware loads op te vangen. Framerates in games zijn vaker merkbaar stabieler met minder drops dan vergelijkbaar geclockte Intel CPU's. Visa versa zijn de Intel's beter in absolute maxima, en iets beter in gemiddelden. Dat lijkt vooral op de cache structuur te hangen. Zen heeft veel meer cache om zaken op te vangen terwijl Intel is efficiënter in cache toewijzen aan cores.

Er zit een relatie tussen de fps en de variatie. Dit heb ik bij rainbow six siege goed gemerkt. In die game neemt de benodigde rekenkracht exponentieel toe bij hogere framerates. Wanneer er volgens iets gebeurd, denk aan het inslaan van een raam of een explosie, dan kakt daardoor je framerate flink in. Pas wanneer jij framerates gaat cappen krijg je in die game rechte FRAPS plots. Met een wat lagere Mhz haal je minder fps en zijn de drop automatisch minder heftig. Op mijn 2500K wisselde de framerates tussen de 140+ en <30 fps. Op de G4560 was het veel minder een issue, die haalde gewoon minder fps.

Verder schijnt Nvidia zwaarder op de cpu te leunen wat verklaart waarom Intel+ Nvidia beter loopt, bij Intel heb je wat meer headroom.

Tot slot valt mij op dat steeds meer games echt zwaar in de AVX optimalisatie zitten. Veel meer games dan verwacht gebruiken AVX. Juist aan de AVX kant is de prestatie bij Intel gigantisch gestegen de laatste jaren. Wat dat betreft is het jammer dat je AVX niet makkelijk aan en uit kunt zetten.

[enchion]

sdk1985 schreef op zaterdag 10 februari 2018 @ 01:17:
[...]
Verder schijnt Nvidia zwaarder op de cpu te leunen wat verklaart waarom Intel+ Nvidia beter loopt, bij Intel heb je wat meer headroom.

Tot slot valt mij op dat steeds meer games echt zwaar in de AVX optimalisatie zitten. Veel meer games dan verwacht gebruiken AVX. Juist aan de AVX kant is de prestatie bij Intel gigantisch gestegen de laatste jaren. Wat dat betreft is het jammer dat je AVX niet makkelijk aan en uit kunt zetten.

We think therefore it is.

[Sp3ci3s8472]

enchion schreef op zaterdag 10 februari 2018 @ 01:24:
[...]


We think therefore it is.

Het feit dat Nvidia meer op de cpu leunt kan je zelf nagaan. Doordat Nvidia draw DX11 calls in de driver kan opknippen kunnen ze meer cores gebruiken. Nadeel is dat dit overhead geeft waardoor de cpu in totaal meer wordt belast. AMD doet het maar op een core met DX11 en is daarin heel efficient, alleen het is maar 1 core...

[Enchantress]

Sp3ci3s8472 schreef op vrijdag 9 februari 2018 @ 23:23:
Maandag overigens de launch van de 2200G en de 2400G. Dan verloopt de NDA voor de reviews ook. Ben benieuwd, nu nog fatsoenlijke mini itx bordjes met HDMI 2.0.

Dan krijgen we bij HWI weer een mooie review
Gaan we de APU testen met GTA 5, Metro Last Light, far cry primal lekker oude games er tegen aan gooien.


Maar ben zeer zeker benieuwd hoe de APU gaat presteren, 2400g zou in de beurt moeten komen van de GTX 1060 max-q.

[Verwijderd]

Sp3ci3s8472 schreef op vrijdag 9 februari 2018 @ 23:23:
Maandag overigens de launch van de 2200G en de 2400G. Dan verloopt de NDA voor de reviews ook. Ben benieuwd, nu nog fatsoenlijke mini itx bordjes met HDMI 2.0.

Snap overigens niet dat fabrikanten niet doorhebben dat dat een gewilde combinatie zou zijn...

Ja, dit is een zeer goede basis voor mini-ITX formaat. Als je bijvoorbeeld een HTPC of console-emulator wil dan heb je niet meer dan dit nodig. Eigenlijk zou AMD of een partner hier een soort van NUC van moeten maken.

Enchantress schreef op zondag 11 februari 2018 @ 02:30:
[...]

Dan krijgen we bij HWI weer een mooie review
Gaan we de APU testen met GTA 5, Metro Last Light, far cry primal lekker oude games er tegen aan gooien.

Met als smoes dat ze anders niet kunnen vergelijken met alle oude hardware.
Het is prima om ook een paar oude spellen in de benchmark te houden, waarbij Crysis 3 en Metro veel meer voor de hand liggen dan GTA5 wat notoir ongeschikt is voor benchmarks (verschuil je nu niet achter andere websites en Youtubers die GTA5 in hun lijstje hebben staan, zij doen hier eveneens fout aan en doen dit enkel omdat het spel veel werd gespeeld), maar de meeste spellen in zo'n lijstje moeten nieuwe spellen zijn die nu veel worden gespeeld en als het even kan spellen die ook geschikt zijn voor zo'n benchmark.
150 of 170 FPS voor een 5 jaar oud spel bij hoge/zeer hoge instellingen, /care
65 FPS of 85 FPS bij een nieuw spel bij hoge/zeer hoge instellingen, dat is relevant. Als het even kan bij alle spellen met alle Gimpworks uitgeschakeld omdat je anders niet eerlijk vergelijkt.

[ Voor 51% gewijzigd door Verwijderd op 11-02-2018 21:52 ]

[Verwijderd]

sdk1985 schreef op zaterdag 10 februari 2018 @ 01:17:
[...]

Er zit een relatie tussen de fps en de variatie. Dit heb ik bij rainbow six siege goed gemerkt. In die game neemt de benodigde rekenkracht exponentieel toe bij hogere framerates. Wanneer er volgens iets gebeurd, denk aan het inslaan van een raam of een explosie, dan kakt daardoor je framerate flink in. Pas wanneer jij framerates gaat cappen krijg je in die game rechte FRAPS plots. Met een wat lagere Mhz haal je minder fps en zijn de drop automatisch minder heftig. Op mijn 2500K wisselde de framerates tussen de 140+ en <30 fps. Op de G4560 was het veel minder een issue, die haalde gewoon minder fps.

Dat neemt niet weg dat Ryzen ook gewoon een hele stabiele FPS haalt in vergelijking met Intel, dat komt niet alleen doordat die maximale FPS niet hoger is.

Verder schijnt Nvidia zwaarder op de cpu te leunen wat verklaart waarom Intel+ Nvidia beter loopt, bij Intel heb je wat meer headroom.

Dat speelt mee maar het is niet de enige verklaring, het verklaart bijvoorbeeld niet waarom Rocket League (DX9) zo verschrikkelijk slecht (50% FPS of zo, zie de Anandtech-review die ergens tussen maart en juni 2017 uitkwam) liep op een Nvidia-GPU in combinatie met Ryzen in vergelijking met Intel. Het had (heeft?) waarschijnlijk ook met de hack van Nvidia te maken die de load herverdeelt van die ene CPU-kern die door DX11/DX9 wordt aangewezen over andere CPU-kernen. Het is niet moeilijk voor te stellen dat zo'n hack in de soep loopt wanneer het ineens met een ander type CPU moet werken.

Tot slot valt mij op dat steeds meer games echt zwaar in de AVX optimalisatie zitten. Veel meer games dan verwacht gebruiken AVX. Juist aan de AVX kant is de prestatie bij Intel gigantisch gestegen de laatste jaren. Wat dat betreft is het jammer dat je AVX niet makkelijk aan en uit kunt zetten.

Ongeacht of dat dat een probleem is voor games, dat is iets wat AMD voor Zen2 zeker moet aanpakken hebben aangepakt (Zen2 is klaar) aangezien dit een van de weinige zwaktes van Ryzen is in vergelijking met Intel. Ik begrijp nog steeds niet waarom AMD dit niet meenam voor Ryzen. Geen tijd? Bang dat het vermogen te hoog zou worden omdat ze toen nog niet wisten hoe dat uit zou vallen?
Waar leid jij uit af dat spellen zoveel AVX gebruiken?

[ Voor 3% gewijzigd door Verwijderd op 11-02-2018 06:23 ]

[Dennism]

Verwijderd schreef op zondag 11 februari 2018 @ 06:09: zij doen hier eveneens fout aan en doen dit enkel omdat het spel veel werd gespeeld), maar de meeste spellen in zo'n lijstje moeten nieuwe spellen zijn die nu veel worden gespeeld en als het even kan spellen die ook geschikt zijn voor zo'n benchmark.

Ik denk dat ze dit doen omdat het spel nog steeds veel gespeeld wordt, nu weet ik niet exact hoe betrouwbaar de Steamcharts zijn, maar het verschil tussen GTA V en andere recente AAA is vaak erg groot.

Kijk bijv. eens naar de volgende games die je wel eens in reviews ziet:

http://steamcharts.com/app/578080#3m Pubg
http://steamcharts.com/app/271590#3m GTA:V
http://steamcharts.com/app/289070#3m Civ 6
http://steamcharts.com/app/594570#3m Total War: Warhammer 2
http://steamcharts.com/app/582160#3m AS Origins
http://steamcharts.com/app/476620#3m Call of Duty WWII MP
http://steamcharts.com/app/476600#3m Call of Duty WWII SP
http://steamcharts.com/app/421020#3m Dirt 4
http://steamcharts.com/app/379720#3m Doom
http://steamcharts.com/app/435150#3m Divinity: Original Sin 2

Als die charts ook maar enigszins kloppen is Pubg duidelijk het meest gespeelde spel van deze titels op Steam, GTA:V de 2de in dit lijstje. Civ 6 haalt ook nog een top 10 notering wanneer je op de frontpage van http://steamcharts.com/ kijkt. Ik vind het dan dus, zoals ik al vaker aangegeven heb zeker niet vreemd dat Pubg of GTA:V "gewoon" gebenchmarked worden, ook zijn het matig geoptimaliseerde of "oude" titels. Voor spelers zijn dat gewoon hun dagelijks te spelen titels. Veel recente AAA titels lijken er, behalve de initiele "burst", bij release gewoon niet aan te komen en lijken ook geen "staying power" te hebben.

Nogmaals uiteraard wel als deze ook maar enigszins representatief zijn en er zijn natuurlijk ook populaire titels die niet op Steam zitten en daardoor niet zichtbaar, maar mocht dat zo zijn zou je zelfs kunnen stellen dat sommige AAA titels volgens jouw criteria maar een paar keer gebenchmarked zouden moeten worden en dan afgeserveerd, daarna worden ze immers niet "veel" meer gespeeld, dat lijkt me uiteraard ook niet handig voor de consistentie, een enigzins stabiele benchmark suite is imho ook handig. Benchmarks moeten echter imho wel nut hebben voor de mensen die ze lezen. Allemaal titels testen die "amper" (uiteraard een overdrijving) gespeeld worden heeft ook weinig zin als je de meeste populaire titels niet zou meenemen omdat deze niet geoptimaliseerd of "oud" zouden zijn.

[ Voor 6% gewijzigd door Dennism op 11-02-2018 10:22 ]

[wimjongil]

Enchantress schreef op zondag 11 februari 2018 @ 02:30:
[...]
Maar ben zeer zeker benieuwd hoe de APU gaat presteren, 2400g zou in de beurt moeten komen van de GTX 1060 max-q.

Euh nee, dat is de Vega 20/24 (van de Hades Canyon NUC).

Hier overigens de eerste resultaten! GTA V op 50fps, maar dat is blijkbaar geen goede benchmark. Niveau is ongeveer de GT1030, soms sneller, soms trager.

[sdk1985]

[quote]Verwijderd schreef op zondag 11 februari 2018 @ 06:20:
[...]

Dat neemt niet weg dat Ryzen ook gewoon een hele stabiele FPS haalt in vergelijking met Intel, dat komt niet alleen doordat die maximale FPS niet hoger is.

Dat is toch achterhaald? Ryzen haalde de stabielere FPS door de extra cores/threads. Echter die heeft Intel sinds Oktober 2017 nu ook. Dus daarmee vervalt dat voordeel. Ga je vergelijken met een 4/4t of 4c/8t dan zal Ryzen het ongetwijfeld steeds beter gaan doen. Maar de laatste tests met o.a. de 8600K en 8700K laten zien dat Coffee lake het weer net een stapje beter doet.

Ongeacht of dat dat een probleem is voor games, dat is iets wat AMD voor Zen2 zeker moet aanpakken hebben aangepakt (Zen2 is klaar) aangezien dit een van de weinige zwaktes van Ryzen is in vergelijking met Intel. Ik begrijp nog steeds niet waarom AMD dit niet meenam voor Ryzen. Geen tijd? Bang dat het vermogen te hoog zou worden omdat ze toen nog niet wisten hoe dat uit zou vallen?

Komt natuurlijk een punt dat het gewoon naar de winkel moet en het geld op is. Zen is echt een ongelofelijke stap voortuit tov alles van de laatste 5 jaar van AMD. Ze wat mij betreft beter nog wat eerder een wat minder product mogen lanceren.

Waar leid jij uit af dat spellen zoveel AVX gebruiken?

Ik heb een AVX offset in mijn overclock zitten en onder AVX loads wordt mijn multiplier anders. Ik heb altijd MSI afterburner draaien met een OSD met de Mhz, temperatuur en cpu/gpu loads.

[DaniëlWW2]

Ik wil twee dingen even gezegd hebben.

1) De APU's die morgen komen zie ik echt niet geweldig presteren in games. Gewoon nee. Als die RX560 prestaties haalt dan zou dat al heel wat zijn. Ga eerder uit van tussen de RX550 en RX560.
2) Zen ondersteunt ook gewoon AVX...

[NitroX infinity]

DaniëlWW2 schreef op zondag 11 februari 2018 @ 19:06:
Ik wil twee dingen even gezegd hebben.

1) De APU's die morgen komen zie ik echt niet geweldig presteren in games. Gewoon nee. Als die RX560 prestaties haalt dan zou dat al heel wat zijn. Ga eerder uit van tussen de RX550 en RX560.
2) Zen ondersteunt ook gewoon AVX...

De 2400G mag blij zijn als die de RX 550 benaderd, ding wordt ontzettend benadeeld door het langzame systeemgeheugen in vergelijking met GDDR5 op de RX 550 kaarten.

[horizon1978]

Sonofatech heeft stream gedaan met vroeg geleverde 2400G.
Geen geoptimaliseerde drivers.

Maar best wel goede prestaties wat ik vluchtig heb gezien.

RX560.

[DaniëlWW2]

NitroX infinity schreef op zondag 11 februari 2018 @ 19:32:
[...]

De 2400G mag blij zijn als die de RX 550 benaderd, ding wordt ontzettend benadeeld door het langzame systeemgeheugen in vergelijking met GDDR5 op de RX 550 kaarten.

Goed punt ja. Ik was de DDR4 in plaats van GDDR5 even vergeten en keek puur naar hardware specs on die.

[horizon1978]

Zelfs bij rx550 prestaties is er duidelijke meerwaarde. Zeker met prijzen van grafische kaarten... Geduld hebben met hoge settings is het idee...

[The Chosen One]

Heb tijdje terug toen ff met mijn iGPU van de 2500k gegamed, Intel HD3000?
FTL ging best, Diablo 2 (alleen in town, speel HC) SC2 relatief goed gezien ik op 1200 of 1300 resolutie met alles op ultralow.
Hier moet toch best wat mogelijk mee zijn.

[ Voor 11% gewijzigd door The Chosen One op 11-02-2018 20:04 ]

[Dennism]

DaniëlWW2 schreef op zondag 11 februari 2018 @ 19:06:
Ik wil twee dingen even gezegd hebben.

1) De APU's die morgen komen zie ik echt niet geweldig presteren in games. Gewoon nee. Als die RX560 prestaties haalt dan zou dat al heel wat zijn. Ga eerder uit van tussen de RX550 en RX560.
2) Zen ondersteunt ook gewoon AVX...

Ik ben meer benieuwd naar de prestaties van de CPU cores, voor het grafische deel hoef je het als gamer niet echt te doen, voor een simpel spelletje zal het mogelijk volstaan, net als voor andere lichte toepassingen die een beetje van een GPU profiteren en HTPC werk als ze straks HDMI 2.0 hebben.

Nee, ik ben vooral benieuwd of er op gelijke kloksnelheden winst te zien is tussen de 4 core APU's en de 4 core Ryzen chips. Daar AMD in dat interview e.d. aangaf dat dit in principe Ryzen 2 cores zijn, maar dan nog op 14NM zouden in ieder geval mogelijke IPC winsten zichtbaar kunnen zijn.

[DaniëlWW2]

Dennism schreef op zondag 11 februari 2018 @ 20:06:
[...]


Ik ben meer benieuwd naar de prestaties van de CPU cores, voor het grafische deel hoef je het als gamer niet echt te doen, voor een simpel spelletje zal het mogelijk volstaan, net als voor andere lichte toepassingen die een beetje van een GPU profiteren en HTPC werk als ze straks HDMI 2.0 hebben.

Nee, ik ben vooral benieuwd of er op gelijke kloksnelheden winst te zien is tussen de 4 core APU's en de 4 core Ryzen chips. Daar AMD in dat interview e.d. aangaf dat dit in principe Ryzen 2 cores zijn, maar dan nog op 14NM zou in ieder geval mogelijke IPC winsten zichtbaar kunnen zijn.

Ik dus ook.

[Verwijderd]

Wat lekjes. Deze jongen had het geluk te vroeg zijn 2400G te ontvangen van Amazon.
[Video: https://wccftech.com/amd-ryzen-vega-graphics-reviewer-kits-start-showing-ryzen-5-2400g-ryzen-3-2200g/]
Voor mij duurt het te lang maar als iemand zin heeft om het te bekijken...

https://wccftech.com/amd-...en-5-2400g-ryzen-3-2200g/
https://wccftech.com/amd-...rmance-leak-ahead-launch/

Twee interessante benchmarks van Hardware Unboxed.

Bij Rocket League blijkt weer dat Nvidia een probleem heeft om het spel te optimaliseren voor Ryzen en bij Wolfenstein II haalt de RX 550 bij 720p meer dan de dubbele FPS van de GTX GT 1030: 125/111 vs. 52/45 en 112/105 vs. 52/45 voor respectievelijk de Intel 8100 en bij 1080p de R3 1300X en 66/61 vs. 31/25 en 58/53 vs. 31/25. Beide resoluties met de laagste instellingen. Drie keer getest, Nvidia heeft moeite met dit spel (Vulkan).
Source-spellen haten Ryzen en AMD-kaarten maar dat was al bekend.

[ Voor 48% gewijzigd door Verwijderd op 11-02-2018 21:15 ]

[Verwijderd]

sdk1985 schreef op zondag 11 februari 2018 @ 18:13:
Dat is toch achterhaald? Ryzen haalde de stabielere FPS door de extra cores/threads. Echter die heeft Intel sinds Oktober 2017 nu ook. Dus daarmee vervalt dat voordeel. Ga je vergelijken met een 4/4t of 4c/8t dan zal Ryzen het ongetwijfeld steeds beter gaan doen. Maar de laatste tests met o.a. de 8600K en 8700K laten zien dat Coffee lake het weer net een stapje beter doet.

Ik weet niet in welke mate die stelling klopt maar Ryzen levert op een aantal prijspunten nog steeds meer kernen dan Intel en haalt daarmee nog dat voordeel (meer stabiele FPS). Hier tegenover staat natuurlijk het nadeel van een iets lagere single core performance, een iets hogere latency in sommige omstandigheden (niet bij alle omstandigheden) en dat sommige software nog niet is aangepast aan Ryzen (Source, Unreal 4...).
Zie bijvoorbeeld de 8700k vs. de 1700, Ryzen levert 8 kernen vs. 6 van Intel. Ja, snellere kernen waarbij de hogere single core performance gedeeltelijk het kleinere aantal kernen compenseert maar niet volledig, bovendien heeft de 1700 ongeveer 1,5 keer zoveel cache. Dat kan ook helpen om de FPS stabieler te houden.

Komt natuurlijk een punt dat het gewoon naar de winkel moet en het geld op is. Zen is echt een ongelofelijke stap voortuit tov alles van de laatste 5 jaar van AMD.

+ vanuit een enorme financiële achterstand en met een node die ontwikkeld was voor geheugen, dit is niets minder dan een topprestatie van de CPU-architecten. Toch is het jammer dat het net niet af is maar ik twijfel er niet aan dat ze die AVX voor Zen2 gaan aanpakken, dat en de latency wanneer iets van de ene CCX naar de andere moet.

DaniëlWW2 schreef op zondag 11 februari 2018 @ 19:06:
2) Zen ondersteunt ook gewoon AVX...

Daar ging het niet om, het ging om het feit dat ze het minder goed ondersteunen, 128 bit vs. 256 bit. Dat is een flink gat wat AMD moet overbruggen voor Zen2.

horizon1978 schreef op zondag 11 februari 2018 @ 19:49:
Zelfs bij rx550 prestaties is er duidelijke meerwaarde. Zeker met prijzen van grafische kaarten... Geduld hebben met hoge settings is het idee...

Ja, ironisch genoeg komt het AMD misschien zo goed uit dat er een crisis is voor grafische kaarten.
Normaal gesproken zou ik een APU afraden als je ook wil gamen (anders dan met emulatie van consoles ) maar nu kan je misschien net zo goed de gratis graphics erbij nemen, de iets lagere CPU-performance (Ryzen vs. Ryzen2) voor lief nemen en bij Zen 3 nog eens upgraden als de RAM en de grafische kaarten weer voor een normale prijs te kopen zijn.

[ Voor 22% gewijzigd door Verwijderd op 11-02-2018 21:29 ]