AMD Ryzen Threadripper med 16 kärnor hittar ut på webben

Permalänk
Medlem
Skrivet av SweMerlin:

Intel lyckas rätt bra, tycker jag. Till skillnad från AMD som iställlet satsar på en massa kärnor.

Jo, men det tyckte man förut också. Sedan släppte AMD en processor med två kärnor och ganska snabbt började det spela grymt mer roll än den enkeltrådade prestandan Intel i sina enkärniga CPU:er hade. Detta kommer utspela sig igen. Mer och mer köra parallellt idag. Vi kör mer och mer saker sammtidigt idag. Spel samtidigt som TS, streaming, Windows Indexer, you name it.
Med rätt skriven kod så kan du få exakt skalning med antalet kärnor. Skrivs då bara koden rätt så springer en CPU med fler kärnor snabbt cirklar kring en med lägre antal kärnor men lite högre klockfrekvens (om IPC är nogorlunda lika).

Redan idag kan vi dra nytta av fler kärnor i och med att vi kör multitaskande operativsystem som automatiskt drar nytta av detta. Hade vi kört DOS och endast ett aktivt program så hade det sett annorlunda ut. Men den stora vinsten kommer när enskillda program mer anpassas för att köra saker parallelt. Detta skifte har vi sett påbörjas och dessa processorer i konsumentvänliga prisklasser kommer hjälpa till att skynda på detta. Och vi kommer vara glada för det. De som kliade sig i huvudet över två kärnor på en CPU när Intel körde vidare på en kärna förstod också med tiden

Visa signatur

Huvudriggen är en Gigabyte Aorus Xtreme | 128gb DDR5 6000 | Ryzen 7950X | 3080Ti
Utöver det är det för många datorer, boxar och servar för att lista :P

Permalänk
Medlem
Skrivet av inquam:

Har svårt att minnas en kompilator för C++ som endast varit enkeltrådad. Dagens C++ kompilatorer stödjer iaf att utvecklaren skapar hur många trådar han vill och det finns också moderna tillägg till C++ som gör det möjligt att köra saker parallelt utan att behöva dra igång trådar helt manuellt. Exempelvis "räkna ut saker vid sidan om och ge mig resultatet när jag ber om det" (std::promise/std::future).

Vad det handlar om är att utvecklare skall börja utveckla med parallelism i tänket. Det görs till viss del idag, men mycket traditionell spelutveckling har exempelvis lärts ut väldigt sekventiellt. Sedan tillkommer myten om att "trådat är så svårt" som gör att många utvecklare inte tittar närmare på det om de inte måste. Det är egentligen inte så svårt om man vet vad man skall tänka på.
Dock har motorer designats får en eller ett fåtal trådar under mycket lång tid och det krävs att man tänker om en del för att verkligen kunna dra så stor nytta av den nya kraften som möjligt. Tidigare har man kanske kört fysiksimulering i en egen tråd för att den har gått lätt att isolera och sedan varit nöjd. Men idag handlar det om att tänka mycket längre än så och att kanske även olika delar inom fysiksimuleringen beräknas parallellt. Men när vi når dit, då kommer processorer med ett fåtal trådar se ut som stenåldersredskap rätt fort.

Låter som vi får spara posten i 10år och se resultatet då
32 trådar skall i 50% av alla applikationer pressa ut prestandan ganska rejält.
Händer det har JAG fel. Händer det inte har DU fel.

Permalänk
Medlem
Skrivet av Triton242:

Låter som vi får spara posten i 10år och se resultatet då
32 trådar skall i 50% av alla applikationer pressa ut prestandan ganska rejält.
Händer det har JAG fel. Händer det inte har DU fel.

På vilket sätt? Svårt att se logiken i vad du säger.
Om de kodas rätt så kommer de dra stor nytta säger jag. Om du inte tror det är grejen så testa din tes genom att installera Windows 95 (nästan tio år gammalt och inte fokus på en massa trådar) och se om det går galet mycket snabbare på en cpu med 16 kärnor än en med 4. Hade det endast handlat om kompilatorer som på något magiskt vis skötte allt så hade man ju bara kunnat kompilera om alla spelmotorer osv i en modern kompilator och så hade det magiskt dragit nytta av alla nya kärnor. Men det krävs "tyvärr" att man tänker på detta när man kodar. Däremot är jag säker på att vi inom mycket snar framtid kommer se utvecklare som tänker mer på att parallelisera än idag.

Visa signatur

Huvudriggen är en Gigabyte Aorus Xtreme | 128gb DDR5 6000 | Ryzen 7950X | 3080Ti
Utöver det är det för många datorer, boxar och servar för att lista :P

Permalänk
Medlem

Högre klockfrekvenser och högre IPC är ändå lite av en återvändsgränd. Inte ens Intel har ju lyckats pressa upp dem så mycket de senaste 5-6 åren. Kan man få ut 10% mer prestanda den vägen vore det imponerande.

Så lyckas inte spel och program ta tillvara på fler kärnor i framtiden kommer utvecklingen av datorprestanda helt enkelt att avstanna. Den enda vägen framåt är fler kärnor, eller något nytt exotiskt material som gör att man kan nå upp i 8-10 GHz.

Visa signatur

Ryzen 7 3800X, Asus Prime X370 Pro, 32 GB LPX 3600, Gainward RTX 3060 Ti Ghost, 7 TB SSD + 4 TB HDD

Permalänk
Medlem

Får se hur mycket det kommer att kosta. Kanske blir det ytterligare en uppgradering

Visa signatur

WINDOWS 11 X64 | ASUS X570 | AMD RYZEN 3950X | RX 7900 XTX | G.SKILL 3600MHZ 32GB | SAMSUNG 980 PRO 2TB | WD 16TB | NZXT KRAKEN X73 | RAZER ORNATA CHROMA | EVGA SUPERNOVA T2 850W | LOGITECH G604 MUS | PHANTEKS NV7 | LG 34GK950F | LG OLED77G1 |

Permalänk
Medlem
Skrivet av Bakwetu:

Kommer säkert kosta runt $3000. xD

Visa signatur

Ryzen 5600X | Asus B550-F Gaming | 32GB G.Skill Trident Z 3600mhz | Powercolor 6800 XT | Seasonic Prime TX 850W

Athlon 64, du har alltid en plats i mitt hjärta. <3

Permalänk
Medlem
Skrivet av _Merc_:

nu snackar du mycket skit. "Överkörd" så långt ifrån sanningen du kan komma. Stock vs stock där ryzen får minnen upp till 3600 mhz går det om och vid överclock drar de jämnt. Och du glömmer att ryzen inte används fullt ut för att mjukvaran håller tillbaka dem.

Skickades från m.sweclockers.com

I vilket spel då, exakt?

Sweclockers recensioner säger väl allt:
"Nackdelar

Dålig överklockningspotential

Halkar efter Intel i spelprestanda"

