Forum Datorkomponenter Processorer, moderkort och minnen AMD Tråd Inlägg

::: AMD Zen Samlingstråd :::

183 184 185 186 187 188 189 190
Skriv svar
Permalänk
Medlem ★
●
Skrivet av Ratatosk:

För en datanörd är Ryzen som en våt dröm som blivit sann, äntligen åtta kraftfulla kärnor till ett riktigt bra pris!
Man kan slänga på nästan vilken last som helst på denna maskin den kommer inte att storkna.
Jag är euforisk!

Gå till inlägget

Jag byggde ihop min igår (1800x, galleri kommer) men har knappt hunnit testa den ännu.
Däremot byggde jag ihop min systersons Ryzen-rigg förra veckan (1700x) och den skyfflar data ganska bra.

Visa signatur

Akashiro 0.9: Ryzen 5 7600, Radeon RX 7800XT Pure: 64/2000
https://podcasters.spotify.com/pod/show/thomaseron

Redigera
Citera flera Citera
Permalänk
Datavetare ★
●
Skrivet av Enigma:

Just deal with it... Vilken comeback! Oj... Kan bara hålla med @Stoff3th3m4n här. För att du säger att det ska vara så medans andra utöver du själv kanske upptäcker fenomen som inte stämmer med din subjektivitet eller erfarenhet, för det är så du reagerar i alla större diskussioner med andra medlemmar i andra trådar som jag sett och tagit mig tid att läsa igenom. Det blir fort enorma diskussioner som är mer "min åsikt är rätt" när det handlar om fler variabler. Ryzens L2 cache är en stor faktor till dess höga IPC, just deal with it! Ryzen's L3 cache är nästan exkluderande men har hooks/tags via sin fabric för att sniffa data, och inte via RAM, dvs lägre latens än att gå via RAM.

Du själv är inte speciellt nyanserad av dig och vill samtidigt anklaga andra för att glorifiera en produkt eller märke. Det va att slå stort på trumman och inget jag förväntade mig av dig. Samma sak när jag tog up Killer NIC, då va Intel bäst igen när jag länkade till ett test som påvisade att så inte var fallet. Men vet du vad, det var säkert ett handplockat fan-boy test av mig, för jag har Killer ASIC's på väggarna och knaprar på dom av besatthet. Alternativ version kan vara att jag tycker om uppstickare som sätter giganterna till konkurrens. Välj själv vilken version du tror på. Jag har köpt in Intel servers på diverse företag för miljontals kronor för att jag utvärderade dom att vara bäst till dom krav vi hade, och det har ju vart ganska uppenbart sedan Bulldozer kom. Jag har själv haft 3st 4770K i min egna burk hemma samt i princip nästan bara testat/labbat med Intel system sedan Bulldozer kom. Jag har väldigt mycket egen data och praktiska erfarenheter att jämföra med, och på så vis en ganska god uppfattning också. Det finns fler än du som har datorer som en brinnande hobby och samtidigt jobb att sköta som du en gång tog upp av någon anledning.

Det verkar inte som att du är medveten om att detta är en diskussionstråd för Ryzen där det är fullt vettigt och rimligt att vara optimistisk kring en av dom viktigaste lanseringarna i CPU-industrin sedan 1999/2003. Jag kan bara tala för mig själv även om jag inte sett något nämnvärd extremist-fan i tråden, men på vilket sätt har jag glorifierat Ryzen utan att använda mig utav en kraftig källa eller teknisk argumentation eller grund... Mitt senaste eller näst senaste inlägg så skrev jag att en mycket god spelcpu är t.ex 6600K/7600K och att Ryzen verkar passera denna i snitt. Jag är inte ute och cyklar när jag ska skaffa mig en god uppfattning om vad för potential en mikroarkitektur besitter, därav har jag vart lite mindre försiktig tidigare med en del spekulationer medans du "vet allt". Nej du vet inte allt och kan inte allt bäst heller. Du är ingen CPU-arkitekt, därav jag beskrev för dig tidigare att många spec på Ryzen var omöjliga att gissa sig till eller tyda. Numera är den lanserad och det är en hel del bevisade/konstaterade problem på programvarusidan. Du vill istället diktera att det är arkitekturen som är sådan och hugga det i sten.

Sa tidigare att interconnect ligger på samma bandbredd som RAM på grund av datafabric ligger på samma klockdomän, därav samma bandbredd. Bandbredden verkar av att döma tillräcklig och skalningen bra. Detta påvisar dock inget om latensen. AMD har tvärtemot av det du skriver gått ut med att latensen är låg för kommunikation mellan kärnorna men där man givetvis åker på fördröjningar för att kommunicera från t.ex Core0 till Core5. Som sagt, det är cache hooks som går on-die vilket ger lägre latens än att gå ut till RAM som är syftet med cachen.

Jag har läst The Stilt's test sedan första dagen han la ut testet i tråden. 7-zip resultaten tog jag från PC-perspective, och att du kallar det för handplockat är under all kritik. Du verkar vägra att se att det är stor varians på grund av det jag nu förklarat för dig diverse gånger, dvs strul med programvara, bios och OS-setups.

En person med grundläggande kunskap om CPU's och operativsystem kan instämma omedelbart om den saken och man ser tydligt att Ryzen bromsas medans du vill ha rätt i allt och alla andras tankar eller grunder är handplockade, glorifierande eller rent av fanboy's som du godtyckligt uttrycker det utan att använda dig utav själva ordet. Jag har inte dikterat något som jag inte haft en källa till eller en kraftig argumentation. På vilket sätt som jag skulle vara en AMD-anhängare när jag har hållit på mest med Intel system, men att jag samtidigt står med öppna armar för en hård konkurrens igen på CPU marknaden, och i tillägg ser potentialen i Ryzen som dagens tester inte riktigt ger sken om än ser jag inte heller. Hade jag vart ett AMD-fan så hade jag kört en Bulldozer med kompressorkylning på 7GHz bara för att. Jag byter gladeligen ut en Intel-quad mot en Ryzen på desktop. Varför kommer tiden snart att visa dig.

Det är nog första gången du skriver att Ryzen är väldigt lyckad, för det är den, och det var det var därför jag ville göra en rolig tråd om hoppet att AMD skulle komma tillbaka relativt likvärdig eller bättre än Intel med sin snabba Core serie. Zen, en extremt balanserad arkitektur, därav namnet "Zen" på arkitekturen. Allt är inte über med Ryzen och jag har också försökt lyfta fram bägge sidor och argumenterat fram en grund till varför i alla fall jag kan komma på. T.ex Klockfrekvensen/potentialen hos Zen var senast något jag skar ner på då jag personligen tycker om att överklocka sedan Turboknappen blev uppfunnen på persondatorn.

Du själv är ganska onyanserad när du vägrar se andras syn eller behov. Om du redan som du säger har tankarna att kanske låta negativ när ämnet enligt dig gäller glorifiering av Ryzen, varför är du då såpass aktiv i tråden om ämnet irriterar dig? För att rätta andra och alltid ha rätt? Du refererade i ett inlägg efter detta till "idiotiska inlägg" som kan få "stå kvar och göra en wccftech" av det.

