AMD Nieuwsdiscussietopic - Deel 38

[The Chosen One]

YouTube: Ryzen 7 2700X Review - Part 3: Memory Scaling + 5 Kits Tested

[ Voor 20% gewijzigd door The Chosen One op 20-05-2018 00:30 ]

[sdk1985]

Verwijderd schreef op donderdag 17 mei 2018 @ 15:40:
[afbeelding]

Het is jammer dat hij niet eveneens RAM testte met 3200 MT/s en 4,2 GHz , gezien het kleine verschil is het de vraag of dat de 2600 eveneens de 8400 zou verslaan met net iets trager RAM. Een 2600X was ook leuk geweest gezien de hogere boost. Qua prijs is het geen onlogische keuze, afhankelijk van of dat je wel of niet die stock-koeler bij de 8400 wil gebruiken.

Voor wie het niet zou weten, bij Intel is het verschil verwaarloosbaar klein als je beter RAM gebruikt, daarom testte hij voor Intel slechts met 1 RAM-klokfrequentie.

Het is vooral jammer dat er niet getest is met een 8600K. De 8400 is een stuk goedkoper en eigenlijk alleen interessant op een Z bord van o.a. Asrock (waarmee je kunt overclocken via de base frequency).

Scaling bij Intel is overigens behoorlijk aanwezig sinds Skylake. Even cherry picken (lage resolutie, specifieke game). Dit is de 8700K:


Totaal verschil is overigens inderdaad beperkt tot minder dan 4% bij lage resolutie (wat overigens goed te vergelijken is met een gpu over 3-4 jaar). Dus ja verder wel met je eens dat het niet heel schokkend is dat bij Intel niet met sneller geheugen is getest.

[ Voor 8% gewijzigd door sdk1985 op 20-05-2018 14:06 ]

[Verwijderd]

@sdk1985
11 FPS tussen 2400 en 3200 bij zo'n lage resolutie, het is weinig in vergelijking met de verschillen die je bij Ryzen ziet, daar heb je 10-20 FPS verschil tussen 2400 en 3200 bij 1080p. Zie bijvoorbeeld ook deze korte vergelijking van RedGamingTech (ongeveer halverwege de video).