http://www.sweclockers.com/test/23426-amd-ryzen-7-1800x-och-7...

Lägg av med det där skitsnacket att Ryzen skulle vara ens nära att vara jämn med Intel. I 90% av spelen halkar de efter alldeles för långt back för att vara current-gen. Du kan också droppa det där AMD-fanboy-typiska argumentet "buhu mjukvaran håller tillbaka".

Visa signatur

| Corsair Crystal 460X | Z390-F | 9700K | ROG Ryujn 360mm | RTX 3080Ti | ROG Thor 850W | Vengeance Pro 3200mhz 16cl 16GB (2x8) | 970 Pro 2TB + 2xWD Black 4TB | ROG SWIFT PG279Q | Arctis 7 Pro Wireless | ROG Scope Deluxe red silent | ROG Chakram |

Permalänk
Datavetare
Skrivet av inquam:

Har svårt att minnas en kompilator för C++ som endast varit enkeltrådad. Dagens C++ kompilatorer stödjer iaf att utvecklaren skapar hur många trådar han vill och det finns också moderna tillägg till C++ som gör det möjligt att köra saker parallelt utan att behöva dra igång trådar helt manuellt. Exempelvis "räkna ut saker vid sidan om och ge mig resultatet när jag ber om det" (std::promise/std::future).

Vad det handlar om är att utvecklare skall börja utveckla med parallelism i tänket. Det görs till viss del idag, men mycket traditionell spelutveckling har exempelvis lärts ut väldigt sekventiellt. Sedan tillkommer myten om att "trådat är så svårt" som gör att många utvecklare inte tittar närmare på det om de inte måste. Det är egentligen inte så svårt om man vet vad man skall tänka på.
Dock har motorer designats får en eller ett fåtal trådar under mycket lång tid och det krävs att man tänker om en del för att verkligen kunna dra så stor nytta av den nya kraften som möjligt. Tidigare har man kanske kört fysiksimulering i en egen tråd för att den har gått lätt att isolera och sedan varit nöjd. Men idag handlar det om att tänka mycket längre än så och att kanske även olika delar inom fysiksimuleringen beräknas parallellt. Men när vi når dit, då kommer processorer med ett fåtal trådar se ut som stenåldersredskap rätt fort.

Att använda många trådar är i sig inte svårt. Har man sedan massor med sinsemellan oberoende problem är det även lätt att utnyttja fler trådar/CPU-kärnor på ett väldigt effektivt sätt.

Problemen hopar sig när problemet man ska lösa är ett enskilt problem. I värsta fall är problemet sekventiellt, då går det överhuvudtaget inte att använda flera CPU-kärnor på något vettigt sätt.

T.ex. spel har viss parallellism, går alltså inte att skala perfekt men man kan absolut få bättre prestanda genom att använda flera kärnor (upp till en viss punkt). Att utnyttja parallellism i dessa fall är fundamental svårt, alla som försökt vet detta. Dels måste man balansera mängden parallellism, blir den för hög kommer prestanda minska! Dels kommer denna typ av problem innehålla tillstånd som delas mellan CPU-trådar, detta måste synkroniseras på ett effektivt och korrekt sätt (misslyckas man med det senare har man ett data-race, något som ger upphov till extremt svårlokaliserade Heisenbugs).

Ett exempel på ett problem med extrem mängd teoretisk parallellism är den rekursiva implementationen av Fibonacci. Detta är en variant som använder std::futures men på ett sätt så det fortfarande är enkeltrådat

uint64_t fib(uint64_t n) { if (n < 2) return n; auto n1_ftr = std::async(std::launch::deferred, fib, n - 1); auto n2 = fib(n - 2); return n1_ftr.get() + n2; }

Samma program men där varje beräkning av fib(n-1) utförs asynkront på en separat tråd

uint64_t fib(uint64_t n) { if (n < 2) return n; auto n1_ftr = std::async(std::launch::async, fib, n - 1); auto n2 = fib(n - 2); return n1_ftr.get() + n2; }

Den seriella varianten är för n=10 i alla fall tusen gånger snabbare än den parallella... Detta är ett extremfall av när man använt alldeles för mycket parallellism, ljusets hastighet (signalers propageringshastighet) visar sitt fula tryne. Hur mycket parallellism som är "optimalt" är i detta fall något man mer eller mindre måste testa sig fram till (== dyrt) och det optimala värdet varierar med antal CPU-kärnor och med CPU-modell (men ofta går det hitta en nivå som är OK över ett rätt brett spann).

Some people, when confronted with a problem, think, “I know, I’ll use threads!” Now they have 10 problems. –Bill Schindler

Multi-core är inte precis nytt, de första SMP servers togs i bruk på 60-talet(!).

För mer än tio år sedan fanns det kretsar med upp till 64-kärnor (som jag tyvärr aldrig jobbade med, men jobbade vid den tiden mycket med 16-kärniga kretsar). Givet rätt typ av problem demolerade dessa CPUer dåtidens x86:or men de var värdelösa som desktop-dator då den typ av problem man normalt ställs inför där tenderar vara latenskritiska, få och sekventiella. Med många kärnor vill man ha problem som är bandbreddskrävande, väldigt många och möjligen även dataparallella (dataparallella problem kan ofta nyttja båda SIMD och flera kärnor).

Så länge det gick att öka frekvens var det meningslöst med flera kärnor på skrivbordet. Allt blir snabbare när enkeltrådprestanda ökar, men bara vissa saker blir snabbare av flera kärnor. Sett till total kraft var det däremot bättre med flera kärnor redan på 60-talet, så givet "rätt" problem har multi-core varit ett bättre val ca ett halvt århundrade. Flera kärnor på skrivbordet är ändå helt naturligt idag, inte för att det är en bra idé utan för att det är den enda vägen som har någon möjlighet till bättre prestanda idag

En CPU som Threadripper kommer bli väldigt utmanande att jobba med utanför fall där man har massor med helt oberoende problem. CPUn är ju två 8-kärniga CPUer i samma kapsel, d.v.s. logiskt är det samma problem som två 8-kärnors CPUer, det är ett NUMA-system (två separata dual-channel RAM öar, det är INTE en quad-channel), något som får CCX-problematiken att verkligen kännas som en grönområdespromenad

Visa signatur

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

Permalänk
Avstängd
Skrivet av Mithras:

I vilket spel då, exakt?

Sweclockers recensioner säger väl allt:
"Nackdelar

Dålig överklockningspotential

Halkar efter Intel i spelprestanda"

http://www.sweclockers.com/test/23426-amd-ryzen-7-1800x-och-7...

Lägg av med det där skitsnacket att Ryzen skulle vara ens nära att vara jämn med Intel. I 90% av spelen halkar de efter alldeles för långt back för att vara current-gen. Du kan också droppa det där AMD-fanboy-typiska argumentet "buhu mjukvaran håller tillbaka".