Ironiskt nog att du är så hemma med MT programmering och spelutveckling och samtidigt går emot det jag sagt hela tiden och det som sägs av spelutvecklare (senast på GDC där man lägger enorma resurser på MT och även Ryzen. MT gör sig bättre och bättre i spel, tom bättre än vad jag någonsin hade kunnat tänka mig i vissa titlar. Jag hade aldrig kunnat tänka mig att Bulldozer skulle stå sig så bra mot t.ex en 2500K/2600K som den gör i många av dagens MT-titlar. Ryzen har tack vare OS och avsaknad optimering hos titlarna i sig problem med sin SMT i spel nu, men det löser sig. Ryzens styrka om något är MT, något vi fått se prov på också både i designen och rent praktiskt vilken enormt boost alla applikationer får som nyttjar SMT.

Det du inte verkar ta hänsyn till är att i testet så kördes inte 100.000-tals CPU'er klustrade, utan det var inte mer parallelliserat än ett desktopscenario vid rendering t.ex. Zen uppvisar god IPC, prestanda per kärna/processor mot Intel's dito i dessa operationer som ställer enorma krav på både latens, heltal, flyttal minnesbandbredd och cache. Jag tog upp testet i samband med när jag tog upp Naples som ett motryck till dina påståenden om att "Zen inte är bra på nått attityd".

Jag tror att du argumenterade emot mig fler gånger än vad jag sa det till dig, bara som en upplysning. Jag skrev enkelt och tydligt att det står på ARK men du vägrade ta in det. Min poäng med att upplysa detta är att du vägrar inse fakta ibland för att du inte litar på någon annan än dig själv. Detta är ett ganska bra exempel på hur svårt det blir att föra en diskussion med dig när du tror att folk verka hitta på vad som skrivs som rena vilda västern trots kraftig argumentation.

Gå till inlägget

Sista först, jag hade fel, där du fick läsa det igen Har inget problem med det, faktum är att det är något POSITIVT för jag lärde mig något då det jag läst på AnandTech och Toms Hardware var fel. Och har redan förklarat att den engelska ARK hade mycket riktigt informationen, men jag kan inte URL i huvudet utan använder alltid Google. Google gav mig den svenska ARK som saknande informationen.

Och ge dig kring "vilda western". Vem litar du mest på: AnandTech och Toms Hardware eller någon random person i ett forum?

Angående Killer NIC och i21x. Vilket är viktigaste: sänka latensen på den lokala datorn på ett sätt som kan påverka hela ditt lokala nätverk negativt eller sänka latensen via QoS som typ alla Internet-accesspunkter utanför extrem budget innehåller, då på ett sätt som tar hänsyn till HELA ditt LAN?

Ovanpå det har i21x HW-implementerad synkronisering, något som redan när en CPU-tråd jobbar hårt mot NIC gör att CPU-lasten går ner. Det är inte en stor skillnad, men stor nog för att eventuella problem med att "multi-taska" (köra skype, spotify m.m.) borde raderas då skillnaden i CPU-last mellan att köra Killer NIC och i21x är långt större än lasten som äts upp av ovan program. Slutligen kring detta, vi pratar om CPUer med många kärnor och vinsten i CPU-last med HW-synkronisering ökar långt mer än linjärt när antal kärnor går upp.

Vidare finns HW-stödet i i21x för att göra motsvarande QoS som Killer NIC gör. Men vet inte om Windows-drivaren har det stöds som krävs, i Linux fungerar det absolut då jag använt det på föregångaren till i21x samt på 10 GBit/s versionen.

Angående MT programmering. Alla designer gör avvägningar och kompromisser. Är fortfarande inte helt på det klara vilken marknad AMD primärt tänkt sig med Zen, i Intels fall är det uppenbart att man primärt bygger en CPU-kärna för skrivbordet som man sedan skalat upp till servers och ner till mobila enheter (gick ju sådär på sista delen, ARM är föga oväntat bättre då det är primärt fokus för dem men fungerar för Intel på bärbara datorer och upp).

De kompromisser AMD gjort i Zens cache-system gynnar problem som är "embarrassingly parallel", men hur relevanta är dessa problem på skrivbordet? Kan få spel att fungera lite bättre än idag, med största sannolikhet ja. Men men ännu större sannolikhet kommer det vara en minimal skillnad då problemet inte är något nytt. PS4/XBO har exakt samma design och det ses som ett problem av spelutvecklare, C2Q har samma problem men inget gjordes åt det för det gick inte.

Det fundamentala problemet är att saker som måste synkronisera mellan CPU-kärnor är helt beroende på tiden det tar att koordinera ägande och innehåll i en viss minnescell (den där låset ligger). Men två CCX där RAM är LLC och de sitter ihop via en, från CPU-kärnan sett, extern buss kommer se höga kostnader här.

Vidare pekar ju Hardware.fr att latens mot RAM är högre i Ryzen jämfört med de flesta andra designer vid en given uppsättning minnes-timings. Det stämmer även med de resultat som uppmäts i AIDA64 samt de som mätningar som Legit Reviews gjort.

Valen man gjort i Zen gynnar då saker som behöver mycket L3$ bandbredd. 2x 8 MB cache ger ju dubbel aggregerad bandbredd. Intel har viss skalning av bandbredd i sin ringdesign, teoretiskt ökar den perfekt med antal kärnor men tänker man på hur det rent praktiskt är implementerat så inser man rätt snabbt varför skalningar inte alls är linjär. Det är nog en orsak till varför man har flera ringar över tio kärnor.

Men valen man gjort i Zen missgynnar latens för att hålla saker koherenta. Däremot är cache-latensen för ren läsning riktigt bra (bättre än E-serien, men där är också L3$ latens väsentligt högre än S-serien). Legit Reviews visar det rätt bra, Zen fungerar precis lika bra som Intel när L1$ tar hand om det hela. Vid L2$ och L3$ har Zen faktiskt en fördel i latens om det är ett trivialt accessmönster (prefetch ligger uppenbarligen lite tidigare i pipeline för Zen). Vid slumpmässig läsning hamnar man efter för L2$ men fortfarande före vid L3$ (upp till 8 MB som är storleken för varje CCX).

D.v.s för MT program där kärnor inte kommunicerar med varandra så har Zen en bättre cache-design än Core i de flesta fall. Intel har några fördelar som att om alla kärnor ofta läser samma data måste Zen duplicera informationen per CCX medan Core bara behöver en kopia i L3$ och det är lägre latens mot RAM då det inte finns någon annan CCX som också tas med i ekvationen vid RAM-access.

De flesta på SweClockers är ändå främst intresserad av skrivbordsprogram i allmänhet och spel i synnerhet. I det läget blir kostnaden för att hålla data koherent mellan kärnor det som seglar upp + att fokus flyttas från de ofta flyttalsintensiva program som det ofta handlar om när det är trivialt att parallellisera till heltalsintensiva program.

När det kommer till att hålla data koherent mellan flera kärnor är en icke-inkluderande cache policy ett minus, att ha två CCX som i praktiken kommunicerar med latens av RAM (vilket är vad hardware.fr hävdar blir fallet och man hävdar även att man frågat AMD om man förstått rätt) så har man rejäl uppförsbacke. Framförallt när "den andra sidan" har en design där L3$ täcker alla kärnor och är inkluderande vilket betyder att L3$ även kan utnyttjas som snoop-filter (vilket också görs i praktiken).

Det är en ocean i latensskillnad mellan två Core kärnor och två Zen-kärnor som måste synkronisera något. Det gäller till viss del även två kärnor i samma CCX eftersom man vid miss i lokala cachen inte vet om den andra CCX:en har cellen cachad eller om det ska tas från RAM.

Kommer naturligtvis ner till vilket användarfall som är viktigast. Finns VÄLDIGT många fler program i det senare fallet där kärnor måste synkronisera data. Ovanpå det så är det just fallen som är triviala att parallellisera som är toppkandidater för att köras med GPGPU. @sAAb postade t.ex. detta, ingen som reagerar på de två överlägset snabbaste fallen? CUDA kanske ringer en klocka och kommentaren i artikeln som länkas är rätt talande

"Otherwise, for the most part, Blender and Premiere are happening on the GPU – though other workloads like compiles, should you work with them, would benefit from CPU acceleration."

D.v.s. har man en GPU kvittar ju CPU-delen för just det som testas här då allt går betydligt snabbare GPU-accelererat (d.v.s. lika snabbat på i7-7700K som Ryzen/E-serien till lägre pris och högre prestanda i de 99 % man INTE spenderar i final-render). Vidare är inte ens hans kommentera kring kompilering korrekt, det stämmer för "rebuilt all" men normalt gör man tiotals, kanske hundratals, inkrementella byggen per totalt ombygge. De inkrementella byggena beror till 100 % av enkeltrådprestanda.

Här tänkte lite på de kommenterar i denna tråd som hävdar hur irrelevant enkeltrådprestanda är idag under två senaste veckorna, sitter och putsar på andra personers kod och unit-tester vilket betyder massor med koda-kompilera-köra_tester. Då det är C++ med en hyfsad andel templates tar en inkrementell kompilering ~10 sekunder, otroligt irriterande tidsspann då det är för kort för att göra något annat men ändå långt nog att absolut märkas. Enda som sänker denna tid är högre enkeltrådprestanda för heltal!

Har aldrig sagt att Naples är inte bra på något. Den kommer vara ruggigt vass på saker som är rent CPU-bundna, främst skalära flyttal, där problemet behöver LÄSA väldigt stora mängder data och det hela är "embarrassingly parallel". Vi vet ännu inte om det finns något likt DDIO (en teknik som minskar trycket på RAM och minskar latens enormt på access till data som kommer via DMA, detta nästan dubblade prestanda för I/O-bundna laster när det introducerades), vi vet inte var nivån för RAS ligger (d.v.s går man upp mot E5 eller E7).

Däremot vet vi redan att Naples kommer ligga efter på de flesta HPC-laster (de är storkonsumenter av SIMD) och då ingen tråd någonsin kan se mer än 8 MB + 512 kB cache kommer den hamna på efterkälken i laster där "working-set" är större än så. Finns 4/6-kärniga Xeon E5 med 10/15 MB L3$ just för att det finns problem som aktivt jobbar på relativt stora "working-sets", i extremfallet kan ju en kärna använda hela 50 MB L3$ i en E5 2699.

Men lär ändå bli en succé för AMD och ett problem för Intel. Intel sitter i detta fall på 99 % av marknaden, så oavsett hur liten del av marknaden AMD är bästa val för betyder det en minskning för Intel.

Döp om tråden till "AMD Zens gloriferingstråd", då kommer antagligen aldrig posta mer. Nu är det trots allt så att det finns intressanta saker som diskuteras här och hoppas det finns intresse av att både se uppsidor OCH nedsidor av saker.
Tänker för övrigt inte heller skriva ett enda inlägg i en eventuell "Intel Broadwell-E är bäst" tråd heller, för borde framgå att jag må anse att 8-kärnors Ryzen är en nischprodukt men Broadwell-E är en nischprodukt av en nisch p.g.a. av sin prislapp (och när jag ändå är på basha-intel stråk, ser minimal poäng med Optane-diskarna då fördelen är latens men PCIe pajar ju alla latensfördelar, ser en poäng med 3DXpoint när den används som RAM).

Visa signatur

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

Redigera
Citera flera Citera
Permalänk
Hjälpsam ★
●
Skrivet av Enigma:

Ahh kanon att du hade uppsikt över det Ser betydligt bättre ut, dock så postade Stilt sina resultat efter den posten, men han kan fortfarande ha kört ett icke uppdaterat OS om nu verkligen MS löst detta. Det är ett allvarligt problem, men oavsett vad som är orsaken just nu så är det verkligen något som bromsar Zen när man tittar på resultaten mellan Win7 och Win10 både med och utan SMT.

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

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

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

No NUMA nodes.

Logical Processor to Cache Map:
**--------------  Data Cache          0, Level 1,   32 KB, Assoc   8, LineSize  64
**--------------  Instruction Cache   0, Level 1,   64 KB, Assoc   4, LineSize  64
**--------------  Unified Cache       0, Level 2,  512 KB, Assoc   8, LineSize  64
********--------  Unified Cache       1, Level 3,    8 MB, Assoc  16, LineSize  64
--**------------  Data Cache          1, Level 1,   32 KB, Assoc   8, LineSize  64
--**------------  Instruction Cache   1, Level 1,   64 KB, Assoc   4, LineSize  64
--**------------  Unified Cache       2, Level 2,  512 KB, Assoc   8, LineSize  64
----**----------  Data Cache          2, Level 1,   32 KB, Assoc   8, LineSize  64
----**----------  Instruction Cache   2, Level 1,   64 KB, Assoc   4, LineSize  64
----**----------  Unified Cache       3, Level 2,  512 KB, Assoc   8, LineSize  64
------**--------  Data Cache          3, Level 1,   32 KB, Assoc   8, LineSize  64
------**--------  Instruction Cache   3, Level 1,   64 KB, Assoc   4, LineSize  64
------**--------  Unified Cache       4, Level 2,  512 KB, Assoc   8, LineSize  64
--------**------  Data Cache          4, Level 1,   32 KB, Assoc   8, LineSize  64
--------**------  Instruction Cache   4, Level 1,   64 KB, Assoc   4, LineSize  64
--------**------  Unified Cache       5, Level 2,  512 KB, Assoc   8, LineSize  64
--------********  Unified Cache       6, Level 3,    8 MB, Assoc  16, LineSize  64
----------**----  Data Cache          5, Level 1,   32 KB, Assoc   8, LineSize  64
----------**----  Instruction Cache   5, Level 1,   64 KB, Assoc   4, LineSize  64
----------**----  Unified Cache       7, Level 2,  512 KB, Assoc   8, LineSize  64
------------**--  Data Cache          6, Level 1,   32 KB, Assoc   8, LineSize  64
------------**--  Instruction Cache   6, Level 1,   64 KB, Assoc   4, LineSize  64
------------**--  Unified Cache       8, Level 2,  512 KB, Assoc   8, LineSize  64
--------------**  Data Cache          7, Level 1,   32 KB, Assoc   8, LineSize  64
--------------**  Instruction Cache   7, Level 1,   64 KB, Assoc   4, LineSize  64
--------------**  Unified Cache       9, Level 2,  512 KB, Assoc   8, LineSize  64
Gå till inlägget

Funderar på, om det inte vore bra med två NUMA noder.

Visa signatur

AMD Ryzen 7 5700X | Saphire RX 5700 Pulse XT (Silent Mode) | 64 GB Kingston ECC | https://valid.x86.fr/51gntq | Stockkylaren | Bitfenix Whisper M 750W.
AMD Ryzen 9 5900X | AMD RX 5700 | 64 GB Micron ECC | https://valid.x86.fr/gwcxfs
HTPC | https://valid.x86.fr/gqtxws |

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av Åsa-Nisse:

Ryzen - The Tech Press Loses The Plot - https://www.youtube.com/watch?v=ylvdSnEbL50

Gå till inlägget

#16704294
#16704428
#16703674
#16703905

Visa signatur

“When a clown moves into a palace he doesn’t become a king, the palace instead becomes a circus.”

Redigera
Citera flera Citera
Permalänk
Datavetare ★
●
Skrivet av Enigma:

Uppvisar ganska trevliga resultat, och detta med fasta dividers, dvs utan BCLK som ger ännu mer prestanda.

http://www.legitreviews.com/wp-content/uploads/2017/03/deus-ex-gaming.jpg

BCLK med DDR2400 strap:

http://forum.hwbot.org/attachment.php?attachmentid=5393&stc=1&d=1488554236
http://forum.hwbot.org/attachment.php?attachmentid=5394&stc=1&d=1488554236

Sen har vi problemen med schemaläggaren i Win10 och Ryzen som betraktar varje tråd på Zen som en egen L1, L2 och L3 cache...

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

Katastrofalt att ingen patch finns till Win 10 ännu. Borde vart klart före lansering och vem man ska skylla på är ju okänt här. Ställer verkligen till prestanda på alla plan, speciellt i spel. Win 7 som heller inte är optimalt uppvisar 26% sämre min-fps och 8% lägre snittfps i Total War: Warhammer som många recensenter använt sig utav i sina tester ihop med AotS som inte alls fungerar som det ska på Ryzen med nuvarande patch.

Gå till inlägget

För det sista finns en patch, problemet har aldrig varit Windows utan det är endera mikrokod i CPU eller något om ska patchas på moderkortet för andra ser rätt resultat: https://forums.anandtech.com/threads/ryzen-strictly-technical...

Denna information kommer från CPUID (som är mikrokodat):

Logical Processor to Cache Map:
**--------------  Data Cache          0, Level 1,   32 KB, Assoc   8, LineSize  64
**--------------  Instruction Cache   0, Level 1,   64 KB, Assoc   4, LineSize  64
**--------------  Unified Cache       0, Level 2,  512 KB, Assoc   8, LineSize  64
********--------  Unified Cache       1, Level 3,    8 MB, Assoc  16, LineSize  64
--**------------  Data Cache          1, Level 1,   32 KB, Assoc   8, LineSize  64
--**------------  Instruction Cache   1, Level 1,   64 KB, Assoc   4, LineSize  64
--**------------  Unified Cache       2, Level 2,  512 KB, Assoc   8, LineSize  64
----**----------  Data Cache          2, Level 1,   32 KB, Assoc   8, LineSize  64
----**----------  Instruction Cache   2, Level 1,   64 KB, Assoc   4, LineSize  64
----**----------  Unified Cache       3, Level 2,  512 KB, Assoc   8, LineSize  64
------**--------  Data Cache          3, Level 1,   32 KB, Assoc   8, LineSize  64
------**--------  Instruction Cache   3, Level 1,   64 KB, Assoc   4, LineSize  64
------**--------  Unified Cache       4, Level 2,  512 KB, Assoc   8, LineSize  64
--------**------  Data Cache          4, Level 1,   32 KB, Assoc   8, LineSize  64
--------**------  Instruction Cache   4, Level 1,   64 KB, Assoc   4, LineSize  64
--------**------  Unified Cache       5, Level 2,  512 KB, Assoc   8, LineSize  64
--------********  Unified Cache       6, Level 3,    8 MB, Assoc  16, LineSize  64
----------**----  Data Cache          5, Level 1,   32 KB, Assoc   8, LineSize  64
----------**----  Instruction Cache   5, Level 1,   64 KB, Assoc   4, LineSize  64
----------**----  Unified Cache       7, Level 2,  512 KB, Assoc   8, LineSize  64
------------**--  Data Cache          6, Level 1,   32 KB, Assoc   8, LineSize  64
------------**--  Instruction Cache   6, Level 1,   64 KB, Assoc   4, LineSize  64
------------**--  Unified Cache       8, Level 2,  512 KB, Assoc   8, LineSize  64
--------------**  Data Cache          7, Level 1,   32 KB, Assoc   8, LineSize  64
--------------**  Instruction Cache   7, Level 1,   64 KB, Assoc   4, LineSize  64
--------------**  Unified Cache       9, Level 2,  512 KB, Assoc   8, LineSize  64

Sedan får gärna någon peka på ett enda program som testas så här långt != AIDA64 och CPU-Z som överhuvudtaget bryr sig i cache-topologi. D.v.s. det spelar i praktiken ingen som helst roll att den informationen inte är korrekt.

Hur CPU-trådar hänger ihop med kärnor reder OS ut på ett annat sätt (APICID i stället för CPUID). I Windows läggs sedan CPU-trådar så här

AaBbCcDd

där Aa är två CPU-trådar på samma fysiska CPU-kärna.

I Linux blir det i stället

ABCDabcd

För att säkerställa att trådar och kärnor detekteras korrekt kan man boota Linux och kolla /proc/cpuinfo. Kolla raden som heter "sibings" resp den som heter "cpu cores". Fungerar allt så ska "siblings" visa antal CPU-trådar (16 för Ryzen R7) och "cpu cores" antal CPU-kärnor (8 för Ryzen R7).

Exempel på /proc/cpuinfo

Visa signatur

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

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

En tråd hade varit rätt tråkig om den bara hyllade en produkt. Tänk speltrådar i jämförelse, det finns inte någon större tråd om väldigt bra och kritikerrosade spel som inte tar upp nackdelar och saker som spelet är mindre bra på och som spelet kunde göra bättre. Precis samma sak ser vi i den här tråden och det är något som gör den intressant att läsa och följa. Man kan säkert starta en tråd där endast positiva saker med Zen får diskuteras och resten hade nog enligt forumets regler kunnat rapporteras som offtopic.

Visa signatur

sweclockers prestandaindex

Efter 10 kommer 11.
Efter 99 kommer 100.

Redigera
Citera flera Citera
Permalänk
Inaktiv
●
Skrivet av Yoshman:

Döp om tråden till "AMD Zens gloriferingstråd", då kommer antagligen aldrig posta mer. Nu är det trots allt så att det finns intressanta saker som diskuteras här och hoppas det finns intresse av att både se uppsidor OCH nedsidor av saker.

Gå till inlägget

Tillåta "otrogna ej frälsta fanboys" i en debatt, det finns många exempel på att det inte är bra.
Nej jag tycker dina inlägg är bra, det jag främst inte håller med om att i7 7700K är den bästa processorn för den stora skaran etc. Då ingen processor ur Intels i7 eller Ryzen 7 serie är den bästa processorn för den stora skaran, de både är riktade emot nischade användare som är värt att betala mer för en dator än vad gemene person behöver. Och kollar man på spel så duger en i5a åt nästan alla.

Angående laster bland nischade nördar så kör väldigt många laster som kan köras på helt olika datorer som inte på något sätt behöver ha kommunikation mellan varandra. Jag skulle tro att bland konsumenter så är det främst spel som är den belastningen som har mycket kommunikation mellan olika trådar. Andra appikationer så är trådarna ofta mer oberoende av varandra. Trådarna får ta den tid det tar, det finns trådar som t.ex körs en gång i minuten och uppdaterar något, all annan kod bryr sig inte om detta, det enda som kan hända är att ögonblicket som tråden uppdaterar något så är detta något låst.
Och problemet med att köra all last på en maskin är att de får dela på resurser som rambredd, grafikkort, portar av olika slag etc, där Naples kanske är ett bättre val om ens plånbok vore större.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Ikväll ger det sig förhoppningsvis om det blir en beställning av Ryzen eller inte. Jag avbröt min förhandsbokning pga. avsaknaden av information gällande stöd för virtualisering och ECC RAM. Men, som sagt, om någon missat det så kommer Wendell hos Level1Techs att publicera ett klipp där han går igenom virtualisering (och förhoppningsvis ECC) med fokus på IOMMU och ACS i Linux, där tidigare tester visade på problem med gruppering/isolering vilket försvårade/omöjliggjorde tilldelning/passthrough av hårdvara till olika VMs. Klippet ska enligt en tweet jag tidigare länkat förhoppningsvis dyka upp till 20:00 ikväll svensk tid på deras webbsida och YouTube-kanal.

Lite off-topic nu, men förutsatt att det blir ett serverbygge, finns det 16GB Single Rank Unbuffered ECC DDR4-DIMMs på marknaden? Jag hittar bara 8GB-moduler med dessa egenskaper, vilket i så fall begränsar oss till 32GB maximalt systemminne om vi vill ha ECC. De moduler jag hittat är Kingstons KVR24E17S8/8 och KVR24E17S8/8MA, samt Crucials CT8G4WFS824A, samtliga ligger dock på 2400MHz, men det bör väl inte vara några problem att köra dem i 2133MHz som Ryzen verkar vilja om man kör 4x DIMMs?

Annars kan man ju givetvis köra 2x 16GB Dual Rank Unbuffered ECC DDR4-DIMMs, som Crucials CT16G4WFD8213, alternativt Kingstons KVR24E17D8/16 eller KVR24E17D8/16MA, där de två sistnämnda ligger på 2400MHz vilket Ryzen ska fixa vid 2x DIMMs.

Redigera
Citera flera Citera
Permalänk
Datavetare ★
●

@anon159643: helt OK att inte hålla med.

Tror jag har förklarat varför jag anser den är bästa valet för de flesta (bottendestillatet är: långt mer än vad man tror beror fortfarande främst på enkeltrådprestanda). Men det är ingen absolut sanning och någon som känner annorlunda gör tråden en tjänst genom att argumentera för sin sak, t.ex. genom att peka på mätningar som visar varför det kanske är på sättet denne anser.

Sedan finns det absolut saker jag väljer att spetsa till. Oftast gör jag det i hopp om att någon vet mer än mig om det som avhandlas och det bästa som kan hända är att denne sätter mig på plats genom att visa med hårda fakta att jag var fel ute. Inte kul att ha fel, men dessa lägen är ju en av de få tillfällen när all tid som spenderas i dessa forum faktiskt ger mig något konkret tillbaka: ny kunskap adderad!

Visa signatur

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

Redigera
Citera flera Citera
Permalänk
Avstängd
●
Skrivet av Yoshman:

Men lär ändå bli en succé för AMD och ett problem för Intel. Intel sitter i detta fall på 99 % av marknaden, så oavsett hur liten del av marknaden AMD är bästa val för betyder det en minskning för Intel.

Döp om tråden till "AMD Zens gloriferingstråd", då kommer antagligen aldrig posta mer. Nu är det trots allt så att det finns intressanta saker som diskuteras här och hoppas det finns intresse av att både se uppsidor OCH nedsidor av saker.
Tänker för övrigt inte heller skriva ett enda inlägg i en eventuell "Intel Broadwell-E är bäst" tråd heller, för borde framgå att jag må anse att 8-kärnors Ryzen är en nischprodukt men Broadwell-E är en nischprodukt av en nisch p.g.a. av sin prislapp (och när jag ändå är på basha-intel stråk, ser minimal poäng med Optane-diskarna då fördelen är latens men PCIe pajar ju alla latensfördelar, ser en poäng med 3DXpoint när den används som RAM).

Gå till inlägget

du är betydligt mer förståbar här.

Ryzen 6c/12t lär bli den optimala spel cpu samt hemma pulare gör det mesta annat.
sammanfaller med mitt köp med, helt ofattbart sammanträffande!

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)

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av Yoshman:

