In mijn vorige blog heb ik gesproken over de vergadering van de
standaardisatie van C++ in Rapperswil. Laten we nu eens gaan kijken
naar wat er allemaal gaat veranderen in de aanstaande C++ standaard.

Allereerst moet je je realiseren dat het bij programmeren en het
ontwikkelen van programmeertalen gaat over het aanbrengen van
abstractie. In eerste instantie werden computers geprogrammeerd door
nullen en enen in het geheugen te zetten met behulp van schakelaars.
Later werden groepjes van nullen en enen vervangen door octale of
hexadecimale cijfers.

Wat meer abstractie kwam er met de introductie van assembly talen. In
plaats van het binaire 0011 1110 0110 0111 of het hexadecimale 3E 67,
mocht je dan schrijven LOAD A, 103. Je hebt dan niets meer te maken met
nullen en enen, je zegt dat er in een processorregister met de naam A, de
waarde 103 (hexadecimaal: 67) moet worden gezet. De assembler
vertaalt de tekst LOAD A, 103 naar 3E 67.

Maar zelfs dat is niet abstractie genoeg. In het midden van de jaren
50 van de vorige eeuw bedacht een team van IBM een taal waarbij je
wiskundige formules kon schrijven, die dan door een vertaalprogramma
omgezet konden worden naar machinetaal instructies.
Zo kon bijvoorbeeld OPP = BREEDTE * HOOGTE geschreven worden. Het
vertaalprogramma maakte daar zoiets van als:

OPP:     RESERVEER 4 BYTES
BREEDTE: RESERVEER 4 BYTES
HOOGTE:  RESERVEER 4 BYTES
.....
LOAD       A, (BREEDTE) # haal breedte op en stop in register A
LOAD       B, (HOOGTE)  # haal hoogte op en stop in register B
MUL        C, A, B      # vermenigvuldig register A met B en sla op in C
STORE      C, (OPP)     # sla register C op in OPP

Je ziet, je hoeft als programmeur die OPP=BREEDTE*HOOGTE niet meer na
te denken over hoe het moet worden gedaan, alleen maar dat het moet
worden gedaan.

Je vraagt je misschien af: “wat heeft dit allemaal te maken met
C++0X?” Bij de stap van het C++ uit 1998 (met een kleine
koerscorrectie in 2003) naar C++0X worden grote stappen gemaakt die
onder andere het abstractieniveau verhogen.

Mooie voorbeelden zijn meteen twee voor de programmeur zeer zichtbare
nieuwe faciliteiten: auto en het for statement over een range:

Het keyword auto dat nog in de taal zat maar geen echt gebruik meer
had, heeft een nieuwe betekenis gekregen bij het definieren van een
variabele. auto laat de compiler uitzoeken wat het type van de
variabele moet zijn – je hoeft dat dus niet meer expliciet op te
geven:

template <typename Container>
int f(Container c) {
  auto a=5;
  auto b=*(c.begin());
}

De variabele a hierboven krijgt als type int. Dat is nog niet
echt interessant. Maar variabele b krijgt als type: datgene wat het
dereferencen van de returnwaarde van de memberfunctie begin() van het
type Container teruggeeft. Als je de functie f aanroept met als
parameter een list<double>, dan krijgt b het type double. Maar de
functie een map<string, int> als parameter meekrijgt, is b automatisch
een pair<string, int>. En dat is niet zo makkelijk “zelf” uit te
zoeken in zo’n generieke functie: In C++98 zouden we moeten
schrijven: typename c::valuetype b=*(c.begin())

Je ziet: je kunt met auto op een hoger abstractieniveau tegen dingen
aankijken. Iets soortgelijks zie je ook in de nieuwe mogelijkheid van
de for lus. Toevallig speelt auto daar ook een rol.

Vroeger zou je geschreven hebben:

for (vector<int>::iterator p=v.begin(); p!=v.end; ++p) {
    cout << *p << endl;
}

We hebben al gezien dat je dat in C++0X ook mag schrijven als:

for (auto p=v.begin(); p!=v.end; ++p) {
    cout << *p << endl;
}

Maar nu mag het zelfs op een hoger abstratie-niveau:

for (auto x: v) {
    cout << x << endl;
}

En dat nu is zelfs echt nu: gcc 4.6 ondersteunt deze features nu ook
al, zoals te zien is op http://gcc.gnu.org/gcc-4.6/cxx0x_status.html
Je vertelt in deze for-lus niet meer hoe je over de container wilt
itereren, maar alleen maar dat je dat wilt.

Behalve faciliteiten die denken op een hoger abstractieniveau mogelijk
maken, zijn er ook faciliteiten toegevoegd die programma’s in C++
sneller maken. Een veel gehoorde klacht is dat als je een stukje code
hebt als volgt (waarbij Matrix een klasse is die je zelf geschreven
hebt):

Matrix f() {
    Matrix m;
    ....
    return m;
}

int main() {
    Matrix mat;

    mat=f();
}