yes för att sweclockers tester med som inte är uppdaterade för nya BIOS och minnes support och inte kört i 3600 mhz minnen. dags att du kollar runt på fler källor.

https://www.youtube.com/watch?v=RZS2XHcQdqA&t

https://www.youtube.com/watch?v=BXVIPo_qbc4

https://www.youtube.com/watch?v=JASuqhT8prk&t

Visa signatur

New: Asus x370 prime pro, Ryzen 1700 (@3.925ghz) , Ripjaws V 16GB 3600 MHz (@3200mhz 14c). https://valid.x86.fr/curj7r
Radeon VII.

Permalänk
Medlem
Skrivet av Yoshman:

Att använda många trådar är i sig inte svårt. Har man sedan massor med sinsemellan oberoende problem är det även lätt att utnyttja fler trådar/CPU-kärnor på ett väldigt effektivt sätt.

Problemen hopar sig när problemet man ska lösa är ett enskilt problem. I värsta fall är problemet sekventiellt, då går det överhuvudtaget inte att använda flera CPU-kärnor på något vettigt sätt.

T.ex. spel har viss parallellism, går alltså inte att skala perfekt men man kan absolut få bättre prestanda genom att använda flera kärnor (upp till en viss punkt). Att utnyttja parallellism i dessa fall är fundamental svårt, alla som försökt vet detta. Dels måste man balansera mängden parallellism, blir den för hög kommer prestanda minska! Dels kommer denna typ av problem innehålla tillstånd som delas mellan CPU-trådar, detta måste synkroniseras på ett effektivt och korrekt sätt (misslyckas man med det senare har man ett data-race, något som ger upphov till extremt svårlokaliserade Heisenbugs).

Ett exempel på ett problem med extrem mängd teoretisk parallellism är den rekursiva implementationen av Fibonacci. Detta är en variant som använder std::futures men på ett sätt så det fortfarande är enkeltrådat

uint64_t fib(uint64_t n) { if (n < 2) return n; auto n1_ftr = std::async(std::launch::deferred, fib, n - 1); auto n2 = fib(n - 2); return n1_ftr.get() + n2; }

Samma program men där varje beräkning av fib(n-1) utförs asynkront på en separat tråd

uint64_t fib(uint64_t n) { if (n < 2) return n; auto n1_ftr = std::async(std::launch::async, fib, n - 1); auto n2 = fib(n - 2); return n1_ftr.get() + n2; }

Den seriella varianten är för n=10 i alla fall tusen gånger snabbare än den parallella... Detta är ett extremfall av när man använt alldeles för mycket parallellism, ljusets hastighet (signalers propageringshastighet) visar sitt fula tryne. Hur mycket parallellism som är "optimalt" är i detta fall något man mer eller mindre måste testa sig fram till (== dyrt) och det optimala värdet varierar med antal CPU-kärnor och med CPU-modell (men ofta går det hitta en nivå som är OK över ett rätt brett spann).

Some people, when confronted with a problem, think, “I know, I’ll use threads!” Now they have 10 problems. –Bill Schindler

Multi-core är inte precis nytt, de första SMP servers togs i bruk på 60-talet(!).

För mer än tio år sedan fanns det kretsar med upp till 64-kärnor (som jag tyvärr aldrig jobbade med, men jobbade vid den tiden mycket med 16-kärniga kretsar). Givet rätt typ av problem demolerade dessa CPUer dåtidens x86:or men de var värdelösa som desktop-dator då den typ av problem man normalt ställs inför där tenderar vara latenskritiska, få och sekventiella. Med många kärnor vill man ha problem som är bandbreddskrävande, väldigt många och möjligen även dataparallella (dataparallella problem kan ofta nyttja båda SIMD och flera kärnor).

Så länge det gick att öka frekvens var det meningslöst med flera kärnor på skrivbordet. Allt blir snabbare när enkeltrådprestanda ökar, men bara vissa saker blir snabbare av flera kärnor. Sett till total kraft var det däremot bättre med flera kärnor redan på 60-talet, så givet "rätt" problem har multi-core varit ett bättre val ca ett halvt århundrade. Flera kärnor på skrivbordet är ändå helt naturligt idag, inte för att det är en bra idé utan för att det är den enda vägen som har någon möjlighet till bättre prestanda idag

En CPU som Threadripper kommer bli väldigt utmanande att jobba med utanför fall där man har massor med helt oberoende problem. CPUn är ju två 8-kärniga CPUer i samma kapsel, d.v.s. logiskt är det samma problem som två 8-kärnors CPUer, det är ett NUMA-system (två separata dual-channel RAM öar, det är INTE en quad-channel), något som får CCX-problematiken att verkligen kännas som en grönområdespromenad

Om man vänder på de hela då, att man väljer problem som är enklare att lösa trådat än att försöka välja lösningar för att kunna tråda upp problem som inte kanske kan nystas upp enkelt?

Då tänker jag mig att vi går ifrån rasterering och omfamnar raytrace algoritmer istället. Dessa går idag att tråda upp till minst 95% skalbarhet beräknat på 8 kärnor.
Om vi väljer att lägga fram problem t.ex. vars lösning är fotorealistisk rendering med t.ex. MLT eller liknande bi-directional pathtracer algoritmer så har vi möjlighet att använda flera kärnor, istället för att skohorna in trådat tänk i något som rasterering som i sin helhet är ganska sekventiellt (om jag har förstått det rätt).
Ett annat exempel är om datamängden blir allt för dyr att överföra med tanke på ljusets hastighet så kan kanske kärnorna beräkna fram viss data som t.ex. geometri på ett parametriskt vis från cache med hjälp av flera kärnor.

Min tanke är att man inte approach:ar flertrådat programmering från scratch, att man däremot möter multicore tänket genom att tänka utanför lådan.

Permalänk
Medlem
Skrivet av SolidReactor:

Om man vänder på de hela då, att man väljer problem som är enklare att lösa trådat än att försöka välja lösningar för att kunna tråda upp problem som inte kanske kan nystas upp enkelt?

Då tänker jag mig att vi går ifrån rasterering och omfamnar raytrace algoritmer istället. Dessa går idag att tråda upp till minst 95% skalbarhet beräknat på 8 kärnor.
Om vi väljer att lägga fram problem t.ex. vars lösning är fotorealistisk rendering med t.ex. MLT eller liknande bi-directional pathtracer algoritmer så har vi möjlighet att använda flera kärnor, istället för att skohorna in trådat tänk i något som rasterering som i sin helhet är ganska sekventiellt (om jag har förstått det rätt).
Ett annat exempel är om datamängden blir allt för dyr att överföra med tanke på ljusets hastighet så kan kanske kärnorna beräkna fram viss data som t.ex. geometri på ett parametriskt vis från cache med hjälp av flera kärnor.

Min tanke är att man inte approach:ar flertrådat programmering från scratch, att man däremot möter multicore tänket genom att tänka utanför lådan.

Tack! - äntligen någon som vågar tänka lite djupare

Permalänk
Medlem
Skrivet av Yoshman:

Att använda många trådar är i sig inte svårt. Har man sedan massor med sinsemellan oberoende problem är det även lätt att utnyttja fler trådar/CPU-kärnor på ett väldigt effektivt sätt.

Problemen hopar sig när problemet man ska lösa är ett enskilt problem. I värsta fall är problemet sekventiellt, då går det överhuvudtaget inte att använda flera CPU-kärnor på något vettigt sätt.

T.ex. spel har viss parallellism, går alltså inte att skala perfekt men man kan absolut få bättre prestanda genom att använda flera kärnor (upp till en viss punkt). Att utnyttja parallellism i dessa fall är fundamental svårt, alla som försökt vet detta. Dels måste man balansera mängden parallellism, blir den för hög kommer prestanda minska! Dels kommer denna typ av problem innehålla tillstånd som delas mellan CPU-trådar, detta måste synkroniseras på ett effektivt och korrekt sätt (misslyckas man med det senare har man ett data-race, något som ger upphov till extremt svårlokaliserade Heisenbugs).

Ett exempel på ett problem med extrem mängd teoretisk parallellism är den rekursiva implementationen av Fibonacci. Detta är en variant som använder std::futures men på ett sätt så det fortfarande är enkeltrådat

uint64_t fib(uint64_t n) { if (n < 2) return n; auto n1_ftr = std::async(std::launch::deferred, fib, n - 1); auto n2 = fib(n - 2); return n1_ftr.get() + n2; }

Samma program men där varje beräkning av fib(n-1) utförs asynkront på en separat tråd

uint64_t fib(uint64_t n) { if (n < 2) return n; auto n1_ftr = std::async(std::launch::async, fib, n - 1); auto n2 = fib(n - 2); return n1_ftr.get() + n2; }

Den seriella varianten är för n=10 i alla fall tusen gånger snabbare än den parallella... Detta är ett extremfall av när man använt alldeles för mycket parallellism, ljusets hastighet (signalers propageringshastighet) visar sitt fula tryne. Hur mycket parallellism som är "optimalt" är i detta fall något man mer eller mindre måste testa sig fram till (== dyrt) och det optimala värdet varierar med antal CPU-kärnor och med CPU-modell (men ofta går det hitta en nivå som är OK över ett rätt brett spann).

Some people, when confronted with a problem, think, “I know, I’ll use threads!” Now they have 10 problems. –Bill Schindler

Multi-core är inte precis nytt, de första SMP servers togs i bruk på 60-talet(!).

För mer än tio år sedan fanns det kretsar med upp till 64-kärnor (som jag tyvärr aldrig jobbade med, men jobbade vid den tiden mycket med 16-kärniga kretsar). Givet rätt typ av problem demolerade dessa CPUer dåtidens x86:or men de var värdelösa som desktop-dator då den typ av problem man normalt ställs inför där tenderar vara latenskritiska, få och sekventiella. Med många kärnor vill man ha problem som är bandbreddskrävande, väldigt många och möjligen även dataparallella (dataparallella problem kan ofta nyttja båda SIMD och flera kärnor).

Så länge det gick att öka frekvens var det meningslöst med flera kärnor på skrivbordet. Allt blir snabbare när enkeltrådprestanda ökar, men bara vissa saker blir snabbare av flera kärnor. Sett till total kraft var det däremot bättre med flera kärnor redan på 60-talet, så givet "rätt" problem har multi-core varit ett bättre val ca ett halvt århundrade. Flera kärnor på skrivbordet är ändå helt naturligt idag, inte för att det är en bra idé utan för att det är den enda vägen som har någon möjlighet till bättre prestanda idag

En CPU som Threadripper kommer bli väldigt utmanande att jobba med utanför fall där man har massor med helt oberoende problem. CPUn är ju två 8-kärniga CPUer i samma kapsel, d.v.s. logiskt är det samma problem som två 8-kärnors CPUer, det är ett NUMA-system (två separata dual-channel RAM öar, det är INTE en quad-channel), något som får CCX-problematiken att verkligen kännas som en grönområdespromenad

Håller med om allt du skriver och du vet helt klart mer än typ alla om detta, men när det gäller argumentet att köra flera program samtidigt och göra saker i bakgrunden så är väl ändå det ett relevant argument (har aldrig sett dig svara på det). För det klarar väl moderna operativsystem av att hantera så att arbetet sprids?

Det är huvudanledningen till att jag är intresserad av en mångkärnig variant (framförallt) till jobbet där jag ofta gör en del CPU tunga saker samtidigt som jag jobbar med annat (COMSOL (FEA-simuleringar som körs på CPU), SolidWorks, Matlab och en del annat kan vara igång samtidigt och jobbas med). Jag kommer defenitivt vilja ha en med 4kanaligt minne (då det är extremt avgörande för framförallt simuleringsprestandan, huvudsaklig flaskhals, skalar knappt ens med CPU-frekvens) och jag funderar kring både Threadripper och Intels motsvarande, jag skulle kunna vara beredd att stödköpa lite AMD om prestandan är snarlik eller kan motiveras av att vara bättre i vissa fall.

Permalänk
Medlem
Skrivet av inquam:

Jo, men det tyckte man förut också. Sedan släppte AMD en processor med två kärnor och ganska snabbt började det spela grymt mer roll än den enkeltrådade prestandan Intel i sina enkärniga CPU:er hade. Detta kommer utspela sig igen. Mer och mer köra parallellt idag. Vi kör mer och mer saker sammtidigt idag. Spel samtidigt som TS, streaming, Windows Indexer, you name it.
Med rätt skriven kod så kan du få exakt skalning med antalet kärnor. Skrivs då bara koden rätt så springer en CPU med fler kärnor snabbt cirklar kring en med lägre antal kärnor men lite högre klockfrekvens (om IPC är nogorlunda lika).

Redan idag kan vi dra nytta av fler kärnor i och med att vi kör multitaskande operativsystem som automatiskt drar nytta av detta. Hade vi kört DOS och endast ett aktivt program så hade det sett annorlunda ut. Men den stora vinsten kommer när enskillda program mer anpassas för att köra saker parallelt. Detta skifte har vi sett påbörjas och dessa processorer i konsumentvänliga prisklasser kommer hjälpa till att skynda på detta. Och vi kommer vara glada för det. De som kliade sig i huvudet över två kärnor på en CPU när Intel körde vidare på en kärna förstod också med tiden

Som jag förstått det så är det bra mycket enklare att ta fram en CPU med många kärnor än att programmera spel och programm så att de kan använda alla dessa kärnor Mjukvaran måste skala något offantligt. Detta ser vi även på att de flesta spel och program är förbenat dåliga på att använda mer än ett fåtal trådar.

Visa signatur

