- Deltakere: Simen Fredriksen, Stian Blankenberg, Jone Manneråk, Kristian Hagberg, Tarjei Taxerås og Rasmus Sørby
- Nicolay Leknes og Tommy Nilsson deltok på første gjennomgang av ICA02.
Vi lagde ny repostory for ICAen fordi vi følte at den gamle repostorien var uryddig og uoversiktelig. Alle i gruppen har jobbet med oppgavene, men alle har ikke jobbet på egen PC. Av disse grunnene har ikke alle i gruppen commitet.
NB: Dersom bildene ikke fungerer kan de bli funnet i levert PDF-fil.
Det er ikke mulig å finne nøyaktig antall siden det varierer hele tiden. Det meste som skjer på en pc krever en egen prosess, selv tastetrykk. Prosessene som ikke kjører kommer opp som suspendert, dette betyr at de er lastet inn i hovedminnet, men ikke bruker noe prosessorkraft. De kan derfra enkelt endre status til kjørende. Er brukt for prosesser som “venter” på å bli startet. Hos oss var det nettlesere som stod for hovedbruket av minne. Google Chrome er her godt kjent for å kreve store mengder minne, en av grunnene til dette er at den splitter det meste nettleseren består av i mindre deler. Dette forhindrer at resten av nettleseren crasher hvis en plug-in gjør det, men fører igjen til duplikater av prosesser. Det er mye informasjon som blir midlertidig lagret i minnet når man har en nettleser oppe, spesielt ved bruk av flere faner, her skjer det igjen duplisering av prosesser. For at en prosess skal kjøre kreves det en prosessor, hovedminne, input-enhet og output-enhet. Prosessoren utfører kalkulasjonene som kreves for at et program skal kjøre. Det prosessoren kalkulerer blir underveis lagret i hovedminnet. Prosessoren kan igjen hente ting som er lagret i hovedminnet for å utføre videre kalkulasjoner. For å utføre prosesser kreves det en input-enhet som gir instruksjoner til prosessoren, dette er typisk fysiske ting som tastatur og datamus. Output-enheten er slik man mottar informasjonen som prosessoren produserer, dette kan være andre fysiske ting som en skjerm, en printer, eller høyttalere.
For å skrive koden fant vi først ut hvor i ubuntu vi ville lage koden. Etter å ha valgt en mappe, skrev vi inn “nano hello.go” for å lage et hello.go-program.
Dette er et bilde av koden.
I dette eksempelet ville vi lage kode for Windows. Dette ble gjort ved å spesifisere OS=windows (GOOS=windows) og GOARCH=amd64. Dette er spesifikasjonene for en av
PC’ene og kan variere for andre plattformer. Dette blir altså til en .exe-fil for windows.
Her ser vi kommandoen for å gjøre om filen til en exe-fil og en “ls”-kommando for å bekrefte at filen ligger der. Filen vi bruker er hello.exe. Etter dette lastet vi opp koden via github. Vi har ikke tatt bilder av dette ettersom vi regner med at folk kjenner til den vanlige måten å laste opp/ned kode eller prosjekter fra Github. Dette er kanskje ikke den optimale måten å gjøre det på, spesielt med tanke på at filen ble en del større enn vanlig kode, men det fungerte greit og det var få problemer med det. Etter at filen var lastet ned, slettet vi den, fordi det generelt sett ikke er god praksis å ha slike filtyper på GitHub. En bedre måte å overføre på er gjennom SCP. SCP står for Secure Copy Protocol, og er en god måte å overføre fra en remote maskin til en local. Dette kan gjøres ved å bruke terminalen slik: scp -i ~downloads/Pem-filnavn ubuntu@IP:/home/ubuntu/filnavn. For meg vil det da se slik ut: “scp -i ~downloads/RRS.pem ubuntu@IP:home/ubuntu/Hello.exe .” Da vil Hello.exe-filen bli lastet ned i den mappen jeg befinner meg i, i terminalen.
Her er et eksempel på hvordan man kan skrive det i ATOM. Dette er da int32.
Det vi har gjort her er at vi har laget tester som produserer feil. Det vi får som feilmelding på int32 er "constant 2147483648 overflows". Det vil da si at den er ikke innenfor int32 sin rekkevidde. Settet av alle signerte 32-bits heltall er kun innenfor dette rekkevidde (-2147483648 til 2147483647), men vi gikk utenfor denne rekkevidden, fordi da produserer den feil. Slik som i eksempelet over.
Her har vi da tatt inn to parametere og skrevet de ut i Powershell. Da vil det bli slik som dette:
Det som skjer er at vi legger inn to argumenter (parametere) slik at den skal skrive det ut når vi prøver å kjøre denne i powershell. Det som blir gjort er at filen blir kjørt sammen med to variabler (tall) slik powershell kan regne ut “regnestykke” og dermed printer svaret rett under. 1+2=3.
Logaritmisk graf som viser de tre forskjellige benchmark-testene opp mot hverandre. Benchmark-testene går gjennom en sortering av henholdsvis 100, 1000 og 10000 tall. Det kommer her tydelig fram effektiviteten til QuickSort sammenlignet med BubbleSort; ved 1000 tall ligger QuickSort på rundt 1 000 000 nanosekunder, mens begge BSort testene går forbi 50 000 000 ns (BSortModified ender her opp på langt over 300 000 000 ns). Sammenlignet med Big-O regnearket får vi bekreftet det vi så ovenfor; til tross for at BSort har potensial til å være bedre enn QSort, er den vanligvis suboptimal. Det kommer også fram at BSortModified bare er optimal sammenlignet med BSort opp til et viss punkt. Dette er sammenlignbart med andre sorteringsalgoritmer hvor vanligvis optimal algoritme blir suboptimal sammenlignet med en annen etter et viss punkt. Selv om vi bruker relativt få verdier i testene, kan vi konkludere med at sorteringsfunksjonene er gjennomsnittlige i forhold til Big-O basert på resultatet.
Først kjørte vi main_boring.go via bash. Denne kjører kontinuerlig, og printer ut index +1 hvert sekund. Vi lastet deretter ned Process Explorer. Man kan herfra også enkelt avslutte prosessen ved å bruke ctrl-c kommandoen.
Her kan man se en liste over kjørende prosesser, sammen med utfyllende informasjon om hvor mye CPU de bruker, og hvor mange threads de er knyttet opp med. Man kan også enkelt avslutte prosessen herfra ved å høyreklikke på den og velge “kill process”. Vi fant bash på denne listen, og valgte videre den kjørende boring prosessen.
Her kan man se 5 forskjellige threads som er knyttet opp til boring prosessen. Trykker man inn på disse står det at samtlige prosesser er sleeping, de venter altså på nye ordre.
Mens vi kjørte main_boring.go på den virtuelle serveren gjennom et vindu, kunne vi se alle prosessene gjennom et nytt vindu. Her brukte vi et tillegg som het htop for lettere visualisering av prosesser.
Man kan også bruke kommandoen “ps aux | grep main_boring;” for å finne prosesser som inneholder main_boring i informasjonen. Her får vi opp 3 forskjellige prosesser.
Ved å bruke PID’en til den øverste prosessen (27628) kunne vi finne hvor mange tråder som er tilknyttet denne prosessen. Her kan vi også se hvilken status trådene har ved å se hvilke symbol de har under “S” (status). Vi kan da se at samtlige av trådene er sleeping.
Her er resultatet ved undersøkelse av main_boring_goroutine.go:
Boring10 funksjonen vil nok være mer dominerende med å få designert prosessorkraft ettersom den skriver ut tall i et mye høyere tempo.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent