Onderzoekers versnellen singlethreaded applicaties

Informatici hebben een manier gevonden om singlethreaded programma's als webbrowsers toch op meer dan één thread te laten draaien. Hiertoe scheiden ze de werklast in een rekenintensieve stap en een stap voor geheugenmanagement.

Hoewel vrijwel elke pc die in de winkels wordt verkocht over meer dan één core danwel thread beschikt, kan de meest gebruikte software, zoals webbrowsers en tekstverwerkers, nauwelijks multithreaded worden geprogrammeerd. Dat stellen de informatici van North Carolina State University. De werklast van deze lineaire programma's is moeilijk te splitsen en op die manier over verschillende, al dan niet virtuele cores te verdelen.

De onderzoekers van de Amerikaanse universiteit zeggen erin te zijn geslaagd om de rekenintensieve stap van bijvoorbeeld een browser te scheiden van de geheugenmanagementstap. Door dit laatste proces in een aparte thread te laten draaien, zou software als browsers of tekstverwerkers tot twintig procent sneller kunnen zijn. De informatici ontwikkelden hun geheugenmanagement zodanig dat deze transparant met de doelsoftware kan samenwerken, zodat geen aanpassingen in de broncode nodig zijn.

Zij noemen het proces, waarbij een aparte thread voor dynamisch geheugenmanagement wordt gecreëerd, een memory management thread. De aparte thread is een mmt-server, die het daadwerkelijke geheugenmanagement voor zijn rekening neemt. De mmt-client is een deel van de hoofdthread en fungeert als geheugenallocator voor het programma. De mmt werkt samen met twee bestaande geheugenallocators: de malloc-versie van Doug Lea en PHKmalloc. Bij gebruik van PHKmalloc kunnen de veiligheidsfeatures daarvan bovendien zonder prestatieverlies worden uitgevoerd, terwijl dat zonder aparte geheugenmanagementthread in een prestatiedip van 21 procent zou resulteren.

Reacties (81)

[.oisyn]

Het lijkt me stug dat juist malloc() geparallelliseerd wordt. Je kunt elke functie wel verhuizen naar een andere thread, maar zolang de aanroepende thread een antwoord nodig heeft loopt er niets parallel. Alleen een aanroep zoals free() is fire-and-forget. In dat geval kan de geheugenmanagementthread in z'n eigen tijd geheugenblokken mergen e.d., terwijl de hoofdthread gewoon doorgaat met z'n werk.

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.
[.edit: het paper suggereert idd precies dit :)]

[Reactie gewijzigd door .oisyn op 26 juli 2024 08:24]

[Roland684]

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.

[.oisyn]

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.

Het punt is dat het nou eenmaal niet zo werkt zonder de code aan te passen, maar dat is wel wat de onderzoekers hier lijken te suggereren - je hoeft alleen maar te linken met een andere library. Geen enkele compiler kan aan een malloc() call zijn dat hij asynchroon is en dat hij nog wat werk kan doen voordat het resultaat van die functie gewenst is. Geen enkele compiler zal bij een stuk code van

void * ptr = malloc(size);
doSomething();
doSomethingElse(ptr);

doSomething() aanroepen vóór de malloc() als doSomething merkbare side-effects heeft. En dus heeft het verhuizen van de interne werking van malloc() naar een andere thread geen enkel nut, de hoofdthread kan niet verder voordat malloc() een resultaat heeft teruggegeven. Pas als je als programmeur rekening houdt met het feit dat een opdracht asynchroon is dan kun je hier ook daadwerkelijk gebruik van maken. Bijvoorbeeld:

handle h = startmalloc(size);
doSomething();
void * ptr = endmalloc(h);
doSomethingElse(ptr);

Maar daar is dus een aanpassing van de broncode voor nodig, en dat is voor de library in dit artikel niet het geval.

[Reactie gewijzigd door .oisyn op 26 juli 2024 08:24]

[Carbon]

