Intels kapacitetsproblem på 14 nanometer fortsätter – kan döpa om Z370 till Z390

Trädvy Permalänk
Datavetare
Plats
Stockholm
Registrerad
Jun 2011
Skrivet av houze:

Gäller väl bara om applikations minnesarea understiger NUMA-zonens minneskapacitet? Men borde vara ovanligt med enkeltrådade applikationer som tar mer än hälften av systemets RAM så det är nog ett icke-problem i allafall.

Om det vore normalfallet vore kommande 32C Threadripper meningslös. Moderna "big-core" CPUer är väldigt duktiga på att "gömma" latens förutsatt att programkoden innehåller väldigt lite minnessynkroniserade instruktioner. Enkeltrådade program har ju ingen annan tråd de behöver synkronisera med => fungerar normalt sett väldigt bra att köra dessa även om de refererar RAM på "fel" NUMA-zon.

Det havererar när man har program där olika CPU-trådar behöver synkronisera access till gemensam data, i det läget är det i praktiken omöjligt för CPUn att spekulera => latens blir superkritiskt (är exakt så man "fixar" Spectre, stoppar in en synkroniserande x86 instruktion då den förbjuder CPUn att spekulera).

Skrivet av houze:

Överbeläggningen på 14nm produktionen är ju bra för de Intel-fabrikerna, de borde vara rätt lönsamma när de går konstant på 100%, men man undrar ju lite smått hur mycket kapacitet deras 22nm-frabriker går på, hade kanske varit bra idé att designa även z390 för den processnoden.

Med facit i hand är det absolut så. Rent generellt tror jag Intel insett att deras nuvarande strategi där man endast planerar en mikroarkitektur-uppdatering per nod håller inte, man har ingen plan B på vare CPU eller kringkrets-sidan som täcker fallet att 10 nm inte börjar rulla på inom en väldigt snar framtid.

Gissar att även en relativt enkel krets som Z390 skulle ta minst ett år att designa om till en annan process, d.v.s. inget man rimligen gör i detta läge.

Om vi antar att Ice Lake hittar ut Q3 2019 så har Intel inte haft några nyheter sett till mikroarkitektur under 4 års tid (i7-6700K lanserades Q3 2015) på konsumentsidan, det är något man måste ha en väsentligt bättre plan för framöver. (Jag förutsätter nästan att Cannon Lake kommer bli mer eller mindre skrotad, det verkar mest vara Skylake på 10 nm med uppdaterad iGPU).

Skrivet av houze:

Lite samma sak med ARM, prestandan förut har ju begränsat användning av ARM-baserade servrar till vissa nischer, är väl först nu med Cavium Thunder X2 som det börjar bli lite intressant, men det saknar rätt mycket mjukvaru-stöd i form av optimeringar för arkitekturen vilket får prestandan att ligga efter på vissa saker, misstänker att det fortfarande är 2-3 år bort innan mjukvaran börjar närma sig och givetvis så behöver de större tillverkarna leverera systemlösningar med ARM i vilket också känns som det är ett tag bort. Molnleverantörer är nog de som har bäst resurser idag att kunna basera system på det.

Saknas absolut optimering inom vissa nischer, 64-bitars ARM är inte ens 10 år gammalt än (lanserades 2010).

Dock saknas mindre än vad många kanske skulle gissa, säljs trots allt ungefär 5x så många 64-bitars ARM CPUer enbart till mobiler jämfört med totala mängden x86 CPUer. Totalt säljs det väl över 10x så mycket ARM som x86, en väldigt stor andel av dessa ARM-system kör Linux med ett stort överlapp av grundläggande programvara/bibliotek med vad en server använder.

Blivit rejält positivt överraskad över mognadsgraden under det år jag nu jobbat med 64-bitars ARM (i form av utveckling av C/C++ standardbibliotek ihop med LLVM/clang).

Skrivet av CyberVillain:

@Yoshman: Rätt hårdvara till rätt problem, jag hade inte tackat nej till nya TR med 32 cores för att baka ljus i Unity. Ska jag köra en databas, not so much

Exakt! Och har flera gånger understrukit att TR är absolut en vettig produkt. Men TR är bara bra till vissa nischer, så man måste vara väldigt medveten om hur de fall man själv är intresserade av är befattade för att kunna avgöra om TR är rätt produkt eller ej.

Att "baka" ljus är exempel på något som är "embarrassingly parallel" och det passar därför TR väldigt väl.

