Intel klemmer inn gasspedalen

[nicholas]

Hvorfor er denne TDPen så viktig? Bruker nye datamaskiner så mye strøm i dag at man må bekymre seg for slike ting?

[sinnaelgen]

1) : i utgangspunktet så er det ikke så galt derimot hvis man opplever det samme med Windows så blir jeg betenkt.

det var for en stund siden en større diskusjon på forumet het hvorfor Windows kom i så mang utgaver når det hadde holdt med noen få ,- en for de profesjonelle og en for hjemme brukeren.

 

2) hvis jeg ikke husker helt galt ( det er lenge siden) så var det Windows 2 som i en 286 utgave og en 386 utgave ( på disketter ). hvorfor de gjorde det slik er jeg ikke sikker

 

3) nå var det ikke det jeg tenkte på da.

 

 

det er snakk om unngå å måtte tvinge brukeren til måtte kjøpe alt utstyrer på nytt hvis man oppgraderer operativsystemet.

 

et klassisk eksempel er når noe av det gamle utstyret må skiftes ut sg så må man kaste resten av utstyret også fordi det ikke passer lenger ( ikke fysisk men p.g.a. driver mangler) .

 

 

hvis nå Microsoft måtte tilpasse Windows til en ny arkitektur til et hovedkort fra intel er man da så sikker på at man da for til noe alla xp-modus for at brukeren fortsatt kan bruke noen av det gamle utstyrer sitt lenger.

 

alternativet blir som det som har skjedd med xp , man venter lenge , veldig lenge før man oppgraderer.

dette går utover både det ene og det andre , ikke minst sikkerheten

 

 

 

om driverne er innebygget eller ikke så er man nødt til bruke en utgave til Windows og en anen utgave hvis man vil bruke linux eller OSX. så har passer ikke den en spille til flere operativsystemer. slik er det også med de programmene man bruker

Endret 21. mars 2010 av den andre elgen

[Simen1]

Elgen: Du tar feil. Det er ikke så komplisert å benytte andre ISA. Hvis f.eks Cell var vanlig i hjemmePCer så ville Microsoft enkelt ha kompilert Windows til Cell. Det er noen få dagers arbeid for en enkelt utvikler. (I utgangspunktet minutter, men så skal det feilsøkes og fikses og det tar fort mer tid)

 

Deretter hadde man enkelt installert Cell-versjonen av den programvaren man bruker i stedet for x86-versjonen. Ingen hokus pokus her heller altså.

[OldMan]

Tror rimlig sikkert at MS tar imot en jobbsøknad fra deg hvis du kan love å porte Windows til enhver plattform i løpet av noen dager Simen1.

 

Jeg har tidligere jobbet med å vedlikeholde programmer på flere plattformer (Solaris på gamle Sun bokser, HP unix bokser og PC), og jeg må si at det ikke er noen enkel jobb. Som programutvikler/leverandør er det mange som har spart/tjent mye på at Windows på x86 har vært/er så dominerende.

Endret 21. mars 2010 av OldMan

[HKS]

Elgen: Du tar feil. Det er ikke så komplisert å benytte andre ISA. Hvis f.eks Cell var vanlig i hjemmePCer så ville Microsoft enkelt ha kompilert Windows til Cell. Det er noen få dagers arbeid for en enkelt utvikler. (I utgangspunktet minutter, men så skal det feilsøkes og fikses og det tar fort mer tid)

 

Deretter hadde man enkelt installert Cell-versjonen av den programvaren man bruker i stedet for x86-versjonen. Ingen hokus pokus her heller altså.

Så enkelt er det nok ikke...

 

Det er masse kode i Windows samt i driverene som følger med som er optimert med MMX/SSE/SSE2 etc. Dette fungerer ikke på Cell, så dette måtte blitt skrevet om til Altivec. Etter dette var gjort hadde du sittet med en PowerPC versjon av Windows som hadde kjørt på den middelmådige PPE prosessoren på Cell.

 

Etter det måtte du brukt laaang tid på å identifisere hvilke deler av koden som kan være egnet til å kjøre på Cell sine SPE'er, for å så skrive vektorisert kode, samt dispatching til SPE.

[del_diablo]

Tror rimlig sikkert at MS tar imot en jobbsøknad fra deg hvis du kan love å porte Windows til enhver plattform i løpet av noen dager Simen1.

 

Jeg har tidligere jobbet med å vedlikeholde programmer på flere plattformer (Solaris på gamle Sun bokser, HP unix bokser og PC), og jeg må si at det ikke er noen enkel jobb. Som programutvikler/leverandør er det mange som har spart/tjent mye på at Windows på x86 har vært/er så dominerende.

 

Hvor mye av jobben var det å skrive om programmene for å beholde kompitabliteten mellom biblotek? Eller vis du porter så ble det sikkert massive hopp i version nummere?

x86 er for treg til å brukes til noe.

[OldMan]

Tror rimlig sikkert at MS tar imot en jobbsøknad fra deg hvis du kan love å porte Windows til enhver plattform i løpet av noen dager Simen1.

 

Jeg har tidligere jobbet med å vedlikeholde programmer på flere plattformer (Solaris på gamle Sun bokser, HP unix bokser og PC), og jeg må si at det ikke er noen enkel jobb. Som programutvikler/leverandør er det mange som har spart/tjent mye på at Windows på x86 har vært/er så dominerende.

 

Hvor mye av jobben var det å skrive om programmene for å beholde kompitabliteten mellom biblotek? Eller vis du porter så ble det sikkert massive hopp i version nummere?

