Apple maakt broncode Grand Central Dispatch openbaar

Apple heeft de broncode van zijn multithreading-technologie Grand Central Dispatch beschikbaar gesteld onder de Apache 2.0-licentie. De technologie is onderdeel van Apples nieuwe besturingssysteem Snow Leopard.

Met de Grand Central Dispatch is het volgens Apple voor ontwikkelaars eenvoudiger om optimaal gebruik te maken van de aanwezige processors. Threads van software met GCD-ondersteuning worden door het besturingssysteem aan de hand van de workload automatisch verdeeld over de cpu's in een systeem. Om GCD door een zo breed mogelijk ontwikkelaarsgilde geaccepteerd te krijgen, heeft Apple besloten de broncode ervan vrij te geven onder de Apache 2.0-licentie. Met behulp van de broncode kan de technologie ook geschikt worden gemaakt voor onder meer Linux.

De broncode van de GCD-software is ondergebracht bij het 'libdispatch'-project, terwijl de kernelondersteuning voor GCD te vinden is in het 'xnu'-project. Xnu is niet direct noodzakelijk voor gebruik op andere platformen, maar voegt optimalisaties toe voor Mac OS X. Voor elk afzonderlijk platform zal voor de GCD-functionaliteit nieuwe kernelondersteuning geschreven moeten worden. Om de volledige GCD-api te ondersteunen moet de C-compiler zogeheten blocks-ondersteuning bieden. De runtime daarvan is verkrijgbaar als onderdeel van het LLVM-project. Ook de blocks-extensie voor C is een technologie van Apple.

Eerdere pogingen van Apple om onafhankelijke ontwikkelaars warm te maken voor zijn softwaretechnologie, zijn met gemengd enthousiasme ontvangen. Zo werden zijn codedonaties voor de Webkit-browserengine met open armen door de ontwikkelaarcommunity ontvangen, maar is bijvoorbeeld 'launchd', een beheertool voor het starten en het stoppen van daemons, programma's en scripts, nooit buiten het Mac-platform in gebruik genomen.

Reacties (40)

[Zpottr]

Dit is wel een slimme zet; toepasbaarheid zal voornamelijk in andere UNIXen en UNIX-achtigen liggen waar geen significante concurrenten op de desktop bijzitten. Als zo de code beter wordt en ontwikkelaars er beter mee om leren gaan zal dat OS X flink te goede komen.

[Reactie gewijzigd door Zpottr op 24 juli 2024 11:49]

[Gerco]

Juist op de desktop is nog veel te winnen voor multicore programmeren. Een instapsysteem heeft tegenwoordig al 2 cores en dat zullen er alleen maar meer worden. Er is niets aan GCD wat specifiek voor serversystemen is en gebruik op de desktop lijkt me dan ook voor de hand liggend.

Op een server is het niet altijd erg wanneer iets een seconde reaktietijd heeft omdat er andere dingen aan de gang zijn. Juist op de desktop is het belangrijk om je werkzaamheden goed te verdelen om zo snel mogelijk de user weer van dienst te kunnen zijn.

Ik duft te beweren dat multithreading en multicore op de desktop minstend net zo belangrijk is als op servers. Er is overigens ook niets specifiek unix of apple aan GCD. Op Windows kan deze techniek net zo goed werken.

[Reactie gewijzigd door Gerco op 24 juli 2024 11:49]

[kiang]

Op een server is het niet altijd erg wanneer iets een seconde reaktietijd heeft omdat er andere dingen aan de gang zijn. Juist op de desktop is het belangrijk om je werkzaamheden goed te verdelen om zo snel mogelijk de user weer van dienst te kunnen zijn.

Ik duft te beweren dat multithreading en multicore op de desktop minstend net zo belangrijk is als op servers. Er is overigens ook niets specifiek unix of apple aan GCD. Op Windows kan deze techniek net zo goed werken.

Ook op servers heeft GCD een nut hoor: GCDis ontwikkeld om het JUISTE aantal threads aan te maken: dus niet te weinig, maar vooral niet TE VEEL!