Många, dock långt ifrån alla, "embarrassingly parallel" problem fungerar lysande att accelerera med GPGPU. Att baka ljus är en sådan. Så för Unity är TR ett vettig val då det tyvärr saknas GPGPU stöd för detta, i t.ex. UE4 vore det helt meningslöst då en GPU krossar en CPU på denna uppgift (FP32 kapacitet i TR-1950X ligger i nivå med GPUer som Intel Iris Plus Graphics 650 och Nvidia GT 1030).

Men finns kanske hopp för Unity. Dels finns en del försökt med CUDA-backends för att baka ljus. AMD presterande också rätt nyligen "Radeon Rays" stöd i Unity, här är vad de bl.a. säger om prestanda

"10 – 20x performance improvement
Before 1 day baking => 1 hour with Radeon Rays"

Så rätt absolut viktigt att välja rätt maskinvara och än mer att välja rätt teknik för varje uppgift.

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

Trädvy Permalänk
Avstängd
Plats
Stockholm
Registrerad
Dec 2003
Skrivet av Yoshman:

Men finns kanske hopp för Unity. Dels finns en del försökt med CUDA-backends för att baka ljus. AMD presterande också rätt nyligen "Radeon Rays" stöd i Unity, här är vad de bl.a. säger om prestanda

"10 – 20x performance improvement
Before 1 day baking => 1 hour with Radeon Rays"

Så rätt absolut viktigt att välja rätt maskinvara och än mer att välja rätt teknik för varje uppgift.

Du är inte van vid Unity hör jag De började prata om Nested prefabs 2012, de kommer först Q3-Q4 2018 (Om de inte blir försenade förstås). Behöver du baka idag eller tom under 2018 är det CPU som gäller Unity är hopplöst sega på få ut sina features

När vi pratar Unity så är det ju även bra med multi core för slutkonsumeten, Unity 2018 har bra ECS-stöd, vilket i sig är super för single core prestanda, CPU är bra att hantera stora datamängder
som ligger tight packat i minnet (cache coherence), något klassisk OOP inte är vidare bra på, men ECS löser då data och logik separeras. Blandar man multi core i den mixen blir det ännu mer intressant. Lika så jobbar Unity hårt med multi core prestanda med uppkommande Vulkan och deras Gfx jobs.

Dock antar jag att minneslatency för TR blir ett problem även här, dock, så länge du kan sprida ut jobbet över flera cores och sedan sy ihop säcken inom 11ms (90 fps minimum framerate at all times i VR) gränsen så är du hemma.

Trädvy Permalänk
Datavetare
Plats
Stockholm
Registrerad
Jun 2011
Skrivet av CyberVillain:

Du är inte van vid Unity hör jag De började prata om Nested prefabs 2012, de kommer först Q3-Q4 2018 (Om de inte blir försenade förstås). Behöver du baka idag eller tom under 2018 är det CPU som gäller Unity är hopplöst sega på få ut sina features

När vi pratar Unity så är det ju även bra med multi core för slutkonsumeten, Unity 2018 har bra ECS-stöd, vilket i sig är super för single core prestanda, CPU är bra att hantera stora datamängder
som ligger tight packat i minnet (cache coherence), något klassisk OOP inte är vidare bra på, men ECS löser då data och logik separeras. Blandar man multi core i den mixen blir det ännu mer intressant. Lika så jobbar Unity hårt med multi core prestanda med uppkommande Vulkan och deras Gfx jobs.

Dock antar jag att minneslatency för TR blir ett problem även här, dock, så länge du kan sprida ut jobbet över flera cores och sedan sy ihop säcken inom 11ms (90 fps minimum framerate at all times i VR) gränsen så är du hemma.

Självklart måste man vara pragmatisk och använda det som finns idag, vilket för standard Unity är CPU-baserad ljushantering.

Det jag mest ville belysa(!) var att fall som skalar väldigt bra med CPU-kärnor många gånger är de som passar GPGPU perfekt.

Kommer i princip ned till om det är uppgiftsparallella problem, då fungerar GPGPU/SIMD uselt medan många CPU-kärnor är hand-i-handsken match. Här hittar vi de flesta fall man har på servers. Är det i stället dataparallellt är normalt GPGPU/SIMD överlägset flera kärnor, GPGPU passar bäst om FP32 eller minnesbandbredd är flaskhals medan SIMD passar bäst om FP64 eller minneslatens är flaskhals.

