::: AMD Zen Samlingstråd :::

2017-03-14 09:02

Avstängd

Plats: Skåne
Registrerad: Sep 2006

●

Skrivet av Oegat:

Då låter det som att nästa test som det vore intressant att se är om skillnaden mellan win10 och win7 vid 2CCX försvinner då core parking specifikt stängs av i 10. För att svara på frågan om detta är samma problem eller ett annat.

Gå till inlägget

Att det skulle vara Core Parking som är problemet är jag oerhört tveksam till. Jag gjorde en fräsch nyinstallation häromdagen av Win 10 och den parkerar definitivt inga kärnor.

Core Parking var väl endast aktuellt med Win 7 och Server 2008 R2?

Edit: Testade precis jobbdatorn, en E7250 med Win 10 Enterprise. Ingen Core Park igång.

Visa signatur

R7 3700X | X570 Aorus Master | 32GB | EVGA 1080 Ti FTW3 | Noctua NH-D15S | FD Meshify C Copper
R7 1700 | X370 Gaming-ITX | 16GB | RX Vega 64 LE | Noctua U12S | Node 304
2 x HPE ProLiant Microserver Gen 8 | 1265L V2 | 16GB | 20TB

Rapportera Redigera

Citera flera Citera

2017-03-14 09:02

Permalänk

Ratatosk

Hjälpsam ★

Plats: Karlskoga
Registrerad: Jan 2007

●

Skrivet av AMD:

By the first week of April, AMD intends to provide an update for AMD Ryzen™ processors that optimizes the power policy parameters of the Balanced plan to favor performance more consistent with the typical usage models of a desktop PC.

https://community.amd.com/community/gaming/blog/2017/03/13/am...

edit
Detta kunde väl AMD klämt ur sig på en gång.

1.The AMD Ryzen™ processor does not offer memory dividers for DDR4-3000 or DDR4-3400. Users shooting for higher memory clocks should aim for 3200 or 3500 MT/s.

8.AMD’s officially-supported DRAM configurations are below for your reference:

DDR4 Speed (MT/s)	Memory Ranks	DIMM Quantities
2667	Single	2
2400	Dual	2
2133	Single	4
1866	Dual	4

https://community.amd.com/community/gaming/blog/2017/03/14/ti...

Japp jag har minnen som har en XMS profil för 3000 MT/s, hoppas att UEFI är smart nog att ställa in det i 2933.

edit 2
Core parking kan vara positiv för singelcore prestanda.
https://www.reddit.com/r/Amd/comments/5z8gi1/request_some_qui...
https://www.reddit.com/r/Amd/comments/5yonzw/core_parking_and...

Senast redigerat 2017-03-14 09:48

Visa signatur

Rapportera Redigera

Citera flera Citera (7)

2017-03-14 09:07

Permalänk

Ratatosk

Hjälpsam ★

Plats: Karlskoga
Registrerad: Jan 2007

●

Skrivet av tellus82:

En sak som Ryzen ägare skulle kunna prova för att se hur det påverkar prestanda är att justera context switching clock ticks, normalt ligger denna på 2 i klient OS, på server ligger den normalt på 12 men det är inte jättelätt att få fram exakta siffror från MS på detta. Dock kan man ändra från lägst klock ticks till högst tillåtna genom att ändra:
"schemaläggning av processor" under Prestandaalternativ som finns under systemegenskaper. Normalt står denna på Program i win10 klient & på server står den på bakgrundstjänster, skillnaden ligger främst här i hur många klock ticks en tråd hålls kvar innan nästa släpps fram (förutsatt att bägge har samma prio), detta är inte bara bra åt ena eller andra hållet men det skulle vara lite intressant att se om det har någon inverkan på just ryzen när trådar hålls kvar längre vid liv innan nästa väntande tråd får tillträde, detta i sin tur skulle rent teoretiskt kunna sänka trådhoppandet en smula. Av naturliga skäl har det såklart en del negativa effekter också men det vore intressant ur ett rent teoretiskt perspektiv.

Edit: Man kan relativt enkelt prova genom att köra wPrime & en arbetstråd, ett scenario där du får konstant trådhoppande, på min intel burk gav det en negativ prestandaskalning med -0,3% att köra bakgrundstjänster på just wPrime med 1 tråd jämfört med "program". Det borde vara något liknande på de flesta burkar & skulle vara skoj ifall någon kunde prova på en Ryzen setup. Bara och köra ett par rundor & slå ut ett medel, ändra schemaläggarn & köra ett par igen & ta medel.

Gå till inlägget

Är ju väldigt enkelt att testa, men det blir först till helgen.
Körde ofta schemaläggning på bakgrund för ett par år sedan, men jag har låtit det vara på som det är på zenare.

Visa signatur

Rapportera Redigera

Citera flera Citera (2)

2017-03-14 09:10

Permalänk

marcusOCZ

Medlem ★

Plats: Trondheim, Norge
Registrerad: Feb 2005

●

https://www.youtube.com/watch?v=G_GXSV-Pquo

Där ser man en del vad Ryzen är god för som är väldigt aktuellt för många här inne. Hoppas det kommer fler liknande tester så att det inte bara är en källa.

Visa signatur

14900KF--Apex Encore--RTX 4090--G.Skill 2x24GB DDR5-8000--Dynamic Evo XL
12900K--Asrock Z790i--2X16GB DDR5 6000
Ljud: Lewitt Connect 6--Shure SM7B

Rapportera Redigera

Citera flera Citera (5)

2017-03-14 09:44

Permalänk

sAAb

