Dagens programvare er gammeldags

[Simen1]

Artikkelen er i høyeste grad agurknytt og velkjente selvfølgeligheter. Jeg skjønner ikke hvorfor det brukes kilder på noe sånt.

 

Den enkle konklusjonen blir dermed at prosessorindustrien for tiden er langt mer fremoverlent på ny teknologi enn det som er tilfelle på programvare.

Tidligere har programytelsen økt pga raskt økende klokkefrekvenser. Programmene trengte ingen endringer for å få ta i bruk denne økte ytelsen. Når klokkefrekvensene møtte veggen i 2003 ble det ikke så enkelt lengre. Nå må programmene faktisk skrives om i omfattende grad for å få økt ytelse pga flere kjerner.

 

Smarte teknikker som SIMD (SSEx o.l.) har riktignok hjulpet en god del det også, men det har krevd ganske enkle endringer av programmene. Mer cache og bedre kommunikasjon mellom prosessoren og omgivelsene har også hjulpet en god del, men den biten med flere kjerner er ikke så enkelt å skrive om programmene for.

 

Jeg vil si programvareindustrien har vært middels flinke til å utnytte flere kjerner, tatt i betraktning av hvor vanskelig det er.

 

Ellers så vil jeg legge mer skyld på prosessorproduentene for å ikke bruke flere og smartere metoder som instruksjonsutvidelser og tilhørende kompilatorforbedringer.

[Anders Jensen]

Ellers så vil jeg legge mer skyld på prosessorproduentene for å ikke bruke flere og smartere metoder som instruksjonsutvidelser og tilhørende kompilatorforbedringer.

Instruksjonsutvidelser er et tveegget sverd på lik linje med dypere pipeline for å øke ytelsen. På ett eller annet tidspunkt er blir økningen i kompleksitet og valgmuligheter så stor at den motvirker forbedringen endringen gir. Da ender du opp med et frankenstein monster som ikke fungerer etter hensikten. Forskjellen er at et dypt pipeline design kan endres, instruksjoner som er lagt til kan ikke like enkelt fjernes igjen.

 

Det vi trenger er et instruksjonssett som har riktig mengde general purpose instruksjoner og utnytter de bitene som brukes til det maksimale. Videre er det absolutt nødvendig å ikke skusle bort all parallellitetsinformasjonen som alle moderne kompilatorer likevel finner for å optimalisere koden. Som du sikkert vet så kalles dette jeg beskriver for IA64 og det er vel bare å vente tålmodig på at resten av verden skal innse det.

[Simen1]

Hehe, selvsagt skjønner jeg at du sikter til IA64 igjen.

 

Men som tidligere nevnt har jeg mer tro på en evolusjonær tilnærming til instruksjonssett enn til revolusjon (særlig en revolusjon som avskaffer konkurranse). Med evolusjonært mener jeg at gamle/ineffektive instruksjoner gjerne kan fases ut samtidig som nye innføres. Gamle/ineffektive instruksjoner bør kunne emuleres med dårligere ytelse. Instruksjonssett bør som protokoller på nettet være åpne for konkurranse.

 

Det vil gi en relativt smertefri utvikling av instruksjonssettet uten at eldgammel, men viktig kode låses ut i kulda.

[Anders Jensen]

Vel jeg er grunnleggende uenig i den evolusjonære tilnærmingen da problemet ikke ligger i hvilke instruksjoner som er implementert, men hvordan de er organisert. En jump, load, store eller add instruksjon er like relevant i dag som den var for 60 år siden og disse utgjør ca 80% av all kode. Hva slags eksotiske instruksjoner du legger til i de siste 20% er ikke mye viktig. Alt en oppnår er at stadig større del av kjernen er idle til enhver tid. Kan du imidlertid optimalisere de fire over nevnte instruksjonsgruppene så optimaliserer du mesteparten av koden.

 

Når det gjelder konkurranseaspektet så er jeg helt enig. Vi har ikke behov for enda en periode med Intel monopol på ytelse. For meg er den mest interessante problemstillingen hvordan vi kan få konkurranse innen IA64 eller eventuelt med en tilsvarende, men inkompatibel løsning. Jeg mener det er en langt mer realistisk løsning enn at noen skal klare å patche x64 til å bli brukbart. Vi får håpe at det vokser noe bra ut av India og Kina snart på denne fronten og at IBM/HP/SUN/DELL kan presse frem en second source løsning. Selv aksjonærer i HP bør være skeptisk til total Intel dominans enda HP sitter med store interesser i IA64.

Endret 30. januar 2009 av Anders Jensen

[tommyb]

Jeg vet ikke om jeg er enig i at det er mer moderne å utvikle mer avansert for å ende opp med samme funksjonaliteten som man allerede lager. Flertrådet programmering er rett og slett mye dyrere. Og det er tross alt svært få programmer som egentlig er utviklet for maksimal ytelse. Er det egentlig noen som bryr seg om at kalkulatoren i windows eller algoritmen som brukes for å oppdatere scrollinga i WinAmp-GUIet kunne vært 25% raskere med en multitrådet tilnærming? De ytterst få programmene som faktisk har utbytte av høy kalkuleringskraft, er allerede multitrådet. De fleste populære programmene i dag har derimot internettbåndbredde som den eneste reelle flaskehalsen.

 

Så jeg ser ikke noen grunn til å øke utviklingskostnadene på disse. Mangetrådet programmering er mye mer komplisert, medfører langt flere bugs og det blir vanskeligere å isolere og fikse hver enkelt bug. Bugs er en viktigere issue enn ytelse.

[Kahuna]

Tror noen vi får se noe FPGA-liknende saker som standard i CPUer etterhvert? Tunge oppgaver som video encoding/decoding blir ofte overlatt til spesialkretser som står idle mesteparten av tiden uansett. Hvis disse hadde blitt implementert i FPGA kunne man både utnyttet kretsene bedre samt fått mye mer fleksible hardware. (+ mer moro for programmerere...)

[Anders Jensen]

Tror noen vi får se noe FPGA-liknende saker som standard i CPUer etterhvert? Tunge oppgaver som video encoding/decoding blir ofte overlatt til spesialkretser som står idle mesteparten av tiden uansett. Hvis disse hadde blitt implementert i FPGA kunne man både utnyttet kretsene bedre samt fått mye mer fleksible hardware. (+ mer moro for programmerere...)

FPGA er forsåvidt fleksibelt ved at det er reprogrammerbart, men det er en vesentlig overhead på hardware nivå for å kunne gjøre dette. I praksis er all logikk lagd slik at den kan implementere alle mulige kombinasjoner. Det er som om alle biler ble lagd slik at de kunne løst alle oppgaver fra lastebil til sportsbil. Naturlig nok blir det verken fugel eller fisk ut av det.

 

FPGA egner seg til lave volum. Utover det er du stort sett bedre tjent med en god general purpose CPU.

[Kahuna]

Tror noen vi får se noe FPGA-liknende saker som standard i CPUer etterhvert? Tunge oppgaver som video encoding/decoding blir ofte overlatt til spesialkretser som står idle mesteparten av tiden uansett. Hvis disse hadde blitt implementert i FPGA kunne man både utnyttet kretsene bedre samt fått mye mer fleksible hardware. (+ mer moro for programmerere...)

FPGA er forsåvidt fleksibelt ved at det er reprogrammerbart, men det er en vesentlig overhead på hardware nivå for å kunne gjøre dette. I praksis er all logikk lagd slik at den kan implementere alle mulige kombinasjoner. Det er som om alle biler ble lagd slik at de kunne løst alle oppgaver fra lastebil til sportsbil. Naturlig nok blir det verken fugel eller fisk ut av det.

 

FPGA egner seg til lave volum. Utover det er du stort sett bedre tjent med en god general purpose CPU.

Nå tenkte jeg vel å bruke FPGA som supplement til CPU og kanskje som erstatning for noen spesialkretser som i dag feks bygges inn i GPU (encoding/decoding av video)

 

Er det problemer man ikke kan fjerne hvis FPGA begynner å brukes i større volum? Nå følger jeg ikke FPGA-markedet tett men tror jeg leste noe om at 'klokkefrekvensen' var et vesentlig hinder for større utbredelse.

[icc]

Mange gode argumenter her.

 

Når det kommer til å plassere skylden så er dette ene og alene utviklerene av operativsystemene som skal ha den. I allefall nesten. Problemet er langt fra å kjøre fler tråder, du kan lett dele en stor oppgave i to og la en annen tråd ta seg av halvparten. Problemet er at 2 tråder i et program aldri ville kunne kjøre samtidig uansett hvor mange kjerner du har. Det bare virker som de kjører samtidig. To kjerner / cpu'er vil aldri kunne aksessere samme minne samtidig. Derfor vil heller aldri et program kunne utnytte flere kjerner samtidig uansett hvor mange tråder du kjører. Tråder er egentlig bare for å kunne være to plassere i koden simulert samtidig. En annen liten positiv ting med tråder er jo mindre i/o headers og tull slik at det virker som det går litt kjappere med tråder.

[WhiteFire]

Dette kan jo være interessant: TPL.

[Anders Jensen]

Mange gode argumenter her.

Uten å kommentere egne innlegg, da det blir litt cheese, så kan jeg si meg enig i det.

 

Når det kommer til å plassere skylden så er dette ene og alene utviklerene av operativsystemene som skal ha den. I allefall nesten. Problemet er langt fra å kjøre fler tråder, du kan lett dele en stor oppgave i to og la en annen tråd ta seg av halvparten. Problemet er at 2 tråder i et program aldri ville kunne kjøre samtidig uansett hvor mange kjerner du har. Det bare virker som de kjører samtidig. To kjerner / cpu'er vil aldri kunne aksessere samme minne samtidig. Derfor vil heller aldri et program kunne utnytte flere kjerner samtidig uansett hvor mange tråder du kjører. Tråder er egentlig bare for å kunne være to plassere i koden simulert samtidig. En annen liten positiv ting med tråder er jo mindre i/o headers og tull slik at det virker som det går litt kjappere med tråder.

Jeg er redd alt dette er feil.

[DarkSlayer]

Mange gode argumenter her.

Uten å kommentere egne innlegg, da det blir litt cheese, så kan jeg si meg enig i det.

 

Når det kommer til å plassere skylden så er dette ene og alene utviklerene av operativsystemene som skal ha den. I allefall nesten. Problemet er langt fra å kjøre fler tråder, du kan lett dele en stor oppgave i to og la en annen tråd ta seg av halvparten. Problemet er at 2 tråder i et program aldri ville kunne kjøre samtidig uansett hvor mange kjerner du har. Det bare virker som de kjører samtidig. To kjerner / cpu'er vil aldri kunne aksessere samme minne samtidig. Derfor vil heller aldri et program kunne utnytte flere kjerner samtidig uansett hvor mange tråder du kjører. Tråder er egentlig bare for å kunne være to plassere i koden simulert samtidig. En annen liten positiv ting med tråder er jo mindre i/o headers og tull slik at det virker som det går litt kjappere med tråder.

Jeg er redd alt dette er feil.

La oss fikse litt på dette:

Nå er det ikke så ofte jeg gjør denne type programmering... men

 

Om du har muligheten for å dele en jobb opp i flere oppgaver(tråder eller prosesser), så er du ikke garantert at OS vil kjøre dem på hver sin kjerne. Kjører hver sin tråd på hver sin kjerne, så kjører dem faktisk samtidig - men om de kjører på samme kjerne, så sørger OS for at hver tråd får sin tilmålte tid. PS dette kommer helt ann på OS og rammeverk. I java så er det JVM som tar seg av hvor og når hver tråd kjører f.eks.

 

Om 2 jobber ikke deler noe data seg i mellom så er det i grunn ikke store problemet. Men som oftest så er det nettopp det de må gjøre. Når 2 tråder skal ha tilgang til samme data, så finnes det ulike måter å løse det på. Skal man bare lese så er det ikke store problemet, men skal man skrive så må dette skje strengt sekvensielt.

 

Det er ikke noe problem å ha 2 tråder som jobber på samme tabell i en database. Men når begge trådene skal skrive til samme sted, så forsvinner faktisk nytten ved å ha flere tråder. Da må man synkronisere, og dette er en STOR overhead. Med andre ord: Er det lite kollisjoner så går ting bedre. Men er det mye kollisjoner så går ting trengere enn om en hadde 1 tråd.

 

Det koster også mye cpu å opprette tråder, det koster cpu å schedule, og det koster mye cpu å synkronisere. Summa sumarum så går det mye tid i både OS og ditt eget program å håndtere masse tråder. Ergo så er det ikke vits å drive multithreading på småting.

En annen ting er at effektiviteten totalt sett går bort i overhead om det blir for mange tråder - spesielt om de skal jobbe på samme data.

 

Og sist - Vår måte å tenke, og løse et problem er ofte strengt sekvensielt. Det er først etter mye erfaring med å løse et bestemt problem at man finner ting som kan løses parallellt et annet sted for å oppnå effektivitet (tenk staten).

[icc]

Om 2 jobber ikke deler noe data seg i mellom så er det i grunn ikke store problemet. Men som oftest så er det nettopp det de må gjøre. Når 2 tråder skal ha tilgang til samme data, så finnes det ulike måter å løse det på. Skal man bare lese så er det ikke store problemet, men skal man skrive så må dette skje strengt sekvensielt.

 

Er mye rett i det du sier, men du må gjerne opp i dyrere og mer avanserte systemer for at dette skal fungere i praksis. Windows XP / vista o.l. har ikke denne type teknologi og derfor simuleres tråder som om de skulle kjøre samtidig. 2 kjerner kan ikke aksessere samme data i minnet uansett om det bare er lesing fordi den rette teknologien ikke er implementert. Så et program, uansett hvor mange tråder vil aldri kunne utnytte mer så en kjerne.

[Anders Jensen]

icc: OS, uansett hvilket, styrer ikke trådsynkroniseringen. Alt OS gjør er å tildele hvilken tråd som skal kjøre på hvilken kjerne. Hva slags minne hver tråd har aksess til styres på prosessnivå i windows og alle tråder fra samme prosess kan fint skrive samtidig til det samme området i minnet uten at OS vil blande seg inn i det på noe som helst vis. Resultatet av et slikt program vil imidlertid bli fullstendig ubrukelig, men det er en annen sak.

[Arve Systad]

Er riktig at fleire kjernar ikkje kan aksessere minne samtidig, så det dei gjer er å hente ut data etter tur og legge i sitt eiget vesle, superraske minne (cache på prosessoren) som dei kan arbeide frå. Dette måtte dei gjort uansett, så om det blir sendt data vekselvis til kjerne A og B i ein kontinuerlig straum, kan begge kjernane få arbeide med sitt heile tida. Sett at oppgåva er tilpassa det, sjølvsagt. Er oppgåva for lita blir det mykje dødtid fordi du må vente på minnet.

[DarkSlayer]

Det jeg tenkte på var at man ikke trenger å kjøre syncronisering for at 2 tråder skal lese fra samme minne.

Skulle vel legge inn noe om at io bussen antagelig ikke takler slikt, men det er litt bagatell.

 

Men ja ... io er vel det som begynner seriøst å bli flaskehals.

 

Men poenget mitt var vel litt det at multithreading/multiprocessing er et tveegget sverd. Det er ikke bare å programmere opp en masse parallelle jobber - Det er faktisk ganske mye å ta hensyn til.

 

Men Gartner sitt synspunkt var jo at Windows/Linux etc ikke takler 256kjerner - som vi potensielt kan sette sammen litt senere i 2009.

Jeg jobber stort sett med web, og da er det ikke vanskelig å tenke seg et scenario der min sekvensielle jobb for å hoste opp en webside, kan startes av 1000vis av brukere på en gang - og derfor potensielt ta i bruk 256kjerner ... men så blir jeg hindret av begrensninger i OS.

Endret 30. januar 2009 av DarkSlayer

[brsseb]

Slapp av folkens. Dette fikser Obama i løpet av neste uke.. :!:

[Simen1]

Vel jeg er grunnleggende uenig i den evolusjonære tilnærmingen da problemet ikke ligger i hvilke instruksjoner som er implementert, men hvordan de er organisert. En jump, load, store eller add instruksjon er like relevant i dag som den var for 60 år siden og disse utgjør ca 80% av all kode.

Bare ta en titt over på SSE (SIMD) og se hva Intel har fått til med utvidelser der. Utvidelsene både reorganiserer og slår sammen flere operasjoner i en. Det er snakk om de ~80% av all kode: jump, load, store og add. Ganske mye programvare (med videokodeker som stjerneeksempel) får enorm ytelseøkning på grunn av disse utvidelsene.

 

Jeg ser til og med for meg at IA64 kan innføres på en evolusjonær måte.

[Anders Jensen]

