AMD: "Vi är fast med kisel för tillverkning av kretsar i åtminstone 7–10 år till"

Permalänk
Melding Plague

AMD: "Vi är fast med kisel för tillverkning av kretsar i åtminstone 7–10 år till"

Fördelarna med nya tillverkningstekniker klingar av, men än finns ingen klar kandidat att efterträda kisel. AMD-chefen Forrest Norrod förutspår att en sådan dröjer till efter 3 nanometer.

Läs hela artikeln här

Visa signatur

Observera att samma trivselregler gäller i kommentarstrådarna som i övriga forumet och att brott mot dessa kan leda till avstängning. Kontakta redaktionen om du vill uppmärksamma fel i artikeln eller framföra andra synpunkter.

Permalänk
Inaktiv

Inte konstigt, mycket svårarbetat, inte mycket nytta vi haft av grafen hittills.

När de löst mass produktion av grafen i kvalitet som duger för komponenter kommer den förändra världen vi lever i avsevärt.

https://www.graphene-info.com/

Permalänk
Medlem

Ja, blir nog en ganska stagnerad utveckling tills dess med små prestandahopp emellan varje generation.

Visa signatur

12c/24t 4.0GHz (Zen2) • 2x16GiB 3200MHz C14 • RTX 2080 FE 1965MHz 7000MHz • X570 I PW • Ghost S1 MKII

Permalänk
Medlem
Skrivet av anon162230:

Inte konstigt, mycket svår arbetat, inte mycket nytta vi haft av grafen hittills.

När de löst produktion av grafen i stor skala kommer den nog förändra världen på många områden.

https://www.graphene-info.com/

Det gäller att vara snabb på bollen att köpa aktier när det väl kommer ett företag som lyckas med produktionen. Där snackar vi raket mtp hur många olika användningsområden som föreslagits kunna revolutioneras med det ämnet.

Permalänk
Medlem

"I am sure that quantum will mature in 10 to 100 years"

Lol!

Visa signatur

Core i7 7700K | Titan X (Pascal) | MSI 270I Gaming Pro Carbon | 32 GiB Corsair Vengeance LPX @3000MHz | Samsung 960 EVO 1TB

Permalänk
Medlem

De kommer inte lösa massproduktion av grafen för processorer förens de tjänar mer på det än krympa ytterligare på kisel.
Så ingen oro för att vi kommer få se fantastiska framgångar närmsta tiden.

Skickades från m.sweclockers.com

Visa signatur

Regn är snö på sommarn.

Permalänk
Medlem
Skrivet av anon162230:

Inte konstigt, mycket svår arbetat, inte mycket nytta vi haft av grafen hittills.

När de löst produktion av grafen i stor skala kommer den nog förändra världen på många områden.

https://www.graphene-info.com/

Energiåtgången vid framställning av grafen är ju enorm, det är en ren förlustaffär i nuläget. Svårt att se att de hittat lösningar som fungerar i praktiken inom en överskådlig framtid. Men det sitter ju en del personer i Chalmers-projektet och klurar på det där med en tämligen fet forskningsbudget, så man kan alltid hoppas.

Permalänk
Inaktiv

Och hur mycket uppskattar man kunna krympa Grafenprocessorer till?
Quantumprocessorer ser jag endast till för vissa tillämpningar.

Varvid min gissning är att utvecklingen kommer att stagnera precis om den alltid brukar göra. Detta fenomen har observeras sedan några tusen år tillbaka och det kallas för S-kurvan:
http://www.galsinsights.com/the-innovation-s-curve/

Permalänk
Medlem
Skrivet av serdyllon:

Energiåtgången vid framställning av grafen är ju enorm, det är en ren förlustaffär i nuläget. Svårt att se att de hittat lösningar som fungerar i praktiken inom en överskådlig framtid. Men det sitter ju en del personer i Chalmers-projektet och klurar på det där med en tämligen fet forskningsbudget, så man kan alltid hoppas.

Vore ju jävligt coolt om Sverige var de som lyckades först...

Permalänk
Medlem

Skulle de även kunna kombinera tillverkningen av grafen med att plocka ut kol ur atmosfären, så hade det varit grymt.

Permalänk
Medlem

Även om de nu har en bra plan för att krympa ner till 3nm, så är man ju fortfarande lite orolig för hur kapaciteten kommer vara, liksom hur trångt lär det inte bli på TSMC 7nm med ryzen, radeon, geforce, nya konsoller och massor av ARM SoCs. Lär dessutom bli en utmaning att ens behålla nuvarande frekvenser, vilket jag antar är en av de största problem med intels 10nm process, förutom det uppenbara med yields.

Permalänk
Medlem

Om någon är intresserad kan jag rekommendera det här klippet. Han pratar om cores och andra saker och förklarar varför det inte bara går att lägga till flera cores för att öka prestandan. Riktigt bra video.

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

Permalänk
Avstängd

Vi behöver bättre mjukvara utan spionprogram och annat skit som slöar ner är min teori.

Permalänk
Medlem

Kan man inte öka prestandan så mycket mer så får man öka effektiviteten i programmen. Har en känsla av att det är för mycket abstraktion idag. C# och allt vad det är. Bättre om man går tillbaka till ASM och skriver extremt optimerade och väloljade program. Visst, det blir lite jobbigare för utvecklarna men de har ju också helt sjukt bra löner idag.

Visa signatur

ozzed.net Min egenkomponerade 8-bit musik. Gillar du musiken från gamla klassiska NES eller Gameboy och liknande är det värt ett besök. :) Jag finns också på Spotify, Bandcamp, Jamendo, Youtube, och du kan även följa mig på Twitter och Facebook.
Vet du att du har fel? Signalera detta tydligt med Argumentationsfel och gärna Whataboutism.

Permalänk
Medlem
Skrivet av Ozzed:

Kan man inte öka prestandan så mycket mer så får man öka effektiviteten i programmen. Har en känsla av att det är för mycket abstraktion idag. C# och allt vad det är. Bättre om man går tillbaka till ASM och skriver extremt optimerade och väloljade program. Visst, det blir lite jobbigare för utvecklarna men de har ju också helt sjukt bra löner idag.

Du får ursäkta mig om detta låter lite otrevligt, men med lite tur så finns det bättre metodik för vad som leder till bättre utveckling än känslan hos folk utan större kompetens inom ämnet. Om du nu sitter på något med lite mer substans så får du gärna länka till det eller förklara hur detta på något sett är ett realistiskt alternativ att gå tillbaka till maskinkod i dagens marknad.

Permalänk
Medlem
Permalänk
Medlem
Skrivet av sKRUVARN:

Du får ursäkta mig om detta låter lite otrevligt, men med lite tur så finns det bättre metodik för vad som leder till bättre utveckling än känslan hos folk utan större kompetens inom ämnet. Om du nu sitter på något med lite mer substans så får du gärna länka till det eller förklara hur detta på något sett är ett realistiskt alternativ att gå tillbaka till maskinkod i dagens marknad.

Det säger väl sig självt? Om man inte längre kan öka prestandan så måste man ju minska overhead, och enda sättet att göra det på ett vettigt sätt är väl då att koda så optimerat som möjligt?

Ett alternativ skulle såklart kunna vara att man låter AI sköta den biten. DVS att man som idah kodar i typ C# och sedan låter AI optimera koden till ASM.

Sen vet jag inte riktigt vad du menar med "dagens marknad", men visst skulle man tillslut bli tbungen att skriva optimerade program om prestandan slog i ett tak. Annars gör ju någon annan det och tar då pengarna. Det är ju logiskt.

Ingen fara, rycker inte du var nedlåtande eller så men jag tror du grovt missuppfattade det jag skrev.

Visa signatur

ozzed.net Min egenkomponerade 8-bit musik. Gillar du musiken från gamla klassiska NES eller Gameboy och liknande är det värt ett besök. :) Jag finns också på Spotify, Bandcamp, Jamendo, Youtube, och du kan även följa mig på Twitter och Facebook.
Vet du att du har fel? Signalera detta tydligt med Argumentationsfel och gärna Whataboutism.

Permalänk
Medlem
Skrivet av Ozzed:

Kan man inte öka prestandan så mycket mer så får man öka effektiviteten i programmen. Har en känsla av att det är för mycket abstraktion idag. C# och allt vad det är. Bättre om man går tillbaka till ASM och skriver extremt optimerade och väloljade program. Visst, det blir lite jobbigare för utvecklarna men de har ju också helt sjukt bra löner idag.

Att handknacka ultraoptimerad assembler är väldigt komplicerat och tar väldigt lång tid, så det är definitivt inte vägen framåt. Det håller inte för generellt bruk i praktiken, utan bara i extremfall (och så har det varit länge).

Det är en mycket bättre idé att låta kompilatorer optimera åt en, dels för att de i princip alltid gör ett bättre jobb, dels för att det går blixtsnabbt. Låt maskiner sköta det som maskiner gör bättre än människor.

Visa signatur

5950X, 3090

Permalänk
Medlem
Skrivet av Ozzed:

Det säger väl sig självt? Om man inte längre kan öka prestandan så måste man ju minska overhead, och enda sättet att göra det på ett vettigt sätt är väl då att koda så optimerat som möjligt?

Ja, men det är en lång väg från det till att sitta och knappra in maskinkod.

Citat:

Ett alternativ skulle såklart kunna vara att man låter AI sköta den biten. DVS att man som idah kodar i typ C# och sedan låter AI optimera koden till ASM.

Jag är ingen programmerare... Men vad tror du en kompilator gör? Att göra smartare kompilatorer är inte samma sak som att börja skriva ASM.

Citat:

Sen vet jag inte riktigt vad du menar med "dagens marknad", men visst skulle man tillslut bli tbungen att skriva optimerade program om prestandan slog i ett tak. Annars gör ju någon annan det och tar då pengarna. Det är ju logiskt.

Med dagensmarknad så menar jag att det absolut säkert hade gått att skriva tetris i maskinkod inom en rimlig tids/pris-ram, men att skriva RDR2 i maskinkod i princip blir omöjligt.

Permalänk
Medlem
Skrivet av Ozzed:

Ett alternativ skulle såklart kunna vara att man låter AI sköta den biten. DVS att man som idah kodar i typ C# och sedan låter AI optimera koden till ASM.

C# runtimeoptimeras med JIT, och så har det varit sedan 2001 så vitt jag vet. Det är inte samma sak som ett "AI", men om det går att ta fram bättre kompilatorer (statiskt eller runtime) med hjälp av någon form av maskininlärning så vore det förstås bra.

Visa signatur

5950X, 3090

Permalänk
Medlem

@Ozzed Det du frågar efter är helt meningslöst. För det mesta är det inte programmens optimering som är problemet, det är I/O. För spel är det oftast GPU:n som är flaskhalsen. Som andra skrivit skulle de flesta projekt aldrig kunnat byggas om de skrevs i maskinkod - de hade t.ex bara fungerat på en specifik CPU - trist om du köpt en annan CPU.

Snarare får vi nog se fler specialbyggda kärnor som kan en och endast en sak. Video-kodare/avkodare osv som vi har i mobil-SOC. De är otroligt snabba och effektiva på sin sak. Många problem kan fortfarande parallelliseras mer och dra nytta av fler kärnor, men ROI är oftast låg. Användarna är inte beredda att betala den utvecklingstid det kräver att öka prestandan. Nästa Battlefield, ultra-optimerat, pris 4865 kr. Som hittat.

Skickades från m.sweclockers.com

Permalänk
Medlem
Skrivet av Ozzed:

Kan man inte öka prestandan så mycket mer så får man öka effektiviteten i programmen. Har en känsla av att det är för mycket abstraktion idag. C# och allt vad det är. Bättre om man går tillbaka till ASM och skriver extremt optimerade och väloljade program. Visst, det blir lite jobbigare för utvecklarna men de har ju också helt sjukt bra löner idag.

