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

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.

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

Lol!

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...

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.

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.

@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

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.

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

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.

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.

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

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