mboost-dp1
Advanced Micro Devices, Inc.
Det er bare surt at så mange programmer er takseret efter hvor mange kerne en licens er tilladt at bruge.
Et meget godt eksempel er det program, RealFlow, som vi på mit arbejde bruger til at udvikle simulationer:
Full license for 2 CPU 2.000 €
Full license for 4 CPU 2.500 €
Full license for 8 CPU 3.300 €
Full license for 16 CPU 4.800 €
For hvad? Det er det samme program der kører, eneste forskel er bare hvor vidt man kan udnytte 2,4,8 eller 16 kerner... Suk...
Et meget godt eksempel er det program, RealFlow, som vi på mit arbejde bruger til at udvikle simulationer:
Full license for 2 CPU 2.000 €
Full license for 4 CPU 2.500 €
Full license for 8 CPU 3.300 €
Full license for 16 CPU 4.800 €
For hvad? Det er det samme program der kører, eneste forskel er bare hvor vidt man kan udnytte 2,4,8 eller 16 kerner... Suk...
Det ser da allerede interessant ud fra en udviklers synspunkt, med deres parallel fx library til .NET .
Det gør det noget lettere at lave programmer som udnytter flere kerner/processorer.
Det gør det noget lettere at lave programmer som udnytter flere kerner/processorer.
#8
Der er ikke nogen som venter 5 år. Der har været forsket i emnet ihvertfald siden 80'erne. Både kommercielt og på universiteterne. Nu har 2 specifikke firmaer MS og Intel så indgået en aftale om at sponsorere noget forskning på 2 specifikke universiteter de næste 5 år. De vil så forhåbentligt levere nogle gode ideer der kan bruges af firmaerne om 5-10 år. De ting som der kommer på gaden idag blev startet som forskning for 5-10 år siden.
Der er ikke nogen som venter 5 år. Der har været forsket i emnet ihvertfald siden 80'erne. Både kommercielt og på universiteterne. Nu har 2 specifikke firmaer MS og Intel så indgået en aftale om at sponsorere noget forskning på 2 specifikke universiteter de næste 5 år. De vil så forhåbentligt levere nogle gode ideer der kan bruges af firmaerne om 5-10 år. De ting som der kommer på gaden idag blev startet som forskning for 5-10 år siden.
Jeg er ret sikker på, at der er nogle der undervurderer kompleksiteten af dette ret voldsomt.. Så lad nu være med at være så negative.
Nogen der er har nogle kvalificerede bud på hvad der bla. er problemerne?
Mit gæt (ukvalificeret)
Uddelegering af opgaver (via AI)
Adgang til data uden at forstyrre hinanden samt
intern kommunikation til videre bearbejdning.
Mit gæt (ukvalificeret)
Uddelegering af opgaver (via AI)
Adgang til data uden at forstyrre hinanden samt
intern kommunikation til videre bearbejdning.
#12
Nu er jeg langt fra ekspert i parallelisering.
Men de to grundliggende problem stillinger må være:
1) Programmøren skriver multi threaded kode.
Kunsten er her at lave programmerings sprog, compilere og
libraries som gør det nemt at lave massivt multithreaded apps
uden fejl.
2) Automatisk kørsel af singlethreaded kode i multiple threads.
Compiler (AOT eller JIT) eller hardware som automatisk
analyserer koden og paralleliserer den. Dette er absolut ikke
nemt for helt generel kode.
Nu er jeg langt fra ekspert i parallelisering.
Men de to grundliggende problem stillinger må være:
1) Programmøren skriver multi threaded kode.
Kunsten er her at lave programmerings sprog, compilere og
libraries som gør det nemt at lave massivt multithreaded apps
uden fejl.
2) Automatisk kørsel af singlethreaded kode i multiple threads.
Compiler (AOT eller JIT) eller hardware som automatisk
analyserer koden og paralleliserer den. Dette er absolut ikke
nemt for helt generel kode.
#13,
Multitrådet programmer kan du ikek nødvendigvis splitte ud over flere kerner, det kræver multi-process programmer.
En program kan bestå af en eller flere processer, og hver proces af en eller flere tråde.
Det der er vigtigt her, er at flere tråde i en process kan arbejde direkte med de samme variabler, og derfor skal have samme forståelse af hvilken værdi de givne variabler har. Mellem processer deles der ikke på samme måde adgang til variabler.
Problemet med at splitte en process op på flere kerner, er at de så skal sikre at alle tilgange til variabler sker under en mutex lock, så en cpu ikke tror der ligger værdi 'A' i variablen mens cpu 2 har skrevet 'B' i samme variable.
Man har ikke samme problem mellem multible processer, da kommunikationen imellem dem er mere i stil med netværks kommunikation.
Så arbejder man med flere kerner, skal man have en måde at skille et program af, så det kan spredes ud, eller man skal have en måde at få kernerne til at arbejde på de samme registorer og cashe.
Multitrådet programmer kan du ikek nødvendigvis splitte ud over flere kerner, det kræver multi-process programmer.
En program kan bestå af en eller flere processer, og hver proces af en eller flere tråde.
Det der er vigtigt her, er at flere tråde i en process kan arbejde direkte med de samme variabler, og derfor skal have samme forståelse af hvilken værdi de givne variabler har. Mellem processer deles der ikke på samme måde adgang til variabler.
Problemet med at splitte en process op på flere kerner, er at de så skal sikre at alle tilgange til variabler sker under en mutex lock, så en cpu ikke tror der ligger værdi 'A' i variablen mens cpu 2 har skrevet 'B' i samme variable.
Man har ikke samme problem mellem multible processer, da kommunikationen imellem dem er mere i stil med netværks kommunikation.
Så arbejder man med flere kerner, skal man have en måde at skille et program af, så det kan spredes ud, eller man skal have en måde at få kernerne til at arbejde på de samme registorer og cashe.
#14
Jo - multithreaded programmer kan bruge flere kerner. Forudsat at det er kernel threads - som alle nyere styre systemer understøtter.
Processer kan principielt også dele memory (shared memory eller global memory) og har så samme synkroniserings problemer som threads, men det er dog sjældent at det bruges.
Jo - multithreaded programmer kan bruge flere kerner. Forudsat at det er kernel threads - som alle nyere styre systemer understøtter.
Processer kan principielt også dele memory (shared memory eller global memory) og har så samme synkroniserings problemer som threads, men det er dog sjældent at det bruges.
nåh, kiggede lige på wiki da det var hurtigere end at finde noget brugbart i min gamle bøger..
Det ser ud til at dine kernel threads, "bare" er seperate processor, og det er derfor de kan splittes ud. De er godt nok ikke fulde processer, men en light-weight process, og ud fra hvad jeg lige kan læse mig til, så skal et program designes til at bruge kernel threads/LW-processes.
Det ser ud til at dine kernel threads, "bare" er seperate processor, og det er derfor de kan splittes ud. De er godt nok ikke fulde processer, men en light-weight process, og ud fra hvad jeg lige kan læse mig til, så skal et program designes til at bruge kernel threads/LW-processes.
#17
Som det også fremgår af artiklen er der væsentligt forskel på processer og threads. Processer har forskellig addresse space - threads har samme address space.
En applikation skal designes til at anvende threads. Om det er kernel eller user threads bør være usynligt for applikationen. Faktisk skal man tænke sig mere om hvis man bruger user threads, fordi en blocking operation kan blocke alle tråde.
Som det også fremgår af artiklen er der væsentligt forskel på processer og threads. Processer har forskellig addresse space - threads har samme address space.
En applikation skal designes til at anvende threads. Om det er kernel eller user threads bør være usynligt for applikationen. Faktisk skal man tænke sig mere om hvis man bruger user threads, fordi en blocking operation kan blocke alle tråde.
#19
Det er muligt at detecte antal sockets, antal cores og antal logical processors fra software.
For dem der har Win Vista eller Win 2008 er det WMI Win32_Processor NumberOfCores og NumberOfLogicalProcessors.
Jeg har ikke den fjerneste anelse om de bruger den info til noget.
I nogle tilfælde kunne det give god mening, hvis diverse Lx cache ikke er delt mellem alle logical processors.
Så OS kan have grund til at udnytte den information.
Jeg har ikke fantasi til at forestille mig at en normal applikation skulle kunne bruge informationen til noget.
Det er muligt at detecte antal sockets, antal cores og antal logical processors fra software.
For dem der har Win Vista eller Win 2008 er det WMI Win32_Processor NumberOfCores og NumberOfLogicalProcessors.
Jeg har ikke den fjerneste anelse om de bruger den info til noget.
I nogle tilfælde kunne det give god mening, hvis diverse Lx cache ikke er delt mellem alle logical processors.
Så OS kan have grund til at udnytte den information.
Jeg har ikke fantasi til at forestille mig at en normal applikation skulle kunne bruge informationen til noget.
#3 din måde at sige det på er øhh lidt !?!?!. men ja jeg har gået og tænkt det samme...
hvad nu hvis de lavede en chip på bundkortet der kunne mærke instruktioner og sende dem til div. kerner for derefter at samle det hele igen når det kommer ud af kernerne igen...
har faktisk ingen forstand på hvad jeg snakker om så ret mig endelig.
men er det ikke en ide at fjerne det med at have et program til at køre på flere kerner fra software siden helt.
hvad nu hvis de lavede en chip på bundkortet der kunne mærke instruktioner og sende dem til div. kerner for derefter at samle det hele igen når det kommer ud af kernerne igen...
har faktisk ingen forstand på hvad jeg snakker om så ret mig endelig.
men er det ikke en ide at fjerne det med at have et program til at køre på flere kerner fra software siden helt.
#20-21
I stand corrected.
Så kan jeg lære at læse *alle* detaljerne i /proc/cpuinfo :P
$ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 75
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 3800+
stepping : 2
cpu MHz : 1000.000
cache size : 512 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy
bogomips : 3621.50
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc
processor : 1
vendor_id : AuthenticAMD
cpu family : 15
model : 75
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 3800+
stepping : 2
cpu MHz : 1000.000
cache size : 512 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy
bogomips : 3621.50
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc
I stand corrected.
Så kan jeg lære at læse *alle* detaljerne i /proc/cpuinfo :P
$ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 75
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 3800+
stepping : 2
cpu MHz : 1000.000
cache size : 512 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy
bogomips : 3621.50
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc
processor : 1
vendor_id : AuthenticAMD
cpu family : 15
model : 75
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 3800+
stepping : 2
cpu MHz : 1000.000
cache size : 512 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy
bogomips : 3621.50
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc
Nogle af de største problemer er/var:
Adgang til hukommelsen. Hvis du har en værdi i den ene CPU's cache som ændres, så kan det være dette skal reflekteres og synkroniseres med de andre CPU'er. Det skaber ret meget synkronisering mellem CPU cacherne. Man kan selvfølgelig skrive direkte ned i hukommelsen, men det er ret langsomt i forhold til cache skrivninger.
Et andet problem er at ret få programmeringsprog IKKE understøtter rigtig multithreading. Java gør det fra version 1.5 (de lavede en matematisk baseret memory model), .NET mener jeg gør det fra version 2.0. C++ standarden kender IKKE til begrebet tråde. Derfor kan en standard compliant compiler uden videre optimere read og write operationer i din kode med det resultat af dine locks osv bliver ignoreret. Husk at win32 tråde eller posix tråde blot er libraries. De har intet med C++ sproget at gøre. En "løsning" er at man enten slår optimering fra (hvilket man nok ikke har lyst til) eller at man skriver noget assembler snask (hvilket man nok heller ikke har lyst til).
Og selvf. hvis man bruger en compiler der er skrevet specifikt til et dual-cpu system (som f.eks. Microsofts VC++ Itanium compiler) så har man ikke de problemer. Det er netop årsagen til at en Visual Studio VC installation fordobles hvis man tilvælger Itanium compileren...det er nemlig en helt ny, selvstændig compiler.
Adgang til hukommelsen. Hvis du har en værdi i den ene CPU's cache som ændres, så kan det være dette skal reflekteres og synkroniseres med de andre CPU'er. Det skaber ret meget synkronisering mellem CPU cacherne. Man kan selvfølgelig skrive direkte ned i hukommelsen, men det er ret langsomt i forhold til cache skrivninger.
Et andet problem er at ret få programmeringsprog IKKE understøtter rigtig multithreading. Java gør det fra version 1.5 (de lavede en matematisk baseret memory model), .NET mener jeg gør det fra version 2.0. C++ standarden kender IKKE til begrebet tråde. Derfor kan en standard compliant compiler uden videre optimere read og write operationer i din kode med det resultat af dine locks osv bliver ignoreret. Husk at win32 tråde eller posix tråde blot er libraries. De har intet med C++ sproget at gøre. En "løsning" er at man enten slår optimering fra (hvilket man nok ikke har lyst til) eller at man skriver noget assembler snask (hvilket man nok heller ikke har lyst til).
Og selvf. hvis man bruger en compiler der er skrevet specifikt til et dual-cpu system (som f.eks. Microsofts VC++ Itanium compiler) så har man ikke de problemer. Det er netop årsagen til at en Visual Studio VC installation fordobles hvis man tilvælger Itanium compileren...det er nemlig en helt ny, selvstændig compiler.
#25
Java har haft fuld multi threading support siden version 1.0.
Med en memory model. Men de ændrede memory modellen i 1.5 for at slippe af med nogle uhensigtsmæssigheder.
.NET har også en memory model og har altid haft det. .NET's memory model lider lidt under at .NET verdenen er meget x86 fokuseret. Der er eksempler på kode som ikke overholde .NET memory modellen men overholder x86 memory modellen.
Java har haft fuld multi threading support siden version 1.0.
Med en memory model. Men de ændrede memory modellen i 1.5 for at slippe af med nogle uhensigtsmæssigheder.
.NET har også en memory model og har altid haft det. .NET's memory model lider lidt under at .NET verdenen er meget x86 fokuseret. Der er eksempler på kode som ikke overholde .NET memory modellen men overholder x86 memory modellen.
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