x86 er for treg til å brukes til noe.

Mye av jobben var å forholde seg til forskjellige 3. parts biblioteker, hvilke kompilator versjoner de støttet osv. Jobbet også med problemer med lesing av binære filer med little/big endian lagring og mye annet idiotisk/unødvendige ting.

Når vi benchet våre apps på en Pentium 166 og så at de var ett par ganger raskere enn Sparc ble heldigvis det meste flyttet over på PC og vedlikehold og utviklingskostnader gikk selvfølgelig ned.

 

Selv om det kanskje finnes andre instruksjonssett som er bedre en x86 i dag, så er den generelle ytelsen på Intel/x86 fremdeles konkuransedyktig - mye pga av Intels ledelse i produksjonsteknologi.

Endret 21. mars 2010 av OldMan

[Simen1]

Hvis man har normalt gode kompilatorer til de ulike arkitekturene så er det de som gjør jobben med oversetting av kode og optimering mot ulike prosessorressurser som SSE og SPE. Programmererne skal ikke behøve å tenke på sånt. Det er sjelden det blir gjort noe særlig manuell optimering av kritiske løkker likevel.

[Bolson]

Jeg har tidligere jobbet med å vedlikeholde programmer på flere plattformer (Solaris på gamle Sun bokser, HP unix bokser og PC), og jeg må si at det ikke er noen enkel jobb. Som programutvikler/leverandør er det mange som har spart/tjent mye på at Windows på x86 har vært/er så dominerende.

 

Kortsiktig spart/tjent - men kanskje med langsiktige tap. I alle fall for kundene. Monokulturer er ikke kjent for å initiere de beste måtene å gjøre ting på. Jeg er fullt klar over at det er og ikke minst har vært arbeid med å vedlikeholde programmer på flere plattformer. Men mye av det tror jeg også skyldes dårlig utviklingsstrategi i utgangspunktet og monokulturbasert oppbygging.

 

Så langsiktig tror jeg man hadde tjent på flere plattformer med markedsandel av betydning, da man da i langt større grad hadde måttet tenke på andre måter i programvareutvikling.

[HKS]

Hvis man har normalt gode kompilatorer til de ulike arkitekturene så er det de som gjør jobben med oversetting av kode og optimering mot ulike prosessorressurser som SSE og SPE. Programmererne skal ikke behøve å tenke på sånt. Det er sjelden det blir gjort noe særlig manuell optimering av kritiske løkker likevel.

Det du snakker om der høres sikkert fint ut, men det finnes ikke...

[Simen1]

Kompilatorer finnes i hopetall. Både for en haug ulike programmeringsspråk og for en haug ulike prosessorarkitekturer. Bare for å ta et eksempel så kan man fint kompilere C++ koden sin til den arkitekturen man måtte ønske. Enkelt og greit skriver programmereren en kode, mens kompilatorene oversetter koden til de maskinvarekodene man ønsker.

 

Wikipedia: Compiler

[HKS]

Kompilatorer finnes i hopetall. Både for en haug ulike programmeringsspråk og for en haug ulike prosessorarkitekturer. Bare for å ta et eksempel så kan man fint kompilere C++ koden sin til den arkitekturen man måtte ønske. Enkelt og greit skriver programmereren en kode, mens kompilatorene oversetter koden til de maskinvarekodene man ønsker.

 

Wikipedia: Compiler

Ok... La meg pressisere...

 

Det finnes ingen kompilator som automatisk vektoriserer koden din på en effektiv måte, samt automatisk laster over oppgaver til SPE'ene på en Cell.

 

Si at du skriver ett enkelt C++ eller C program for å gjøre DCT på ett bilde, da kan du kompilere dette programmet så mye du ønsker, med hvilken som helst kompilator du klarer å finne. På en Cell kommer bare programmet ditt til å bruke PPE'en, som ikke er noe annet en middelmådig Power4 prosessor.

 

Skal du utnytte SPE'ene så må det gjøres manualt. Først må du først skrive kode for å dispatche jobber. Her er det flere teknikker. SPE'ene kjører vanligvis noe som ligner pthreads, og du kommuniserer ofte via mailboxer. Deretter må du skrive kode for å overføre data og kode til SPE'ene. Kode og data kan ikke være større enn 256kb (local storage), antakeligvis er ikke det nok, så da trenger du kode til DMA operasjoner for å få data inn til SPE'ene, og tilbake til minnet når det er prosessert ferdig. Ønsker du maksimal ytelse så vil du også bruke double-buffering for å skjule noe av overheadet du har med disse DMA operasjonene. Til slutt så bør koden optimeres for SPE'ene, som i bunn og grunn er en vektorprosessor. Du må derfor skrive om koden til noe som ligner på altivec, dette ser ganske forskjellig ut fra vanlig scalar kode som er skrevet for x86.

 

Jeg skal love deg at det er vanskelig å få god ytelse ut av en Cell, og det er et helvete å få maksimal ytelse. Ting går heldigvis litt fortere etterhvert, siden du kan gjenbruke mye kode... En ting er iallefall sikkert... Kompilatoren gjør ikke stort for deg her, hverken gcc eller IBM sin egen kompilator.

[OldMan]

I en ideel verden hvor alle os var bygget over en liten hal (Hardware Abstraction Layer) og hardware ytelsen var så god på alle platformer at optimaliseringer etc ikke var nødvendig, så ville dine ideer vært riktig Simen1, men slik er dessverre ikke virkeligheten.