- (Oblig)
Følgende viser at det er thread-siblings (på serveren Linux-VM kjører på):
group100@os100:~$ grep "" /sys/devices/system/cpu/cpu*/topology/thread_siblings_list
/sys/devices/system/cpu/cpu0/topology/thread_siblings_list:0,48
/sys/devices/system/cpu/cpu1/topology/thread_siblings_list:1,49
/sys/devices/system/cpu/cpu10/topology/thread_siblings_list:10,58
/sys/devices/system/cpu/cpu11/topology/thread_siblings_list:11,59
/sys/devices/system/cpu/cpu12/topology/thread_siblings_list:12,60
.
.
.
Her er CPU 0 og 48 siblings.
group100@os100:~$ lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
Address sizes: 43 bits physical, 48 bits virtual
CPU(s): 96
On-line CPU(s) list: 0-95
Thread(s) per core: 2
Core(s) per socket: 48
Socket(s): 1
NUMA node(s): 1
Vendor ID: AuthenticAMD
CPU family: 23
Model: 49
Model name: AMD EPYC 7552 48-Core Processor
Stepping: 0
CPU MHz: 3303.166
BogoMIPS: 4391.62
Virtualization: AMD-V
L1d cache: 1.5 MiB
L1i cache: 1.5 MiB
L2 cache: 24 MiB
L3 cache: 192 MiB
NUMA node0 CPU(s): 0-95
'Thread(s) per core: 2' viser at det er to threads per core og altså hyperthreading kjerner.
- (Oblig)
Det tar dobbelt så lang tid når begge tvinges til å kjøre på samme CPU, fordi de ta må bytte på å bruke den samme ALUen.
OS starter dem opp på hver sin CPU og det går da dobbelt så fort.
group100@os100:~$ for i in {1..2}; do time ./a.out & done
Real:10.000 User:9.991 System:0.008 99.98%
Real:10.022 User:10.013 System:0.004 99.95%
group100@os100:~$ for i in {1..2}; do time taskset -c 0 ./a.out & done
Real:20.035 User:10.022 System:0.000 50.02%
Real:20.045 User:10.022 System:0.000 50.00%
- (Oblig)
group100@os100:~$ for i in 0 48; do time taskset -c $i ./regn & done
group100@os100:~$
Real:21.451 User:21.446 System:0.004 99.99%
Real:21.567 User:21.562 System:0.004 100.00%
group100@os100:~$ for i in 0 1; do time taskset -c $i ./regn & done
group100@os100:~$
Real:13.393 User:13.386 System:0.004 99.97%
Real:13.534 User:13.528 System:0.004 99.98%
Det tar vesentlig lenger tid når regn kjører på CPU 0 og CPU 48 som er siblings og faktisk del av samme hyperthreading CPU,
men langt ifra dobbelt så lang tid som det minst ville tatt om man kjørte begge på samme core som ikke var hyperthreading.
Det betyr at hyperthreadingen her har en merkbar effekt.
-
For mem.c er det nesten ingen effekt av hyperthreading:
group100@os100:~$ for i in 0 48; do time taskset -c $i ./a.out & done
group100@os100:~$
Real:1.262 User:1.261 System:0.000 99.88%
Real:1.264 User:1.261 System:0.000 99.78%
group100@os100:~$ for i in 0 49; do time taskset -c $i ./a.out & done
group100@os100:~$
Real:0.643 User:0.639 System:0.000 99.33%
Real:0.643 User:0.643 System:0.000 100.00%
For regnejobben er det overraskende god effekt:
group100@os100:~$ for i in 0 48; do time taskset -c $i ./a.out & done
group100@os100:~$
SUm: 0.000000Real:10.468 User:10.463 System:0.004 99.98%
SUm: 0.000000Real:10.472 User:10.464 System:0.004 99.97%
group100@os100:~$ for i in 0 49; do time taskset -c $i ./a.out & done
group100@os100:~$
SUm: 0.000000Real:10.427 User:10.426 System:0.000 100.00%
SUm: 0.000000Real:10.433 User:10.431 System:0.000 99.99%
Dette viser at det går nesten like raskt på en enkelt hyperthreading CPU som på to uavhengige. Det kan se ut som om den hyperthreading CPUen klarer å få gjort denne beregningen helt parallellt.
- (Oblig)
- (Oblig)
-
#! /bin/bash
docker container stop $(docker ps -q)
for i in {1..9}
do
cont=$(docker container run -p 808$i:80 -dit apbuntu /bin/bash)
docker container exec $cont /bin/bash -c "echo docker 808$i > /var/www/html/index.html"
docker container exec $cont /bin/bash -c "/etc/init.d/apache2 start"
done
- (Oblig)
For hver ny docker instans er det bare litt overhead av konfigurasjon som må lagres i RAM for hver og ikke behov for noe ekstra disk plass. Hver ny VM må ha plass på disk og i RAM til hele Ubuntu operativsystemet i tillegg til hele Apache webserver.
- (Oblig)