Met GCD maak je voor concurrente bewerkingen namelijk queues ipv threads: opdrachten uit die queues worden dan door GCD aan threads toegewezen, afhankelijk van hoeveel cores er beschikbaar zijn en hoe hard welke bezig is: elk appart programma krijgt minstens 1 thread, en maximaal 1 thread voor elk van zijn queues.

Dit is nuttig omdat het neit echt immens moeilijk is met meerdere threads te werken, het moeilijkste is kiezen HOEVEEL threads je gaat gebruiken: heeft de gebruiker een dual of Q-core, HT of niet, en mag jouw app het hele systeem belasten of meot er ruimte zijn voor andere apps? Dit bepaalt allemaal het aantal threads dat je wilt. Er zijn 2 keuzes die vaak worden gemaakt: zoveel mogelijk threads maken of slecht 1 thread maken, en geen van beide is goed.
1 thread is slecht omdat je dan maar 1 core kunt gebruiken, een immens aantal threads creëert dan weer immens veel overhead.
Een ander aantal threads lijkt dan weer miss goed voor nu, maar wat wanneer er een upgrade bij je doelpubliek is, en ze plots 8 cores hebben?

Met GCD maak je gewoon zoveel queues als je wilt, en GCD bepaalt dan at runtime over hoeveel threads dit mag lopen, adhv de beschikbare resources: zo wordt alles mooi verspreid en de overhead word geminimaliseerd.

Dit is dus wel nuttig voor zowel servers als desktops, aangezien beide vaak meer of minder threads hebben lopen dat goed is.

Een uitgebreide bespreking van GCD vind je op Ars Technica

[Reactie gewijzigd door kiang op 24 juli 2024 11:49]

[Verwijderd]

Aantal threads het moeilijkst, eerste keer dat ik dat hoor. Heb je al eens een multi threaded programma gemaakt van enige omvang? Hoe je een programma opsplitst/parallelliseert is de grote vraag, het aantal threads dat daaruit voort vloeien zijn meestal een gevolg. Als het maar een kwestie van aantal was, denk je niet dat quasi alle programma's op z'n minst al meer dan 1 thread gebruikten?

Thread pooling is stok oud en relatief eenvoudig in vergelijking met andere problemen die bij threading komen kijken, het voordeel van GDC is dat het een centrale thread pool is ipv een pool per applicatie. Het zal meer invloed hebben op run-time dan op dev-time. Maw, GDC gaat er niet voor zorgen dat alle applicaties plots multi threaded zullen worden, maar dat bepaalde multi threaded applicaties er misschien wel beter mee omspringen.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 11:49]

[kiang]

de meeste apps gebruiken ook meer dan 1 thread hoor. In Windows weet ik eht niet maar in OSX kun je dat gewoon in je activitymonitor zien.
Zoals je al op mijn systeem kunt zien gebruikt bijna alles al meerdere threads. Firefox is zelfs al gigantisch goed opgesplitst. Jammer genoeg maakt deze theoretisch erg goede aanpak de overhead erg grtoo, wat voor een groot deel opgelost zou worden met GCD.

[Zpottr]

Juist op de desktop is nog veel te winnen voor multicore programmeren. Een instapsysteem heeft tegenwoordig al 2 cores en dat zullen er alleen maar meer worden. Er is niets aan GCD wat specifiek voor serversystemen is en gebruik op de desktop lijkt me dan ook voor de hand liggend.

Misschien zet ik het niet duidelijk genoeg neer, maar ik doel ook op performancewinst op de desktop. Ik denk alleen dat de fabrikanten die deze code min of meer direct kunnen grbuiken, geen belangrijke concurrenten van Apple in hun grootste markt (desktops) zijn.

Er is overigens ook niets specifiek unix of apple aan GCD. Op Windows kan deze techniek net zo goed werken.

De techniek wel, maar de nu geopede code hergebruiken in Windows lijkt me een heel ander verhaal

