Dagens programvare er gammeldags

[int20h]

Programvareindustrien henger etter når det gjelder utnyttelse av flere kjerner.

 

Les mer

[PacAnimal]

Her kan det jo for det første diskuteres om programvareprodusentene i det hele tatt er enige i at å stappe flest mulig prosessorer i en maskin ER fremtidsrettet, eller om de bare synes prosessorprodusentene er tåpelige som ikke klarer å kjøre en enkelt kjerne raskere og derfor kompenserer med å putte inn flere av dem.

 

Dessuten er det jo slik at så godt som alle kjører mer enn ett program av gangen og vil derfor til en viss grad få utnyttet flere kjerner uavhengig av om programmene i seg selv støtter det.

 

Hvilke programmer er det forøvrig som ligger så veldig i bakleksa? Ikke alt trenger flere kjerner for å kjøre effektivt, og mange spill og tunge programmer som f.eks. photoshop og diverse videoprogrammer, pluss 3D-rendering og slikt gjør jo det allerede. Jeg gir da beng i om winamp bruker en eller flere kjerner på å spille musikk...

[Anders Jensen]

Tja, vet ikke om jeg vil legge all skylden på programvareprodusentene. Flertråding er veldig vanskelig og kan være noe forferdelig svineri å finne feil i siden programmene typisk vil kjøre forskjellig fra gang til gang (ikke deterministiske). Med andre ord kan det være alvorlige feil i programvaren som bare inntreffer en sjelden gang og som ikke lar seg reprodusere av en software tester innen rimelig tid.

 

Hardware produsentene har funnet ut at det tradisjonelle Out of order designet var en blindgate og lempet dermed problemet over på software industrien da de innså at de heller vil sitte på ræva å lage kopier av det de allerede kunne, isteden for å skaffe oss bedre ytelse per tråd. Nå skal det sies at all verdens nytenkning ikke kunne reddet oss fra en situasjon der ytelsen per tråd før eller siden stagnerer, men den veggen behøver ikke å være her riktig enda.

 

Det er mye kjent, men noe krevende, som kan gjøres internt i kjernene og det er mye som kan gjøres med minnehierarkiene som kan øke ytelsen per tråd.

 

Cell har tatt et viktig steg på minnehierarkiet ved å implementere flere lokale adresseområder. Det er noe herk å programmere for noe slikt, minst like ille som flertråding, men det kan også gi svært mye. Intel har også planer for integrert RAM i ganske høvelige mengder. Det vil gi omtrent tilsvarende effekt som integrering av minnekontrolleren.

 

Når det gjelder kjernene, så har Nehalem kommet med litt mer av alt vi har sett før, men ikke noe nytt. Power6 kom med en del interessante teknikker (runahead f.eks) og delvis OoO kjerne uten register renaming for FP og med høye klokkefrekvenser, som er bra. Intel Poulson (Neste gen Itanium) er naturlig nok den neste store kandidaten til CPU kjerne innovasjon sammen med IBM Power7. La oss håpe de tar ansvar her isteden for å lempe stadig flere og like dårlige kjerner over på programvareindustrien. Kvantitet kan faktisk ikke oppveie for kvalitet.

[Sajkow]

Tror nok flerkjernede prosessorer har kommet for å bli (det er vel en grunn til at industrien lager dem slik...), så det er vel på tide at programvareprodusenter også begynner å tenke litt mer fremtidsrettet og gi den store andel av konsumenter som faktisk eier en flerkjernet prosessor litt utbytte for pengene. Og om noen skulle argumentere imot, så spør deg selv "Hvorfor ikke?"

[Brukerkonto inaktiv]

Slettet av brukeren

Endret 6. mars 2009 av omaha

[Kimble]

Nå er det slett ikke alle oppgaver som lar seg parallellisere. Det vil også være avhengig av algoritme og implementasjon hvor mange kjerner en klarer å utnytte. Andelen kode som må kjøre serielt begrenser veldig effektivt hvor mange kjerner en vil kunne utnytte.

 

Det er slett ikke garantert at en oppgave vil gå raskere på 8 enn 4 kjerner. Dersom 50% av koden må kjøres serielt vil du ikke få utnyttet mer enn to kjerner uansett hvor mange du måtte ha tilgjengelig.

 

Så det er en del problemer programvarebransjen må løse. Tjenere med mange klienter vil selvfølgelig kunne dra nytte av en mengde kjerner da det er separate operasjoner.