Het punt is dat het nou eenmaal niet zo werkt zonder de code aan te passen

Helemaal juist, echter 'free' kun je met deze opzet wel nonblocking laten uitvoeren, maar of dat zoveel effect heeft?

[Reactie gewijzigd door Carbon op 26 juli 2024 08:24]

[Fiander]

Geen idee, maar wat als er veel free's achter elkaar zijn.
De MMT zou dan net als in java en .Net een defrag van je geheugen kunnen doen.
Voor zover ik weet gebeurt dat momenteel tijdens de malloc op het moment dat je een block geheugen nodig hebt wat groter is dan het grootste vrije block.

tevens zou de malloc waneer er voor bv een array 10 x 200 bytes gealloceert moet worden, deze op de achtergrond kunnen omzetten naar 1 x 2000 bytes continu geheugen. enz enz enz

[.oisyn]

De MMT zou dan net als in java en .Net een defrag van je geheugen kunnen doen.

Nee, dat kan dus niet. In tegenstelling tot VM's als Java en .Net is er in native applicaties geen boekhouding van wat alle data in het geheugen precies voorstelt. Als je defragmenteert zul je pointers die naar een verplaatst stuk geheugen wijzen moeten updaten, wat niet kan omdat je niet weet waar die pointers staan.

[Fiander]

En als ie ipv een pointer, een pointer naar een pointer aangeboden krijgt?
Dan zou de MMT het beheer in handen krijgen.

of werkt dat niet ???

( ben zelf meer thuis in .Net )

[!null]

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.

[RayNbow]

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.

[Finwe]

@vgTto: als ik het goed begrepen heb moet je je software gewoon linken met een library van hun, die malloc() / free() opnieuw implementeert.

Ik snap het toch niet helemaal; het alloceren van geheugen is normaal gesproken toch een blocking operatie, dat wil zeggen, je kan niet returnen voordat het geheugen ook echt is gealloceerd. Dus het is niet alsof de thread die om geheugen vraagt ondertussen wat anders kan gaan doen.

Hooguit bij het releasen van geheugen zie ik het nut wel, dat zou je best asynchroon kunnen doen. Misschien komt daar dan ook de grootste winst vandaan...

[Edit] Inmiddels hier de paper gelezen, het lijkt erop dat ze inderdaad dingen pre-allocaten, en de free()'s batch-processen. Maar hun zogenaamde MMT-thread loopt wel 100% CPU-tijd (op een enkele core) te slurpen omdat de lock-wakeups te traag zijn...ik betwijfel of dit wel echt zo nuttig is...

[Reactie gewijzigd door Finwe op 26 juli 2024 08:24]

[DrClaw]

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.

[Polbeer91]

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.

Als je een quad-core hebt, kan één (off mss 2 dan) van de kernen prima in z'n eentje het OS, anti-virus, etc. draaien. Als je dan een singlethreaded app hebt, zij ofwel 3 kernen een heel klein beetje bezig, ofwel één kern wat harder met alle achtergrondtaken, en 2 helemaal niet. Als je dus 2 kernen aan de main-app laat werken, en 2 aan de achtergrondtaken, heb je er dus geen last van dat je een kern minder hebt voor die achtergrondtaken.

[robvanwijk]

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

Ze gebruiken gewoon standaard versies hoor. Ik kan me niet voorstellen dat die "crappy" zijn.

quote: Pagina 2

we use both memory allocation library implemented
in GNU C and PHKmalloc

Los daarvan, ze vergelijken de library "met zichzelf" (met en zonder hun MMT), dus of ze nou crap zijn of niet maakt niet uit. Óf je hebt er met en zonder MMT evenveel last van, óf ze hebben iets bedacht om een crappy library goede performance te geven. Beide zijn leuk.

[Remus]

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.

[robvanwijk]

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.

[gamepower2005]

Programma's kunnen op verschillende manieren automatisch parallel gemaakt worden. De meeste (of alle) van deze methoden zijn fine-grained; de veranderingen die gemaakt worden zijn op een heel laag niveau. Het nadeel van werk verdelen op een laag niveau is dat er vaker gesynchroniseerd moet worden en het dus meestal minder efficient is dan coarse-grained. Vergelijk het met een hulp die je aan het werk kunt zetten met "maak een maaltijd" (coarse-grained) of "doe twee liter water in de pan, enz." (fine-grained), waarbij het coarse-grained aansturen van iemand natuurlijk veel efficiënter is.

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. De meeste problemen (en dus applicaties) kunnen echter op een hoog niveau opgesplitst worden, waarmee meer snelheidswinst te behalen valt. Als voorbeeld voor een single-threaded applicatie wordt een browser genoemd. In de praktijk wordt ieder tabblad in een webbrowser vaak in een aparte thread gedraaid, waardoor het werk goed te verdelen is over een quadcore (mocht dat nodig zijn).

Kortom: zeer interessante theorie, maar het werk van de programmeur is nog niet overbodig gemaakt.

[Reactie gewijzigd door gamepower2005 op 26 juli 2024 08:24]

[analog_]

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).

[awulms]

UML is niet geschikt om de details in te steken die het verschil maken tussen een interface specificatie en de daadwerkelijke implementatie. UML is dan ook een ontwerp taal (Modelling Language) en geen implementatie taal.

Het overbodig worden van programmeurs wordt al voorspeld sinds de eerste CASE tools uit de jaren 80 van de vorige eeuw, maar de praktijk blijkt toch iets hardnekkiger te zijn.

[MSalters]

Sterker nog, de opkomst van multi-core processoren leidt juist een grote beweging terug. Nee, assembly hoeven we niet meer te genereren, dat doen compilers voor ons. Maar taken aan threads assignen kan nog lang niet zo automatisch.

[analog_]

Ik ging ook over UML end dergelijke concepten:
Dus eigenlijk komt het erop neer dat we gewoon nog geen modeleer taal hebben voor concrete logic en dat de compilers nog niet slim genoeg zijn maw is het een kwestie van tijd. Het is technisch haalbaar en er zijn duidelijke voordelen dus ik zie niet in waarom we er niet naar toe gaan evolueren.

edit: Software Architectuur is ook een relatief nieuwe wetenschap waarin nog vollop ontwikkelingen worden gemaakt en zullen worden. Het feit dat we momenteel programmeren in talen die kwa ontwerp minstens 40 jaar oud zijn (functioneel, object georienteerd) geeft mij meer dan genoeg vertrouwen dat we er wel gaan komen.

[Reactie gewijzigd door analog_ op 26 juli 2024 08:24]

[gamepower2005]

Waar je op doelt is niet UML, maar MDD (Model-Driven Design). Hierbij maak je UML schema's die door de ontwikkelomgeving omgezet worden naar een applicatie. Je moet dan meestal nog steeds redelijk wat code zelf typen, maar de trend zal zijn dat software ontwerpers op een hoger niveau zullen gaan werken. Er is volgens mij dan ook geen enkele opleiding (op HBO niveau) die "programmeurs" opleidt; ze noemen die mensen software engineers omdat ze meer doen dan code typen.

[teacup]

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 26 juli 2024 08:24]

[gamepower2005]

In het midden van je post beschrijf je een applicatie die andere programma's versnelt (maar het OS niet langzamer maakt). Dat is helaas iets te mooi om waar te zijn. Ver van de waarheid zit je echter niet; Windows kopieert veelgebruikte applicaties automatisch naar het geheugen, zodat ze sneller opstarten wanneer je ze nodig hebt.

Parallel programmeren (zo wordt dat genoemd) is niet moeilijk in een simpele situatie. Het probleem is dat de meeste applicaties niet simpel in elkaar zitten en om in een ingewikkelde applicatie een drastische verandering te maken kost veel tijd en geld.