Vel jeg er grunnleggende uenig i den evolusjonære tilnærmingen da problemet ikke ligger i hvilke instruksjoner som er implementert, men hvordan de er organisert. En jump, load, store eller add instruksjon er like relevant i dag som den var for 60 år siden og disse utgjør ca 80% av all kode.

Bare ta en titt over på SSE (SIMD) og se hva Intel har fått til med utvidelser der. Utvidelsene både reorganiserer og slår sammen flere operasjoner i en. Det er snakk om de ~80% av all kode: jump, load, store og add. Ganske mye programvare (med videokodeker som stjerneeksempel) får enorm ytelseøkning på grunn av disse utvidelsene.

Ja de har gjort en del på SIMD siden, men utelukkende for parallell kode. Denne tråden og artikkelen handler om at programvaren ikke er så enkel å parallellisere. Om kun få år så vil parallelle problemer være å anse som trivielle fordi du kan få nesten ubegrenset parallell regnekraft fra massivt parallelle prosesseringsenheter som Cell, GPU, Niagara og Larrabee. Til en viss grad er dette sant allerede i dag. Hvis du ikke har mulighet til/kan/har tid eller ressurser til å parallellisere koden din i stor nok grad så er du avhengig av å få kjøpt en CPU med raskere sekvensiell ytelse. SIMD hjelper ingenting da. Faktisk vil det være flere problemer som lar seg parallellisere på Niagara og Larrabee enn på en SIMD enhet, da disse ikke er avhengig av data alignment og tilstedeværelsen av parallelle instruksjoner av nøyaktig samme type. SIMD er egentlig bare løkke utrulling, den enklest tilgjengelige parallelliteten.

Jeg ser til og med for meg at IA64 kan innføres på en evolusjonær måte.

Det kan nok innføres gradvis, men for å få dette utviklet var det nødvendig å gå drastisk til verks. Fordelene med dette kan du se for fullt i Secure64 sin DNS server. Hvor mange er det som kan levere en x64 server som med letthet besvarer DNS oppslag uten nevneverdig forsinkelse selv under et kraftig DDOS angrep og samtidig gjør brannmurer overflødig? En kan vel egentlig lure på om x64 maskiner har noen fremmtid som helst på Internett...

 

Uansett er det nå ganske smertefritt å bytte ISA i disse dager enten du går til x64, x86, arm, IA64 osv. Det er så mye kode der ute som støtter disse arkitekturene at du kan løse nesten hvilken som helst serveroppgave med hvilket som helst ISA. På desktop er det imidlertid en del som gjenstår, men jeg regner med at det kommer for full fart i løpet av de neste par årene.

 

Arve Systad: to ting;

1) Ja en minnekontroller vil serialisere aksess til samme minneområde. I en NUMA maskin er det imidlertid ikke gitt at den CPUen som får aksess først er den som får data levert først. Derfor er det litt meningsløst å si at de ikke kan aksessere minnet sammtidig for det er nettopp hva de gjør. Tar du samtidig hensyn til at de fleste maskiner begynner å få flere separate minnekontrollere (er vel bare C2D chipsettene som ikke har det) så blir det jo enda mer meningsløst å si at en ikke kan jobbe i parallell mot minnet.

 

2) Du beskriver cache nesten som et lokalt buffer slik en har implementert i Cell. Det er ikke slik en cache fungerer. CPU aksesserer RAM, cache lagrer de data som blir hentet i tilfelle CPU skulle finne på å aksessere samme området på nytt, hvilket er veldig sannsynlig. CPU kan imidlertid ikke se en cache, og den har ingen formening om all orkestreringen som foregår i bakgrunnen for å sørge for at cache er koherent med andre CPU cache (og DMA kontrollere) i maskinen. Faktisk så bryter cacheing med din første feiltakelse (1), fordi samme minneadresse kan være cachet i flere separate cacheområder og dermed tilbyr maskinen sann parallell tilgang til samme minneområde så lenge ingen skriver til dette området. Da vil nemlig cache coherency protokollen slå inn og serialisere skriving mot minneadressen. Det er denne cache coherency protokollen som gjør multi CPU systemer så uendelig mye enklere å programmere enn en GPU som har separate minneområder med egne adresser og uten noen form for coherency. Det er også samme cache coherency som gjør multi CPU systemer så mye mer komplisert og lite skalerbare på hardware nivå i forhold til GPU.

Endret 1. februar 2009 av Anders Jensen