MIT-rapport: Når prosessorene ikke kan bli kjappere, må utviklerne skrive smartere kode [Ekstra]

[Kurt Lekanger]

MIT-rapport: Når prosessorene ikke kan bli kjappere, må utviklerne skrive smartere kode [Ekstra]

[inside_980467]

Det at de fleste programmer er ineffektive, betyr også at de fører til langt høyere strømforbruk enn nødvendig.

Grønn programmering = effektive programmer

[Simen1]

Sånn går det når det er to vidt forskjellige parter som betaler regninga for optimering av programvare og innkjøp/drift av maskinvare. Hadde begge regninger blitt betalt av samme selskap og de to miljøene snakket sammen så kunne man spart mye. Selv om 60 000x var et drøyt eksempel, tror jeg det er veldig mye å hente..

[morten7]

52 minutes ago, Simen1 said:

Sånn går det når det er to vidt forskjellige parter som betaler regninga for optimering av programvare og innkjøp/drift av maskinvare. Hadde begge regninger blitt betalt av samme selskap og de to miljøene snakket sammen så kunne man spart mye. Selv om 60 000x var et drøyt eksempel, tror jeg det er veldig mye å hente..

Antar basert på egen erfaring at mer enn 90% av det offentlige har egne ansatte og konsulenter som sitter såpass tett på at de har et forhold til det. Men igjen, er det verdt å spare 200kr i strøm i året ved å bruke 50timer ekstra, på noe som lever i 5-10år?

Når det kommer til Python er det svært raskt og enkelt å prototype i mot Java. Koden som kjøres blir kompilert til C og ved neste kjøring er det C-koden som benyttes. Også vanlig å optimalisere Python både å bruke tillegg og ved å bytte ut delene som er CPU-krevende med C-kode. Eksempelet i artikkelen bør sånn sett ikke leses som at bør velge noe annet enn Python, men ha et forhold til DevOps (som de aller fleste allerede har).

Ikke noe nytt med andre ord.

Endret 8. juni 2020 av morten7

[Simen1]

morten7 skrev (3 minutter siden):

Antar basert på egen erfaring at mer enn 90% av det offentlige har egne ansatte og konsulenter som sitter såpass tett på at de har et forhold til det. Men igjen, er det verdt å spare 200kr i strøm i året ved å bruke 50timer ekstra, på noe som lever i 5-10år?

Når det kommer til Python er det svært raskt og enkelt å prototype i mot Java. Koden som kjøres blir kompilert til C og ved neste kjøring er det C-koden som benyttes. Også vanlig å optimalisere Python både å bruke tillegg og ved å bytte ut delene som er CPU-krevende med C-kode. Eksempelet i artikkelen bør sånn sett ikke leses som at bør velge noe annet enn Python, men ha et forhold til DevOps (som de aller fleste allerede har).

Ikke noe nytt med andre ord.

Er det en lite ytelsekrevende one-off programvare for en spesifikk kunde? - Da er det nok best å spare de 50 timene. Mye programvare programmeres derimot for bruk i høyt antall eksemplarer, gjerne hos et høyt antall kunder, eller at det krever mye effekt å gjøre jobben. En måte å løse det på er å kaste kraftige maskinparker etter den og løse det på den måten. Det koster penger selvsagt. Kjører man litt tunge oppgaver så har man kanskje en egen regnemaskin eller leier seg kapasitet eksternt. Ofte er energikostnaden av en kontinuerlig brukt regnemaskin i størrelseorden 3-4 ganger høyere enn prisen på regnemaskina. Da blir det fort lønnsomt å investere de 50 timene.

[Ivar Nesje]

Her slår man virkelig inn åpne dører. Det viktigste er at et program er korrekt. Et program som er feil, vil aldri kunne regne ut rett svar. Å skrive en god matrisemultiplikasjon som sørger for at prosessoren ikke kaster bort 99.999 prosent av tiden på å vente på å hente nye tall fra minne er en enormt vanskelig oppgave, men det finnes ferdig kode som har løst det problemet. Bruk ferdig kode som allerede er optimalisert for slike oppgaver.

Effektive programmer er noen ganger viktig, men er utrolig vanskelig. Ofte vil ytelsestriks som reduserer kjøretiden i et program til 1% av orginalprogrammet, øke kjøretiden på et annet. Derfor anbefaler mange at man først og fremst optimaliserer for lesbarhet og korrekthet. Hvis ytelsen blir for dårlig og man må skrive mindre lesbar kode, så må man passe på at man faktisk måler effekten. Kjøretiden i programmer domineres nesten alltid av en veldig liten del av programmet, og optimalisering av de andre delene vil knapt være målbart.

Endret 8. juni 2020 av Ivar Nesje
Del setning i to

[Gjest Slettet-aEAbw77a]

Skulle likt å sett flere kode eksempler, som f.eks Java og C versjonen. Samt den optimaliserte koden de endte opp med, som er 60 000 ganger mer effektiv

[tjavel]

Noe av problemet er tullete abstraksjoner og over-engineering på høyere nivå.

Det er ikke alltid sånn, micro services og containere er nyttige så lenge en ikke forsøker splitte for en hver pris der bindingene i datamodellen er for tette til å klare det.

Skrekk-eksempel på feil-abstraksjoner er delen av JPA/Hibernate som forsøker å få det å aksessere en relasjons-database ut til å se ut omtrent som man bare jobber mot objekter i minne.

Så noe som ser ut som bare hente en liste av objekter fyker ned mot databasen og henter en masse objekter alt etter hva implementasjon er. Uleselig kode med "managed objets" som bryter med principle of least surprise om en ikke er flittig med DAOer og som må attaches igjen om de serialiseres og deserialiseres selv om primary keyen og annen nødvendig info er der.

Så blir dette for tregt og man legger caching på toppen for å komme seg rundt det om øker kompleksiteten ytterligere.

En relasjons-database og SQL og objekter i minne er to vidt forskjellige konsepter, ikke forsøk å blande de på grunn av en oppfunnet "impedance mismatch". Det er ikke noen mismatch. En relasjonsdatabase er en relasjonsdatabase og noe annet enn lokale objekter. Skal en forsøke mappe alle systemer som ikke er konseptuelt det samme over i noe annet i stedet for bare skrive koden for å kalle ett system fra et annet?

Den aksesseres med SQL (evt HQL, JPQL eller LINQ), et helt annet mønster. Den er bygd for å optimalisering av query kjøring på databaseserveren. Ikke flytt joins til klientsiden, la mest mulig hentes ut i fra databasen. SQL er et framifrå språk å uttrykke søk i, er ikke tilfeldig at også NoSQL databaser har deklarative query språk.

 

For å føle meg ordentlig gammel her så husker jeg midten av 90 tallet da jeg kjørte en IDE relativt smooth på 32MB minne og 50Mhz prosessor.

I dag ser jeg i task manager at IDEen fyker opp på snart 1GB minne når jeg navigerer typehierarkiet i Java kode og min tipp topp bærbare blir sørpe treg.

Endret 9. juni 2020 av tjavel

[EremittPåTur]

Rask kode er også kode full av feil

 

[Ximalas]

 

13 hours ago, omBratteng said:

Skulle likt å sett flere kode eksempler, som f.eks Java og C versjonen. Samt den optimaliserte koden de endte opp med, som er 60 000 ganger mer effektiv

https://zenodo.org/record/3715525

Endret 9. juni 2020 av Ximalas
Manglet sitering. Grensesnittet i digi.no er ikke like bra som hos diskusjon.no

[tjavel]

23 minutes ago, EremittPåTur said:

Rask kode er også kode full av feil

 

Kommer an på hva du optimaliserer. Om du fin-optimaliserer med å tyne ut færrest mulig CPU-instruksjoner så kan det være det, men som noen andre sa, da bruker man optimaliserte biblioteker. En bør unngå å bruke tid på mikro-optimaliseringer.

Rask kode havner en del om å organisere datamodellen riktig i forhold til hva det er man modellerer og hvor dataene ligger i hele systemet, f.eks på en annen maskin. Også i hvilke algoritmer en bruker og at dataene som er nødvendige for å kjøre en rask algoritme er tilgjengelig der en kjører de.

Dårlig overordna design og modularitet i utgangspunktet vil medføre masse kludges og kludges på de igjen for å få ting til å kjøre raskt nok.

Skalerbar kode og algoritmisk kompleksitet er viktigere enn at hver kodelinjer i en kodesnutt er så rask som mulig i seg selv.

 

[EremittPåTur]

10 hours ago, tjavel said:

Kommer an på hva du optimaliserer. Om du fin-optimaliserer med å tyne ut færrest mulig CPU-instruksjoner så kan det være det, men som noen andre sa, da bruker man optimaliserte biblioteker. En bør unngå å bruke tid på mikro-optimaliseringer.

Rask kode havner en del om å organisere datamodellen riktig i forhold til hva det er man modellerer og hvor dataene ligger i hele systemet, f.eks på en annen maskin. Også i hvilke algoritmer en bruker og at dataene som er nødvendige for å kjøre en rask algoritme er tilgjengelig der en kjører de.

Dårlig overordna design og modularitet i utgangspunktet vil medføre masse kludges og kludges på de igjen for å få ting til å kjøre raskt nok.

Skalerbar kode og algoritmisk kompleksitet er viktigere enn at hver kodelinjer i en kodesnutt er så rask som mulig i seg selv.

 

Sorry, jeg som ikke sjekket hva som kom ut av tastamusen..

Skulle stått

"Rask koding er også koding full av feil" 

Ett helt annet budskap med andre ord.

Jeg skrev nok for fort??!!

Poenget mitt er at om en utvikler må bruke tid på å effektivisere koden sin så den kjører fortere så krever det at man , kanskje, tenker bedre i gjennom  hva en skriver. Kan jo håpe på det.

 

Endret 9. juni 2020 av EremittPåTur

[siDDis]

Når det kommer til Python er det svært raskt og enkelt å prototype i mot Java. Koden som kjøres blir kompilert til C og ved neste kjøring er det C-koden som benyttes. Også vanlig å optimalisere Python både å bruke tillegg og ved å bytte ut delene som er CPU-krevende med C-kode.

Nei, Python er enklere, samtidig som det igjen blir vanskeligere. Python kode blir kompilert i VM'en, akkurat som med Java til byte code. Men Java har mye mer avanserte optimalisering i VM'en som gjør at Java er i mange tilfeller blir like raskt eller raskere enn C. Fordelen med Java vs C er at du ikke lenger trenger å tenke på memory management og kan løse problemer raskere enn med C med tilsvarende ytelse. C har fordeler med at du er nærmere maskinvaren og kan bruke diverse cpu instruksjoner direkte. Dette er f.eks abstrahert vekk i Java. Men...

Python som med Java har også tilgang til C biblioteker. Flaskehalsen i begge miljøer er kopiering av data mellom ditt program og c biblioteket. Numpy f.eks oppretter datastrukturene på C siden, så du kan lynkjapt utføre manipulasjoner med å kalle på metoder. Det kan du også gjøre med Java.

Men for å ta et annet eksempel, en av mine favorittdatabaser for å prosessere tidsserie data er ClickHouse. På en AMD Epyc med minst 64 kjerner kan du forvente å prosessere 50 milliarder "excel" rader i sekundet!!! Dette ved hjelp av flere iotråder som vektoriserer data med SIMD(SSE) instruksjoner. Hadoop/Spark kan gå å legge seg ?

[Arne Sommerfelt]

Optimalisering av kode er viktig og noe jeg har jobbet mye med, men denne artikkelen står i fare for å tegne et bilde av at optimalisering handler om å først velge riktig språk. Å bytte språk er i min erfaring som regel unødvendig og kun en siste utvei. I mange tilfeller finnes hele eller deler av algoritmen allerede ferdig optimalisert. Matrisemultiplikasjon anser jeg som et naivt og uinteressant eksempel å bygge en artikkel på. Denne funksjonen finnes tilgjengelig som ferdig optimaliser biblioteksfunksjon i veldig mange språk, og i python i særdeleshet. Altså trenger man her bare å bytte ut de 3 nøstede løkkene med et enkelt funksjonskall på en linje.

Den kompetente programmerer velger grovt sett blant 5 ulike tiltak:

1) Algoritmisk optimalisering (f.eks. har store matriser ofte mange nuller og det kan utnyttes til å oppnå raskere multiplikasjon),

2) Finne hele eller deler av algoritmen som ferdig optimalisert modul som kan kalles fra det språket du allerede bruker.

3) Grovkornet parallelisering (MIMD eller multiprosessering)

4) Finkornet parallelisering (SIMD eller vektorisering med f.eks AVX eller GPU)

5) Omkoding fra tolket (interpreted) til kompilert kode.

Punktene 1,2,3 og 4 er ofte tilgjengelig uten å bytte språk.

Den sistnevnte omkodingen i 5) kan også foregå på mange måter. I f.eks. Python som jeg kjenner godt, kan man i de noen tilfeller bare skrive @numba.jit over en funksjonsdefinisjon så går koden 100 ganger fortere. Alternativt kan man bytte Python-dialekt til Cython som er mye mindre arbeidskrevende enn å kode helt om til C, - som altså må anses som siste utvei.

PS. Jeg har skummet originalartikkelen som egentlig fokuser mer på andre ting enn å velge rett programmeringsspråk. Den innledningsvis et spektakulære eksempel på hastighetsforbedring som de selv omtaler som naivt. Altså er dette først og fremst ment som lokkemat for å få folk til å lese, - og det har de jo lykkes med...

[[email protected]]

Amen, Brother! :-)

[[email protected]]

Så har vi den berømte "Premature optimalization is the root of all Evil"...
Den gjelder i aller høyeste grad ennå.

Først skriver man forståelig kode som beviselig løser problemet korrekt.
Viser det seg så at ytelse (i enhver form; tid, ressursbruk, strøm, etc.) blir et problem, bruken man energi på å optimalisere.