[Verwijderd]

Ik zou zelfs zover willen gaan dat het gebruik van GDC op de desktop belangrijker is dan op een server. Op een desktop is het belangrijk dat een enkel programma alle cores weet te benutten. Dit is bij een hoop desktop applicaties niet het geval. Op servers gebeurd er echter al veel tegelijk verdeeld over hoge aantallen threads dus voor deze is GCD lang zo belangrijk niet al kan GCD de efficientie wel verhogen.

[vgroenewold]

Of het wel of niet in gebruik is genomen, is niet meteen het grote probleem denk ik. Het feit dat men zoveel opensource maakt, is op zich al een pre. Het geeft in ieder geval aan dat Apple, al langer, opensource een vrij goede ondersteuning kan bieden. Naar mate dat men dat dan meer en meer gaat doen, volgen ontwikkelaars vanzelf... denk ik dan. GCD is in ieder geval een hele goede stap voor OSX en idd bijv. Linux, die systemen maken dan eindelijk eens echt goed gebruik van multi-cores.

[Reactie gewijzigd door vgroenewold op 24 juli 2024 11:49]

[RM-rf]

enkel het 'vrijgeven' van een sourcecode betekent nog niet dat het bedrijf absoluut zo positief voor de opensource-gemenschap werkt:
De Apache-licentie biedt ook bv de mogelijkheid aan Apple om hun zelf intern ontwikkelde source redelijk gesloten te houden en de vrijgegeven source hooguit als 'eenrichtingsverkeer' te benutten om daarop gepubliceerde verdere innoaties ook zelf makkelijk en snel te kunnen toepassen, maar toch als intern en comemrcieel product een beter uitgewerkte versie te gebruiken...

helaas is dat deels ook het gedrag dat Apple nog wel eens heeft vertoond omtrend Khtml/Webkit ... alhoewel ze wel er goed gebruik van maken voor hun eigen producten, kwam ook regelmatig de klacht dat Apple daarvoor ook weinig 'teruggaf' aan de gemeenschap...
Overigens heeft Apple op dat punt na veelvuldig geuitte kritiek wel enige verbetering getoond.

[Gustaaf437]

Apple gaf in het begin alleen WebCore vrij. Zeg maar het HTML plak gedeelte van WebKit. Alle andere onderdelen bleven gesloten en Apple's ontwikkelaars voegden niet veel toe. WebKit is echter al een aantal jaren volledig opensource met volle ondersteuning van Apple. Enkele dingen worden vaak wel eerst intern ontwikkeld, maar uiteindelijk komt alles naar buiten.

[Verwijderd]

webkit is juist uitermate succesvol het wordt door google gebruikt in chrome en android, palm pre en ook nokia symbian gebruiken het in hun mobiele platform.

edit@nekokoneko

ja maar als webkit door anderen gebruikt wordt dan is dat de community toch, ik weet dan niet over welke community jij en rm-rf het hebben. en webkit is juist de verbetering van khtml die dan ook door apple gedoneerd is?

[Reactie gewijzigd door Verwijderd op 24 juli 2024 11:49]

[Neko Koneko]

Dat is het punt niet dat RM-rf maakt, het gaat erom dat Apple alle input vanuit de OS community gebruikt maar zelf niet genoeg terugdoet voor diezelfde community. Dus als de OS community iets verbetert verwerkt Apple dat in zijn eigen producten, maar als Apple iets verbetert houden ze het lekker voor zichzelf.

[Verwijderd]

Apple niet genoeg terugdoet voor de OS community? Valt wel mee, grote delen van OS X zijn opensource, en ze hebben programmeurs in dienst die dedicated aan opensource-projecten werken.

Zie ook http://opensource.apple.com waar je sourcecode vindt van grote stukken uit OS X, inclusief Snow Leopard. Wat had je graag meer van ze willen zien?

[Reactie gewijzigd door Verwijderd op 24 juli 2024 11:49]

[Maurits van Baerle]

Webkit valt deels onder LGPL en deels onder de BSD licentie en wordt ontwikkeld in een publiek toegankelijke CVS. Hoe kun je daar in vredesnaam iets voor jezelf houden? Elke verbetering van Apple is binnen enkele seconden openbaar...

Hetzelfde geldt bijvoorbeeld voor CUPS, het printsysteem dat vrijwel elk UNIX of Linux gebaseerd OS gebruikt. Draait gewoon in een open CVS en is gelicenseerd onder LGPL.

[Reactie gewijzigd door Maurits van Baerle op 24 juli 2024 11:49]

[gertvdijk]

Webkit valt deels onder LGPL en deels onder de BSD licentie en wordt ontwikkeld in een publiek toegankelijke CVS. Hoe kun je daar in vredesnaam iets voor jezelf houden? Elke verbetering van Apple is binnen enkele seconden openbaar...

Hetzelfde geldt bijvoorbeeld voor CUPS, het printsysteem dat vrijwel elk UNIX of Linux gebaseerd OS gebruikt. Draait gewoon in een open CVS en is gelicenseerd onder LGPL.

LGPL en BSD licenties zijn niet te vergelijken met de Apache License. Wanneer bedrijven zonder verplichtingen naar de community toe gebruik kunnen maken van de software in hun closed-source producten is de gedeelde innovatie er snel af. Bedrijven zijn nou eenmaal vaak met oogkleppen en tunnelvisie aan het focussen op een uniek product met de ontwikkelingen geheim voor de concurrenten...

[cariolive23]

Wanneer bedrijven zonder verplichtingen naar de community toe gebruik kunnen maken van de software in hun closed-source producten is de gedeelde innovatie er snel af.

Ik maak dagelijks gebruik van PostgreSQL (als SQL-ontwikkelaar) wat wordt uitgegeven onder de BSD licentie. Diverse (grote) bedrijven leveren daar hun bijdrages aan en ik heb niet de indruk dat het project PostgreSQL iets tekort komt dankzij deze licentiekeuze. Dat jij van mening bent dat BSD of LGPL geen goede/ideale licentie is, prima, maar ga niet generaliseren. Voor mij en mijn opdrachtgevers werkt het uitstekend.

[gertvdijk]

Ik doelde op de Apache License! Dat lijkt me nogal duidelijk, zeker gezien de overige discussie.

[Borromini]

CUPS werd door Apple opgekocht. Ze zijn volledig eigenaar van de code en kunnen dus elk moment beslissen om de licentie te veranderen (en dus afhankelijke projecten de facto dwingen om te forken). Net zoals de meeste bedrijven heeft Apple een dubbelzinnige relatie met open source. Vergeet niet dat de BSD-licensie een stuk soepeler is dan bv. GPL, en Darwin (de BSD code die in OS X zit) wordt naar het schijnt niet altijd even trouw bijgehouden.

[Keypunchie]

Het is een verstandige zet van ze om dit te open sourcen. Grand Central Dispatch is alleen maar nuttig als software er gebruik van maakt. Op zichzelf is het apple-platform en al helemaal op servergebied een niche markt.

Als het binnen de Linux(server)gemeenschap veel gebruik van gemaakt, betekent dit bijna automatisch dat veel meer tools en software voor Mac OS X platform GCD ondersteunen.

In theorie is Grand Central Dispatch een prachtige ontwikkeling, die veel meer uit multicore platformen kan gaan halen. Maar zonder inzet van developers, die het ook echt gebruiken zal het bij een theoretisch technologiesnufje blijven.

[vgroenewold]

OSX is niet meer zo'n niche markt als vroeger. Het is nog lang niet noemenswaardig, maar zeker al groter dan de Linux-consumentenmarkt, de groei van het aantal gebruikers is ook nog steeds behoorlijk. En via zaken als de iPhone en de app-store, weet Apple ook veel extra developers aan te trekken. Zo ben ik voor de iPhone begonnen te ontwikkelen en weet ik nu meteen ook hoe ik voor OSX moet programmeren, die overstap is bijna nihiel. GCD zal ik dan zeker gaan gebruiken, aangezien het de bedoeling is dat de vanoudsher zeer moeilijke multi-threading, een stuk eenvoudiger is gemaakt.

