Onderzoekers versnellen singlethreaded applicaties

Ik zie ook niet helemaal in hoe dat in z'n werk gaat. Je wacht voor zulke alloceer en andere memory functies gewoon op resultaat, het is niet echt geschikt voor asynchroon werk. Verder zie ik ook niet helemaal in wat de MMT verder moet doen.

Het enige voordeel wat ik zie is de hoofd thread die heeeel eventjes een slaapje kan doen tijdens een allocatie, maar dat brengt voor het proces zelf geen snelheidswinst naar boven.

Een malloc is idd behoorlijk blocking. Ik weet het fijne niet van hun implementatie, maar er kan natuurlijk wel wat speelruimte gecreeerd worden door een malloc te doen, ruim voordat het geheugen werkelijk gebruikt wordt. En variableledeclaratie doe je traditioneel aan het begin van een functie, dus er zal al een hoop software zijn dat dat doet. (al zal een groot deel ervan gewoon op de stack staan)
Je kunt dan nog wat andere instructies doen terwijl de andere core zich bezighoude met de malloc.

En/of ze zouden een klein beetje geheugen op voorhand kunnen alloceren en daarmee een deel van de hits opvangen. Alleen de echt grote mallocs zijn dan nog blocking.

Wat natuurlijk wel mogelijk is is dat er een analyse wordt gedaan voor de verschillende geheugenallocaties, en dat er een schatting wordt gemaakt voor de volgende paar allocaties die mogelijk komen gaan. De manager zou dan al kandidaatblokken klaar kunnen zetten, zodat daar ten tijde van een daadwerkelijke malloc() niet meer naar gezocht hoeft te worden.

Ik heb de paper heel snel doorgebladerd en het lijkt erop dat er inderdaad al wat van tevoren klaar wordt gezet. Zie figuur 5 op pagina 6 van de paper.

Waarschijnlijk is het grootste voordeel bij de free aanroep, maar waarschijnlijk is het in de aparte thread makkelijker/sneller om bij te houden waar ruimte beschikbaar is (en welke grootte), zodat de malloc sneller een geschikte ruimte beschikbaar kan stellen.

persoonlijk vind ik dit geen handige uitvinding. ze doen aan:

* free() batchen ( 200 stuks in 1x )
* inderdaad de stack preallocaten, en
* 1 thread houdt continue 1 code wakker, via een busy loop voor de memory thread, omdat ze vinden dat de wakeups te traag zijn.

het nadeel ? sowieso heb je plots 1 core minder om dingen te doen op je computer. en dat is bij een single process zoals een webbrowser bij mn oma misschien nog realistisch, maar op een typische computer draait er altijd nog wel wat in de achtergrond, en schiet je jezelf dus in de voet.

sowieso zul je dit niet op een server gebruiken, tenzij je een server dedicated voor 1 applicatie hebt.

en verder, ze stellen een prestatiewinst van 20 procent te hebben. Ik betwijfel of ze dat getal kunnen halen. Stel je hebt een quad core, dan heb je bij gebruik van deze MMT implementatie effectief een triple core over, dus sowieso een 25% performance verlies. maar je memory mapping is maximaal 20% sneller?

En dan ga je er vanuit dat je een crappy malloc/free implementatie gebruikt?

Nah, dit is een mooie laboratoriumproef geweest, maar voor de echte wereld niet geschikt.

ik betwijfel of dit wel echt zo nuttig is...

Als ik het zo lees dan gaat het ongeveer zo:

• Hej, laten we memory management in een aparte thread gooien!!!111
• Argh, communicatie / synchronisatie kost veel teveel tijd
• Laten we onze flinterdunne client ombouwen tot een dikke meta-memory manager om overhead zoveel mogelijk te verbergen

Fork dan een bestaande memory manager en implementeer daar je pre-allocator en bulk-deallocator in. Toegegeven, dan ben je niet mee onafhankelijk van de onderliggende memory manager (de paper grijpt elke mogelijkheid die ze hebben aan om te benadrukken dat ze mm agnostic zijn), maar als het aanslaat dan is het veel breder inzetbaar (ook voor applicaties die toch al multi-threaded zijn bijvoorbeeld).

Als ik het zo lees halen ze het overgrote deel van hun winst uit het optimaliseren van het memory management:

quote: pagina 11

We note that speculative bulk allocation should have positive effect on cache locality, on the other hand bulk deallocations may have negative effect. Interestingly, speculative preallocation and bulk deallocation work synergistically so that overall locality of the program is significantly improved (Figure 10).

En ze hebben een mazzeltje:

quote: pagina 10/11

The reason why MMT improves the L2 cache and TLB performance is that the code and cache behavior of regular computation in the benchmarks and the memory allocation library are different enough that they produce mostly negative interference. When they run in separate cores with the MMT approach, they no longer compete and interfere for core resources or cache resources.

Maak je geen zorgen met de komst van UML en dergelijke concepten voor programmeren en de steeds betere auto code generators worden programmeurs binnenkort wel overbodig (enfin, dat denk ik toch). Ik bedoel hiermee programmeur als degene die een de analyse van een software architect uitvoert (omzet in concrete code). Je zal dan een shift zien naar hardcore programmeurs die dergelijke software opzetten en de andere groep zal z'n heil moeten zoeken met die tools (en dus software architect spelen/zijn ... niet vervelend bedoelt).

Afgezien van een beetje programmeren bevindt ik me nadrukkelijk aan de gebruikerskant.van software. @gamepower2005: je reactie verwoordde heel mooi hoe deze ontwikkeling is te beoordelen. Met de afhankelijkheid die het dochterproces (geheugenmanagement) van de moeder zal hebben (applicatie) en de extra resources die het zal vragen vindt ik de versnelling van 20 procent toch behoorlijk te noemen. Het lijkt er wel op dat de 20% de absolute max. in het spectrum zal zijn. De gemiddelde versnelling zal dus lager zijn.

Niet heel efficient? Zonder meer. Kost de nodige resources. Yep {alsof tekstverwerkers nu al niet genoeg opvreten}. Wordt dit een eindprodukt? Twijfelachtig. De overmaat aan computercapaciteit vergroot wel de kans erop (de maatschappelijke druk hiervan is enorm ). Hoeveel cores zouden in Nederland inmiddels wel niet duimen zitten te draaien?

Kan het programma je in de staart gaan bijten, als het aantal te bedienen threads te groot wordt? Kan bandbreedte naar het geheugen een bottleneck vormen? Blijft geheugengebruik efficient (het pre-allocatie verhaal)? Zonder iets zinnigs over programmadetails te kunnen zeggen moet er toch iets te bouwen zijn wat zich voortdurend volgend opstelt aan zijn omgeving? Een dergelijk programma zou dus primaire applicaties niet voor de voeten moeten gaan lopen en waar het kan inkicken om een programma te versnellen. Ook moet het het OS de gelegenheid geven zijn werk te doen. Het programma zou dus niet statisch gelinked moeten zijn aan een bepaalde applicatie maar meer moeten kijken naar wat er aan applicaties draait en waar het, met de beschikbare resources, het meest effectief aan kan bijdragen. Van mijn part pompt het binnen deze kaders de cpu capaciteit en memory (bandbreedte) dan lekker vol.

Zo'n programma zou naar mijn idee dus niet zozeer autonoom moeten zijn en uitsluitend gericht op een of enkele applicaties, maar meer als een soort schil tussen OS en applicaties. Misschien zelfs een extensie van het OS zelf. Bovenstaande criteria vergroten de overhead van het programma wel. Het moet zich immers behoorlijk intelligent opstellen.

Zelf vond ik dit een heel interessant bericht.... Waarom? Het stoort me behoorlijk, met multicore processoren al bijna 5 jaar beschikbaar, dat de softwarewereld zo traag reageert. JaJa, multicoreprogrammeren is heeel complex, kregen we midden 2000 te horen, en is een wat onderhuidse feature die bij klanten nog niet als een sellingpoint is te communiceren. Althans, dat lijkt me de heersende opvatting. Mijn indruk is bovendien dat proffessionele software hekkesluiter is in dit proces. Terwijl daar toch echt veel te verdienen is. (Ik hoop dat medetweakers me op het tegendeel kunnen wijzen).

Hoe dan ook, dagelijks neemt het potentiaalverschil van de niet gebruikte processorcapaciteit toe. Wanneer gaat die emmer eindelijk eens leeglopen? In dit kader ben ik heel blij met dit soort initiatieven. Niet om de software an sich, maar meer omdat ze fungeert als een katalysator in een proces dat hoog nodig eens vlotgetrokken moet gaan worden.

[Reactie gewijzigd door teacup op woensdag 7 april 2010 22:01]

Deze onderzoekers hebben bepaalde geheugenoperaties parallel gemaakt en in sommige situaties win je hier snelheid mee, namelijk als je iets nuttigs kunt gaan doen terwijl je wacht tot het geheugen beschikbaar is.

Ja en nee. Wat je zegt klinkt meer als hyperthreading; als de ene thread gestalled is dan hou je (de execution units van) de CPU bezig met instructies van een andere thread. Ik heb net de paper doorgelezen en dat is juist niet wat ze doen. Hun oplossing is om de MMT (memory management thread) "vooruit te laten werken", er worden geheugenblokken gealloceerd waar nog niet om gevraagd is. Zodra er dan wel om gevraagd wordt kan, als de pre-allocator goed gegokt heeft, dan onmiddelijk een blok geheugen worden toegekend.
Je hebt wel gelijk dat de hoofdthread "iets nuttigs" doet terwijl de MMT bezig is: de hoofdthread draait gewoon door terwijl de MMT aan het pre-allocaten is. Maar dat werkt alleen als de voorspelling correct is; als de pre-allocator geprutst heeft (als er geen blok klaarstaat) dan wordt de hoofdthread gewoon net zo hard gestalled als zonder MMT.