AMD Thunderbird 1.33 GHz (133 MHz Bus), Epox 8K7A, 1 x 256MB Corsair PC2100 DDR SDRAM, 20.5GB 7200 RPM Western Digital EIDE, Visiontek GeForce 3

Permalänk

@skewgen:
SolidWorks använder en kärna vid modellering.
Renderingar kan använda flera kärnor

Permalänk
Medlem

@ZaaphodBleebronx: Okej, misstänkte att SolidWorks inte använde så många. Vet att simuleringarna går på i stort sett alla kärnor som finns tillgängliga (och maxar dessa dessutom för det mesta). Men det finns ofta en gräns när det blir bättre att begränsa kärnorna manuellt, generellt tror jag man bör ha 2-4 kärnor per minneskanal för bäst effekt, även om det är väldigt problemberoende.

Min fråga var dock snarare hur bra operativsystem är på att distribuera arbetet. Dvs, är det möjligt att använda datorn till annat samtidigt som man kör simuleringar osv i större utsträckning med en väldigt flerkärnig CPU (jag tänker mest på området 8 vs 16 kärnor inkl HT), kommer man märka någon skillnad i de scenarierna? Det kanske inte spelar någon roll om man har outnyttjade kärnor om man ändå belastar hela minnesbussen..? Resten av systemet kanske går segt i alla fall då?

Permalänk
Medlem
Skrivet av Mithras:

I vilket spel då, exakt?

Sweclockers recensioner säger väl allt:
"Nackdelar

Dålig överklockningspotential

Halkar efter Intel i spelprestanda"

http://www.sweclockers.com/test/23426-amd-ryzen-7-1800x-och-7...

Lägg av med det där skitsnacket att Ryzen skulle vara ens nära att vara jämn med Intel. I 90% av spelen halkar de efter alldeles för långt back för att vara current-gen. Du kan också droppa det där AMD-fanboy-typiska argumentet "buhu mjukvaran håller tillbaka".

Inte skulle vara current gen cpu?
You sir are a joke. Håll dig till din Fiat. Jag kör en dodge istället

Skämt och sido 😌. Du bad om det.

Skickades från m.sweclockers.com

Visa signatur

Lightsaber - Black armour - and balls!

Permalänk
Medlem
Skrivet av SweMerlin:

Som jag förstått det så är det bra mycket enklare att ta fram en CPU med många kärnor än att programmera spel och programm så att de kan använda alla dessa kärnor Mjukvaran måste skala något offantligt. Detta ser vi även på att de flesta spel och program är förbenat dåliga på att använda mer än ett fåtal trådar.

Njae... Jag kan koda och dra nytta av många kärnor, men jag skulle knappast kunna ta fram en CPU med många kärnor. Så så mycket enklare vet jag inte om det är. Dock stämmer det att man måste koda med parallelism i tanken för att dra nytta av kärnorna. Detta är dock inte något som är direkt jättesvårt. Att utnyttja alla kärnor till 100% är dock väldigt svårt att få till, men att utnyttja parallelism bättre än vi gör idag är inte jättesvårt.

Det vi till stor del dras med när det gäller spel är att många började utveckla innan en massa trådar var en grej, utbildningar har lärat ut att koda spel väldigt sekventiellt, det för många känns skrämmande att tänka trådar så de låter bli och att processorer varit tillräckligt snabba för att "dölja" att vi inte utnyttjar deras prestanda fullt ut.

Då många idag bygger sina spel på existserande teknologier som Unity, Unreal Engine etc så är de fast i arvet av hur dessa motorer är byggda. Därav kommer skiftet inte direkt. Men det har helt klart påbörjats och kommer nog få ett helt annat fokus än vad det traditionellt har haft. Istället för att ha någon "tråd expert" (vilket jag sett bolag som haft) så kommer det vara en naturlig del av fler utvecklares verktygslåda.

Visa signatur

Huvudriggen är en Gigabyte Aorus Xtreme | 128gb DDR5 6000 | Ryzen 7950X | 3080Ti
Utöver det är det för många datorer, boxar och servar för att lista :P

Permalänk
Medlem

Folk som tror nån % performance enkeltrådat är att föredra framför typ 100% flertrådat får tänka om.

Hårdvaran går mot fler kärnor och folk köper denna hårdvara.
För att spel ska vara fetast o ha bäst grafik så får de lära sig att koda för den hårdvara som finns tillgänglig, annars så är inte spelet det bästa och något annat spel kommer vara bättre.

Ryzen klarar väll att driva runt alla nuvarande spel?

Permalänk
Discokungen
Skrivet av _Merc_:

yes för att sweclockers tester med som inte är uppdaterade för nya BIOS och minnes support och inte kört i 3600 mhz minnen. dags att du kollar runt på fler källor.

https://www.youtube.com/watch?v=RZS2XHcQdqA&t

https://www.youtube.com/watch?v=BXVIPo_qbc4

https://www.youtube.com/watch?v=JASuqhT8prk&t

Det är inte direkt några bra jämförelser egentligen. Han borde ha jämfört 7700K med samma hastighet på minnet också och haft med 7600K. Intel har bra mycket högre frekvenser så det hade inte heller varit dumt att köra allt i samma klockfrekvens för att jämföra IPC, speciellt i spel i vanlig upplösning. I övrigt tappar Ryzen med åtta kärnor rätt mycket när det inte är spel som använder många trådar som GTA 5, som sig bör. Det är en bra bit tills dess att spel kan använda 8 kärnor effektivt.

Ryzen är dock en bra arkitektur och Threadripper är fantastiskt kostnadseffektiv för mängden kärnor. Otroligt användbart i lägen en behöver flertrådad prestanda till lägre priser än Intel. Jag ser glatt framemot konkurrensen för det behöver verkligen Intel och AMD behöver tjäna mer pengar!

Visa signatur

AMD 5800X3D - G.Skill Trident Z 3200 CL16 32GB - Asus B550 TUF - ASRock 7900 XTX Phantom - Intel 900p - CaseLabs S8 - LG 42C2 - Corsair AX1200i - Aquaero 6 - Vattenkyld

Permalänk
Datavetare
Skrivet av SolidReactor:

Om man vänder på de hela då, att man väljer problem som är enklare att lösa trådat än att försöka välja lösningar för att kunna tråda upp problem som inte kanske kan nystas upp enkelt?

Då tänker jag mig att vi går ifrån rasterering och omfamnar raytrace algoritmer istället. Dessa går idag att tråda upp till minst 95% skalbarhet beräknat på 8 kärnor.
Om vi väljer att lägga fram problem t.ex. vars lösning är fotorealistisk rendering med t.ex. MLT eller liknande bi-directional pathtracer algoritmer så har vi möjlighet att använda flera kärnor, istället för att skohorna in trådat tänk i något som rasterering som i sin helhet är ganska sekventiellt (om jag har förstått det rätt).
Ett annat exempel är om datamängden blir allt för dyr att överföra med tanke på ljusets hastighet så kan kanske kärnorna beräkna fram viss data som t.ex. geometri på ett parametriskt vis från cache med hjälp av flera kärnor.