Medlem ★

Plats: Stockholm
Registrerad: Jan 2007

●

Skrivet av Yoshman:

För att bygga på Ubuntu: tillräckligt ny C++ (använder C++11) samt GNU-make
Sedan ska detta räcka, antag att filen heter th_ping.cpp

make CXXFLAGS="-std=c++11 -O2 -pthread" th_ping

Behövs inga makefiler, GNU-make har implicita regler och dessa är fullt tillräckliga för detta program.

Detta är vad som borde hända på ubuntu 16.04

kenneth@skylake:~/th_ping$ make CXXFLAGS="-std=c++11 -O2 -pthread" th_ping
g++ -std=c++11 -O2 -pthread    th_ping.cpp   -o th_ping

Nu ska det finnas en körbar fil med namnet "th_ping"

Edit: verkar även fungera på RPi3.

kenneth@rpi3:~/programming/c++/th_ping $ make CXXFLAGS="-std=c++11 -O2 -pthread" th_ping
g++ -std=c++11 -O2 -pthread    th_ping.cpp   -o th_ping
kenneth@rpi3:~/programming/c++/th_ping $ ./th_ping
This system got 4 CPU-threads
 0 <-> 1  :  40 ns
 0 <-> 2  :  38 ns
 0 <-> 3  :  39 ns
 1 <-> 2  :  38 ns
 1 <-> 3  :  38 ns
 2 <-> 3  :  38 ns
kenneth@rpi3:~/programming/c++/th_ping $ file th_ping
th_ping: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32, BuildID[sha1]=38f7f12ef80f578a744062839f47fd4eea2f76a4, not stripped

Dold text

Gå till inlägget

Jag fick fortfarande inte make att fungera, men väl

g++ -std=c++11 -O2 -pthread th_ping.cpp   -o th_ping

Här kommer resultatet för en Q6600, som kanske liknar CCX i struktur.

$ ./th_ping
This system got 4 CPU-threads
0 <-> 1 : 191 ns
0 <-> 2 : 186 ns
0 <-> 3 : 80 ns
1 <-> 2 : 81 ns
1 <-> 3 : 186 ns
2 <-> 3 : 185 ns

Visa signatur

Rapportera Redigera

Citera flera Citera (1)

2017-03-14 09:50

Permalänk

Yoshman

Datavetare ★

Plats: Stockholm
Registrerad: Jun 2011

●

Skrivet av Oegat:

Jag har tänkt en del på schemaläggningsintervallet också. @Yoshman gav tidigare en beräkning som går ut på att overhead av trådflytt i sammanhanget är liten vid 16ms OS-ticks, men sen noterade jag detta:

Ryzen: Strictly technical #458

Slide 6 i listan, handlar om saker som påverkar powermanagement, dvs mest kända saker som redan diskuterats i tråden. Men jag noterar raden:

”Timeout intervals” är väl samma sak som OS ticks? Så Win10 game mode ökar eventklockans upplösning, jag antar för att ge högre responsivitet vilket kan gynna tex FPS-spel online. Jag vet inte hur universellt detta är eller när och hur läget aktiveras. Jag kan ha fel om hur ofta det sparkar in. Men om vi tittar på Yoshmans beräkning igen:

200 ms/ns är 20% overhead i extremfallet. Då är det fortfarande ett extremfall, men lägg en okänd faktor på det iom Ryzens speciella cachestruktur och inter-CCX-kommunikation. Nu tror jag ändå inte att denna aspekt av trådflytt kan ansvara för hela skillnaden mellan Win10 och Win7, men om trådflytt kan ske varje millisekund så är det en magnitudskillnad med en faktor 16 mot ”vanliga” OS-ticks.

Det finns också en del som tyder på att strömsparfunktionerna, som är vad AMDs slide ovan egentligen handlar om (och som är anledningen till att AMD rekommenderar test under High Performance powerscheme), interagerar med schemaläggningen. En skribent från strictly technical-tråden argumenterar för att det inte är schemaläggningsalgoritmen utan Win10s system för core parking som ställer till det, vilken i sin tur förser schemaläggaren med invärden (vilka cores som är tillåtna att schemalägga). Sammanfattat här: https://www.reddit.com/r/Amd/comments/5yonzw/core_parking_and...

Strömsparfunktionerna interagerar alltså med eventtimern, och en högfrekvent sådan kan skapa prestandatapp i anslutning till powermanagement enligt AMDs egna tester (vilka jag antar utförts med 2 CCX aktiva).

Jag undrar därför om någon testat om prestandatappet i Win10 jämfört med Win7 (i förekommande fall) kvarstår vid likvärdig eventtimerupplösning? Har man kontrollerat för detta i de speltester som specifikt jämför Win10 och Win7?

Om eventtimern är boven så skulle det kunna innebära två saker:

Att schemaläggarna såväl som strömsparfunktionerna i Win10 och Win7 är precis lika dåliga för Ryzen, men Win10 råkar vara effektivare på att göra sin dåliga grej, då OSet har möjlighet att lägga sig i oftare (varje ms jämfört med var 16e ms).
Den lilla men stabila absoluta skillnaden mellan Win7 och Win10 vid 1st CCX kan bero på ett generellt OS overhead till följd av den högfrekventa eventtimern, som kan interagera med processorarkitekturen och därför vara mer utpräglat på vissa processorer (tex Ryzen). Ett generellt prestandafall är att vänta med snabbare OS-events, något vi också ser med lowlatency-kernelinställningar i Linux.

Som vanligt kan min hypotes redan ha uteslutits, då jag inte i primärt följer testerna för spelprestanda i detalj. Jag vet att HPET = off är ett förslag på prestandaoptimering för Ryzen som kom tidigt, och kanske något alla testare redan kör med, så min hypotes kanske redan är falsifierad. Men det är en kandidat på något som skiljer sig systematiskt mellan Win10 och Win7, inte huruvida HPET är aktiverat utan huruvida den ges inflytande över OS (jag förutsätter alltså att HPET=off omöjliggör 1ms upplösning, så körs de relevanta testerna med HPET avstängt så faller min hypotes).

Gå till inlägget

Timers och OS-ticks är logiskt sett två helt separata saker. Men p.g.a. implementationstekniska detaljer finns det beröringspunkter mellan dessa.

För att helt kunna förklara detta måste man tyvärr introducera lite fler koncept.

Windows schemaläggare jobbar egentligen inte med OS-ticks utan med vad man kallar "quantum", kvanta. Sedan Windows 8 har inte Windows en tick-counter som körs hela tiden, utan precis som Linux/OSX kör Windows nu med s.k. "tickless kernel".

Ovanpå detta tillkommer klockor som kan mäta aktuell tid med hög noggrannhet, t.ex. HPET, TSC och ART. Dessa är helt frikopplade från timeouts i OS-anrop och frikopplade från schemaläggaren i OS. Poängen med dessa är deras upplösning, typiskt 1 ns eller bättre!

HPET kan generera avbrott, hanteraren för detta avbrott kan t.ex. väcka upp en OS-tråd. Så indirekt kan HPET påverka schemaläggning, men Windows kärnan använder själv inte HPET. TSC och ART är båda passiva, de genererar inte avbrott men deras upplösning är typiskt ett CPU-tick motsvarande basklockfrekvensen så sub-nanosekunder upplösning.

Är ju fortfarande så att schemaläggaren måste ha lite fasta referenspunkter att förhålla sig till, därför finns det fortfarande ett virtuellt tick som ligger till grund för schemaläggningsbesluten. I desktop Windows är normala upplösningen för timeouts 15,6 ms (vilket blir 16 ms i heltal och det var också resultatet mitt Windows 10 rapporterade).

En OS-tråd som är CPU-bunden och därför inte frivilligt ger upp CPUn (vilket blir fallet i ett spel om det är CPU-bundet) får i normalfallet köra ostört i två kvanta, d.v.s. 15,6 * 2 = ~30 ms. Så mitt "worst-case" överdrev overhead med en faktor två om man kör en normalt konfigurerad Windows.

OK, men vad händer då om en applikation ändrar upplösningen på OS-timern? Förutsatt att alla program har samma prioritet så kommer OS-schemaläggaren fortfarande bara ta ett nytt beslut vartannat kvanta, d.v.s är fortfarande 30 ms mellan fallen när trådar kan tänkas hoppa mellan CPU-kärnor.

MEN, och detta är ett väldigt viktigt men, Windows är främst designat som ett interaktivt OS. En sak Windows gör är att dynamiskt öka prioriteten på OS-trådar som självmant lägger sig att sova innan de använt upp sitt kvanta. När en sådan OS-tråd blir körbar igen, ta t.ex. Chrome som är ett exempel på applikation som ökar upplösningen på timers, har den högre prioritet än en OS-tråd som är CPU-bunden -> blir kontext-switch direkt.

Så har man mycket program som ligger i bakgrunden så kan det i sig orsaka hopp mellan CPU-trådar, i värsta fall med en frekvens långt högre än vartannat kvanta! Om man värderar låg FPS-varians ska man därför stänga ner onödiga program, det vare sig om man har två, fyra, åtta eller 44 kärnor i sitt system.

Ju fler CPU-kärnor man har desto mindre frekvent vill man egentligen köra schemaläggaren då kostnaden både för CPU-trådmigration och balansering mellan kärnor ökar. Windows Server kör därför normalt 12 (i stället för 2) kvanta innan schemaläggaren tvingas köras. Det ökar kapaciteten, men försämrar responsen för interaktiva program.

Och det är orsaken till att jag argumenterar för att en CPU som främst ska användas interaktivt ska prioritera enkeltrådprestanda över allt annat, färre starkare kärnor ger bästa interaktiva respons. En CPU som ska agera server eller tugga siffror under lång tid ska däremot med fördel ges fler kärnor, även om det är på bekostnad av något sämre enkeltrådprestanda.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Rapportera Redigera

Citera flera Citera (9)

2017-03-14 10:07

Permalänk

Flopper

Avstängd

Plats: Vännäs
Registrerad: Jul 2002

●

Skrivet av Yoshman:

Om det är någon tröst i folks AMD vs Intel korståg är min övertygelse att svärmen med företag som använder ARM (eller möjligen RISC-V) kommer i slutändan "vinna" över båda dessa företag. x86 designer är allt för komplicerade att validera så AMD/Intel kommer få en näst intill omöjligt uppgift att hänga med allt eftersom ARM-designerna blir kraftigare. D.v.s. vi kommer få en repris på hur x86 slog ut de mer avancerade (och dyrare) RISC CPUer under 90-talet, om det tar 10 eller 30 år vet jag inte men det kommer hända.

Spelutvecklare kan absolut optimera för någon som CCX designen, det görs ju redan idag på konsolerna som har en väldigt snarlik design.

Gå till inlägget

börjar ju bli kris med transistor storlekar, de mindre rymmer ju inte så mycket.
att följa nästa steg bortom 14n/10nm blir intressant

Visa signatur