Vet man vad man gör så går det alldeles utmärkt att skriva väloptimerade program även i högnivåspråk som C#. Kompilatorerna idag är så pass bra att man inte vinner mycket på att skriva i Assembler ens i bästa fall.

De flesta viktiga optimeringar har ändå inget med val av programmeringsspråk att göra utan har främst att göra med att välja rätt algoritmer - och i vissa fall justera ordningen på data åtkomster så att man utnyttjar cachen så bra som möjligt.

Permalänk
Medlem
Skrivet av TechGuru:

@Ozzed Det du frågar efter är helt meningslöst. För det mesta är det inte programmens optimering som är problemet, det är I/O. För spel är det oftast GPU:n som är flaskhalsen. Som andra skrivit skulle de flesta projekt aldrig kunnat byggas om de skrevs i maskinkod - de hade t.ex bara fungerat på en specifik CPU - trist om du köpt en annan CPU.

Snarare får vi nog se fler specialbyggda kärnor som kan en och endast en sak. Video-kodare/avkodare osv som vi har i mobil-SOC. De är otroligt snabba och effektiva på sin sak. Många problem kan fortfarande parallelliseras mer och dra nytta av fler kärnor, men ROI är oftast låg. Användarna är inte beredda att betala den utvecklingstid det kräver att öka prestandan. Nästa Battlefield, ultra-optimerat, pris 4865 kr. Som hittat.

Skickades från m.sweclockers.com

Fast det har väl gjorts på GPU-fronten redan. Med t. ex Vulkan och DX12 så är det "close to metal" och så ser man stora prestandavinster om det görs rätt. Det jag efterfrågar är alltså ett "Vulkan" fast för CPU. Alltså att man själv skriver programmen specifikt för att dra nytta av sista droppen blod i en processor. Visst, du får skriva ett program för Coffee-lake, ett för Ryzen osv, men tittar man på hur programmering såg ut förr så var det ju mer så, att man handoptimerar för varje unik arkitektur.

Att programmen blir dyrare tror jag inte. Kommer alltid finnas en tävlande aktör som går in och gör samma jobb till ett lägre pris så länge vi har en fri marknad. Så att man skall kunna fuska upp priserna utan att folk märker det tror jag inte är sannorlikt.

Visa signatur

ozzed.net Min egenkomponerade 8-bit musik. Gillar du musiken från gamla klassiska NES eller Gameboy och liknande är det värt ett besök. :) Jag finns också på Spotify, Bandcamp, Jamendo, Youtube, och du kan även följa mig på Twitter och Facebook.
Vet du att du har fel? Signalera detta tydligt med Argumentationsfel och gärna Whataboutism.

Permalänk
Medlem
Skrivet av Ozzed:

Fast det har väl gjorts på GPU-fronten redan. Med t. ex Vulkan och DX12 så är det "close to metal" och så ser man stora prestandavinster om det görs rätt. Det jag efterfrågar är alltså ett "Vulkan" fast för CPU. Alltså att man själv skriver programmen specifikt för att dra nytta av sista droppen blod i en processor. Visst, du får skriva ett program för Coffee-lake, ett för Ryzen osv, men tittar man på hur programmering såg ut förr så var det ju mer så, att man handoptimerar för varje unik arkitektur.

Att programmen blir dyrare tror jag inte. Kommer alltid finnas en tävlande aktör som går in och gör samma jobb till ett lägre pris så länge vi har en fri marknad. Så att man skall kunna fuska upp priserna utan att folk märker det tror jag inte är sannorlikt.

Mängden kod som körs på GPU (shaders) är liten i jämförelse med vad som körs på CPUn. Små tighta loopar, lite kod, körs konstant massivt antal gånger. Det är klart man vinner på att optimera de raderna.

Hur mycket fortare går det att läsa upp en textur från hårddisken med assembler? Det gör det inte.