Min tanke är att man inte approach:ar flertrådat programmering från scratch, att man däremot möter multicore tänket genom att tänka utanför lådan.

Just grafik är ett problem man tittat på väldigt mycket, GPUer är ju specialdesignade kretsar som tar tillvara just den typ av parallellism som finns där.

Att du nämner ray-tracing (antar att du med det menar path-tracing) är illustrativt för denna diskussion då det kastar mer ljus på hur komplex "parallellism" kan vara, det innan man ens skapat sin första tråd.

En GPU är brutalt mycket snabbare jämfört med en CPU på problem som är av typen: massor med indata -> transform(data) -> massor med utdata, där transformen är så beskaffad att en klar majoritet av alla datapunkter följer samma beräkning. Rent praktiskt är det kritiska att alla datapunkter i en "warp"/"wavefront" (32 trådar för Nvidia och 64 trådar för AMD) följer samma beräkning.

Path-tracing är precis som "traditionell" 3D-datorgrafik ett problem som är "embarrassingly parallel" (då det är inte 95 % parallellt, det är >99 % parallellt vilket även är fallet för rastrering), men det är ändå inte jätteeffektivt att köra på GPUer då beräkningen utefter två olika strålar (motsvarande två olika pixels på skärmen) med väldigt stor sannolikhet kommer divergera (följa olika beräkningar) så fort man träffar på en yta. Det optimala för just path-tracing verkar vara massor med CPU-kärnor + SIMD (SSE/AVX för x86) för t.ex. att hitta skärningspunkter för alla tre dimensioner i en smäll.

Så absolut, måste man använda path-tracing är en CPU med massor med kärnor + SIMD bättre än en GPU (även om det kanske är snarlik prestanda i bästa fall för GPUn drar är CPU-spåret mer energieffektivt). Men för spel, där man har möjligheten att välja hur man vill representera sin värld, är rastrering långt vettigare då en GPU gör detta hundratals gånger mer effektivt jämfört med multicore CPUer.

Rent generellt kan man inte välja vilket problem man ska lösa, problemet dikteras liksom av vad man är ute efter. I vissa lägen kan det självklart finnas algoritmer som kan köras på flera CPU-kärnor, i de flesta fall finns tenderar de mest effektiva algoritmerna vara sekventiella och de är så pass mycket mer effektiva att de blir ett vettigare val att köra på en CPU-tråd (då har man även kvar kapaciteten i övriga kärnor till eventuella andra uppgifter).

För att åter ta Fibonacci-exemplet. Den rekursiva definitionen har massiv möjlighet till parallellism, styr man parallellismen till en rimlig nivå skalar det jag listade ovanutan problem perfekt till både 8 och 16 kärnor. För n=48 är skalningen till åtta kärnor i princip perfekt och den är x15,8 till sexton kärnor (tar totalt 0,76s). Men den sekventiella algoritmen är över tusen gånger snabbare, den tar inte ens en mikrosekund att beräkna n=48.

uint64_t fib(uint64_t n) { uint64_t f1 = 0; uint64_t f2 = 1; while (n-- > 0) { std::tie(f1, f2) = std::make_tuple(f2, f1 + f2); } return f1; }

^ Exempel på sekventiellt lösning i C++11

Skrivet av skewgen:

Håller med om allt du skriver och du vet helt klart mer än typ alla om detta, men när det gäller argumentet att köra flera program samtidigt och göra saker i bakgrunden så är väl ändå det ett relevant argument (har aldrig sett dig svara på det). För det klarar väl moderna operativsystem av att hantera så att arbetet sprids?

Det är huvudanledningen till att jag är intresserad av en mångkärnig variant (framförallt) till jobbet där jag ofta gör en del CPU tunga saker samtidigt som jag jobbar med annat (COMSOL (FEA-simuleringar som körs på CPU), SolidWorks, Matlab och en del annat kan vara igång samtidigt och jobbas med). Jag kommer defenitivt vilja ha en med 4kanaligt minne (då det är extremt avgörande för framförallt simuleringsprestandan, huvudsaklig flaskhals, skalar knappt ens med CPU-frekvens) och jag funderar kring både Threadripper och Intels motsvarande, jag skulle kunna vara beredd att stödköpa lite AMD om prestandan är snarlik eller kan motiveras av att vara bättre i vissa fall.

"Best-case" för NUMA-system (vilket Threadripper är, den har två NUMA-zoner så är logiskt en dual-socket 8-kärnors system) är att varje NUMA-zon jobbar med hel separata uppgifter. Absolut "best-case" är om man har massor med enkeltrådade uppgifter. som sinsemellan är i det närmaste oberoende.

Några exempel i verkligheten där det gäller är: kompilering av massor med filer, path-tracing (varje pixel kan beräknas helt oberoende av alla andra), matris-multiplikation (varje cell i matrisen kan beräknas oberoende av alla andra). Så finns absolut fall, men de är inte jättemånga (matris-multiplikation är dock väldigt generellt användbart).

Handlar det mer om att köra mer normala desktop-program parallellt så är skalningen med CPU-kärnor långt sämre än vad många verkar tro (t.ex. här där i3-4130 drar jämnt med FX-8350 när man kör fyra CPU-tunga program parallellt, ingen jätteskillnad mellan Intel 2 och 4 kärniga heller utanför skillnad i frekvens).

Just multi-tasking har ändå blivit bättre när man har flera kärnor, den viktigaste orsaken är tekniker som Intels speed-shift (där val av s.k. P-states flyttas från OS-kärnan direkt till kretsen då kretsen kan regera flera tiopotenser snabbare på förändrad last). Även Ryzen verkar ha långt större frihet att välja frekvens i kretsen jämfört med tidigare, men det verkar inte vara lika långtgående som speed-shift där hela frekvensskalningen effektivt sett hanteras av CPUn själv (OS-kärnan ger bara en vink om man ska prioritera hög prestanda eller låg strömförbrukning).

Med traditionell P-state hantering kan upplevd prestanda i värsta fall minska när antalet kärnor ökar under multitasking där de flesta saker jobbar med I/O (disk, nätverk etc). Detta då sannolikhet blir högre att den latenskritiska processen man som användare interagerar med råkar hamna på en CPU-kärna som har ett högt P-state (låg frekvens), frekvensskalningen låg då på millisekundskala (med speedshift är den på tiotals mikrosekunder).

Har aldrig hävdat att det inte finns några fall där många kärnor är väldigt användbart, att man kört SMP sedan 60-talet visar att så inte är fallet. Däremot tenderar det man gör på en typisk skrivbordsdator vara långt mer latenskritisk än beräkningskapacitetkritiskt, latens skalar i de flesta fall knappt alls med CPU-kärnor medan det (precis som allt som är CPU-bundet) skalar perfekt med prestanda per kärna. Är ingen slump att bärbara idag står för ~70 % av PC-marknaden och att bärbara nästan uteslutande nöjer sig med två kärnor, idag kan man nå 4,0 GHz med 15 W TDP (men lär vara stopp där, så nu är enda möjligheten även här att börja öka antal kärnor alt. stoppa in mer kisel som löser en specifik uppgift vilket är riktningen mobiler allt mer tar).