Toch loopt de software wereld niet zo achter op de hardware wereld als je lijkt te denken. De populairste programma's die baat zouden hebben bij het gebruik van meerdere cores zijn daarvoor geschikt gemaakt (Photoshop, WinRAR, games, etc.). Het heeft weinig zin om Notepad parallel te laten werken, omdat dat zo simpel werk nooit een core vol zal belasten. Ook hoef je als software bedrijf veel klanten niet te overtuigen van het nut van parallel programmeren, je hoeft ze alleen te overtuigen dat het programma te langzaam werkt en dat het sneller gemaakt moet en kan worden. Hoe je dat precies doet maakt die klanten niet uit; bij hun gaat het puur om het resultaat (je hebt natuurlijk wat meer technische klanten die ook de andere kant van het verhaal willen horen).

Je zegt dat je de cores vol belast wil zien. Maar is dat wel nodig? Met de huidige quadcore processors is er simpelweg veel te veel rekenkracht aanwezig voor alledaagse taken. Twee oplossingen zijn mogelijk:

• Laat de processor het werk van je buurman doen, die bijv. met Photoshop bezig is; je verhuurt de rekenkracht die je over hebt.
• Laat de processor langzamer werken en bespaar energie (wordt vooral in laptops toegepast).

Kortom: het parallel maken van software gaat best goed. Dit soort research draagt misschien bij, maar zal geen drijvende factor zijn bij parallel programmeren.

[Reactie gewijzigd door gamepower2005 op 26 juli 2024 08:24]

[robvanwijk]

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.

[BugBoy]

Leuk bedacht, maar eigenlijk niets nieuws. Talen als C# en Java gebruiken garbage collection en daarbij haal je geheugen van een lineaire heap. Geheugen aanvragen gaat dus zeer snel. Het vrijgeven wordt overgelaten aan de garbage collector die op een aparte thread draait.

Als het systeem even rust heeft, dan wordt al het geheugen weer netjes achter elkaar geplaatst, zodat de vrije ruimtes opgevuld worden. Dit gaat geheugenfragmentatie tegen en dat is belangrijk bij applicaties die langdurig draaien en veel kleine blokken geheugen aanvragen en ook weer vrijgeven. Als er geen maatregelen genomen worden, dan kan het voorkomen dat er per geheugenblok (4KB) slechts en paar bytes echt gebruikt worden. Dit is inefficient voor caching en fysiek geheugengebruik. Een goede garbage collector gaat dit tegen.

Huidige malloc/free implementaties gebruiken behoorlijk complexe algoritmes om goed te werken in multi-threaded scenarios en geheugenfragmentatie zoveel mogelijk tegen te gaan. Dat bouw je niet zomaar even om, dus ik denk dat die 20% winst in heel specifieke scenarios zal zijn. Desondanks leuk bedacht, maar praktisch niet echt bruikbaar lijkt me.

[Lord Anubis]

Mijn idee, ik denk ook die richting. Er word er een flinke ruimte gereserveerd en klaar gemaakt ( in een tweede thread/core ) en pas op moment dat een stukje nodig is wordt deze aangereikt.
Het vrijgeven kan gebeuren in een/de thread in een andere core, zo gauw de pointer null is bv.

Ook Obj-C's Cocoa garbage collector is multithreaded en zal uitgevoerd worden wanneer er tijd is.

Ik denk dat hun methode uiteindelijk pas intersant is als alle apps single threaded zijn en er twee core's zijn. Uiteindelijk kost het ook weer beschikbare cpu omdat je de tweede core weer extra belast/reserveert. Ik maak me een beetje zorgen om VM, worden deze blokken dan in zijn geheel bewaard of is er ook intelligentie gebruit in de vm code?

[cdwave]

En klassieke talen (C, C++, Pascal) gebruiken de verouderde library waar de onderzoekers hun 20% op baseren ook allang niet meer.

Een malloc in C onder Windows alloceert van een heap die alleen in de huidige thread wordt gebruikt. Daardoor is er geen mutex nodig, en is malloc snel en blokkeert vrijwel niet, behalve als de heap te klein wordt en aan het OS om meer heap geheugen moet worden gevraagd.

