mboost-dp1
unknown
Udmærket artikel der også kommer ind på at det nu ikke ligefrem bliver nemmere at skrive performance software, når to (eller flere) kerner skal dele og synkronisere data. Velkommen til alderen for (parallel) Service-Oriented Software Engineering.
#2:
Det er vel præcis smamme problem som med flere adskilte CPU'er, så det er jo ikke fordi at det er noget nyt.
Spil undtaget bruger 95% af den software der er idag alligevel ikke særligt meget cpu, så der vil ikke være nogen grund til at understøtte 2 cpu'er - og det meste af de resterende 5% understøtter allerede flere CPU'er.
På spilsiden vil der måske være lidt - men mon ikke det i de fleste tilfælde vil være at spawne et par tråde til AI'en.
Så alt i alt tror jeg ikke det kommer til at betyde særligt meget for udvikling :)
Det er vel præcis smamme problem som med flere adskilte CPU'er, så det er jo ikke fordi at det er noget nyt.
Spil undtaget bruger 95% af den software der er idag alligevel ikke særligt meget cpu, så der vil ikke være nogen grund til at understøtte 2 cpu'er - og det meste af de resterende 5% understøtter allerede flere CPU'er.
På spilsiden vil der måske være lidt - men mon ikke det i de fleste tilfælde vil være at spawne et par tråde til AI'en.
Så alt i alt tror jeg ikke det kommer til at betyde særligt meget for udvikling :)
Har jeg misforstået noget, eller er hele dual-core konceptet et udtryk for, at man (processorfirmaerne) er ved at nå loftet for hvor hurtig (ydelsesmæssigt) en processor kan laves med nuværende teknologi og derfor går i panik? Jeg undrer mig lidt over, hvad vi skal med to kerner i desktop-systemer...
Nu har jeg kun lige skimtet artiklen igennem, men hvordan er strømforbruget ?
Bruger Dualcore ligeså meget strøm som en alm cpu, af samme hastighed, bruger den dobbelt så meget..
Hvis der er strømbesparelse at hente, er det i mine øjne et godt tegn.
Så er jeg mere eller mindre ligeglad med om jeg skal vente 2 sekunder ekstra, på at et program/spil startes op.
Bruger Dualcore ligeså meget strøm som en alm cpu, af samme hastighed, bruger den dobbelt så meget..
Hvis der er strømbesparelse at hente, er det i mine øjne et godt tegn.
Så er jeg mere eller mindre ligeglad med om jeg skal vente 2 sekunder ekstra, på at et program/spil startes op.
#6 set ud fra min elektroniske viden må to kerner med halv hastighed give det samme som en med fuld.
men da der er nogle regler i elektronik der gør at når man halvere noget bliver effekten en fjerdedel. så i teorien ender du med to kerner der bruger to fjerdedele af effekten på den med en kerne og med ca. samme ydelse ;-)
men teorien holder garanteret ikke helt.. men jeg tror der er både ydelse og besparelse at hente..
men da der er nogle regler i elektronik der gør at når man halvere noget bliver effekten en fjerdedel. så i teorien ender du med to kerner der bruger to fjerdedele af effekten på den med en kerne og med ca. samme ydelse ;-)
men teorien holder garanteret ikke helt.. men jeg tror der er både ydelse og besparelse at hente..
#3 Jo men nu er der ikke mange alm. programmer der er skrevet til at udnytte 2 CPU'er. Implementeringen af et stykke software behøver ikke at ændre sig ikke når en CPU går fra 1GHz til 2GHz, men skal 2 1GHz CPU'er klare samme opgave som én 2GHz CPU så sætter det altså betydelige krav til OS, compiler og ikke mindst udvikleren. Der er en grund til at man i Windows kan linke til tråd-sikre og ikke-tråd-sikre libraries; nemlig performance.
#5 Du har forstået det korrekt. Skønt man ikke taler om "muren" endnu, så er problemerne med at flytte litografi-processen til 90nm og 65nm så svær at producenterne simpelthen har set sig nødsaget til at gå andre veje.
#5 Du har forstået det korrekt. Skønt man ikke taler om "muren" endnu, så er problemerne med at flytte litografi-processen til 90nm og 65nm så svær at producenterne simpelthen har set sig nødsaget til at gå andre veje.
#6
Der står i artiklen at Intel implementerer dualcore i workstations med 2*Prescott. Det siger måske lidt :)
Den siger også at Intels dualcore til laptop, skal holdes under 40W i max effektforbrug for CPU. Der står at intel vil implementere en løsning, således at en af kernene kan slukkes når der ikke er brug for den. Det betyder vel at strømforbruget forbliver som i dag, for laptops.
Der står i artiklen at Intel implementerer dualcore i workstations med 2*Prescott. Det siger måske lidt :)
Den siger også at Intels dualcore til laptop, skal holdes under 40W i max effektforbrug for CPU. Der står at intel vil implementere en løsning, således at en af kernene kan slukkes når der ikke er brug for den. Det betyder vel at strømforbruget forbliver som i dag, for laptops.
#8:
Du fanger ikke min pointe.
Det færreste desktop software har brug for en 2GHz CPU ELLER 2 CPU'ere :)
Hvad vil flere cores hjælpe dig i din email-klient, browser, spreadsheet og tekstbehandlings program?
Så helt konkret - HVILKE programmer er det du mener udvikleren(mig) skal tage højde for flere kerner?
(Stadig undtaget spil, som jeg har beskrevet en simpel løsning på)
Du fanger ikke min pointe.
Det færreste desktop software har brug for en 2GHz CPU ELLER 2 CPU'ere :)
Hvad vil flere cores hjælpe dig i din email-klient, browser, spreadsheet og tekstbehandlings program?
Så helt konkret - HVILKE programmer er det du mener udvikleren(mig) skal tage højde for flere kerner?
(Stadig undtaget spil, som jeg har beskrevet en simpel løsning på)
Går vel ud fra at alle Divde an Conquor algoritmer kan bruges fornuftigt på flere kerner. Dvs søgning og når ting skal sorteres bliver vel hurtigere. Men ved søgning på harddisk er det nok der flaskehalsen ligger, og ikke på cpu'en som skal bearbejde dataen......
Jeg ser da frem til at lege med sådan en, når de kommer ud. (og bliver til at betale)
Jeg kan nu godt lide at have lidt ekstra kubik.
Specielt når jeg skal compile OOo... ;) (Ekstremt eksempel)
At kompilere 210Mb* kildekode, tager *lidt* tid... ;) (I pakket form)
Hvad de fleste dog glemmer er, at der tit kan være væsentligt større flaskehalse end ens CPU.
Ens harddisk kan også være en flaskehals.
Jeg kan nu godt lide at have lidt ekstra kubik.
Specielt når jeg skal compile OOo... ;) (Ekstremt eksempel)
At kompilere 210Mb* kildekode, tager *lidt* tid... ;) (I pakket form)
Hvad de fleste dog glemmer er, at der tit kan være væsentligt større flaskehalse end ens CPU.
Ens harddisk kan også være en flaskehals.
#9 LOL fedt nok, en dual core CPU som kun bruger den ene ved alm. brug... SKOD
#10 tror måske du misforstår det.
selv om en operation som i din task manager kun står til at benytte 10% CPU, ikke har behov for mere CPU kraft, kan den stadig udføres hurtigere med flere CPUer.
Når man f.eks. surfer på nettet, er det ikke meget CPU-kraft man bruger, heller ikke når man f.eks. downloader eller åbner/lukker browseren
men hvis den ene CPU tog sig at OS-specifikke opgaver, samt diverse netværksprotokoller, mens den andne CPU tog sig af rendering af websiderne osv. ville man kunne klare den opgave det er at fremvise en webside, på et kortere stykke tid. i eksemplet med webbrowsing her, er det måske 0,1 sekund på moderne computere, men det er princippet der er interessant
ovenstående eksempel kræver selvfølgelig at softwaren og OS er skrevet så det fordeler arbejdet fornuftigt
#10 tror måske du misforstår det.
selv om en operation som i din task manager kun står til at benytte 10% CPU, ikke har behov for mere CPU kraft, kan den stadig udføres hurtigere med flere CPUer.
Når man f.eks. surfer på nettet, er det ikke meget CPU-kraft man bruger, heller ikke når man f.eks. downloader eller åbner/lukker browseren
men hvis den ene CPU tog sig at OS-specifikke opgaver, samt diverse netværksprotokoller, mens den andne CPU tog sig af rendering af websiderne osv. ville man kunne klare den opgave det er at fremvise en webside, på et kortere stykke tid. i eksemplet med webbrowsing her, er det måske 0,1 sekund på moderne computere, men det er princippet der er interessant
ovenstående eksempel kræver selvfølgelig at softwaren og OS er skrevet så det fordeler arbejdet fornuftigt
#14
I mine ører lyder det nu som en rigtig dejlig feature på mobile cpu'er, hvor vi jo ofte gerne vil spare lidt på strømmen.
Vi kan vel blive enige om at små programmer der bruger forsvindende få cycles og spenderer det meste af deres liv på at vente på I/O, ikke kan få nogen nævneværdig glæde af to cpu'er, udover at vi kan dele multiple af dem ud på cpu'erne (uden at ændre noget i programmerne). Hvorimod spil kan være bundløse cycle-spisere.
#9 LOL fedt nok, en dual core CPU som kun bruger den ene ved alm. brug... SKOD
I mine ører lyder det nu som en rigtig dejlig feature på mobile cpu'er, hvor vi jo ofte gerne vil spare lidt på strømmen.
#10 tror måske du misforstår det.
selv om en operation som i din task manager kun står til at benytte 10% CPU, ikke har behov for mere CPU kraft, kan den stadig udføres hurtigere med flere CPUer.
Vi kan vel blive enige om at små programmer der bruger forsvindende få cycles og spenderer det meste af deres liv på at vente på I/O, ikke kan få nogen nævneværdig glæde af to cpu'er, udover at vi kan dele multiple af dem ud på cpu'erne (uden at ændre noget i programmerne). Hvorimod spil kan være bundløse cycle-spisere.
#15 alting udvikler sig... også softwaren.
hvis softwarekravene ikke var steget, ville man kunne starte sit tekstbehandslingsprogram, skrive, gemme, printe osv. flere tusinde gange hurtigere i dag end man kunne på den første IBM PC...
men så finder man jo lige på lidt mere og lidt mere, der alt sammen tager CPU kraft... tænk bare på Windows XP og NT4.0, det er i bund og grund samme system, men 5 års forskel har bare sat sine spor, hvilket også ses i systemkravene.
men vi er enige om at den ekstra processorkraft har minimal betydning, ved alm. applikationer, men den har dog en betydning
hvis softwarekravene ikke var steget, ville man kunne starte sit tekstbehandslingsprogram, skrive, gemme, printe osv. flere tusinde gange hurtigere i dag end man kunne på den første IBM PC...
men så finder man jo lige på lidt mere og lidt mere, der alt sammen tager CPU kraft... tænk bare på Windows XP og NT4.0, det er i bund og grund samme system, men 5 års forskel har bare sat sine spor, hvilket også ses i systemkravene.
men vi er enige om at den ekstra processorkraft har minimal betydning, ved alm. applikationer, men den har dog en betydning
#17 problemet med softwareudviklere har altid været, at jo flere ressourcer deres sofware har til rådighed, jo mindre tænker de på at optimere koden...
på samme måde, som man rydder mere op på sin HD, hvis man har begrænset plads, end man ville have gjort med en større disk...
så hvad enten man vil det eller ej, skal fremtidens programmer nok blive mere krævende, især når CPU kraften næsten bliver fordoblet i form af dual core til desktops
på samme måde, som man rydder mere op på sin HD, hvis man har begrænset plads, end man ville have gjort med en større disk...
så hvad enten man vil det eller ej, skal fremtidens programmer nok blive mere krævende, især når CPU kraften næsten bliver fordoblet i form af dual core til desktops
#18 - Ja hvis det bliver et problem, så er det jo et spørgsmål om hvad der har bedst cost/benefit: optimere sit "single-core" program, eller optimere det til multi-core. Men tror nu vi skal vente længe eller udviklerne skal blive meget sløsede, før Messengers 50 sek cputid på denne 600MHz P3 efter noget der ligner 12 timers drift, giver anledning til at begive sig ud i dual-core optimeringer. :)
Chris Rijk fra Ace's Hardware har gennem det sidste års tid skrevet tre artikler om 'Thread-level parallelism' og CMP/CMT:
http://www.aceshardware.com/read.jsp?id=60000312
http://www.aceshardware.com/read.jsp?id=65000292
http://www.aceshardware.com/read.jsp?id=65000333
Han kommer blandt andet ind på at man kan reducere strømforbruget ved at lade de enkelte kerner dele om de dele af CPU'en der sjældent bliver brugt, som for eksempel FPU'en.
http://www.aceshardware.com/read.jsp?id=60000312
http://www.aceshardware.com/read.jsp?id=65000292
http://www.aceshardware.com/read.jsp?id=65000333
Han kommer blandt andet ind på at man kan reducere strømforbruget ved at lade de enkelte kerner dele om de dele af CPU'en der sjældent bliver brugt, som for eksempel FPU'en.
Lidt info om kommende dual cores fra [H]:
"AMD & Intel Dual Core Update:
Information on dual core systems is getting a bit more solid now days. AMD is telling partners in Taiwan that dual core AMD Athlon 64 processor will launch in Q3'05. As expected, it will follow the same infrastructure as a their single core 939-pin CPUs. While not tested, this tells us that we should be able to simply upgrade a current 939-pin motherboard with a AMD dual core CPU. The first AMD dual core CPUs will utilize a DDR1 memory controller, but will later transition to DDR2. Each core will also have its own L2 cache. As for gamers, AMD admits that this segment of the market will be best served with a maximum frequency, single core solution until 2006. AMD's single and dual core CPUs will coexist in the market throughout 2006.
Intel's first dual core processor, that has yet to be branded, is also currently scheduled to appear in Q3'05 and will possibly come in 2.8GHz, 3GHz, and 3.2GHz speed bins. The Intel 90nm Smithfield cores (think 2X Prescotts), much like the AMD solution, will have a dedicated 1MB L2 cache for each core. The Intel dual core CPUs will debut in a LGA 775 socket configuration and carry a 800MHz bus. A platform transition will take place as a new northbridge chipset will be needed for Intel dual core processor support. The dual core supporting 955X (codenamed Glenwood) and 945G/P (codenamed Lakeport) northbridges should launch in Q2'05 and will both have support for DDR2-667 as well. These new processors will have "EM64T" support as well and are timed to be launched around the arrival of Microsoft’s Windows XP Pro x64."
Jeg finder det interessant, at artiklen snakker om muligheder for bedre virtualisering. Det er en ting som altid har været besværligt med Intel arkitekturen. I nogen udstrækning har virtualisering været muligt, det har bare altid lidt af et problem, nemlig at den virtuelle arkitektur ikke har været helt den samme som den underliggende arkitektur. Jeg frygter at disse nye virtualiseringstiltag kommer til at lide af samme problem som alle de tidligere. Vi kommer nok endnu en gang til at se en ny arkitektur, som kan virtualisere en tidligere arkitektur men som ikke kan virtualisere sig selv. Det næste vi ser er så et OS, som kan køre på den fysiske maskine og i en eller anden udstrækning udnytte nogle af de nye muligheder. Men i samme øjeblik sådan et OS kommer ind i billedet har man ikke mere fordelene ved virtualisering. Det er selvfølgelig ikke nemt både at skulle lave en arkitektur som er perfekt til at virtualisere sig selv, og samtidig skal være bagudkompatibel, men det burde være muligt. Virtualisering har i sig selv intet med multicore at gøre. Den eneste grund til at begge dele nævnes i samme artikel er, at det er to forskellige forbedringer producenterne kigger på nu de har problemer med at presse klokfrekvenserne højere op.
Det fremgår af artiklen, at de første dual core CPUer kan forventes at have seperate caches til de to CPUer. Det er naturligvis den nemmeste arkitektur at implementere, men ikke nogen ubetinget fordel. Skal begge cores benytte de samme data fra RAM er det ikke godt, hvis de begge skal hente det fra RAMen. Har den ene core først hentet noget fra RAM vil det helt klart være en fordel, hvis den anden core kan hente det fra cache i stedet for RAM. Men siden der alligevel skal kommunikeres mellem caches for at sikre coherency, så kan det være der faktisk kan overføres data mellem caches uden RAM tilgang. Delt cache bliver naturligvis mere compliceret. Specielt er man nødt til at overveje problematikken omkring monopolisering af cachen. Hvis den ene core kan fylde cachen op med sine egne data kan det gå ud over den anden cores performance. Men hvis den ene core er idle kan det til gengæld være en fordel, hvis den anden core får lov at udnytte hele cachen. Endeligt kan der være situationer, hvor en core kan opnå så meget ekstra performance ved at monopolisere cachen, at det kan forsvares på trods af at den anden core sløves ned. Det gør sig gældende, hvis programmets working set har en størrelse, der ligger tæt på den totale cache.
Nogle stedder i artiklen benyttes betegnelsen EM64T. Jeg vil helst lade Intel være alene om at bruge den betegnelse, så kan alle vi andre give AMD den kredit de fortjener ved at benytte deres betegnelse om en teknologi, som Intel har "lånt" fra AMD. At Intel vælger at lave AMD64 kompatible CPUer ser jeg som et positivt træk, men jeg ville foretrække, at de samtidigt ville stå ved, at det er det, de gør.
Det nævnes også, at Intel vælger at slå HT fra i de første dual core CPUer. Der er sikkert en god grund til det, men den fremgår ikke af artiklen. Den kompleksitet, som opstår ved dual core HT, ligger i operativsystemet og ikke hardwaren. Det kræver altså ikke ekstra fysisk plads på chipen. I øvrigt er problematikken slet ikke ny, den har altid eksisteret i HT SMP systemer.
Det fremgår af artiklen, at de første dual core CPUer kan forventes at have seperate caches til de to CPUer. Det er naturligvis den nemmeste arkitektur at implementere, men ikke nogen ubetinget fordel. Skal begge cores benytte de samme data fra RAM er det ikke godt, hvis de begge skal hente det fra RAMen. Har den ene core først hentet noget fra RAM vil det helt klart være en fordel, hvis den anden core kan hente det fra cache i stedet for RAM. Men siden der alligevel skal kommunikeres mellem caches for at sikre coherency, så kan det være der faktisk kan overføres data mellem caches uden RAM tilgang. Delt cache bliver naturligvis mere compliceret. Specielt er man nødt til at overveje problematikken omkring monopolisering af cachen. Hvis den ene core kan fylde cachen op med sine egne data kan det gå ud over den anden cores performance. Men hvis den ene core er idle kan det til gengæld være en fordel, hvis den anden core får lov at udnytte hele cachen. Endeligt kan der være situationer, hvor en core kan opnå så meget ekstra performance ved at monopolisere cachen, at det kan forsvares på trods af at den anden core sløves ned. Det gør sig gældende, hvis programmets working set har en størrelse, der ligger tæt på den totale cache.
Nogle stedder i artiklen benyttes betegnelsen EM64T. Jeg vil helst lade Intel være alene om at bruge den betegnelse, så kan alle vi andre give AMD den kredit de fortjener ved at benytte deres betegnelse om en teknologi, som Intel har "lånt" fra AMD. At Intel vælger at lave AMD64 kompatible CPUer ser jeg som et positivt træk, men jeg ville foretrække, at de samtidigt ville stå ved, at det er det, de gør.
Det nævnes også, at Intel vælger at slå HT fra i de første dual core CPUer. Der er sikkert en god grund til det, men den fremgår ikke af artiklen. Den kompleksitet, som opstår ved dual core HT, ligger i operativsystemet og ikke hardwaren. Det kræver altså ikke ekstra fysisk plads på chipen. I øvrigt er problematikken slet ikke ny, den har altid eksisteret i HT SMP systemer.
#7
Så vidt jeg husker, så er strømforbruget for en digital kreds påvirket af følgende faktorer:
Clockfrekvens, lineært afhængig.
Spænding, kvadratisk afhængig.
Kapacitet, lineært afhængig. Kapacitet gives groft sagt ved antal transistorer.
Så en dual-core CPU ved halv hastighed vil bruge samme mængde strøm som den tilsvarende single-core CPU.
Så vidt jeg husker, så er strømforbruget for en digital kreds påvirket af følgende faktorer:
Clockfrekvens, lineært afhængig.
Spænding, kvadratisk afhængig.
Kapacitet, lineært afhængig. Kapacitet gives groft sagt ved antal transistorer.
Så en dual-core CPU ved halv hastighed vil bruge samme mængde strøm som den tilsvarende single-core CPU.
#24
De har helt sikkert slået den fra pga. eksisterende programmer med CPU-licenser.Det argument holder ikke. På HT systemer nummereres de logiske CPUer på en sådan måde, at hvis man bare bruger de første, så får man en logisk CPU fra hver fysisk CPU. Det problem du beskriver er ikke nyt. Problemet er ligesom det tidligere nævnte set før på HT SMP systemer, og problemet er allerede løst.
#24 effektforbruget på CPU er eksponentielt, når spændingen øges, mens det er proportionat med frekvensen.
grunden til at det er eksp. mht. spændingen, er fordi cpuen har en vis elektrisk modstand.
da antallet af ampere er = volt / ohm, vil antallet af ampere (strømstyrken) være proportional med spændingen
men da effekten er = amp*volt, vil en ændring på X volt betyde en ændring på X^2 watt
grunden til at det er eksp. mht. spændingen, er fordi cpuen har en vis elektrisk modstand.
da antallet af ampere er = volt / ohm, vil antallet af ampere (strømstyrken) være proportional med spændingen
men da effekten er = amp*volt, vil en ændring på X volt betyde en ændring på X^2 watt
bwah.. hvis der ikke snart sker noget drastisk vil alle software udviklere blive ved med at udvikle mere og mere systemkrævende software, hvor størstedelen bare er dårlig kodet, bare for at kunderne skal købe større og større hardware.. en uendelig pengemaskine.. se det er opensource virkelig løsningen på hvor software udviklerne ikke direkte har nogen andre hensigter med udviklingen end at det skal fungere ordenligt.
på den anden side er det da godt med noget udvikling ment på den måde at vi bliver klogere og nok engang skal finde ud af at udnytte vores viden ordentligt..
på den anden side er det da godt med noget udvikling ment på den måde at vi bliver klogere og nok engang skal finde ud af at udnytte vores viden ordentligt..
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