Visa signatur

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

Permalänk
Datavetare

Då det förra inlägget är långt nog: spel har en väldigt trevlig egenskap i att det är ren fiktion. Här finns alltså en del utrymme att välja vilka typer av problem som ska lösas.

Men finns ändå en del ramar man måste förhålla sig till, vissa speltyper kommer vara lättare att skala över CPU-kärnor än andra.

I grunden är ett spel ett stort problem som har mer eller mindre inneboende parallellism, så det man med 100 % säkerhet kan säga är att spel aldrig kommer skala i närheten av perfekt med CPU-kärnor. Är dock fullt möjligt att se en viss boost från rejält med kärnor, redan idag ser de flesta spel > 0% skalning till mellan 6-8 kärnor. Dock är skalning så pass låg att om övergången till 4 -> 6 kärnor (t.ex. i7-7700K -> i7-6850K) medför lägre enkeltrådprestanda så presterar de flesta spel bättre med färre och högre klockade kärnor.

För Ryzen finns ju inte den aspekten då den högst klockade modellen är 1800X som också har flest kärnor (1600X är i princip identiskt klockad och den presterar i det närmaste identiskt i de flesta spel, faktiskt något bättre i vissa vilket tyder på att spelmotorn använder för mycket parallellism, men finns fall där 1800X också presterar lite bättre (AoS)).

Threadripper lägger tyvärr in en extra komplicerade faktor: NUMA. Finns i princip noll desktop-program som är NUMA-anpassade. Förutom rendering och server-laster lär det vara svårt att hitta något som är riktigt optimalt här.

Naturligtvis kan man t.ex. dela upp sin dator med virtualisering, huvud-OS på ena NUMA-zonen och en eller flera virtualiserade OS på andra NUMA-zonen. Så går absolut att hitta fall, men det är nischer.

Visa signatur

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

Permalänk
Medlem
Skrivet av Moriquende:

Kommer säkert kosta runt $3000. xD

1999 dollars för att vara exakt

https://www.windowscentral.com/intels-core-i9-extreme-edition...

Visa signatur

"What doesn't kill you makes you smaller." -Super Mario

Permalänk
Medlem
Skrivet av Yoshman:

"Best-case" för NUMA-system (vilket Threadripper är, den har två NUMA-zoner så är logiskt en dual-socket 8-kärnors system) är att varje NUMA-zon jobbar med hel separata uppgifter. Absolut "best-case" är om man har massor med enkeltrådade uppgifter. som sinsemellan är i det närmaste oberoende.

Några exempel i verkligheten där det gäller är: kompilering av massor med filer, path-tracing (varje pixel kan beräknas helt oberoende av alla andra), matris-multiplikation (varje cell i matrisen kan beräknas oberoende av alla andra). Så finns absolut fall, men de är inte jättemånga (matris-multiplikation är dock väldigt generellt användbart).

Handlar det mer om att köra mer normala desktop-program parallellt så är skalningen med CPU-kärnor långt sämre än vad många verkar tro (t.ex. här där i3-4130 drar jämnt med FX-8350 när man kör fyra CPU-tunga program parallellt, ingen jätteskillnad mellan Intel 2 och 4 kärniga heller utanför skillnad i frekvens).

Just multi-tasking har ändå blivit bättre när man har flera kärnor, den viktigaste orsaken är tekniker som Intels speed-shift (där val av s.k. P-states flyttas från OS-kärnan direkt till kretsen då kretsen kan regera flera tiopotenser snabbare på förändrad last). Även Ryzen verkar ha långt större frihet att välja frekvens i kretsen jämfört med tidigare, men det verkar inte vara lika långtgående som speed-shift där hela frekvensskalningen effektivt sett hanteras av CPUn själv (OS-kärnan ger bara en vink om man ska prioritera hög prestanda eller låg strömförbrukning).

Med traditionell P-state hantering kan upplevd prestanda i värsta fall minska när antalet kärnor ökar under multitasking där de flesta saker jobbar med I/O (disk, nätverk etc). Detta då sannolikhet blir högre att den latenskritiska processen man som användare interagerar med råkar hamna på en CPU-kärna som har ett högt P-state (låg frekvens), frekvensskalningen låg då på millisekundskala (med speedshift är den på tiotals mikrosekunder).

Har aldrig hävdat att det inte finns några fall där många kärnor är väldigt användbart, att man kört SMP sedan 60-talet visar att så inte är fallet. Däremot tenderar det man gör på en typisk skrivbordsdator vara långt mer latenskritisk än beräkningskapacitetkritiskt, latens skalar i de flesta fall knappt alls med CPU-kärnor medan det (precis som allt som är CPU-bundet) skalar perfekt med prestanda per kärna. Är ingen slump att bärbara idag står för ~70 % av PC-marknaden och att bärbara nästan uteslutande nöjer sig med två kärnor, idag kan man nå 4,0 GHz med 15 W TDP (men lär vara stopp där, så nu är enda möjligheten även här att börja öka antal kärnor alt. stoppa in mer kisel som löser en specifik uppgift vilket är riktningen mobiler allt mer tar).

Tack för svar, jag misstänkte lite att många överdrev flerkärniga CPU:ers prestandavinst i att köra många program i desktop samtidigt. Vilket är det jag kommer göra, men då kanske en 8 kärnig variant med 4-kanaligt snabbt minne och högre frekvenser snarare är vägen att gå för min användning (framför en 16 kärnig). Mina FEM simuleringar skalar väldigt bra med extra minne och två kärnor per minneskanal verkar vara där COMSOL fungerar som bäst , och det är det tyngsta programmet jag kör dagligen.

Enda anledningen att jag skulle vilja ha fler kärnor är om det skulle göra så att jag bättre kan använda datorn samtidigt som den simulerar, dvs om jag låser 8/16 kärnor till COMSOL. Men jag misstänker att det inte kommer bli någon större skillnad eftersom COMSOL ändå kommer äta all minnesbandbredd, och om jag låser COMSOL till kärnor i samma NUMA-zon så kommer COMSOL bara utnyttja halva minnesbandbredden och därför inte jobba långsammare (typ halva hastigheten), dock kanske gå att använda datorn samtidigt till annat..?

Permalänk
Avstängd
Skrivet av Flamso:

Det är inte direkt några bra jämförelser egentligen. Han borde ha jämfört 7700K med samma hastighet på minnet också och haft med 7600K. Intel har bra mycket högre frekvenser så det hade inte heller varit dumt att köra allt i samma klockfrekvens för att jämföra IPC, speciellt i spel i vanlig upplösning. I övrigt tappar Ryzen med åtta kärnor rätt mycket när det inte är spel som använder många trådar som GTA 5, som sig bör. Det är en bra bit tills dess att spel kan använda 8 kärnor effektivt.

