De afgelopen jaren is het aantal cores in mainstream desktopplatformen flink toegenomen. Er is nu zelfs een 16core-processor te krijgen. Maar wat is multithreading nou precies? En wat zijn de technische beperkingen en uitdagingen die hiermee gepaard gaan?

Toen in de jaren 2000 bleek dat de kloksnelheden van processors niet onbeperkt verhoogd konden worden, werd de keuze gemaakt om in te zetten op meer processorcores. Een systeem met meerdere cores was niet nieuw. Servers hadden al langere tijd multisocket-moederborden, met ondersteuning voor meerdere processors. Doordat nu meerdere cores werden geïntegreerd in een enkele zogenoemde ‘die’, werd multithreading een stuk toegankelijker.

Het daadwerkelijk goed benutten van die extra cores loopt wel achter op de technische verbeteringen. Sommige programma’s zijn goed geoptimaliseerd voor multithreading en kunnen 16 cores benutten, maar dit is lang niet altijd het geval. Dit heeft meerdere oorzaken, waar we nu naar gaan kijken.

Wat zijn threads?

Allereerst is het belangrijk om onderscheid te maken tussen processen en threads. Elk proces beschikt over zijn eigen geheugensegment en opereert in principe compleet onafhankelijk van andere processen. Het besturingssysteem voorkomt elke poging van een proces om bij het geheugen van een ander proces te komen. Daarentegen zijn threads niet volledig onafhankelijk. Ze kunnen bij het geheugen van andere threads komen, maar het is wel een andere ‘draad’ van executie, die tegelijkertijd met de andere threads wordt uitgevoerd. Een proces kan meerdere threads hebben, maar een thread kan zelf geen eigen processen hebben.

Er zijn twee soorten threads: software-threads en hardware-threads. Het aantal software-threads wordt bepaald door het totale aantal ‘draden’. Dit kan veranderen, afhankelijk van het opstarten en afsluiten van programma’s. Wanneer we in dit artikel het woord thread zonder kwalificatie gebruiken, bedoelen we software-threads.

Het aantal hardware-threads ligt juist vast, en is afhankelijk van het aantal cores en of er Simultaneous Multithreading (SMT) wordt ondersteund. Een 8core-processor met SMT heeft bijvoorbeeld 16 threads.

Ideaal is een situatie waarbij er evenveel software-threads zijn als hardware-threads. Wanneer er minder software-threads zijn, wordt de hardware niet efficiënt benut. Dat spreekt voor zich, maar ook een te groot aantal software-threads kan negatief uitpakken voor de prestaties.

Threads versus processen

Zowel processen als threads kunnen gebruikt worden voor ‘concurrency’, een term die iets breder is dan multithreading, omdat het alles omvat waarbij meerdere taken tegelijkertijd worden uitgevoerd. Het voordeel van het gebruik van processen is dat het crashen van een proces niet leidt tot het beëindigen van het programma: Google gebruikt voor zijn Chrome-browser bijvoorbeeld meerdere processen om de stabiliteit te verbeteren.

Het grote nadeel is dat het opstarten van een proces veel trager is dan het starten van een thread. Dit is vooral het geval op Windows, waarbij alle bronnen van tevoren toegekend moeten worden. Linux heeft een andere implementatie, waarbij een proces zichzelf kan klonen. Deze kloon of ‘fork’ heeft toegang tot alle bronnen van het eerste proces. Door copy-on-write krijgt het tweede proces pas zijn eigen kopie van delen van het geheugen, als het ernaar probeert te schrijven. Dit zorgt voor veel efficiëntere multiprocessing dan op Windows, waarbij het zoals gezegd voor het creëren van een proces noodzakelijk is dat alle bronnen van tevoren toegewezen worden.

©PXimport

Aangezien threads dezelfde bronnen delen, is het makkelijker voor threads om te communiceren dan voor processen (maar zoals in de paragraaf ‘Gezamenlijk geheugengebruik’ wordt uitgelegd, is dit ook erg gevaarlijk). Inter-process communication is een kunst op zich en dat gaat vaak via omwegen die veel zwaarder en trager zijn dan wat voor threads mogelijk is. Niettemin is er een plaats voor multiprocessing en dit is vaak ook een stuk eenvoudiger te programmeren dan multithreading.