Träna bort dyslexin. Ryzen 3600 - asus B350plus - Msi Vega56 - Acer 1440p 144hz - M.2 ssd - asus essence stx - Sennheiser hd600 - Corsair 750w - 16gb ram 3ghz - atcs 840 - luftkylt - Felsökning? (Lär dig Googla)

Rapportera Redigera

Citera flera Citera (2)

2017-03-14 10:09

Permalänk

Yoshman

Datavetare ★

Plats: Stockholm
Registrerad: Jun 2011

●

Skrivet av sAAb:

Jag fick fortfarande inte make att fungera, men väl

g++ -std=c++11 -O2 -pthread th_ping.cpp   -o th_ping

Här kommer resultatet för en Q6600, som kanske liknar CCX i struktur.

$ ./th_ping
This system got 4 CPU-threads
0 <-> 1 : 191 ns
0 <-> 2 : 186 ns
0 <-> 3 : 80 ns
1 <-> 2 : 81 ns
1 <-> 3 : 186 ns
2 <-> 3 : 185 ns

Gå till inlägget

OK, kan ju kvitta om make fungerar eller ej. Men rätt skumt... Inte så att du har något annat än GNU-make installerat? För det jag skrev bygger på att man kör just GNU-make som har en rad implicita regler som ofta faktiskt gör att man kan klara sig utan eller med extremt enkla makefiler.

Intressant numrering på Q6600, verkar som 0 och 3 respektive 1 och 2 delar L2$.

Sedan är det så att delad L2$ inte alltid är det enda sättet att få lägsta latens. Kolla in resultatet för Z3770 (Silvermont Atom, två kärnor delar L2$, ingen L3$ och är totalt fyra kärnor).

This system got 4 CPU-threads
 0 <-> 1  : 121 ns
 0 <-> 2  :  84 ns
 0 <-> 3  :  83 ns
 1 <-> 2  :  84 ns
 1 <-> 3  :  84 ns
 2 <-> 3  : 118 ns

Här är alltså latensen HÖGRE mellan de två kärnor som delar L2$ (0 och 1 samt 2 och 3) än mellan de som bara delar RAM. I detta läge finns antagligen någon logik för att skicka information mellan kärnor i kretsen + Silvermont har ett extremt simpelt sätt att hantera x86 strikta minneskonsistensmodell: är typ skriv A B C. Om skrivningen på A av någon anledning "stallar", t.ex. cache-miss, så slänger man bara in A B C i en ring-buffer. Varje varv kollar man om A nu kan skrivas, när svaret är "ja" testar man B etc.

RPi3 (ARM Cortex A53) demolerar verkligen Silvermont på denna punkt, halva latensen (nu kör jag i.o.f.s relaxed memory ordering, det gynnar ARM mer än x86, lägger på ~7 ns för ARM om man går till "sequentially consistent" memory ordering).

Allt detta gör inte Ryzen till en dålig CPU, precis som allt annat har konstruktörerna gjort avvägningar. Dessa avvägningar gör den mindre lämpad för vissa uppgifter och mer lämpad för andra.

Ryzen är ruggigt bra på skalära flyttal, CCX-designen ger skalbarhet och den är ingen nackdel för saker där det är lite kommunikation mellan kärnor (något som är relativt vanligt i just flyttalsintensiva program).

Core är brutal på sådant som kan vektoriseras och lysande på skalära heltal. Man ser också att core-to-core latensen är lägre i S-modellerna än i E- och E5. Enkelt att förstå på en teknisk nivå och vettigt när man tänker på målmarknader för respektive krets.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Rapportera Redigera

Citera flera Citera (3)

2017-03-14 10:12

Permalänk

Vesh

Medlem ★

Plats: Lund
Registrerad: Jul 2011

●

Skrivet av murklor:

Så för att summera det så är AMDs bästa gaming CPU den sämsta Ryzen överclockad med hälften av kärnorna avstängda, lol.

Gå till inlägget

Intels vassaste spelprocessor ligger inte i entusiastklassen och består till mer än 33% död yta för en GPU som inte kan driva spel speciellt bra, lol.

Rapportera Redigera

Citera flera Citera (7)

2017-03-14 10:12

Permalänk

Ratatosk

Hjälpsam ★

Plats: Karlskoga
Registrerad: Jan 2007

●

@Yoshman: Appropå tickless kernel.

Skrivet av AMD:

Update Your Firmware
Ensure that you are using the latest UEFI ROM for your motherboard.
1.The latest ROMs will support the Windows 10 tickless kernel for best application performance.
2.Newer ROMs can improve the functionality/stability of your motherboard and its UEFI menu options.

https://community.amd.com/community/gaming/blog/2017/03/14/ti...

Tror att det inte finns någon perfekt lösníng för;
1. Singeltrådprestanda.
2. Multitrådprestanda.
3. Energieffektivitet.
Vi kommer att få finna oss i att man måste kompromissa.
Sjäv satsar jag främst på ett energisnålt system.
Läste tidigare att du var inne på att skaffa Ryzen, är det fortfarande aktuellt? eller väntar du på att den första oredan skall lägga sig.

Visa signatur

Rapportera Redigera

Citera flera Citera (3)

2017-03-14 10:30

Permalänk

Yoshman

Datavetare ★

Plats: Stockholm
Registrerad: Jun 2011

●

@Ratatosk: min plan är fortfarande att skaffa en R7 1700, kommer köpa in den på mitt företag så är ju nästan "gratis"
Men väntar till problemen med Ubuntu lagt sig, har tänkt köra Ubuntu server på det systemet.

Är uppenbart att det inte finns en bästa design längre. Avancerade användare kommer allt mer behöva förstå sitt eget användarmönster för att förstå vilket val som är bäst för dem.

Den stora massan har i de flesta fall sedan länge passerat "tillräckligt bra" oavsett val. Det är också orsaken till att jag är övertygad att ARM (eller möjligt RISC-V som faktiskt är ännu enklare än ARM samt helt öppet) i slutändan kommer "vinna", det är helt enkelt billigare att hantera dessa för tillverkarna. Har ju varit en del skriverier om att "riktiga" Windows kommer till ARM samt att nu även Windows-server ska komma till ARM.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Rapportera Redigera

Citera flera Citera (9)

2017-03-14 10:30

Permalänk

sAAb

Medlem ★

Plats: Stockholm
Registrerad: Jan 2007

●

Skrivet av Yoshman:

OK, kan ju kvitta om make fungerar eller ej. Men rätt skumt... Inte så att du har något annat än GNU-make installerat? För det jag skrev bygger på att man kör just GNU-make som har en rad implicita regler som ofta faktiskt gör att man kan klara sig utan eller med extremt enkla makefiler.

Gå till inlägget

# make -v
GNU Make 4.1
Built for x86_64-pc-linux-gnu
Copyright (C) 1988-2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Visa signatur

Rapportera Redigera

Citera flera Citera

2017-03-14 10:39

Permalänk

sAAb

Medlem ★

Plats: Stockholm
Registrerad: Jan 2007

●

Skrivet av Yoshman:

@Ratatosk: min plan är fortfarande att skaffa en R7 1700, kommer köpa in den på mitt företag så är ju nästan "gratis"
Men väntar till problemen med Ubuntu lagt sig, har tänkt köra Ubuntu server på det systemet.

Är uppenbart att det inte finns en bästa design längre. Avancerade användare kommer allt mer behöva förstå sitt eget användarmönster för att förstå vilket val som är bäst för dem.

Den stora massan har i de flesta fall sedan länge passerat "tillräckligt bra" oavsett val. Det är också orsaken till att jag är övertygad att ARM (eller möjligt RISC-V som faktiskt är ännu enklare än ARM samt helt öppet) i slutändan kommer "vinna", det är helt enkelt billigare att hantera dessa för tillverkarna. Har ju varit en del skriverier om att "riktiga" Windows kommer till ARM samt att nu även Windows-server ska komma till ARM.

Gå till inlägget

Den där 48-kärniga "Falkor" kommer ju att bråka med Naples också.

https://www.extremetech.com/computing/245496-qualcomm-announc...

Visa signatur

Rapportera Redigera

Citera flera Citera (1)

2017-03-14 10:42

Permalänk

Ratatosk

Hjälpsam ★

Plats: Karlskoga
Registrerad: Jan 2007

●

@Yoshman: R7 1700 är en riktigt trevlig CPU, ett stort bonus är att den är så effektsnål, dess originalkylare är rikigt bra och duger mer än väl om man inte klockar.
Vid ett stresstest med CPU-z på alla kärnor, drog min mindre än 65W och tempen höll sig väl under 60 grader, detta med tyst läge på fläkten.
Behöver jag säga att det är sällan den kommer att använda kärnorna så mycket? vid normal belastning kommer den dra betydligt mindre än så.

Visa signatur

Rapportera Redigera

Citera flera Citera (3)

2017-03-14 10:43

Permalänk

Yoshman

Datavetare ★

Plats: Stockholm
Registrerad: Jun 2011

●

Skrivet av sAAb:

Den där 48-kärniga "Falkor" kommer ju att bråka med Naples också.

https://www.extremetech.com/computing/245496-qualcomm-announc...

Gå till inlägget

Även Cavium petar ju i detta, man lanserade relativt nyligen sin ThunderX2 plattform med upp till 54 64-bitars ARM kärnor.

Förstår fortfarande inte make-problemet, vi kör ju exakt samma version av make!

make -v
GNU Make 4.1
Built for x86_64-pc-linux-gnu
Copyright (C) 1988-2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

RPi3 körde 4.0 och borde inte vara kinkigt med version då jag använt detta i över tio år...

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Rapportera Redigera

Citera flera Citera

2017-03-14 10:50

Permalänk

anon78208

Inaktiv

Registrerad: Dec 2005

●

1700 rapporterar tydligen temperatur annorlunda jämfört med 1700X och 1800X. Intressant
http://www.guru3d.com/news-story/amd-ryzen-7-have-a-temperatu...

Rapportera Redigera

Citera flera Citera

2017-03-14 10:58

Permalänk

sAAb

Medlem ★

Plats: Stockholm
Registrerad: Jan 2007

●

Skrivet av Yoshman:

Även Cavium petar ju i detta, man lanserade relativt nyligen sin ThunderX2 plattform med upp till 54 64-bitars ARM kärnor.

Förstår fortfarande inte make-problemet, vi kör ju exakt samma version av make!

make -v
GNU Make 4.1
Built for x86_64-pc-linux-gnu
Copyright (C) 1988-2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

RPi3 körde 4.0 och borde inte vara kinkigt med version då jag använt detta i över tio år...

Gå till inlägget

Jag copy-pastade

make CXXFLAGS=\"-std=c++11 -O2 -pthread\" th_ping

in i prompten som user, men får svar som börjar med

$ make CXXFLAGS=\"-std=c++11 -O2 -pthread\" th_ping
make: invalid option -- 'a'
make: invalid option -- '"'
Usage: make [options] [target] ...

och slutar med

# Pattern-specific Variable Values

# No pattern-specific variable values.

# Directories

# No files, no impossibilities in 0 directories.

# Implicit Rules

# No implicit rules.

# Files

# Not a target:
th_ping:
#  Command line target.
#  Implicit rule search has not been done.
#  Modification time never checked.
#  File has not been updated.

# files hash-table stats:
# Load=1/1024=0%, Rehash=0, Collisions=0/1=0%
# VPATH Search Paths

# No 'vpath' search paths.

# No general ('VPATH' variable) search path.

# strcache buffers: 1 (0) / strings = 1 / storage = 8 B / avg = 8 B
# current buf: size = 8162 B / used = 8 B / count = 1 / avg = 8 B

# strcache performance: lookups = 2 / hit rate = 50%
# hash-table stats:
# Load=1/8192=0%, Rehash=0, Collisions=0/2=0%
# Finished Make data base on Tue Mar 14 10:55:11 2017

Jo, det är OT här...

Visa signatur

Rapportera Redigera

Citera flera Citera

2017-03-14 11:08

Permalänk

marcusOCZ

Medlem ★

Plats: Trondheim, Norge
Registrerad: Feb 2005

●

Skrivet av Ratatosk:

@Yoshman: R7 1700 är en riktigt trevlig CPU, ett stort bonus är att den är så effektsnål, dess originalkylare är rikigt bra och duger mer än väl om man inte klockar.
Vid ett stresstest med CPU-z på alla kärnor, drog min mindre än 65W och tempen höll sig väl under 60 grader, detta med tyst läge på fläkten.
Behöver jag säga att det är sällan den kommer att använda kärnorna så mycket? vid normal belastning kommer den dra betydligt mindre än så.

Gå till inlägget

1700,1700x och 1800x har precis samma effekt per clock. Bara AMD som har programmerat offset på x-modellerna till att visa 20c för mycket.

Visa signatur

14900KF--Apex Encore--RTX 4090--G.Skill 2x24GB DDR5-8000--Dynamic Evo XL
12900K--Asrock Z790i--2X16GB DDR5 6000
Ljud: Lewitt Connect 6--Shure SM7B

Rapportera Redigera

Citera flera Citera

2017-03-14 11:13

Permalänk

Sisyfos

Entusiast ★

Plats: Linköping
Registrerad: Mar 2012

●

Skrivet av Yoshman:

@Ratatosk: min plan är fortfarande att skaffa en R7 1700, kommer köpa in den på mitt företag så är ju nästan "gratis"
Men väntar till problemen med Ubuntu lagt sig, har tänkt köra Ubuntu server på det systemet.

Är uppenbart att det inte finns en bästa design längre. Avancerade användare kommer allt mer behöva förstå sitt eget användarmönster för att förstå vilket val som är bäst för dem.

Den stora massan har i de flesta fall sedan länge passerat "tillräckligt bra" oavsett val. Det är också orsaken till att jag är övertygad att ARM (eller möjligt RISC-V som faktiskt är ännu enklare än ARM samt helt öppet) i slutändan kommer "vinna", det är helt enkelt billigare att hantera dessa för tillverkarna. Har ju varit en del skriverier om att "riktiga" Windows kommer till ARM samt att nu även Windows-server ska komma till ARM.

Gå till inlägget

Angående det här med ARM's framåtmarsch, varför har inte riktigt strömtörstiga monster till ARM-processorer gjorts än? Varför bara på x86?

Är det så enkelt att det är för att ARM bara använts ihop med mobila/lättare operativsystem än så länge och att det behovet inte har funnits?

Skickades från m.sweclockers.com

Visa signatur