D.v.s för MT program där kärnor inte kommunicerar med varandra så har Zen en bättre cache-design än Core i de flesta fall. Intel har några fördelar som att om alla kärnor ofta läser samma data måste Zen duplicera informationen per CCX medan Core bara behöver en kopia i L3$ och det är lägre latens mot RAM då det inte finns någon annan CCX som också tas med i ekvationen vid RAM-access.

Gå till inlägget

Intressant, detta borde betyda att program skrivna i C/C++ fungerar bättre på Zen medan den kan vara något svagare i språk där språket gömmer trådning/skalningen och använder garbage collector. C/C++ programmerare vet om att det kostar och synkronisera data vilket gör att man anpassar koden och minimerar synkroniseringen. Andra språk som inte är lika "close to the metal". Då blir trådning/skalningen något mer "förvirrad" och oförutsägbar.
Troligen är Zen bra i databasservrar och liknande medan de inte är lika starka i servrar som kör java applikationer.

Redigera
Citera flera Citera
Permalänk
Datavetare ★
●
Skrivet av klk:

Intressant, detta borde betyda att program skrivna i C/C++ fungerar bättre på Zen medan den kan vara något svagare i språk där språket gömmer trådning/skalningen och använder garbage collector. C/C++ programmerare vet om att det kostar och synkronisera data vilket gör att man anpassar koden och minimerar synkroniseringen. Andra språk som inte är lika "close to the metal". Då blir trådning/skalningen något mer "förvirrad" och oförutsägbar.
Troligen är Zen bra i databasservrar och liknande medan de inte är lika starka i servrar som kör java applikationer.