Klart det blir dyrare att skriva maskinkod för hand. Mycket mycket dyrare. I 99% av fallen kommer högnivåkod kompileras till maskinkod som presterar likvärdigt. Jag tror inte att du har någon aning om vad du pratar om.

Det är som om målare skulle börja måla fasader med tandborstar för att komma in en mikrometer djupare i springorna. Klart det håller bättre men vem betalar för det... Handlar inte om att fuska upp priserna, mängden jobb ökar markant och prestandan blir bara marginellt bättre.

Skickades från m.sweclockers.com

Permalänk
Medlem
Skrivet av Ozzed:

Kan man inte öka prestandan så mycket mer så får man öka effektiviteten i programmen. Har en känsla av att det är för mycket abstraktion idag. C# och allt vad det är. Bättre om man går tillbaka till ASM och skriver extremt optimerade och väloljade program. Visst, det blir lite jobbigare för utvecklarna men de har ju också helt sjukt bra löner idag.

Det här är "hello world" i x86 Assembler:

section .text global _start _start: mov edx,len mov ecx,msg mov ebx,1 mov eax,4 int 0x80 mov eax,1 int 0x80 section .data msg db 'Hello, world!',0xa len equ $ - msg

Det här är "hello world" i Python:

print ("Hello, world!")

Annars kan vi jämföra med C++

#include<iostream> using namespace std; int main() { cout << "Hello World!"; return 0; }

Förutom antal rader kod och hur svårläst koden är har assembler också det där lilla problemet att det måste skrivas om för olika arkitekturer. Såhär ser samma program ut för ARM:

.text .global _start _start: mov r0, #1 ldr r1, =message ldr r2, =len mov r7, #4 swi 0 mov r7, #1 swi 0 .data message: .asciz "hello world\n" len = .-message

Och det här är endast de mest grundläggande problemen.

Permalänk
Datavetare
Skrivet av Ozzed:

Fast det har väl gjorts på GPU-fronten redan. Med t. ex Vulkan och DX12 så är det "close to metal" och så ser man stora prestandavinster om det görs rätt. Det jag efterfrågar är alltså ett "Vulkan" fast för CPU. Alltså att man själv skriver programmen specifikt för att dra nytta av sista droppen blod i en processor. Visst, du får skriva ett program för Coffee-lake, ett för Ryzen osv, men tittar man på hur programmering såg ut förr så var det ju mer så, att man handoptimerar för varje unik arkitektur.

Att programmen blir dyrare tror jag inte. Kommer alltid finnas en tävlande aktör som går in och gör samma jobb till ett lägre pris så länge vi har en fri marknad. Så att man skall kunna fuska upp priserna utan att folk märker det tror jag inte är sannorlikt.

Det fungerar inte riktigt så längre. Om man skulle ge uppgiften att skriva något i assembler i stället för t.ex. C eller C++ skulle minst nio av tio skriva något som är långsammare än vad en modern kompilator producerar.

Är bara väldigt specifika fall man får någon vinst från att skriva assembler direkt, men även dessa fall hanterar man idag typiskt via s.k. intrinsics (exempel för x86 SSE/AVX och ARM NEON). Intrinsics gör att användandet av specifika assemblerinstruktioner uppför sig som C-funktioner, det är långt enklare att få saker korrekt ihop med övrig kod + är mindre dålig mot optimeringspassen vid kompilering.

Assembler-block i C/C++ kod måste hanteras som svarta lådor som i praktiken kan göra vad som helst, något som förhindrar en del optimeringar i kod som använder assembler -> sannolikheten att det i slutändan är snabbare är ännu mindre.

Sedan skriver man inte assembler i GPUer. Hela poängen med CUDA/OpenCL är ju att man ska kunna skriva relativt "normal" C-kod. Senaste versionerna av CUDA tillåter ju även användning av C++, från och med Volta finns alla funktioner i GPUn för att man ska kunna använda sig av standardversionen av ISO C11 och ISO C++17.

Varje sig människor eller ens kompilatorer är speciellt framgångsrika att optimera för specifika mikroarkitekturer. Moderna CPUer är helt enkelt så bra på att hantera maskinkod så som den typiskt genereras från kompilatorer. Ett exempel på hur det inte blir som man tänk sig är en diskussion om att "-march=znver1" i genomsnitt ger 0-3 % sämre prestanda jämfört med "-march=haswell" när man kör på just Zen.

0-3 % är en irrelevant skillnad, men skillnaden har verifierats av tillräckligt många för att det inte borde vara slumpen. D.v.s. när man optimerar för vara som borde vara optimalt för Zen visar det sig att en människa (för det är en människa som beskrivit hur det borde förhålla sig här) stjälper mer än hjälper här.

Har sett liknande fenomen på Intel CPUer, d.v.s att kompilera med t.ex. "-march=core2" kan ibland ge bättre resultat jämfört med "-march=skylake" trots att det körs på en Skylake. En egentliga poäng jag ser med "-march=xxx" är egentligen att låsa upp intrinsics (fast det kan göras explicit också). T.ex. krävs ju en viss nivå för att AVX-intrinsics ska gå att använda.

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 Ozzed:

Fast det har väl gjorts på GPU-fronten redan. Med t. ex Vulkan och DX12 så är det "close to metal" och så ser man stora prestandavinster om det görs rätt. Det jag efterfrågar är alltså ett "Vulkan" fast för CPU. Alltså att man själv skriver programmen specifikt för att dra nytta av sista droppen blod i en processor. Visst, du får skriva ett program för Coffee-lake, ett för Ryzen osv, men tittar man på hur programmering såg ut förr så var det ju mer så, att man handoptimerar för varje unik arkitektur.

Att programmen blir dyrare tror jag inte. Kommer alltid finnas en tävlande aktör som går in och gör samma jobb till ett lägre pris så länge vi har en fri marknad. Så att man skall kunna fuska upp priserna utan att folk märker det tror jag inte är sannorlikt.

Skrivet av DasIch:

Det här är "hello world" i x86 Assembler:

section .text global _start _start: mov edx,len mov ecx,msg mov ebx,1 mov eax,4 int 0x80 mov eax,1 int 0x80 section .data msg db 'Hello, world!',0xa len equ $ - msg

Det här är "hello world" i Python:

print ("Hello, world!")

Annars kan vi jämföra med C++

#include<iostream> using namespace std; int main() { cout << "Hello World!"; return 0; }

Förutom antal rader kod och hur svårläst koden är har assembler också det där lilla problemet att det måste skrivas om för olika arkitekturer. Såhär ser samma program ut för ARM:

.text .global _start _start: mov r0, #1 ldr r1, =message ldr r2, =len mov r7, #4 swi 0 mov r7, #1 swi 0 .data message: .asciz "hello world\n" len = .-message

Och det här är endast de mest grundläggande problemen.

Skrivet av Yoshman:

Det fungerar inte riktigt så längre. Om man skulle ge uppgiften att skriva något i assembler i stället för t.ex. C eller C++ skulle minst nio av tio skriva något som är långsammare än vad en modern kompilator producerar.

Är bara väldigt specifika fall man får någon vinst från att skriva assembler direkt, men även dessa fall hanterar man idag typiskt via s.k. intrinsics (exempel för x86 SSE/AVX och ARM NEON). Intrinsics gör att användandet av specifika assemblerinstruktioner uppför sig som C-funktioner, det är långt enklare att få saker korrekt ihop med övrig kod + är mindre dålig mot optimeringspassen vid kompilering.

Assembler-block i C/C++ kod måste hanteras som svarta lådor som i praktiken kan göra vad som helst, något som förhindrar en del optimeringar i kod som använder assembler -> sannolikheten att det i slutändan är snabbare är ännu mindre.

Sedan skriver man inte assembler i GPUer. Hela poängen med CUDA/OpenCL är ju att man ska kunna skriva relativt "normal" C-kod. Senaste versionerna av CUDA tillåter ju även användning av C++, från och med Volta finns alla funktioner i GPUn för att man ska kunna använda sig av standardversionen av ISO C11 och ISO C++17.

Varje sig människor eller ens kompilatorer är speciellt framgångsrika att optimera för specifika mikroarkitekturer. Moderna CPUer är helt enkelt så bra på att hantera maskinkod så som den typiskt genereras från kompilatorer. Ett exempel på hur det inte blir som man tänk sig är en diskussion om att "-march=znver1" i genomsnitt ger 0-3 % sämre prestanda jämfört med "-march=haswell" när man kör på just Zen.

0-3 % är en irrelevant skillnad, men skillnaden har verifierats av tillräckligt många för att det inte borde vara slumpen. D.v.s. när man optimerar för vara som borde vara optimalt för Zen visar det sig att en människa (för det är en människa som beskrivit hur det borde förhålla sig här) stjälper mer än hjälper här.

Har sett liknande fenomen på Intel CPUer, d.v.s att kompilera med t.ex. "-march=core2" kan ibland ge bättre resultat jämfört med "-march=skylake" trots att det körs på en Skylake. En egentliga poäng jag ser med "-march=xxx" är egentligen att låsa upp intrinsics (fast det kan göras explicit också). T.ex. krävs ju en viss nivå för att AVX-intrinsics ska gå att använda.

För att inte tala om att en del kod som är tidskritisk/behöver optimeras skrivs som in-line assembler i c/c++ kod redan som det är idag

Visa signatur

Intel 6700k @ stock || Noctua NH-U14s || ASUS R9 290X DCII || MSI Z170-A Pro || Corsair V LPX 3000MHz CL15 2x8GB || Corsair AX850 || Intel 535 240GB (OS+spel) || Samsung 860 EVO 500GB

Permalänk
Medlem
Skrivet av Ozzed:

Visst, du får skriva ett program för Coffee-lake, ett för Ryzen osv, men tittar man på hur programmering såg ut förr så var det ju mer så, att man handoptimerar för varje unik arkitektur.

Hur lång tid tycker du att utvecklare ska gå tillbaka när dom släpper ett nytt spel? Hur lång tid framåt ska utvecklare släppa optimeringar när det kommer nya processorer?

Skickades från m.sweclockers.com

Visa signatur

sweclockers prestandaindex

Efter 10 kommer 11.
Efter 99 kommer 100.

Permalänk
Medlem
Skrivet av TechGuru:

Mängden kod som körs på GPU (shaders) är liten i jämförelse med vad som körs på CPUn. Små tighta loopar, lite kod, körs konstant massivt antal gånger. Det är klart man vinner på att optimera de raderna.

Hur mycket fortare går det att läsa upp en textur från hårddisken med assembler? Det gör det inte.

Klart det blir dyrare att skriva maskinkod för hand. Mycket mycket dyrare. I 99% av fallen kommer högnivåkod kompileras till maskinkod som presterar likvärdigt. Jag tror inte att du har någon aning om vad du pratar om.

Det är som om målare skulle börja måla fasader med tandborstar för att komma in en mikrometer djupare i springorna. Klart det håller bättre men vem betalar för det... Handlar inte om att fuska upp priserna, mängden jobb ökar markant och prestandan blir bara marginellt bättre.

Skickades från m.sweclockers.com

Skrivet av DasIch:

Det här är "hello world" i x86 Assembler:

section .text global _start _start: mov edx,len mov ecx,msg mov ebx,1 mov eax,4 int 0x80 mov eax,1 int 0x80 section .data msg db 'Hello, world!',0xa len equ $ - msg

Det här är "hello world" i Python:

print ("Hello, world!")

Annars kan vi jämföra med C++

#include<iostream> using namespace std; int main() { cout << "Hello World!"; return 0; }

Förutom antal rader kod och hur svårläst koden är har assembler också det där lilla problemet att det måste skrivas om för olika arkitekturer. Såhär ser samma program ut för ARM:

.text .global _start _start: mov r0, #1 ldr r1, =message ldr r2, =len mov r7, #4 swi 0 mov r7, #1 swi 0 .data message: .asciz "hello world\n" len = .-message