Sommige taken zijn relatief eenvoudig multithreaded te maken, dit geldt bijvoorbeeld voor 3D-rendering en encoderen onder. Andere programma’s, zoals computer assisted design (CAD), zijn dan weer noodgedwongen singlethreaded. Dit is niet willekeurig, maar hangt af van hoe geschikt een bepaald programma is voor multithreading.

Rekenen

Het belangrijkste punt is dat er zo min mogelijk afhankelijkheidsrelaties moeten zijn. In wiskundige termen moet de taak associatief zijn, wat inhoudt dat het niet uitmaakt in welke volgorde hij wordt uitgevoerd. De plusoperatie is bijvoorbeeld associatief, waardoor de volgende simpele berekening prima in een andere volgorde kan worden uitgevoerd: x = 4 + 2 + 5 + 6.

We zouden deze som met of zonder afhankelijkheid kunnen uitvoeren. In het eerste geval berekenen we eerst 4 + 2, vervolgens 6 + 5 en uiteindelijk 11 + 6. Tijdens elke stap hebben we de uitkomst van de vorige berekening nodig. Stel dat we dit anders doen, dat we eerst 4 + 2 berekenen, dan 5 + 6 en tot slot de uitkomst hiervan bij elkaar optellen. Het aantal benodigde berekeningen verandert niet, dat blijft drie, maar de afhankelijkheid is verminderd.

Voor de mens wordt het er niet makkelijker op, maar een cpu zou de eerste twee berekeningen tegelijkertijd kunnen uitvoeren, waardoor er (uitgaande van een enkele klokcyclus voor de add-instructie) maar twee klokcycli nodig zijn en niet drie. Dit voorbeeld dient ter illustratie, want als deze getallen worden ingevoerd als ‘literals’ (vaste getallen), weet een beetje compiler wel het juiste antwoord direct in te voeren.

©PXimport

Heel spannend klinkt dit misschien niet, maar de vorige paragraaf verklaart waarom bijvoorbeeld het encoderen van video zo goed als perfect multithreaded is. Het beeld wordt opgedeeld in bijvoorbeeld zestien verschillende delen. Deze hebben ieder niets te maken met de andere delen, waardoor processorthreads er onafhankelijk aan kunnen werken. Uiteindelijk wordt het beeld samengevoegd, iets wat wel afhankelijk is van de eerdere berekeningen, maar triviaal is daarmee vergeleken.

Het verklaart ook waarom sommige andere taken heel slecht geschikt zijn voor multithreaded, zoals CAD en sommige Photoshop-filters. Deze hebben een zeer hoge mate van afhankelijkheid van andere delen van een foto, waardoor het niet mogelijk is om de taak op te splitsen in verschillende delen. Het gevolg is dat er minder threads aan kunnen werken.

In hoeverre multithreading de prestaties kan verbeteren, kan uitgerekend worden op basis van het deel van het werk dat parallel te maken is. Dit heet de wet van Amdahl en luidt als volgt: 1 / (1 – p), waarbij p staat voor het deel dat te parallelliseren is. Een programma waarbij de helft geschikt is voor multithreading, kan met een onbeperkt aantal cores maximaal twee keer zo snel worden. Dit is omdat het voor de helft van de tijd niet uitmaakt hoeveel cores er zijn.

Thread-safety en cache coherence

Drie termen die vaak worden gebruikt in combinatie met multithreading zijn thread-safe, thread-unsafe en thread-compatible. Dit gaat altijd over delen van een bepaald programma, oftewel functies. Allereerst heb je functies die thread-unsafe zijn. Deze kunnen überhaupt niet vanuit meerdere threads gebruikt worden. Dit is vrijwel altijd het resultaat van slecht programmeerwerk. Het standaardniveau is thread-compatible. Dit betekent dat de functie geen problemen oplevert, zolang er niets naar het geheugen wordt geschreven.

Zonder wijzigingen is er ook geen synchronisatie noodzakelijk. Het hoogste niveau is thread-safe. Dit betekent dat er data wordt gewijzigd, maar dit levert geen problemen op dankzij de synchronisatiemechanismes die we verderop bespreken.

©PXimport

Iets wat multithreading heel ingewikkeld maakt, is het probleem van ‘cache coherency’, een van de fundamentele uitdagingen in de computerwetenschap. Dit gaat over de vraag hoe je ervoor zorgt dat het geheugen consistent is wanneer er meerdere programma’s zijn die hetzelfde geheugen lezen en ernaar schrijven. Het grote probleem is dat deze lees- en schrijfoperaties via de cache gebeuren, omdat deze vele malen sneller is dan het werkgeheugen. Aangezien iedere core zijn eigen cache heeft, kan het gebeuren dat de waarde hier verschilt met die in het geheugen, doordat een andere thread het geheugen heeft veranderd, of doordat de huidige thread de cache heeft aangepast en deze nog niet is bijgewerkt in het geheugen.

Gezamenlijk geheugengebruik

Op zich is het geen enkel probleem als er meerdere threads gebruik willen maken van hetzelfde geheugen, zolang er maar geen enkele thread is die naar het geheugen schrijft. Als er meerdere threads naar het geheugen schrijven, is dat zeker een probleem. Dit maakt multithreading onmiddellijk een stuk moeilijker … en gevaarlijker! Om een heel simpel voorbeeld te geven: stel dat er een programma is met een functie die enkel een teller verhoogt. Het volgende is een voorbeeld in C++:

We willen dit programma graag multithreaded maken. Simpeler dan dit kan niet, dus je zou verwachten dat dit geen problemen zou kunnen geven. Helaas niet. Er gaat veel meer gepaard met het verhogen van een teller dan je zou verwachten. Dit heet een RMW- operatie: read-modify-write. Het systeem moet eerst uitlezen wat de teller is (bijvoorbeeld door het te kopiëren naar een processorregister), vervolgens dit aantal verhogen met 1 en dit daarna terugschrijven naar de geheugenlocatie. Vooral deze laatste stap gaat gepaard met een aanzienlijke vertraging. Wat als de teller op 2 staat en de functie wordt twee keer tegelijkertijd aangeroepen? In beide gevallen zal de functie 2 lezen en zal de verhoging daarom uitkomen op 3, terwijl het eigenlijk 4 zou moeten zijn.

Het kan nog erger. Het uitlezen ging het vorige voorbeeld immers nog netjes, ondanks het gelijktijdig beschrijven van exact hetzelfde geheugen. We krijgen óf de waarde van voor de laatste verandering óf die van daarna, maar niet iets anders. Dit is lang niet op alle processorarchitecturen zo (maar wel op x86). In een ander geval kan de tweede functie een willekeurig getal uitlezen, bijvoorbeeld 284 of -90. Dit getal wordt dan netjes vermeerderd met 1, maar het komt helaas op iets anders uit dan de 4 die we willen hebben. Het resultaat is ongedefinieerd gedrag, wat inhoudt dat er geen enkele garantie is voor wat de uitkomst is.

Een race-conditie is wanneer de uitkomst van een programma afhangt van de volgorde waarin of de tijd waarop bepaalde code toevallig wordt uitgevoerd. Een programma hoort deterministisch en daarmee voorspelbaar te zijn, dus een goed programma hoort vrij te zijn van race-condities. Wat we willen, is dat de tweede oproep van de functie netjes wacht totdat de vorige klaar is, en dat hij daarom ook de nieuwe waarde leest. Hiervoor is synchronisatie noodzakelijk, iets wat we hierna bespreken.

©PXimport

Mutex en Atomics

Een veelgebruikt synchronisatiemechanisme is een ‘mutual exclusion object’ (mutex). Een mutex is vergelijkbaar met een ‘stoplicht’, dat voorkomt dat meerdere threads tegelijkertijd bij een bepaald deel van het geheugen kunnen komen. Een thread die toegang wil, zal eerst een vrije mutex op ‘slot’ zetten. Elke volgende thread die bij de mutex komt, zal geblokkeerd worden totdat de mutex weer vrijgegeven wordt door de eerste thread.

Mutexen hebben alleen wel de nodige problemen. Zo zijn ze relatief sloom en gevaarlijker is het probleem van potentiële deadlocks. Dat is wanneer verschillende delen van een programma meerdere van dezelfde mutexen nodig hebben, dan kan het gebeuren dat een benodigde mutex nooit vrijgegeven wordt en dat het programma blijft hangen. Deze kans is nog aanzienlijker wanneer met andere mutexen beschermde delen van het programma afhankelijk zijn van elkaar. Als deze dan tegelijkertijd gedraaid worden, dan wacht de ene thread op een vrije mutex totdat hij zijn eigen mutex vrijgeeft, terwijl de eerste mutex niet vrijkomt totdat de eerste thread klaar is met zijn werk. Er moet dus op een goed doordachte manier geprogrammeerd worden. Een simpel voorbeeld in C++:

In sommige gevallen kan het lonen om in plaats van een gewone mutex een ‘reader writer’-mutex te gebruiken. Deze kan of aan één thread schrijftoestemming geven of aan een onbeperkt aantal threads leesbevoegdheid. Aangezien alleen veranderend geheugen race-condities oplevert, kan dit de prestaties verbeteren als er maar weinig naar het beschermde geheugen wordt geschreven.

Concurrency-problemen kunnen in sommige gevallen ook opgelost worden door het gebruiken van variabelen die geen tussenstaat laten zien. Deze heten ‘atomics’ in C en C++, en ‘volatile’ variabelen (vluchtige variabelen) in Java en C#. Als we een atomische variabele gebruiken voor ons eerdere scenario, dan begint de tweede operatie pas wanneer de eerste klaar is. Dan heb je niet het probleem dat een van de vermeerderingen potentieel verloren gaan.

Volgorde

Simpele atomics lossen niet alle problemen op. Atomische variabelen kunnen ook garanderen dat bepaalde code in een voorgeschreven volgorde wordt uitgevoerd. Elke atomische operatie heeft een bepaalde ‘memory barrier’, ook wel ‘memory order’ genoemd. Deze barrière bestaat uit een ‘acquire’-laadoperatie die wordt gekoppeld aan ‘release’-opslagoperatie. Tussen deze twee operaties wordt er een zogenoemde ‘çritical section’ gecreëerd. Instructies binnen dit deel is sterk beperkt in herordening: ze mogen niet buiten de sectie worden gebracht door de compiler of de processor. Dit garandeert dat alle instructies binnen (en voor) dit deel zijn uitgevoerd wanneer er een ‘acquire’ wordt uitgevoerd. Ook wordt er gegarandeerd dat de laatste waarde van de atomische variabele is geschreven naar het geheugen en de caches, zodra de acquire is uitgevoerd.

Als er toegang wordt gevraagd voordat het systeem hier klaar mee is, wordt toegang tot de betrokken delen van het geheugen geblokkeerd. Dit om te voorkomen dat er iets gebeurt met de tussenstaat van de variabele. Hier zijn speciale machine-instructies voor, die het werk efficiënter kunnen verrichten dan een mutex. Het volgende voorbeeld laat zien hoe dat werkt.

In de praktijk komt dit erop neer dat een ‘release’ informatie publiceert die een ‘acquire’ kan opvragen (bij een RMW-operatie is er een gecombineerde acquire en release). Waar zou dit nuttig voor kunnen zijn? Veel systemen moeten van een valide staat naar een andere valide staat gebracht worden, zonder dat er het een en ander kan gebeuren in de tussenstaat. Om maar een voorbeeld te geven: bij het uitvoeren van een banktransactie is het een goed idee om zowel de vermindering als de vermeerdering op de respectieve rekeningen als een alles-of-niets-transactie uit te voeren.

