Intel Coffee Lake prislistas i Europa

Permalänk
Medlem
Skrivet av Masyve:

Förhoppningen är väl att en standardiseirng av fler kärnor på marknaden kanske driver programmerare av spelmotorer att våga distribuera kraft över fler trådar om de finns tillgängliga så att spelutvecklare får lite mer pulver att leka med som utgångsläge, och på så vis kanske på sikt sätta om standarden lite eller åtminstone öppna upp för de av oss som vill pröjsa för mer kraft.

Njae, ursäkta att jag upprepar mig gällande följande inlägg men så blir det när man svarar. Dilemmat är inte att jobba med flera trådar samtidigt - dilemmat är att i spel så måste resultatet av detta sammanfogas igen och presenteras. Detta dilemma tar CPU-kraft även det och då försvinner vinsten av flertrådat, till stor del. Flertrådat är egentligen bara vettigt i applikationer där kärnorna kan arbeta med uppgifter som är helt skilda från varandra och inte behöver sammanfogas.

Så argumentet att om bara folk har fler kärnor så gör spelutvecklarna fler trådar klingar väldigt tomt, och en aning desperat. Det är nämligen inte "bara att lösa".

Och fram tills dess, där "dess" är långt in i framtiden, är en bra spel-CPU en med ett relativt få antal kärnor - men med hög frekvens/IPC

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
Inaktiv
Skrivet av _hellstrom_:

Haha, undrade också hur det gått till, men den volten var "rätt" fet Vad har du för kylning?

Noctua D15 och 2st arctic F12 pwm

Skrivet av marcusOCZ:

Nånting som skurrar där. 1.6 volts och på 4.3 ghz får max 70 grader. Vill påstå att det inte är möjligt utan torris, kväve eller riktigt kall ambient.

För mig funkar det ju uppenbart utan torris mm.

Permalänk
Skrivet av anon200632:

Noctua D15 och 2st arctic F12 pwm

Ok, intressant Har en 3930k @ 4,5 ghz, sugen att skaffa en 1600x eller 1700. Skulle behöva en rejäl överklock för att uppgraderingen ska kännas betydelsefull.

Permalänk
Medlem

@anon200632: Kan du köra en validering av din cpu-z?

Visa signatur

14900KF--Apex Encore--RTX 4090--G.Skill 2x24GB DDR5-8000--Dynamic Evo XL
12900K--RTX 2080Ti--Gigabyte Z690 Aorus Master--4X16GB DDR5 6000
Ljud: Lewitt Connect 6--Shure SM7B
Skärmar: Neo G8 4K 240hz--Huawei 3440x1440 165hz

Permalänk
Medlem

Spiken i kistan för gaming på Ryzen

Visa signatur