Och det här är endast de mest grundläggande problemen.

Skrivet av Yoshman:

Det fungerar inte riktigt så längre. Om man skulle ge uppgiften att skriva något i assembler i stället för t.ex. C eller C++ skulle minst nio av tio skriva något som är långsammare än vad en modern kompilator producerar.

Är bara väldigt specifika fall man får någon vinst från att skriva assembler direkt, men även dessa fall hanterar man idag typiskt via s.k. intrinsics (exempel för x86 SSE/AVX och ARM NEON). Intrinsics gör att användandet av specifika assemblerinstruktioner uppför sig som C-funktioner, det är långt enklare att få saker korrekt ihop med övrig kod + är mindre dålig mot optimeringspassen vid kompilering.

Assembler-block i C/C++ kod måste hanteras som svarta lådor som i praktiken kan göra vad som helst, något som förhindrar en del optimeringar i kod som använder assembler -> sannolikheten att det i slutändan är snabbare är ännu mindre.

Sedan skriver man inte assembler i GPUer. Hela poängen med CUDA/OpenCL är ju att man ska kunna skriva relativt "normal" C-kod. Senaste versionerna av CUDA tillåter ju även användning av C++, från och med Volta finns alla funktioner i GPUn för att man ska kunna använda sig av standardversionen av ISO C11 och ISO C++17.

Varje sig människor eller ens kompilatorer är speciellt framgångsrika att optimera för specifika mikroarkitekturer. Moderna CPUer är helt enkelt så bra på att hantera maskinkod så som den typiskt genereras från kompilatorer. Ett exempel på hur det inte blir som man tänk sig är en diskussion om att "-march=znver1" i genomsnitt ger 0-3 % sämre prestanda jämfört med "-march=haswell" när man kör på just Zen.

0-3 % är en irrelevant skillnad, men skillnaden har verifierats av tillräckligt många för att det inte borde vara slumpen. D.v.s. när man optimerar för vara som borde vara optimalt för Zen visar det sig att en människa (för det är en människa som beskrivit hur det borde förhålla sig här) stjälper mer än hjälper här.

Har sett liknande fenomen på Intel CPUer, d.v.s att kompilera med t.ex. "-march=core2" kan ibland ge bättre resultat jämfört med "-march=skylake" trots att det körs på en Skylake. En egentliga poäng jag ser med "-march=xxx" är egentligen att låsa upp intrinsics (fast det kan göras explicit också). T.ex. krävs ju en viss nivå för att AVX-intrinsics ska gå att använda.

Skrivet av mickwald:

För att inte tala om att en del kod som är tidskritisk/behöver optimeras skrivs som in-line assembler i c/c++ kod redan som det är idag

Skrivet av ClintBeastwood:

Hur lång tid tycker du att utvecklare ska gå tillbaka när dom släpper ett nytt spel? Hur lång tid framåt ska utvecklare släppa optimeringar när det kommer nya processorer?

Skickades från m.sweclockers.com

Det jag pratar om är ett scenario där det blir diminishing returns av att öka rå prestanda. Vi är tack och lov inte där än och förhoppningsvis så hamnar vi aldrig där heller. Men ponera rent hypotetiskt att vi hamnar i ett läge där enkeltrådsprestanda inte längre går att öka och man inte heller kan öka prestandan i vissa beräkningar genom att lägga till fler kärnor. Hur skall man då effektivisera koden utan att koda "närmare metallen"?

Visa signatur

ozzed.net Min egenkomponerade 8-bit musik. Gillar du musiken från gamla klassiska NES eller Gameboy och liknande är det värt ett besök. :) Jag finns också på Spotify, Bandcamp, Jamendo, Youtube, och du kan även följa mig på Twitter och Facebook.
Vet du att du har fel? Signalera detta tydligt med Argumentationsfel och gärna Whataboutism.

Permalänk
Medlem

Som sagt, "närmre metallen" än vad vi redan är när det behövs hjälper inte - då har vi nått vägs ände.

Skickades från m.sweclockers.com