[Mellow Jack]

En via zaken als de iPhone en de app-store, weet Apple ook veel extra developers aan te trekken.

Niet alleen extra ontwikkelaars maar vooral ook heel veel nieuwe klanten voor Osx

[DCK]

Aangezien Apache 2.0 niet compatible is met de GPL v2 dat Linux gebruikt, dus het kan alleen worden gebruikt in Linux als ze overgaan op GPL v3 (dat wil Torvalds niet) of als Apple het onder een andere licentie uitbrengen. De suggestie dat het in Linux kan worden gebruikt is dus fout.. MSalters heeft gelijk, verkeerd gelezen. In dit geval is dit een vrij veelbelovende technologie, maar ik denk dat succes uitblijft bij gebrek aan het gebruik van LLVM onder Linux.

Het 'blocks-project' (en meer algemeen het hele LLVM-project) is niet van Apple, maar is een door Apple geinitieerd project bij GCC. Het is een manier om C-code te compileren naar een VM-taal zodat er zoals bij Java en .NET runtime optimalisaties kunnen worden uitgevoerd. Het wordt uitgebracht onder een BSD-licentie en is dus door vrijwel iedereen te gebruiken.

De suggestie wordt gewekt dat Grand Central Dispatch ook nuttig is voor Linux, maar heeft iemand informatie of Linux dit niet al doet? Op zich klinkt het alleen als een uitbreiding op de scheduler.

[Reactie gewijzigd door DCK op 24 juli 2024 11:49]

[MSalters]

Ik denk dat je teveel naar Microsoft hebt geluisterd. De GPL is niet zo viral. Zo mag je onder Linux zelfs closed-source applicaties als Oracle DB draaien. De GPL van Linux eindigt bij de kernel APIs cq. headers. Het is dus geen enkel probleem dat "libdispatch" onder de Apache license valt.

Het kerneldeel van GCD moet toch al herschreven worden voor Linux, zoals in het artikel staat. Die nieuwe, Linux-specifieke code hoeft niet Apache-licensed te zijn, juist omdat 'ie herschreven is.

Kortom: noch het userland deel, noch het kernel deel heeft een Apache/GPL incompabiliteit.

[Gerco]

Het is niet alleen een uitbreiding op de scheduler. De scheduler hoeft zelfs helemaal niet veranderd te worden om GCD te kunnen gebruiken. Het kan wel helpen om de scheduler erin te betrekken voor optimalisaties.

Zie GCD als "closures voor C/C++/Obj-C" gecombineerd met een handige manier om die closures aan queues te koppelen. De runtime (die dus niet in de kernel moet zitten) schedulet die queues dan op threads.

Het is dus een andere manier van *applicaties* maken. "linux" kan dit dit dus helemaal niet al doen, op linux draaiende applicaties wel

[Zyphrax]

Tjonge jonge jonge, al dat gekakel hierboven over wie de grootste dispatcher heeft. Of je nou voor of tegen Apple bent, dit is een goed initiatief om een technologie die ingezet is ook te laten gebruiken door steeds meer developers.

Steeds meer bedrijven zetten in op multi-core aangezien de processor clock speed op dit moment niet meer zo praktisch sneller wil, zonder uit je kast te fikken. Het wordt weer eens tijd voor een revolutionair nieuw concept. Er is eigenlijk maar een relatief klein deel qua applicaties dat echt baat heeft bij multi-core.

[Verwijderd]

[q]Er is eigenlijk maar een relatief klein deel qua applicaties dat echt baat heeft bij multi-core.[q/]
Elke applicatie (behalve die onder DOS , rip) heeft baat bij multicore, omdat applicaties nooit alleen daaien. Er draaien altijd talloze processen...

[Gerco]