Går man utanför öppen källkod och kan leva med Nvidia-only lösning (CUDA), finns ju kommersiella lösningar som ger GPGPU acceleration i Unity redan idag, bl.a. Octane Render.

Men är helt med på vad du menar med att de är långsam, sett vad folk anser om utvecklingshastigheten i Unity på deras forum...

Och angående OOP, det är inte nödvändigtvis dåligt för cache-lokalitet. Sättet språk som C# och Java hanterar objekt gör det väldigt dåligt (man får normalt allt en extra indirection p.g.a. att objekt allokeras på heap:en och refereras via pekare), men det är inte alls sant i C++ där man kan hantera objekt "by-value".

Däremot är OOP totalt trasigt i alla former av parallella program, ett stenhårt krav i effektiv parallellprogrammering är att man har direkt synlighet in data för korrekt och optimal synkroniseringen. En av hörnpelarna i OOP är ju "data hiding"... Man kan aldrig gömma saker som synkroniseringsprimitiver, i all fall om man inte tycker det är kul med dead-locks/data-race och avser jobba med fler än ett objekt i stöten.

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

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Apr 2012

Jag kanske är för trött för att läsa alla kommentarer, men det anses alltså dåligt att vi får nya processorer som funkar till Z370? 😊

Trädvy Permalänk
Medlem
Plats
Jönköping
Registrerad
Aug 2011

Fördelen med ny teknik i sammanhanget är stöd för ny I/O, medan fördelen med ”gammal” teknik är att man slipper vara beta-testare för kretsar och firmware, som jag var när jag köpte den då helt nya Z170...

Det ska bli intressant att se var detta tar vägen. Rebrands är dock ett otyg. Intel kunde valt att kalla den uppdaterade kretsen vad som helst förutom den planerade uppföljarens namn, även om det på förhand var känt att skillnaderna mellan Z370 och Z390 skulle komma att bli minimala.

Det här sänder bara dåliga signaler till presumtiva kunder, helt i onödan.

http://xkcd.com/386/
http://readthefuckingmanual.com/
http://en.wikipedia.org/wiki/Megahertz_myth

”Alltså vad är det med grafikkortsmakare och bokstaven X? Det är precis som med dansbandsmusiker och bokstaven Z.”

Trädvy Permalänk
Avstängd
Plats
Stockholm
Registrerad
Dec 2003
Skrivet av Yoshman:

Självklart måste man vara pragmatisk och använda det som finns idag, vilket för standard Unity är CPU-baserad ljushantering.

Det jag mest ville belysa(!) var att fall som skalar väldigt bra med CPU-kärnor många gånger är de som passar GPGPU perfekt.

Kommer i princip ned till om det är uppgiftsparallella problem, då fungerar GPGPU/SIMD uselt medan många CPU-kärnor är hand-i-handsken match. Här hittar vi de flesta fall man har på servers. Är det i stället dataparallellt är normalt GPGPU/SIMD överlägset flera kärnor, GPGPU passar bäst om FP32 eller minnesbandbredd är flaskhals medan SIMD passar bäst om FP64 eller minneslatens är flaskhals.

Går man utanför öppen källkod och kan leva med Nvidia-only lösning (CUDA), finns ju kommersiella lösningar som ger GPGPU acceleration i Unity redan idag, bl.a. Octane Render.

Men är helt med på vad du menar med att de är långsam, sett vad folk anser om utvecklingshastigheten i Unity på deras forum...

Och angående OOP, det är inte nödvändigtvis dåligt för cache-lokalitet. Sättet språk som C# och Java hanterar objekt gör det väldigt dåligt (man får normalt allt en extra indirection p.g.a. att objekt allokeras på heap:en och refereras via pekare), men det är inte alls sant i C++ där man kan hantera objekt "by-value".

Däremot är OOP totalt trasigt i alla former av parallella program, ett stenhårt krav i effektiv parallellprogrammering är att man har direkt synlighet in data för korrekt och optimal synkroniseringen. En av hörnpelarna i OOP är ju "data hiding"... Man kan aldrig gömma saker som synkroniseringsprimitiver, i all fall om man inte tycker det är kul med dead-locks/data-race och avser jobba med fler än ett objekt i stöten.

I c# har man istället delat upp det i klasser och struktar. Så en by value klass översätts till en strukt i C#. Att JIT kompilatorn kan göra target platform optimeringar är ju heller inte det fel då Unity är multi platform.