[CPU: Intel i5-750 @ 2,6 ghz][MB: Gigabyte P55A-UD3][GFX: Phantom Geforce 670 GTX OC][RAM: Corsair XMS3 1600MHz 8GB][Chassi: Fractal Design r3] [HDD: 1TB Samsung Spinpoint F3][SSD: Crucial MX100 2.5" 7mm 256GB @ SATA 2][PSU: Corsair TX650W][CPU Kylning: Akasa Venom][OS: W7 64-bit][Skärm: BENQ 2412]

Permalänk
Inaktiv
Skrivet av marcusOCZ:

@Decimal: Kan du köra en validering av din cpu-z?

Är på jobbet nu men det kan jag göra när tid fås.

Permalänk
Medlem
Skrivet av bsk!:

Spiken i kistan för gaming på Ryzen

Hurså? Ett Ryzen-system för gaming kommer fortfarande vara betydligt billigare än ett Coffee Lake-system för gaming.
Inte lika bra så klart, men betydligt billigare.

Visa signatur

CPU: i9-13900K + Cooler Master ML360L ARGB V2 || GPU: Gainward RTX 4090 Phantom GS.
MoBo: Asus Rog Strix Z790-F Gaming || RAM 32 GB Kingston Fury Beast CL40 DDR5 RGB 5600 MHz.
PSU: Corsair RMe 1000W 80+ Gold || Chassi: Phanteks Eclipse P500A D-RGB.
Lagring: Kingston Fury Renegade M.2 NVME 2TB + Samsung 860 QVO 1TB.
Skärmar: 27" 1440p 144 Hz IPS G-sync + 27" 1440p 155 Hz VA || OS: Win 11 Home.

Permalänk
Hedersmedlem
Skrivet av MinscS2:

Hurså? Ett Ryzen-system för gaming kommer fortfarande vara betydligt billigare än ett Coffee Lake-system för gaming.
Inte lika bra så klart, men betydligt billigare.

Svårt att säga att *alla* Coffee Lake kommer att vara dyrare än och bättre än *alla* Ryzen-system i spel riktigt än.

Men faktum är ju att, som ett exempel, om man jämför i7-8700K med Ryzen 5 1600 (båda är 6C/12T-delar) så kommer ju 1600:n vara betydligt billigare. Samtidigt är ju inte Ryzen-systemet dåligt i spel på något sätt, det är först när man vill ha riktigt höga framerates och high-end-grafikkort som typ 1080 Ti i 1080p som det börjar spela roll på riktigt.

Permalänk
Medlem
Skrivet av pv2b:

Men faktum är ju att, som ett exempel, om man jämför i7-8700K med Ryzen 5 1600 (båda är 6C/12T-delar) så kommer ju 1600:n vara betydligt billigare. Samtidigt är ju inte Ryzen-systemet dåligt i spel på något sätt, det är först när man vill ha riktigt höga framerates och high-end-grafikkort som typ 1080 Ti i 1080p som det börjar spela roll på riktigt.

Precis.

Visa signatur

CPU: i9-13900K + Cooler Master ML360L ARGB V2 || GPU: Gainward RTX 4090 Phantom GS.
MoBo: Asus Rog Strix Z790-F Gaming || RAM 32 GB Kingston Fury Beast CL40 DDR5 RGB 5600 MHz.
PSU: Corsair RMe 1000W 80+ Gold || Chassi: Phanteks Eclipse P500A D-RGB.
Lagring: Kingston Fury Renegade M.2 NVME 2TB + Samsung 860 QVO 1TB.
Skärmar: 27" 1440p 144 Hz IPS G-sync + 27" 1440p 155 Hz VA || OS: Win 11 Home.

Permalänk
Medlem
Skrivet av anon200632:

Jag va bara ironisk

Såg tester från Cinebench och jag får högre score i multitrådat @ Stock som 8700K så det blir inget byte.

http://www.guru3d.com/news-story/intel-core-i7-8700k-benchmar...

Tycker det ser ut som att 8700K inte är optimerad än. Jag får ca 1350 multitrådat i Cinebench med min 5820K i 4343Mhz. Det är ungefär samma frekvens 8700K kör på alla kärnor, och 8700K bör rimligen vara klart snabbare per kärna än en gammal Haswell-E.

Permalänk
Snusfri

En i3-8100 skulle sitta som fisken i vattnet i en liten webserver, kan nog bli en sådan nästa månad för det.

Visa signatur

WS: i9 13900K - 128GB RAM - 6.5TB SSD - RTX 3090 24GB - LG C2 42" - W11 Pro
LAPTOP 1: Lenovo Gaming 3 - 8GB RAM - 512GB SSD - GTX 1650
LAPTOP 2: Acer Swift 3 - 8GB RAM - 512GB SSD
SERVER: i5 10400F - 64GB RAM - 44TB HDD
NALLE: Pixel 7 Pro

Permalänk
Medlem
Skrivet av DasIch:

Jag får ca 1350 multitrådat i Cinebench med min 5820K i 4343Mhz.

1% högre clock och 11% högre score? Är det ett jävligt generöst "cirka" eller har du roligare minnen?

Visa signatur

Bara fanboys kallar folk för fanboy!

Permalänk
Medlem
Skrivet av Implor:

Om man ska tro läckor så är endå multicore bara runt 1600/1600x nivå. Men singel ska vara runt 7700k. Få se vad Ryzen refresh erbjuder i ökade frekvenser.

För mig har det bästa av två världar äntligen slagit samman, singeltråds prestanda i kombination av många kärnor för flertrådade program.

För en seriös gamer och produktioner av videos.

Visa signatur

MSI X99A GODLIKE GAMING | i7-6950X 4.3GHz | 64GB RAM 3200MHz | RTX 2080

Nintendo Switch | PlayStation 5 | Xbox Series X

Min FZ Profil

Permalänk
Medlem

Vilken socket kommer dessa köra? Tycker mig inte se det.

Skickades från m.sweclockers.com

Permalänk
Medlem

@qmiW: s1151, chip z370/z390 (q1 2018 förmodligen)
Så tyvärr moderkortsbyte också om man vill byta.

Visa signatur

Skärm: Acer XB271 HU, Keyboard: Corsair k95
Moderkort: Asus Prime-A Z690, GPU: RTX 4080
CPU: Intel i7 13700k, Ram: 32Gb DDR5 6000Hz
Chassi: Lian Li Lancool 3, Högtalare: ALTEC LANSING 5.1 THX
Disk 1: WD 850x 1Tb, Disk 2: WD 850x 2Tb,PSU: Seasonic Prime 1000w

Permalänk
Medlem
Skrivet av Masyve:

https://i.gyazo.com/fad375f9b7d1449ba85548b5caea413a.png

1% högre clock och 11% högre score? Är det ett jävligt generöst "cirka" eller har du roligare minnen?

De tidigare turerna med poäng runt 1240 var med en cache multipel på 24. 1349 poäng är med en multipel på 43, precis som för kärnorna. Per default matchar cache/uncore kärnornas frekvens så det är inga konstigheter där.

Kanske kan tilläggas att detta är i Windows. MacOS brukar ge 100-150 poäng högre.

Minnena kör i 2424Mhz, 4 kanaler. Jag måste laborera med stödspänningar om jag ens ska få upp dem 2666Mhz, som de är gjorda för. Det är sopiga Corsair LPX så absolut inget roligt där (förutom kanske XMP-profiler som minnena inte klarar av, det är ju på sätt och vis roligt när man frågar sig hur Corsair tänkt).

Permalänk
Medlem

HAHAHA

Samma dag som intel presenter priset för 8700k så pris droppar man 1800x till 3999kr

Kan inte anklaga AMD för att vara slö på bollen!

Visa signatur

| CPU: Intel i7 7700k | RAM: Crucial DDR4 OC @2400mhz 16GB (2x8GB) | GPU: EVGA GeForce RTX 2080 XC GAMING| Mobo: MSI H110I Pro | SSD: Crucial BX200 240GB 2.5" SSD | SSD2: Samsung 850 EVO 500GB 2.5" SSD | Nätagg: be quiet! SFX L Power 600W | Kylare: NZXT Kraken X62 | Chassi: Fractal Design Nano S | OS: Windows 10 Pro

Permalänk
Medlem
Skrivet av SweMerlin:

Njae, ursäkta att jag upprepar mig gällande följande inlägg men så blir det när man svarar. Dilemmat är inte att jobba med flera trådar samtidigt - dilemmat är att i spel så måste resultatet av detta sammanfogas igen och presenteras. Detta dilemma tar CPU-kraft även det och då försvinner vinsten av flertrådat, till stor del. Flertrådat är egentligen bara vettigt i applikationer där kärnorna kan arbeta med uppgifter som är helt skilda från varandra och inte behöver sammanfogas.

Så argumentet att om bara folk har fler kärnor så gör spelutvecklarna fler trådar klingar väldigt tomt, och en aning desperat. Det är nämligen inte "bara att lösa".

Och fram tills dess, där "dess" är långt in i framtiden, är en bra spel-CPU en med ett relativt få antal kärnor - men med hög frekvens/IPC

Jag håller inte med dig helt, och du har fel om minst en sak och gör vissa förenklingar (såsom att alla jobb som görs tar kortare tid än synkroniseringen) som inte direkt behövs.

Skrivet av SweMerlin:

Flertrådat är egentligen bara vettigt i applikationer där kärnorna kan arbeta med uppgifter som är helt skilda från varandra och inte behöver sammanfogas.

Fel... Tänk dig att du har 6 kärnor.
Säg att du har 4 skilda jobb som tar: 1ms , 1ms, 1 ms , 16ms (säg t.ex att det här är en lång lista med NPC:s som ska fatta komplexa beslut)

Vi prövar med din metod. Varje jobb får en processor var och vi slutar efter 16ms.
Nu prövar vi att lägga 1 processor var på de första tre jobben och 3 processorer på det fjärde jobbet där vi låter de olika processorerna dela på den stora listan med saker att göra och då får vi att varje processor spenderar 16/3=5,3ms. Sedan så har vi synkroniseringen också... och här har vi rum för att synkronisera i hela 10,7 ms.....vilket den för övrigt skulle hinna synka 7-20 gånger redan. Även med en medelmåttig tid på 2ms skulle vara dubbelt så bra som ditt förslag.

Självklart betyder inte det att du kan köra 120538763489263852 kärnor och förvänta en förbättring, men de allra flesta fall hamnar ju som högst vid 8 trådar så vi har en del kvar när man kommer till en punkt då synkroniseringen blir dominerande.

Skrivet av SweMerlin:

Så argumentet att om bara folk har fler kärnor så gör spelutvecklarna fler trådar klingar väldigt tomt, och en aning desperat. Det är nämligen inte "bara att lösa".

Och fram tills dess, där "dess" är långt in i framtiden, är en bra spel-CPU en med ett relativt få antal kärnor - men med hög frekvens/IPC

Sedan hur framtiden ser ut kan man enbart spekulera i, men en del saker talar för flerkärniga processorer med aningen sämre singletrådprestanda än en processor med färre trådar. Jag kommer dra huvudpunkterna med en kort förklaring:

  • Utvecklarna har aldrig behövt utveckla för över 8 trådar, för den marknaden har varit så låg. Nu när ryzens 12&16 trådiga CPU:er har sålts i flertalet så kan det vara värt för utvecklarna att tänka på det (lägg även till 8700k och 8700 nu).

  • Nya GPU-API:er får fäste. Dx11, OpenGL och så är begränsade till hur många trådar får hjälpa till med att samla ihop drawcalls. DX12 och Vulkan har mycket högre antal som kan hjälpa till. Utvecklaren måste förstås göra rätt för att det ska bli en skillnad. En förklaring för drawcalls finns här (fram till 6:20) och här ser man skillnaden i ett väloptimerat fall. De flesta fall är INTE så just nu.

  • Kort sagt, en processor som redan utnyttjar sina trådar fullt ut idag kan aldrig bli bättre i framtiden.

Då talar jag mest om de stora utvecklarna som har råd att lägga ner tiden och pengarna på det här. AMD och Intel går nog även in själv och vill optimera för de riktigt stora spelen.

Att då säga att "allting är så långt bort att man inte bör bry sig om man köper en CPU med 4 kärnor med hög IPC och klockfrekvens" känns minst lika naïvt som att säga att "optimeringar kommer att hända inom en snar framtid". Sedan kommer det alltid finnas spel från småutvecklare som är ooptimerade för fler trådar, å andra sidan handlar det oftast då om inte alltför krävande spel.

Permalänk
Inaktiv
Skrivet av marcusOCZ:

@Decimal: Kan du köra en validering av din cpu-z?

@marcusOCZ
Hej, nu är jag hemkommen från jobbet och fixade en validering på cpu-z.
https://valid.x86.fr/g5aaif

Mitt gtx 1080 kom idag så blir att installera det under dagen ochså.

Edit, såg nu att jag hade volten kvar på värdet när jag körde den i 4.4GHz, därav den va lite hög.
Har den annars på 1.55V

Permalänk
Datavetare
Skrivet av Radolov:

Jag håller inte med dig helt, och du har fel om minst en sak och gör vissa förenklingar (såsom att alla jobb som görs tar kortare tid än synkroniseringen) som inte direkt behövs.

Fel... Tänk dig att du har 6 kärnor.
Säg att du har 4 skilda jobb som tar: 1ms , 1ms, 1 ms , 16ms (säg t.ex att det här är en lång lista med NPC:s som ska fatta komplexa beslut)

Vi prövar med din metod. Varje jobb får en processor var och vi slutar efter 16ms.
Nu prövar vi att lägga 1 processor var på de första tre jobben och 3 processorer på det fjärde jobbet där vi låter de olika processorerna dela på den stora listan med saker att göra och då får vi att varje processor spenderar 16/3=5,3ms. Sedan så har vi synkroniseringen också... och här har vi rum för att synkronisera i hela 10,7 ms.....vilket den för övrigt skulle hinna synka 7-20 gånger redan. Även med en medelmåttig tid på 2ms skulle vara dubbelt så bra som ditt förslag.

Självklart betyder inte det att du kan köra 120538763489263852 kärnor och förvänta en förbättring, men de allra flesta fall hamnar ju som högst vid 8 trådar så vi har en del kvar när man kommer till en punkt då synkroniseringen blir dominerande.

Sedan hur framtiden ser ut kan man enbart spekulera i, men en del saker talar för flerkärniga processorer med aningen sämre singletrådprestanda än en processor med färre trådar. Jag kommer dra huvudpunkterna med en kort förklaring:

  • Utvecklarna har aldrig behövt utveckla för över 8 trådar, för den marknaden har varit så låg. Nu när ryzens 12&16 trådiga CPU:er har sålts i flertalet så kan det vara värt för utvecklarna att tänka på det (lägg även till 8700k och 8700 nu).

  • Nya GPU-API:er får fäste. Dx11, OpenGL och så är begränsade till hur många trådar får hjälpa till med att samla ihop drawcalls. DX12 och Vulkan har mycket högre antal som kan hjälpa till. Utvecklaren måste förstås göra rätt för att det ska bli en skillnad. En förklaring för drawcalls finns här (fram till 6:20) och här ser man skillnaden i ett väloptimerat fall. De flesta fall är INTE så just nu.

  • Kort sagt, en processor som redan utnyttjar sina trådar fullt ut idag kan aldrig bli bättre i framtiden.

Då talar jag mest om de stora utvecklarna som har råd att lägga ner tiden och pengarna på det här. AMD och Intel går nog även in själv och vill optimera för de riktigt stora spelen.

Att då säga att "allting är så långt bort att man inte bör bry sig om man köper en CPU med 4 kärnor med hög IPC och klockfrekvens" känns minst lika naïvt som att säga att "optimeringar kommer att hända inom en snar framtid". Sedan kommer det alltid finnas spel från småutvecklare som är ooptimerade för fler trådar, å andra sidan handlar det oftast då om inte alltför krävande spel.

Finns ett par tankevurpor i resonemanget ovan.

  • låter som du antar att synkroniseringskostnaden är konstant oavsett antal trådar som är involverad, det är inte sant utan tvärt om ökar den i praktiken med antal kärnor (ofta snabbare än linjärt). Amdalhls lag brukar beskrivas som en pessimistisk syn, grejen är att det är en övre gräns då den bl.a. förutsätter konstant synkroniseringskostnad

  • det normala i saker som spel är att jobb inte är totalt oberoende av allt annat, ett jobb kan inte starta innan det har all indata och indata kommer i vissa fall från andra jobb. Detta minskar teoretisk möjlig parallellism.

  • GPGPU är absolut helt rätt väg att gå, visst kan t.ex. rendering bli snabbare med flera kärnor men en GPU är betydligt mer lämpad för uppgiften. Man måste dock särskilja på olika typer av parallellism, s.k. uppgiftsbaserad parallellism fungerar väldigt illa på GPUer (och även på CPUers SIMD) så här har multicore CPUer sin framtid säkrad. Även om SIMD och GPUer är snarlika i att det båda är extremt effektiva på dataparallella problem finns problem där den ena är ett betydligt bättre val än den andra. Sådana saker är en kvarnsten för hela parallellprogrammeringsområdet, det är fundamentalt svårt att få rätt och därmed dyrt!

Det första går att belysa rätt väl med ett litet exempel. Finns ett koncept som kallas "span/work law", det kan användas för att beräkna den teoretisk maximala parallellismen man kan få ut ur en viss algoritm.

Applicerar man det på den enkla formen merge-sort (där "merge" steget är seriell, går att till viss del parallellisera även det) får man att parallellismen är proportionell mot log2(N) där N är antal element som ska sorteras.

Ett sätt att implementera det i C++ är detta

// -*- compile-command: "g++ -std=c++14 -fcilkplus main.cpp -O3 -march=native -o main" -*- #include <chrono> #include <cilk/cilk.h> #include <functional> #include <iomanip> #include <iostream> #include <list> #include <stdlib.h> #include <string> #include <vector> using namespace std; typedef unsigned long num_t; static inline list<int>::iterator middle(list<int> &lst) { auto l = lst.size(); if (l <= 1) { return begin(lst); } auto it = begin(lst); for (l /= 2; l > 0; l--) { it++; } return it; } void ssort(list<int> &lst) { auto mid = middle(lst); if (mid != begin(lst)) { list<int> front_lst; front_lst.splice(begin(front_lst), lst, mid, end(lst)); ssort(front_lst); ssort(lst); lst.merge(front_lst, [](int a, int b) -> bool { return a < b; }); } } void psort(list<int> &lst) { auto mid = middle(lst); if (begin (lst) != mid) { list<int> front_lst; front_lst.splice(begin(front_lst), lst, mid, end(lst)); cilk_spawn psort(front_lst); psort(lst); cilk_sync; lst.merge(front_lst, [](int a, int b) -> bool { return a < b; }); } } static float measure(function<void(void)> &&fn) { auto start = chrono::steady_clock::now(); fn(); auto end = chrono::steady_clock::now(); auto elapsedMs = chrono::duration_cast<chrono::microseconds>(end - start); return elapsedMs.count() / 1000.0 / 1000.0; } int main(int argc, char *argv[]) { vector<string> args(argv + 1, argv + argc); int n = stoi(args[0]); list<int> lst1; list<int> lst2; for (int i = 0; i < n; i++) { int r = rand() % 100; lst1.push_back(r); lst2.push_back(r); } cout << fixed << setprecision(2); auto s = measure([&](void) { ssort(lst1); }); cout << "Serial : " << s << 's' << endl; auto p = measure([&](void) { psort(lst2); }); cout << "Parallel : " << p << 's' << endl; cout << "Speedup : " << s / p << endl; }

Dold text

Har här använt Cilk+, det är så vitt jag vet det mest effektiva fork-join ramverk som existerar idag (OpenMP ligger numera på samma nivå). Både Cilk+ och OpenMP är idag integrerade i gcc.

Testat jag och sortera 40 miljoner poster finns en teoretisk parallellism på >20. Det skalar i praktiken i det närmaste perfekt när man går från en till två kärnor!

Fast slänger man inte 16 kärnor / 32 trådar på problem ser man detta med htop

Två saker man bör notera. Dels används verkligen alla trådar till 100 %, så finns absolut saker att göra för alla trådar.

Notera de stora röda sektionerna, det är tiden man spenderar i kärnan. Titta på koden, den borde aldrig befinna sig i kärna förutom i uppstarten när minne allokeras (och mäter inte den tiden). Vad vi ser här är att trådarna till väldigt stor del börjar kliva varandra på tårna i "fork" resp "join" stegen när de delar upp och sammanfogar delresultaten.

Faktum är att prestanda börjar droppa efter ungefär 3-4 kärnor / 6-8 trådar (fall som använder fork-join ser ofta rätt bra boost från SMT, så är även fallet här). Så trots att det bevisligen finns parallellism för att teoretisk nå >x20 speedup går i praktiken inte att nå mycket mer än ~x2,5 vilket redan nås med 3-4 kärnor.

För att gå tillbaka till spel. Ju större och mer komplicerade världar som skapas, ju mer möjlighet finns till att utnyttja flera kärnor. Det är precis vad Gustafsons lag säger.

Men spel innehåller den typ av problem som kräver kommunikation mellan kärnor. Då kostnad för synkronisering inte är konstant utan ökar med antalet kärnor så överskattar Gustafsons lag (det är i grunden samma lag som Ahmdals fast man varierar en annan parameter) hur mycket skalbarheten ökar med storleken på problemet.

D.v.s. det blir exponentiellt svårare att utnyttja fler kärnor, inte linjär. Så det kommer gå allt långsammare, alternativet är att man helt ändrar hur spelmotorer fungerar och börjar använda helt andra typer av algoritmer och abstraktioner.

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

@anon200632: Vild cpu och vild volt, but i like it! Du har verkligen vunnit cpulotteriet.

Visa signatur

14900KF--Apex Encore--RTX 4090--G.Skill 2x24GB DDR5-8000--Dynamic Evo XL
12900K--RTX 2080Ti--Gigabyte Z690 Aorus Master--4X16GB DDR5 6000
Ljud: Lewitt Connect 6--Shure SM7B
Skärmar: Neo G8 4K 240hz--Huawei 3440x1440 165hz

Permalänk
Medlem

@Yoshman: Jag håller med dig, men jag antog aldrig att synkroniseringskostnaden var konstant (gav värdet 1,5ms~ 2ms för 1700X med openMP för att synkronisera alla 16 trådar och då CCX strukturen ej är så optimal för synkroniseringar antogs det vara ett någorlunda högt värde, men inte i närheten av 16 kärniga processorer.)

2,5x stämmer väl överens med de siffrorna som jag sett för 8-24 trådar. Det var dock på ett jobb som tog 1ms på en tråd (alltså visar det att även små jobb kan förbättras, trots synkroniseringstiden) och det var lite den poängen jag ville förmedla (ja, Amdahls lag är en approximation som inte tar hänsyn till alla variabler, men funkar rent pedagogiskt.)

Självklart finns det jobb som beror på andra, å andra sidan syftade inte jag på dessa när jag talade om saker som kan parallelliseras. Jag syftade mest på uppgiftsbaserad parallellism som inte går att genomföra med SIMD som du talar om.

Jag gillar ditt exempel med mergesort som illustrerar kostnaden för synkronisering. Det går inte att lägga på hur många kärnor som helst och förvänta sig att det går snabbare utan 3-4 kärnor max per jobb verkar vara gränsen nu (sedan går det förstås att lägga till fler, men det är exponentiellt avtagande till den punkt då kostnaden för join är för hög och tidsåtgången kommer åter att stiga igen).

Skrivet av Yoshman:

För att gå tillbaka till spel. Ju större och mer komplicerade världar som skapas, ju mer möjlighet finns till att utnyttja flera kärnor. Det är precis vad Gustafsons lag säger.

Ja, större jobb bör generellt leda till lägre andel synkroniseringstid, vilket klingar bra med möjligheter för större (eller mer detaljrika) världar som utvecklarna kan känna sig mer motiverade till att skapa nu när antalet kärnor ökar för den genomsnittliga spelaren.

Jag står fast dock vid att parallellism går att använda i vissa delar av spel mer än den mån det generellt används idag. Det är dock inte trivialt att lösa förstås, men jag tror att utvecklarna bör känna sig uppmanade till att hitta lösningar på dessa problem nu.

Permalänk
Medlem

är nästan sugen på den enklaste i3'an bara för att maxa fps i quake champions

Visa signatur

i5 10400f | asus b460-f | 2x8gb kingston 2666 | zotac 3060ti | corsair mp510 960gb (OS) + samsung 860 evo 1tb + 2x kingston a400 480gb | corsair vx450 | tr true black | fractal r3 | asus mg279q + lg w2363d | dt 880 | win 10 x64 | deathadder chroma | glorious 3xl | tb impact 600 | oculus quest 2

Permalänk

Någon som vet om det kommer nya moderkort i och med dessa eller funkar det med ens nuvarande 1151?

Visa signatur

Laptop och Philips Fidelio X2HR :)