Transactional memory
Wat misschien wel de grootste impuls aan de prestaties van software zal geven – mits die daarvoor expliciet geschikt gemaakt wordt – is de komst van Transactional Synchronization Extensions (TSX). Deze nieuwe technologie verbetert de manier waarop meerdere threads van hetzelfde programma omgaan met data in het geheugen. Het kan ervoor zorgen dat multithreaded software beter kan schalen naar meerdere cores.
Wat is het geval? Wanneer een thread van een programma op dit moment aanpassingen aan de data van het programma in het geheugen wil doen, wordt in de regel het gehele geheugensegment op slot gezet. Andere threads kunnen de data dan enkel nog read-only of soms zelfs helemaal niet meer benaderen. Vergelijk het met wanneer twee mensen in hetzelfde bedrijf aan dezelfde Excel-spreadsheet willen werken. Zodra één iemand de sheet geopend heeft, krijgt de ander bij openen een melding van Excel dat de sheet alleen in een alleen-lezen modus geopend kan worden. (We gaan er bij deze analogie even gemakshalve vanuit dat de werknemers nog niet hebben ontdekt dat het ook mogelijk is om een Excel-sheet te delen). Net zoals de twee werknemers op elkaar moeten wachten om data in de sheet aan te passen, moeten de verschillende threads binnen de CPU dat ook. Wachten is in beide gevallen zonde van de tijd. Zo’n complete lock is vaak niet nodig: net zoals het bij Excel-sheet best mogelijk is dat de twee medewerkers in een compleet ander gedeelte van de sheet werken, kan het bij meerdere threads ook zo zijn dat ze aanpassingen doen in gedeeltes van het geheugen waar de ander niet afhankelijk van is.
Een oplossing is om bij aanpassingen van het geheugen met zogenaamde transacties te gaan werken, een concept dat voor database-techneuten gesneden koek zal zijn. Bij een transactie worden alle aanpassingen van een bepaald lijst opdrachten opgespaard en uiteindelijk in één keer verwerkt. Mocht er tijdens het verwerken van de transactie iets veranderen waardoor deze niet meer kan worden uitgevoerd, wordt alles teruggedraaid en krijgt de software de mogelijkheid om het opnieuw te proberen of om de opdracht te laten zitten. Dat werkt uitstekend voor databases en kan net zo goed werken voor geheugen.
De Transactional Synchronization Extensions bestaan uit twee implementaties. Hardware Lock Elision (HLE) is de simpelste en is backwards compatible met bestaande processors. Wat hier gebeurt is dat de instructies die een stuk van het geheugen ‘locken’ worden voorafgegaan door twee instructies die alleen de TSX-processors snappen. Oudere processors slaan die instructies over en geven ouderwets de volledige lock, net als vroeger. Bij de Haswell processors zorgen de prefix-instructies dat de lock niet echt wordt gezet, maar dat de aanpassingen aan het geheugen van de betreffende thread in een transactie worden gedaan. Zolang de fictieve lock aanwezig is, houdt de processor exact bij wat de thread en de andere threads in het betreffende gedeelte van het geheugen uitvoeren. Zodra er een conflict is (twee threads willen dezelfde data overschrijven of de ene thread leest een stuk data dat de ander net wil gaan overschrijven), dan draait de processor de transactie terug vóór de blokkering wordt opgeheven.
De tweede variant is Restricted Transactional Memory. Wanneer de software op deze wijze wordt gecompileerd, is deze niet compatibel met oudere processors, maar hebben ontwikkelaars zélf invloed op de transacties. Ze kunnen deze zelf starten, stoppen en ook opgeven wat er moet gebeuren wanneer een transactie wordt teruggedraaid. Bestaande programmeertalen zijn trouwens nog niet erg geschikt om hiermee te werken, maar Intel heeft een uitbreiding op de C++ programmeertaal voorgesteld om het werken met geheugentransacties makkelijker te maken.
4 besproken producten
Vergelijk | Product | Prijs | |
---|---|---|---|
![]() |
Intel Core i5 4430 Boxed
|
Niet verkrijgbaar | |
![]() |
Intel Core i5 4670
|
Niet verkrijgbaar | |
![]() |
Intel Core i5 4670K
|
Niet verkrijgbaar | |
![]() |
Intel Core i7 4770K
|
Niet verkrijgbaar |