Een C++ compiler kan in principe kleine mallocs ook op de stack doen, zoals:

m = malloc(4)
// use m
free(m)

"m" kan hier door de compiler gewoon naar4 bytes op de stack worden gezet, dan kunnen de malloc en free calls achterwege worden gelaten.

[Gamebuster]

Bestaat het geheugen ook al uit blokken? Wist ik niet eens

[BugBoy]

Bij het gebruik van virtueel geheugen wordt er gewerkt met pagina's. Meestal is zo'n page rond de 4KB groot. Virtueel geheugen wordt dan altijd per blok van 4KB uit het fysieke geheugen gehaald. Een pagina is een soort atomair iets voor de memory manager. Het kan niet zijn dat slechts een deel van de pagina in memory staat. Daarom is het van belang om de pagina's die in het geheugen staan goed gevuld te houden.

[Basbarbrbarbr]

Dus als ik het goed begrijp moeten deze aanpassingen worden toegebracht aan de individuele software of moet het os worden aangepast?

Overgens goede zaak, af en toe wel frustrerend als iets traag loopt op 1 core terwijl 3cores aan het idle'en zijn

[Reactie gewijzigd door Basbarbrbarbr op 26 juli 2024 08:24]

[Ram-G-maN]

Overgens goede zaak, af en toe wel frustrerend als iets traag loopt op 1 core terwijl 3 cores aan het idle'en zijn

Daarom hoop ik stiekem dat dit systeem ook te toepassen is op een PlayStation 3 waarop Linux Yellowdog runt. Nu laat hij 6 cores ongemoeid, heel frustrerend dus.

[Scorpei]

Dat is onder andere, volgens mij teminste, omdat je die cores op dit moment niet MAG gebruiken. Dat kan veranderen, ofja, dan mag het nog steeds niet natuurlijk maar kun je er misschien omheen als men door de hypervisor heen kan (afaik).

[Verwijderd]

Deze stelling is incorrect, je hebt toegang tot 6 van de 7 SPE's zoals die genoemd zijn.
Volgens wikipedia : "Only six of the seven SPEs are accessible to developers as one is reserved by the OS.".

De link : http://en.wikipedia.org/wiki/Cell_(microprocessor)

Er zitten 8 SPEs op de CPU waarvan er 7 beschikbaar zijn om de yield te verhogen.

[Verwijderd]

Voor linux is er maar 1 beschikbaar en dat bedoelt GT-R

[SuperDre]

Nope, voor linux zijn alle 6 van de 7 SPE's gewoon beschikbaar.. Alleen de meeste software is daar niet voor geoptimaliseerd inclusief YDL zelf, en met het verwijderen van OtherOS zal daar ook geen vooruitgang meer in komen..

[MrSnowflake]

Zo ver ik mij kan herinneren kan(/kon) Linux idd 6SPE's gebruiken. Maar deze SPE's zijn niet bepaald geschikt om te gebruiken als GP (General Purpose) PU.

[Tigran]

Maak je niet druk, Sony wil de eigen OS toch in een patch disablen

http://tweakers.net/nieuw...d-na-firmware-update.html

[Melvinvm]

Dat was toch een 1 april grap?

"Het oude 'fat' PlayStation 3-model verliest de mogelijkheid om Linux te draaien als de gebruiker de voor 1 april aangekondigde 3.21 firmware-update installeert. Sony zegt uit 'veiligheidsoverwegingen' tot deze stap te zijn gekomen. "

edit: gemene sony maakte geen grap

[Reactie gewijzigd door Melvinvm op 26 juli 2024 08:24]

[fdm391]

Maak je niet druk, Sony wil de eigen OS toch in een patch disablen

http://tweakers.net/nieuw...d-na-firmware-update.html

Als je niet update kun je nog gewoon linux gebruiken hoor...

[Reactie gewijzigd door fdm391 op 26 juli 2024 08:24]

[robvanwijk]

Laatste keer dat ik ermee gespeeld heb kon je zelf aangeven wat op elke SPU moet draaien. Als er zes niks staan te doen is dat dus, no offense, je eigen schuld. Wel draait de kernel op zijn eigen SPU (IIRC), maar goed, het is de bedoeling dat je zelf de andere zes volop bezig houdt, dus die taken over meerdere SPUs verdelen is normaal gesproken toch geen optie.

[SuperDre]

kweet niet waar jij mee gespeeld hebt, maar het is niet de CELL/PS3 in iedergeval, want je kunt helemaal niet aangeven wat waar moet draaien aangezien de SPU helemaal geen general purpose 'core' is.

[Verwijderd]

Toch wel, je kan (of kon eigenlijk aangezien je nu helemaal geen 'Other OS' meer kan draaien) aangeven op welke SPE's je een bepaald stuk code wou laten draaien. Er is namelijk een c functie "spe_create_thread" waarvan het vijfde argument een mask is die aangeeft op welke SPEs je de code uit wilt laten voeren.

Voor meer informatie : http://www.ibm.com/developerworks/library/pa-linuxps3-1/

[Cid Highwind]

De PS3 heeft slechts één core, de rest zijn SPE's die goed zijn in parallelle berekeningen, maar kunnen niet als een core worden gezien. Ze staan als het ware in dienst van die ene core. Het is een compleet andere opzet dan op een PC of zelfs een Xbox 360, waar alle cores gelijkwaardig zijn.

[Herko_ter_Horst]

Helaas is de Other OS functie met de recentste update uit de PS3 verdwenen...

[bartvb]

Gaat alleen om aanpassingen aan de software, kernel staat hier los van, het is vooral een kwestie van linken met een library die de onderzoekers gebouwd hebben. De truc is nu dat de echte malloc en free calls in een losse thread worden gedaan. Hoe ze dat precies willen doen met malloc is mij nog niet helemaal duidelijk, lijkt me dat je toch een geheugenadres terug wilt krijgen als je om een stuk geheugen vraagt.

Edit:
Paper even snel doorgebladerd en het idee is eigenlijk best nice. Het toewijzen en vrijgeven van geheugen kost tijd, wat ze nu vooral gedaan hebben is dat de MMT van te voren probeert te bedenken wat het volgende verzoek gaat worden. Vaak worden er b.v. arrays in het geheugen gezet met b.v. 1000 entries van allemaal 200 bytes. Als de MMT dan ziet dat er 10 van dat soort 200 byte blokken worden aangevraagd kan hij ook alvast beginnen met het reserveren van weer 100 200 byte blokken in die losse thread. Slim

[Reactie gewijzigd door bartvb op 26 juli 2024 08:24]

[humbug]

Tsja, het is maar wat je slim noemt. Je gebruikt een array van 10x200 en het systeem reserveert 110X200 bytes. Geheugen is goedkoop, maar nog niet gratis. Het systeem zal die extra gereserveerde ruimte dus ook weer vrij moeten gaan geven. Om dat te bepalen moet de thread allerlei zaken gaan bijhouden. Resultaat een MMT die redelijk wat geheugen en processorkracht gebruikt. Het is maar de vraag of dit de zaken in werkelijkheid versnelt of juist vertraagd. En helemaal fijn wordt het natuurlijk als je de MMT als server voor meerdere processen gaat gebruiken. Dan wordt het geheugen wat door de MMT beheerd wordt beschikbaar voor al die processen. Iets wat men nu net probeert tegen te gaan.

[bartvb]

De MMT gebruiken voor meerdere processen lijkt me nogal lastig en onnodig.

Het reserveren (en evt vrijgeven) van dat extra geheugen kost inderdaad tijd maar netto levert dit 20% snelheidswinst op. Het is zeker geen ideale oplossing aangezien die winst verdampt op het moment dat je wel alle cores echt in gebruik hebt maar het is een erg eenvoudige manier om situaties die in de praktijk voorkomen te verbeteren. Vanzelfsprekend is het beter als de applicatie zelf multi-threaded is maar dat is nu eenmaal niet zo eenvoudig. Dit is een aardige methode om toch gebruik te maken van de tig (vaak idle) cores op moderne processoren.

[daft_dutch]

Dus als ik het goed begrijp moeten deze aanpassingen worden toegebracht aan de individuele software of moet het os worden aangepast?

Het is een techniek om single threaded source code te compileren met een sub mmt thread (magic ). Een assistent van je normale App thread En door die Magic weet die assistent precies waar je APP mee bezig. wat veel tijd schilt.

Je source moet wel een supported malloc gebruiken maar het eventuele aanpassen van je code is zeer beperkt omdat je proces en data structuren ongewijzigd blijven. Dit zou moeten werken op elk serieus OS.

[Reactie gewijzigd door daft_dutch op 26 juli 2024 08:24]

[HerrPino]

Ik zou zeggen, kom maar met die nieuwe Linux kernel waarbij dit ingebakken zit ... hierbij neem ik voor het gemak even aan dat je de kernel hierop moet aanpassen. Goede ontwikkeling, door dit soort ontwikkelingen kunnen oudere pc's weer wat langer mee.

[Reactie gewijzigd door HerrPino op 26 juli 2024 08:24]

[Vorlon]

Dat gaat niet. Het werkt door een code bibliotheek die nu single threaded werkt te vervangen door een multi-threaded versie. En dat gaat dus alleen als je het programma recompiled.

[Squee]

Lijkt me niet. Als je ook bijv. Valgrind aan je binary kan hangen die malloc door zijn eigen versie vervangt zonder hercompilatie. (zodat je op memoryleaks etc kan checken) Volgens mij wordt malloc (op Linux dan) gewoon dynamisch uit je Libc geladen.

[analog_]

Heb niet de paper gelezen maar bedoel je dat in het programma zelf er extra functies worden gegeven die dit nieuwe geheugen beheer aansturen of is het voor een executable exact hetzelfde als vroeger. Want dan zie ik niet echt het probleem in om je libc zoals hierboven (op dat ene probleempje na) te recompilen. Ik mag toch aannemen dat de meeste linux software geen static linked libraries gebruikt ?

[Reactie gewijzigd door analog_ op 26 juli 2024 08:24]

[MSalters]

Een biblioteek (library) kun je vervangen met een relink; daarvoor is geen recompile nodig. Moderne OSen gebruiken vaak dynamische libraries (DLL/.so), die pas bij gebruik van het programma worden gelinkt. Dus nee, een recompile is niet nodig, en de relink deed je waarschijnlijk toch al elke keer.

[leuk_he]

niet de kernel, maar libc he? En libc wil je niet veranderen, want dan zie je opeens dat applicaties niet goed meer werken. (in 90% zal deze lib de boel versnellen, in 1% zul je een dramitsch tegengesteld effect zien)

als ik naar dl memory kijk dan gaat dit vooral over het weer bij elkaar schuiven (coalesking) van vrij geheugen, en pre-split, al wat chunks klaarzetten van een bepaalde bin-size.

[MSalters]

90% versnellen, 1% vertragen? Niet echt, eerder andersom.

Die extra thread draait weliswaar op een core die idle is, en dus "gratis". Maar wat er hierbij niet gezegd wordt is wat de consequentie is voor het geheugen en de cache. Dat zijn namelijk resources die gedeeld worden door cores. Deze _memory_ allocator maakt uiteraard nogal veel gebruik van geheugen, dat is nou eenmaal normaal voor die dingen. Maar al dat memorygebruik kost bandbreedte, bandbreedte die niet voor je echte programma beschikbaar is.

Een ander probleem is dat de geheugenallocaties van deze memory allocator in eerste instantie in de L1 cache van de destbetreffende core komen. Dat is dus niet de L1 core waar je programma gebruik van maakt. Ook dat vertraagt de zaak.

En de winst voor een browser? Daar heb je nou net een voorbeeld van een applicatie die best meerdere threads kan gebruiken. Een simpele pagina is snel genoeg, en een ingewikkelde pagina bestaat uit een groot aantal delen (tekst, plaatjes, code) die afzonderlijk geladen en gerenderd kunnen worden. En met modernetabbed browsers kun je dat allemaal nog eens parallel per tab doen.

[Verwijderd]

Beetje ongelukkig om browsers als voorbeeld te nemen kort nadat Microsoft met IE9 is gekomen die wel multithreaded pagina's rendert.

[erikdenv]

Gelukkig hoeft niet iedereen Windows te gebruiken en is binnen Windows IE niet de enige browser. Het is ook maar een voorbeeld. Ik weet dat je een MS-freak bent maar de wereld draait niet om MS (gelukkig).

[Cyberwizzard]

Dan nog zit meer dan 20% van de performance in memory management alleen zit het nu over meerdere threads uitgesmeerd. Door de MMT te delen met alle threads zou je misschien alsnog de 20% speedup kunnen krijgen (of juist weer een afhankelijkheid tussen alle threads indien niet goed uitgedacht).

[MSalters]

Deze oplossing "werkt" omdat ze 20% van het werk verplaatsen naar een idle core, die daarna op 100% draait. Maar IE9 zal zelden idle cores hebben, en dan is 20% van het werk opblazen naar 100% absoluut geen winst meer.

Erger nog, wat je bovendien introduceert is een centrale bottleneck: als er twee threads tegelijk geheugen nodig hebben (gangbaar, 't is tenslotte niet voor niets 20% van het werk) dan moet de tweede wachten totdat de eerste van de MMT z'n geheugen heeft gekregen. Niet handig.

[Thunderhawk]

Aan de individuele software. Echter stellen de makers dat er geen verandering in code nodig is. Het enigste dat dus nodig is is dat de maker van een willekeurig (single-threaded) programma de libs van onder andere dus de malloc functies vervangt door de libs van deze jongens. Dus een recompile van een programma zal nodig zijn voordat het programma deze nieuwe techniek kan gebruiken.

[Reactie gewijzigd door Thunderhawk op 26 juli 2024 08:24]

[Madrox]

Van een tekstverwerken weet ik het niet, maar de snelheid van de browser vind ik
helemaal goed. Zie dan ook amper het nut van een 20% snellere browser, ik bedoel; de pagina's vliegen me nu al om de oren.

[Cyberwizzard]

Ik vind de beschrijving twijfelachtig aangezien een single threaded programma nog steeds grotendeels single treaded blijft.

Ik kan me voorstellen dat het offloaden van het geheugen management van een programma naar een losse thread een versnelling kan geven, mits de overhead van de losse thread zelf maar klein genoeg is. Ik bedoel dan dat het synchroniseren van taken over meerdere cores resources kost dus indien je memory management niet erg intensief is, zou dit eerder negatief werken.

Tot slot dacht ik hetzelfde als sommige andere mensen in het commentaar hierboven: als je een call voor geheugen allocatie doet, moet deze per definitie blokkeren totdat het geheugen gealloceerd is. Dit betekent dat de malloc zelf niet sneller zal zijn, eerder langzamer dan single threaded (omdat tussen 2 losse threads er een uitwisseling moet zijn ipv dat je een stuk geheugen aan wijst en zegt: 'mine'). Het alternatief is om preventief geheugen te alloceren zodat een malloc naar de MMT toe direct kan worden afgehandeld, dit kost echter wel weer meer geheugen.

Misschien dat deze techniek als aparte call geimplementeerd kan worden: 'dmalloc' voor distributed memory allocation en 'malloc' voor de kleine dingen... Overigens is het wel leuk om te zien dat dus meer dan 20% van de performance van je browser puur in geheugen management zit.