.NET heeft niets, maar dan ook helemaal niets, met GCD te maken. Zelfs kwa functionaliteit komen ze slechts zijdelings bij elkaar in de buurt (.NET doet, onder heel veel anderen, iets met multithreading en GCD ook).

Deze reaktie slaat dan ook werkelijk helemaal nergens op. Staat hij wel bij het goede artikel?

[Reactie gewijzigd door Gerco op 24 juli 2024 11:49]

[Verwijderd]

GCD is nochthans om dezelfde reden tot leven geroepen als TPL. Ze pakken het zelfs bijna gelijk aan maar wel op een ander platform.

[Verwijderd]

TPL is meer het zelfde id als OpenMP. Dat wil zeggen dat de paralelle uitvoer synchroon gebeurd dus een functie met paralelle code wordt pas beeindigt als ook alle paralelle code is uitgevoerd.. GCD ondersteund echter ook asynchrone uitvoer dat wil zeggen dat een functie kan beeindigt worden voordat de paralelle code uit de functie klaar is. Hierdoor kun je dus c ode op de achtergrond door laten lopen zonder dat de interface hangt. Tevens kun je in GCD tasks koppelen aan bepaalde gebeurtenissen zoals het beschikbaar komen van data op een socket of het binnen komen van een OS signal.

[elmuerte]

Waar heb je het over!?

[Toolskyn]

Wat heeft dit met .NET te maken als ik vragen mag?

[Verwijderd]

Als ik de reactie goed snap:
Er bestaat bijna iets voor een ander platform (.NET) dat blijkbaar heel makkelijk is en veel talen spreekt. Dat is dan de reden dat deze technologie overbodig zou worden.

.NET is dan blijkbaar niet eens cross platform, waardoor een hoop mensen er niets aan hebben. Die mensen vinden dat ook helemaal niet erg.

Probleem opgelost dan?

[Mellow Jack]

Hoe ik de post snap (ben geen programmeur) is dit geen ontwikkel platform zoals .Net maar meer iets waar een platform/taal gebruik van kan maken.

[ZpAz]

Inderdaad, dit is gewoon een hulpstukje wat je bij een framework kan gebruiken (mocht het voor windows komen, dan zou dit in .net kunnen, onder OSX kan je er bijvoorbeeld gebruik van maken via Cocoa, maar ook zonder framework (direct C) kan je het aanroepen.

Het idee achter dit systeem is dat je zelf geen rekening hoeft te houden met het aantal cores in de computer, je moet je eigen code nog wel zo maken dat de berekeningen naast elkaar gemaakt kunnen worden.

Deze 'voer' je dan aan dit systeem, en deze verdeeld het netjes over de beschikbare cores, heb je meer threads aangemaakt dan er cores beschikbaar zijn, dan worden ze in de wachtrij via het FIFO princiepe geplaatst. En uitgevoerd wanneer er weer een core beschikbaar is.

Dus of je dan 2 of 8 cores hebt, je hebt altijd voordeel.

[YopY]

lol offtopic MS plug. Da's bijna net zo erg als een 'M$ $uX!' post onder een artikel over Intel.

[Zpottr]

Net so samenhangend en on-topic als deze reactie... Is Steve jobs over je hondje heengereden of zo?! Man man man.

[Verwijderd]

Max was z'n naam. Steve had een lever nodig en die mens kent geen grenzen

[johnkeates]

haha, fanboy of geen fanboy, I don't care maar het is wel een leuke misschien stond t beter als ie over een varken heen gereden zou hebben, dan komen d'r theorieen dat die organen ook goed werken

maarja, in z'n keynote met z'n ipods en die andere dingetjes ging ie ook nog de donor met z'n verkeersongeluk bedanken.. nu maar hopen dat meer mensen orgaandonor willen worden, zo erg is het nou ook weer niet. Als je dood bent heb je ze toch niet meer nodig

[johnkeates]

Eet nooit met de deur open als het blauw is.

Niet posten als je high bent!