Gå till inlägget

Skulle säga att det finns en skillnad, men är tvärt om. Program skrivna i C/C++ är mer beroende av låg kostnad för synkronisering då en tracing GC möjliggör en rad låsfria algoritmer samt det finns fler möjligheter till att aggregera minneshantering med GC, något som gör det möjligt att amortera kostnaden för synkronisering över väldigt många minnesobjekt.

Utan tracing GC är det väldigt svårt att korrekt använda "lock-free" och "wait-free" algoritmer då nästan alla sådana försök leder till en bug känd som ABA-problemet. Finns sätt att lösa ABA, i princip alla, förutom att använda en tracing GC, är så komplicerade att det blir billigare att bara smacka dit ett lås.

Men jobbar just nu på ett patent kring billig synkronisering i språk som inte använder tracing GC. Tekniken kan tyvärr inte bli helt allmängiltig (går teoretisk bevisa att den som hävdar det måste ha gjort en tankevurpa), men i fallet jag jobbar med fungerar det för sådant som är "read-mostly" och där mängden data per post man skyddar är relativt lite (extremt vanligt fall i både spel och framförallt OS vilket är huvudmålet för mig).

Visa signatur

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

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av Yoshman:

Hur CPU-trådar hänger ihop med kärnor reder OS ut på ett annat sätt (APICID i stället för CPUID). I Windows läggs sedan CPU-trådar så här