[Webtroll]

Jeg aner ikke hvordan operativsystemene ordner arbeidet for prosessoren, men kan man ikke fordele programmer slik at de får tildelt "sin" prosessor når det er noe som skal utføres?

 

Gleder meg til den tid at man kan kjøre alle kjerner samtidig, hele tiden(nesten).

[krigun]

Dagens programvare er gammeldags er resultatet av at dagens programmeringspråk er gammeldags.

[siDDis]

Dagens programvare er gammeldags er resultatet av at dagens programmeringspråk er gammeldags.

Jepp, kor mange er det som faktisk har høyrt om Erlang?

[Anders Jensen]

Det er slett ikke garantert at en oppgave vil gå raskere på 8 enn 4 kjerner. Dersom 50% av koden må kjøres serielt vil du ikke få utnyttet mer enn to kjerner uansett hvor mange du måtte ha tilgjengelig.

Vel det er ikke helt riktig. Hvis 50% er serielt så er det i utgangspunktet ikke noe hinder for å utnytte uendelig mange kjerner, men uansett hvor mange du bruker så vil du aldri kunne kjøre algoritmen på mindre enn halvparten av tiden brukt på å kjøre med kun en kjerne. Det er en forskjell der.

 

Forøvrig er 50% serielt arbeid unormalt mye serielt. Det ligger vel oftere i området 10% og nedover. Det er også noen algoritmer som har en del kommunikasjons overhead. Dette kan medføre at bruk av flere kjerner medfører at programmet kjører tregere. Generelt sett vil alle algoritmer være offer for dette, men det varierer hvor negativ "speedup" inntreffer. Noen algoritmer vil kjøre tregere på to kjerner enn på en kjerne selv med en optimal implementasjon, andre kan kjøre på millioner av kjerner og fremdeles skalere nesten perfekt.

[Zlatzman]

La meg gjøre om litt:

 

Maskinvareprodusentene på bærtur

 

Selv etter flere år med press er stadig programvareutviklere mer interessert i én rask prosessor enn flere mindre raske. Det gjenstår å se når prosessorene gjenspeiler dette.

[DarkSlayer]

Kritik til hw.no:

Digi har en bedre artikel på hva som faktisk er saken. Nemlig at gartner påpeker at om ikke lenge får vi servere med 256kjerner (8 x 16 eller hva det var..)

Problemet er at win/lin/mac har begrensning på 64 kjerner, lin kan økes til det doble. Virtualiseringssoftware har mye lavere kjerneantall da wmware max tar 64, og 4 kjerner pr image. Virtualpc har 24...

 

bla blabal

 

Men om jeg skal holde meg til forumtråden, så kan jeg vel si det slik at det er feil å skyte programmereren.

 

multi-threading/multi-processing er faktisk veldig vanskelig å jobbe med. Det er også vanskelig å identifisere HVOR man kan dele en jobb i flere biter.

 

Så har man kost/nytte verdien. Det å lage en sortering/søk/parsing flertrådet f.eks, tar mye tid, og krever mye testing = høy kostnad VS entrådet programmering av problemet.

Ofte er det filleting programmereren jobber med også. Sortering/søk i en liste på 1000 enheter... hallo 0,00003ms tar jobben.

 

95% av programmerere er ikke istand til å forstå konseptet med multitråding og synkronisering i det hele tatt. Det er bare til å titte på tonnesvis av php kode mot mysql base. Det er fint lite låsing der for å si det slik (altså 2 brukere kan fint kjøre update på samme rad og ende opp med piss). Bare det viser at det er faktisk ikke lett å tenke på dette.

[krigun]

Dagens programvare er gammeldags er resultatet av at dagens programmeringspråk er gammeldags.

Jepp, kor mange er det som faktisk har høyrt om Erlang?

 

Akkurat, det er ikke mange som har hørt om Erlang, og enda færre klarer å relatere seg til konseptene bak funksjonell programmering (unngå tilstand, immutable datastrukturer, osv). Erlang er jo heller ikke en erstatning på dagens språk, men det løser enkelte problemer myye bedre enn hva du kunne gjort med dagens mest brukte språk. Benytte f.eks 64 CPU kjerner effektivt er blant annet en av dem. Det faktum at du ikke har muterbar tilstand gjør at du ikke trenger låsing og synkronisering (med få unntak, seflfølgelig).