ECS är sanslöst snabbt pga att man får en tight cache coherence, att jobba över 50k entiteter per frame singeltrådat är inget problem. Kör man det multitrådat ja då skalar det ju därefter (Beroende på problem självfallet).

Vi jobbar just nu med en avancerad ballistics sim där varje kula i luften hanteras med luftmotstånd, materialpenetration osv i åtagande. Inget problem med flera hundra till tusen kulor i luften samtidigt tack vare ECS / Job systems och async raycasting (raycast skilt från rendertråden). Detta fungerar enbart för det gör inget om impakteffekten eller kulhålet dröjer en frame.

Vi har också lasersikten i spelet som fungerar genom att vi raycastar och sedan har en custom shader som löser lite edge case problem för en laserprick, men den får absolut inte lagga efter för det märker spelaren direkt.

Dock jobbar Unity på en async raycast som är garanterad att landa inom samma frame, ska bli intressant se hur det fungerar. Imponerande de kan sy ihop det inom en frame slot.

Trädvy Permalänk
Medlem
Plats
Öland
Registrerad
Dec 2013

@CyberVillain Vilka är "vi"? Det låter hursomhelst som häftiga simuleringar. Räknar ni även med förändringar i luften och hur det påverkar efterkommande kulor eller blir aldrig så mycket att det har effekt?

# = Brädgård
FD Nano S|Corsair SF450 V2|Asrock AB350 ITX|AMD 2400G|Ballistix Sport 2666Mhz CL 16|Samsung 860 EVO 250GB|Dell U2415|Logitech K400+

Trädvy Permalänk
Avstängd
Plats
Stockholm
Registrerad
Dec 2003
Skrivet av LaoLao:

@CyberVillain Vilka är "vi"? Det låter hursomhelst som häftiga simuleringar. Räknar ni även med förändringar i luften och hur det påverkar efterkommande kulor eller blir aldrig så mycket att det har effekt?

Vi i vår spelstudio
Nej vi använder oss enbart av den sk ballistiska koefficienten för att beräkna kulans tappande av energi i atmosfären. Sedan när kulan träffar solit material har vi lite olika beräkningar baserat på infallsvinkel, egenskaper på materialet den träffar, kulans egenskaper osv, en tyngre kula med högre energi kommer penetrera medans en lättare kulla kommer studsa av ytan, osv

Har tyvärr ingen cool film från vårt spel där jag demar detta, fortfarande mycket jobb kvar

Trädvy Permalänk
Medlem
Plats
Öland
Registrerad
Dec 2013

@CyberVillain Aha. Attans. Det hade varit häftigt att se annars.

# = Brädgård
FD Nano S|Corsair SF450 V2|Asrock AB350 ITX|AMD 2400G|Ballistix Sport 2666Mhz CL 16|Samsung 860 EVO 250GB|Dell U2415|Logitech K400+

Trädvy Permalänk
Avstängd
Plats
Stockholm
Registrerad
Dec 2003
Skrivet av LaoLao:

@CyberVillain Aha. Attans. Det hade varit häftigt att se annars.

Rent effektmässigt för användaren blir det inte så stor skillnad emot idag, ser ut såhär

https://youtu.be/tzNvG8t-mfc?t=541

Men det kommer bli sjukt nice när man står inne i en hangar med tunna metallväggar och se utgångseffekten på samma sätt som i filmen ovan, kommer bli lite stressigt

Trädvy Permalänk
Medlem
Plats
TX-225 GAVw
Registrerad
Dec 2017
Skrivet av dix_xib:

Jag kanske är för trött för att läsa alla kommentarer, men det anses alltså dåligt att vi får nya processorer som funkar till Z370? 😊

Nä, dom flesta vill ha nativt stöd USB 3.1 Gen 2... Kan man säga.
Sen kan man ifrågasätta valet att döpa om något för tredje gången.

Skickades från m.sweclockers.com

🖥 Fractal Design Define Mini C. Fractal Design Integra M 550W. Intel Core i5-8400. GIGABYTE Z370M D3H. 2x8GB Ballistix Elite 2666MHz. NVIDIA RTX 2080 FE. 250GB + 1TB WD BLUE 3D NAND. 32 GB Intel Optane Memory. 2TB WD Black. SAMSUNG SE-218.
AOC G2460FQ. GUNNAR VAYPER ONYX. Logitech G603. Logitech G240. Logitech G613. Logitech G933. Luxorparts Headphone Stand.