Ik vind benchmarks met 1280*720 in het algemeen niet nuttig in deze tijd. Je kan het als parameter voor een indicator van CPU-performance gebruiken - met caveats (je moet niet appels met peren vergelijken, de hogere multithreadperformance is net zo'n belangrijke indicator voor hoe goed de CPU X jaar later presteert als dat de betere performance bij lage resoluties is) - maar er zijn weinig mensen die in deze tijd met een lagere resolutie dan 1920*1080 spelen.

Het is geen punt van discussie of dat je bij Intel scaling ziet, de scaling is bij Intel veel kleiner dan bij Ryzen. Dat is logisch gezien het verschil in architectuur, Ryzen is min of meer 2 CPU's op 1 PCB waarbij Intel 1 CPU op 1 PCB heeft.
Overigens moet je bij Ryzen wel de kanttekening plaatsen dat het de totale kosten van het platform verhoogt. Lager dan 3000/3200 MT/s wil je echt niet doen bij Ryzen maar met de huidige afzetterij van Samsung, Hynix en Micron geeft dat helaas wel €50-100 extra kosten.

[ Voor 23% gewijzigd door Verwijderd op 20-05-2018 14:31 ]

[Fleximex]

Hij had ook 3400/3466 moeten testen met strakke timings. Er blijkt tussen 3200 en 3466 ook nog best wat te winnen op Ryzen.

[ Voor 3% gewijzigd door Fleximex op 20-05-2018 16:19 ]

[The Chosen One]

In principe kun je dus een 4500 setje kopen (heel slecht voorbeeld ofc) en dan 100% stabiel op 3000/3200 kunnen draaien puur door de speed/timings e.d. op safe/strak te zetten?
Of kan zoiets ook gewoon nooit kunnen draaien.

[ Voor 8% gewijzigd door The Chosen One op 20-05-2018 17:41 ]

[sdk1985]

Verwijderd schreef op zondag 20 mei 2018 @ 14:25:
@sdk1985

Ik vind benchmarks met 1280*720 in het algemeen niet nuttig in deze tijd. Je kan het als parameter voor een indicator van CPU-performance gebruiken - met caveats (je moet niet appels met peren vergelijken, de hogere multithreadperformance is net zo'n belangrijke indicator voor hoe goed de CPU X jaar later presteert als dat de betere performance bij lage resoluties is) - maar er zijn weinig mensen die in deze tijd met een lagere resolutie dan 1920*1080 spelen.

Verschil tussen de twee resoluties is ongeveer 56% in die test. Dat is een prestatie toename die zeker ik nog wel verwacht te gaan zien op mijn huidige cpu platform. Mijn 2500K begon immers op een GTX 260 en eindigde op een GTX 1070. In ruwe rekenkracht zit daar factor 10 verschil tussen. Aan de gpu kant zie ik tot heden weinig reden zo pessimistisch te zijn dat die 56% niet gehaald wordt. Wat mij betreft is dus een dergelijke 720p test vooral informatief voor wie verwacht circa 5 jaar met zijn cpu platform door te willen komen (waar ik mijzelf ook onder reken).

[Verwijderd]

sdk1985 schreef op zondag 20 mei 2018 @ 17:54:
[...]

Verschil tussen de twee resoluties is ongeveer 56% in die test. Dat is een prestatie toename die zeker ik nog wel verwacht te gaan zien op mijn huidige cpu platform. Mijn 2500K begon immers op een GTX 260 en eindigde op een GTX 1070. In ruwe rekenkracht zit daar factor 10 verschil tussen. Aan de gpu kant zie ik tot heden weinig reden zo pessimistisch te zijn dat die 56% niet gehaald wordt. Wat mij betreft is dus een dergelijke 720p test vooral informatief voor wie verwacht circa 5 jaar met zijn cpu platform door te willen komen (waar ik mijzelf ook onder reken).

Ik val nu in herhaling, het is slechts een beperkte indicator aangezien daar tegenover staat dat software eveneens meer threads gaat gebruiken. Een 6c/12t Intel (dus de 8700k) vs. een 6c/12t Ryzen (dus de 2600(X)), dat kan je prima vergelijken met elkaar, daarvoor is een '720p'-test interessant. Een 6c/6t Intel vs. een 8c/16t Ryzen, daarvoor is het niet interessant aangezien je niet kan beoordelen - met zekerheid - hoe de toename van het aantal gebruikte threads opweegt tegenover de lagere singlethread-performance. Dat zijn de caveats die je moet maken wanneer je als reviewers een 720p vergelijking doet als indicator van CPU-performance, veel van die reviewers verzuimen om dat te doen om diverse redenen. Ik schat in dat spellen over een paar jaar standaard 16 threads gaan gebruiken (consoles) en dat die dan zijn afgestemd op de performance van 1 enkele core/thread bij de CPU's die in die consoles zit met de afstelling die daarvoor is gekozen. Aangezien bij consoles het vermogen laag moet zijn (hitte, klein volume, lawaai fan, prijs voeding...) ligt het voor de hand dat ze bij het programmeren uitgaan van 16 threads en 2,5-3,5 GHz. per thread. We weten zo goed als zeker dat de PS5 en de X2 (alleen gaat MS natuurlijk weer trollen met die naam ) een Ryzen-CPU gaan krijgen.

[ Voor 17% gewijzigd door Verwijderd op 20-05-2018 20:32 ]

[Sp3ci3s8472]

sdk1985 schreef op zondag 20 mei 2018 @ 17:54:
[...]

Verschil tussen de twee resoluties is ongeveer 56% in die test. Dat is een prestatie toename die zeker ik nog wel verwacht te gaan zien op mijn huidige cpu platform. Mijn 2500K begon immers op een GTX 260 en eindigde op een GTX 1070. In ruwe rekenkracht zit daar factor 10 verschil tussen. Aan de gpu kant zie ik tot heden weinig reden zo pessimistisch te zijn dat die 56% niet gehaald wordt. Wat mij betreft is dus een dergelijke 720p test vooral informatief voor wie verwacht circa 5 jaar met zijn cpu platform door te willen komen (waar ik mijzelf ook onder reken).

Ik denk tegen de tijd dat je die 0-20% (het verschil tussen AMD/Intel) op 720p gaat merken dat de meeste spellen over zijn op Vulkan of DX12 en dat je daar dus geen bottleneck meer hebt gezien Ryzen meer threads heeft. Jij doet iets van 5 jaar met je cpu, dus dat lijkt me een prima tijdlijn voor spellen om over te schakelen op de nieuwere render engines. Zelfs indies zijn dan over gezien alle grote engines het standaard ingebakken hebben.

Als je alleen wilt gamen/office, dan kan je best af met Intel. Wil je daarnaast andere dingen met je pc doen die veel cores gebruiken (VM, compilen, encoden etc...) of gamen met streamen ben je beter af met Ryzen.

[-The_Mask-]

sdk1985 schreef op zondag 20 mei 2018 @ 17:54:
[...]

Verschil tussen de twee resoluties is ongeveer 56% in die test. Dat is een prestatie toename die zeker ik nog wel verwacht te gaan zien op mijn huidige cpu platform. Mijn 2500K begon immers op een GTX 260 en eindigde op een GTX 1070. In ruwe rekenkracht zit daar factor 10 verschil tussen. Aan de gpu kant zie ik tot heden weinig reden zo pessimistisch te zijn dat die 56% niet gehaald wordt. Wat mij betreft is dus een dergelijke 720p test vooral informatief voor wie verwacht circa 5 jaar met zijn cpu platform door te willen komen (waar ik mijzelf ook onder reken).

De 720p game test is altijd al een heel slechte test geweest. Het geeft namelijk alleen weer wat de geteste games nu doen in die paar seconden die de test vaak wordt gedraaid op die resolutie.

Veel mensen staren zich al jaren blind op zulke tests, maar het geeft dus echt alleen een beeld van bovenstaande. Een zeer kort moment in de genoemde games op de genoemde lage instellingen. Zo'n test is dus ook alleen interessant voor mensen die die games spelen op zulke lage instellingen en dat zijn er vast niet veel.

Daarnaast moet je ook altijd afwachten of het gekozen moment ook een beetje representatief is voor de rest van de game, meestal ook niet namelijk. Meestal wordt er gekozen voor een moment wat het meest gemakkelijke te herhalen is, dat is logisch, maar maakt de test wel vrij nutteloos.

Hoe dan ook, als je denkt dat een 720p test realistisch is voor de komende 5 jaar dan zou ik upgraden naar een i3 8350K met snel geheugen en beide overklokken. Maar alle andere mensen kunnen beter een Ryzen 5 2600(X) nemen met ~3000MT/s geheugen voor een vergelijkbaar bedrag.

Een goede CPU test zou de games testen op de zwaarste momenten, met gebruikelijke instellingen en kijken naar frametimes. Alleen dat geeft een goede indicatie voor de games die getest worden. Niet voor toekomstige games overigens. Dat is iets waar je gewoon logisch over moet nadenken.

En omdat we bij zowel Intel als AMD nog wel iets van drie jaar met een vergelijkbare CPU architectuur en dus performance per thread zitten. Is het logisch om aan te nemen dat games alleen maar meer CPU kracht kunnen gebruiken als ze meer threads of core's gebruiken. Iets wat de laatste jaren, sinds Sandy Bridge trouwens al van toepassing is.

Sinds die tijd hebben we namelijk geen serieuze stap meer in performance per thread gehad. En sinds die tijd wordt multithread performance ook steeds belangrijker. Al zag je in het begin dat het in de Sandy Bridge tijd nog niet belangrijk was. Immers was de performance per thread elke generatie daarvoor toen nog wel een stap vooruit.

[ Voor 21% gewijzigd door -The_Mask- op 21-05-2018 10:29 ]

[DaniëlWW2]

The Chosen One schreef op zondag 20 mei 2018 @ 17:20:
In principe kun je dus een 4500 setje kopen (heel slecht voorbeeld ofc) en dan 100% stabiel op 3000/3200 kunnen draaien puur door de speed/timings e.d. op safe/strak te zetten?
Of kan zoiets ook gewoon nooit kunnen draaien.

Niet nodig. Met uitzondering van de G.Skill Sniper X zijn alle 3200MT/s+ setjes B-die. Die extreem hoge setjes zijn cherry picks die je toch nooit kan draaien op die snelheid met een gemiddelde chip. Dat geld ook voor Intel chips. Met een 2700X zou ik blij zijn als je 3600MT/s haalt of 3466MT/s met strakke timings. In principe kan je hiervoor ook een 3200MT/s C14 setje voor kopen. Die zijn niet goedkoper dan 3400MT/s C16 of 3600MT/s C17. Zijn namelijk dezelfde kwaliteit chips met lossere timings en hogere clockspeeds. Het enige dat je krijgt bij een hoger geclocked setje is het XMP profiel. Dat werkt de helft van de tijd toch niet, dus who cares?

---

Verder alweer de 720P test?
Dit komt nu al jaar terug, en elke keer is de enige logische conclusie dat het onzin is. Om maar even een voorbeeld te pakken. Neem AC Origins. Die game kan je net spelen op een quadcore in de relatief lege omgevingen. Ga je Alexandrië binnen, dan krijg je een diavoorstelling op een quadcore. Dat is je 720P test in actie. De quadcore CPU loopt gewoon 100% op alle cores en vormt een enorme bottleneck. 720P testen gaat dat nooit detecteren, zeker als je niet benchmarked op locaties waar de CPU load zwaar is. Om dat eens te demonstreren wederom een van de zeer weinige reviews die werkelijk wat zinvols heeft getest...

"Gewoon" je Titan Xp en 1080P, maar in CPU intensieve gebieden liepen de Ryzen 1600(X) al weg van de 7600K. Dat is hier de trend die al jaren bezig is, en dat is waarom je geen quadcore meer moet kopen. Dat was vorig jaar zo, en dat is dit jaar nog veel meer zo.

[sdk1985]

-The_Mask- schreef op maandag 21 mei 2018 @ 09:22:
[...]


Hoe dan ook, als je denkt dat een 720p test realistisch is voor de komende 5 jaar dan zou ik upgraden naar een i3 8350K met snel geheugen en beide overklokken. Maar alle andere mensen kunnen beter een Ryzen 5 2600(X) nemen met ~3000MT/s geheugen voor een vergelijkbaar bedrag.

Een goede CPU test zou de games testen op de zwaarste momenten, met gebruikelijke instellingen en kijken naar frametimes. Alleen dat geeft een goede indicatie voor de games die getest worden. Niet voor toekomstige games overigens. Dat is iets waar je gewoon logisch over moet nadenken.

En omdat we bij zowel Intel als AMD nog wel iets van drie jaar met een vergelijkbare CPU architectuur en dus performance per thread zitten. Is het logisch om aan te nemen dat games alleen maar meer CPU kracht kunnen gebruiken als ze meer threads of core's gebruiken. Iets wat de laatste jaren, sinds Sandy Bridge trouwens al van toepassing is.

Sinds die tijd hebben we namelijk geen serieuze stap meer in performance per thread gehad. En sinds die tijd wordt multithread performance ook steeds belangrijker. Al zag je in het begin dat het in de Sandy Bridge tijd nog niet belangrijk was. Immers was de performance per thread elke generatie daarvoor toen nog wel een stap vooruit.

Ik heb zelf reeds een 8700K .

Wat betreft Sandy Bridge, die heb ik ook nog staan. Daarbij merk je toch dat skylake in een aantal games een flink betere IPC heeft. Ik heb hier vaker het voorbeeld van Rainbow Six Siege gegeven waarbij mij G4560 betere minimum fps haalt dan mijn 2500K op 4.4+ Ghz. Dit is eigenlijk alleen te verklaren door de +- verdubbeling van de AVX prestaties. Immers de ipc per clock weegt niet op tegen de flink lagere clock (1.4 Gz minder) en het ontbreken van 2 fysieke cores. Het AVX vermoeden wordt bevestigd wordt op mijn 8700K omdat rainbow six siege daar altijd met de avx offset draait. Het sentiment dat er sinds Sandy Bridge niets is verandert klopt dus niet.

Verder was er een direct aantal games waarbij Sandy Bridge stock direct na launch niet voldoende was en je tegen een cpu bottleneck aan liep. De voor mij bekendste daarvan was F1 2010 en dan met name de Monaco track. Opmerkelijk genoeg draaide die game toen al op 80%+ core loads en was daarmee toen al opmerkelijk multithreaded. Als ik mij niet vergis zat ik toen nog op de voor die tijd niet bijzondere GTX 260.


Maar goed hoe je het ook went of keert de gouden regel bij pc hardware is dat je nooit hardware moet kopen op de gok dat het in de toekomst ineens de betere keuze wordt. Die denkfout werkt namelijk alleen maar in je eigen nadeel. Je levert op 'dit' moment prestatie in terwijl je in de toekomst maar moet afwachten wat er gebeurd. Hoe langer het duurt voor die toekomst waarheid wordt, als het al gebeurd, des te groter de kans dat je voor een prikkie kunt upgraden naar een superieur alternatief op beide vlakken.

Andere gouden regel is dat games altijd een main thread hebben die voldoende lucht moet hebben om de boel aan te sturen. De multithreaded toekomst zit er zeker aan te komen de vraag is even of de huidige generatie daar al sterk genoeg voor is. Aangezien bijvoorbeeld een 2600X, welke dicht bij zijn maximum OC zit, nu al 10 a 20% achter loopt op bijvoorbeeld een stock 8600K heb ik daar serieus mijn twijfels over wat die cpu betreft.

Combineer beiden regels en de 8600K blijft de veiligste optie. Die cpu is immers nu de onbetwiste winnaar op fps en frame times. Verder heeft hij, niet toevallig, ook de beste single threaded performance. Waar overigens ook nog veel rek in zit. Mijn 8700K met HT uit draaide stabiel op x52.

Los daarvan vind ik de 2600X een hele leuke cpu voor een leuke prijs. De nieuwe generatie loopt wellis waar feitelijk nog steeds achter, maar ze kunnen zeker mee komen. Maar ik zou mezelf daarmee niet rijk gaan rekenen. Je ziet dat de eerste Ryzen nu eigenlijk hun relevantie al volledig hebben verloren. Die konden op gaming immers helemaal niet mee komen en ik zie dat eigenlijk de komende 4 jaar niet veranderen. Ik moet de eerste game waarbij een 1800X significant sneller is dan een 8600K nog tegen komen. Voor Adobe software hoef je de 2600X ook niet te nemen, lightroom en photoshop en premiere ga je geen winsten zien, zeker niet met OC. Wat resteert is de prijs, je kiest voor een 2600X omdat een 8600K te duur voor je is. (Of omdat je heel graag een AMD cpu wil).

Of ik een 2600X in plaats van een 8400 zou aanraden vind ik lastig omdat ik een Asrock bord heb gehad waarbij base frequency overclocking perfect werkte. Maar ik heb geen 8400 getest dus of je die naar 5 Ghz kunt krijgen weet ik niet. Je kunt het proberen en anders terug sturen...

Een quadcore zou ik zelf overigens ook niet snel aanraden, dat is niet nodig binnen het huidige aanbod.

[ Voor 23% gewijzigd door sdk1985 op 21-05-2018 12:18 ]

[Verwijderd]

Volgens mij is dat AC Unity.
Crysis 3 is een nog mooier voorbeeld waarbij de 1600 gehakt maakt van de 7600k maar ACO laat vooral goed zien hoe erg je FPS-getallen met een korrel zout moet nemen aangezien het zo sterk afhangt van het stuk in het spel waarin die zijn gemeten. Is er veel extra werk die door andere threads kan worden uitgevoerd (NPC's bijvoorbeeld) dan wint de trage 6c/12t het ruimschoots van de snelle 4c/4t, is het een stuk waarbij vooral plaatjes worden getekend en wordt DX11 gebruikt dan wint de snelle 4c/4t het. Dan toch beter die trage 6c/12t aangezien de zwakste momenten in het spel het meest bepalen hoe lekker het speelt. Liever die 10% achterstand in delen en nergens een grote dip dan die 10% voorsprong in delen en regelmatig een grote dip. Van Assassin's Creed Origins is bekend dat zelfs de 7700k het niet redt in delen van het spel (rond de 30 FPS).

Als je voor Intel kiest, kies dan de 8700k of wacht op die 8c waarvan ik verwacht dat die €400-450 gaat kosten. Go big or go home.

[ Voor 9% gewijzigd door Verwijderd op 21-05-2018 12:00 ]

[sdk1985]

Verwijderd schreef op maandag 21 mei 2018 @ 11:55:
Volgens mij is dat AC Unity.
Crysis 3 is een nog mooier voorbeeld waarbij de 1600 gehakt maakt van de 7600k maar ACO laat vooral goed zien hoe erg je FPS-getallen met een korrel zout moet nemen aangezien het zo sterk afhangt van het stuk in het spel waarin die zijn gemeten. Is er veel extra werk die door andere threads kan worden uitgevoerd (NPC's bijvoorbeeld) dan wint de trage 6c/12t het ruimschoots van de snelle 4c/4t, is het een stuk waarbij vooral plaatjes worden getekend en wordt DX11 gebruikt dan wint de snelle 4c/4t het. Dan toch beter die trage 6c/12t aangezien de zwakste momenten in het spel het meest bepalen hoe lekker het speelt. Liever die 10% achterstand in delen en nergens een grote dip dan die 10% voorsprong in delen en regelmatig een grote dip. Van Assassin's Creed Origins is bekend dat zelfs de 7700k het niet redt in delen van het spel (rond de 30 FPS).

Als je voor Intel kiest, kies dan de 8700k of wacht op die 8c waarvan ik verwacht dat die €400-450 gaat kosten. Go big or go home.

Ik denk niet dat hier iemand is die een quadcore gaat aanraden. The mask was niet serieus in zijn advies om voor een 8350K te gaan. Maar we gaan offtopic want het is stiekem niet het advies topic hier, doe ik zelf ook fout .

[ Voor 3% gewijzigd door sdk1985 op 21-05-2018 12:20 ]

[The Chosen One]

DaniëlWW2 schreef op maandag 21 mei 2018 @ 11:44:
[...]
Niet nodig. Met uitzondering van de G.Skill Sniper X zijn alle 3200MT/s+ setjes B-die. Die extreem hoge setjes zijn cherry picks die je toch nooit kan draaien op die snelheid met een gemiddelde chip. Dat geld ook voor Intel chips. Met een 2700X zou ik blij zijn als je 3600MT/s haalt of 3466MT/s met strakke timings. In principe kan je hiervoor ook een 3200MT/s C14 setje voor kopen. Die zijn niet goedkoper dan 3400MT/s C16 of 3600MT/s C17. Zijn namelijk dezelfde kwaliteit chips met lossere timings en hogere clockspeeds. Het enige dat je krijgt bij een hoger geclocked setje is het XMP profiel. Dat werkt de helft van de tijd toch niet, dus who cares?

Nee ofcourse niet maar gewoon puur theoretisch gezien bedoel ik. Kun je een bijv. 4500/5000 (adata?) setje op 3200 100% stabiel laten draaien. Onzin om daadwerkelijk te doen natuurlijk. Maar is zoiets mogelijk met ram?
Heb zelf al een 3600 setje, alleen nog op 1 ding uit Amerika wachten dan bestel ik de rest bij Azerty/sicomputers.

@Verwijderd Nee dat bedoel ik niet, of een 5000 setje omlaag zetten naar 3*** theoretisch mogelijk is. Dat dat niet slim is om te doen is ff een 2e, en 3e, en 4e. ;p

-

Quadcore is alleen nog aan te raden als je een 7700k/set voor 150-200 totaal kunt kopen of zo met budget limiet. Dus niet nieuw/los.

[ Voor 11% gewijzigd door The Chosen One op 21-05-2018 13:59 ]

[DaniëlWW2]

The Chosen One schreef op maandag 21 mei 2018 @ 12:20:
Nee ofcourse niet maar gewoon puur theoretisch gezien bedoel ik. Kun je een bijv. 4500/5000 (adata?) setje op 3200 100% stabiel laten draaien. Onzin om daadwerkelijk te doen natuurlijk. Maar is zoiets mogelijk met ram?
Heb zelf al een 3600 setje, alleen nog op 1 ding uit Amerika wachten dan bestel ik de rest bij Azerty/sicomputers.

Natuurlijk kan dat. Gewoon je XMP profiel selecteren en handmatig 3200 invoeren en booten. Je timings zijn dan zo slecht dat het meteen zal werken.

[Verwijderd]

sdk1985 schreef op maandag 21 mei 2018 @ 12:19:
[...]

Ik denk niet dat hier iemand is die een quadcore gaat aanraden.

Nu niet meer maar ik herinner mij van vorig jaar dat veel mensen nog beweerden dat de 7700k de betere keuze was dan een 6c/12t Ryzen. Ik doel nu niet specifiek op iemand of een paar mensen, je zag het internationaal. Pas nadat CL uitkwam gingen mensen aanvaarden dat de quadcore outdated is, de becnhmarks die lieten zien dat zelfs de 7600k en 7700k worstelen bij sommige spellen (op bepaalde momenten in het spel) hielpen hierbij.

Maar we gaan offtopic want het is stiekem niet het advies topic hier, doe ik zelf ook fout .

Er is voorlopig geen AMD-nieuws dus dat lijkt me voor nu niet zo'n probleem.

The Chosen One schreef op maandag 21 mei 2018 @ 12:20:
[...]


Nee ofcourse niet maar gewoon puur theoretisch gezien bedoel ik. Kun je een bijv. 4500/5000 (adata?) setje op 3200 100% stabiel laten draaien.

Nee! 36** MT/s lijkt het maximum te zijn voor Ryzen2, uiteraard afhankelijk van allerlei loterijen. Rond de 3800 MT/s lukt normaal gesproken niet (8 uur lang een RAM-test draaien of iets dergelijks). 36** of 34** met hele strakke timings is het beste wat je kunt doen qua RAM bij Ryzen2 en dit haal je als je goede latjes hebt en je geen pech hebt met de memorycontroller.

@CHBF Nee dat bedoel ik niet, of een 5000 setje omlaag zetten naar 3*** theoretisch mogelijk is.

Natuurlijk kan dat. Handmatig de klokfrequentie verlagen en de timings strakker zetten. In het algemeen is het zinloos (met de huidige DDR4) om snellere RAM dan 3600 MT/s te kopen, qua performance heb je meer aan 3600 MT/s met hele strakke timings dan 4000 MT/s of 'sneller' met losse timings. Buildzoid (hij is een competitieve overklokker) had hier het een en ander over uitgelegd, je kan dat gemakkelijk vinden, 3600 MT/s met strakke timings is het beste qua performance wat op de markt is, bij snellere RAM gaat het teveel ten koste van die timings.

[ Voor 77% gewijzigd door Verwijderd op 21-05-2018 14:06 ]

[Werelds]

sdk1985 schreef op maandag 21 mei 2018 @ 11:53:
Dit is eigenlijk alleen te verklaren door de +- verdubbeling van de AVX prestaties.

G4560 ondersteunt AVX niet. Geen enkele Celeron of Pentium doet dat. AVX en AVX2 vind je alleen in processors onder de "Core" noemers.

Dus nee, dat is het niet

Daarnaast overschat jij het gebruik en nut van AVX enorm voor games. Bij mijn weten is er geen enkele game engine die AVX gebruikt voor core rendering taken (zie hieronder). Zowel PhysX als Havok maken wel gebruik van AVX (indien aanwezig) voor enkele dingen. Cloth bijvoorbeeld. Maar ook dat is nauwelijks het geval in R6:S.

Sterker nog, AVX zou voor engines zelfs averechts werken, omdat de AVX pipeline "exclusief" is. Zodra die pipeline z'n werk moet doen vreet dat zo veel stroom dat de CPU ook echt even 100% daar op focust; vandaar ook dat AVX offsets nodig zijn, omdat je anders met langdurige 100% belasting op de betrokken pipelines het ding vrij rap naar z'n limieten trekt. De paar gevallen waar AVX wél vrij veel gebruikt wordt, doen dat met expliciete codepaths en dat is meestal voor physics. pCARS deed dat - of ze het nog steeds doen weet ik niet. Kijk voor de gein eens naar Epyc vs Skylake-EP; laatstgenoemde is op papier sneller met AVX en met kortdurig gebruik is dat ook zo, maar in de praktijk zie je dat AMD dat gevecht met gemak wint omdat ze niet zo hard hoeven te throttlen. Hetzelfde is in mindere mate waar voor Ryzen/Kaby.

Dat jouw 8700K op de AVX offset draait in R6:S zegt ook helemaal niets over of die game bewust AVX gebruikt, laat staan veelvuldig. Alle gangbare compilers (GCC, ICC, MSVC) hebben ingebakken optimalisaties die automatisch vector instructies (SSE, AVX) gebruiken indien aanwezig, echter gaat het dan over kleine optimalisaties - en die optimalisaties kun je ook uitschakelen. Zodra er echter een AVX instructie wordt gebruikt dan schakelt de offset in. Het hoeft er echt slechts één in een batch te zijn.

Dus zitten er AVX instructies in R6:S? Vast wel.

Is dat de reden dat jouw G4560 hogere minima haalt dan je 2500K? Absoluut niet, aangezien eerstgenoemde überhaupt geen AVX ondersteunt - eerder het omgekeerde, jouw 2500K throttled wellicht als een malle

En haalt R6:S bakken performance uit AVX? Absoluut niet, omdat AVX een hoop beperkingen op de CPU legt.

[sdk1985]

Werelds schreef op maandag 21 mei 2018 @ 14:13:
[...]

G4560 ondersteunt AVX niet. Geen enkele Celeron of Pentium doet dat. AVX en AVX2 vind je alleen in processors onder de "Core" noemers.

Dus nee, dat is het niet

Daarnaast overschat jij het gebruik en nut van AVX enorm voor games. Bij mijn weten is er geen enkele game engine die AVX gebruikt voor core rendering taken (zie hieronder). Zowel PhysX als Havok maken wel gebruik van AVX (indien aanwezig) voor enkele dingen. Cloth bijvoorbeeld. Maar ook dat is nauwelijks het geval in R6:S.

Sterker nog, AVX zou voor engines zelfs averechts werken, omdat de AVX pipeline "exclusief" is. Zodra die pipeline z'n werk moet doen vreet dat zo veel stroom dat de CPU ook echt even 100% daar op focust; vandaar ook dat AVX offsets nodig zijn, omdat je anders met langdurige 100% belasting op de betrokken pipelines het ding vrij rap naar z'n limieten trekt. De paar gevallen waar AVX wél vrij veel gebruikt wordt, doen dat met expliciete codepaths en dat is meestal voor physics. pCARS deed dat - of ze het nog steeds doen weet ik niet. Kijk voor de gein eens naar Epyc vs Skylake-EP; laatstgenoemde is op papier sneller met AVX en met kortdurig gebruik is dat ook zo, maar in de praktijk zie je dat AMD dat gevecht met gemak wint omdat ze niet zo hard hoeven te throttlen. Hetzelfde is in mindere mate waar voor Ryzen/Kaby.

Dat jouw 8700K op de AVX offset draait in R6:S zegt ook helemaal niets over of die game bewust AVX gebruikt, laat staan veelvuldig. Alle gangbare compilers (GCC, ICC, MSVC) hebben ingebakken optimalisaties die automatisch vector instructies (SSE, AVX) gebruiken indien aanwezig, echter gaat het dan over kleine optimalisaties - en die optimalisaties kun je ook uitschakelen. Zodra er echter een AVX instructie wordt gebruikt dan schakelt de offset in. Het hoeft er echt slechts één in een batch te zijn.

Dus zitten er AVX instructies in R6:S? Vast wel.

Is dat de reden dat jouw G4560 hogere minima haalt dan je 2500K? Absoluut niet, aangezien eerstgenoemde überhaupt geen AVX ondersteunt - eerder het omgekeerde, jouw 2500K throttled wellicht als een malle

En haalt R6:S bakken performance uit AVX? Absoluut niet, omdat AVX een hoop beperkingen op de CPU legt.

Net gechecked en er zit volgens cpu-z inderdaad helemaal geen AVX in de G4560. Dus dan kan de verklaring voor de betere performance van skylake in die game inderdaad absoluut niet in AVX worden gezocht. Sterker nog, de lijst van extensions tussen de 2500K en de G4560 is identiek. Resteert nog wel de verklaring waarom die game dan zoveel beter op skylake draait.

De 2500K zelf kan ik niets aan ontdekken. Die wordt niet warmer dan 66 graden met prime95 (idle 40) en als je een synthetic draait dan scoort hij goed. Sterker nog hij zit zelfs in het 100e percentiel op http://www.userbenchmark.com/UserRun/5512397 .

Verder heeft een maatje van me de stock 3570K en ook hij liep in die game tegen 100% cpu belasting op. Toevallig deze week zijn cpu even op x40 gezet en ook toen had hij slechtere minimum fps dan mijn G4560. Videokaarten waren op dat moment redelijk gelijkwaardig (GTX 660 Ti op de G4560 en een GTX 670 op de 3570K).

Dat bij elkaar doet mij toch vermoeden dat er iets zit in skylake waardoor die game beter draait.

Bovenstaande heeft betrekking op de ingebouwde benchmark die wellicht niet heel representatief is. Maar heb vorig jaar ook gameplay opgenomen met FRAPS. Nog even ter illustraite hoe slecht die game op sandy (en dus ook ivy) draait:



Op de 8700K geen last (de streep daar de killcam):


Zou wellicht wel leuk zijn om iemand met een 1600X/2600X ook even FRAPS te laten draaien in terrorist hunt. Zien we meteen hoeveel beter dan Sandy/Ivy het dan is.

[ Voor 6% gewijzigd door sdk1985 op 21-05-2018 14:55 ]

[Werelds]

sdk1985 schreef op maandag 21 mei 2018 @ 14:45:
[...]
Net gechecked en er zit volgens cpu-z inderdaad helemaal geen AVX in de G4560. Dus dan kan de verklaring voor de betere performance van skylake in die game inderdaad absoluut niet in AVX worden gezocht. Sterker nog, de lijst van extensions tussen de 2500K en de G4560 is identiek. Resteert nog wel de verklaring waarom die game dan zoveel beter op skylake draait.

Niet geheel identiek hoor: https://ark.intel.com/compare/97143,52210

2500K heeft AVX wél

Dat bij elkaar doet mij toch vermoeden dat er iets zit in skylake waardoor die game beter draait.

Nog even ter illustraite hoe slecht die game op sandy (en dus ook ivy) draait:

[afbeelding]

R6:S is een raar spel - ze hebben niet voor niets meerdere performance patches gedaan omdat hun spel zo raar overal op reageerde

Een 8400 doet het ook beter dan een 8700K. Het spel is ook 100% CPU-limited totdat je op 2160p zit te spelen. Met andere woorden: throttling en de manier waarop een driver gebruik maakt van de CPU is waardoor je die verschillen ziet.

In jouw geval zijn je benchmarks niet te vergelijken:
- De één heeft een FPS cap, de ander niet (FPS cap beperkt ook de CPU limit, waardoor je minima hoger uit kunnen vallen)
- De één op themepark, de ander op kafe (online sessies? even gegoogled en dat zijn blijkbaar namen van de maps )
- De één loopt 4m46,1 - de ander slechts 2m44,4

Edit: ah, een edit

Die capped grafiek was dus ook van je 2500K. Het hoe en wat is lastig te vergelijken tenzij beide op dezelfde driver versie etc. waren - en de maps/omstandigheden blijven ook belangrijk.

[ Voor 6% gewijzigd door Werelds op 21-05-2018 15:04 ]

[sdk1985]

Werelds schreef op maandag 21 mei 2018 @ 15:00:
[...]

Niet geheel identiek hoor: https://ark.intel.com/compare/97143,52210

2500K heeft AVX wél


[...]

R6:S is een raar spel - ze hebben niet voor niets meerdere performance patches gedaan omdat hun spel zo raar overal op reageerde

Een 8400 doet het ook beter dan een 8700K. Het spel is ook 100% CPU-limited totdat je op 2160p zit te spelen. Met andere woorden: throttling en de manier waarop een driver gebruik maakt van de CPU is waardoor je die verschillen ziet.

In jouw geval zijn je benchmarks niet te vergelijken:
- De één heeft een FPS cap, de ander niet (FPS cap beperkt ook de CPU limit, waardoor je minima hoger uit kunnen vallen)
- De één op themepark, de ander op kafe (online sessies? even gegoogled en dat zijn blijkbaar namen van de maps )
- De één loopt 4m46,1 - de ander slechts 2m44,4

Haha maar even herschrijven dit...

Dat het niet duidelijk is, is duidelijk. In de basis liep ik tegen een probleem aan op mijn oude systeem en dat was dat mijn rainbow six siege zoveel haperde dat ik niemand dood kreeg. Daar komt de eerste figuur in beeld. Immers het bleek dat een hogere framerate een dermate hoge overhead had dat het afgaan van een granaat of het intikken van een raampje ervoor kon zorgen dat je een halve seconde geen updates kreeg.

Dus even los van de map zie je op de 2500K dat het cappen van je fps altijd tot een flinke versmalling van de bandbreedte van je frame leidt. Verder inderdaad volkomen illustratief, andere games, andere tegenstanders, andere maps. Maar je moet maar even van mij aannemen dat het geen placebo effect is. Op elke map is het verschil even significant.

Dan de tweede figuur. Ik was nog altijd niet tevreden met de dips (40ms) dus toen heb ik de 8700K aangeschaft. Ik heb toen drie dagen later dezelfde GTX 1070 in de 8700K gegooid en ben ook daarmee gaan frapsen. Deze keer heb ik mijzelf beperkt tot terrorist hunt. Die modus is net wat zwaarder en kun je lekker snel doen (40seconde voor je dood bent). Dat leverde een verschil van dag en nacht op. Verder zie je dat zelfs met de 8700K het cappen nog altijd enige nut heeft.

Dat alles is puur voor mijn eigen spelplezier en niet om een review van te bouwen of iets dergelijks. Qua 'wetenschappelijk onderzoek' heb ik overigens wel met elke processor en framecap de ingebouwde benchmark gedaan. Persoonlijk vind ik die echter minder inzichtelijk de figuren die ik heb gedeeld. Daar zie je namelijk alleen de minimum, gemiddelde en maximum framerate.

Hoe dan ook is het bij deze game ook een kwestie van een niet te snelle videokaart hebben. Ik test zojuist de 2500K opnieuw met de ingebouwde benchmark. Die 2500K heeft nu een tragere 660 Ti en daar haal ik nu uncapped een minimum fps van 63.1. Daarmee is de prestatie vergelijkbaar met de G4560. Met de GTX 1070 knal je veel dieper omlaag. Getuige mijn eigen 8700K. Ik doe net de test even opnieuw en vandaag haalt die 15.4 min, 157 avg, 304 max.

Dus even heel kort door de bocht getallen uit de ingebouwde benchmark:
G4400 met GTX 660 Ti = 30 minimum
G4560 met GTX 660 Ti = 60 minimum
2500K OC met 660 Ti = 63 minimum
2500K OC met 1070 = <10 minimum
8700K met 1070 = 15 minimum (147 gemiddeld, 304 max)
8700K met 1070 / 120cap = 98 minimum (119,9 gemiddeld, 155 max)

Waarbij het dus het meest opmerkelijke is dat je met die 2500K rond de 4.4 Ghz nodig hebt om het niveau van de G4560 te evenaren. Onder de 4 Ghz hoef je het echt niet te proberen.

[ Voor 89% gewijzigd door sdk1985 op 21-05-2018 15:59 . Reden: opnieuw geschreven ]

[Sp3ci3s8472]

sdk1985 schreef op maandag 21 mei 2018 @ 11:53:
[...]

Ik heb zelf reeds een 8700K .

Wat betreft Sandy Bridge, die heb ik ook nog staan. Daarbij merk je toch dat skylake in een aantal games een flink betere IPC heeft. Ik heb hier vaker het voorbeeld van Rainbow Six Siege gegeven waarbij mij G4560 betere minimum fps haalt dan mijn 2500K op 4.4+ Ghz. Dit is eigenlijk alleen te verklaren door de +- verdubbeling van de AVX prestaties. Immers de ipc per clock weegt niet op tegen de flink lagere clock (1.4 Gz minder) en het ontbreken van 2 fysieke cores. Het AVX vermoeden wordt bevestigd wordt op mijn 8700K omdat rainbow six siege daar altijd met de avx offset draait. Het sentiment dat er sinds Sandy Bridge niets is verandert klopt dus niet.

Wat voor geheugen gebruik je? Had laatst gelezen dat de 2500k zeker op 4.8Ghz een behoorlijke bandbreedte limiet heeft.
Grote kans dat dat meer meespeelt dan dat cpus daadwerkelijk zoveel sneller is geworden.

Edit:
Ik zie dat je 1600 hebt. Als je naar 2133 c9 zou gaan is daar best nog wat te halen.

[ Voor 4% gewijzigd door Sp3ci3s8472 op 21-05-2018 16:48 ]

[sdk1985]

Sp3ci3s8472 schreef op maandag 21 mei 2018 @ 16:44:
[...]


Wat voor geheugen gebruik je? Had laatst gelezen dat de 2500k zeker op 4.8Ghz een behoorlijke bandbreedte limiet heeft.
Grote kans dat dat meer meespeelt dan dat cpus daadwerkelijk zoveel sneller is geworden.

Edit:
Ik zie dat je 1600 hebt. Als je naar 2133 c9 zou gaan is daar best nog wat te halen.

Zit 1 stapje boven stock inderdaad. G4560 zit op DDR4 2400 Mhz, ook 1 stapje erboven. Memory bandwidth niet aan gedacht, goede suggestie. Mocht ik mij vervelen dan kan ik de 2400 Mhz DDR4 weleens terug clocken en dan de 660 Ti weer bij de G4560 stoppen en kijken wat er gebeurd. Sneller ddr3 heb ik immers niet zomaar, maar het DDR4 vertragen is vrij eenvoudig.

[ Voor 5% gewijzigd door sdk1985 op 21-05-2018 22:48 ]

[Blaat]

Allemaal leuk jongens maar dit is het AMD nieuws discussie topic. Niet het vergelijk Sandy Bridge met Skylake topic.

[Help!!!!]

https://nl.hardware.info/...tel-amd-en-arm-processors

Nieuwe spectre bug gevonden. Benieuwd wat de impact van mitigerende maatregel bij AMD is.

De intel oplossing waarbij ze de patch standaard uit laten staan in BIOS ivm de grote performancehit vind ik overigens niet ok. Hopelijk gaat AMD dit pad niet volgen.

AMD heeft aangegeven microcode en patches uit te rollen, maar geeft niet aan wat voor impact op performance dat gaat hebben.

Intel heeft ook al microcode beschikbaar gesteld aan oem's om zich tegen het risico te weren, met een iets grotere performance impact van 2 tot 8 procent. Vanwege deze impact heeft Intel echter besloten om de optie standaard uit te laten staan, waardoor gebruikers van kritieke systemen zelf in de bios de patch moeten aanzetten.

[Dennism]

Help!!!! schreef op dinsdag 22 mei 2018 @ 10:24:
https://nl.hardware.info/...tel-amd-en-arm-processors

Nieuwe spectre bug gevonden. Benieuwd wat de impact van mitigerende maatregel bij AMD is.

De intel oplossing waarbij ze de patch standaard uit laten staan in BIOS ivm de grote performancehit vind ik overigens niet ok. Hopelijk gaat AMD dit pad niet volgen.


[...]

AMD doet exact hetzelfde als Intel, fix zal ook daar standaard niet aan staan. Te vinden op https://www.amd.com/en/corporate/security-updates

Edit: Denk trouwens dat jij een eerste versie van dat artikel quote, HWI heeft er wat anders staan nu.

Fabrikanten: de reacties van Arm, Intel en AMD
Arm heeft al laten weten de veelgebruikte Cortex-A57, -A72, -A73 en -A75 cpu-kernen getroffen zijn door v4. Er is per direct firmware beschikbaar die het probleem migreert met een performance impact van 1 tot 2% bij de meeste workloads. In juli moeten er nieuwe versies van de A72, A73 en A75 kernen uitkomen die resistent zijn tegen variant 2, en Cortex-A75 wordt ook resistent gemaakt tegen v3, ook bekend als Meltdown.

Intel heeft ook al microcode beschikbaar gesteld aan oem's om zich tegen het risico te weren, met een iets grotere performance impact van 2 tot 8 procent. Vanwege deze impact heeft Intel echter besloten om de optie standaard uit te laten staan, waardoor gebruikers van kritieke systemen zelf in de bios de patch moeten aanzetten.

AMD heeft aangegeven microcode en patches uit te rollen, maar geeft niet aan wat voor impact op performance dat gaat hebben. Net als Intel zal het de patches standaard uitgeschakeld laten, omdat het risico op misbruik erg klein is.

[ Voor 48% gewijzigd door Dennism op 22-05-2018 11:46 ]

[DaniëlWW2]

Nergens in die security blog van AMD, geeft AMD aan dat ze patches die ze aanbrengen via microcode, standaard uit zetten...

[Dennism]

DaniëlWW2 schreef op dinsdag 22 mei 2018 @ 12:00:
Nergens in die security blog van AMD, geeft AMD aan dat ze patches die ze aanbrengen via microcode, standaard uit zetten...

Voor zover ik het begrepen heb door snel even de whitepaper te lezen die gelinkt is in dat artikel geven ze dit aan in de volgende zin in de Blog.

Based on the difficulty to exploit the vulnerability, AMD and our ecosystem partners currently recommend using the default setting that maintains support for memory disambiguation.

Die default setting zou betekenen fix niet geactiveerd, non-default setting fix wel geactiveerd. Zie ook de onderstaande uitleg van Red Hat waarin te zien is dat Memory Disambiguation on = Spectre V4 fix off.

Mitigation
Red Hat recommends customers apply the microcode/firmware update provided by your hardware or CPU vendor and also install these updated kernels as soon as possible. Software updates can be applied independently from the hardware microcode, but will not take effect until the CPU firmware has been updated. ​

Customers are advised to take a risk-based approach in mitigating this issue. Systems that require high degrees of security and trust should be addressed first, and should be isolated from untrusted systems until such time as treatments can be applied to those systems to reduce the risk of exploitation.

x86 processors from Intel and AMD offer Model Specific Registers(MSRs) which can be used to enable/disable the Speculative Store Bypass function. Using these MSRs, the new kernel updates offer the following kernel command line parameters:

spec_store_bypass_disable=[auto/on/off/prctl]
default: auto
auto: when booting with this option, the kernel detects if the processor supports the Speculative Store Bypass(SSB) function, and selects appropriate mitigation.
on: It turns the Speculative Store Bypass mitigation ON. The processor will not speculatively execute load(read) instructions, before all store(write) addresses are resolved.
off: It turns the Speculative Store Bypass mitigation OFF. The processor will use the memory disambiguator function to speculatively execute load(read) instructions before earlier store(write) instructions.
prctl: It enables the Speculative Store Bypass mitigation on a per-thread basis using the prctl(2) interface.
nospec_store_bypass_disable:
Disable all mitigations for the Speculative Store Bypass vulnerability.

[ Voor 57% gewijzigd door Dennism op 22-05-2018 12:48 ]

[Verwijderd]

Er is nu een extra aanwijzing (maar geen bewijs!) dat de PS5 een Zen-CPU krijgt.
https://www.phoronix.com/...y-LLVM-Ryzen-Improvements

One of Sony's compiler experts has taken to working on some tuning for the AMD Ryzen "znver1" microarchitecture support within the LLVM compiler stack. This begs the question why Sony is working on Ryzen improvements if not for a future product.

Sony's Simon Pilgrim has been recently investing time in the "znver1" AMD first-generation Zen CPU support within LLVM. Simon has been a programmer for Sony for the past decade. His LinkedIn reveals that indeed at Sony he's working on compiler tooling for the PlayStation devices:
...
But let's not forget that the PlayStation 4 is powered by a semi-custom AMD Jaguar CPU with GCN Radeon graphics. On top of that, Sony indeed uses LLVM/Clang as the compiler for the PlayStation 4. In fact, they contributed the PS4 support to upstream LLVM and have dealt with the upstream LLVM compiler community over the years.
...

Het punt lijkt te zijn dat ze er nu best wel intensief aan werken.
Hier kan je wat van zijn werk zien.
https://github.com/llvm-m...af3a06d63b63cda41243e1325
https://github.com/llvm-m...85e25fb5dadf26db3ad1d9e25
https://github.com/llvm-m...e3d63adc1daa815d69d00f9b0

Help!!!! schreef op dinsdag 22 mei 2018 @ 10:24:
De intel oplossing waarbij ze de patch standaard uit laten staan in BIOS ivm de grote performancehit vind ik overigens niet ok. Hopelijk gaat AMD dit pad niet volgen.

Ik ben het met jou eens dat dit standaard aan hoort te staan. Voor de meeste gebruikers is het niet erg om een paar procent tot 10% performance-verlies te hebben maar de mindere veiligheid is wel een concreet probleem. Het gaat hierbij vooral om het beschermen van n00bs die niet eens weten wat een BIOS is en hoe ze daarin komen (wat overigens wordt verërgerd door OEM's die het nodig vinden om niet te melden hoe je in de BIOS komt ).

[ Voor 43% gewijzigd door Verwijderd op 22-05-2018 12:47 ]

[Dennism]

Verwijderd schreef op dinsdag 22 mei 2018 @ 12:39:
Het gaat hierbij vooral om het beschermen van n00bs die niet eens weten wat een BIOS is en hoe ze daarin komen (wat overigens wordt verërgerd door OEM's die het nodig vinden om niet te melden hoe je in de BIOS komt ).

Staat dat niet op zo'n beetje ieder boot scherm? Volgens mij staat er altijd wel iets als Press F10 for Setup of iets van die strekking. Ik ken iig geen OEM die de Uefi / bios bewust niet vermelden tijdens het booten of in de documentatie.

[Verwijderd]

Dennism schreef op dinsdag 22 mei 2018 @ 12:53:
[...]


Staat dat niet op zo'n beetje ieder boot scherm? Volgens mij staat er altijd wel iets als Press F10 for Setup of iets van die strekking.

Je zou het denken maar nee.
Acer heeft het uitgeschakeld. Ik heb een laptop van Acer, je ziet daar enkel het logo op en je mag opzoeken met welke knop je het boot-menu of de BIOS laadt. Sterker nog, als je een ander besturingssysteem wil starten, zelfs via een live-USB, dan moet je eerst in een menu van de BIOS een wachtwoord invoeren alvorens je in een ander menu van de BIOS Safeboot uit te kunnen schakelen, tot die tijd is die optie 'greyed out'.
Tijd voor een Nederlands woord hiervoor!

Volgens mij stond er bij die laptop ook niets vermeld in de documentatie, niet in de papieren die je erbij kreeg. Er stond weinig informatie vermeld in de handleiding. Ik heb er echter niet erg aandachtig naar gekeken aangezien ik het niet de moeite waard vond na er vluchtig naar te hebben gekeken en te hebben besloten dat ik daar niets aan zou gaan hebben. Het is erg dun (een paar bladzijdes op een klein formaat), het is erg op n00bs gericht en er staat weinig zinvolle informatie in. "Eerst batterij opladen blablabla"

[ Voor 6% gewijzigd door Verwijderd op 22-05-2018 22:11 ]

[Dennism]

Verwijderd schreef op dinsdag 22 mei 2018 @ 13:10:
[...]

Je zou het denken maar nee.
Acer heeft het uitgeschakeld.

Ohja, die bestaan ook nog Ik werk eigenlijk alleen met HP, IBM en Dell wat client machines betreft

Ik heb een laptop van Acer, je ziet daar enkel het logo op en je mag opzoeken met welke knop je het boot-menu of de BIOS laadt. Sterker nog, als je een ander besturingssysteem wil starten, zelfs via een live-USB, dan moet je eerst in een menu van de BIOS een wachtwoord invoeren alvorens je in een ander menu van de bios Safeboot uit te kunnen schakelen, tot die tijd is die optie 'greyed out'.
Tijd voor een Nederlands woord hiervoor!

Opzich logisch, een distro die een signed bootloader gebruikt moet dat ook oplossen trouwens.

[Paprika]

Verwijderd schreef op zondag 20 mei 2018 @ 20:28:
[...]
Aangezien bij consoles het vermogen laag moet zijn (hitte, klein volume, lawaai fan, prijs voeding...) ligt het voor de hand dat ze bij het programmeren uitgaan van 16 threads en 2,5-3,5 GHz. per thread. We weten zo goed als zeker dat de PS5 en de X2 (alleen gaat MS natuurlijk weer trollen met die naam ) een Ryzen-CPU gaan krijgen.

Van de 8 cores in de huidige lineup (2013) merk je amper iets. Sterker nog, zelfs de PS3 en Xbox 360 hadden meerdere threads (al dan niet gesimuleerd) en daar merkte je weinig van. Iedere keer zie je toch dat de huidige mainstream hardware op de desktop de meeste impact heeft op game ontwikkelaars. Daarnaast is gameload verdelen over 16 threads behoorlijk lastig. Je zult toch je data moeten syncen en daar zit de bottleneck. Vandaag de dag is daar gewoon geen echte oplossing voor en sterker nog, de Zen architectuur is zelfs in het nadeel in het scenario dat je al die threads gaat gebruiken en iedere frame alles weer bij elkaar moet komen.

16 threads op een dergelijke snelheid zou overigens een reusachtige stap zijn t.o.v. de huidige lineup. Een verdubbeling in threads, core snelheid en een veel betere IPC. Niet onmogelijk dus, maar het zou wel zo z'n impact hebben op de industrie.

[ Voor 13% gewijzigd door Paprika op 22-05-2018 13:28 ]

[Dennism]

Ik vind 16 threads, zeker bij 2.5 - 3.5Ghz nogal wat, zeker daar ze voor zover ik begrijp console cpu's rond de 30W maximaal verbruik willen hebben. de 4C/8T Intel en AMD laptop parts gaan daar tijdens boost al overheen, en die halen dan net zulke frequenties, ik zou eerder 6C/12T verwachten en misschien zelfs wel 4C/8T

[sdk1985]

Kwam trouwens een geinig channel tegen:

Valt bij de laatste op dat de 2700X toch iets te zwak blijft. Je ziet bijvoorbeeld in The Witcher wat microstutter terwijl de gpu load van de 8700K dan op 96% draait terwijl de 2700X op 79% blijft hangen. Even later zie je beide kanten 98% gpu weergeven. Dus de 2700X gaat wat slechter met het zware moment om. Dit is getest met een GTX 1080. Over 1-3 jaar zullen de effecten wat verder dramatiseren.

Verder zie ik dat de i3 duidelijk achter blijf top de 2600, de i3 stutter veel vaker en heftiger. Dit was wel te verwachten maar is toch even bevestigd...

[ Voor 12% gewijzigd door sdk1985 op 22-05-2018 14:59 ]

[madmaxnl]

Kijk vooral niet naar de processor belasting... Over 1-3 jaar blijft een 8700K achter bij een 2700X.

De yields en clocks lijken me ook niet helemaal appels met appels.

De kans op 5GHz stabiele 8700K lijkt mij kleiner dan de kans op een 4,3GHz stabiele 2700X:
https://www.reddit.com/r/.../?st=jhhqai7j&sh=5458a74f

Daarnaast is er geen informatie over de kloksnelheid van het RAM geheugen. Dat kan een aardig verschil opleveren aldus diezelfde youtube channel:

Soms zie ik verschillen van 20%, maar goed ik ben geen lopende rekenmachine dus wat het gemiddeld scheelt geen idee.

YouTube: 2400Mhz vs 3600Mhz RAM Test in 8 Games (Ryzen 5 2600)

[ Voor 80% gewijzigd door madmaxnl op 22-05-2018 15:57 ]

[sdk1985]

madmaxnl schreef op dinsdag 22 mei 2018 @ 15:28:
Kijk vooral niet naar de processor belasting... Over 1-3 jaar blijft een 8700K achter bij een 2700X.

Dat dachten de kopers van een Q6600 ook. Maar tegen de tijd dat dit bij trok had je de veel snellere i7 920 (en de goedkopere 875K) die zowel beter was als de Q6600 als de E6700/E6750 en de latere E8400.

Bij Far Cry 5 zie je dat de 2700X de gpu ook niet vol krijgt, de cpu hangt dan op slechts 17%. Dat is geen toeval, de game hangt daar op single threaded performance. Fc5 is een 'AMD game' dus wie weetkomt er nog een optimalisatie patch, echter de 8700K daadwerkelijk voorbij streven zie ik niet gebeuren. Maar goed in software kan in theorie alles .

Qua games die nog moeten uitkomen is het erg koffiedik kijken. Tot heden zie ik zelf echter geen enkel teken dat we ineens een shift naar DX12/Vulkan krijgen. Daarnaast zien we ook dat in veel gevallen DX12 ook niet betekend dat je met een Nvidia kaart verbetering ziet. In Civ V doet DX12 bijvoorbeeld niets en in Battlefield 1 kost het performance. In die hoek hoef je het niet te zoeken en mid-range boeit het allemaal uberhaupt niet (gpu limited). Dus dan moet je er op gokken dat AMD binnen 1 tot 3 jaar terug is in high-end met een 'betaalbare' kaart én dat de games massaal gebruik gaan maken van DX12 en Vulkan. In beide afhankelijkheden heb ik zelf een hard hoofd...

[ Voor 6% gewijzigd door sdk1985 op 22-05-2018 16:01 ]

[madmaxnl]

sdk1985 schreef op dinsdag 22 mei 2018 @ 15:56:
[...]

Dat dachten de kopers van een Q6600 ook. Maar tegen de tijd dat dit bij trok had je de veel snellere i7 920 (en de goedkopere 875K) die zowel beter was als de Q6600 als de E6700/E6750 en de latere E8400.

En de FX-8150, FX-8350 vs de 2500K dan?

Het is heel simpel, is er één thread 100% terwijl er nog andere threads staan te sufkutten dan is het alles behalve geoptimaliseerd. In de toekomst gaan CPUs nog veel meer threads krijgen. Dan gaan developers er niet meer komen met één thread in het honderd terwijl de rest op 10% zit.

[sdk1985]

madmaxnl schreef op dinsdag 22 mei 2018 @ 16:03:
[...]


En de FX-8150, FX-8350 vs de 2500K dan?

Dat wint de 2500K, zeker met overclocks naar 4.6-4.8. Er zijn er niet veel die het testen, dit is uit 2017 met een i5 2400 (3.1 GHz...) vs 8350 op 4.0 GHz. De i5 wint, aldus de youtuber. YouTube: FX 8350 vs i5 2400 in 2017 | Which One You Should Have Bought 5 Year... Super betrouwbaar? Nee. Maar het geeft wel een indicatie dat de 8350 nu ineens niet magisch sneller is.

Het is heel simpel, is er één thread 100% terwijl er nog andere threads staan te sufkutten dan is het alles behalve geoptimaliseerd. In de toekomst gaan CPUs nog veel meer threads krijgen. Dan gaan developers er niet meer komen met één thread in het honderd terwijl de rest op 10% zit.

Daar ligt een taak voor de gameontwikkelaars om heel creatief te zijn want al jaren worden games opgesplitst in 20+ threads maar daarvan zijn er vaak 19 een stuk minder zwaar dan die ene. Bij de resource monitor (taakbeheer>prestatie>bron controle) kun je het aantal threads zien AFAIK. Bij GTAV stond er 28 als ik me niet vergis.

[DaniëlWW2]

Paprika schreef op dinsdag 22 mei 2018 @ 13:22:
[...]

Van de 8 cores in de huidige lineup (2013) merk je amper iets. Sterker nog, zelfs de PS3 en Xbox 360 hadden meerdere threads (al dan niet gesimuleerd) en daar merkte je weinig van. Iedere keer zie je toch dat de huidige mainstream hardware op de desktop de meeste impact heeft op game ontwikkelaars. Daarnaast is gameload verdelen over 16 threads behoorlijk lastig. Je zult toch je data moeten syncen en daar zit de bottleneck. Vandaag de dag is daar gewoon geen echte oplossing voor en sterker nog, de Zen architectuur is zelfs in het nadeel in het scenario dat je al die threads gaat gebruiken en iedere frame alles weer bij elkaar moet komen.

16 threads op een dergelijke snelheid zou overigens een reusachtige stap zijn t.o.v. de huidige lineup. Een verdubbeling in threads, core snelheid en een veel betere IPC. Niet onmogelijk dus, maar het zou wel zo z'n impact hebben op de industrie.

Tja, maar zowel de PS4 als de XBONE draaien op Jaguar. IPC verschil met Zen is maar iets van 70 a 80%. Is de clockspeed ook nog eens de helft van een Zen CPU voor de originele modellen, en iets hoger voor de geüpdatet modellen. Volgens mij kan je dus de berekeningen voor die acht cores, vrij gemakkelijk met twee desktop cores uitvoeren. Dat schiet natuurlijk niet op nee.

Qua GPU is het natuurlijk veel beter gesteld. De PS4 Pro heeft eigenlijk een Polaris 10 met 2xFP16. De XBONE X heeft een GPU die echt niet mis gestaan had in een mainstream systeem. 40CU, (eigenlijk 44CU maar vier staan uit) 384bit bus, 12GB GDDR5. Was waarschijnlijk een prachtige GTX1070 tegenhanger geweest als die chip ook was uitgebracht als dGPU. Natuurlijk loopt die voor geen ene meter in een console zonder extreme optimalisaties, maar daarom hebben consoles allang low level acces.

Ik zag trouwens ook dat deze tweede generatie op "16nm" word gebakken. Dat is dus TSMC waardoor er potentieel een boute bedrag verbonden zit aan AMD hun SoC verkopen aan Sony en MS.

---

Verder heb ik altijd begrepen dat als je eenmaal een zekere mate van parallellisatie introduceert in software, dat de moeilijkheid om extra threads aan te spreken eigenlijk verdwijnen. Dat is iets dat we de afgelopen drie jaar ook steeds meer zien in games. Het hek is van de dam qua aantal threads dat een game pakt. Gaan games eenmaal over vier heen, dan pakken ze al snel gewoon minstens 16 threads. Dat is tenminste het gedrag dat ik constant zie met games. De oudere stoppen vaak bij twee of vier, de nieuwere gooien een paar procent load op de meest threads. Natuurlijk doen de DX12 titels het helemaal goed met een goede verdeling over 16 threads.

Ik ben het dus niet helemaal met je eens dat het geen effect heeft. Een port van een game zal al snel flink wat threads aanspreken. Het is alleen zinloos omdat de game waarschijnlijk perfect draait op twee threads met console niveau instellingen, mits goed geoptimaliseerd. Het zou je vervolgens wel kunnen helpen als je ver voorbij console niveau instellingen gaat en bijvoorbeeld veel zwaardere physics effecten gaat draaien. Als die dan lekker op een andere core worden afgeschoven, dan helpt dat op PC.

---

Ik denk dat ook wel duidelijk is dat Sony bij AMD blijft voor de PS5. Van MS verwacht ik hetzelfde als ze nog mee blijven doen met XBOX. Omdat games in het algemeen op x86 CPU's draaien, zullen die ook nog wel even blijven als standaard voor de consoles. Vervolgens is AMD dan onverslaanbaar als leverancier van je primaire rekeneenheden. Alleen AMD kan zowel een CPU als GPU leveren, en dit doen ze voor het juist bedrag ook nog eens als een custom SoC. Voor de toekomstige consoles kan je zoiets als een Zen + Vega based SoC verwachten met waarschijnlijk GDDR6 voor zowel systeem als videogeheugen. Je werkt toch niet met sockets, dus je kan dit allemaal op een PCB zetten met geringe latency's.

De vraag zal eerder zijn of het op GoFlo 12nm of 7nm gebakken zal worden, of toch een TSMC node als AMD geen boete hoeft te betalen aan GoFlo.

[ Voor 3% gewijzigd door DaniëlWW2 op 22-05-2018 17:18 ]

[Paprika]

Welke game('s) hebben we het dan over (16 threads)? Zitten daar ook games bij die niet in de groep strategie en/of simulatie vallen?

[ Voor 44% gewijzigd door Paprika op 22-05-2018 17:42 ]

[Sp3ci3s8472]

sdk1985 schreef op dinsdag 22 mei 2018 @ 14:49:
Kwam trouwens een geinig channel tegen:
[video]
[video]
[video]


Valt bij de laatste op dat de 2700X toch iets te zwak blijft. Je ziet bijvoorbeeld in The Witcher wat microstutter terwijl de gpu load van de 8700K dan op 96% draait terwijl de 2700X op 79% blijft hangen. Even later zie je beide kanten 98% gpu weergeven. Dus de 2700X gaat wat slechter met het zware moment om. Dit is getest met een GTX 1080. Over 1-3 jaar zullen de effecten wat verder dramatiseren.

Verder zie ik dat de i3 duidelijk achter blijf top de 2600, de i3 stutter veel vaker en heftiger. Dit was wel te verwachten maar is toch even bevestigd...

Die settings in de spellen zijn erg random gekozen. Totaal niet logisch, je gaat bij een cpu test niet ineens mesh detail op het laagste niveau zetten en andere gpu bound dingen weer op high.
Laat ik het zo stellen dat ik niet precies de waarde van deze testen inzie.

Over 1-3 jaar zullen de effecten minder zijn, tenzij je DX11 gaat gebruiken en 200fps verwacht.

Wat is het punt wat je precies probeert te maken? Het begint offtopic te raken. Zowel Intel als AMD hebben goede cpu's om op te gamen, je gaat daar niet de komende paar jaar een bottleneck zien waar dat met de FX series wel het geval was naar mijn mening.
Zolang je een cpu koopt met meer dan 8 threads dan zit je goed, hoewel 6 echte cores met of zonder MT een betere keuze is.

[DaniëlWW2]

Paprika schreef op dinsdag 22 mei 2018 @ 17:39:
Welke game('s) hebben we het dan over (16 threads)? Zitten daar ook games bij die niet in de groep strategie en/of simulatie vallen?

Games zoals AC Unity, AC Origins of the Witcher 3 heb ik het zelf ruimschoots kunnen ervaren. Unity ben ik al eens op ingegaan met de 60%+ load op alle 16 threads. En dan vroegen mensen zich af waarom het niet draaide op een quadcore.

Verder kan je natuurlijk BF1 aandragen, of the Division, of Crysis 3 als een zeer vroeg voorbeeld van een game die flink wat threads gebruikt, er er ook daadwerkelijk baad bij heeft. Die game haat quadcores. GTA 5 is ook een leuke die gewoon 16 threads kan aanspreken. Dit kan je ook allemaal online vinden.

Zie bijvoorbeeld:
YouTube: Ryzen 1700 vs i7 7700K | An Unbiased Look at Benchmarks

Ik kan heel lang doorgaan hoor. Er zijn maar weinig games uitgebracht de afgelopen jaren die niet enorm doorschalen met extra threads. Uitzonderingen zijn bijvoorbeeld HOI4 en City Skylikes, die dus voor geen ene meter draaien.

[Paprika]

Voornamelijk AI/simulatie gedreven zo te lezen dan. Voor de mainstream Fortniter/PUBGer/LoLer/Dotaer/CSGOer/WoWer dus niet relevant... . Een echt kip-ei verhaal. Mainstream games hebben 't niet nodig dus liever 'n snelle Intel -> meeste mensen hebben een quad core dus we moeten daar op focussen.

Wel slecht van Skylines. Daar zou 't makkelijk moeten kunnen.

[ Voor 93% gewijzigd door Paprika op 22-05-2018 19:07 ]

[DaniëlWW2]

Paprika schreef op dinsdag 22 mei 2018 @ 18:57:
Voornamelijk AI/simulatie gedreven zo te lezen dan. Voor de mainstream Fortniter/PUBGer/LoLer/Dotaer/CSGOer/WoWer dus niet relevant... . Een echt kip-ei verhaal. Mainstream games hebben 't niet nodig dus liever 'n snelle Intel -> meeste mensen hebben een quad core dus we moeten daar op focussen.

Wel slecht van Skylines. Daar zou 't makkelijk moeten kunnen.

Ik zou juist willen beargumenteren dat Fortniter/PUBGer/LoLer/Dotaer/CSGOer/WoWer juist een specifiek genre van games zijn. Deze draaien allemaal op een aardappel @3GHz dus relevant voor benchmarking zijn ze eigenlijk ook niet.

Daarnaast zijn er nog een aantal genres aan mainstream games. Die vragen in steeds grotere mate om flink wat CPU, en in steeds grotere mate is de quadcore daar niet meer voldoende voor. Daarin varieert het van lagere gemiddelde tot enorme framedrops.

Als we het dan over simulaties hebben, dan zou ik graag ArmA 3 aan willen dragen als het ultieme voorbeeld dat simulatie games niet per definitie gebruik maken van veel threads.

Verder is Paradox een beetje bijzonder omdat ze het concept van multithreading maar niet lijken te begrijpen. Met een 7700K @5GHz en een GTX1080Ti haal je in City Skylines alsnog geen stabiele 60fps.

[ Voor 6% gewijzigd door DaniëlWW2 op 22-05-2018 19:30 ]

[Verwijderd]

Paprika schreef op dinsdag 22 mei 2018 @ 13:22:
Van de 8 cores in de huidige lineup (2013) merk je amper iets.

8 kernen die onderdoen voor een middelmatige quadcore van Intel of Ryzen vs. 8 serieuze kernen op 3-3,5 GHz. en SMT , dat is nogal een verschil! De performance zou minstens 2-3 keer zo hoog worden en qua vermogen is het ook prima te doen. Of dat het gebeurt moeten we afwachten maar wat zou dat toch de gaming kunnen verbeteren als developers er op een goede manier gebruik van leren maken. Tot nu toe hadden ze de hardware niet, hopelijk durft Sony het aan om wel met die hardware te komen en de developers de kans te geven om het te leren gebruiken.

16 threads op een dergelijke snelheid zou overigens een reusachtige stap zijn t.o.v. de huidige lineup. Een verdubbeling in threads, core snelheid en een veel betere IPC. Niet onmogelijk dus, maar het zou wel zo z'n impact hebben op de industrie.

Qua kosten zou het zeker mogelijk zijn, de vraag is of dat Sony de noodzaak ziet om die hardware te kopen. Zelfs 6c/12t zou al geweldig zijn in vergelijking met wat ze nu hebben. Ik denk dat je dan ook nog wel de factor 2 haalt.

Dennism schreef op dinsdag 22 mei 2018 @ 13:15:
[...]


Ohja, die bestaan ook nog Ik werk eigenlijk alleen met HP, IBM en Dell wat client machines betreft

offtopic:
Ze zijn het goedkoopst en ik stel weinig eisen aan laptops.
- 4c/8t check (al is het wat laag geklokt met 3,5/3,8 GHz)
- SSD check
- HD IPS check
- basic graphics

Naar het schijnt zijn ze goed genoeg en zijn ze tegenwoordig minder fragiel dan vroeger. Ik heb nog geen problemen gemerkt met ventilatie maar ik moet afwachten hoe dat over een jaar gaat zijn. De fan gaat enkel aan bij een serieuze CPU-load, niet bij licht gebruik (browser, video), dat is in ieder geval positief (minder snel stofophoping).
Voor mij is een laptop 100% een utility, ik gebruik het niet om te gamen en ik gebruik het niet voor multimedia, zware performance voor andere taken heb ik slechts af en toe nodig.

[quote]Opzich logisch, een distro die een signed bootloader gebruikt moet dat ook oplossen trouwens.
[/quote]
Ik probeerde Ubuntu 18.04 Mate uit op de laptop. ik kreeg enkel het desktopscherm te zien, geen knopjes of menu of zo. Op de desktop was het geen probleem en na het uitschakelen van de safe boot op de laptop was het ook geen probleem. Ik ben op zoek naar een goede Linux-distro voor op de laptop. Misschien iets met budgie? Kwestie van dat het voor productiviteit wel handig is als Windows niet de hele tijd lastig valt met updates (of Acer met idiote meldingen over batterijperformance 'verbeteren' ).
Ik gebruik dat ding thuis vaak dagenlang niet, zo gauw j het aanzet heb je weer dat update-gedoe, daar krijg ik het van op[ mijn heupen voordat je wat gedaan krijgt. Elke week zijn er wel weer nieuwe updates die het afsluiten en opstarten flink vertragen.
Het zou fijn zijn als MS (idem voor Mozilla overigens!) beveiliginsupdates zou loskoppelen van andere updates waar de meeste gebruikers niet op zitten te wachten. If something ain't broken...

[ Voor 35% gewijzigd door Verwijderd op 22-05-2018 19:45 ]

[Dennism]

DaniëlWW2 schreef op dinsdag 22 mei 2018 @ 19:28:


Ik zou juist willen beargumenteren dat Fortniter/PUBGer/LoLer/Dotaer/CSGOer/WoWer juist een specifiek genre van games zijn. Deze draaien allemaal op een aardappel @3GHz dus relevant voor benchmarking zijn ze eigenlijk ook niet.

Als je dat van een game als WoW zegt, kan je dat van iedere game wel zeggen Iedere game kan je dan bij wijze van spreken draaien op eein tosti ijzer. Ook WoW inderdaad, dat solo prima speelbaar is op lage settings op een tosti ijzer.

Ga je echter kijken naar hjigh end is er geen machine die WoW zal draaien in mythic raids op 1080P @ 60FPS+ zonder dips op de hoogste settings.

Nu is WoW imho inderdaad niet echt relevant voor benchmarks, omdat je alleen zaken kan benchen die geen performance nodig hebben en inderdaad op een tosti ijzer ook soepel draaien.

Echter denk ik dat over het algemeen de relevantie van die titels er wel is in benchmarks, zo hebben volgens mij bijv. pubg en fortnite bijv. ook aardig pittige hardware nodig om op hoge settings in hogere resolutie te spelen maar daarnaast ook de speler aantallen. Juist de populariteit van dat soort games maakt ze wat mij betreft relevant voor benchmarks. Als ik bijv. een systeem wil kopen om Pubg of fortnite spelen op 4K of 1440P en / of in 144Hz zijn juist die games om het algemeen imho een stuk relevanter dan AAA titels van EA/Ubisoft die even enigzins populair zijn maar vaak kort daarna nog maar door anderhalve man en een paar spreekwoordelijke paardekop gespeeld worden.

Verwijderd schreef op dinsdag 22 mei 2018 @ 19:33:


Qua kosten zou het zeker mogelijk zijn, de vraag is of dat Sony de noodzaak ziet om die hardware te kopen. Zelfs 6c/12t zou al geweldig zijn in vergelijking met wat ze nu hebben. Ik denk dat je dan ook nog wel de factor 2 haalt.

Ik denk dat dit mogelijk nog wel lastig is, ik meen ergens gelezen te hebben dat de bulk prijs die MS betaald heeft tussen de $100 en $75 heeft gezeten voor de One, One S en One X (start van de verkoop en de prijs later na de die-shrink en betere yields) en Sony voor de PS4 en PS4 Pro ook zo rond de $100, mogelijk ook hier wat minder na een tijdje met betere yields.

Het lijkt me toch vrij lastig om een 8C/16T + een Vega GPU voordat budget in een SoC te stoppen.

[ Voor 20% gewijzigd door Dennism op 22-05-2018 20:09 ]

[Verwijderd]

PUBG zouden ze natuurlijk nooit moeten gebruiken als indicator voor hoe een CPU/GPU presteert (waarmee ik niet zeg dat het niet gebenchmarkt mag worden, dat is een ander verhaal), hooguit is het interessant om te weten of hardware X voor dat ene spelletje goed werkt maar het probleem zit veel meer in de prutsers van PUBG dan in de hardware.
Met respect, het zal vast niet gemakkelijk zijn maar we kunnen objectief vaststellen dat andere developers beter werk leveren qua optimalisatie. Zo bijzonder is PUBG niet in veel opzichten (voor de CPU zou het niet zwaarder dan bijvoorbeeld GTA5 moeten zijn en qua graphics is het niet bijzonder) en toch draait het gigantisch slecht.

Dennism schreef op dinsdag 22 mei 2018 @ 19:58:
Ik denk dat dit mogelijk nog wel lastig is, ik meen ergens gelezen te hebben dat de bulk prijs die MS betaald heeft tussen de $100 en $75 heeft gezeten voor de One, One S en One X (start van de verkoop en de prijs later na de die-shrink en betere yields) en Sony voor de PS4 en PS4 Pro ook zo rond de $100, mogelijk ook hier wat minder na een tijdje met betere yields.

Zijn de productiekosten van Ryzen zoveel hoger? De node is aanzienlijk kleiner, de yields zijn prima en naar het schijnt zou je een volle 16c/32t voor ongeveer $100 produceren, het lijkt me aannemelijk dat de kosten voor een 8c/16t minder dan de helft bedragen dan die van de 16c/32t (toch weer een paar extra stappen waarbij er wat mis kan gaan) waarmee de kosten voor een 8c/16t niet boven de $50 zouden moeten liggen. Dan heb je natuurlijk wel alleen nog maar de CPU. Geen idee wat de GPU zou kosten.
Tegen de tijd dat dat spul uitkomt is het alweer een jaar later (eind 2019?), hopelijk zijn de productiekosten tegen die tijd laag genoeg dat het mogelijk is. Op zich interesseren consoles mij niet (ik heb een hekel aan vendor lock-in) maar voor de PC-gamers zou het echter wel leuk zijn als PC-gaming wat minder wordt afgeremd door die consoles.

Ik weet niet hoe het met jou zit, ik zou maar wat graag zien dat de CPU eens wat meer prioriteit zou krijgen, desnoods ten koste van de GPU. Die graphics zitten al op een redelijk hoog niveau, de CPU zit nog op niveau 0.
Een gebrekkige benutting van de CPU haalt je veel meer uit het spel dan het relatief kleine verschil in graphics. Het zou ook mooi zijn als developers eens betere algorithmen zouden ontwikkelen voor de PC (of andere voldoende krachtige CPU's). Maak maar eens een opties-menu zoals voor de graphics gebeurt.

Nog even over Acer, ze hebben nog steeds niemand in dienst die fatsoenlijk Engels beheerst. Bij een eerdere computer stond er bij het startscherm "no any devices found". In de BIOS van mijn laptop (Copyright Acer Inc.) staat er "Otherwise, touchpad will be no function". Dat kan toch niet bij zo'n groot bedrijf, een doorsnee 3-VMBO-leerling beheerst beter Engels dan de persoon die dit intypt voor de BIOS.

Edit
Als je denkt dat het niet gekker kan. Ik had als experiment van UEFI naar BIOS geschakeld, dan meldt de computer (BIOS?): "no bootable device" (ook herstart en het nog een keer geprobeerd). Daarna weer terug op UEFI gezet en het boot wel weer. What the fuck?
Er staat in de BIOS aangegeven dat UEFI wordt aanbevolen omdat Microsoft "dat aanbeveelt om de nieuwe features van Windows8 en hoger te gebruiken" maar blijkbaar is het niet eens mogelijk om via legacy BIOS te starten ondanks dat het als optie te selecteren is in de UEFI.
Het lijkt erop dat de fout voor dit probleem bij Microsoft ligt en niet bij Acer.
https://docs.microsoft.co...-mode-or-legacy-bios-mode

[ Voor 55% gewijzigd door Verwijderd op 22-05-2018 22:52 ]

[sdk1985]

Sp3ci3s8472 schreef op dinsdag 22 mei 2018 @ 18:05:
[...]


Die settings in de spellen zijn erg random gekozen. Totaal niet logisch, je gaat bij een cpu test niet ineens mesh detail op het laagste niveau zetten en andere gpu bound dingen weer op high.
Laat ik het zo stellen dat ik niet precies de waarde van deze testen inzie.

Over 1-3 jaar zullen de effecten minder zijn, tenzij je DX11 gaat gebruiken en 200fps verwacht.

Wat is het punt wat je precies probeert te maken? Het begint offtopic te raken. Zowel Intel als AMD hebben goede cpu's om op te gamen, je gaat daar niet de komende paar jaar een bottleneck zien waar dat met de FX series wel het geval was naar mijn mening.
Zolang je een cpu koopt met meer dan 8 threads dan zit je goed, hoewel 6 echte cores met of zonder MT een betere keuze is.

Nieuwswaarde is dat die video's inzichtelijk maken hoe de diverse cpu's nu draaien (tijdje na launch), verder illustreerde hij ook mooi de quad vs 6core en zat er als kers op de taart ook nog antwoord op de grote vraag, hoe doet het beste van Intel (8700K 5 GHz) het tegen het beste van AMD (2700X 4.3 GHz).


Op het channel staat trouwens ook nog een video over 4,6,8 cores icm far cry 5.


Verder verwacht ik zelf dat er deze zomer nog wel een 1180 gaat komen (en een 1170) en ik gok weer op +35% indexatie waarde (tpu grafiekje, niet relatief maar aftrekken) en ik vrees dat de stock cpu's dan al door de mand gaan vallen. Je ziet immers nu al dips in gpu load veroorzaakt door tekorten aan cpu kracht in de bovenstaande runs.

[Sp3ci3s8472]

sdk1985 schreef op dinsdag 22 mei 2018 @ 23:17:
[...]

Nieuwswaarde is dat die video's inzichtelijk maken hoe de diverse cpu's nu draaien (tijdje na launch), verder illustreerde hij ook mooi de quad vs 6core en zat er als kers op de taart ook nog antwoord op de grote vraag, hoe doet het beste van Intel (8700K 5 GHz) het tegen het beste van AMD (2700X 4.3 GHz).


Op het channel staat trouwens ook nog een video over 4,6,8 cores icm far cry 5.


Verder verwacht ik zelf dat er deze zomer nog wel een 1180 gaat komen (en een 1170) en ik gok weer op +35% indexatie waarde (tpu grafiekje, niet relatief maar aftrekken) en ik vrees dat de stock cpu's dan al door de mand gaan vallen. Je ziet immers nu al dips in gpu load veroorzaakt door tekorten aan cpu kracht in de bovenstaande runs.

Niet iedereen speelt op 720p/1080p (zeker niet met een 1080 lijkt me), die resoluties kan je ook prima af met een RX 580/GTX1060.

Zodra er mooie schermen zijn ga ik naar een UWQHD scherm. Op die resolutie is een cpu limitatie de komende jaren geen probleem. Het is vrijwel zeker dat je eerder met een quadcore tegen een limitatie gaat aanlopen dan met een andere cpu, dat zie je nu al met Assasins Creed, dat gat zal alleen maar groter worden.

[Dennism]

Verwijderd schreef op dinsdag 22 mei 2018 @ 21:58:

Als je denkt dat het niet gekker kan. Ik had als experiment van UEFI naar BIOS geschakeld, dan meldt de computer (BIOS?): "no bootable device" (ook herstart en het nog een keer geprobeerd). Daarna weer terug op UEFI gezet en het boot wel weer. What the fuck?
Er staat in de BIOS aangegeven dat UEFI wordt aanbevolen omdat Microsoft "dat aanbeveelt om de nieuwe features van Windows8 en hoger te gebruiken" maar blijkbaar is het niet eens mogelijk om via legacy BIOS te starten ondanks dat het als optie te selecteren is in de UEFI.
Het lijkt erop dat de fout voor dit probleem bij Microsoft ligt en niet bij Acer.
https://docs.microsoft.co...-mode-or-legacy-bios-mode

Volgens mij is ook dat compleet logisch, ik heb iig nog geen machines gezien die "zomaar" kunnen wisselen tussen Uefi en Bios.. Even snel uit mijn hoofd maakt Uefi gebruik van GPT en Bios van MBR en hebben ze beide verschillende bootloaders. Je kiest dan voor de installatie van je OS of je wil gaan installeren met Bios support of met Uefi support (volgens mij zijn er wel wat tools die een bestaande installatie kunnen converteren, ik heb ze echter nog nooit gebruikt). Zomaar Uefi uitzetten en bios aanzetten heb ik in ieder geval nog nooit zien werken.

[Verwijderd]

Dennism schreef op dinsdag 22 mei 2018 @ 13:53:
Ik vind 16 threads, zeker bij 2.5 - 3.5Ghz nogal wat, zeker daar ze voor zover ik begrijp console cpu's rond de 30W maximaal verbruik willen hebben.

Hier komt die weer, van The Stilt.

Zoals je ziet is 2,9 GHz. mogelijk met 30W. Dit hangt natuurlijk wat af van de specifieke load maar het geeft een goede indicatie. Bedenk hierbij dat dit de GF '14 nm'. is en niet hun '12 nm' die iets zuiniger is. Mogelijk is het tegen die tijd weer zuiniger en in theorie zouden ze zelfs GF/TSMC 7 nm. kunnen gebruiken (bij Polaris wachtte AMD niet lang met dat te verkopen aan Sony en MS).
Maar goed, laten we ons ajb. niet blindstaren op die 30 W. Er is geen goede reden dat 65 W niet zou kunnen en dan kan je zelfs 3,7 GH.z halen. Ik weet dat het een traditie is dat consolebakjes zo klein mogelijk zijn en een slechte voeding en koeling hebben maar daar kan iets aan worden gedaan, Maak het iets groter (hoger vooral), stop er een goede heatsink en 140 mm. fans in en een iets minder prutserige voeding. Zoveel maakt het niet uit voor de kosten.

ik zou eerder 6C/12T verwachten en misschien zelfs wel 4C/8T

4c/8t zou teleurstellend zijn voor ons PC-gamers. Zijn we eindelijk door AMD verlost van de quadcore CPU's nadat Intel jarenlang hun monopolie misbruikte en dan zitten we alsnog een volle generatie consoles (of 2, in ieder geval een periode van minstens 6 jaar, de PS4 is er al sinds eind 2013) vast aan quadcore CPU's tenzij developers eindelijk eens apare algorithmes ontwikkelen voor de PC.
6C zou kunnen maar dan zou AMD ofwel 2 goede kernen weggooien ofwel aardig wat beschadigende stukken hebben. We weten dat het laatste niet het geval is. AMD zou natuurlijk 2 kernen kunnen utischakelen om het vermogen lager te houden maar daar wordt niemand vrolijk van, behalve misschien de managers van Sony en MS.

[ Voor 6% gewijzigd door Verwijderd op 23-05-2018 18:36 ]

[roy-t]

DaniëlWW2 schreef op maandag 21 mei 2018 @ 11:44:
[...]


Niet nodig. Met uitzondering van de G.Skill Sniper X zijn alle 3200MT/s+ setjes B-die. Die extreem hoge setjes zijn cherry picks die je toch nooit kan draaien op die snelheid met een gemiddelde chip. Dat geld ook voor Intel chips. Met een 2700X zou ik blij zijn als je 3600MT/s haalt of 3466MT/s met strakke timings. In principe kan je hiervoor ook een 3200MT/s C14 setje voor kopen. Die zijn niet goedkoper dan 3400MT/s C16 of 3600MT/s C17. Zijn namelijk dezelfde kwaliteit chips met lossere timings en hogere clockspeeds. Het enige dat je krijgt bij een hoger geclocked setje is het XMP profiel. Dat werkt de helft van de tijd toch niet, dus who cares?

---

Verder alweer de 720P test?
Dit komt nu al jaar terug, en elke keer is de enige logische conclusie dat het onzin is. Om maar even een voorbeeld te pakken. Neem AC Origins. Die game kan je net spelen op een quadcore in de relatief lege omgevingen. Ga je Alexandrië binnen, dan krijg je een diavoorstelling op een quadcore. Dat is je 720P test in actie. De quadcore CPU loopt gewoon 100% op alle cores en vormt een enorme bottleneck. 720P testen gaat dat nooit detecteren, zeker als je niet benchmarked op locaties waar de CPU load zwaar is. Om dat eens te demonstreren wederom een van de zeer weinige reviews die werkelijk wat zinvols heeft getest...

[video]

"Gewoon" je Titan Xp en 1080P, maar in CPU intensieve gebieden liepen de Ryzen 1600(X) al weg van de 7600K. Dat is hier de trend die al jaren bezig is, en dat is waarom je geen quadcore meer moet kopen. Dat was vorig jaar zo, en dat is dit jaar nog veel meer zo.

Als (ex) game developer snap ik dit argument niet. Op hogere resoluties moet vooral de GPU meer werk doen. De physics, AI, e.d. en het voorbereiden van de data voor de GPU veranderen niet significant qua werk. Dus op een hogere resolutie wordt hoe dan ook de GPU de bottleneck. Op een lagere resolutie zie je dus veel beter de impact die de CPU echt heeft.

Het voorbeeld wat je geeft zou je dus juist moeten detecteren op 720p als de CPU echt de bottleneck is. Immers zal in dit geval de GPU je niet limiteren.

Een TItan XP op 1080p draaien is natuurlijk ook niet snel de bottleneck. Maar op 720p is je GTX960 dat ook niet meer. Zelfde test voor je CPU eigenlijk. . Een games tests voor CPUs, waarbij (een core van) de CPU de 100% niet aantikt is eigenlijk geen goede CPU test. Immers houd iets anders dan de prestaties tegen.


Er wordt hier trouwens altijd ontzettend ingezet op multi-threaded en dat dit zo'n boost gaat geven in de toekomst. Harstikke mooi. Maar ik heb het idee dat hier bij Amdahl's Law heel erg vaak vergeten wordt. Elke programma heeft een deel dat niet multi-threaded uitgevoerd kan worden. Vooral bij games/simulaties is het zelfs erg lastig om het overgrote deel multi-threaded te maken. Omdat je elke stap in je simulatie (elk frame) (bijna) alle informatie nodig hebt. Hierdoor loop je tegen een soort limiet aan van de theoretisch maximale speed-up die elke core die je toevoegt kan hebben. (In de praktijk loop je natuurlijk al veel eerder tegen problemen aan).

Zo zie je hieronder dat als je 75% van het werk kan paralleliseren een AMD Threadripper al tegen deze theoretische limieten aan begint te lopen (32 threads).

[ Voor 18% gewijzigd door roy-t op 23-05-2018 12:28 ]

[DaniëlWW2]

roy-t schreef op woensdag 23 mei 2018 @ 12:19:
[...]


Als (ex) game developer snap ik dit argument niet. Op hogere resoluties moet vooral de GPU meer werk doen. De physics, AI, e.d. en het voorbereiden van de data voor de GPU veranderen niet significant qua werk. Dus op een hogere resolutie wordt hoe dan ook de GPU de bottleneck. Op een lagere resolutie zie je dus veel beter de impact die de CPU echt heeft.

Het voorbeeld wat je geeft zou je dus juist moeten detecteren op 720p als de CPU echt de bottleneck is. Immers zal in dit geval de GPU je niet limiteren.

Een TItan XP op 1080p draaien is natuurlijk ook niet snel de bottleneck. Maar op 720p is je GTX960 dat ook niet meer. Zelfde test voor je CPU eigenlijk.

Het probleem dat ik ermee heb is dat games systematisch meer gaan vragen van de CPU naarmate de jaren vorderen. 720P wordt altijd gebruikt als "indicatie" van toekomstige prestaties, terwijl er nooit rekening word gehouden met de trend naar meer CPU load. De trend naar meer CPU is ook duidelijk als je naar de 2500K vs de 8150 "faaldozer" kijkt. "Faaldozer" is uiteindelijk behoorlijk ingelopen, en 720P testen kunnen dat nooit verklaren.

[roy-t]

DaniëlWW2 schreef op woensdag 23 mei 2018 @ 12:28:
[...]


Het probleem dat ik ermee heb is dat games alle software systematisch meer gaat vragen van de CPU naarmate de jaren vorderen. 720P wordt altijd gebruikt als "indicatie" van toekomstige prestaties, terwijl er nooit rekening word gehouden met de trend naar meer CPU load. De trend naar meer CPU is ook duidelijk als je naar de 2500K vs de 8150 "faaldozer" kijkt. "Faaldozer" is uiteindelijk behoorlijk ingelopen, en 720P testen kunnen dat nooit verklaren.

Fixed .

Ah ik had niet begrepen dat dit als toekomst indicator werd gezien. Dan ben ik het met jou en ook met
sdk1985. De toekomst is onvoorspelbaar, workloads kunnen drastisch veranderen en dat ga je lastig zien in wat voor test dan ook.

[foppe-jan]

DaniëlWW2 schreef op woensdag 23 mei 2018 @ 12:28:
[...]


Het probleem dat ik ermee heb is dat games systematisch meer gaan vragen van de CPU naarmate de jaren vorderen. 720P wordt altijd gebruikt als "indicatie" van toekomstige prestaties, terwijl er nooit rekening word gehouden met de trend naar meer CPU load. De trend naar meer CPU is ook duidelijk als je naar de 2500K vs de 8150 "faaldozer" kijkt. "Faaldozer" is uiteindelijk behoorlijk ingelopen, en 720P testen kunnen dat nooit verklaren.

De vraag is niet eens zozeer of 720p het probleem is, of het feit dat er door een aantal reviewers ook met low q wordt getest, omdat dit betekent dat de scenes minder complex worden gemaakt, ten faveure van pure frame rates: https://nl.hardware.info/...onderzocht-deel-1.293301/
En dat is totaal niet relevant voor 'future perf', want ook in de toekomst zullen maar weinig mensen kiezen voor lage kwaliteit.

[ Voor 7% gewijzigd door foppe-jan op 23-05-2018 14:01 ]

[Werelds]

De tests op lage resoluties zijn nooit nuttig geweest en zijn ook geen indicator van hoe goed een CPU wel of niet is; laat staan dat het een indicatie voor de toekomst is. Dat is omdat het software test, niet hardware.

Als je van bovenaf begint bij de game, heb je daar al meteen het eerste probleem. Elke engine draait anders; en zelfs UE draait niet hetzelfde tussen verschillende games, afhankelijk van doorgevoerde patches en optimalisaties - en vooral ook third-party libraries (Havok vs. PhysX). Niet elke game verdeelt z'n load op dezelfde manier.

Ga je een stapje lager, kom je aan bij de gebruikte API. DX11 ST, DX11 MT, DX12, OpenGL, Vulkan - stuk voor stuk maken ze op een andere manier gebruik van de processor.

Volgende stap: de driver. Ook daar zitten gigantische verschillen; niet alleen tussen Nvidia en AMD, maar ook nog tussen generaties GPU's. Maxwell/Pascal of Polaris/Vega worden op een andere manier behandeld dan eerdere generaties en de CPU load vanuit de driver verschilt dan ook tussen driver versies én GPU generaties.

Het enige nut dat deze tests hebben is om aan te geven hoe een specifieke combinatie van CPU, GPU, driver en API met elkaar reageren in een game. Het toont aan wat de beste combinatie voor die specifieke game is. Als een game zwaar multithreaded is en DX12 gebruikt zal AMD naar boven drijven en dan zal dat op hogere resoluties ook betekenen dat je met AMD minder snel tegen een bottleneck aan loopt. Tegelijkertijd zal in de gemiddelde DX11ST game een snellere CPU meer voordeel bieden en dan dus beter uit de bus komen, waardoor je in sommige games nog steeds gewoon beter een dual-core op 5+ GHz kunt hebben dan een quad-core op 4+ GHz; meer voor AMD dan voor Nvidia vanwege de aard van de drivers, Nvidia zal op die quad-core minder terug vallen. Dat heeft dan geen reet te maken met die specifieke CPU, maar alles met de software stack er boven.

Voordat je bij de CPU prestaties aan komt ben je al op verschillende niveaus potentiële bottlenecks tegen gekomen waar je niets aan kunt doen. Het werk dat de CPU doet verschilt afhankelijk van de game, API en driver - en ook de output verschilt. Andersom kun je bij het testen van een GPU wel zo veel mogelijk de CPU bottleneck beperken door er voor te zorgen dat deze ofwel genoeg cores heeft, ofwel snel genoeg tikt om de software niet te beperken. Het werk dat de GPU doet verschilt ook hier tussen Nvidia en AMD, maar de output is (min of meer) hetzelfde. Neemt niet weg dat het weldegelijk belangrijk is om tegenwoordig Intel en AMD beide in benchmarks te gebruiken, met beide GPU fabrikanten, puur om enige driver-/API bias voor specifieke soorten CPU's weg te nemen.

[ Voor 4% gewijzigd door Werelds op 23-05-2018 15:26 ]

[roy-t]

Al je argumenten kun je ook betrekken op alle benchmarks, en als je deze precies omkeert juist exact op GPUs testen. Verder test elke benchmark ook de software en APIs waarin de benchmark geschreven is. Dit is niet speciaal iets wat alleen geld voor games. Het testen van verschillende workloads is daarom erg belangrijk.

Je kunt helaas een CPU (of elk ander computer onderdeel) nooit echt testen in isolatie. Je kunt alleen proberen om ervoor te zorgen dat je CPU zo min mogelijk gehinderd wordt door de andere onderdelen. Je GPU minder werk laten doen maakt deze minder de bottleneck en laat je dus beter de performance zien. Alle grafische instellingen maken (nagenoeg) alleen maar het werk voor de GPU makkelijker, spellen hebben eigenlijk nooit instellingen die het CPU werk makkelijker maken (zoals de AI dommer, of de physics minder precies...).


Als je echt puur de CPU wil testen, met zo min mogelijk invloed van buitenaf moet je eigenlijk iets doen wat misschien tegen je intuitie in gaat. Je moet zorgen voor zo min mogelijk andere bottlenecks, Je moet dezelfde deterministische test vaak herhalen. En je moet het snelste resultaat nemen.

Immers, waarom is het resultaat soms slechter dan het beste resultaat:

- Omdat een ander programma ook even wat CPU tijd nodig had
- Omdat de CPU moest wachten op een ander apparaat dat net pech had. Bijvoorbeeld op de hardeschijf omdat de benchmark data nog naar het werkgeheugen of de CPU cache gebracht moest worden.
- Omdat de CPU te warm werd en moest throttelen
...

Al deze scenarios zijn niet de schuld van de CPU, maar gevallen van pech waar de CPU zelf weinig aan kan doen. (In geval van warmte zou het nog een ontwerp fout kunnen zijn, maar meestal duid dit op inadequate koeling).


Dit is natuurlijk de ideale situatie waarbij zo min mogelijk interactie met andere apparaten in acht genomen wordt. In de echte wereld koop je een hele computer, zijn tests niet altijd helemaal deterministisch en past de CPU zich continue aan (frequenties, core keuze, caching strategie).

[ Voor 21% gewijzigd door roy-t op 23-05-2018 17:12 ]

[Sp3ci3s8472]

roy-t schreef op woensdag 23 mei 2018 @ 17:07:
Je kunt helaas een CPU (of elk ander computer onderdeel) nooit echt testen in isolatie. Je kunt alleen proberen om ervoor te zorgen dat je CPU zo min mogelijk gehinderd wordt door de andere onderdelen. Je GPU minder werk laten doen maakt deze minder de bottleneck en laat je dus beter de performance zien. Alle grafische instellingen maken (nagenoeg) alleen maar het werk voor de GPU makkelijker, spellen hebben eigenlijk nooit instellingen die het CPU werk makkelijker maken (zoals de AI dommer, of de physics minder precies...).

Dat is niet waar, er zijn specifieke instellingen die zwaar zijn voor de cpu. Om een aantal te noemen (want er zijn er wel meer):

• Mesh detail
• Draw Distance
• Particle instances
• Ragdoll
• Sound (kwaliteit en aantal channels)

Het is wellicht een oud spel, maar als je UT2004 erbij pakt zie je gewoon bij elke setting in het spel staan of het impact heeft op de cpu of gpu. Zie ook de oude tweakguide http://www.tweakguides.com/UT2004_5.html.

Daarnaast, het enige wat je doet met de resolutie op 720p zetten is ervoor zorgen dat de thread die de gpu moet voorzien van drawcalls maximaal wordt belast. Laten dingen zoals AI, Physics en networking juist allemaal op een eigen tickrate draaien bijvoorbeeld 60x per seconde, die gaan niet sneller.
Je pakt dus 1 onderdeel van een spel en gaat dat maximaal belasten. Dat geeft totaal geen realistisch beeld van de performance van een cpu, het enige dat dat je verteld is dat een bepaalde cpu erg goed is in het aanmaken van drawcall in een bepaalt spel.
Dat is nu ook juist het punt wat moderne apis zoals DX12 en Vulkan oplossen.

[Verwijderd]

roy-t schreef op woensdag 23 mei 2018 @ 12:31:
Ah ik had niet begrepen dat dit als toekomst indicator werd gezien.

Dat was inderdaad dde kritiek. 720p 'testen' wordt gebruikt misbruikt als toekomstvoorspellen. Dat kan je misschien doen als de CPU's evenveel kernen en threads hebben en dan mogelijk nog met beperkingen, niet als de ene CPU 2/4 meer kernen en 4/8/12 meer threads heeft.

[Werelds]

roy-t schreef op woensdag 23 mei 2018 @ 17:07:
Al je argumenten kun je ook betrekken op alle benchmarks, en als je deze precies omkeert juist exact op GPUs testen. Verder test elke benchmark ook de software en APIs waarin de benchmark geschreven is. Dit is niet speciaal iets wat alleen geld voor games. Het testen van verschillende workloads is daarom erg belangrijk.

Je kunt helaas een CPU (of elk ander computer onderdeel) nooit echt testen in isolatie. Je kunt alleen proberen om ervoor te zorgen dat je CPU zo min mogelijk gehinderd wordt door de andere onderdelen. Je GPU minder werk laten doen maakt deze minder de bottleneck en laat je dus beter de performance zien. Alle grafische instellingen maken (nagenoeg) alleen maar het werk voor de GPU makkelijker, spellen hebben eigenlijk nooit instellingen die het CPU werk makkelijker maken (zoals de AI dommer, of de physics minder precies...).

In volledige isolatie? Nee, dat lukt inderdaad niet. Het verschil met GPU benchmarks is echter dat de workload volledig verschilt.

Een CPU zal met zo'n test geheel andere dingen doen en geheel anders belast worden. De optimale condities zijn per game verschillend; de ene game kun je het best op DX12 met een AMD GPU en CPU met veel cores draaien, terwijl een andere game juist het best met DX11, een Nvidia GPU en een snelle dualcore draait. Geen van beide games is dus enige maatstaf voor CPU performance in z'n algemeen. In het eerste geval is de CPU slechts bijzaak, de GPU zal daar veel meer belast worden en het aantal drawcalls dat verstuurd wordt zal veel hoger zijn. In het laatste geval zal het grootste deel van de CPU tijd doorgebracht worden in de DX11 API.

Beide games zijn wel valide maatstaven voor GPU performance, omdat ongeacht de parameters de output hetzelfde is voor elke combinatie. Er zijn nog altijd combinaties van parameters die voor bepaalde generaties GPU's optimaal zijn, maar als puntje bij paaltje komt maakt het voor de output niet uit. Een poly is en blijft een poly. Dat een AMD GPU dat met andere instructies doet dan een Nvidia GPU is te verwachten en normaal, maar in tegenstelling tot de CPU voorbeelden hierboven is het werk dat de GPU moet doen in grote lijnen hetzelfde.

Games zijn gewoon slechte benchmarks, maar voor CPU performance zijn ze ronduit nutteloos. Voor GPU's zijn ze nuttig, mits de parameters bekend zijn (en het liefst gevarieerd getest worden). Je moet de benchmarks wel nog steeds in perspectief zien; dat wil zeggen, de combinatie van GPU, CPU, API en driver versie is en blijft relevant en je kunt de ene game niet met de andere vergelijken.

Maar dat is ook juist hoe GPU's gebenchmarked worden: over meerdere games. De enige manier waarop 720p tests relevant zouden kunnen zijn als CPU benchmarks is als ze ook al die games testen met verschillende GPU's. Vrijwel overal worden de 720p tests op slechts één of twee games uitgevoerd, wat helemaal niets zegt over de CPU.

Een spel als Rocket League (DX11ST) kun je beter op Nvidia uitvoeren dan AMD en een snelle dual-core doet daar meer dan een quad-core, laat staan hogere core counts. Dus hoe ga je dat testen? Gebruik je dan juist een AMD GPU om te zien hoe dat helpt met de driver bottleneck? Of ga je juist voor Nvidia zodat je kunt zien hoe die CPU helpt met de API bottleneck? Want in geen van beide gevallen zal de CPU noch de GPU de bottleneck zijn.

En neem je vervolgens DOOM, geldt iets geheel anders. Ga je dan voor Nvidia zal de CPU meer werk moeten verrichten voor hun scheduler (ja, zelfs met Pascal nog), terwijl je met een AMD GPU juist vrijwel geen software bottleneck hebt en je dus dichter op de werkelijke limiet van de CPU komt te zitten.

Dát is waarom 720p tests nutteloos zijn. Wilt men deze nuttig maken, moet men ze ook over dezelfde test suite als GPU benchmarks uitvoeren en ook op dezelfde manier bekijken: patronen herkennen tussen verschillende engines, API's en drivers.

[Psyonara]

Is Rocket League niet een slecht voorbeeld DX9 only.....

[roy-t]

@Werelds

Je zegt dat games CPUs anders belasten. Maar elk programma belast de CPU anders. Ik snap niet waarom dat dan geen valide benchmark meer is. Games zijn (trouwens helemaal niet zo heel anders. Lijstjes doorzoeken, lijsten aanmaken, wat pointers volgen, wat rekenwerk, etc...) Je spreekt continue over dat ze bepaalde APIs aanspreken maar dat is niks magisch ook maar gewoon saaie code. Het is niet anders dan dat een zip benchmark een heel andere workload heeft dan Cinebench . De workload is ook niet zo ver verwijderd van normaal gebruik dat niemand er iets aan heeft.

[ Voor 9% gewijzigd door roy-t op 24-05-2018 17:53 ]

[Werelds]

roy-t schreef op donderdag 24 mei 2018 @ 11:45:
@Werelds

Je zegt dat games CPUs anders belasten. Maar elk programma belast de CPU anders. Ik snap niet waarom dat dan geen valide benchmark meer is. Games zijn (trouwens helemaal niet zo heel anders. Lijstjes doorzoeken, lijsten aanmaken, wat pointers volgen, wat rekenwerk, etc...) Je spreekt continue over dat ze bepaalde APIs aanspreken maar dat is niks magisch ook maar gewoon saaie code. Het is niet anders dan dat een zip benchmark een heel andere workload heeft dan Cinebench . De workload is ook niet zo ver verwijderd van normaal gebruik dat niemand er iets aan heeft.

(Als programmeur verbaasd het me af en toe hoe magisch games voor mensen zijn. Het is echt 98% hele saaie normale code )

Je mist m'n punt volledig

Het is niet dat games CPU's anders belasten. Het is dat elke game de CPU anders belast; en niet eens slechts elke game, maar elke combinatie van game, API en driver. Dat een zip benchmark iets anders doet dan CineBench is bekend. Maar die benchmarks worden ook als dusdanig behandeld: de prestaties van die CPU in die benchmark.

Maar met de 720p tests, waar het bijna altijd over slechts 1 game gaat, worden behandeld en bekeken als "de" benchmark voor "game performance". Dat is gewoon onjuist. Die 720p test geldt alleen voor de geteste CPU's in die game op die API, met die GPU(-generatie) op die driver. Verwissel je de GPU dan kun je de hele benchmark weggooien. Kan de game schakelen tussen DX12 en Vulkan? Dan moet je ze ook apart benchmarken; dat wordt voor GPU tests al gedaan door een beetje respectabele reviewer, maar voor die 720p "CPU tests" niet.

En de API maakt weldegelijk iets uit - de code is zo spannend niet, maar wat er gebeurt wel. DX11 kun je single- en multi-threaded gebruiken. Dat alleen al geeft een geheel ander CPU profiel. Daaronder zit vervolgens de driver, die in het geval van Nvidia DX11ST gebruik deels MT uit voert, waardoor het CPU profiel met een Nvidia kaart geheel anders is dan met AMD. Dan heb ik het nog niet eens gehad over OGL, DX12 of Vulkan. Zeggen dat de API niets uit maakt is hetzelfde als zeggen dat het niet boeit of je GCC, ICC of MSVC gebruikt

Ik ben overigens ook programmeur van beroep hoor, ik weet donders goed hoe dit alles werkt

[roy-t]

Werelds schreef op donderdag 24 mei 2018 @ 12:20:
[...]

Je mist m'n punt volledig

Het is niet dat games CPU's anders belasten. Het is dat elke game de CPU anders belast; en niet eens slechts elke game, maar elke combinatie van game, API en driver. Dat een zip benchmark iets anders doet dan CineBench is bekend. Maar die benchmarks worden ook als dusdanig behandeld: de prestaties van die CPU in die benchmark.

Ik heb gemist dat er bij games anders over wordt gedacht. Maar als dat je stelling is dan ben ik het eens. Net als elk stuk software is ook elke game anders.

Verwissel je de GPU dan kun je de hele benchmark weggooien.

Eens, elke benchmark die 2 cpus vergelijkt moet zo vergelijkbaar mogelijk zijn.

Kan de game schakelen tussen DX12 en Vulkan? Dan moet je ze ook apart benchmarken; dat wordt voor GPU tests al gedaan door een beetje respectabele reviewer, maar voor die 720p "CPU tests" niet.

Tsja, kan, is je krijgt een klein beetje een andere workload in de paar procent van de CPU instructies die daadwerkelijk met deze API praat. Communiceren me het doorgeefluik is maar een heel klein deel van wat de CPU per frame moet doen. Wel is het zo dat je sommige GPU APIs asynchroon of multi-threaded kan aanspreken waardoor de CPU er niet op hoeft te wachten. Maar ook dit is maar een klein onderdeel van het hele werk. Het veranderd het grootste deel van de workload niet. Het is meer als een paar minder belangrijke instellingen van je benchmark testen. Zeer goed voor de volledigheid of om hele gekke dingen te vinden. Maar niet zo dat je niks kan zeggen als je niet elke combinatie hebt geprobeerd.

En de API maakt weldegelijk iets uit - de code is zo spannend niet, maar wat er gebeurt wel. DX11 kun je single- en multi-threaded gebruiken. Dat alleen al geeft een geheel ander CPU profiel. Daaronder zit vervolgens de driver, die in het geval van Nvidia DX11ST gebruik deels MT uit voert, waardoor het CPU profiel met een Nvidia kaart geheel anders is dan met AMD. Dan heb ik het nog niet eens gehad over OGL, DX12 of Vulkan. Zeggen dat de API niets uit maakt is hetzelfde als zeggen dat het niet boeit of je GCC, ICC of MSVC gebruikt

Ik ben het met je eens dat er iets veranderd, maar we zijn het niet heel erg eens over de impact denk ik. Ik weet niet of je zelf tegen deze APIs aan programmeert. Maar het is echt maar een heel klein onderdeel van de hele codebase. Wel is het zo dat met DX12 en Vulkan er ineens veel meer mogelijk is op zo'n manier dat je potentie de engine architectuur heel erg kan omgooien (veel meer multi-threading). En Vulkan laat je net dat laagje dieper gaan waardoor je een hoop soms onnodige kunt overslaan, vandaar de soms hogere FPS in benchmarks.

Ik ben overigens ook programmeur van beroep hoor, ik weet donders goed hoe dit alles werkt

Excuus, het meer bedoeld als algemene opmerking.

[Sp3ci3s8472]

roy-t schreef op donderdag 24 mei 2018 @ 14:37:
[...]

Excuus, het meer bedoeld als algemene opmerking.

Die opmerking past beter op fok , hier zitten behoorlijk wat programmeurs.

Aanvullend aan wat er is gezegd, er zit een best verschil tussen DX12 en Vulkan als het gaat om het maximale aantal draw calls wat een kaart kan maken. Dit zie je met name bij AMD kaarten.

[sdk1985]

Werelds schreef op donderdag 24 mei 2018 @ 12:20:
[...]


Maar met de 720p tests, waar het bijna altijd over slechts 1 game gaat, worden behandeld en bekeken als "de" benchmark voor "game performance". Dat is gewoon onjuist. Die 720p test geldt alleen voor de geteste CPU's in die game op die API, met die GPU(-generatie) op die driver. Verwissel je de GPU dan kun je de hele benchmark weggooien. Kan de game schakelen tussen DX12 en Vulkan? Dan moet je ze ook apart benchmarken; dat wordt voor GPU tests al gedaan door een beetje respectabele reviewer, maar voor die 720p "CPU tests" niet.

Is dat zo? Ik zie hem eigenlijk zelden staan als 'de' benchmark. Hij staat er vaker niet dan wel bij.

Verder kan ik mij ook niet vinden in de bewering dat een 720p tests altijd over 1 game gaat. Toevallig van de week nog een link geplaatst naar techpowerup en memory scaling en daar werden er direct 4 getest op 720p en 1080p. Dan zie je ook direct dat er ook games zijn die totaal niet schalen. In de regel zijn het de shooters die redelijk lineair mee schalen met de resolutie. Dat zijn niet toevallig net de games waarbij FPS daadwerkelijk belangrijk zijn.

Zo'n 720p test is de enige test die een indictie kan geven wat voor resultaten jij kan gaan zien wanneer jij een gpu in je systeem zet die nog uit moet komen. Iets beters is tot heden niet verzonnen.

Even die TPU erbij pakken: 1920x1080 / 1280x720 = 55% (hoogst haalbare)

Met de snelste cpu results:
Bf 1 234.7 / 149.2 = 36%
Dishondered 2 111.5 / 103.8 = 7%
Hitman 155.1 / 141.5 = 9%
The Witcher 3 138.7 / 104.6 = 25%

Met de traagste memory results:
Bf 1 227 / 145.7 = 35%
Dishondered 2 102.3 / 98 = 4%
Hitman 121.4 / 120.5 = 1%
The Witcher 3 135.8 / 102.9 = 24%

Toch best interessante informatie. Zo zou je eruit kunnen halen dat hitman erg zwaar op de cpu leunt en dat om enige vorm van scaling te zien je daar een snelle(re) cpu nodig hebt. Steeds meer games hebben tegenwoordig een render scaling slider (daarmee kun je de UI op native resolutie houden maar het renderen op een lagere resolutie zetten) en dan weet je ook meteen wat je op dat vlak qua rek kunt verwachten.

Verder ben ik het er wel mee eens dat het mooi zou zijn als de verschillende api's, indien mogelijk, dan ook mee worden genomen. Daar is Bf One een goed voorbeeld van. Echter als reviewer probeer je natuurlijk een verhaal neer te zetten en als je te veel erbij zet dan ontstaat er bij veel lezers information overload. Ergens zal er toch een selectie worden gemaakt. Maar goed als jij goede redenen hebt waarom iets er echt bij staat dan staat een reviewer wellicht open voor die feedback.

Houdt daarbij wel rekening met de hoeveelheid werk. Om de TPU test met de 'beperkte' game test even te quoten

For this article, we completed nearly 500 individual benchmark runs to paint a more complete picture on the DDR memory situation with Coffee Lake.

Het houdt natuurlijk wel een keer op. Des te meer wanneer het om bijvoorbeeld 3% gaat.

Een spel als Rocket League (DX11ST) kun je beter op Nvidia uitvoeren dan AMD en een snelle dual-core doet daar meer dan een quad-core, laat staan hogere core counts. Dus hoe ga je dat testen? Gebruik je dan juist een AMD GPU om te zien hoe dat helpt met de driver bottleneck? Of ga je juist voor Nvidia zodat je kunt zien hoe die CPU helpt met de API bottleneck? Want in geen van beide gevallen zal de CPU noch de GPU de bottleneck zijn.

Dit zal IMO niet zo snel de insteek van een reviewer zijn. Als reviewer ga je de vraag proberen te beantwoorden; Als ik product X koop wat kan ik dan verwachten. Daarbij loop je direct tegen het probleem aan dat niet iedereen op dezelfde resolutie en met dezelfde hardware combinatie werkt. Ga je een cpu testen dan pak je dus de snelste gpu die je kunt vinden. Ga je een gpu testen dan is dat omgekeerd. Er is gewoon geen andere manier want elke mogelijk combinatie testen is niet alleen te veel werk, het is voor de lezer uiteindelijk ook geen doorkomen aan. Wat restreert is zo veel mogelijk 'cetris paribus' testen. Zelfs dat is tegenwoordig haast onmogelijk omdat games zichzelf updaten.

Verder zijn de meeste lezers ook totaal niet bezig met de details. Dus dat er andere api's bestaan of dat een bepaalde GTX 1050 ineens meer shader cores heeft zal ze aan hun reet roesten. Die willen gewoon een duidelijk antwoord op een logische maar te algemene vraag.

Natuurlijk kunnen er interessante subvragen ontstaan als 'ja maar ik heb geen Intel cpu, hoe doen de gpu's het dan op ryzen'. Maar bij elke gpu review gaan testen op een reeks aan Intel en AMD cpu's is echt geen doen. Niet voor de reviewer en niet voor de lezer. Dat kun je alleen oppakken in een aparte test om die vraag in algemene zin te proberen te beantwoorden. Dit soort dingen zie je HWI weleens doen, daarvoor lof (ook al zou ik het soms anders aanpakken).

Ik zou zelf gewoon wat minder van reviews verwachten. Zie het gewoon als grove indicaties hoe product range X het bij benadering doet. HWI komt tegenwoordig met 35 pagina's wat dat betreft zijn we tegenwoordig al behoorlijk verwend. Een jaar of 15 geleden was de hele review vaak op 1 a4 uit te printen. En als dat niet werkt dan kun je altijd nog zelf reviews gaan schrijven. De drempel is minimaal.

[ Voor 35% gewijzigd door sdk1985 op 24-05-2018 18:03 ]

[roy-t]

Sp3ci3s8472 schreef op donderdag 24 mei 2018 @ 17:07:
[...]


Die opmerking past beter op fok , hier zitten behoorlijk wat programmeurs.

Helemaal gelijk, ik zal 'm weghalen

[Verwijderd]

roy-t schreef op donderdag 24 mei 2018 @ 14:37:
Eens, elke benchmark die 2 cpus vergelijkt moet zo vergelijkbaar mogelijk zijn.

En zelfs dat zegt enkel iets over het verschil tussen die twee CPU's met die ene grafische kaart! Neem bijvoorbeeld RotTR met DX12 vorig jaar, Ryzen vs. Intel bij een FuryX gaf een heel ander resultaat dan een Ryzen vs. Intel bij een 980 Ti (of 980 of 1070). Idem voor Rocket League (DX9) bij een RX 580 vs. een GTX 1060.

Sp3ci3s8472 schreef op donderdag 24 mei 2018 @ 17:07:
[...]


Die opmerking past beter op fok , hier zitten behoorlijk wat programmeurs.

En zelfs van de niet-programmeurs hebben veel mensen hier wel enige ervaring met programmeren op de een of andere manier. In mijn geval bijvoorbeeld C, C++/Java, assembly en Verilog. Op een relatief laag niveau maar genoeg om de belangrijkste algemene principes van programmeren en hardware/software interactie te begrijpen. Veel mensen hier hebben op de een of andere manier een bèta-achtergrond (calculus, natuurkunde, lineaire algebra, toegepaste wetenschappen...) en wat ervaring met programmeren op de een of andere manier, al is het maar Matlab of zo.

sdk1985 schreef op donderdag 24 mei 2018 @ 17:42:
Zo'n 720p test is de enige test die een indictie kan geven wat voor resultaten jij kan gaan zien wanneer jij een gpu in je systeem zet die nog uit moet komen. Iets beters is tot heden niet verzonnen.

Enkel voor dat spel. Voor toekomstige spellen zegt het meestal niets aangezien je ook maar moet afwachten hoeveel threads het kan benutten, hoe goed de load verdeeld kan worden over die threads etc.
Roy gaf aan dat er beperkingen zijn aan mogelijkheden om te multithreaden en dat er de beperking is dat alles wat die threads doen moet worden gebruikt voor dat ene frame, dat klopt maar laten we tegelijkertijd niet vergeten dat ondertussen Crysis3 op de 2700X beter draait dan op de 8700k, de extra threads helpen dus in ieder geval voor dat spel.
Dat er van alles bij elkaar moet komen voor 60-120 keer per seconde voor een doorsnee AAA spel lijkt me een beperkt probleem voor het schalen van multithreading. Laten we uitgaan van een FPS van 100 (best hoog maar iets wat we graag willen), dan moet elke 10 ms alles samenkomen. Een cyclus van een up to date CPU (2600X, 2700X, 8700k) duurt <= 250 picoseconde, dat past 40 000 000 keer in die 10 ms.
Wat is de datalatency voor verschillende kernen van de CPU? Ergens tussen de tientallen en net boven de 100 ns (bij Zen2 ongetwijfeld een stukje onder de 100), waarmee je zo'n 400 cycli kan verliezen van die 40 000. Dat lijkt mij mee te vallen maar als jullie dat anders zien dan lees ik dat graag.
Een groter probleem is wanneer er afhankelijkheden zijn (bijvoorbeeld wanneer je hardware simuleert, dat valt slecht of niet te multithreaden). Maar hoe erg is dat een probleem bij spellen? Een simpele voorbeeldje, de thread die de kogelbaan berekend hoeft slechts een coördinaat en een paar andere waardes voor variabelen (wind, wapen...) door te krijgen.

Natuurlijk heb ik gemakkelijk praten aangezien ik het niet hoef uit te voeren.
Ja, daar ben ik me goed bewwust van.
Programmeurs moeten leren omgaan met hoe je het maximale haalt uit al die threads maar bij spellen valt daar nog gigantisch veel mee te winnen.

[ Voor 65% gewijzigd door Verwijderd op 24-05-2018 20:07 ]

[Paprika]

Denk dat men dit wel had verwacht, maar toch...

https://wccftech.com/rumo...tailed-zen-2-zen-3-zen-5/

[DaniëlWW2]

Paprika schreef op zondag 27 mei 2018 @ 11:52:
Denk dat men dit wel had verwacht, maar toch...

https://wccftech.com/rumo...tailed-zen-2-zen-3-zen-5/

Het probleem is dat ik geen echte roadmap zie met details.
Maar nee, die twaalf a zestien cores komen niet geheel onverwacht. Die speculatie hebben we hier al vaak genoeg afgedraaid. Wil wel zeggen dat als het er echt zestien op AM4 worden, dat dit gewoon natrappen is.

[NitroX infinity]

AMD heeft nu 8 cores op zowel AM4 als TR4. Misschien zullen we alleen 16 cores op TR4 krijgen en 12 cores als maximum op AM4 om TR4 wat aantrekkelijker te maken?

[The Chosen One]

En binnen enkele jaren al zoveel cores op mainstream lijkt me in de praktijk ook nog niet zo nuttig of wel?
Ja 6-8 cores worden zeker gebruik van gemaakt met games/prog's al dan niet alles ofc maar 12-16 dan al daarvoor? Al kunnen ze natuurlijk gewoon "kijk naar onze cores wheeeeee" doen.

[Paprika]

The Chosen One schreef op zondag 27 mei 2018 @ 13:40:
En binnen enkele jaren al zoveel cores op mainstream lijkt me in de praktijk ook nog niet zo nuttig of wel?
Ja 6-8 cores worden zeker gebruik van gemaakt met games/prog's al dan niet alles ofc maar 12-16 dan al daarvoor? Al kunnen ze natuurlijk gewoon "kijk naar onze cores wheeeeee" doen.

Het gaat heus wel op. Net zoals de hoeveelheid RAM en core count voor 'thuisgebruik' ook al jaren oploopt. Kijk maar eens naar telefoons...

Daarnaast valt mainstream nog altijd onder een bovengemiddelde last.

[ Voor 6% gewijzigd door Paprika op 27-05-2018 13:53 ]

[enchion]

Ik zou denken dat alle 8+ core CPU`s als 16 core gemakt worden en de 16cores die volledig goed werken naar Threadripper gaan en die met foutjes als 12core Ryzen7 gebruikt gaan worden.

Om het productie proces eenvoudig te houden.

Als het al meteen 16 cores met ook een flinke mhz boost wordt voor Ryzen dan moeten we afscheid gaan nemen van Intel denk ik, tenzij Intel spoedig daarna met een Home-Quantum-computer op de proppen komt.

[The Chosen One]

Mja, laten we zeggen Intel heeft volgend jaar een 8 core met ~7Ghz baseclock ineens. Dan kun je alsnog wel een 12 core 5Ghz hebben maar dan is er genoeg reden voor mensen om nog Intel te kiezen.

Daarnaast heeft Intel nog wel wat miljardjes op de bank staan.

[madmaxnl]

Om het nog wat ongeloofwaardig te maken, op 10nm zeker? Daar hebben ze al enkele miljardjes op stuk geslagen

[schaduw]

Zoals al langsgekomen is als nieuwsbericht, komen er nieuwe HP Envy X360 Ryzen modellen aan. Er werd gesproken van eind mei, dus ik werd wat ongeduldig voor de 13 inch versies.

Na lang zoeken, heb ik ze eindelijk gevonden. Prijzen en levertijden staan er nog niet helaas. Op de HP NL site staat nog alleen support informatie, zoals deze specs. Het gaat in de 13-ag0000 serie. Met, voor zover ik weet, voor het eerst ook de AMD 2300u (2GHz - 3,4GHz quadcore, 4 threads).

Het is nu hopen (bijna tegen beter weten in, gezien het compacte formaat) dat deze modellen voldoende koeling bieden om de prestaties van de APU tentoon te spreiden.



Dit zijn de modellen. Voor ons minder interessant vanwege de eigen toetsenbord indelingen.
Verschillen tussen de twee UK varianten per APU heb ik nog niet kunnen vinden.
Opvallend is dat de UK 2500u's mager bedeeld zijn met een 128GB SSD en natuurlijk de verschillen in verkrijgbaarheid van de APU keuze per land. De Duitsers hebben (nog) geen 2700u, maar wel 16GB RAM als optie.


AMD Ryzen 7 2700U (2 GHz base frequency, up to 3.8 GHz burst frequency, 6 MB cache, 4 cores) Vega10 / 8GB ram

• 13-ag0503na (4AZ73EA) 512GB PCIe NVMe M.2 SSD (UK)
• 13-ag0003sa (4JV76EA) 512GB PCIe NVMe M.2 SSD (UK)

AMD Ryzen 5 2500U Quad-Core (2 GHz base frequency, up to 3.6 GHz burst frequency, 6 MB cache) Vega 8 / 8GB ram

• 13-ag0002ns (3ZS88EA) 256GB PCIe NVMe M.2 SSD (Spanje)
• 13-ag0502na (4AZ72EA) 128GB M.2 SSD (UK)
• 13-ag0002sa (3ZT32EA) 128GB M.2 SSD (UK)
• 13-ag0005ng (4JS64EA) 16GB ram ipv 8GB, 512GB PCIe NVMe M.2 SSD (Duitsland)
• 13-ag0301ng (4MV96EA) 256GB PCIe NVMe M.2 SSD (Duitsland)
• 13-ag0004ng (4JS63EA) 512GB PCIe NVMe M.2 SSD (Duitsland)

AMD Ryzen 3 2300U (2 GHz base frequency, up to 3,4 GHz burst frequency, 6 MB Cache, 4 threads) Vega 3 / 8GB ram

• 13-ag0001ns (3ZS89EA) 256GB PCIe NVMe M.2 SSD (Spanje)
• 13-ag0003ng (4AX62EA) 256GB PCIe NVMe M.2 SSD (Duitsland)

Verder gelijk bij allen:

• Display 33.8 cm (13.3") diagonal FHD IPS micro-edge WLED-backlit touch screen with Corning® Gorilla® Glass NBT™ (1920 x 1080)
• Wireless: 802.11b/g/n/ac (2x2) Wi-Fi® and Bluetooth® 4.2 combo
• Accu 4-cell, 53.2 Wh Li-ion, 45W adapter, 11 uur werktijd
• Supports battery fast charge: approximately 50% in 45 minutes
• Gewicht 1.3 kg
• DDR4-2400 SDRAM
• HP Imagepad with multi-touch gesture support
• Camera: HP Wide Vision HD IR Camera with integrated dual array digital microphone
• Audio features: Bang & Olufsen, quad speakers, HP Audio Boost
• Ports
• 1 USB 3.1 Type-C™ Gen 2 (Data Transfer up to 5 Gb/s, Power Delivery, DisplayPort™ 1.4, HP Sleep and Charge)
• 2 USB 3.1 Gen 1 (1 HP Sleep and Charge)
• 1 HDMI 2.0
• 1 headphone/microphone combo
• Expansion slots
• 1 microSD media card reader
• Product color: Dark ash silver
• Product design: Aluminum cover finish
• Dimensions (W x D x H): (30.67 x 21.46 x 1.49 cm)

Zie hier de modellen per land, Duitsland, Spanje, UK.

[ Voor 20% gewijzigd door schaduw op 29-05-2018 14:35 ]

[Help!!!!]

Vandaag op meerdere plekken in het nieuws:

Epyc fail? We can defeat AMD's virtual machine encryption, say boffins

"Evil hypervisors can lift plaintext info out of ciphered memory, it is claimed"

[ Voor 16% gewijzigd door Help!!!! op 29-05-2018 17:32 ]

[Blaat]

Help!!!! schreef op dinsdag 29 mei 2018 @ 16:53:
Vandaag op meerdere plekken in het nieuws:

Epyc fail? We can defeat AMD's virtual machine encryption, say boffins

Evil hypervisors can lift plaintext info out of ciphered memory, it is claimed

Dus in het kort als ik het goed begrijp; dmv een exploit kan Epyc SEV omzeild worden en er unencrypted data van de ene VM naar de andere VM gesluisd worden.

Hoe erg is dit? Het lijkt mij om daar gericht misbruik van te kunnen maken dat je moet weten wat er in de andere VM gaande is en in de toepassingen die in het artikel genoemd worden lijkt me dat verre van voor de hand liggend.

Of zie ik dat verkeerd?

[madmaxnl]

Erg is het zeker, aangezien dit dus toegepast kan worden bij gehuurde VMs. Je kan dus andere klanten, die bij dezelfde partij VMs afnemen, een poot uitdraaien.

Wel kan een verhuurder van VMs hier makkelijk rekening mee houden door elke partij die VMs afneemt op fysiek aparte machines te laten lopen. Ergo, geen twee verschillende klanten op dezelfde fysieke machine waar meerdere VMs op draaien. Dit maakt het voor de verhuurder natuurlijk niet goedkoper, integendeel. Schaalvoordelen e.d. tellen plots niet meer als je tig klanten hebt die maar een paar VMs nodig hebben.

[dcm360]

Ehm, dat kan dus niet, je moet controle hebben over de Hypervisor, en dat krijg je als klant niet.

Overigens betreft het een feature die überhaupt niet bestaan buiten het platform van AMD.

[madmaxnl]

Nu niet meer nee.

[dcm360]

madmaxnl schreef op dinsdag 29 mei 2018 @ 17:26:
Nu niet meer nee.

Wat precies nu niet meer? Het was al niet mogelijk om vanuit een VM een andere VM te beinvloeden, en dat is het nog steeds niet. Er moet aan de hypervisor voor geknutseld gaan worden, en dan heb je daar al het grootste probleem te pakken. Zonder deze feature kon de hypervisor sowieso al het geheugen van alle VM's zonder moeite uitlezen.

[madmaxnl]

Kun je me een voorbeeld geven van een 'untrusted Hypervisor'?

[Paprika]

madmaxnl schreef op dinsdag 29 mei 2018 @ 17:17:
Wel kan een verhuurder van VMs hier makkelijk rekening mee houden door elke partij die VMs afneemt op fysiek aparte machines te laten lopen.

Totaal niet realistisch. Dan zou praktisch iedere grotere partij (Microsoft met Azure, Amazon met hun cloud, IBM/SoftLayer cloud, Google cloud, HP cloud etc) per direct kunnen inpakken.

Wel jammer dat de techsites een belangrijk onderdeel niet noemen:

However, a technique dubbed SEVered can, it is claimed, be used by a rogue host-level administrator, or malware within a hypervisor, or similar, to bypass SEV protections and copy information out of a customer or user's virtual machine.

Verder is het niet zo'n ramp in deze gevallen, want je moet dus op de host (de HyperVisor) gaan knutselen. Dan hebben we het dus over een gehackte root en/of beheerder die zijn beheertoegang misbruikt om dit resultaat te bereiken. Tja...

Squee heeft dit trouwens al erg goed uitgelegd, dus dat ga ik niet nog eens doen:
Squee in 'nieuws: 'AMD Epyc-encryptie voor virtuele machines is te omzeilen''

[ Voor 27% gewijzigd door Paprika op 29-05-2018 18:27 ]

[Werelds]

Paprika schreef op dinsdag 29 mei 2018 @ 18:14:
[...]

Totaal niet realistisch. Dan zou praktisch iedere grotere partij (Microsoft met Azure, Amazon met hun cloud, IBM/SoftLayer cloud, Google cloud, HP cloud etc) per direct kunnen inpakken.

Wel jammer dat de techsites een belangrijk onderdeel niet noemen:

[...]

Verder is het niet zo'n ramp in deze gevallen, want je moet dus op de host (de HyperVisor) gaan knutselen. Dan hebben we het dus over een gehackte root en/of beheerder die zijn beheertoegang misbruikt om dit resultaat te bereiken. Tja...

Squee heeft dit trouwens al erg goed uitgelegd, dus dat ga ik niet nog eens doen:
Squee in 'nieuws: 'AMD Epyc-encryptie voor virtuele machines is te omzeilen''

Squee's post legt het inderdaad briljant uit

Dit soort exploits zijn, en nu zeg ik iets dat sommigen wellicht eng in de oren klinkt, normaal. Er zijn tal van dit soort exploits -en dus ook niet alleen op AMD CPU's- waar allerlei patches voor zijn. Het is ook weer een gevalletje waar de exploit pas werkt als men al diepgaande toegang tot het systeem in kwestie heeft. Dat kan in theorie ook door een HV die zelf een exploit heeft, maar dat kan dan ook gepatched worden.

Wat SEV verder betreft biedt het nog steeds een hoger niveau van beveiliging en is het gewoon een hele solide feature. Dit doet daar niets aan af in mijn ogen


@madmaxnl voorbeelden van untrusted hypervisors? Alles wat niet Xen, ESX(i), Hyper-V of Oracle VMS is

Dat kom je dus niet tegen bij een reputabele hosting provider.

[DaniëlWW2]

En aan de productiekant komt er ook steeds meer naar voren. Er wordt hier sterk gesuggereerd dat GoFlo haar 7nm procedé bewust heeft aangepast zodat AMD ook gebruik kan maken van TSMC voor Zen 2.

Later this year, GF will use immersion steppers to tape out its first 7-nm chip, an AMD processor. An IBM processor will follow with ASICs coming in 2019, said Patton.

GF made the size of its 7-nm pitches and SRAM cells similar to those of TSMC to let designers like AMD use both foundries. AMD “will have more demand than we have capacity, so I have no issues with that,” he said of AMD using the Taiwan foundry.

https://www.eetimes.com/d..._id=1333326&page_number=2

[Verwijderd]

madmaxnl schreef op zondag 27 mei 2018 @ 18:58:
Om het nog wat ongeloofwaardig te maken, op 10nm zeker? Daar hebben ze al enkele miljardjes op stuk geslagen

Naar het schijnt gaat Intel niet voor 2020 komen met een 10 nm. die beter presteert dan hun huidige 14++ , 2019 wordt een leuk jaar voor de CPU-afdeling van AMD.
Nu maar hopen dat het klopt dat die Zen2-CPU's 12/16 kernen bevatten. Stel je voor: 1,25*1,50 de performance van de 6900k 2,5 jaar later en voor <25-30% van de prijs. Sweet!
De Zen2-CPU's presteren single core in Cinebench gelijk met de Skylake-CPU's. Het gat tussen Skylake en Coffee Lake is alles wat overbrugd hoeft te worden.

[ Voor 30% gewijzigd door Verwijderd op 30-05-2018 00:02 ]

[EaS]

AMD Welcomes Cisco to the EPYC™ Processor Family:

“The addition of AMD to the Cisco UCS server portfolio marks a first for us as partners,” said Kaustubh Das, vice president, product management - Computing Systems, Cisco’s Data Center Business Group. “Leveraging the innovation of AMD EPYC, Cisco is bringing forth transformative technology that will enable our customers to accelerate compute-intensive workloads with a high-density server that can be managed from the cloud."

[Help!!!!]

Details AMD Ryzen 3 2300X en Ryzen 5 2500X duiken op

en

GlobalFoundries Gives 7 nm Capacity Update, Mulls Skipping 5 nm

[ Voor 37% gewijzigd door Help!!!! op 31-05-2018 18:46 ]

[Verwijderd]

Over Threadripper, Intel, 32-bit, 64-bit, geheugen kopiëren en compilers.

[EaS]

AMD verdrievoudigd aandeel in server markt:

There’s a new kid in town, too. AMD is slowly, and I do mean slowly, starting to come on. It shipped the Epyc processor to ODMs last summer, but unlike the desktop and laptop market, where new product comes to market in weeks, it takes months for new servers to come to market.

Epyc’s server market share, according to Mercury Research, is… 1%, said Dean McCarron, Mercury’s president. But a year ago AMD had a 0.3% share. So technically, yes, it’s tripled its share. “An important point to make is servers have a slow ramp. Volumes are doubling every quarter, so they are on an exponential ramp right now,” said McCarron.

[spNk]

TR2: 32 cores max 250Watt.
https://www.anandtech.com...2-cores-250w-x399-refresh
16 cores krijgen als ik het goed begrijp geen direct memory acces, ben benieuwd wat dat voor de prestaties betekend.

Die "notes" onder de tabel zijn ook wel interessant:

- Both the 24-core and 32-core sample CPUs are clocked at 3.0GHz base and 3.4GHz all-core turbo, with the latter being a work-in-progress according to the company.
- The 32-core system was equipped with DDR4-3200 memory. This is notable because the Ryzen processors based on the same 12nm Zeppelin dies officially max out at DDR4-2933.
- The codename for the processor family is listed as "Colfax". This is the first we've heard this codename from AMD.
- Despite the high TDP, both CPUs used in AMD's demos were air-cooled, using AMD's Wraith Ripper Air Cooler

[ Voor 57% gewijzigd door spNk op 06-06-2018 09:22 ]

[Fleximex]

spNk schreef op woensdag 6 juni 2018 @ 09:20:
TR2: 32 cores max 250Watt.

[DaniëlWW2]

Deze HEDT chips die vrijwel elke serverchip totaal declasseren, komen kennelijk ook nog eens met een koeler van AMD.

Zie hier de meest serieuze stock koeler ooit.

Verder lijkt de de implicaties van een 32 core HEDT ook dat AMD voor Epyc 2 doodleuk meer aan zal gaan bieden.

[ Voor 4% gewijzigd door DaniëlWW2 op 06-06-2018 12:57 ]

[spNk]

Toch vraag ik mij af... 250W afvoeren met een tower cooler?

[Blaat]

spNk schreef op woensdag 6 juni 2018 @ 13:25:
Toch vraag ik mij af... 250W afvoeren met een tower cooler?

Als dat ding een ingebouwde pomp heeft die vloeistof circuleert kan dat best.

[spNk]

Blaat schreef op woensdag 6 juni 2018 @ 13:28:
[...]


Als dat ding een ingebouwde pomp heeft die vloeistof circuleert kan dat best.

Hoezo? Vloeistof is in deze toch niet meer dan een geleider? Het koeloppervlak wordt er niks groter van?

[ Voor 49% gewijzigd door spNk op 06-06-2018 13:32 ]

[Blaat]

spNk schreef op woensdag 6 juni 2018 @ 13:31:
[...]

Hoezo? Vloeistof is in deze toch niet meer dan een geleider? Het koeloppervlak wordt er niks groter van?

Een 120mm AIO is in de praktijk ook voldoende om een 250w verstokende Vega64 van koeling to voorzien zodat hij onder de 65 graden blijft. En zo'n radiator heeft toch echt minder oppervlakte dan deze tower.

De grootste beperking van tower coolers is dat de warmte niet meer zo effectief over het totale koeloppervlak verspreid kan worden, wat in de regel dan ook een nadeel is dat actieve vloeistofkoeling niet heeft. Een radiator waar vloeistof doorheen circuleert is gewoon efficienter vanuit dat perspectief.

Het gaat niet alleen maar om oppervlakte.

[Help!!!!]

Anandtech: AMD Reveals Threadripper 2 : Up to 32 Cores, 250W, X399 Refresh

[ Voor 32% gewijzigd door Help!!!! op 06-06-2018 13:50 ]