Den digitala högborgen: [Fractal Design Meshify C] ≈ [Corsair RM850x] ≈ [GeForce RTX 3080] ≈ [AMD Ryzen 7 7800X3D ≈ [Noctua NH-U14S] ≈ [G.Skill Flare X5 32GB@6GHz/CL30] ≈ [MSI MAG B650 TOMAHAWK] ≈ [Kingston Fury Renegade 2 TB] ≈

Rapportera Redigera

Citera flera Citera (1)

2017-03-14 11:20

Permalänk

wowsers

Medlem

Registrerad: Jul 2015

●

Skrivet av anon78208:

1700 rapporterar tydligen temperatur annorlunda jämfört med 1700X och 1800X. Intressant
http://www.guru3d.com/news-story/amd-ryzen-7-have-a-temperatu...

Gå till inlägget

Jag undrar vad som händer om detta hindrar OC, om CPU'n slappnar av tidigare än vad den borde?

Visa signatur

"Oh glorious cheeseburger… we bow to thee. The secrets of the universe are between the buns..."
"All my farts come straight from hell, you're already dead if you notice a smell"

Rapportera Redigera

Citera flera Citera (1)

2017-03-14 11:21

Permalänk

Ratatosk

Hjälpsam ★

Plats: Karlskoga
Registrerad: Jan 2007

●

Skrivet av marcusOCZ:

1700,1700x och 1800x har precis samma effekt per clock. Bara AMD som har programmerat offset på x-modellerna till att visa 20c för mycket.

Gå till inlägget

Så är det, vid underklockning kan en R1800x mycket väl dra mindre effekt, men eftersom en 1700 är lägre klockad, så drar den oklockad mindre effekt, spänningen och frekvensen är lägre, inget konstigt.
Den medföljande kylaren är också trevlig, som sagt.

Offseten är en annan historia, den används för att dra upp hastigheten på fläktarna mer, på X modellerna.

Visa signatur

Rapportera Redigera

Citera flera Citera (1)

2017-03-14 11:27

Permalänk

wowsers

Medlem

Registrerad: Jul 2015

●

Skrivet av Sisyfos:

Angående det här med ARM's framåtmarsch, varför har inte riktigt strömtörstiga monster till ARM-processorer gjorts än? Varför bara på x86?

Är det så enkelt att det är för att ARM bara använts ihop med mobila/lättare operativsystem än så länge och att det behovet inte har funnits?

Skickades från m.sweclockers.com

Gå till inlägget

I servermiljöer är strömsnålhet (oftast) mer viktigt än maximal prestanda, och som Linus Torvalds har sagt har x86 redan infrastrukturen på desktop marknaden. Om ARM eller RISC-V plötsligt skulle få konsumentkort som "bara fungerade" som x86 gör med alla extra grejer som RGB belysning och plug 'n play saker skulle det inte vara några problem, men då måste man också ha mjukvarustöd som inte finns för tillfället. (vet ej inte hur högt man kan klocka en ARM CPU för att den ska prestera lika bra som x86 heller)

Senast redigerat 2017-03-14 12:50

Visa signatur

"Oh glorious cheeseburger… we bow to thee. The secrets of the universe are between the buns..."
"All my farts come straight from hell, you're already dead if you notice a smell"

Rapportera Redigera

Citera flera Citera

2017-03-14 13:00

Permalänk

wowsers

Medlem

Registrerad: Jul 2015

●

Skrivet av Ratatosk:

https://community.amd.com/community/gaming/blog/2017/03/13/am...

edit
Detta kunde väl AMD klämt ur sig på en gång.

1.The AMD Ryzen™ processor does not offer memory dividers for DDR4-3000 or DDR4-3400. Users shooting for higher memory clocks should aim for 3200 or 3500 MT/s.

8.AMD’s officially-supported DRAM configurations are below for your reference:

DDR4 Speed (MT/s)	Memory Ranks	DIMM Quantities
2667	Single	2
2400	Dual	2
2133	Single	4
1866	Dual	4

https://community.amd.com/community/gaming/blog/2017/03/14/ti...

Japp jag har minnen som har en XMS profil för 3000 MT/s, hoppas att UEFI är smart nog att ställa in det i 2933.

edit 2
Core parking kan vara positiv för singelcore prestanda.
https://www.reddit.com/r/Amd/comments/5z8gi1/request_some_qui...
https://www.reddit.com/r/Amd/comments/5yonzw/core_parking_and...

Gå till inlägget

Dom har iaf officiellt stöd för upp till 2667 MHz, Intel har ju bara officiellt stöd för 2133/2400 MHz

Visa signatur

"Oh glorious cheeseburger… we bow to thee. The secrets of the universe are between the buns..."
"All my farts come straight from hell, you're already dead if you notice a smell"

Rapportera Redigera

Citera flera Citera

2017-03-14 13:19

Permalänk

tellus82

Medlem ★

Plats: Sälen
Registrerad: Maj 2004

●

Skrivet av Oegat:

Intressant! Om det är timern borde vi alltså se samma prestandaprofil för Ryzen i win8 som i win10, och det räcker med att ett program som körs tycker att det ska ha hög timer för att hela systemet ska få det. Men är denna siffra relaterad till HPET-inställningen i bios alls? Jag trodde HPET var fix på 1000Hz men här går det uppenbarligen att ha en eventfrekvens på 2000Hz (0.5ms). Det skulle kunna betyda att det är någon annan klocka som används och att HPET är oskyldig, men det verkar också lite underligt. Det låter i vilket fall som att ett tredjepartsprogram som forcerar timern globalt likt det du länkar hade varit användbart i win10, åtminstone för de spel som inte har stor nytta av hög inputprecision.

Då låter det som att nästa test som det vore intressant att se är om skillnaden mellan win10 och win7 vid 2CCX försvinner då core parking specifikt stängs av i 10. För att svara på frågan om detta är samma problem eller ett annat.

Gå till inlägget

Har kollat lite mer och det är precis som du säger att med HPET igång så är det 1000Hz som gäller eller 1ms tick rate, med HPET av är det 0,5ms om invariant TSC används (alltså hårdvara stödjer det, inte helt säker på namnet där). Endast vid rent idlande vid tomt skrivbord hamnar man på 15.625ms. Yoshman verkar ha skrivit något eget program som inte ändrar timern utan behåller idle timern vilket ger en mycket felaktig bild av hur timern egentligen fungerar under load, i windows 10 så är det som sagt dynamiskt och nästan alla tunga program jag testat hitintills (spel och liknande) använder lägsta tillgängliga timer/högsta frekvens. Alltså för HPET av så 0,5ms, kan vara ännu lägre på Ryzen då HPET avslagen fortfarande använder en timer, den som finns inbyggd direkt i cpu'n.

Anledningen till att jag själv kör utan HPET är att drivarn till mitt ljudkort verkar få tuppjuck av och till vid 1ms res timer (förväxlar kanaler av sig själv), med HPET avslaget och 0,5ms så har jag inga sådana problem. Det sägs att 0,5ms kan förbättra DPC latency för många moderkort också och det kan vara något sådant som händer i mitt fall, måste kolla mer noggrant på den och vad som händer. Jag har dock mindre stutter & bättre prestanda i spel med 0,5ms på min intel burk.

Förmodligen spelar resolution timern in på hur Ryzens olika p states funkar speciellt med tanke på att man rekommenderat att slå av HPET under benchmarks och specifikt nämner just att p state hanteringen då kan reagera snabbare. Rent tekniskt sett ska dock inte windows 8-10 använda HPET om inte någon specifik applikation inte begär det, antivirus och klockningsverktyg brukar generellt göra det. För att vara säker på att HPET inte används kan man stänga av det i bios/uefi och stänga av det med ett kommando för bcdedit om det finns tillagt i winboot, standard win10 konfig är att det inte finns tillagt. Så rent stock så kan windows använda HPET om program frågar efter det om det dessutom är påslaget i bios, är det inte det så kommer det fortsätta använda de andra tillgängliga timers. HPET är lite av en relik idag vad det verkar.

Som jag sa tidigare så kommer detta definitivt påverka hur ofta trådförflyttning sker för även om quantum värdet är separat så bestäms fortfarande slutgiltiga tiden på quantum värdet genom resolution timern och quantum värdet tillsammans. Vid 1ms timer så blir q värdet i slutändan 6ms på saker i förgrund i windows klient OS. Tråden har alltså möjlighet att köra hela quantum värdet*timer upplösningen innan något annat med samma prio ges tillträde i schedulern.

bcdedit /set disabledynamictick yes
Detta kommando ger ett fast värde på resolution timer från och med windows 8 och då bör det kunna kontrolleras med hjälp av programmet jag tidigare länkade till. En sak till som ska kunna ändras i bcdedit är policyn för TSC timern, exakt hur dessa lägen arbetar verkar inte ms gå in i detalj på direkt "tscsyncpolicy [ Default | Legacy | Enhanced ]". Sen har man då kommandot för att stänga av HPET om den ligger som plattformsklocka (inte standard att den gör det) men om den gör det i ditt fall så är det följande kommando som tar bort det.
bcdedit /deletevalue useplatformclock
Dock så kan som sagt HPET timern fortfranade användas av program som specifikt ber om det om man inte också slår av det i BIOS/UEFI

Om man vill köra dynamisk timer igen så kör
bcdedit /deletevalue disabledynamictick

Om man kör
bcdedit /enum BOOTMGR
eller
bcdedit /enum OSLOADER
eller bara
bcdedit
så får man upp en lista med alla entries för bootmgr & winloadern, har man inte "useplatformclock" med i listan så används inte heller HPET som standard, igen, detta betyder inte att HPET inte kan begäras av applikation utan bara att den inte är standard timern, det i sig är fullt normalt på win10. Vill man förhindra att HPET används alls så är det som sagt bara att slå av i moderkortets bios/uefi.

Edit:
Det absolut enklaste man som Ryzen ägare kan göra för att kolla hur alla dessa saker påverkar prestanda i slutändan är att köra wPrime med 1 tråd, för att sedan kolla hur det eventuellt påverkar trådförflyttning är att jämföra de första resultatet med en ny runda i wPrime fast med låst affinity till en av kärnorna, gärna en fysisk sådan.
wPrime verkar råka ut för konstant trådförflyttning om man kör färre arbetstrådar än vad man har logiska kärnor, något som teoretiskt inte är till fördel för Ryzen. Så det är i sig ett bra scenario att testa tweaks på quantum värde & resolution timer. Om man vill kan man köra ännu fler trådar men det förenklar lite att bara köra en när man sedan ska låsa ner cpu affinity

Edit2: för alla som tjötar om corepark på Ryzen så rekommenderar jag
https://bitsum.com/parkcontrol/
Med detta ser man direkt om corepark är aktiverat för de olika energischeman, normalt är corepark inte aktiverat för balanserat eller hög prestanda schemat. Här kan man också slå på & av core park för en till alla kärnor och justera frekvensskalning

Edit 3:
OBS! Att ändra tillgänglighet av HPET kan ställa till det för program som bitdefender och liknande, det går utmärkt att köra utan HPET om man installerar bitdefender utan HPET från början men ta inte bort det för en befintlig installation som tidigare kört HPET, då måste man installera om bitdefender eller slå på HPET

Senast redigerat 2017-03-14 14:07

Visa signatur

Rapportera Redigera

Citera flera Citera (3)

2017-03-14 16:52

Permalänk

sAAb

Medlem ★

Plats: Stockholm
Registrerad: Jan 2007

●

Skrivet av murklor:

Så för att summera det så är AMDs bästa gaming CPU den sämsta Ryzen överclockad med hälften av kärnorna avstängda, lol.

Gå till inlägget

Det är samma för Intel.

i7-6900K som kostar 12 000 Kr är sämre än i7-6700K som kostar drygt 3000 Kr också i vissa spel, de som gillar frekvens mer än kärnor.

Visa signatur

Rapportera Redigera

Citera flera Citera (5)

2017-03-14 17:03

Permalänk

sAAb

Medlem ★

Plats: Stockholm
Registrerad: Jan 2007

●

Skrivet av Ratatosk:

Fått en avisering om att de är på gång nu, dock inte lämnat Webhallen än.
Beställde förra veckan.
Vi får se, jag ropar inte hej, innan jag har dem i handen.

Gå till inlägget

Skrivet av Ratatosk:

https://community.amd.com/community/gaming/blog/2017/03/13/am...

edit
Detta kunde väl AMD klämt ur sig på en gång.

1.The AMD Ryzen™ processor does not offer memory dividers for DDR4-3000 or DDR4-3400. Users shooting for higher memory clocks should aim for 3200 or 3500 MT/s.

8.AMD’s officially-supported DRAM configurations are below for your reference: