mboost-dp1
unknown
Det er meget fint med alle de mange kerner, men vi venter jo stadig på software der kan udnytte bare to kerner effektivt.
Det er meget fint at OS'et understøtter eksempelvis SMP (eller NUMA for den sags skyld), men hvis 90-95% af den software der findes ude i den store verden, stadig ikke er i stand til at arbejde effektivt i et SMP miljø, så kan du jo have nok så mange kerner uden det betyder det store.
Det er meget fint at OS'et understøtter eksempelvis SMP (eller NUMA for den sags skyld), men hvis 90-95% af den software der findes ude i den store verden, stadig ikke er i stand til at arbejde effektivt i et SMP miljø, så kan du jo have nok så mange kerner uden det betyder det store.
#1:
"gadvide hvad sådan et bæst så sluger af strøm? - sandynligvis mere end Barsebæk kunne levere på 500år :| "
Faktsik er du way off...
Intel's Answer to Cell: The Teraflop chip
"Intel showed off a wafer of these teraflop chips, with a target clock speed of 3.1GHz and power consumption of about 1W per 10 gigaflops - or 100W for 1 TFLOP. The chip is simply a technology demo and won't be productized in any way, but in the next 5 years don't be too surprised if you end up seeing some hybrid CPUs with a combination of powerful general purpose cores with smaller more specialized
Terra...
"gadvide hvad sådan et bæst så sluger af strøm? - sandynligvis mere end Barsebæk kunne levere på 500år :| "
Faktsik er du way off...
Intel's Answer to Cell: The Teraflop chip
"Intel showed off a wafer of these teraflop chips, with a target clock speed of 3.1GHz and power consumption of about 1W per 10 gigaflops - or 100W for 1 TFLOP. The chip is simply a technology demo and won't be productized in any way, but in the next 5 years don't be too surprised if you end up seeing some hybrid CPUs with a combination of powerful general purpose cores with smaller more specialized
Terra...
#2
Man kunne forestille sig nye måder at programere på kunne løse det, hvis man f.eks. henter inspiration hos FPGA/CPLD programeringsprog (VHDL og Verilog) så kunne man godt forestille sig at man med mange kerner (>10) kunne arbejde med ikke-lineær kode og på den måde opnå udnyttelse af de store paraleliseringsmuligheder uden at programøren som sådan skulle spekulere på det.
I dag er det drønbesværligt at arbejde med f.eks. asynkron I/O, men der er inten i vejen for at lave et programeringssprog der gjorde det let, og tilsvarende kunne man godt forstille sig at man kunne udnytte ikke-lineær kode til at drage fordel af de mange kerner - men der vil naturligvis stadig være mange opgaver der er naturligt linære og derfor ikke kan drage nytte af det, og det vil under alle omstændigheder kræve at programmer (og programører) omskrives fra bunden for at kunne udnytte det.
Man kunne forestille sig nye måder at programere på kunne løse det, hvis man f.eks. henter inspiration hos FPGA/CPLD programeringsprog (VHDL og Verilog) så kunne man godt forestille sig at man med mange kerner (>10) kunne arbejde med ikke-lineær kode og på den måde opnå udnyttelse af de store paraleliseringsmuligheder uden at programøren som sådan skulle spekulere på det.
I dag er det drønbesværligt at arbejde med f.eks. asynkron I/O, men der er inten i vejen for at lave et programeringssprog der gjorde det let, og tilsvarende kunne man godt forstille sig at man kunne udnytte ikke-lineær kode til at drage fordel af de mange kerner - men der vil naturligvis stadig være mange opgaver der er naturligt linære og derfor ikke kan drage nytte af det, og det vil under alle omstændigheder kræve at programmer (og programører) omskrives fra bunden for at kunne udnytte det.
For at flytte data mellem de forskellige kerner, vil Intel benytte sig af SRAM (Statisk RAM) chips, forbundet direkte til bunden af de enkelte chips.
Det bliver noget slemt noget at få ordenligt styr på uden at det giver mange forsinkelser.
#8: Vi havde faktisk, omend begrænset, undervisning i multithreading på 1. år af ha.dat...
Datamatikeruddannelser siger du? Der er vist i det hele taget behov for en KRAFTIG revurdering af datamatiker uddannelsen, hvis denne skal klare sig såvel nationalt som internationalt fremover!
Datamatikeruddannelser siger du? Der er vist i det hele taget behov for en KRAFTIG revurdering af datamatiker uddannelsen, hvis denne skal klare sig såvel nationalt som internationalt fremover!
ja, prisen bliver vel også derefter, hvis de koster +20K$ er der nok ikke så mange der købe dem til hjemmebrug.
Men hvis udvilkingen skal følge moore's lov er man vel også næsten nødt til at bruge flere cpu'er, og vi er jo allerede på 4 i dag, det er vel en meget naturlig udvikling.
#2
Det er der vel heller ikke noget mærkeligt i det er ikke mere end 2-3 år siden smp systemer kom så langt ned i pris at man begyndte at købe dem til hjemme brug, og det er først nu det er begyndt at blive en 'default' ting, så det er nok også først nu udviklingen af smp programmer til hjemmebrug starter.
Men hvis udvilkingen skal følge moore's lov er man vel også næsten nødt til at bruge flere cpu'er, og vi er jo allerede på 4 i dag, det er vel en meget naturlig udvikling.
#2
Det er meget fint med alle de mange kerner, men vi venter jo stadig på software der kan udnytte bare to kerner effektivt.
Det er der vel heller ikke noget mærkeligt i det er ikke mere end 2-3 år siden smp systemer kom så langt ned i pris at man begyndte at købe dem til hjemme brug, og det er først nu det er begyndt at blive en 'default' ting, så det er nok også først nu udviklingen af smp programmer til hjemmebrug starter.
#15
Du skal tænke på at $20k+ er billigt for en teraflop regnekraft. Tænk på hvor glade forskere og firmaer vil være for denne CPU.
Og det er egentlig ligemeget om programmer kan finde ud af at multithreade sig selv - Vi kan bare assigne en kerne til hver applikation på OS'et, så man eksempelvis kan køre Apache med 60 tråde på hver sin CPU.
Du skal tænke på at $20k+ er billigt for en teraflop regnekraft. Tænk på hvor glade forskere og firmaer vil være for denne CPU.
Og det er egentlig ligemeget om programmer kan finde ud af at multithreade sig selv - Vi kan bare assigne en kerne til hver applikation på OS'et, så man eksempelvis kan køre Apache med 60 tråde på hver sin CPU.
#16
Ja det virker, men der er også mange steder det er en rigtig dårlig løsning.
Og det er egentlig ligemeget om programmer kan finde ud af at multithreade sig selv - Vi kan bare assigne en kerne til hver applikation på OS'et, så man eksempelvis kan køre Apache med 60 tråde på hver sin CPU.
Ja det virker, men der er også mange steder det er en rigtig dårlig løsning.
#17
Det kan du ikke bare tillade dig at sige. Kom med et realistisk eksempel og en ordentlig forklaring.
Eksempelvis kan jeg også fortælle dig at det nogle gange er en meget dårlig idé at tage sig en lur. For eksempel mens du er i gang med at føre bil. (duh)
Ja det virker, men der er også mange steder det er en rigtig dårlig løsning.
Det kan du ikke bare tillade dig at sige. Kom med et realistisk eksempel og en ordentlig forklaring.
Eksempelvis kan jeg også fortælle dig at det nogle gange er en meget dårlig idé at tage sig en lur. For eksempel mens du er i gang med at føre bil. (duh)
#18
Det virker jo ikke hvis alle tråde ikke skal arbejde sammen om at nå et fælles resultat, ofte er det ikke nok bare at starte det samme program x antal gange, et program der tæller fra 1 til 1.000.000 kører jo ikke hurtigere fordi du kører det x gange samtidig.
Det virker jo ikke hvis alle tråde ikke skal arbejde sammen om at nå et fælles resultat, ofte er det ikke nok bare at starte det samme program x antal gange, et program der tæller fra 1 til 1.000.000 kører jo ikke hurtigere fordi du kører det x gange samtidig.
Multithreading er en måde at distribuere opgaver i programmer mellem flere, alenestående men samarbejdende tråde i programmet, og adskiller sig fra multiproces-programmer ved, at der ikke anvendes flere instanser af samme program samtidig, med dertil hørende interproceskommunikation, men at al håndtering af koordination og kommunikation foregår inde i selve programmet, samt at programmerne nemt og elegant kan anvende samtlige globale variable.
#19, ad din box:
Det er i bund og grund ligegyldigt om du snakker tråde eller processer på et hyperthreaded, multicore eller multicpu system.
Det hele afhænger af hardware udnyttelsen. Den ægte multithreading som man ser på de tre ovennævnte arkitekturtyper vil medføre en revolution, der langt overgår OO.
Eksempelvis er det lidt ligegyldigt om det er en tråd eller en process når vi taler om at koordinere writes og reads til memory fordelt over x antal core/cpu caches.
Det er i bund og grund ligegyldigt om du snakker tråde eller processer på et hyperthreaded, multicore eller multicpu system.
Det hele afhænger af hardware udnyttelsen. Den ægte multithreading som man ser på de tre ovennævnte arkitekturtyper vil medføre en revolution, der langt overgår OO.
Eksempelvis er det lidt ligegyldigt om det er en tråd eller en process når vi taler om at koordinere writes og reads til memory fordelt over x antal core/cpu caches.
I tilfælde af folk vil se mere om denne CPU og Intel's andre tiltag fra IDF:
http://mfile.akamai.com/28603/wmv/intelstudio.down...
Terra...
http://mfile.akamai.com/28603/wmv/intelstudio.down...
Terra...
#20
process
Thread
process
In computing, a process is a running instance of a program, including all variables and other state. A multitasking operating system may just switch between processes to give the appearance of many processes executing concurrently or simultaneously, though in fact only one process can be executing at any one time per CPU thread (some new processors, such as Athlon 64 X2 can actually execute two processes at a time, because they are multicore processors. Intel's Pentium 4 with Hyperthreading capability has a different design: some doubled parts of the core allow the processor to make a context switch in almost no time).
Thread
Threads are a way for a program to split itself into two or more simultaneously (or pseudo-simultaneously) running tasks. Threads and processes differ from one operating system to another, but in general, the way that a thread is created and shares its resources is different from the way a process does.
Og faldt lige over en god artikel om TeraScale CPU's:
http://www.pcper.com/article.php?aid=302&type=...
Terra...
http://www.pcper.com/article.php?aid=302&type=...
Terra...
#12 - Det lyder spændende. Det må du gerne uddybe en smule. Jeg har kørt SMP siden '97 og venter stadig på "almindelig" software der virkelig kan få noget ud af det. På Linux fronten har SMP længe været godt kørende på serverapplikationerne, ganske som det også har det på Windows, men de mere mundæne applikationer har jeg endnu ikke set eksempler på.
#15 - Prisen på SMP systemer har længe været i en pris der er til at betale. Jeg købte mit første dual bundkort i 97-98. Jeg købte på den tid det mest avancerede bundkort i handelen (Asus et eller andet med SCSI Raid og mange andre ørkesløse finesser). Det kostede mig den nette sum af 4200,00 gode danske kroner. Ja, det var mange penge dengang og det er det stadig, men man kunne også få bundkort til det halve (SCSI var den primære årsag til prishoppet), dvs. ca. 2000,00 kr. hvilket mig bekendt ikke er en helt hen i vejret pris på et bundkort den dag i dag. Allerede i sensommeren 1998 kom MSI eller Tyan med et dual bundkort til under 1500,00 kr. Så prismæssigt kan jeg ikke se at udviklingen af SMP skulle have været en hindring.
SMP har været fremme længe og understøttelsen fra den mest populære platform har også været der længe (siden NT 4.0), så det undrer mig en smule at udviklingen har stået så stille. 7 år er en evighed i computerindustrien. Vi er gået fra VLBUS til ISA til eISA til PCI 1.0 2.0 til AGP 2x 4x 8x til PCIe på den tid.
Det skorter jo heller ikke på innovative sjæle og folk med visioner, så jeg må selv konkludere det med, at Dual processor (senere Dual Core) bare ikke har appelleret til udviklerne på trods af at man på et tidligt tidspunkt har set at fremtiden ville betyde flere kerner frem for disse enkeltstående kogeplader.
Hvis halvdelen af ovenstående gav bare en smule mening, så er det i sig selv en succes.
#15 - Prisen på SMP systemer har længe været i en pris der er til at betale. Jeg købte mit første dual bundkort i 97-98. Jeg købte på den tid det mest avancerede bundkort i handelen (Asus et eller andet med SCSI Raid og mange andre ørkesløse finesser). Det kostede mig den nette sum af 4200,00 gode danske kroner. Ja, det var mange penge dengang og det er det stadig, men man kunne også få bundkort til det halve (SCSI var den primære årsag til prishoppet), dvs. ca. 2000,00 kr. hvilket mig bekendt ikke er en helt hen i vejret pris på et bundkort den dag i dag. Allerede i sensommeren 1998 kom MSI eller Tyan med et dual bundkort til under 1500,00 kr. Så prismæssigt kan jeg ikke se at udviklingen af SMP skulle have været en hindring.
SMP har været fremme længe og understøttelsen fra den mest populære platform har også været der længe (siden NT 4.0), så det undrer mig en smule at udviklingen har stået så stille. 7 år er en evighed i computerindustrien. Vi er gået fra VLBUS til ISA til eISA til PCI 1.0 2.0 til AGP 2x 4x 8x til PCIe på den tid.
Det skorter jo heller ikke på innovative sjæle og folk med visioner, så jeg må selv konkludere det med, at Dual processor (senere Dual Core) bare ikke har appelleret til udviklerne på trods af at man på et tidligt tidspunkt har set at fremtiden ville betyde flere kerner frem for disse enkeltstående kogeplader.
Hvis halvdelen af ovenstående gav bare en smule mening, så er det i sig selv en succes.
#19
Nej, okay. Tak for at pointere det åbenlyse.
Når vi snakker servere, så er det jo ikke en linær opgave de skal løse - men en parralel. De skal konstant modtage requests og afsende responses. Hvis jeg sætter MySQL og Apache til at spawne 40 tråde af sig selv hver, så skal de nok finde ud af hvordan det hele kommer til at virke best! De har hver deres eget kontrolprogram som sørger for at videresende requests til den mindst travle node. At have en 80-kerne CPU på en server der driver et stort website (Bare for eksempel) ville være genialt. Bare forestil dig hvor meget volumen du vil kunne trække!
Nej, okay. Tak for at pointere det åbenlyse.
Når vi snakker servere, så er det jo ikke en linær opgave de skal løse - men en parralel. De skal konstant modtage requests og afsende responses. Hvis jeg sætter MySQL og Apache til at spawne 40 tråde af sig selv hver, så skal de nok finde ud af hvordan det hele kommer til at virke best! De har hver deres eget kontrolprogram som sørger for at videresende requests til den mindst travle node. At have en 80-kerne CPU på en server der driver et stort website (Bare for eksempel) ville være genialt. Bare forestil dig hvor meget volumen du vil kunne trække!
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