#include <algorithm> #include <iostream> using namespace std; int main() {    // Lager et data-array    int i,c;    int arraySize = 32768;    int data[arraySize];        for (c = 0; c < arraySize; ++c)      {     data[c] = rand() % 256;      }        // Gir tilfeldig tall mellom 0 og 255    // Gir samme array med tall for hver kjøring         // sort(data, data + arraySize);    // sorterter data-arrayet        // Skriver ut de 10 første verdiene    for (c = 0; c < 10; c++)      cout << data[c] << "\n";        // Legger sammen alle tall større enn 127    long sum = 0;        // Ytre løkke for at det skal ta litt tid...    for (i = 0; i < 50000; ++i)      {         // Indre løkke         for (c = 0; c < arraySize; ++c)       {          if (data[c] > 127)            sum += data[c];       }      }        cout << "sum = " << sum << "\n"; }

ChatGPT: Dette fenomenet kan forklares med hvordan moderne prosessorer bruker cache-hukommelse og hvordan 
de forutsier dataadgangsmønstre.

Når du ikke sorterer data-arrayet, er tallene i det tilfeldige. Når du går gjennom arrayet, er det ingen 
klar mønster til tallene du sammenligner med 127, så prosessoren har ingen måte å forutsi hvilke data den 
skal hente fra hovedminnet og laste inn i cachen.

Når du sorterer data-arrayet, blir tallene ordnet i en bestemt rekkefølge. Nå, når du går gjennom arrayet, er 
det en klar sekvens til tallene du sammenligner med 127. Dette gjør det mye lettere for prosessoren å forutsi 
hvilke data den skal hente fra hovedminnet og laste inn i cachen.

Cache-henting er mye raskere enn å hente data fra hovedminnet, så når prosessoren kan forutsi hvilke data den 
trenger å hente, kan den gjøre det på forhånd og spare tid når dataene faktisk trengs. Dette er kjent 
som cache-forvarming.

Så selv om sortering av data-arrayet legger til en ekstra operasjon, gjør det dataadgangen under summen mye 
mer effektiv, noe som fører til en total reduksjon i kjøretid.

Dette er et flott eksempel på hvorfor det noen ganger kan være vanskelig å forutsi ytelsen til et program 
basert på antall operasjoner alene - maskinvareegenskapene og hvordan de samhandler med programmet kan ha 
en stor innvirkning på den faktiske ytelsen.
-------------------------------------------------------------------------------------

Haugerud: Det kan vel ikke stemme? At dataene er sortert påvirker ikke cache, den samme sekvensen av tall 
hentes inn hver gang. Og cache er i begge tilfeller varm etter første runde i løkken. Hva kan dette 
ellers skyldes?

-------------------------------------------------------------------------------------

ChatGPT: Beklager for forvirringen. Du har rett, mine unnskyldninger for feilinformasjonen. Cache-
forutsigbarhet skulle ikke være en faktor her siden vi itererer gjennom hele arrayet sekvensielt 
i begge tilfeller.

Det som faktisk skjer her, er relatert til prosessorens branch prediction. Moderne prosessorer prøver å 
forutsi resultatet av betingede grener (som if-uttalelser) for å forbedre ytelsen. Ved å sortere arrayet, 
gjør vi effektivt if (data[c] > 127)-sjekken mer forutsigbar for prosessoren, noe som fører til færre 
mispredicted branches og dermed raskere utførelse.

Når arrayet er sortert, vil alle tallene større enn 127 være på slutten av arrayet, så prosessoren kan 
effektivt forutsi at if-sjekken vil være false for den første halvparten av arrayet, og true for den andre 
halvparten. Når arrayet ikke er sortert, er resultatet av if-sjekken tilfeldig, noe som fører til mange 
mispredicted branches og dermed tregere utførelse.

Dette er et godt eksempel på hvordan detaljene i prosessorarkitekturen kan påvirke programytelsen 
på uventede måter.
-------------------------------------------------------------------------------------

Haugerud: Ja, den vil vel etterhvert gjette riktig hver gang, helt til man her halvveis i arrayet.
-------------------------------------------------------------------------------------

ChatGPT: Ja, det stemmer! Når du sorterer arrayet, vil prosessoren etter hvert lære å forutsi utfallet av
if-instruksjonen korrekt. I starten vil den forutsi at utfallet alltid er false (siden alle tallene i 
starten av det sorterte arrayet er mindre enn eller lik 127). Når den når midtpunktet i arrayet, vil den 
merke at utfallet plutselig endrer seg til true og vil raskt tilpasse seg denne endringen, og begynner 
å forutsi at utfallet vil være true.

Dermed vil prosessorens branch predictor effektivt "følge" sorteringen av arrayet og oppnå en høy grad 
av nøyaktighet i sine forutsigelser, noe som gjør at koden kjører raskere.

Dette demonstrerer hvordan moderne prosessorer bruker sofistikerte teknikker for å forbedre ytelsen, 
og hvordan egenskapene til dataene dine kan påvirke disse teknikkene. 

-------------------------------------------------------------------------------------

Haugerud: Har dette også hatt sikkerhetsmessige konsekvenser i form av malware?
-------------------------------------------------------------------------------------

ChatGPT: Ja, prosessorfunksjoner som branch prediction og cache-mekanismer kan utnyttes av skadelig 
programvare til å få tilgang til sensitiv informasjon. To kjente eksempler på dette er Spectre og Meltdown 
sikkerhetsfeilene som ble oppdaget i 2018.

    Spectre utnytter prosessorens branch prediction mekanismen til å lure prosessoren til å kjøre 
    instruksjoner som ellers ikke ville blitt kjørt, og deretter få tilgang til resultatene 
    av disse operasjonene gjennom cache.

    Meltdown angriper en optimalisering kalt "ut-av-rekkefølge utførelse" hvor prosessoren utfører 
    instruksjoner i en ikke-lineær rekkefølge for å maksimere ytelsen. Meltdown kan få tilgang til data 
    fra andre programmer og operativsystemet ved å utnytte denne funksjonen.

Disse angrepene er mulige på grunn av den komplekse interaksjonen mellom programvare og maskinvare, og de 
har ført til betydelige endringer i hvordan operativsystemer og prosessorer er designet og implementert 
for å forbedre sikkerheten.

$ ./regn > res.txt 2> err.txt &

$ (time regn) > res.txt 2> err.txt&

for i in {1..6}; do time ./a.out& done

sudo addgroup s123456 sudo

# Allow members of group sudo to execute any command
%sudo	ALL=(ALL:ALL) ALL

$ sudo adduser groupXX os
$ chgrp -R os ~/felles 
$ chmod -R 770 ~/felles 

$ screen -d -m -S felles

$ screen -x felles

 

#! /bin/bash ssh group100@os100.vlab.cs.hioa.no "if [ ! -d ~/tmp ]; then mkdir ~/tmp; fi" ssh group100@os100.vlab.cs.hioa.no "if [ -d ~/tmp/dir ]; then /bin/rm -R ~/tmp/dir; fi" tar cfz dir.tgz -C /tmp dir scp dir.tgz group100@os100.vlab.cs.hioa.no:~/tmp /bin/rm dir.tgz ssh group100@os100.vlab.cs.hioa.no "cd ~/tmp; tar xfz dir.tgz; /bin/rm dir.tgz"

 

#! /bin/bash # Run every night /usr/bin/rsync --delete -a group60@os60.vlab.cs.oslomet.no:/home/group60  /home/s123456/home echo "Backup ble tatt $(date)" >> sync.log

# m h  do# m h  dom mon dow   command
0 3 * * * /home/haugerud/sync.sh > /dev/null 2&>1

 

#! /bin/bash # Run every night # Tillegg for root: /usr/bin/rsync --delete -a root@os60.vlab.cs.hioa.no:/etc  /iu/cube/u0/s123456/home

ssh-keygen -f ~/.ssh/id_rsa -y