er erg veel kopieeracties van de Matrix m naar mat plaatsvindt. In
C++0X zijn zogenaamde move constructors mogelijk, waarbij je aangeeft
dat de oude eigenaar van de inhoud van de Matrix (zoals m in de
functie f) geen behoefte meer aan de data heeft, en dat de nieuwe
eigenaar deze data over mag nemen.

Ook is de taal orthogonaler geworden. Dat wil zeggen dat als een
bepaalde constructie in situatie A mag, en situatie B lijkt erg op A,
dan mag B die constructie ook. Een voorbeeld: We definieren een struct
met twee members, en een class met twee (private) members die middels
een constructor worden geinitialiseerd:

int main() {

    struct A {
        int a;
        int b;
    };

    class B {
    public:
        B(int x, int y) : a(x), b(y) {}
    private:
        int a;
        int b;
    }
}

Nu mogen we A en B objecten aanmaken. Maar in C++0X mogen we de oude
C syntaxt ook gebruiken: dat leidt automatisch tot het aanroepen van
de constructor.

A mijna = { 1, 2 };    // C, C++98 en C++0X okee

B mijnb(1,2);          // C++98 en C++0X okee
B nogeenb = { 1, 2 };  // C++0X okee

Maar dat mag zelfs bij het aanroepen van een functie:

extern void f(A);
extern void g(B);

f( { 1, 2 })           // C++0X okee, niet in C++98
g( { 1, 2 })           // C++0X okee, niet in C++98

Via zogenaamde initializer lists mag je zelfs schrijven:

vector<int> vec = { 1, 2, 3, 4 };

Naast deze vrij grote toevoegingen zijn er nog tal van wijzigingen die
klein lijken, maar wel een groot programmeergemak opleveren.

Zo hoef je als je een template variabele definieert, niet meer uit te
kijken dat een dubbele > leidt tot het interpreteren als een >>:

vector<list<int> >  v   // C++98: > > is nodig
vector<list<int>>   v2  // C++0X: spatie niet verplicht, >> mag ook

Een ergernis van velen is het ontbreken van een echte null pointer in
C++. Daardoor weet de compiler bij een overload als:
void f(int) { }
void f(char *) {}
niet wat te doen met een anroep als f(0).

In C++0X is er een constante: nullptr die als null pointer gebruik
wordt. Deze is niet zomaar te converteren van of naar een int.

Behalve wijzigingen en extra’s in de taal, zijn er ook flink wat
toevoegingen in de standaardbibliotheek. Zo zijn er onder andere
faciliteiten voor reguliere expressies, threading (ook ondersteund in
de taal), hash tables (zoasl map, maar dan ongesorteerd), en smart
pointers ter vervanging van auto_pointer.

Al met al is de standaard flink gegroeid.
Er zijn nog veel meer aanpassingen.
Een aardige lijst staat op wikipedia:
http://en.wikipedia.org/wiki/C%2B%2B0x maar ook Bjarne Stroustrup
heeft een goed document over de nieuwe standaard:

http://www2.research.att.com/~bs/C++0xFAQ.html

Van 2 tot en met 7 augustus werd in Rapperswil, Zwitserland
vergaderd door de ISO C++ standaardisatiecommissie. Ik was daar
voor Nederland als Head of Delegation aanwezig namens het NeN voor AT
Computing en de NLUUG.

Je kunt je afvragen waar in zo’n vergadering over gesproken wordt.
Waarom moet er zo lang gepraat worden?

In de vergadering in Rapperswil waren 8 landen vertegenwoordigd door
zo’n 60 mensen. Het grootste blok komt traditiegetrouw uit de
verenigde staten. Ieder land heeft tijdens de stemmingen één stem.
Daarom wordt tijdens de officiele zittingen altijd eerst over de
Amerikaanse mening gestemd, waarna ieder “head of delegation” van de
landen hun nationale stem mag uitbrengen. De leden van de
standaardisatiecommissie werken bij vendors (compilerleveranciers
zoals Microsoft, HP, Sun, RedHat (g++) en EDG (Edison Design Group een
OEM compilerbouwer), C++ grootgebruikers zoals Bloomberg en Fermilabs,
onderwijsinstellingen zoals universiteiten (en AT Computing!) en vele
andere bedrijven en instellingen. Al deze mensen hebben belang bij een
standaard die implementeerbaar is, bruikbaar is en onderwijsbaar is.
Er zijn dus verschillende belangen, waardoor soms ook spannende
discussies kunnen ontstaan.

De eerste C++ standaard (C++98) kwam uit in 1998. Daar is toen lang
aan gewerkt. In 2003 kwam er een “tussenversie” waarin kleine
onvolkomenheden werden gerepareerd, maar geen grote features
werden toegevoegd. Er zit nu een echt nieuwe standaard aan te komen. De
werktitel is C++0X hoewel de standaard niet in het eerste decennium
van deze eeuw uit is gekomen. Er is vertraging opgelopen omdat op een
vrij laat moment een groot feature uit de taal is verwijderd dat maar
niet goed gespecifieerd leek te kunnen worden (“concepts”). Een reële
datum lijkt nu medio 2011 te zijn.

Geen enkel commissielid kent de hele standaard, of begrijpt van alle
ontwerp-beslissingen waarom die genomen zijn. Daarom wordt de
vergadering opgesplitst in werkgroepen: Eén of twee werkgroepen over
de bibliotheek, Eén of twee over de kern van de taal (“core”) en een
over concurrency (een van de nieuwe features in de taal is
multi-threading). De werkgroepen lopen de voor hun relevante
problemen door en doen dan een voorstel voor de gehele vergadering.

Hoewel de atmosfeer ontspannen en vriendschappelijk is, zijn met name
de ISO zittingen erg officieel. Er mag absoluut niet de
indruk ontstaan dat bedrijven hun mening proberen door te drukken of
dat er gefraudeerd wordt. Tijdens de werkgroepvergaderingen wordt er
ook regelmatig gestemd, maar dan veel informeler. Vaak worden er
“straw polls” gehouden waar alle deelnemers aan de commissie mogen
stemmen: “Stel dat we dit probleem oplossen op de
besproken manier, zou je daar dan voor of tegen zijn”. Meestal kun je
kiezen uit vier standpunten: Strongly in Favor, Weakly in Favor,
Weakly Against, Strongly Against. Afgekort tot SF, WF, WA en SA.
Heel soms kun je ook stemmen voor OMDB (“over my dead body”), maar dat
kwam tijdens deze vergadering niet voor. Vaak gaat het dan over
nieuwe features, maar omdat in het stadium waarin de commissie nu zit
geen nieuwe features worden toegevoegd, speelt dat nu niet.

De commissie heeft een werkdocument dat in feite de standaard in
aanbouw is. In juni 2010 hebben de leden van de ISO (de nationale
standaardisatiecommissies) mogen stemmen over de toenmalige versie
van dat document. Dat document had de status FCD – Final Committee
Draft. De landen hadden de gelegenheid de FCD goed of af te keuren,
en ze konden daarbij commentaar op de tekst zelf leveren. Dat
commentaar kan groot zijn (wij vinden dat feature XYZ verwijderd moet
worden: veel consequenties) maar ook erg klein: “op pagina 123 staat
dat de libraryfunctie zusenmezo een int teruggeeft, terwijl op pagina
456 een voorbeeld staat waarin de functie een long teruggeeft”. Deze
commentaren heten “National Body Comments”. Tijdens de vergadering in
Rapperswil zijn alle national body comments langsgelopen. Dat waren
er honderden.

De verwachting is dat over twee vergaderingen (in maart 2011) alle
commentaren adequaat kunnen zijn afgehandeld en dat het werkdocument
met de status FDIS (Final Draft International Standard) naar het ISO
gestuurd zal worden. De landen kunnen er dan nog een laatste Ja of
Nee tegen zeggen en hopelijk hebben we dan medio 2011 een C++11
standaard. Deze standaard maakt C++ makkelijker te gebruiken en
makkelijker te leren.

Daarna blijft de commissie tweemaal per jaar bijeenkomen. Ten eerste
zullen er toch weer problemen opduiken in het 1200 pagina’s tellende
document. Maar ook zal een werkgroep weer nieuw leven ingeblazen
worden: evolution. In deze werkgroep worden nieuwe features
voorbereid voor de standaard na 2011. Hopelijk zal het mogelijk
blijken om het belangrijke onderwerp “concepts” dat helaas niet in de
huidige FCD meegenomen kon worden nu wél op een goede manier n de
standaard opgenomen kan worden. Het zal foutmeldingen van compilers
een stuk beter maken, en het programmeren in C++ nog verder
vergemakkelijken.

In een volgende blog gaan we kijken welke spannende features er in
C++0X zitten en in hoeverre deze nu al bruikbaar zijn.

Thuis gebruik ik al jaren met veel plezier mythtv
(http://www.mythtv.org) op een Linux systeem als videorecorder.
We kijken bijna nooit meer live TV, het meest recente journaal staat
altijd klaar, en reclames spoelen we zo door omdat mythtv die voor ons
markeert.

Op een zeker moment begonnen nieuwe opnamen her en der “blokjes” te
vertonen. Van die typische MPEG-artefacten die je ook wel eens bij
satelliet-TV ziet als het weer erg slecht is, of bij DVB-T
(Digitenne en dergelijke) als een slecht afgeschermde brommer voorbij
komt rijden.

Toen ik als test een aantal video-files naar een andere machine
kopieerde om dáár het bestand beter te bekijken, gaf rsync af en
toe foutmeldingen dat het kopieren niet goed gelukt was: de checksum
aan beide zijden was niet hetzelfde.

Pardon?

Er leek dus iets mis met de hardware. Het geheugen is het makkelijkst te
testen. Ik heb memtest86 (http://www.memtest86.com/) een dag laten draaien
om het geheugen te testen. Geen enkel probleem.

Dan de disk. In de logfiles was niets te zien. Het viel het me wel op
(bij de vele keren rebooten) dat er af en toe een filesystem op de
disk corrupt was. smartctl wist me te vertellen dat de disk zelf
niet het idee had dat hij “bijna defect” zou zijn. En bij het
controleren van de disk gekoppeld aan een ander systeem vond ook
badblocks dat er niets aan de hand was. Ook andere intensieve tests
op de disk aan een ander systeem lieten geen disk-problemen zien.

Vreemd.

De laatste test die ik deed gaf uitsluitsel. Ik schreef een klein
programmaatje dat willekeurige bytes in een file zet:

#include <stdlib.h>
#include <stdio.h>

int main() {

  srandom(0);

  const int n=1024;

  short ar[n];
  long long i;
  int idx;

  for (i=0, idx=0; i<2L*1024*1024*1024 / sizeof(ar[0]); ++i) {
    ar[idx++]=random();
    if (idx==n) {
      write(1, ar, sizeof(ar));
      idx=0;
    }

  }
}

Dit programma schrijft 2GiB aan pseudo-willekeurige bytes naar
standard output. Die gegenereerde random getallen zijn voorspelbaar
als je het begingetal kent. Ze zijn niet goed genoeg voor
cryptografische doeleinden, maar wel goed genoeg om reproduceerbaar,
min of meer willekeurige bytes te maken. Iedere keer dat het
programma start, krijg je bij hetzelfde begingetal dezelfde reeks.
Dat begingetal wordt gezet met de functie srandom. Hier gebruiken
we het begingetal 0. De 2GiB aan gegenereerde data kun je vervolgens
in een file zetten:

    ./randfile > OUT

Door het programma nogmaals te draaien (met hetzelfde begingetal 0),
kun je vergelijken of wat er in de file staat, overeenkomt met wat er
door het programma wordt geschreven:

    ./randfile | cmp OUT -

En wat bleek? In ongeveer één op de miljoen bytes, was het meest
significante bit (met de waarde 128) van 1 op 0 gevallen (zo werd een
byte met de hexadecimale waarde C3 nu 43, en een byte met de waarde F9
werd 79). Het leek dat bij het schrijven naar de disk, soms de data
niet goed bij de disk aankwam. Het probleem zat niet in het lezen:
nadat ik de file gemaakt had, en het programma op een andere machine
startte, bleken de bytes ook echt fout op de disk te staan. Ook met
andere disks trad dit probleem op. En op een andere machine met
dezelfde disk, trad het verschijnsel niet op. Het probleem leek dus
niet aan de disk zelf te liggen.

Het probleem werd opgelost door een ander moederbord te nemen, en daar
de videorecorder weer mee op te bouwen. Toen dat gebeurd was, waren
nieuwe opnamen weer vrij van blokjes, en traden filesystem problemen
niet meer op.

Laatst was een van onze consultants bij een klant die last had van
ernstige performance-problemen. Na uitbreiding van het aantal
clientprocessen was het systeem bij tijd en wijle onbruikbaar traag.

In dergelijke gevallen komt dan al snel het aloude programma top om de
hoek zetten om te kijken waar het probleem nu werkelijk in zit.

Helaas laat top op systeemniveau niet zien hoe het resourcegebruik is
van disk en netwerk; dus wachtsituaties die bij die resources ontstaan
zijn niet te zien. Gelukkig laat atop deze wel zien.

Na installatie van atop bleek dat van de 24 CPUs er hooguit 6 werk
hadden, en er 18 idle waren. De CPU-belasting kon dus niet het
probleem zijn. Het beschikbare geheugen (48GiB) werd voor 70% benut
door de cache en er was geen swapping actief. Geheugengebrek was dus
ook niet de oorzaak van het performance-probleem. Ook de disks konden
de vraag nog aan: ze waren gemiddeld 30% busy. En het netwerk
(gigabit) kon de stroom data van circa 10 megabit/s ruimschoots aan.

Je kunt je natuurlijk afvragen: hoe kan een systeem waarvan deze vier
hardware resources niet overbelast zijn, toch zo onwerkbaar traag
zijn. Vaak denken mensen dat als een systeem te traag is, er door
extra of snellere hardware verlichting verkregen kan worden. Helaas
is dat niet altijd (of eigenlijk: meestal niet) het geval.

Laten we een voorbeeld nemen. Stel dat er tegelijkertijd 100
applicaties draaien op het systeem die allemaal een record in een
bestand willen aanpassen. Ze zullen daarvoor een record lock
aanvragen bij het systeem. Als ze allemaal een ander record willen
aanpassen, kunnen ze tegelijkertijd op het bestand werken. Maar wat
nu als de applicatie zo geschreven is dat (om welke reden dan ook) er
geen lock wordt aangevraagd voor een enkel record, maar voor de gehele
file? Dan kunnen de 100 applicaties niet meer tegelijkertijd de file
aanpassen, en zullen ze een voor een aan het werk moeten gaan. Zelfs
al heb je 24 CPUs en zou je dus 24 applicaties echt tegelijk kunnen
afhandelen. Als er nu per seconde meer nieuwe aanvragen binnenkomen
dan er een-voor-een per seconde kunnen worden afgehandeld, krijg je een
steeds groter wordende achterstand.

Je kunt dit vergelijken met een 24-baans snelweg waarvan
op een klein stukje van de weg maar één baan mag worden bereden.
Als je het brede deel van de snelweg verbreedt van 24 rijstroken naar
48, levert dat helemaal niets op. Het is de wegversmalling die het
probleem oplevert. Hier geldt: meer asfalt, niets wijzer. Als je de
wegversmalling zou verbreden (waarschijnlijk een veel goedkopere
oplossing dan de hele weg verbreden), heb je het probleem op een veel
effectievere manier opgelost.

In de praktijk blijkt dat software resources (zoals locks en
semaforen) erg vaak de reden zijn van performance-problemen.
Dergelijke wachtsituaties kun je zien door te kijken naar het
wait-channel in de uitvoer van ps:

$ ps -o pid,wchan:20,s,cmd
  PID WCHAN                S CMD
32275 wait                 S -bash
32277 pipe_wait            S awk {n+=$0} END {print n}
32278 fcntl_setlk          S tstlock
32279 -                    R tstlock
32280 fcntl_setlk          S tstlock
32281 fcntl_setlk          S tstlock
32282 fcntl_setlk          S tstlock
32283 fcntl_setlk          S tstlock
32284 fcntl_setlk          S tstlock
32285 fcntl_setlk          S tstlock
32299 -                    R ps -o pid,wchan:20,s,cmd

We kunnen hier duidelijk zien dat er maar een tstlock proces is dat
loopt (de status is R). De andere staan allemaal te wachten op het
verkrijgen van een file lock (ze staan in de kernel te wachten op
fcntl_setlk). Op een systeem met meerdere CPUs staan hier de andere
CPUs duimen te draaien…

Moraal van dit verhaal: Kijk bij performance-problemen naar alle
resources, en niet alleen naar de hardware resources. Voor je
het weet heb je veel geld uitgegeven aan nieuwe hardware die het
probleem niet oplost omdat de problemen in de applicatiesoftware
zitten. Motto: extra ijzer, niets wijzer. En oh ja, bij die klant
kwam het ook goed zonder andere hardware te hoeven kopen.

Het Probleem

Ik was laatst een nieuwe disk aan het in-gebruik-nemen, waarbij ik
veel grote files moest kopieren van de oude (kleinere) disk. Dat
soort dingen doe ik normaliter met rsync (daarvan zitten de opties in
mijn vingers). Maar nu zag ik dat de performance bedroevend was. Ik
moest zo’n 700GiB aan data overpompen, en dat ging met een tempo van
zo’n 30MiB/s. Beide disks kunnen ieder minstens 100MiB/sec lezen
en/of schrijven. En ik haalde dus nog geen derde daarvan. (We hebben
het over een totale doorlooptijd van ruim 2 uur versus 6 uur!)

Meten…

Ik ben toen eens wat gaan meten en gaan spelen. Hiervoor bedacht ik
een simpele benchmark: het kopieren van een file van 10GiB. Zowel de
bronfile als de bestemming stonden op een ext4 filesysteem dat ik op
de buitenste (snelste) tracks van de twee fysieke disk formatteerde.

Als kopieerprogramma’s gebruikte ik:

• rsync
• cpio
• cp
• cat

uiteraard voorafgegaan door commando’s om de cache te legen en
afgesloten door een sync om de cache te flushen. Dus bijvoorbeeld:

sync                               # forceer dirty buffers naar disk
echo 3 > /proc/sys/vm/drop_caches  # gooi caches weg
time sh -c "cp $SRC $DEST; sync"   # meet cp én sync tijd

De echo naar /proc/sys/vm/drop_caches forceert het volledig
invalideren van de cache. Dat werkt alleen voor de niet-dirty
pagina’s, daarom dat we eerst een sync commando gebruiken om alle
dirty pagina’s naar disk te forceren. Het betreffende kopieer programma zal
de 10GiB file kopieren, maar ook eindigen vóórdat de laatste blokken naar
disk worden geschreven (die blijven nog 30 seconden in de cache plakken).
Daarom meet het time commando de tijd die nodig is voor het kopieer programma,
en de sync om de laatste restjes te flushen.

De metingen voor rsync, cpio, cp en cat wezen het volgende uit:

user      sys     elaps  hog  MiB/s  test
158.75   108.71  320.08  83%   31   rsync
  5.24    80.60  116.81  73%   87   cpio
  0.73    53.41  109.36  49%   93   cp
  1.42    62.03  108.80  58%   94   cat

Ik ben daarop wat nader gaan kijken. Wat blijkt:
rsync heeft 3 processen nodig: een lezend, een schrijvend en een
niets-doend (control?) proces. Op mijn 4-core systeem draaien ze
bijna de hele tijd alledrie op één enkele CPU. Met het commando
taskset kun je afdwingen op welke CPUs een proces mag draaien. Stel
dat de drie rsync processen de PID’s 1111, 1112, 1113 hebben, dan kun
je afdwingen dat ze ieder op hun eigen CPU draaien met:

taskset -pc 0 1111   # forceer op CPU0
taskset -pc 1 1112   # forceer op CPU1
taskset -pc 2 1113   # forceer op CPU2

Door met het taskset commando meteen na het starten ieder rsync
proces zijn eigen CPU te geven, gaat de throughput omhoog van
31MiB/s naar 39MiB/s. Als de drie rsync processen met taskset
geforceerd worden op één CPU, loopt de performance terug naar
27MiB/s.

rsync heeft daarnaast erg veel user+sys CPU-tijd nodig. Ondanks dat, schaalt
de on-demand cpufreq niet de frequentie omhoog. Als ik de frequentie forceer
op de hoogst mogelijke met:

for i in 0 1 2 3 ; do
  echo performance > /sys/devices/system/cpu/cpu$i/cpufreq/scaling_governor
done

dan gaat de throughput van rsync fors omhoog: 58MiB/sec. De CPU’s draaien dan
op de hoogst mogelijke frequentie (op dit systeem 2.6GHz). Als we dat
combineren met de taskset truuk om de drie rsync processen ieder hun eigen CPU
te geven, weten we er zelfs 79MiB/s uit te persen. Nog altijd zo’n 20% lager
dan de andere, en tegen flink CPU-verbruik, maar toch.

De conclusie is dat je door in plaats van rsync, cp te gebruiken in de default
instellingen, je van 30MiB/s naar 93MiB/s kan gaan. Maar ook door een
beetje te spelen met de instellingen van het systeem, kun je zelfs met
rsync flinke verbeteringen bereiken!

throughput #CPUs    frequentie
22MiB/s    1 CPU,    0.8GHz
23MiB/s    1-3 CPUs, 0.8GHz
27MiB/s    1 CPU,    ondemand
31MiB/s    1-3 CPUs, ondemand     << default
38MiB/s    3 CPUs,   0.8GHz
39MiB/s    3 CPUs,   ondemand
58MiB/s    1-3 CPUs, 2.6GHz
58MiB/s    1 CPU,    2.6GHz
79MiB/s    3 CPUs,   2.6GHz

In de tabel geeft de tweede kolom aan hoe de rsync processen over de
CPU’s verdeeld werden: 1 CPU wil zeggen dat met taskset de drie rsyncs
alledrie op één en dezelfde CPU gedwongen werden. 1-3 CPus wil zeggen
dat de scheduler zelf de vrije hand had, en 3 CPU’s wil zeggen dat
ieder rscyn proces met taskset zijn eigen CPU kreeg.

Je kunt duidelijk zien dat het slechter kan dan de default
instellingen, maar ook heel veel beter!

De toekomst…

Op Linux Weekly News
http://lwn.net/Articles/384132/
stond recentelijk een bericht dat de ondemand scheduler moeite heeft
met processen die veel I/O doen en ook vrij veel CPU tijd nodig
hebben: In de tijd dat de CPU op disk I/O staat te wachten, wordt de
CPU weer naar een lage frequentie teruggeschaald. Als het proces dan
weer wil rekenen duurt het enige tijd voordat er weer omhoog wordt
geschaald. Arjan van de Ven van het Intel Open Source Technology
Centre heeft een aanpassing op de ondemand scheduler aangebracht die
de CPU pas omlaag schaalt als deze echt idle is (en niet op disk I/O
staat te wachten).

Je kunt dit verschijnsel ook mooi zien:

Als je

modprobe cpufreq_stats

doet, krijg je precies (in jiffies gemeten) het aantal hits te zien
voor de verschillende te gebruiken clock frequenties.

Bekijken we dit voor een rsync commando, dan zien we
bijvoorbeeld voor cpu nummer 2:

cat /sys/devices/system/cpu/cpu2/cpufreq/stats/time_in_state
2600000 423293
1900000 363
1400000 534
800000 6645805

Je kunt hier dus zien dat cpu2 (sinds het laden van de module) het
grootste deel van de tijd in de lage frequentie (0.8GHz) heeft gelopen.

De aanpassing van Arjan van de Ven is nog een lapje voor het bloeden,
want hij heeft een hele nieuwe governor in voorbereiding.

Er was eens….

een bank met vele kantoren door het land. De medewerkers in de
kantoren klaagden dat de nieuwe computers te traag waren. Dit speelde
in de tijd dat electronisch bankieren, pinnen en geldautomaten nog een
onbeduidende rol speelden. Klanten gingen naar de bank om geld op te
nemen, en door de trage computers ontstonden er lange rijen. Daarom
wilde de bank af van het contract met de leverancier.

Maar de leverancier stuurde een performance analyse en tuning expert
om de oorzaak van de problemen te onderzoeken. Hij zag al snel dat
één specifiek programma vrijwel alle CPU capaciteit opsoupeerde. Met
een profiling tool kon hij inzoomen op het programma, en vond hij de
uiteindelijke oorzaak. In de source code van het programma stond:

for (i=0; i<strlen(s); ++i) {
    if (... s[i] ...) ...
}

Die string s was gemiddeld vele duizenden karakters lang en iedere
aanroep van strlen loopt langs alle karakters van de string op zoek
naar de afsluitende null-byte. De string veranderde echter nooit in
het lusje, dus hoefde de programmeur ook maar één keer de lengte vast
te stellen. Daarmee zouden duizenden aanroepen van strlen bespaard
kunnen worden, en dus miljoenen karaktervergelijkingen.

De code (door de bank zelf geschreven) werd snel aangepast, en de
bankbedienden leefden nog lang en gelukkig:

n=strlen(s);
for (i=0; i<n; ++i) {
    if (... s[i] ...) ...
}

Had de programmeur niet beter zijn best moeten doen? Hij had toch
moeten weten dat door de code zo op te schrijven als hij gedaan had,
de code CPU-tijd nodig heeft die kwadratisch schaalt met de lengte van
de string?

Iedere programmeur kent het motto:
“first make it work, then make it work fast”. Hiermee worden de
valkuilen van micro-optimalisatie voorkomen. Maar het bovenstaande
voorbeeld zou je bijna doen geloven dat de programmeur een
Machiavelliaans motto aanhing “first make it work slowly.”

Deze onnadenkendheid komt regelmatig voor. En het is niet alleen maar
een kwestie van “je moet niet proberen het wiel opnieuw uit te
vinden”. Soms tikken onwetende programmeurs zonder na te denken “in
het wilde weg” en hebben ze op die manier zomaar bubble sort
“uitgevonden”. En dan zijn ze er misschien nog trots op ook!

Naast het kiezen van het goede algoritme, moet je ook de goede
datastructuur kiezen voor het soort probleem dat je aan het oplossen
bent. De keuze voor een datastructuur kan erg veel invloed hebben.
Als je bijvoorbeeld een gelinkte lijst gebruikt voor de opslag van
miljoenen items waar je ook nog in wilt kunnen zoeken, heb je weer een
suboptimale oplossing gevonden. Een gehashte datastructuur of een
binaire boom laat je in dit geval de te zoeken data veel sneller
vinden.

Programmeurs moeten dus het wiel niet proberen uit te vinden, en
zoveel mogelijk gebruik maken van bestaande bibliotheken. Maar om
problemen zoals die van de bank hierboven te vermijden, moeten de
programmeurs wel wéten wat de eigenschappen van algoritmes en
datastructuren zijn. Goed programmeerwerk begint dus bij een goede
opleiding. Is het alleen maar de mooie opschmück in moderne
tekstverwerkers die er voor zorgt dat ze net zo traag aanvoelen als
old-school programma’s zoals WordStar die in de jaren 80 van de vorige
eeuw op 8-bits processor’s draaiden in computers met 64KB geheugen?

Velen zeggen dat hergebruik is waar het om draait. Maar bovenal
moeten programmeurs weten wanneer je wat op welke manier moet
hergebruiken. Ze moeten dus kennis hebben van het probleemdomein, en
van algoritmes en datastructuren.

Een goede programmeur weet ook wanneer een inferieur algoritme toch
betere resultaten op zal leveren. Als je bijvoorbeeld zeker weet dat
je nooit meer dan vijf items wilt sorteren (denk aan de vijf
dobbelstenen in een Yahtzee spel), kun je misschien wel het beste
kiezen voor bubble sort, omdat dat bubble sort gegeven de beperkte
probleemgrootte het snelst en simpelst is.

Dus: leer van anderen (open source helpt!) en lees goede boeken
(die je dan wel ook moet snappen). En mocht je de boekenserie bij
uitstek goed lezen (Donald Knuths “The art of computer programming”)
zou je nog mazzel kunnen hebben en je onsterfelijk kunnen maken ook:
Don Knuth betaalt een hexadecimale dollar ($2,56) voor iedere fout die
je in het boek ontdekt.

UNIX – a giant leap for mankind…

Zomer 1969: Op 20 juli zit de hele wereld aan de TV gekluisterd om de eerste
voetstappen van een mens op de maan te zien.

Terwijl Neil Armstrong zijn woorden “A small step for a man, a giant leap for
mankind” uitspreekt, vindt in AT&T Bell laboratories in Murray Hill, New
Jersey een technische revolutie plaats die zo mogelijk nog meer directe
invloed op ons leven nu heeft: Ken Thompson en Dennis Ritchie bedenken UNIX.

De basis-ideeen in UNIX uit die zomer van 1969 waren baanbrekend. Daarom
worden de concepten nog steeds gebruikt, niet alleen in UNIX varianten
(waaronder Linux en MacOS X) maar ook in andere moderne besturingssystemen
zoals Windows XP en zijn opvolgers. Niet voor niets mochten Thompson en
Ritchie in 1983 de Turing award ontvangen voor hun werk. De Turing award
wordt wel gezien als de Nobelprijs van de informatica.

Na 10 jaar UNIX systemen beheerd te hebben beginnen Ger Austen en Hendrik-Jan
Thomassen (A en T) in 1985 het bedrijf
AT Computing; het eerste cursus- en
consultancybedrijf op het gebied van UNIX in Nederland.

Ruim 20 jaar na het ontstaan van UNIX bouwt in 1991 de Finse student Linus
Torvalds het UNIX compatible systeem Linux.

Inmiddels zijn we veertig jaar na de eerste schreden van Neil Armstrong, en
heeft Linux met zijn 18 jaren een volwassen leeftijd! En wat zien we: Het
aantal UNIX-achtige systemen en dan met name Linux groeit en groeit.

UNIX en Linux worden gebruikt op zeer kleine en zeer grote installaties. Zo is
kans groot dat als u een ADSL router heeft, u daar Linux in heeft draaien.
Dat geldt ook voor navigatie apparaten, televisies, digitale videorecorders,
kassa’s bij supermarkten en warenhuizen, reclamezuilen etc etc. En wie een
hippe iPhone van Apple gebruikt, beleeft ook dagelijks plezier van het UNIX
dat binnenin het kleinood zijn werk doet…

Ook grote UNIX en Linux installaties worden door iedereen dagelijks gebruikt:
Het is algemeen bekend dat zoekdienst Google vele honderduizenden Linux
systemen laat samenwerken tot de website die iedereen kent. En bekende sites
als Ebay, Amazon,
bol.com en de Nederlandse Spoorwegen
zijn UNIX en Linux
grootgebruikers. Van de 500 grootste en snelste
computers in de wereld werkt ruim 95% met UNIX of Linux.

Kortom: Is UNIX na 40 dienstjaren pensioengerechtigd en afgeschreven? Nee,
integendeel! UNIX is springlevend! U zult nog veel van UNIX en Linux
gebruik maken.

AT Computing – Verstand van UNIX, gevoel voor UNIX – al 25 jaar.

UNIX – a giant leap for mankind…

Zomer 1969: Op 20 juli zit de hele wereld aan de TV gekluisterd om de eerste
voetstappen van een mens op de maan te zien.

Terwijl Neil Armstrong zijn woorden “A small step for a man, a giant leap for
mankind” uitspreekt, vindt in AT&T Bell laboratories in Murray Hill, New
Jersey een technische revolutie plaats die zo mogelijk nog meer directe
invloed op ons leven nu heeft: Ken Thompson en Dennis Ritchie bedenken UNIX.

De basis-ideeen in UNIX uit die zomer van 1969 waren baanbrekend. Daarom
worden de concepten nog steeds gebruikt, niet alleen in UNIX varianten
(waaronder Linux en MacOS X) maar ook in andere moderne besturingssystemen
zoals Windows XP en zijn opvolgers. Niet voor niets mochten Thompson en
Ritchie in 1983 de Turing award ontvangen voor hun werk. De Turing award
wordt wel gezien als de Nobelprijs van de informatica.

Na 10 jaar UNIX systemen beheerd te hebben beginnen Ger Austen en Hendrik-Jan
Thomassen (A en T) in 1985 het bedrijf
AT Computing; het eerste cursus- en
consultancybedrijf op het gebied van UNIX in Nederland.

Ruim 20 jaar na het ontstaan van UNIX bouwt in 1991 de Finse student Linus
Torvalds het UNIX compatible systeem Linux.

Inmiddels zijn we veertig jaar na de eerste schreden van Neil Armstrong, en
heeft Linux met zijn 18 jaren een volwassen leeftijd! En wat zien we: Het
aantal UNIX-achtige systemen en dan met name Linux groeit en groeit.

UNIX en Linux worden gebruikt op zeer kleine en zeer grote installaties. Zo is
kans groot dat als u een ADSL router heeft, u daar Linux in heeft draaien.
Dat geldt ook voor navigatie apparaten, televisies, digitale videorecorders,
kassa’s bij supermarkten en warenhuizen, reclamezuilen etc etc. En wie een
hippe iPhone van Apple gebruikt, beleeft ook dagelijks plezier van het UNIX
dat binnenin het kleinood zijn werk doet…

Ook grote UNIX en Linux installaties worden door iedereen dagelijks gebruikt:
Het is algemeen bekend dat zoekdienst Google vele honderduizenden Linux
systemen laat samenwerken tot de website die iedereen kent. En bekende sites
als Ebay, Amazon,
bol.com en de Nederlandse Spoorwegen
zijn UNIX en Linux
grootgebruikers. Van de 500 grootste en snelste
computers in de wereld werkt ruim 95% met UNIX of Linux.

Kortom: Is UNIX na 40 dienstjaren pensioengerechtigd en afgeschreven? Nee,
integendeel! UNIX is springlevend! U zult nog veel van UNIX en Linux
gebruik maken.

AT Computing – Verstand van UNIX, gevoel voor UNIX – al 25 jaar.