[Gjest Slettet-Pqy3rC]

Dagens programvare er gammeldags er resultatet av at dagens programmeringspråk er gammeldags.

Jupp. Skal en få fart på paralellisering må en inn med strukturendring i C++ ol. En endring på linje med tidligere innføring av objektoreintert struktur (C til C++).

[krigun]

Dagens programvare er gammeldags er resultatet av at dagens programmeringspråk er gammeldags.

Jupp. Skal en få fart på paralellisering må en inn med strukturendring i C++ ol. En endring på linje med tidligere innføring av objektoreintert struktur (C til C++).

 

Akkurat, det vi trenger er et "general purpose" språk som har disse egenskapene bygd inn, og som er bakoverkompatibel med eksisterende biblioteker, slik at ikke "hjulet" må skrives på nytt. Men dette er nok litt harde krav

[ATWindsor]

La meg gjøre om litt:

 

Maskinvareprodusentene på bærtur

 

Selv etter flere år med press er stadig programvareutviklere mer interessert i én rask prosessor enn flere mindre raske. Det gjenstår å se når prosessorene gjenspeiler dette.

 

Nå er jo dette et mer komplekst problem enn å bare innse at en superrask CPU er fint og flott.

 

AtW

[Svish]

Her kan det jo for det første diskuteres om programvareprodusentene i det hele tatt er enige i at å stappe flest mulig prosessorer i en maskin ER fremtidsrettet, eller om de bare synes prosessorprodusentene er tåpelige som ikke klarer å kjøre en enkelt kjerne raskere og derfor kompenserer med å putte inn flere av dem.

 

Dessuten er det jo slik at så godt som alle kjører mer enn ett program av gangen og vil derfor til en viss grad få utnyttet flere kjerner uavhengig av om programmene i seg selv støtter det.

 

Hvilke programmer er det forøvrig som ligger så veldig i bakleksa? Ikke alt trenger flere kjerner for å kjøre effektivt, og mange spill og tunge programmer som f.eks. photoshop og diverse videoprogrammer, pluss 3D-rendering og slikt gjør jo det allerede. Jeg gir da beng i om winamp bruker en eller flere kjerner på å spille musikk...

 

Kan si meg fullt enig der. Flere prosessorer for meg er stort sett bare det at maskina kan kjøre mykere flere ting samtidig. At et program ikke klarer å sluke opp alt jeg har er jo egentlig bare en fordel... bortsett fra med tanke på spesielle ting som photoshop og slikt som du nevner. men de er jo ganske gode på det allerede om jeg ikke har misforstått helt... mange programmer sliter jo knapt på en kjerne liksom... hvorfor slite for at den skal slite enda mindre på to eller flere?

 

Ser poenget med tanke på det som ble sagt fra digi da. med OSene selv, og virtualisering og slikt...

[Andlier]

Hvis Occam og transputeren hadde fått litt mer oppmerksomhet enn c/c++ gjorde på 80-tallet, så hadde kanskje dette problemet ikke vært et problem i det heletatt. CSP (communicating sequential processes) er i hvertfall en mulig løsning på problemet.

 

Det er virkelig ikke lett å programmere med flere tråder og mutexer/semaforer i c-lignende språk, for å forstå litt mer av problemet er pdf-lefsa: "Little book of semaphores" veldig interessant lesing!

[Arve Systad]

Problemet er vel strengt tatt at det krevast ein heilt fullstendig ny måte å produsere prosessorar på enn i dag om du skal få frekvensen opp noko særlig meir. Det er ikkje veldig mange år igjen med utvikling før forskarane trur dei vil møte veggen på grunn av at ting rett og slett blir for smått. Det er allerede i dag eit problem at ikkje alle elektrona går dit dei helst skal i prosessorane, og difor blir spenninga satt opp. Skal du ha større klokkefrekvens, må spenninga òg settast opp etterkvart. Og då er det plutselig kjølinga som er problemet.

 

Det er vel og forska på optiske prosessorar som kan yte bra. Problemet med dette er vel at dei vil bli alt for store sidan det ikkje er så mykje vi kan gjere med bølgelengd på lys, og skal du då ha svært mange ledarar så blir prosessorane fysisk store i forhold til dagens.

[Anders Jensen]

Transputeren hadde jo et fullstendig løkete instruksjonssett. Kan ikke se hvordan den skulle klare å holde tritt med x64 en gang.