AaBbCcDd

där Aa är två CPU-trådar på samma fysiska CPU-kärna.

I Linux blir det i stället

ABCDabcd

För att säkerställa att trådar och kärnor detekteras korrekt kan man boota Linux och kolla /proc/cpuinfo. Kolla raden som heter "sibings" resp den som heter "cpu cores". Fungerar allt så ska "siblings" visa antal CPU-trådar (16 för Ryzen R7) och "cpu cores" antal CPU-kärnor (8 för Ryzen R7).

Exempel på /proc/cpuinfo

Gå till inlägget

Fast nu missade du den "lilla" detaljen att det finns mjukvara som aktivt undviker att lägga över trådar på HT/SMT kärnor oavsett hur cache ser ut eller används, i Ryzens fall så fungerar inte detta utan trådar skyfflas över även på SMT vilket inte borde ske men det gör det pga att Ryzens arkitektur är sprillans ny och det har inte funnits tid att patcha mjukvaror. Detta är väldigt vanligt i just spel där man aktivt patchat bort användande av SMT i dom situationer det skapat negativ skalning, alltså programmet i sig begär en core affinity som motsvarar fysiska kärnor. Igen, detta sker inte på Ryzen (HyperThreaded Core Avoidance).

Visa signatur

| nVidia RTX3090FE | R9 5800X3D | MSI x570 Unify | Ballistix sport 3000c15 32GB DR@3800c16 | Custom Loop EKWB | 12TB nvme, 2TB sata SSD | RM1000x | Creative X4 | Antec C8 | Alienware aw3821dw | >Antec C8 Custom Loop< |

Redigera
Citera flera Citera
Permalänk
Datavetare ★
●
Skrivet av tellus82:

Fast nu missade du den "lilla" detaljen att det finns mjukvara som aktivt undviker att lägga över trådar på HT/SMT kärnor oavsett hur cache ser ut eller används, i Ryzens fall så fungerar inte detta utan trådar skyfflas över även på SMT vilket inte borde ske men det gör det pga att Ryzens arkitektur är sprillans ny och det har inte funnits tid att patcha mjukvaror. Detta är väldigt vanligt i just spel där man aktivt patchat bort användande av SMT i dom situationer det skapat negativ skalning, alltså programmet i sig begär en core affinity som motsvarar fysiska kärnor. Igen, detta sker inte på Ryzen (HyperThreaded Core Avoidance).

Gå till inlägget

Visst, kan ha missat det. Nämn en enda sådan programvara, I dare you!

Windows är fullt medveten om SMT. Windows, d.v.s. OS-kärnan (samma gäller Linux), kan visa cache-topologin men kärnan själv använder inte den informationen till något alls. Enda OS-kärnorna bryr sig om är storleken på cache-line, den är 64 bytes på alla moderna x86or.

Edit: för att förstå vad patchen för Bulldozer gjorde var just att INTE behandla en modul som en CPU-kärna med SMT, vilket var hur Windows initialt hanterade det hela. Orsaken till detta är att AMD kände att det i genomsnitt var bättre att först fylla båda trådarna på en modul då de hade separata heltalspipelins. Den modulen höll då högsta P-state (maxfrekvens, tar faktiskt rätt lång tid att gå från lägsta till högste frekvens) och om det räckte med två trådar kunde man även boosta högre.

I Zen lär man vilja ha samma beteende som på Core, d.v.s. OSet föredrar att lägga nya trådar på en CPU-kärna som är oanvänd. Det är policy i "performance" läget i alla fall, möjligen kan "balanced" välja att inte väcka upp kärnor i vissa lägen men i så fall gäller samma sak på Core som Zen.

Senast redigerat
Visa signatur

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

Redigera
Citera flera Citera
Permalänk
Hjälpsam ★
●
Skrivet av suzieq:

Ikväll ger det sig förhoppningsvis om det blir en beställning av Ryzen eller inte. Jag avbröt min förhandsbokning pga. avsaknaden av information gällande stöd för virtualisering och ECC RAM. Men, som sagt, om någon missat det så kommer Wendell hos Level1Techs att publicera ett klipp där han går igenom virtualisering (och förhoppningsvis ECC) med fokus på IOMMU och ACS i Linux, där tidigare tester visade på problem med gruppering/isolering vilket försvårade/omöjliggjorde tilldelning/passthrough av hårdvara till olika VMs. Klippet ska enligt en tweet jag tidigare länkat förhoppningsvis dyka upp till 20:00 ikväll svensk tid på deras webbsida och YouTube-kanal.

Lite off-topic nu, men förutsatt att det blir ett serverbygge, finns det 16GB Single Rank Unbuffered ECC DDR4-DIMMs på marknaden? Jag hittar bara 8GB-moduler med dessa egenskaper, vilket i så fall begränsar oss till 32GB maximalt systemminne om vi vill ha ECC. De moduler jag hittat är Kingstons KVR24E17S8/8 och KVR24E17S8/8MA, samt Crucials CT8G4WFS824A, samtliga ligger dock på 2400MHz, men det bör väl inte vara några problem att köra dem i 2133MHz som Ryzen verkar vilja om man kör 4x DIMMs?

Annars kan man ju givetvis köra 2x 16GB Dual Rank Unbuffered ECC DDR4-DIMMs, som Crucials CT16G4WFD8213, alternativt Kingstons KVR24E17D8/16 eller KVR24E17D8/16MA, där de två sistnämnda ligger på 2400MHz vilket Ryzen ska fixa vid 2x DIMMs.

Gå till inlägget

Hittade även dessa, dualrank dock.
https://www.prisjakt.nu/produkt.php?p=3624302
2133 verka vara den hastighet som Ryzens ställer sig i default, jag kör just nu mina 4 st 3000MT/s i 2133MT/s.

edit Hoppsan fel länk.

Senast redigerat
Visa signatur

AMD Ryzen 7 5700X | Saphire RX 5700 Pulse XT (Silent Mode) | 64 GB Kingston ECC | https://valid.x86.fr/51gntq | Stockkylaren | Bitfenix Whisper M 750W.
AMD Ryzen 9 5900X | AMD RX 5700 | 64 GB Micron ECC | https://valid.x86.fr/gwcxfs
HTPC | https://valid.x86.fr/gqtxws |

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av Yoshman:

Skulle säga att det finns en skillnad, men är tvärt om. Program skrivna i C/C++ är mer beroende av låg kostnad för synkronisering då en tracing GC möjliggör en rad låsfria algoritmer samt det finns fler möjligheter till att aggregera minneshantering med GC, något som gör det möjligt att amortera kostnaden för synkronisering över väldigt många minnesobjekt.

Gå till inlägget

Då vet du inte hur extremt GC kod gödslar med minne, de har dessutom noll koll på att se till att nyttja prefetchers av den enkla anledningen att man inte kan kontrollera minnet.
Det går att använda trix i C++ för att undvika låsningar, fler än i GC språk men visst, det kräver en programmerare som kan. De som trådar brukar dock veta vad man pysslar med

Redigera
Citera flera Citera
Permalänk
Datavetare ★
●
Skrivet av klk:

Då vet du inte hur extremt GC kod gödslar med minne, de har dessutom noll koll på att se till att nyttja prefetchers av den enkla anledningen att man inte kan kontrollera minnet

Gå till inlägget

Grundtanken med GC är ju: mängden RAM är oändlig. Ju närmare du är det antagandet i praktiken, ju bättre presterar Java/C# jämfört med motsvarande C/C++ program då man kan vänta allt längre med GC-körningarna. Är också den grundtanken som gjorde beslutet att köra Java i Android rätt udda... Swift kör ju med ARC just för att inte blåsa upp RAM, med ARC tappar man fördelarna GC har kring "lock/wait-free" algoritmer.

Finns faktiskt flera multicore områden där de bästa JVMerna rätt konsekvent spöar motsvarande "optimerad" C/C++ (skriver "optimerad" för är ju teoretiskt möjligt att använda tracing GC även i C/C++ och då borde man kunna matcha Java).

Linux-kärnan är ett lysande exempel på att dagens CPUer är bättre på att avgöra saker som när en prefetch bör göras än vad människor är. Nivån på de som bidrar till core-delarna av Linux-kärnan är rätt hög, ändå fick Linus ett av sina utbrott när han noterade rätt mycket explicita prefetches och när dessa gjordes om till no-ops ökade prestanda på alla moderna CPU-modeller. Är säkert så att explicit prefetch var en bra idé när dessa lades tid, men utvecklingen tickade vidare...

Även Java/C# kan utnyttja t.ex. prefetcher i Zen, de gör detta genom att INTE göra något utan låta CPUn göra sin magi på egen hand.

Samma sak gäller ordningen på instruktioner. Dagens out-of-order CPUer är bättre än de flesta kompilatordesigners att ordna om instruktionerna på ett optimalt sätt. Kompilatorerna kan inte vara bättre då det bästa beslutet kräver information som bara finns när man kör programmet! Så kompilatorerna ska främst se till att inte göra något onödigt samt utnyttja speciella instruktioner där det är möjligt (som SSE/AVX för saker som kan vektoriseras).

Är också detta som gör det lite nativt att tro "optimeringar" kommer göra så mycket skillnad för Zen-prestanda. Man gjorde i ett läge vägvalet mellan lägga optimeringarna i kompilatorn (VLIW är extremfallet av detta) eller i CPUn (dagens out-of-order CPUer med OoO fönster på ~200 instruktioner är extremfallet av detta).

Visa signatur

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

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

@Ratatosk: Tack för tipset, men de är dock inte ECC-minnen vad jag kan se

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av Yoshman:

Visst, kan ha missat det. Nämn en enda sådan programvara, I dare you!

Windows är fullt medveten om SMT. Windows, d.v.s. OS-kärnan (samma gäller Linux), kan visa cache-topologin men kärnan själv använder inte den informationen till något alls. Enda OS-kärnorna bryr sig om är storleken på cache-line, den är 64 bytes på alla moderna x86or.

Edit: för att förstå vad patchen för Bulldozer gjorde var just att INTE behandla en modul som en CPU-kärna med SMT, vilket var hur Windows initialt hanterade det hela. Orsaken till detta är att AMD kände att det i genomsnitt var bättre att först fylla båda trådarna på en modul då de hade separata heltalspipelins. Den modulen höll då högsta P-state (maxfrekvens, tar faktiskt rätt lång tid att gå från lägsta till högste frekvens) och om det räckte med två trådar kunde man även boosta högre.

I Zen lär man vilja ha samma beteende som på Core, d.v.s. OSet föredrar att lägga nya trådar på en CPU-kärna som är oanvänd. Det är policy i "performance" läget i alla fall, möjligen kan "balanced" välja att inte väcka upp kärnor i vissa lägen men i så fall gäller samma sak på Core som Zen.

Gå till inlägget

"I dare you!" ok, here you go...

Nedställt grafiskt så gpu inte orsakar flaskhals trots hög fps

Genomsnittsbelastning i Heaven under 2 minuter

Heaven benchmark, du kan ta hem och kolla själv. Programmet listas i windows egna affinity väljare som att använda alla kärnor men det använder de fysiska primärt som du själv kan se, säg mig hur skulle detta rimma om det inte fanns program som gjorde precis det jag sa? Jag kunde snygga till användningen här till att inte innehålla 75 bakgrundsprocesser som nu smutsar ner användningen på HT kärnorna men jag har inte ork till att cleanboota bara för att visa dig något väldigt basalt, hade visserligen kunnat mördat chrome men jag får skylla på lathet... Hur som det är bara att ta hem Heaven och prova själv.

Senast redigerat
Visa signatur

| nVidia RTX3090FE | R9 5800X3D | MSI x570 Unify | Ballistix sport 3000c15 32GB DR@3800c16 | Custom Loop EKWB | 12TB nvme, 2TB sata SSD | RM1000x | Creative X4 | Antec C8 | Alienware aw3821dw | >Antec C8 Custom Loop< |

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av Stoff3th3m4n:

Självklart är i7-7700K en jättefin processor, tror inte heller någon har påstått att den inte är det. Dock finns det ju användningsområden där Ryzen eller E-serien är det bättre valet, och jag tycker inte att det är nisch-områden. Idag är det många som streamar, videoredigerar, ljudredigerar, bildredigerar på hyfsat tung nivå t ex. Personligen håller jag på med musikinspelning och ganska tung ljudredigering samt komprimering och där är ju valet enkelt för mig, precis som att valet är ganska enkelt om man bara spelar. Men det finns en ocean däremellan där valet inte alltid är självklart.

Gå till inlägget

Men Ryzen är inte ett självklart val för videoredigering och bildredigering med de vanligaste programvarorna på marknaden. Det beror helt vad var din tyngdpunkt ligger. Jag vänder mig mot att slutsatser dras från de genomgående usla tester som typiska speltestare gör av applikationsprestanda. T ex Sweclockers Photoshop och Lightroom-tester som är skämt eftersom de är på tok för simpla och testar för få ingående komponenter för att man ska kunna dra någon slutsats från dem.

Det är så väldigt mycket snack om hur man korrekt testar spel med upplösningar, inställningar, mäter framtimes etc och grälar om vad som är mest riktigt. Men när det kommer till ex Lightroom så exporterar testarna ofta 100 bilder från en kamera och säger "XX är snabbast!" trots att det bara är en väldigt liten del av vad man använde Lightroom till och det kanske finns andra saker som upplevs viktigare för nån som sitter med det dagligen, ex healingpenslar, noise reduction, preview-skapandet.

Hur funkar Ryzen för musikproduktion? Jag skulle gärna se tester som testar maxbelastning med många spår och effekter/instrumentpluggar. Inte för att jag vill "sätta dit" någon utan genuint är intresserad av att göra ett informerat val framöver och där har ju Intel haft ett stort försprång. Har du sett några seriösa tester eller gjort något själv?

Edit:
Ett exempel på det jag pratar om, CPU-prestanda i Adobe After Effects.
https://www.pugetsystems.com/labs/articles/Adobe-After-Effect...

Resultaten är extremt varierande, helt beroende på vilka projekt/effekter som används. Relativt ofta vinner i7-6700K lätt över processorer med betydligt fler kärnor, men i andra projekt hamnar i7-6700K långt efter. Det handlar om hur kärnorna utnyttjas, hur effekterna är skrivna och vad man praktiskt kan dela upp på flera trådar eller ej. Det är också en anledning till varför nästa version av After Effects kommer att ha en helt ny renderingsmotor.

Så nej, ett bra resultat i Cinebench multicore eller Blender säger väldigt lite om hur länge du får vänta på ditt projekt i mer komplexa situationer.

Senast redigerat
Visa signatur

Citera -> större chans till svar.

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av Yoshman:

Grundtanken med GC är ju: mängden RAM är oändlig. Ju närmare du är det antagandet i praktiken, ju bättre presterar Java/C# jämfört med motsvarande C/C++ program då man kan vänta allt längre med GC-körningarna. Är också den grundtanken som gjorde beslutet att köra Java i Android rätt udda... Swift kör ju med ARC just för att inte blåsa upp RAM, med ARC tappar man fördelarna GC har kring "lock/wait-free" algoritmer.

Gå till inlägget

Det är är teori, så fungerar det inte i praktiken. Är prestanda viktigt måste man förstå hur cachen fungerar och hur man kodar så datat så ofta som möjligt ligger i L1 cachen. När man använder så mycket minne som GC kod gör så fungerar cachen inte alls lika bra på grund av mängden.
Ett C/C++ kan ibland vara 100 gånger snabbare, i extrema fall mer jämfört med GC om i vissa typer av arbeten. Det beror på att C++ kodaren lyckats nyttja prefetchers och även om man använder mycket data kommer det bli träff i L1'an nästan hela tiden. GC koden däremot, de använder mycket mer minne och funderar inte på cachen. Effekten av det blir dramatiska skillnader i prestanda.

Skrivet av Yoshman:

Finns faktiskt flera multicore områden där de bästa JVMerna rätt konsekvent spöar motsvarande "optimerad" C/C++ (skriver "optimerad" för är ju teoretiskt möjligt att använda tracing GC även i C/C++ och då borde man kunna matcha Java).

Gå till inlägget

Det stämmer inte, då handlar det om dålig kodare (det finns självklart dåligt skriven C++ kod).

Många i C++ använder STL. Innan Rvalue References kunde en del c++ kodare som inte riktigt behärskade språket skriva seg kod i och med att objekt kopierades när man skickade dem som parameter (by value). Men så kom Rvalue References med C++11 och vips hade man mycket snabbare kod med en omkompilering.

Skrivet av Yoshman:

Även Java/C# kan utnyttja t.ex. prefetcher i Zen, de gör detta genom att INTE göra något utan låta CPUn göra sin magi på egen hand.

Gå till inlägget

Då är vi nere på automatgenererad kod från något verktyg.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av Yoshman:

@sAAb postade t.ex. detta, ingen som reagerar på de två överlägset snabbaste fallen? CUDA kanske ringer en klocka och kommentaren i artikeln som länkas är rätt talande
D.v.s. har man en GPU kvittar ju CPU-delen för just det som testas här då allt går betydligt snabbare GPU-accelererat (d.v.s. lika snabbat på i7-7700K som Ryzen/E-serien till lägre pris och högre prestanda i de 99 % man INTE spenderar i final-render).

Gå till inlägget

Jo, jag gjorde ju det. Testet är HELT värdelöst, det säger ingenting och är snarare gravt missvisande. Dessutom beror prestandan helt på vilken codec och upplösning som används (stod det ens?), eventuella effekter, vad som kan GPU-accelereras i tidslinjen (långt ifrån allt) etc. Idealiskt bör man undvika tester av program som man inte förstår.

Visa signatur

Citera -> större chans till svar.

Redigera
Citera flera Citera
Permalänk
Datavetare ★
●
Skrivet av tellus82:

"I dare you!" ok, here you go...

https://lh3.googleusercontent.com/Yn3HEkNG3r184tRHoc682Rsfy9C_mxz4hKN4YcQV5r91FkjmqAuNpXNSbRX3RtHePLZeQPf3YcoooMzOcYG8JXfemRdxioVKg6d9b0xGdfvxQBTqLBnVw5728XxLBl_ijha_v4jLYlEjf3FuWDMtv2ziopXm7Chi4iaGbl8CBqDrMrOeFwuYTXa3TaDKSHP2LtumK1ZPSz_-iycMLYmqclCwmUCH_jxlpqUBv5a-ShGfmPWJjNepeO2R8jgFkl3yAmtuIEHtfYPqA-37JSjs-GorgYRBlfz_4I2_Zf59l9u3T9iOgSK_k-CXeLi8LlivP33bauo8UuM-gMp7gYj0Ax-90UhjdEWpVBgb1IeikSRuJK2OiYvBNyAwJlSBBZ1hTro5lTk3f36UeNO03JsoC06SIOFDbud8Vd0fZ3XrepOI--Iu0jDCrAXEG8slaBRqhA_J8icqJOFEej4THyOKiRSAiPvE8MmBD4fv_JezAxs1SxgfFSlksfFev-clgn8-Sm7k4FhkWJLKbyp3zZUqwcWc81l0vXF0YOe6XUdCTx37a1dxRWrBHJeVFuPazrKi0jHEQdbXMA10meFPpSs5batPvs3tpvlOw12O_ppBPGJOWBTdnWbmhglhTWjix27T6ge0Yq8Auvq-7N9PmCRDSi8Fiw7uO8zCsDYK4nKgBw=w1458-h616-no
Nedställt grafiskt så gpu inte orsakar flaskhals trots hög fps
http://i621.photobucket.com/albums/tt297/Tellus82/CoresHeaven_zpslxfqrwvx.png
Genomsnittsbelastning i Heaven under 2 minuter

Heaven benchmark, du kan ta hem och kolla själv. Programmet listas i windows egna affinity väljare som att använda alla kärnor men det använder de fysiska primärt som du själv kan se, säg mig hur skulle detta rimma om det inte fanns program som gjorde precis det jag sa? Jag kunde snygga till användningen här till att inte innehålla 75 bakgrundsprocesser som nu smutsar ner användningen på HT kärnorna men jag har inte ork till att cleanboota bara för att visa dig något väldigt basalt, hade visserligen kunnat mördat chrome men jag får skylla på lathet... Hur som det är bara att ta hem Heaven och prova själv.

Gå till inlägget

Detta visar ju att Windows är fullt medveten om att varannan CPU-tråd tillhör samma CPU-kärna

Om du har SMT påslaget ligger CPU-tråd 1&2 på första kärnan, 3&4 på andra kärnan osv.

Vad visar Coreinfo på din dator? För beteendet är rätt och Windows baserar inte detta beteende på cache-topologi utan information kring hur CPU-trådar är fysiskt fördelande över kärnor (som kommer från en annan källa och den informationen måste vara korrekt för att alla CPU-trådar ska kunna aktiveras).

Visa signatur

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

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av Yoshman:

Detta visar ju att Windows är fullt medveten om att varannan CPU-tråd tillhör samma CPU-kärna
http://i621.photobucket.com/albums/tt297/Tellus82/CoresHeaven_zpslxfqrwvx.png
Om du har SMT påslaget ligger CPU-tråd 1&2 på första kärnan, 3&4 på andra kärnan osv.

Vad visar Coreinfo på din dator? För beteendet är rätt och Windows baserar inte detta beteende på cache-topologi utan information kring hur CPU-trådar är fysiskt fördelande över kärnor (som kommer från en annan källa och den informationen måste vara korrekt för att alla CPU-trådar ska kunna aktiveras).

Gå till inlägget

Men nu får du ge dig, normala beteendet är att sprida ut trådar på alla logiska kärnor, inte bara de fysiska. Detta görs av schedulern många många gånger per sekund. Finns mycket dokumenterat på detta. Enda sättet att förhindra spridande av trådar till icke fysiska kärnor är att patcha in detta i mjukvaran eller använda threadlasso. Du bad om ett program som aktivt undvek icke fysiska kärnor och jag levererade ett direkt, ta hem och prova själv istället för att svamla runt i en ursäkt. Jag har inte en ryzen utan en sandy i7 som framgår mycket tydligt och mjukvara har optimerat för denna arkitektur under 6 års tid.

Skickades från m.sweclockers.com

Senast redigerat
Visa signatur

| nVidia RTX3090FE | R9 5800X3D | MSI x570 Unify | Ballistix sport 3000c15 32GB DR@3800c16 | Custom Loop EKWB | 12TB nvme, 2TB sata SSD | RM1000x | Creative X4 | Antec C8 | Alienware aw3821dw | >Antec C8 Custom Loop< |

Redigera
Citera flera Citera
Permalänk
Datavetare ★
●

@klk: det du beskriver är absolut saker som är viktiga för att maximera enkeltrådprestanda, men vi diskuterade väl ändå hur det hela ser ut när man jobbar med multithreading och flera trådar måste komma åt samma data på ett korrekt sätt?

Pratar vi enkeltrådprestanda håller jag absolut med: C/C++ kommer i majoriteten av fallen prestera bättre än Java/C# för de förra kan göra saker som på mikronivå är betydligt effektivare.

Kliver man i stället in på multitrådade program som körs på SMP-system kan man utan problem kopiera en eller ett par page:es med data (en page är normalt 4 kB på x86) och ändå vinna prestanda om det bara sparar en enda synkroniserande operation (instruktion med "lock" prefix i x86 alt. ett "mfence").

Har man en tracing GC kan man t.ex. utnyttja persistent data structures, är då möjligt för trådar som endast läser data att göra det helt utan "lock"-prefix eller "mfence" instruktioner på x86. Då de som läser inte behöver ta något lås behöver de inte heller skriva till någon cache-line som sannolikt ägs av andra CPU-kärnor, extra bra för en design som Zen!

Det är inte praktiskt att använda den typen av datastrukturer utan tracing GC, så i C/C++ är man tvungen att synkronisera dataaccess på andra sätt, dessa andra sätt involverar normalt någon form av lås vilket är dyrt men det sänker även parallellismen -> begränsar skalning med CPU-kärnor (det jag jobbar med nu är att kunna läsa data även i C/C++ utan att skriva till en cache-line som sannolikt är delad, skriva till cache-lines som sannolikt är lokala för aktuell kärna är däremot helt OK).

Senast redigerat
Visa signatur

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

Redigera
Citera flera Citera
Permalänk
Datavetare ★
●
Skrivet av tellus82:

Men nu får du ge dig, normala beteendet är att sprida ut trådar på alla logiska kärnor, inte bara de fysiska. Detta görs av schedulern många många gånger per sekund. Finns mycket dokumenterat på detta. Enda sättet att förhindra spridande av trådar till icke fysiska kärnor är att patcha in detta i mjukvaran eller använda threadlasso. Du bad om ett program som aktivt undvek icke fysiska kärnor och jag levererade ett direkt, ta hem och prova själv istället för att svamla runt i en ursäkt. Jag har inte en ryzen utan en sandy i7 som framgår mycket tydligt och mjukvara har optimerat för denna arkitektur under 6 års tid.

Skickades från m.sweclockers.com

Gå till inlägget

Det normala är att FÖRST sprida ut på ena tråden i varje kärna, vilket är precis det som hänt. Om det sedan finns ännu fler trådar som vill köra börjar man fylla på med andra tråden i varje kärna.

Fallet du visar pekar ju på att en tråd är mer lastad än de andra, Windows har lagt den på CPU-tråd 0. Sedan finns det jobb nog för tre trådar till. Windows har, helt korrekt om systemet är SMT, lagt dem varannan CPU-tråd för att primärt använda en CPU-tråd per kärna.

Eller försöker du hävda att om du lastar ditt system till 100 % så kommer fortfarande fyra trådar vara nästan "idle"? I det läget finns en bug, men just nu visar bilden du länkar att Windows fungerar exakt på det sätt som är optimalt för en CPU med SMT. "Problemet" är i detta fall att GPU är flaskhals så behövs inte mer CPU-kraft.

Visa signatur

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

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av Yoshman:

@klk: det du beskriver är absolut saker som är viktiga för att maximera enkeltrådprestanda, men vi diskuterade väl ändå hur det hela ser ut när man jobbar med multithreading och flera trådar måste komma åt samma data på ett korrekt sätt?

Gå till inlägget

Hur tror du någon parallelliserar arbeten? Det är inte så att man delar upp 5 kodrader i olika trådar utan man delar upp ett större arbete i tårtbitar och så långt som möjligt försöker man undvika att skriva till data i annan tråd. Det är vanligen skrivningen till minne som avgör hur man splittrar arbetet.

Vet att det finns språk som scala exempel, de gör en grej av att vara funktionell programmering (stateless) och splitta upp allt i trådar men det har en mycket hög kostnad.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av Yoshman:

Det normala är att FÖRST sprida ut på ena tråden i varje kärna, vilket är precis det som hänt. Om det sedan finns ännu fler trådar som vill köra börjar man fylla på med andra tråden i varje kärna.

Fallet du visar pekar ju på att en tråd är mer lastad än de andra, Windows har lagt den på CPU-tråd 0. Sedan finns det jobb nog för tre trådar till. Windows har, helt korrekt om systemet är SMT, lagt dem varannan CPU-tråd för att primärt använda en CPU-tråd per kärna.

Eller försöker du hävda att om du lastar ditt system till 100 % så kommer fortfarande fyra trådar vara nästan "idle"? I det läget finns en bug, men just nu visar bilden du länkar att Windows fungerar exakt på det sätt som är optimalt för en CPU med SMT. "Problemet" är i detta fall att GPU är flaskhals så behövs inte mer CPU-kraft.

Gå till inlägget

Men herre min... Gå tillbaka och läs om inläggen, snälla... Jag påvisade att det finns mjukvara som aktivt undviker icke fysiska kärnor och påtalade att dessa idag inte känner igen ryzen. Du ville då ha ett exempel på bara en mjukvara som gjorde detta i din normala översittarton. Senare visade jag exakt ett sådant fall och nu börjar du då svamla om att schedulern fixar detta, hur ska du ha det? Antingen tar schedulern hand om detta enskilt och då kräva det att schedulern gör samma på ryzen vilket den idag inte gör, eller så är det mjukvaran i sig som gör det och då behöver den känna igen ryzen på korrekt sätt, vilket den idag inte gör. Att du glider ifrån dina egna felaktiga påståenden är knappast mitt fel.

Skickades från m.sweclockers.com

Visa signatur

| nVidia RTX3090FE | R9 5800X3D | MSI x570 Unify | Ballistix sport 3000c15 32GB DR@3800c16 | Custom Loop EKWB | 12TB nvme, 2TB sata SSD | RM1000x | Creative X4 | Antec C8 | Alienware aw3821dw | >Antec C8 Custom Loop< |

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Skall man tro på dubbla prestandan för Naples mot Xeon?

http://www.pcgamer.com/amds-shows-off-how-crazily-zen-can-sca...

"Running a seismic analysis workload that involves computationally intensive 3D wave equations, which taxes the entire system—cores, memory, and IO—Naples basically destroyed Intel's Xeon server. "

Visa signatur

| Fractal Design Define R5| Asrock X399 Fatal1ty| Threadripper 1950X| Noctua NH-U14S TR4-SP3| Corsair Vengeance LPX 8x16GB 3200 C16| be quiet! Straight Power 11 Platinum 1000W| ASUS RTX 3080 10GB Strix| LG OLED 4k 42" C2| Debian Sid| KDE 5.x|

Redigera
Citera flera Citera
Permalänk
Datavetare ★
●
Skrivet av klk:

Hur tror du någon parallelliserar arbeten? Det är inte så att man delar upp 5 kodrader i olika trådar utan man delar upp ett större arbete i tårtbitar och så långt som möjligt försöker man undvika att skriva till data i annan tråd. Det är vanligen skrivningen till minne som avgör hur man splittrar arbetet.

Vet att det finns språk som scala exempel, de gör en grej av att vara funktionell programmering (stateless) och splitta upp allt i trådar men det har en mycket hög kostnad.

Gå till inlägget

Visst, men ser inte hur STL och RVALUE-referenses har någon som helst relevant påverkan ovan.

Enda jag säger här är att med tracing GC kan man använda datastrukturer över flera kärnor på ett sätt som minskar och för läsare helt undviker explicita lås och liknande. Det är en fördelen för att skala över CPU-kärnor både på Zen och Core, men då core-to-core kommunikation är dyrare för Zen är det en extra stor fördel för Zen att kunna använda "wait/lock-free" algoritmer i lägen där trådar måste dela data.

Skrivet av tellus82:

Men herre min... Gå tillbaka och läs om inläggen, snälla... Jag påvisade att det finns mjukvara som aktivt undviker icke fysiska kärnor och påtalade att dessa idag inte känner igen ryzen. Du ville då ha ett exempel på bara en mjukvara som gjorde detta i din normala översittarton. Senare visade jag exakt ett sådant fall och nu börjar du då svamla om att schedulern fixar detta, hur ska du ha det? Antingen tar schedulern hand om detta enskilt och då kräva det att schedulern gör samma på ryzen vilket den idag inte gör, eller så är det mjukvaran i sig som gör det och då behöver den känna igen ryzen på korrekt sätt, vilket den idag inte gör. Att du glider ifrån dina egna felaktiga påståenden är knappast mitt fel.

Skickades från m.sweclockers.com

Gå till inlägget

Försöker inte vara ohövligt, men vill inte heller linda in något då det tenderar bli ännu värre (framförallt långt fler missförstånd).

Men finns överhuvudtaget inget i det du visar ovan som antyder något annat än att programmet i fråga faktiskt inte är speciellt CPU-bundet. Om det aktivt låst sig på fyra CPU-trådar matchade en tråd per fysisk kärna och inte utnyttjar dessa CPU-trådar fullt ut (vilket är fallet här) så är det ju det ett hyfsat optimal val när du har en CPU med SMT. Det enda som potentiell skulle kunna vara ännu bättre vore att låsa allt jobb till två CPU-trådar på olika kärnor, det skulle öka cache-lokaliteten.

För övrigt. Om det är programmet som explicit låst sig till en delmängd trådar så säger det ingenting om huruvida Windows är fel eller ej. Det är inte heller något som påverkas av cache-topologin för ett sådant val är det sannolikare att programmet gör baserat på CPU-tråd-topologin (som är korrekt).

Vidare, om programmet låst sig till specifika CPU-trådar ska du kunna se det i "Details" för dina processer i "Taskmanager" under "Set affinity" alternativet. Är det så att denna benchmark själv låser sig till de trådarna? Testa att explicit låsa programmet till CPU-tråd 1 och 3, du kan mycket väl få ett bättre resultat då.

Edit: om jag lastar min dator med 6 program som är helt oberoende av varandra där tillsammans konsumerar motsvarande kraft av 2-3 CPU-kärnor ser jag exakt samma mönster, Windows väljer att primärt köra dessa på kärna 1,3,5,7 på ett system med fyra kärnor med SMT. Ingen av mina program har affinititet till en specifik CPU-kärna, utan är helt upp till Windows.

Dold text

Så endera har min dator samma bug, eller så begriper jag inte alls vad du anser problemet består i.

Senast redigerat
Visa signatur

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

Redigera
Citera flera Citera
183 184 185 186 187 188 189 190
Skriv svar