mboost-dp1
Intel
Så er det godt de fleste tænkende mennesker godt er klar over at der ikke er en lineær sammenhæng mellem clockfrekvens, og hvad en cpu rent faktisk formår :)
De har lavet hvad de påstår er verdens hurtigste computer, og har valgt at optage filmen i Jordens dårligste kvalitet.
IBM, det er en ommer. Den film gider jeg ikke engang kigge på! DER ER MONOLYD! (der kommer i hvert fald kun lyd ud af venstre højtaler her)
*piv piv piv*
IBM, det er en ommer. Den film gider jeg ikke engang kigge på! DER ER MONOLYD! (der kommer i hvert fald kun lyd ud af venstre højtaler her)
*piv piv piv*
Fordi det er svært at programmere til flere cores.TormDK (2) skrev:Flere cores er da nice, men mange apps idag vil stadig gerne have hurtige cores, istedet for flere.
Det er stadigvæk langt mere effiktivt til f.eks. spil, at have mindst 4 cores. Hurtigere er mere relevant for udvikling af mindre/bærbare maskiner, hvor der ikke er plads til mange cores og dertilhørende kølesystemer.
Jeg tror også at udfordringen ligger ligeså meget i køling, som i at placere en stor mængde transitorer på en chip.
Windcape (4) skrev:Fordi det er svært at programmere til flere cores.
Hvilket er CPU-udviklernes skyld. På en CPU med 4 kerner, bør der være en ekstra der KUN håndterer trådene i de øvrige 4 kerner.
Afvikler man et tungt program der ikke er optimeret til flere kerner, vil det typisk være Core-0 der anvendes, også selvom de øvrige 3 kerner er stort set ubelastede.
For at komme udover det problem, er man nødt til selv at programmere en distribution af tråde på de forskellige kerner.
Ved at lade en integreret controller/chip fordele trådene ligeligt på alle kerner er der ikke længere behov for den slags optimering. Man skal selvfølgelig stadig være i stand til at angive hvilke kerner programmet (ikke) må afvikles på.
Windcape (4) skrev:Fordi det er svært at programmere til flere cores.
gu det ej.. det kræver bare en anden måde at tænke på.
Windcape (4) skrev:Det er stadigvæk langt mere effiktivt til f.eks. spil, at have mindst 4 cores. Hurtigere er mere relevant for udvikling af mindre/bærbare maskiner, hvor der ikke er plads til mange cores og dertilhørende kølesystemer.
om du har 1 core med 2 ghz eller 2 core ved 1 ghz giver samme energiforbrug = varme
så det holder ikke det du siger.
mireigi (6) skrev:Hvilket er CPU-udviklernes skyld. På en CPU med 4 kerner, bør der være en ekstra der KUN håndterer trådene i de øvrige 4 kerner.
hvilket man ikke kan/gør - fordi tråd synkronisering ikke kan udføres af en intet-andene dum cpu...
hvis man blot smed instruktionerne fra 1 tråd ud på 4 - ville hele programmet gå i smadder inden du kan nå at blinke...
mireigi (6) skrev:Afvikler man et tungt program der ikke er optimeret til flere kerner, vil det typisk være Core-0 der anvendes, også selvom de øvrige 3 kerner er stort set ubelastede.
dette sørger Kernen allerede for i f.eks. Windows...
prøv selv at start et tungt program 2-3 gange på en quad core... så arbejder 2-3 kerner ved fuld tryk...
Offtopic men
Nej, mono er én kanal, og i gamle dage (80'erne) kunne man altid regne med at det var venstre højttaler i et stereo-setup der bragte lyden fra en mono-kilde. Så hvad #3 skriver er korrekt.
Windcape (5) skrev:Hvis det var mono, ville samme lyd komme ud af begge kanaler.
Nej, mono er én kanal, og i gamle dage (80'erne) kunne man altid regne med at det var venstre højttaler i et stereo-setup der bragte lyden fra en mono-kilde. Så hvad #3 skriver er korrekt.
Wikipedia skrev:monophonic, or "mono" sound, [...] is audio in the form of one channel
Disse processorer er lavet til mainframes. De findes i IBM's nye zEnterprise. Deres instruktionsset er langt større og mere komplekse end hvad man finder i konventionelle processorer.
Så de er optimeret til virtualisering og IO-tunge opgaver. En sammenligning med en supercomputer eller instruktioner per sekund er rimelig intetsigende.
IBM's påstand er formegentlig baseret på clockfrekvensen.
Så de er optimeret til virtualisering og IO-tunge opgaver. En sammenligning med en supercomputer eller instruktioner per sekund er rimelig intetsigende.
IBM's påstand er formegentlig baseret på clockfrekvensen.
Ja, men en normal stereo-forstærker havde også en Mono switch, så lyden blev fordelt på begge højtalere.BlackFalcon (9) skrev:Nej, mono er én kanal, og i gamle dage (80'erne) kunne man altid regne med at det var venstre højttaler i et stereo-setup der bragte lyden fra en mono-kilde. Så hvad #3 skriver er korrekt.
At nøjes med en-kanal lyd er fint, hvis afspilleren fordeler lyden i begge højtalere, hvilket er rimelig standard i dag. Så når videoen kun afspiller i venstre højtaler, så kan vi vel næsten formode at det er stereolyd (2 kanaler), hvor der kun er et aktivt lydspor i den ene kanal.
Og netop det, er hvad der gør det svært. Det bliver nemmere jo flere udviklingsværktøjer vi får til det, men hvis du mener at det er super nemt, er jeg sikker på at du kunne få et meget bedre job end du har i dag!Montago (7) skrev:gu det ej.. det kræver bare en anden måde at tænke på.
Det handler jo ikke bare om at dele programmet op, men også at holde styr på ens tråde og få det korrekte resultat (f.eks. sync lyd med billede).
Så det er definitivt "svært".
Men du mener jo det er super nemt at gøre det, hvorfor modsiger du så dig selv nu? :-)Montago (7) skrev:hvilket man ikke kan/gør - fordi tråd synkronisering ikke kan udføres af en intet-andene dum cpu...
hvis man blot smed instruktionerne fra 1 tråd ud på 4 - ville hele programmet gå i smadder inden du kan nå at blinke...
Montago (8) skrev:dette sørger Kernen allerede for i f.eks. Windows...
prøv selv at start et tungt program 2-3 gange på en quad core... så arbejder 2-3 kerner ved fuld tryk...
Ja, 2-3 kerner arbejder for fuld tryk, mens de(n) resterende er stort set ubrugt.
Problemet med at lade software håndtere den slags, er at der bruges tid på at forespørge CPU'en om belastningen på de enkelte kerner, så en passende kan vælges.
Et mere forståeligt eksempel er mainframes (MF) hos fx BankData. Der står 2 MFsmed 20 km. mellem dem. De er forbundet via lysleder kabel på 10 Gbit hver vej.
Hvis MF1 er fuldt belastet, sættes en opgave i kø til at blive afviklet på MF2, såfremt der er plads på denne. Problemet er bare at på den tid det tager at sende en forespørgsel til MF2 og modtage et svar, er den tid MF1 skal bruge på at få plads til opgaven og afvikle den. Og vi snakker om svartider på under 1 millisekund.
I langt de fleste tilfælde er dette ikke noget problem, men, hvis der skal laves en forespørgsel hver gang, bliver det til meget spildtid.
Med en CPU, vil Round-Robin princippet fungere meget godt, således at alle kerner er belastet lige meget.
Montago (7) skrev:hvis man blot smed instruktionerne fra 1 tråd ud på 4 - ville hele programmet gå i smadder inden du kan nå at blinke...
Du har misforstået det hele. Én tråd hører til på én kerne. Men 2 tråde fra samme program skal ikke køre på samme kerne, medmindre de øvrige kerner er tilsvarende/mere belastede.
Ethvert skridt imod højere clockfrekvens må da ses som positivt. Det er måske ikke af den store betydning for den almindelige computer bruger, og får næppe din frame rate i dit ynglingsspil til at skyde i vejret, men det er denne processor jo heller ikke målrettet til.
Det giver så ikke mening at prøve at mudre vandene med tale om multiprocessorer. Sidder en forsker eller lignende med et problem hvor en beregning afhænger af den næste, så kan han være fløjtende ligeglad med om han har 17 ekstra cpu'er til rådighed, han kommer ikke en meter videre af den grund før den forrige beregning er færdig.
Derudover skal vi da nok på et tidspunkt nå dertil hvor ikke alle problemer på vores egne desktop maskiner kan løses ved bare at smide ekstra cores i cpu'en, og så vil lidt spillover fra bla. IBM's arbejde her nok være meget velkomment.
Det giver så ikke mening at prøve at mudre vandene med tale om multiprocessorer. Sidder en forsker eller lignende med et problem hvor en beregning afhænger af den næste, så kan han være fløjtende ligeglad med om han har 17 ekstra cpu'er til rådighed, han kommer ikke en meter videre af den grund før den forrige beregning er færdig.
Derudover skal vi da nok på et tidspunkt nå dertil hvor ikke alle problemer på vores egne desktop maskiner kan løses ved bare at smide ekstra cores i cpu'en, og så vil lidt spillover fra bla. IBM's arbejde her nok være meget velkomment.
Det afhænger meget af programmet, om det er optimeret til det.Montago (8) skrev:dette sørger Kernen allerede for i f.eks. Windows...
prøv selv at start et tungt program 2-3 gange på en quad core... så arbejder 2-3 kerner ved fuld tryk...
F.eks. World of Warcraft blev optimeret til at kører på duo core for et par år siden, og det gav et mærkbart performance boost, i forhold til før.
Systemet kan kun gøre så meget. Det er af samme grund man bruger forskellige udviklingsværktøjer og sprog (.NET PFX, eller Erlang) til formålet.
Ideen er allerede brugt i dag, f.eks. i playstation 3, hvor en af kernene bruges til at holde styr på de andre.mireigi (13) skrev:Med en CPU, vil Round-Robin princippet fungere meget godt, således at alle kerner er belastet lige meget.
Men det kommer til at tage noget tid (læs: 10-15 år) før vi virkelig er klar til at kode mod flere kerner.
Stadigvæk offtopic men
Enig
Stereo-lyd er per definition "to forskellige lydspor i to kanaler". Ergo er "opskaleret" mono (til to kanaler) ikke stereo. :-)
Windcape (11) skrev:Ja, men en normal stereo-forstærker havde også en Mono switch, så lyden blev fordelt på begge højtalere.
Enig
Windcape (11) skrev:At nøjes med en-kanal lyd er fint, hvis afspilleren fordeler lyden i begge højtalere, hvilket er rimelig standard i dag. Så når videoen kun afspiller i venstre højtaler, så kan vi vel næsten formode at det er stereolyd (2 kanaler), hvor der kun er et aktivt lydspor i den ene kanal.
Stereo-lyd er per definition "to forskellige lydspor i to kanaler". Ergo er "opskaleret" mono (til to kanaler) ikke stereo. :-)
Wikipedia skrev:Stereophonic sound, commonly called stereo, is the reproduction of sound using two or more independent audio channels
og
To record in stereo, sound engineers use various methods, including using two directional microphones, two parallel omnidirectional microphones, or more complex techniques
Windcape (15) skrev:Det afhænger meget af programmet, om det er optimeret til det.Montago (8) skrev:dette sørger Kernen allerede for i f.eks. Windows...
prøv selv at start et tungt program 2-3 gange på en quad core... så arbejder 2-3 kerner ved fuld tryk...
F.eks. World of Warcraft blev optimeret til at kører på duo core for et par år siden, og det gav et mærkbart performance boost, i forhold til før.
Systemet kan kun gøre så meget. Det er af samme grund man bruger forskellige udviklingsværktøjer og sprog (.NET PFX, eller Erlang) til formålet.
OT:
WoW blev ændret fra at bruge 1 til 3 ikke kun 2.
Windcape (12) skrev:Men du mener jo det er super nemt at gøre det, hvorfor modsiger du så dig selv nu? :-)Montago (7) skrev:hvilket man ikke kan/gør - fordi tråd synkronisering ikke kan udføres af en intet-andene dum cpu...
hvis man blot smed instruktionerne fra 1 tråd ud på 4 - ville hele programmet gå i smadder inden du kan nå at blinke...
nu har du jo gang i en stråmand,...
dét jeg sagde var: At det er nemt at kode til flere cores, hvis man tænker på en anden måde (end hvis man koder mod 1 core)
at lave en tråd-schedular som optimere 1 tråd imod flere kerner er derimod IKKE nemt...
mireigi (13) skrev:Ja, 2-3 kerner arbejder for fuld tryk, mens de(n) resterende er stort set ubrugt.
sådan er det jo hvis programmet er 1-trådet... det kan man sku ik lave om på.
hvis du har 3 multi-trådede programmer kørende på en quadcore, vil den køre 98-100% på alle kerner...
men det scenarie som du snakker om, kunne sagtens optimeres bedre med en scheduler... pakkerne som skal eksekveres kan jo smides til højre og venstre uden problemer...
Windcape (16) skrev:Men det kommer til at tage noget tid (læs: 10-15 år) før vi virkelig er klar til at kode mod flere kerner.
Næppe... værktøjerne er allerede på plads, både i fx .NET og Cocoa, og det er nok de mest populære og brugte frameworks på henholdsvis Apple og Mac OS X. Det kommer bestemt ikke til at tage 10-15 år før "vi" er klar. Det vil være en gradvis process, men den er allerede begyndt og de største gevinster vil helt klart komme i starten, hvilket er nu.
Montago (19) skrev:sådan er det jo hvis programmet er 1-trådet... det kan man sku ik lave om på.
hvis du har 3 multi-trådede programmer kørende på en quadcore, vil den køre 98-100% på alle kerner...
Ja, programmer der er optimeret til flere tråde, kan godt finde ud af dette. Men i næsten alle tilfælde, vil 10 samtidige single-thread programmer køre på den samme core, også selvom andre cores er ubelastede.
Strukturen i CPU cores skal bygges op på samme måde som DDR og/eller RAID0. Alting fordeles ligeligt mellem hver RAM-blok/HDD.
Jeg snakker ikke om at dele tråde op i sub-tråde, men om at X antal tråde bliver fordelt ligeligt på Y antal cores. Ikke alene vil det bevirke at alle programmer er uafhængige af multi-thread optimering, det vil også have en drastisk forøgelse på low-end duo/quad CPU'er hvor hastigheden er begrænset, som fx mobile CPU'er.
Windcape (16) skrev:Ideen er allerede brugt i dag, f.eks. i playstation 3, hvor en af kernene bruges til at holde styr på de andre.
I en PS3 er der 7 aktive kerner. 1 af de 7 bruges af OSet til sikkerhed. De sidse 6 står til programmørns rådighed. Der er ikke nogen kerne til <specifikt> at holde styr på resten; dette er op til programmøren.
mireigi (6) skrev:Hvilket er CPU-udviklernes skyld. På en CPU med 4 kerner, bør der være en ekstra der KUN håndterer trådene i de øvrige 4 kerner.
Dedikerede CPU kan kun reducere performance ikke forbedre den.
mireigi (6) skrev:Afvikler man et tungt program der ikke er optimeret til flere kerner, vil det typisk være Core-0 der anvendes, også selvom de øvrige 3 kerner er stort set ubelastede.
Med et single threaded program: ja.
mireigi (6) skrev:For at komme udover det problem, er man nødt til selv at programmere en distribution af tråde på de forskellige kerner.
Der er ingen måde at gøre det på for et single threaded program.
For et multithreaded program kan ethvert OS der er nyere end ca. 20 år klare det.
mireigi (6) skrev:Ved at lade en integreret controller/chip fordele trådene ligeligt på alle kerner er der ikke længere behov for den slags optimering. Man skal selvfølgelig stadig være i stand til at angive hvilke kerner programmet (ikke) må afvikles på.
Der er ingen som helst behov for programmer for selv at schedulere deres tråde. Den slags sørger OS fint for. Problemet er at splitte programmet op i flere tråde således at man stadig er garanteret et korrekt resultat.
mireigi (13) skrev:Problemet med at lade software håndtere den slags, er at der bruges tid på at forespørge CPU'en om belastningen på de enkelte kerner, så en passende kan vælges.
Sådan fungerer schedulere altså ikke.
mireigi (13) skrev:
Et mere forståeligt eksempel er mainframes (MF) hos fx BankData. Der står 2 MFsmed 20 km. mellem dem. De er forbundet via lysleder kabel på 10 Gbit hver vej.
Hvis MF1 er fuldt belastet, sættes en opgave i kø til at blive afviklet på MF2, såfremt der er plads på denne. Problemet er bare at på den tid det tager at sende en forespørgsel til MF2 og modtage et svar, er den tid MF1 skal bruge på at få plads til opgaven og afvikle den. Og vi snakker om svartider på under 1 millisekund.
I langt de fleste tilfælde er dette ikke noget problem, men, hvis der skal laves en forespørgsel hver gang, bliver det til meget spildtid.
Jeg tror ikke rigtigt at du kan sammenligne jobs over 20 km lysleder med tråde og CPU kerner.
mireigi (13) skrev:Med en CPU, vil Round-Robin princippet fungere meget godt, således at alle kerner er belastet lige meget.
Ligelig fordeling på CPU har været helt almindelig i alle OS i mange mange år.
Windcape (15) skrev:Systemet kan kun gøre så meget. Det er af samme grund man bruger forskellige udviklingsværktøjer og sprog (.NET PFX, eller Erlang) til formålet.
Det var ikke ligefrem hvad jeg vil kalde de mest oplagte eksempler.
OpenMP forekom mig at være noget mere udbredt.
mireigi (23) skrev:Ja, programmer der er optimeret til flere tråde, kan godt finde ud af dette. Men i næsten alle tilfælde, vil 10 samtidige single-thread programmer køre på den samme core, også selvom andre cores er ubelastede.
Ikke i Windows (NT/2000/XP/2003/Vista/2008/7), Linux, MacOS X, *BSD, AIX, HP-UX, Solaris, OpenVMS eller z/OS.
Clauzii (24) skrev:I en PS3 er der 7 aktive kerner. 1 af de 7 bruges af OSet til sikkerhed. De sidse 6 står til programmørns rådighed. Der er ikke nogen kerne til <specifikt> at holde styr på resten; dette er op til programmøren.
Sidst jeg kiggede på PS3 specifikationen, havde den 8 SPE'er :D
http://playstation.about.com/od/ps3/a/PS3SpecsDeta...
*1 of 8 SPEs reserved for redundancy total floating point performance: 218 GFLOPS
dertil skal siges, at den har 1 ALU:
http://img89.echo.cx/img89/3283/cellcpu3os.png
ALU'en bruges til alm. instruktioner som er nødvendigt for OS'et
resten af de 8 SPE'er er (så vidt jeg husker) Floating Point / Vector units
General purpose programming. F.eks. giver det jo fint mening at Word, Photoshop eller Visual Studio ville være optimeret mod flere kerner, da de fleste pc'er har en multi-core CPU i dag.arne_v (29) skrev:Nu afhænger det jo lidt af hvem "vi" er.
Hvis vi snakker web server, database server programmører så er -20 år nok et godt gæt.
:-)
Vi er først ved at komme i gang i dag. Frameworks som PFX til .NET, eller Apple's tilsvarende tiltag til Cocoa (har glemt navnet) vil hjælpe konceptet i gang hos *alle* frem for få specialiserede typer af programmer.
Og så ved jeg nu ikke om man kan sige at Apache er multi-core optimeret? :p
#31:
Nej. En CELL CPU har 8 SPEer. I PS3 er det 'kun' 7 der er aktive. Og ja,der er en enkelt PowerPC kerne til generelle instruktioner.
Prøv evt. at kigge lidt i flg.: Programming on the PS3
Nej. En CELL CPU har 8 SPEer. I PS3 er det 'kun' 7 der er aktive. Og ja,der er en enkelt PowerPC kerne til generelle instruktioner.
Prøv evt. at kigge lidt i flg.: Programming on the PS3
#33
det er jo også dét jeg siger ?
8 SPE'er hvor 1 er låst for programmøren (men bruges af systemet)
+ 1 ALU (PowerPC core)
:-)
det var Clauzii som mente der kun var 7 SPE'er hvor en var låst..
det er jo også dét jeg siger ?
8 SPE'er hvor 1 er låst for programmøren (men bruges af systemet)
+ 1 ALU (PowerPC core)
:-)
det var Clauzii som mente der kun var 7 SPE'er hvor en var låst..
Windcape (32) skrev:General purpose programming.
Jeg tror du mener desktop app programming.
Windcape (32) skrev:Vi er først ved at komme i gang i dag.
Kun indenfor desktop apps.
Windcape (32) skrev:F.eks. giver det jo fint mening at Word, Photoshop eller Visual Studio ville være optimeret mod flere kerner, da de fleste pc'er har en multi-core CPU i dag.
Word starter faktisk allerede 10+ tråde og VS 40+ tråde.
Men jeg må indrømme at jeg ikke ved hvor gode de er til faktisk at fordele de opgaver som er CPU intensive.
Windcape (32) skrev:Og så ved jeg nu ikke om man kan sige at Apache er multi-core optimeret?
????
Apache 2.x er da særdeles multithreaded og en typisk httpd.conf angiver ThreadsPerChild 250 på Windows.
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