mboost-dp1
AMD
Det lyder da egentlig smart! Også fordi man så kan håbe på at software som ikke er optimeret til flere kerner vil drage fordel af CPUens 2 kerner alligevel...
Desuden har man den fordel at det ikke er en scheduler i OSet som skal fordele processerne/trådene mellem kernerne, men hardwaren selv, og dermed sparer vi det CPU overhead som systemer med flere CPUer har...
Thumbs up AMD!
Desuden har man den fordel at det ikke er en scheduler i OSet som skal fordele processerne/trådene mellem kernerne, men hardwaren selv, og dermed sparer vi det CPU overhead som systemer med flere CPUer har...
Thumbs up AMD!
#1
thumbs up - og dog?
på den måde tror systemet jo kun der kan køres en tråd ad gangen - det skulle undre mig meget om det på flere områder ikke vil være mere hensigtsmæssigt at fortælle scheduleren at der rent faktisk kunne afvikles flere tråde.. ellers kunne det vel ende ligesom nu hvor maskiner der ikke understøtter smp kan virke som om de ender i et lock-up hvis en enkelt tråd bruger alle ressourcerne.
thumbs up - og dog?
på den måde tror systemet jo kun der kan køres en tråd ad gangen - det skulle undre mig meget om det på flere områder ikke vil være mere hensigtsmæssigt at fortælle scheduleren at der rent faktisk kunne afvikles flere tråde.. ellers kunne det vel ende ligesom nu hvor maskiner der ikke understøtter smp kan virke som om de ender i et lock-up hvis en enkelt tråd bruger alle ressourcerne.
#1
Lige til du indser, at det betyder at alle de forskellige linjer kode i dit program bliver udført på et tidspunkt uafhængig af hinanden. Det er noget lort for at sige det mildt. Jeg håber AMD har fundet løsningen på dette problem men jeg tror absolut ikke det er bagud kombitabelt.
Lige til du indser, at det betyder at alle de forskellige linjer kode i dit program bliver udført på et tidspunkt uafhængig af hinanden. Det er noget lort for at sige det mildt. Jeg håber AMD har fundet løsningen på dette problem men jeg tror absolut ikke det er bagud kombitabelt.
Hvis de kan garantere at man ikke får synkronitetsproblemer eller race-condition ditto, så er det her jo guds gave til udviklerne.
Alle de gamle programmer skal ikke kodes om for at udnytte flerkerne-CPU'er og overgangsfase mellem enkelt- og flerkerne-CPU'er hvor potentialet ikke rigtigt udnyttes (der hvor vi sådan set står nu) vil blive kortere.
Men som #2 siger, så ville der sikkert også være en god pointe i at have muligheden for at tilgå de enkelte kerner i CPU'en direkte og dermed selv have indflydelse på schedulerens håndtering.
Alle de gamle programmer skal ikke kodes om for at udnytte flerkerne-CPU'er og overgangsfase mellem enkelt- og flerkerne-CPU'er hvor potentialet ikke rigtigt udnyttes (der hvor vi sådan set står nu) vil blive kortere.
Men som #2 siger, så ville der sikkert også være en god pointe i at have muligheden for at tilgå de enkelte kerner i CPU'en direkte og dermed selv have indflydelse på schedulerens håndtering.
Jeg tror sagtens man kan lade hardwaren styre fordeling af traade, kan ikke lige sige hvordan, men det jo et ret nyt felt, saa bare fordi man ikke kan ifoelge boegerne betyder det jo ikke at det umuligt.
Jeg enig i hvad #5 siger, hvis AMD kan garantere at traade ikke laver race condi eller deadlock/starvation er dette en fed loesning, og endnu federe hvis det kan scaleres op til flere end 2 CPU'er
Jeg enig i hvad #5 siger, hvis AMD kan garantere at traade ikke laver race condi eller deadlock/starvation er dette en fed loesning, og endnu federe hvis det kan scaleres op til flere end 2 CPU'er
Lyder ret genialt. Vi må jo nok se i øjnene, at alle programmer aldrig vil blive optimeret til flere processorer. Det er simpelt hen ALT for svært.
Programmer, der kan se en reel udnyttelse af flere tråde kan jo sagtens gøre det, men nu får vi altså bare også udnyttelse af flere processorer i "normale" programmer.
Programmer, der kan se en reel udnyttelse af flere tråde kan jo sagtens gøre det, men nu får vi altså bare også udnyttelse af flere processorer i "normale" programmer.
Som jeg læser den originale Franske nyhed, så er benævnelsen "omvendt hyperthreading" måske lidt overdrevet. Så vidt jeg kan tyde så er der tale om at:
- Gøre pipelinen breddere (ligesom skete ved hyperthreading)
- Udvide crossbar-switchen
- Indføre delt cache
...resten må være spekulation og over-fortolkning. Men jeg er skeptisk! Hyperthreading deler en tråd op (efter anmodning fra programmøren) og schedulerer på én kerne. Men omvendt-hyperthreading skulle angiveligt gøre det muligt at dele en tråd op og scedulere på flere kerner. Hvis hyperthreading og out-of-order-execution er problematisk så er det da ingenting i sammenligning med såkaldt omvendt hyperthreading. Intel har brugt mia. af research-$ på netop dette område, så jeg er bange for der er tale om en and.
- Gøre pipelinen breddere (ligesom skete ved hyperthreading)
- Udvide crossbar-switchen
- Indføre delt cache
...resten må være spekulation og over-fortolkning. Men jeg er skeptisk! Hyperthreading deler en tråd op (efter anmodning fra programmøren) og schedulerer på én kerne. Men omvendt-hyperthreading skulle angiveligt gøre det muligt at dele en tråd op og scedulere på flere kerner. Hvis hyperthreading og out-of-order-execution er problematisk så er det da ingenting i sammenligning med såkaldt omvendt hyperthreading. Intel har brugt mia. af research-$ på netop dette område, så jeg er bange for der er tale om en and.
#1
Schedulering af x86 cpuer har foregået på OS niveau lige siden 386'eren hvor det blev muligt seperere enkelte programmers tildelte hukkomelse. Det er ikke noget der er kommet med duel core/hyper threading etc.
Der er en vigtig forskel på processer og tråde. Hvilken proces der får køretid vil fortsat afgøres af OS'ets dispatcher. Hvordan de enkelte tråde overordnet håndteres er på nuværende tidspunkt op til programmøren.
Jeg er som #8 lidt skeptisk. Det er svært på baggrund af googeloversættelsen præcist at vide hvad der menes men én tråd kan som udgangspunkt ikke deles mellem to cores.. i hvertfald ikke med nogen særlig effektivitet. Ordenlige programører benytter sig jo netop af tråde hvor det giver mening, hvilket betyder at koden er ret sekventiel hvorfor det er svært at dele det op. I værste fald vil der gå mere tid med a synkronisere end der spares.
Schedulering af x86 cpuer har foregået på OS niveau lige siden 386'eren hvor det blev muligt seperere enkelte programmers tildelte hukkomelse. Det er ikke noget der er kommet med duel core/hyper threading etc.
Der er en vigtig forskel på processer og tråde. Hvilken proces der får køretid vil fortsat afgøres af OS'ets dispatcher. Hvordan de enkelte tråde overordnet håndteres er på nuværende tidspunkt op til programmøren.
Jeg er som #8 lidt skeptisk. Det er svært på baggrund af googeloversættelsen præcist at vide hvad der menes men én tråd kan som udgangspunkt ikke deles mellem to cores.. i hvertfald ikke med nogen særlig effektivitet. Ordenlige programører benytter sig jo netop af tråde hvor det giver mening, hvilket betyder at koden er ret sekventiel hvorfor det er svært at dele det op. I værste fald vil der gå mere tid med a synkronisere end der spares.
#8 "Intel har brugt mia. af research-$ på netop dette område, så jeg er bange for der er tale om en and."
Jeg tror bare der er tale om en amd og ikke end and :-)
Intel har også brugt masser af penge på research inden de lavede pentium 4 osv. og alligevel har AMD outperformed dem gang på gang...
#9 er godt klar over at skedulering altid har været en nødvendighed ved multitasking/threading...
min pointe var, at nogle af de opgaver som scheduleren på en multikerne maskine i dag brugere CPUen til at udføre, måske vil kunne udføres på hardwareniveau...
Jeg tror bare der er tale om en amd og ikke end and :-)
Intel har også brugt masser af penge på research inden de lavede pentium 4 osv. og alligevel har AMD outperformed dem gang på gang...
#9 er godt klar over at skedulering altid har været en nødvendighed ved multitasking/threading...
min pointe var, at nogle af de opgaver som scheduleren på en multikerne maskine i dag brugere CPUen til at udføre, måske vil kunne udføres på hardwareniveau...
Medmindre de laver dem lidt a la P4 (som er spekulativ osv, men opfører sig pænt) så får man store problemer med synkronisering.
Der er lavet forsøg, og ved en 8 (eller var det 16?) kerner, var kommunikationen mellem de forskellige chips så intensiv, at systemet performede dårligere end en almindelig desktop PC fra Aldi...
Der er lavet forsøg, og ved en 8 (eller var det 16?) kerner, var kommunikationen mellem de forskellige chips så intensiv, at systemet performede dårligere end en almindelig desktop PC fra Aldi...
Hmm, hvad kan det betyde for os der allerede har fået en X2?
Hvis disse cpuer får overhånd vil de fleste vil bare holde sig til singlethreads og vores X2'ere vil vel være så godt som ubrugelige så?
Multitasking er godt ja, men jeg er typen der spiller meget, og hvis alle spil bare holder sig til single så har jeg kun en cpu til rådighed.
Har tænkt på om det ikke kunne være muligt at emulere en X2 til at køre singletråd, via et externt program fx.. det burde da være muligt? Megasvært men ikke umuligt?
Hvis disse cpuer får overhånd vil de fleste vil bare holde sig til singlethreads og vores X2'ere vil vel være så godt som ubrugelige så?
Multitasking er godt ja, men jeg er typen der spiller meget, og hvis alle spil bare holder sig til single så har jeg kun en cpu til rådighed.
Har tænkt på om det ikke kunne være muligt at emulere en X2 til at køre singletråd, via et externt program fx.. det burde da være muligt? Megasvært men ikke umuligt?
Hvorfor kode i tråde, når det må være processorens opgave at fordele arbejdet!
Hvorfor ikke lade den ene cpu tage sig af alle 0'erne og så den anden tage sig af 1'erne :D hehehe så kan de mødes på midten!
Hvorfor ikke lade den ene cpu tage sig af alle 0'erne og så den anden tage sig af 1'erne :D hehehe så kan de mødes på midten!
#14
Selvom den sidste del var en joke, så går jeg ud fra at den første del er seriøs.
Fordi det netop ikke er CPU'ens opgave, det er derimod det en scheduler har til opgave.
CPU'ens opgave er udelukkende at gøre det den for besked på, af scheduleren.
Selvom den sidste del var en joke, så går jeg ud fra at den første del er seriøs.
Fordi det netop ikke er CPU'ens opgave, det er derimod det en scheduler har til opgave.
CPU'ens opgave er udelukkende at gøre det den for besked på, af scheduleren.
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