mboost-dp1
Intel
Det skal jo tages med et gran salt. En ting er at de siger koden kører på flere kerner, men hvor godt?
Intel har jo netop sammen med Microsoft smidt $20 mio. efter University of California at Berkeley og University of Illinois at Champaign-Urbana så de kan decideret forske i hvordan man udnytter flere kerner. Universiteterne smider selv penge i også, og får donationer fra andre, så det samlede beløb til disse nye institutter bliver større.
Alt hvad der er udviklet og forsket i af programmering de sidste 60 år er jo til enkelt-kerne arkitekturer, så det er en kæmpe omvæltning, og den sker ikke bare med en ny compiler.
Denne compiler skal jo ikke ses som et mirakel middel der løser hele denne her problematik. Den skal tværtimod ses som et middel til at få kode-skrevet-til-en-kerne til at køre bedre på flere kerne.
- Men det kan køre langt bedre end det, og jeg er overbevist om at det ikke stopper med nye compilere, men at der skal helt nye programmeringssprog/metoder ind i billedet, der giver udvikleren en fornuftig kontrol over hvordan man styrer afviklingen af koden imellem de flere kerner.
Intel har jo netop sammen med Microsoft smidt $20 mio. efter University of California at Berkeley og University of Illinois at Champaign-Urbana så de kan decideret forske i hvordan man udnytter flere kerner. Universiteterne smider selv penge i også, og får donationer fra andre, så det samlede beløb til disse nye institutter bliver større.
Alt hvad der er udviklet og forsket i af programmering de sidste 60 år er jo til enkelt-kerne arkitekturer, så det er en kæmpe omvæltning, og den sker ikke bare med en ny compiler.
Denne compiler skal jo ikke ses som et mirakel middel der løser hele denne her problematik. Den skal tværtimod ses som et middel til at få kode-skrevet-til-en-kerne til at køre bedre på flere kerne.
- Men det kan køre langt bedre end det, og jeg er overbevist om at det ikke stopper med nye compilere, men at der skal helt nye programmeringssprog/metoder ind i billedet, der giver udvikleren en fornuftig kontrol over hvordan man styrer afviklingen af koden imellem de flere kerner.
Ville jo klart være et win win for alle parter, hvis de kunne ladesig gøre at lave sådan cpu'en selv fordeler software og spil ud over de antal kerne der er til rådighed, engang er sikkert må den primitive måde det forgår nu og så svært som det er at kode til flere kerner, bliver det ikke sjovt den dag vi snakker 40-60 kerner :P
Hvor svært det er at kode til flere kerner afhænger af hvorledes understøttelsen er designet og implementeret i det underlæggende styresystem og her følger de fleste godt med.
Men så vidt jeg har forstået det, har Windows så det problem at det meste af det er lagt over på applikationens skuldre og dermed udviklerens og det er ikke let at smide ind i et udviklingsværtøj, det at man med et enkelt klik kan gøre applikationen threadsafe - for håndtering af udelelige zoner kan være en smerte.
Men så vidt jeg har forstået det, har Windows så det problem at det meste af det er lagt over på applikationens skuldre og dermed udviklerens og det er ikke let at smide ind i et udviklingsværtøj, det at man med et enkelt klik kan gøre applikationen threadsafe - for håndtering af udelelige zoner kan være en smerte.
#1 Det står ingen steder at det virker med absolut al kode. Det er sandsynligvis særlige mønstre der kigges efter som så konverteres til at køre i flere tråde. Og hvis de mønstre ikke optræder, så kan den ikke.
bare en konspirationsteori... kan det tænkes at det vil virke bedre med Intel's processorer (højst sandsynligt) ?
#7 De tager da med garanti stort hensyn til, hvordan caches og timing af kommunikation på Intels chips fungerer, så det virker optimalt med Intel-chips. Det er da vel også fair nok, når nu de leverer chips, at de så også laver en god compiler, der spiller optimalt med chipsene.
Hvis AMD eller andre også vil være med, så skal de da være velkomne til at lave deres egen compiler. I øvrigt kan AMD sikkert genanvende det meste af det teoretiske baggrundsmateriale og forstudier og forskning og så bare skrive compileren til netop deres egne chips.
Alternativt kan det tænkes at lave en compiler, der laver kode, som indeholder kode til enten den ene eller anden slags CPU, og under kørsel af softwaren vælges, hvilken stump af koden, der eksekveres alt efter hvilken CPU, man benytter.
Hvis AMD eller andre også vil være med, så skal de da være velkomne til at lave deres egen compiler. I øvrigt kan AMD sikkert genanvende det meste af det teoretiske baggrundsmateriale og forstudier og forskning og så bare skrive compileren til netop deres egne chips.
Alternativt kan det tænkes at lave en compiler, der laver kode, som indeholder kode til enten den ene eller anden slags CPU, og under kørsel af softwaren vælges, hvilken stump af koden, der eksekveres alt efter hvilken CPU, man benytter.
En begyndelse ville vel være at kigge efter almindelige tråde, som jo har eksisteret noget tid. Disse ville så i stedet for at simulere kerner rent faktisk bruge hver deres kerne. Dog er det nok ikke så nemt, som det lyder. Hvis det rent faktisk lykkes dem at lave en effektiv implementation, er det i hvert fald meget revolutionerende. Ca. ligesom de første high level sprog, der også abstraherede en del kompleksitet over til compileren. Interessant er det under alle omstændigheder.
3 skrev:
Alt hvad der er udviklet og forsket i af programmering de sidste 60 år er jo til enkelt-kerne arkitekturer, så det er en kæmpe omvæltning
Pjat... der har nu været forsket i multiprocessing næsten siden computeren blev opfundet.
Mainframes har kørt siden 1961 med mere end en CPU og for over 10 år siden blev det muligt for almindelige mennesker at samle deres egne systemer med mere end en CPU.
Så bare fordi den nyeste trend er at smide et par CPUer ind i den samme block silicium så er teknologien overhovedet ikke ny.
Desuden kan man jo sagtens forske i datalogi selvom der ikke findes fysiske maskiner inden for det område man vil forske i. F.eks. er der masser af forskning i algoritmer som kan arbejde med ægte shared memory selvom sådanne RAM ikke findes i praksis.
8 skrev:Alternativt kan det tænkes at lave en compiler, der laver kode, som indeholder kode til enten den ene eller anden slags CPU, og under kørsel af softwaren vælges, hvilken stump af koden, der eksekveres alt efter hvilken CPU, man benytter.
Er det ikke smartere bare at compile til en bestemt CPU arkitektur? Hvad er fordelen ved en CPU der skal beslutte hvilken kode skal eksekveres i run-time? Det kan da kun få den til at eksekvere langsommere.
#10 har helt ret.
Set fra en applikations synsvinkel er der ikke nogen forskel på 4 CPU med 1 kerne hver eller 1 CPU med 4 kerner.
Problem stillingen er derfor velkendt.
Og f.eks. Fortran compilere der kan parallelisere vektor og matrice udregninger automatisk eksisterede allerede for 15-20 år siden.
Problemet er at generalisere det.
Set fra en applikations synsvinkel er der ikke nogen forskel på 4 CPU med 1 kerne hver eller 1 CPU med 4 kerner.
Problem stillingen er derfor velkendt.
Og f.eks. Fortran compilere der kan parallelisere vektor og matrice udregninger automatisk eksisterede allerede for 15-20 år siden.
Problemet er at generalisere det.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund