GENETX' tweakblog

Zo, hoog nodig tijd voor het volgende stukje blog! Vorige keer hebben we het gehad over de herkomst van de MHz myth. Zoals aangegeven zijn er echter ook oplossingen om de problemen van een lange pipeline deels te verhelpen. Een langere pipeline hoeft namelijk niet altijd slechter te zijn. In deze blog 3 oplossingen, 1 softwarematige en 2 hardwarematige.

Software: loop unrolling

Vorige keer hebben we met behulp van een stukje C code en de pseudo assembly gezien wat jumps zijn en welk negatief effect ze hebben in de pipeline. Het klinkt misschien stom, maar het antwoord is heel simpel: Zorg voor minder jumps!

En dat is exact wat je kan doen met loop unrolling, zorgen dat je minder jumps uitvoert. Jumps komen constant voor door aan het eind van de loop te kijken of we hetzelfde stukje code nog eens moeten uitvoeren en we springen vervolgens weer terug zoals in het volgende stukje code:

C:

1 2 3

for(int x=0; x<4; x++){    doe_iets(x); //doe 4 maal de functie doe_iets(int waarde); }

We zien dat in ieder geval 3 keer terug moeten springen in dit geval. En voor de mierenneukers is de doe_iets functie hier gewoon wat inline code zonder function calls etc . We houden het even simpel. Ontopic, dat kan beter

C:

1 2 3 4

for(int x=0; x<2; x++){   doe_iets(x*2);   doe_iets((x*2)+1); }

Deze code doet natuurlijk exact hetzelfde, maar nu met slechts 1 jump terug. En wat doet de code, nou het volgende zonder jumps

C:

1 2 3 4

doe_iets(0); doe_iets(1); doe_iets(2); doe_iets(3);

Et voila, helemaal geen jumps meer. Met zo'n kleine loop gaat dat nog wel, maar met een loopje dat je heel vaak of dynamisch moet uitvoeren wordt het lastig. Je kan je ook inbeelden dat je veel meer regels code nodig hebt. En dat klopt ook, je programmagrootte kan er door exploderen... Dit trucje hoef je niet enkel in je code toe te passen, een compiler kan het ook voor je oplossen. Er is echter nog een nadeel aan softwarematige oplossingen zoals deze dat een beetje verklaring vereist.

Instruction Set Architecture (ISA)

Iedereen kent het wel. Intel en AMD zijn x86 processors, maar wat houdt dat nu eigenlijk in? x86 staat hier voor de instructieset van de processor. Dit valt het beste te vergelijken met de taal. Deze blog is in het Nederlands en dat is ook de reden waarom je de blog kan lezen. Voor de meesten zou het knap lastig worden als ik het in het Fries zou doen.

De instructieset is dan ook niets meer dan een specificatie waarin vaststaat wat voor "woorden" (oftewel de instructies) de processor herkent en wat het antwoord er op zal zijn. AMD en Intel kunnen intern compleet verschillende oplossingen hebben, zolang ze zich maar houden aan de specificatie. Naast x86 heb je nog veel meer instructiesets zoals ARM, IA64 en PowerPC.

De kracht van zo'n instructieset is dat deze niet snel veranderd. Zo kan je x86 processor nog altijd de meest oude code draaien. Wel hebben nieuwere processoren subsets zoals MMX en SSE aan boord om de functionaliteit uit te breiden, maar de x86 kern blijft om backward compatible te zijn.

En daar zit ook de grootste reden om oplossingen te zoeken in hardware in plaats van in software zoals hierboven. Men wil voorkomen dat programma's opnieuw gecompileerd moeten worden of zelfs deels herschreven. Daarom wordt gefocust op meer prestaties door verbeterde hardwareoplossingen.

Hardware: Branch Prediction

Jumps binnen de code blijven een vervelend fenomeen. Je neemt de vertakking (branch) wel of je neemt hem niet. Het zou mooi zijn als we een glazen bol zouden hebben om de toekomst te voorspellen. Het beste wat we tot die tijd kunnen doen is echter gokken.

In het eerste stukje code gaan we er vanuit dat we niet springen en laden de volgende regel code. Dat leverde veel jumps op. Wat als we nu gokken dat we wel gaan springen en die vanaf die regel instructies gaan toevoegen aan de pipeline? In dat geval zouden we pas na 3 correcte branches een keer fout gokken.

En bovenstaande is een simpel voorbeeld van branch prediction. Tegenwoordig wordt de geschiedenis van een aantal eerdere branch instructies onthouden en op basis van die geschiedenis een goede gok gedaan. Uiteraard zal je processor er nog steeds wel eens naast zitten, maar in ieder geval een stuk minder vaak dan zonder deze trucjes.

Hardware: Out-of-order execution

Deze term hebben de meesten wel vaak voorbij zien komen bij Intel's Atom processor, want deze ondersteund geen out-of-order execution. Wat houdt dat echter in

In de vorige blog hebben we gezien wat data dependencies zijn. Het zou mooi zijn als we dat zouden kunnen voorkomen door andere instructies voorrang te geven, maar alle instructies staan in hun volgorde en horen zo te blijven. Verder zitten we met het probleem dat de registers voor directe opslag van data vaak hergebruikt worden en voor zogenaamde data hazards zorgen. Namelijk een read-after-write, write-after-write en write-after-read.

Bij out-of-order execution is er wel zo'n soort trucje genaamd register renaming. In dat geval kan een ander register, soms niet eens beschikbaar via de instructieset zelf, worden gebruikt om instructies te verwerken. Daardoor worden de data hazards al voorkomen zodat instructies eerder zonder problemen kunnen worden verwerkt. Ze hebben daarnaast als grote voordeel dat er meer registers beschikbaar zijn voor de code.

Wikipedia bevat een goed voorbeeldje op dit gebied, zie hier: http://en.wikipedia.org/w...naming#Problem_definition

Consider this piece of code running on an out-of-order CPU:
1. R1=M[1024]
2. R1=R1+2
3. M[1032]=R1
4. R1=M[2048]
5. R1=R1+4
6. M[2056]=R1
Instructions 4, 5, and 6 are independent of instructions 1, 2, and 3, but the processor cannot finish 4 until 3 is done, because 3 would then write the wrong value.
We can eliminate this restriction by changing the names of some of the registers:
1. R1=M[1024]
2. R1=R1+2
3. M[1032]=R1
4. R2=M[2048]
5. R2=R2+4
6. M[2056]=R2
Now instructions 4, 5, and 6 can be executed in parallel with instructions 1, 2, and 3, so that the program can be executed faster.

Let hierin goed op de R-waarden, dit zijn de registers. Je ziet dat de originele code dezelfde registers gebruikt, maar dat de stukken code verder onafhankelijk zijn. Door register renaming (R1 wordt R2 in 4, 5 en 6) worden ze helemaal onafhankelijk.

Je ziet nu 2 taken die parallel kunnen worden uitgevoerd, namelijk regels 1 t/m 3 en 4 t/m 6. Dit heet Instruction Level Parallelism (ILP). Bij out-of-order execution wordt gebruik gemaakt van dit fenomeen. Instructions worden netjes in volgorde gefetcht. Vervolgens komen ze in de "reservation station" waar ze wachten tot alle data beschikbaar is, waarna ze worden uitgevoerd. Door middel van ILP kan een andere instructie voorrang krijgen omdat de data voor deze instructie al beschikbaar is in tegenstelling tot de data voor de instructie die eigenlijk aan de beurt is.

Na afronding van deze instructie komt deze in een 2e verzamelplaats, de "instruction retire". Hier moet de uitkomst wachten tot de uitkomst van alle voorgaande instructies uit de code ook bekend is. Zo merk je als eindgebruiker helemaal niets van dit inhalen van instructies. Dat is echter niet helemaal waar, want op deze manier kan de pipeline beter gevuld blijven en dat zul je wel moeten merken.

Volgende blog

Ik heb nog geen flauw idee wat ik hierna zal behandelen. Als iemand graag iets zou zien uitgelicht hoor ik dat graag. De blog kan alle kanten op

In de vorige blog hebben we gezien wat een pipeline is. Velen van ons zullen terugdenken aan de MHz Myth-presentatie van Apple. En dat is inderdaad waar ik het deze blog over zal hebben. Het filmpje van Apple dat iedereen wel kent is deels waar.

Apple zou echter Apple niet zijn als ze het verhaaltje niet mooier zouden maken dan het is. Zo laten ze de Pentium 4 uiteindelijk niet op een hogere frequentie draaien. Daarvoor wordt het notabene nog gemeld. In het tweede stuk, beginnende bij 5:42 zou de P4 op een grofweg 2x zo hoge kloksnelheid moeten draaien en dus eerder eindigen. Dat zou na 35 seconden moeten zijn op 6:17. Leuk bedacht Apple, maar zo slecht is pipelining ook weer niet. Toch zijn er wel degelijk narigheden, maar ook oplossingen!

Pipelining problemen

Ze worden al wel gemeld in het filmpje. Ik zal twee voorbeelden behandelen. De eerste is data dependency, de tweede zijn jumps naar andere stukken code (branches). Voor de codekloppers is dit ook wel een leuk stukje, want ik zal laten zien wat de compiler met je code doet om de instructies vervolgens op de CPU uit te voeren.

1. Data dependencies

Het probleem hier is heel simpel. Stel dat je 2 sommen hebt, maar de tweede som de uitkomst van de eerste nodig heeft:
(1) A = 2 + 3
(2) B = A x 4
Het lijkt me logisch dat we eerst A moeten uitrekenen voor we B kunnen bepalen. Velen zien dit probleem al wel bij multithreaded applicaties. Het probleem speelt echter ook in het pipeline design. Laten we het plaatje van de MIPS uit de vorige blog er bij pakken, maar nu met wat kleurtjes :



We voeren de 2 "instructies" van hierboven in de processor. Na 3 kloktikken komt de eerste instructie aan bij de ALU en zal A bekend worden. Bij de 4e kloktik zal A in het geheugen komen. A is dan dus al bekend en is op dat moment bij de zwarte cirkel.

Op datzelfde moment is de 2e instructie ook al bij de ALU. We hebben echter een probleem: De waarde van A staat nog niet in het register opgeslagen. Dit register (geheugen) houdt uitkomsten vast om er weer bewerkingen mee te doen. We zullen dus moeten wachten tot de uitkomst van A weggeschreven is in het register om vervolgens pas B te kunnen bepalen. Dat is de rode lijn in het plaatje en we zijn op het punt waar ik een zwart cirkeltje omheen heb gezet.

Vanaf dat punt moeten we nog door 2 pipeline stages. Dat is over de groene balkjes. Dat betekend dus ook dat we 2 kloktikken moeten wachten tot de data bij de ALU is om alsnog B te kunnen bepalen. Dit heet een "stall". Op dat moment moeten de instructies wachten tot de data die nodig is beschikbaar is.

Echter hadden we al geconstateerd dat het antwoord van A al bekend was op phet punt waar de zwarte cirkel staat. Kunnen we die dan niet gelijk weer in de ALU proppen . Jazeker, dat kan en dat is ook wat men doet bij deze MIPS processor. Met behulp van een mux (een soort wissel ) kunnen we in plaats van het register de uitkomst van de ALU gelijk terugvoeren naar de input van de ALU. Dat is de blauwe lijn in het plaatje. Een mooie oplossing, want hiermee besparen we dus 2 kloktikken en kan B gelijk worden bepaald!

2. Branching

Branching is een ander fenomeen dat veel voorkomt. Alle instructies die de CPU moet verwerken staat op volgorde in het geheugen. We hebben al gezien dat de program counter weet op welke regel we zijn. Deze gaat normaliter steeds een instructie verder. Wat echter als we naar een ander stukje code willen? Dan moeten we dus een stukje verder (of terug) springen in de code. En dit komt vaak voor, heel vaak. Als je zo'n sprong maakt dan neem je de branch, oftewel de vertakking van de eigenlijke instructies.

Laten we naar de high-level code gaan zoals in C bijvoorbeeld. Iedereen die wel eens code heeft geklopt zal wel gebruik hebben gemaakt van loops en if-then-else constructies. Zeker in die laatste is het duidelijk dat je in de code springt op basis van een vergelijking. We gaan echter naar een simpele while-lus kijken. Neem de volgende code:


C:

1 2 3 4 5 6 7

i = 0; //eerst variabele i resetten while(i < 2){     //zolang i kleiner dan 2 is de volgende regel uitvoeren:     i = i + 1; //i ophogen met 1 } j = 100; //andere code //meer code

De code in de while loop zal nu 2 keer worden uitgevoerd. Daarna is i 2 maal met 1 opgehoogd en dus 2 zijn. Aangezien 2 gelijk is aan 2 voldoet deze niet meer aan de eis dat deze kleiner dan 2 moet zijn en zal de code binnen de while-lus niet nogmaals worden uitgevoerd. Deze code kunnen we eenvoudig omzetten naar assembly code. Deze code is direct te vertalen in de binaire instructies die we aan de CPU geven. Dat is dus ook de code die de compiler voor je maakt. Aangezien voor velen assembly een beetje onleesbaar is zal ik het vertalen in pseudo-code die op hetzelfde neerkomt:


code:

1 2 3 4 5 6

Laad 0 in register i Is waarde register i < 2? Zo niet ga naar 5 register i = register i + 1 Spring naar 2 Laad 100 in register j etc

Deze set aan instructies zal dus netjes 1 voor 1 op volgorde worden ingeladen, gedecodeerd en zo naar de ALU gaan in de pipeline. Dat is fijn, we kunnen weer lekker de pipeline vullen met de instructies

Dat gaat goed tot we in het begin bij instructie 4 zijn. Inmiddels zijn instructie 5 en 6 ook al in de pipeline te vinden. Instructie 4 zegt ons echter dat we naar 2 moeten springen. We hebben dus een probleempje. Instructie 5 en 6 mogen we niet uitvoeren. De pipeline moet dus geleegd worden en we moeten instructie 2 weer ophalen. Hetzelfde herhaalt zich nog eenmaal. Dan zijn we bij regel 2 en bevat register i de waarde 2. Dan moeten we alweer springen, deze keer naar 5.

Outro

Het lijkt me duidelijk: al die sprongen zorgen voor enorm veel vertraging. Iedere keer moeten we een aantal kloktikken wachten tot de we weer wat nuttigs gaan doen met de processor. Je kan je voorstellen dat langere pipelines die we in x86 processoren kennen nog meer vertraging in kloktikken kunnen opleveren. Ook hiervoor zijn oplossingen, namelijk branch prediction en out-of-order instructieverwerking. Ook kan de compiler optimaliseren wanneer bekend is hoe de processor zich gedraagt.

Dat is waar we het volgende keer over gaan hebben. Stel gerust weer vragen en mocht je een ander onderwerp zeer binnenkort aan orde zien komen, vraag dat dan gerust!

Aangezien er in het AMD topic nogal wat vraag is naar wat meer uitleg over processors en hoe ze werken, ben ik van plan een paar blogjes te schrijven. Het kan best zij dat ik er ook een paar keer naast zit, maar dat zien we dan wellicht weer in de reacties . Het doel is om in ieder geval iets van de complexiteit van een processor te verhelderen en op basis daarvan te kijken naar hoe AMD nuttig gebruik maakt van wat waarnemingen om de processor te optimaliseren. Want is een module nou de core, of bevat een module 2 cores

Logische poorten, da's logisch

Iedereen die de afgelopen jaren HAVO of VWO heeft gedaan zal wel in aanraking zijn gekomen met logische poorten. Dit is een niveau hoger dan de transistoren, waar we het in deze dummy course niet echt over hebben. Logische poorten zijn echter wel belangrijk. Ze vormen op dit niveau de bouwstenen om 1en en 0en te bewerken. Eigenlijk is het LEGO voor gevorderden, waarschijnlijk de belangrijkste reden waarom ik het leuk vind

Je hebt verschillende bouwstenen. EN-poorten, OF-poorten, Inverters. Een normale EN-poort heeft 2 ingangen en een uitgang. Enkel als beide ingangen hoog zijn is de uitgang ook hoog (of 1). De OF-poort verraadt zichzelf eigenlijk al. Ingang 0 (technici beginnen met tellen bij 0 ) of 1 moet hoog zijn en dan krijgt de uitgang ook een hoog signaal. Meer lees je op deze pagina: http://nl.wikipedia.org/wiki/Logische_poort

Op die manier kun je ook berekeningen doen met meerdere bitjes. Zo kun je een adder (engels voor opteller, niet zo'n slanggeval onder het gras) bouwen (wiki) of 2 waarden vergelijken. Met al deze poorten kun je dus van alles doen tot het bouwen van een processor. Er zijn wel zat tooltjes op het web mocht je er eens mee willen stoeien. Google kent er zat blijkbaar. Kijk zelf maar.

Een simpele processor

Zoals gezegd, met logische poorten kun je een processor bouwen. Je kan niet alleen optellingen en vergelijkingen doen, je kan ook met wat schakelingen data vasthouden. Voor we naar uitgebreide processors van vandaag de dag gaan beginnen we met een simpele processor, de MIPS. Hieronder een plaatje:


We zien hier 5 stappen in terug. Stappen die eigenlijk iedere processor voorkomen. Wat er globaal gebeurd is als volgt:
1. Instruction fetch
In de eerste fase wordt een instructie opgehaald. Deze instructie is bijvoorbeeld een optelling van 2 waarden, 2 waarden vergelijken of een zogenaamde jump maken in de code. Bij de MIPS zijn instructies 4 bytes groot.
2. Instruction decode
Het decoderen van een instructie. Aangezien het bitjes zijn, moet bekend zijn welk patroon welke handeling verricht. Daarvoor is de ISA. Zo spreken AMD en Intel de x86 "taal". Code voor AMD en Intel draait dan ook niet op de MIPS. Net zoals de meesten hier geen chinees zullen verstaan. Naast de instructie staat er ook data in zoals waarden of waar het resultaat naartoe moet.
3. ALU
Hier vinden de echte berekeningen plaats. In de Arithmetic Logic Unit zitten de schakelingen om op te tellen, te vermenigvuldigen of wat dan ook maar mogelijk is op de processor.
4. Memory access
Toegang tot het geheugen om de resultaten weg te kunnen schrijven. Lijkt me logisch
5. Write back
En dan kan de uitkomst ook nog terug worden geschreven naar registers. Dit zijn kleine geheugenelementen. Zo kan de uitkomst van de instructie gebruikt worden voor volgende instructies.

Je ziet ook een program counter (afgekort als PC). Deze houdt bij waar je bent in het programma. Uit het geheugen worden de instructies geladen. De volgende instructie zit dus 4 bytes verder (immers, een instructie was 32 bits lang (= 4 bytes)). Zo kun je ook springen naar een ander stuk in het geheugen, maar dat komt in verdere blogs aan de orde.

Pipelining

Het laatste stukje voor deze blog. Tot nu toe hebben we de cyclus die 1 instructie doormaakt in één keer gedaan. De signalen door de logische poorten lijken voor ons bijna direct te gaan. Toch zit daar een beetje vertraging in. Maar alle schakelingen van poorten achter elkaar aan tellen steeds een beetje vertraging er bij op tot je toch een paar nanoseconden loopt te wachten op je resultaat. Vandaag zag ik van medetweaker Tjeerd84 een goed voorbeeld van de vertraging. Hij heeft in minecraft (ja een spelletje ) een simpele adder gebouwd. Vanaf 2:15 zie deze adder:



Deze vertraging tussen het aanbieden van data tot het op de uitgang van een logische poort staat heet de propagation delay. Deze bepaald ook de kloksnelheid. Het signaal moet namelijk eerst door de hele combinatie van poorten heen zijn voor je mag beginnen aan de volgende instructie.

Met pipelining ga je de grote schakeling in kleinere stukken hakken. Al die kleine schakelingen samen duren nog net zo lang, maar elk stukje op zich zelf natuurlijk minder lang. Daartussen komt geheugen om de stukjes te scheiden te houden. Het idee is dat deze stukken nu afzonderlijk van elkaar zijn. Omdat ze korter zijn kan de kloksnelheid omhoog.

Het gevolg is dat instructies nog net zo lang duren want ze moeten door de hele pipeline. We kunnen nu echter wel iets doen op alle stappen in de pipeline. Je voelt hetm misschien al aankomen, bij de MIPS bestaat de pipeline uit 5 stappen. Dat zijn de stappen die hierboven staan. Zo kan een instructie worden opgehaald. Zodra deze gedecode wordt kan de volgende instructie alvast worden opgehaald. Een kloktik verder is de eerste instructie bij de ALU, de 2e instructie wordt gedecode en de 3e instructie kan al worden opgehaald.

Alhoewel het niet minder lang duurt voor een instructie klaar is, is de doorvoer wel sneller. Als we de kloksnelheid door deze 5 stappen ook 5x zo hoog kan dan is de doorvoer ook maximaal 5 keer zo hoog. De Pentium 4 had een hele lange pipeline en daarom klokte deze ook zo hoog. Aan de lange pipeline zitten echter ook een aantal nadelen. Maar daar kom ik later op terug. De meesten kennen de megahertz myth wel . Het volgende blog laat zien waardoor dat precies komt.

Voor wie dit laatste stuk te snel ging een jip-en-janneke idee dat het illustreert. Men neme een groot doolhof met de regel dat slechts 1 persoon per keer in het doolhof mag zijn. Hak deze nu in 5 stukjes met als eis dat nog steeds 1 persoon in 1 doolhof mag zijn. Daarbij moet ieder persoon alle 5 doolhoven passeren. Zodra persoon 1 door doolhof 1 is en doolhof 2 instapt kan de volgende persoon al aan doolhof 1 beginnen. Hetzelfde geldt eigenlijk voor signalen door de pipeline van de processor.

You wouldn't run an engine on trust!

We doen er alles aan om de economie overeind te houden. Of eigenlijk beter, om te zorgen dat we weer economische groei krijgen. Economische groei, wat is dat eigenlijk? Economische groei is de groei in productie van goederen en diensten om zo waarde toe te voegen. Zie ook wikipedia.In 1377 had Ibn Khaldun, een arabische econoom, een mooie uitspraak op dit punt:

"When civilization [population] increases, the available labor again increases. In turn, luxury again increases in correspondence with the increasing profit, and the customs and needs of luxury increase. Crafts are created to obtain luxury products. The value realized from them increases, and, as a result, profits are again multiplied in the town. Production there is thriving even more than before. And so it goes with the second and third increase. All the additional labor serves luxury and wealth, in contrast to the original labor that served the necessity of life."

bron

Alhoewel de definities uitgebreid zijn en andere manieren van groei mogelijk zijn, is hier wel een belangrijke basis gelegd. Voor groei hebben we mensen nodig die werk kunnen verzetten. Maar niet alleen mensen kunnen dat. Een paard of ezel kan ook werk voor ons verzetten. Dus de populatie verhogen zal leiden tot groei. Een andere optie is de efficiëntie te verhogen.

Een wereldbevolking van biljoenen

We hebben een geweldige economische groei gezien. Dat klopt ook wel, de wereldbevolking is gestegen van een miljard ofzo naar zo'n 6,5 miljard vandaag de dag. En we hebben de populatie nuttige dieren ook wel kunnen verhogen door ze te fokken. Tel daar wat efficiëntie bij, et voila, de enorme economische groei de we kennen. Groei door er meer energie in te steken.

Ohja, er is ook nog één of ander raar zwart goedje wat we vonden toen we een pijp in de grond staken. En we hebben nog ergens kolen gevonden/ Daarmee kon men paarden vervangen voor treinen. Later kwam de auto. Fabrieken kunnen er op draaien. We konden opeens elektriciteit produceren en projectielen niet alleen de lucht in krijgen, maar ook de ruimte.

Uren slavenarbeid voor slechts €1,70

En dat alles bij de pomp. En wij zeuren dat de benzine duur is. En het mooist is, een groot deel van dat geld gaat via de staat terug in de economie. We hebben met zijn allen een koningenbestaan. Het is zo vanzelfsprekend dat die energie er is. Water komt ongelimiteerd uit de kraan, olie komt ongelimiteerd uit de grond. Nouja, bijna dan.

Alles om ons heen is aardolie, kolen of aardgas. Alles heeft wel ergens een link met één van de fossiele brandstoffen. De auto is logisch, dat zien we met eigen ogen. De meeste elektriciteit wordt er mee opgewekt. Fabrieken fabriceren miljoenen producten per dag met deze energie. Plastictassen en kleding wordt er mee gemaakt en eten in de supermarkt wordt mede mogelijk gemaakt met deze energie. We kunnen nog wel een dag doorgaan op deze manier. Maar ik ga mijn tijd niet verdoen

Energie als motor voor onze economische vooruitgang

De economische groei die we tot nu toe hebben gezien is eigenlijk te danken aan de enorme hoeveelheden goedkope "slaven" in de vorm van voornamelijk fossiele brandstoffen. Natuurlijk is er ook iets aan efficiëntie en optimalisatie gedaan. Maar deze stap is voornamelijk slechts mogelijk gemaakt met goedkope energie. Meer economische groei staat daarom tegenwoordig zo goed als synoniem aan meer, en het liefst goedkope, energie.

Onze leiders pompen nu massaal geld in het economische systeem uit de crisis te halen. Het "vertrouwen" moet volgens hen terug komen. Er moet "rust" zijn op de markt. Met genoeg "overtuigingskracht" zullen onze politici de economie wel weer uit het slop halen. Alles komt goed. De economie zal herstellen naar de normale situatie van onuitputtelijke groei. Maar is die aanname wel gegrond?

Kort na publicatie is de 2e poll vervangen door een foutje. Revote plz.

We leven een normaal leven. Dit is wat we normaal noemen. Maar is alles wel zo normaal als we denken? De 2e economische crisis die we nu hebben heeft me de afgelopen week aan het denken gezet. Ik heb bij de economie en alles wat wij daarin normaal vinden een vraagteken gezet. En nu ga ik jullie aan het denken zetten. Niets is wat het lijkt.

Allereerst van mijn kant de vraag met wanneer jullie de fossiele brandstoffen zo ver opraken dat we te weinig kunnen winnen en er een serieus tekort ontstaat. Alhoewel het dan niet echt op is, is het in onze beleving wel zo goed als op. Zoek dit niet op, maar antwoord gewoon wat je denkt. Het beïnvloed namelijk jou/ons leven.
Poll: Opraken fossiele brandstoffen
• 2010-2019
• 2020-2029
• 2030-2039
• 2040-2049
• 2050-2059
• 2060-2069
• 2070-2079
• 2080-2089
• 2090-ooit
• nooit

^{Ook een poll maken? Klik hier}

Nog eentje, same again. Zoek het niet op. Wanneer denk je dat we de piek in productie van fossiele brandstoffen bereiken om daarna alleen maar minder en minder te produceren?

Poll: Piek in productie fossiele brandstoffen
• Al geweest
• 2011-2019
• 2020-2029
• 2030-2039
• 2040-2049
• 2050-2059
• 2060-2069
• 2070-2079
• 2080-2089
• 2090-ooit
• nooit

^{Ook een poll maken? Klik hier}

Deze gegevens ga ik mogelijk nog gebruiken, maar is ook om een inzage te krijgen hoe overwegend intelligent publiek deze dingen inschat. Dan heb ik ook nog drie openvragen over. Deze ga ik zeker niet gebruiken, maar zijn bedoeld om jou na te laten denken. Onafhankelijk van wat anderen denken. Het is belangrijk dat deze beeldvorming onafhankelijk wordt gegenereerd. De vragen om de komende dagen over na te denken:

1. Waar zijn we gekomen dankzij de energie die fossiele brandstoffen hebben gegeven tot dusverre? En hoe zou de wereld er dus zonder uitzien?

2. Wat voor rol heeft energie in ons dagelijkse huidige leven?

3. Wat zouden we allemaal moeten veranderen om ons huidige niveau van luxe en welvaart te behouden wanneer er geen fossiele brandstoffen zijn?

Nu zul je denken, wat heeft dit met economie te maken. Zoals ik aangaf, niets is wat het lijkt. Meer daarover in het volgende blogje. De comments blijven uit. Hoe nieuwschierig ik en jullie wellicht ook zijn naar elkaars denken. Het is belangrijk om die in deze eerste fase juist niet met elkaar in aanraking te laten komen.