Het voordeel van atomics ten opzichte van een mutex, is dat ze sneller zijn en dat deadlocks niet tot de mogelijkheden behoren. Het nadeel is dat ze nog altijd substantieel langzamer zijn dan gewone variabelen, vooral wanneer het gaat om schrijfacties. Veranderingen moet immers verspreid worden naar niet alleen de verschillende caches, maar ook naar het werkgeheugen. In de tussentijd mag er geen enkele andere thread gebruikmaken van de oude waarde. Een verder nadeel is dat niet alles met atomische variabelen geïmplementeerd kan worden. Programma’s die hier wel gebruik van maken, heten ‘lockfree’, omdat ze geen gebruikmaken van een mutex-slot.

Natuurlijk is het belangrijk hoe een keuken eruitziet, maar het draait vooral om hoe je hem gebruikt. Een goede keuken sluit aan op jouw manier van koken en leven, met een logische indeling en keuzes die het dagelijks gebruik makkelijker maken. In dit artikel laten we zien hoe je stap voor stap tot een ontwerp komt dat echt bij je past – van de eerste schetsen tot het kiezen van werkbladen, apparatuur en grepen.

Begin bij de ruimte en je gewoontes

Voordat je nadenkt over frontjes en kleuren voor je nieuwe keuken, kijk je naar de ruimte die je hebt. Is het een dichte keuken of is hij open en loopt hij naadloos door in je woonkamer? Hoeveel wandlengte is beschikbaar? Waar zitten de ramen, deuren en aansluitpunten? Het helpt om de plattegrond van je keuken op schaal te tekenen. Nog beter: gebruik een digitale tool waarmee je je ontwerp meteen in 3D ziet (zie kader verderop).

Daarna kijk je naar je eigen kookgedrag. Sta je vaak uitgebreid te koken of wil je vooral snel en makkelijk eten kunnen maken? Heb je veel spullen die opgeborgen moeten worden of houd je het graag minimalistisch? De antwoorden op die vragen bepalen welke indeling het best werkt: een rechte wandopstelling, een hoek, een U-vorm of juist een kookeiland.

Let bij het indelen op de zogeheten werkdriehoek. Daarmee bedoelen we de afstand tussen kookplaat, spoelbak en koelkast. Die drie punten vormen samen het hart van je keuken. Hoe dichter deze drie bij elkaar liggen, hoe makkelijker en sneller je werkt. Je hoeft minder heen en weer te lopen en hebt alles onder handbereik.

De ideale werkhoogte

De ideale hoogte van een aanrecht hangt af van je lichaamslengte. Werk je te laag, dan moet je steeds voorover buigen. Werk je te hoog, dan gaan je schouders omhoog. Beide zijn vermoeiend. Daarom loont het om bij het samenstellen van je keuken stil te staan bij de juiste werkhoogte. Een handig uitgangspunt: als je rechtop staat met je armen gebogen in een hoek van 90 graden, dan ligt het werkblad ongeveer 10 tot 15 cm onder je ellebogen. Hieronder zie je een indicatie op basis van je lengte.

Let op: dit zijn richtlijnen. De beste hoogte bepaal je uiteindelijk door zelf even te testen wat prettig voelt – bijvoorbeeld op een instelbaar werkblad of in een showroom met verschillende hoogtes.

Hoeveel opbergruimte heb je nodig?

Gebruik je vaak pannen of bakvormen, dan heb je meer aan een paar brede lades dan aan een kast met planken. Je ziet in één oogopslag wat waar ligt, en je hoeft niet op je knieën om achter in het kastje iets te zoeken. Dat werkt net wat makkelijker – zeker als je dagelijks kookt. Zorg ook dat je je spullen straks logisch kunt verdelen. Het is handig om keukengerei bij de kookplaat op te bergen, schoonmaakspullen onder de spoelbak, en om je voorraad in een hoge kast of ladeblok te bewaren.

Nog iets om bij je ontwerp rekening mee te houden: laat voldoende ruimte over om kastdeuren te openen zonder dat ze elkaar raken. Ook is het prettig om rond het fornuis en de spoelbak minstens 90 centimeter loopruimte te hebben.

©Phurichai

Materialen en stijl: meer dan alleen smaak

Frontjes bepalen in grote mate de uitstraling van je keuken, maar het materiaal zegt ook iets over onderhoud en levensduur. Een gelakte keuken ziet er strak uit, maar is gevoeliger voor krassen en vingerafdrukken. Hout voelt warm aan, maar vraagt meer onderhoud. Kunststof of melamine is onderhoudsvriendelijk en budgetvriendelijk, maar minder duurzaam op de lange termijn.

Voor het werkblad is het goed om verder te kijken dan alleen uiterlijk. Composiet is sterk en makkelijk schoon te houden. Keramiek kan tegen hitte, maar is gevoelig voor harde klappen. Marmer en graniet hebben een unieke uitstraling, maar vereisen regelmatig onderhoud. Houd bij je keuze rekening met hoe je de keuken gebruikt en hoeveel tijd je aan schoonmaak en onderhoud wilt besteden.

Ook de grepen spelen een rol. Een greeploze keuken oogt strak, maar kan onpraktisch zijn als je snel iets wilt pakken. Met zichtbare grepen maak je het jezelf makkelijker – en kies je meteen een detail dat stijl en karakter toevoegt.

©Анастасия Купавц

Apparaten kiezen die bij je passen

Een keuken zonder apparatuur bestaat niet, maar de vraag is welke apparaten je nodig hebt – en hoe je ze slim plaatst. Veel mensen kiezen tegenwoordig voor een inductiekookplaat. Die werkt snel, is energiezuinig en makkelijk schoon te maken. Let wel op de aansluiting: sommige modellen werken op een gewoon stopcontact, maar krachtigere platen hebben een aparte 3-fasengroep nodig in de meterkast.

Belangrijker dan het type is de vraag hoeveel kookzones je nodig hebt. Kook je vaak met meerdere pannen tegelijk? Dan is een brede plaat met vijf of zelfs zes zones handig. Sta je meestal alleen eenpansgerechten te maken, dan volstaat een compactere uitvoering.

Bedenk of je een losse oven wilt, een combi-oven of een stoomoven. Denk na over het formaat en de plaatsing van je koelkast: vrijstaand of inbouw, met vriesvak of zonder. En vergeet de afzuiging niet. In een open keuken werkt een plafondunit of geïntegreerde afzuiging in het kookplaatblad vaak beter dan een klassieke afzuigkap aan de muur.

Bij de plaatsing geldt: apparaten die je vaak gebruikt, moeten makkelijk bereikbaar zijn. Een oven op ooghoogte voorkomt bukken. De vaatwasser naast de spoelbak scheelt heen en weer lopen. Kies je voor een Quooker of een losse kokendwaterkraan? Denk dan ook aan de benodigde ruimte voor het reservoir.

Van ontwerp naar uitvoering

Ben je tevreden met je ontwerp? Neem dan de tijd om alles nog één keer kritisch door te lopen. Kloppen de looproutes? Heb je voldoende werkruimte tussen kookplaat en spoelbak? Zit de oven op een prettige hoogte? Zijn alle opbergruimtes logisch ingedeeld? Kijk ook naar de plaats van je aansluitpunten: water, stroom en afzuiging moeten aansluiten op wat je hebt gepland.

Heb je je keuken in een 3D-tool ontworpen? Dan kun je die visualisatie gebruiken om een afspraak te maken met een adviseur of keukenwinkel. Samen kijk je dan of je ontwerp technisch haalbaar is en welke materialen en apparaten beschikbaar zijn. Pas als alles klopt – van de maatvoering tot de afwerking – is het tijd om je keuken echt te gaan bestellen.

Met een adviesprijs van 849 euro is de Nothing Phone (3) het duurste toestel dat dit jonge merk tot op heden heeft uitgebracht. Zelf presenteert Nothing dit model als een heus vlaggenschip, maar uit onze ervaring blijkt dat deze smartphone dat niveau niet helemaal haalt.

De Nothing Phone (3) voelt met zijn aluminium frame en matte afwerking degelijk aan, maar de glanzende transparante achterkant is wel besmettelijk voor vingerafdrukken. De telefoon heeft vier knoppen, inclusief de Essential Key van de Phone (3a) voor screenshots en spraaknotities. Qua ontwerp haal je de meest unieke smartphone van dit moment in huis. Nothing zet hoog in op esthetiek en verheft de doorgaans saaie achterkant tot een waar kunstwerk. Net als bij andere Nothing-toestellen is die tevens functioneel; zo is er onder meer een rode stip die oplicht zodra je gaat filmen.

De meest controversiële verandering is het verdwijnen van de kenmerkende Glyph-strips. Die zijn voor de gelegenheid vervangen door de Glyph Matrix, een klein monochroom schermpje rechtsboven op de achterzijde van het toestel. Dat matrixdisplay biedt meer functionaliteit dan de ledstrips op de voorgangers, zoals notificaties en spelletjes, maar mist de unieke uitstraling van de Glyphs op zijn voorganger. Vooralsnog zien we alleen potentie in dat extra schermpje. Ontwikkelaars moeten nog aan de bak met nuttige functies en games, want tot op heden is de functionaliteit dusdanig beperkt dat je het onderdeel alleen voor meldingen kunt gebruiken.

©Wesley Akkerman

©Wesley Akkerman

De Essential Key zit onder de powerknop.

Op zich een prima scherm

Het scherm is redelijk op vlaggenschip-niveau. Het toestel heeft een oleddisplay van 6,67 inch met een hoge resolutie en een verversingssnelheid van 120 Hz. De (piek)helderheid is hoog genoeg voor gebruik in de zon, terwijl de kleurweergave zowel nauwkeurig als levendig is. Verder is er support voor HDR10+- en Ultra HDR-content. Helaas mist het scherm LTPO-technologie. Dat betekent dat de verversingssnelheid niet lager dan 30 Hz zakt bij statische content. In de praktijk kan dat de batterijduur negatief beïnvloeden.

De Nothing Phone 3 is de eerste telefoon die de Snapdragon 8s Gen 4-processor gebruikt. De chipset presteert vergelijkbaar met de Snapdragon 8 Gen 3, met lichte grafische verbeteringen en een hogere topsnelheid. Hoewel het toestel in dagelijks gebruik vlot aanvoelt en visueel intensieve games prima aankan, blijft de 8s Gen 4 in rauwe prestaties achter bij de nieuwste échte vlaggenschip-processors, zoals de Snapdragon 8 Elite. Potentiële kopers betwisten daarom of de Phone (3) 'flagship material' is of niet – maar bij normaal gebruik merk je geen vertragingen.

©Wesley Akkerman

©Wesley Akkerman

Voorbeeld van een Glyph Matrix-functie: het batterijniveau.

©Wesley Akkerman

Voorbeeld van een Glyph Matrix-functie: de tijd.

Warmteontwikkeling

Wat ook opvalt, is de warmteontwikkeling tijdens het gebruik. Het toestel kan namelijk flink opwarmen tijdens het uitvoeren van zwaardere taken, zoals bij het gamen. Dan kun je de telefoon bijna niet meer comfortabel vasthouden. Helaas een typisch Qualcomm-euvel dat we vaker tegenkomen. Verder is het zo dat de smartphone met een totaal vermogen van 5150 mAh qua accu ook wat achterloopt op zijn rivalen. Bij intensief gebruik moet je de telefoon soms eerder opladen dan je zou hopen. Bij normaal gebruik kom je er echter de dag wel mee door.

De Nothing Phone (3) draait op Nothing OS 3.5, gebaseerd op Android 15, en biedt een vloeiende, strakke interface met fijne, aanpasbare elementen en opvallende widgets. Net zoals op de Nothing Phone (3a) kom je ook hier de Essential Space tegen, een aparte sectie die screenshots opslaat en AI gebruikt om belangrijke informatie te extraheren en te organiseren, inclusief transcripties van spraakmemo's. Dat laatste gaat verrassend goed, met hier en daar een enkele typefout. Zo'n memo maak je snel aan door bijvoorbeeld de Essential Key ingedrukt te houden.

0,6x

1x

2x

Minder functies, maar wel uniek

Hoewel Nothing OS minder functies heeft dan sommige andere Android-skins, is het vrij van bloatware (erg belangrijk!) en legt het systeem de nadruk op een minimalistische, monochrome esthetiek. Dat maakt de software-omgeving daadwerkelijk anders dan je elders aantreft. Nothing belooft daarnaast vijf Android-upgrades en zeven jaar lang beveiligingspatches. Dat is een uitstekende score, meer dan gemiddeld, maar Nothing staat helaas niet bekend om de snelle uitrol van nieuwe softwareversies. Houd dus wat rekening met vertragingen op dat gebied.

Dat bewijst bijvoorbeeld de uitrol van Android 16. Die versie is reeds beschikbaar, maar de Nothing Phone 3 wordt geleverd met Android 15. Nu is het tegelijkertijd zo dat versie 16 echt nog maar net uit is, maar toch voelt dit aan als een gemiste kans. De upgrade moet echter voor het einde van het jaar verschijnen, dus daar kun je naar uitkijken. Verder heeft de nieuwe AI-zoekbalk nog een eigenaardigheid. Je kunt daarmee van alles opzoeken (apps, contacten, functies en meer), maar de Essential Space wordt daarin niet meegenomen.

3x

6x

6x

3x

Beste camera's tot nu toe, maar…

Verspreid over de achterkant tref je een veelzijdig camerasysteem aan. Dat bestaat uit drie sensoren van 50 megapixel: een hoofdcamera, een ultragroothoek- en een periscooplens. Daarmee zoom je tot 3x optisch in. Ook is er nog een selfiecamera van 50 megapixel. Alle camera's ondersteunen video-opnamen in 4K-kwaliteit bij 60 fps. Overdag leveren ze gedetailleerde foto's met levendige, accurate kleuren en een breed dynamisch bereik, hoewel er soms lichte oververzadiging optreedt en de sluitertijd wat beter kan.

De telelens presteert goed tot en met 6x inzoomen met behoud van helderheid en kleuren. Die lens is ook geschikt voor macro-opnames tot 10 centimeter. Over het algemeen vinden we dit de beste lenzen die Nothing tot nu toe aanbiedt, maar ook op dit vlak presteren concurrerende modellen beter. Vooral de Pixels en Galaxy's leveren betere kwaliteit bij weinig licht en snelle bewegingen. Nothings beeldverwerking zorgt gelukkig voor consistente kleuren over alle lenzen en voor goede diepte, maar de camera's kunnen dus nog verbetering gebruiken.

2x

1x

0,6x

Nothing Phone (3) kopen?

De Nothing Phone (3) streeft duidelijk naar onderscheid met zijn unieke ontwerp en het nieuwe Glyph Matrix-systeem, maar op cruciale punten blijft hij achter bij concurrenten in zijn prijsklasse. Hoewel de Snapdragon 8s Gen 4-processor echt wel vlot is voor dagelijks gebruik, blijft-ie op papier achter bij de concurrentie. Niet dat je al die snelheid per se nodig hebt (eerlijk is eerlijk: veel mobiele cpu's zijn echt overkill), maar die dingen gaan wel tellen als je een hogere prijs betaalt. Het helpt ook niet dat het toestel echt heet wordt onder hoge druk.

Ondanks een capabel camerasysteem presteert de Phone (3) onder uitdagende omstandigheden niet zo goed als je zou willen of verwachten. De batterijduur is adequaat, maar niet uitzonderlijk, en de usb-c-poort blijft steken op de oudere 2.0-standaard. Hoewel Nothing OS 3.5 een strakke en unieke software-ervaring biedt met langdurige updates, compenseren de software-extra's en het innovatieve Glyph-systeem de hardwarematige tekortkomingen niet voldoende om de Nothing Phone (3) een toptoestel te noemen, zeker niet gezien zijn prijskaartje van 850 euro.