Ryzen är dock en bra arkitektur och Threadripper är fantastiskt kostnadseffektiv för mängden kärnor. Otroligt användbart i lägen en behöver flertrådad prestanda till lägre priser än Intel. Jag ser glatt framemot konkurrensen för det behöver verkligen Intel och AMD behöver tjäna mer pengar!

nu gör du samma misstag som han säger att alla intel fanboys gör. You are missing the point and the plot.
Sen verkar du helt ha missat r7 vs 7700k videorna där de drar jämnt. Och testerna med 1600x vs 7600k. Såg du enns igenom något ?

Skickades från m.sweclockers.com

Visa signatur

New: Asus x370 prime pro, Ryzen 1700 (@3.925ghz) , Ripjaws V 16GB 3600 MHz (@3200mhz 14c). https://valid.x86.fr/curj7r
Radeon VII.

Permalänk
Medlem
Skrivet av inquam:

Njae... Jag kan koda och dra nytta av många kärnor, men jag skulle knappast kunna ta fram en CPU med många kärnor. Så så mycket enklare vet jag inte om det är. Dock stämmer det att man måste koda med parallelism i tanken för att dra nytta av kärnorna. Detta är dock inte något som är direkt jättesvårt. Att utnyttja alla kärnor till 100% är dock väldigt svårt att få till, men att utnyttja parallelism bättre än vi gör idag är inte jättesvårt.

Det vi till stor del dras med när det gäller spel är att många började utveckla innan en massa trådar var en grej, utbildningar har lärat ut att koda spel väldigt sekventiellt, det för många känns skrämmande att tänka trådar så de låter bli och att processorer varit tillräckligt snabba för att "dölja" att vi inte utnyttjar deras prestanda fullt ut.

Då många idag bygger sina spel på existserande teknologier som Unity, Unreal Engine etc så är de fast i arvet av hur dessa motorer är byggda. Därav kommer skiftet inte direkt. Men det har helt klart påbörjats och kommer nog få ett helt annat fokus än vad det traditionellt har haft. Istället för att ha någon "tråd expert" (vilket jag sett bolag som haft) så kommer det vara en naturlig del av fler utvecklares verktygslåda.

Då böjer jag mig för din expertis, inquam, och inväntar med spänning spel som kan dra nytta av 16 fysiska kärnor och 32 trådar

Visa signatur

AMD Thunderbird 1.33 GHz (133 MHz Bus), Epox 8K7A, 1 x 256MB Corsair PC2100 DDR SDRAM, 20.5GB 7200 RPM Western Digital EIDE, Visiontek GeForce 3

Permalänk
Medlem
Skrivet av StenmanJones:

Det var ju inte så farligt, för att vara Intel vill säga. Kanske de känner flåset i nacken.

Visa signatur

Ryzen 5600X | Asus B550-F Gaming | 32GB G.Skill Trident Z 3600mhz | Powercolor 6800 XT | Seasonic Prime TX 850W

Athlon 64, du har alltid en plats i mitt hjärta. <3

Permalänk
Discokungen
Skrivet av _Merc_:

nu gör du samma misstag som han säger att alla intel fanboys gör. You are missing the point and the plot.
Sen verkar du helt ha missat r7 vs 7700k videorna där de drar jämnt. Och testerna med 1600x vs 7600k. Såg du enns igenom något ?

Skickades från m.sweclockers.com

Måste missat 1600X vs. 7600K då! Jag har lite svårt att se fördelarna med Youtube när det kommer till prestandatester för det är långt ifrån överskådligt.

Men till saken, vad är poängen då? Ryzen 1700 kostar 3400kr och 7700K kostar 3550kr som billigast. Det är inte stor skillnad. Jag föredrar AMD i alla lägen men sitter på Intel och Nvidia på grund av prestanda för processorn och G-sync till grafikkortet. AMD har stor möjlighet att vinna mot Intel i pris/prestanda men för tillfället ligger de inte så jättebra till. Bra mycket bättre än med Bulldozer men fortfarande.

Visa signatur

AMD 5800X3D - G.Skill Trident Z 3200 CL16 32GB - Asus B550 TUF - ASRock 7900 XTX Phantom - Intel 900p - CaseLabs S8 - LG 42C2 - Corsair AX1200i - Aquaero 6 - Vattenkyld

Permalänk
Hedersmedlem

@Viochee *tråd rensad*

http://www.sweclockers.com/forum/regler

Citat:

§1.6 Meningslösa inlägg som inte för diskussionen framåt är förbjudna. Detta omfattar inlägg som utan vidare motivering uttrycker medhåll eller missnöje. Andra exempel är länkar utan beskrivning eller sammanhang samt inlägg som enbart innehåller citat. Memebilder och andra roliga bilder för nästan aldrig diskussionen framåt.

/Giplet, Moderator

Visa signatur

Använd gilla för att markera nyttiga inlägg!

Permalänk
Medlem
Skrivet av SweMerlin:

Då böjer jag mig för din expertis, inquam, och inväntar med spänning spel som kan dra nytta av 16 fysiska kärnor och 32 trådar

Som sagt "Att utnyttja alla kärnor till 100% är dock väldigt svårt att få till, men att utnyttja parallelism bättre än vi gör idag är inte jättesvårt.". Någon hundraprocentig skalning kommer vi inte att se, speciellt inte i spel (kanske om man radikalt tänker om och börjar köra raytracing istället för rasterering för grafik (vilket inte lär vara på tapeten). Men processorer med åtta kärnor som vi idag kanske ser nyttjade till 20% kommer med stor sannolikhet se bättre nyttjande i framtiden.

Visa signatur

Huvudriggen är en Gigabyte Aorus Xtreme | 128gb DDR5 6000 | Ryzen 7950X | 3080Ti
Utöver det är det för många datorer, boxar och servar för att lista :P

Permalänk
Medlem

@Yoshman: Som vanligt uppskattas dina djupgående artiklar inlägg
Här är ett kort klipp (från 51m08s) som visar TR 16c/32t med 4st Vega FE renderar i blender med AMDs fria opensource CPU+GPU render-plugin vilket är baserad på OpenCL, en sådan yet another "fysiskt korrekt" renderare
Denna video är en liten hint om att det kommer vara rimligt att ha spelmotorer baserad på raytrace algoritmer (raytrace är mitt samlingsnamn för PT, bi-directional PT, MLT, Montecarlo m.fl.)
Ville bara ha något konkret att visa

Btw samtliga TR modeller kommer ha 64 PCIe enligt denna video från Computex igår, inte 44 som tidigare nämnt i swec, vilket låter rimligt då både Epyc och TR är Naples, detta är välkommet för multigpu