Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 66 reacties
Submitter: JanDM

Computergigant IBM heeft aangekondigd een compiler voor gcc te hebben ontwikkeld die in staat is te leren. De compiler kan applicaties op een intelligente manier optimaliseren, wat tot compactere en snellere programma's moet leiden.

HAL van 2001 A Space OdysseyIBM stelt de gcc-compiler, die het Milepost GCC noemt, als opensource-applicatie beschikbaar. De software werd in samenwerking met het door de EU gefinancieerde Milepost-consortium ontwikkeld, waaraan de de compiler ook zijn naam dankt. Dankzij machinaal leren zouden applicaties die met Milepost werden gecompileerd sneller presteren. Bovendien zouden ontwikkelafdelingen hun software sneller kunnen afleveren, zo claimt Big Blue.

De reductie in ontwikkeltijd zou vooral te danken zijn aan de kortere tijd die developers kwijt zijn aan het optimaliseren van software voor verschillende platformen. Milepost GCC zou de optimalisatietijd met een factor tien kunnen verkorten. De optimalisatie van gecompileerde software zou resulteren in een prestatiewinst van 18 procent, waarbij IBM testte met embedded applicaties op System p-servers.

De Milepost GCC-compiler maakt gebruik van kunstmatige intelligentie en machineleren, waarbij gecompileerde programma's met verschillende optimalisaties in de code getest worden, waarna de resultaten met elkaar vergeleken worden. De code met de beste optimalisaties wordt door de compiler als beste geselecteerd.

Moderatie-faq Wijzig weergave

Reacties (66)

Ik heb inmiddels wat meer gelezen, wat losse observaties:

- Eerst tellen ze datastructuren (in de meest ruimte betekenis van het woord). Ze bepalen dus dingen als de verhouding tussen loopjes, ifjes, klassen, strings enzovoort. Hiermee kunnen ze een voorselectie maken van optimalisaties die waarschijnlijk nuttig zijn. Tevens wordt deze informatie opgeslagen om in de toekomst vergelijkbare programma's te herkennen.

- Op grond van deze informatie kan niet alleen voorspeld worden welke optimalisaties gebruikt moeten worden, maar ook welke combinaties het meest waarschijnlijk tot verbetering leiden.'

- Om dit te laten werken heb je dus wel eerst een database nodig met voorgecompileerde test programma's. Die hebben ze aangemaakt door een hele berg software een aantal keren met random opties te laten compileren. Door puur toeval zullen sommige dichter bij optimaal zijn dan anderen. Die verschillen vormen de basis die leren mogelijk maakt.
Dus dan compile je je programma gewoon 5 keer achter mekaar, en elke keer word hij net iets sneller :P
Neen, je hebt een kans dat het sneller is. ;)

Het principe bestaat al lang. Een zogenaamde 'supercompiler' gaat elke mogelijke sequentie instructies na om er de snelste uit te pikken die het gevraagde implementeerd. Uiteraard is dit niet werkbaar in de praktijk. De zoektijd neemt extreem snel toe bij langere reeksen instructies. Maar in de theorie is dit dus de perfecte compiler.

De compiler van IBM gaat niet zomaar elke sequentie instructies na, maar maakt verschillende afwegingen en onthoudt welke een positief effect hadden om de volgende afweging zo goed mogelijk te kunnen maken. Het zal er doorgaans niet in slagen dé meest optimale code te vinden, maar wel een goede oplossing in redelijke tijd.
Maar uit jouw verhaal is op te maken dat hij uiteindelijk wel de meest optimale code zal vinden right? (zodra hij genoeg verschillende scenario's is tegen gekomen).
Nee, zoals ik het lees doet hij dit alleen binnen het gestelde algoritme.
De beste code vinden betekent dat alle mogelijke codes getest en vergeleken moeten worden, dit is natuurlijk logischerwijs onmogelijk aangezien de mogelijkheden kwadratisch toenemen met de grootte van de code.

In die zin kun je zeggen dat de beperking van deze methode processorkracht is. Het 'voordeel' van dit nadeel is dat het niet om een berekening gaat die binnen een aantal seconden gedaan zal moeten worden, indien dit professioneel ingezet gaat worden kan een bestaande code worden ingevoerd en, bij wijze van spreken, dagen kan compilen en vergelijken. Zo is processorkracht meer voorhanden naarmate er meer tijd is.

[Reactie gewijzigd door jordy2811 op 4 juli 2009 00:06]

Wat is een week op een ontwikkel periode van jaren?
Ik denk niet dat er vanwege de verscheidenheid aan programmatuur, 1 beste oplossing zal zijn. Maar een keur aan beste opties zou kunnen, misschien zou je de compiler kunnen aangeven wat voor type programma je aan het maken bent en op die manier sneller de beste code hebben...
Het mooie aan een "zelf lerende" compiler is juist het feit dat hij zelf kan zien wat voor een programmeur er werkt en zodoende de code kan optimaliseren.

Het is een maximalisatie van de performance waar binnen een korte tijd naar gezocht moet worden. Alle mogelijke opties doorlopen kost waarschijnlijk eindeloos veel tijd dus een stukje AI kan het zoeken versnellen. MAW niets anders dan een optimalisatie AI
Tja, dat zou leuk zijn maar dat is niet wat deze compiler doet. Hij gebruikt simpelweg verschillende machine-learning algoritmes om te kijken of hij het programma beter kan optimaliseren. That's it. Niets zelf-lerend of iets dergelijks. De titel is dus ook aardig misleidend.

Nou is het natuurlijk wel een stap voorwaarts, onder andere kan code zo voor multi-cores geoptimaliseerd worden zonder dat je er zelf eigenlijk mee rekening houdt.

@Dajero: Wat ik op de website lees is dat ze de compiler verschillende soorten algoritmes laat testen om te kijken welke uiteindelijk voor het programma het beste presteert. Wat ik in eerste instantie van de website haalde, was dat ze een database aanlegde voor verschillende optimalisatie-algoritmes. Dat op zich kan ik niet echt als zelf-lerend of machine-learning verstaan omdat het zichzelf niet aanpast. Alleen hun uiteindelijke doel is blijkbaar wel om een zelf-aanpassende compiler te maken. En dat is dus wel machine-learning (in ieder geval in mijn ogen). Dus op dit moment nog niet zelf-lerend, in de toekomst hopen ze van wel.

@SuperNull: Het klopt inderdaad dat grote stukken code moeilijk (automatisch) te parallelliseren zijn. Op de website van Milepost zijn onder andere papers te vinden die dit soort dingen proberen te doen. Ik heb ze niet in detail gelezen, maar het is enigszins te verwachten dat hier onderzoek naar gedaan wordt. Veel programma's maken er nog geen gebruik van en toch liggen de cpu-cycles voor het oprapen. Ik neem aan dat je zelf niet in de onderzoek-wereld zit, want als je van te voren al denkt dat zulk onderzoek "extreem onwaarschijnlijk" tot een resultaat komt, dan kom je als onderzoeker natuurlijk nooit een stap verder.

[Reactie gewijzigd door blizzeye op 4 juli 2009 11:40]

Nu vraag ik me af wat jij verstaat onder een machine-learning algoritme. Een machine learning algoritme wordt gebruikt om een bepaald model te leren/adapteren aan de hand van bepaalde input (Dit is expres breed gelaten want er zijn verschillende soorten input en verschillende soorten te leren concepten). Zoals ik het nu lees, worden bepaalde onderdelen van de compiler aangepast met behulp van machine learning algoritmen.

Om hellfighter87's vraag te beantwoorden: Het enkel hercompileren van je programma is waarschijnlijk niet voldoende. De leeralgoritmen zullen een indicatie moeten krijgen van de mate van optimalisatie. Je zult je programma dus ook moeten benchmarken. Een deel van het onderzoek richt zich op dat probleem.
Nou is het natuurlijk wel een stap voorwaarts, onder andere kan code zo voor multi-cores geoptimaliseerd worden zonder dat je er zelf eigenlijk mee rekening houdt.
Waar haal je dit opeens vandaan?
Zolang machines nog geen volle menselijke AI hebben kan echt alleen de programmeur voorzien of threads elkaar in de weg kunnen gaan zitten in elk stuk software dat maar een beetje ingewikkeld is.
Om effectief threads te kunnen gebruiken moet je je hele project echt anders plannen en hier en daar de nodige extra checks doen op van alles en nogwat. Dat zijn allemaal ontwerp perikelen waar het heel makkelijk in is om denkfouten te maken of met iets te eindigen dat minder snel is dan single-thread.
Dat een compiler dat allemaal voor je kan 'fixen' lijkt me extreem onwaarschijnlijk.

Edit: Oh ik geef je gelijk dat dat de multithread API naar de programmeur toe beter kan en dat er nog heel wat te optimisen is, maar je suggereerde dat je helemaal geen rekening zou moeten kunnen houden met multithreading en DAAR geloof ik niet in.

[Reactie gewijzigd door SuperNull op 4 juli 2009 23:06]

Ze brengen het uit als opensource, net als de originele gcc zelf. Zou de code van IBM dan op een gegeven moment in de "gewone" gcc worden opgenomen, zodat iedereen die gcc gebruikt ervan kan profiteren?

gcc is één van de belangrijkste GNU programma's, alle Linux distro's gebruiken dit om de Linux zelf en alle applicaties te compileren.
Er is best kans dat dit gebeuren door de linux community omarmd zal worden, het zal echter niet zomaar in GCC komen. Hiervoor zijn twee redenen. Ten eerste wil de FSF niet alleen dat de te adopteren code onder de GPL valt, maar ook dat de auteurs hun copyright volledig overdragen aan de FSF. Lijkt me dat de auteurs van milepost hier geen zin in zullen hebben. Ten tweede is het project geen compiler, maar een tool die kan leren van compilaties en daarmee nieuwe compilers kan genereren.

Dit is vooral interessant om (snel) goede compilers te maken voor nieuwe architecturen, het is nog maar de vraag of deze tool handgeschreven compilers voor een specifieke architectuur zal kunnen verslaan. Ik verwacht niet dat hier veel uitkomt voor de x86 architectuur, waar sowieso al een hoop aandacht voor is.
"And for a time it was good". Citaat uit: The Animatrix

Heerlijk computers die voor ons gaan denken. Lijkt in het begin niets, maar deze ontwikkelingen kunnen heel snel gaan.
Heerlijk computers die voor ons gaan denken.
Dit denkt helemaal niet voor ons. De titel is nogal misleidend. Het is een lerende compiler, niet een zelf-lerende compiler. Het is een algoritme als een ander. Het gaat simpelweg gedane optimalisaties beoordelen door de verwerkingstijd te meten, en houdt dus bij welke succesvol zijn en herhaald kunnen worden.

Dezelfde methoden worden ook elders gebruikt. Zo kan een GPS aan de hand van de werkelijke tijd over een trip beslissen om de volgende keer een andere route te proberen, of bijhouden dat er op sommige regelmatige tijdstippen fileproblemen zijn op bepaalde wegen.

Je hoeft dus niet paranoia te gaan doen dat zulke algoritmes geheel op zichzelf tot besluiten zouden komen.
Gezien er geen supervisor is, is dit toch wel 'zelf-lerend' in mijn ogen.

De compiler komt een 'scenario' tegen dat nieuw is of ene die hij kent.

Bij een nieuw scenario zal hij verschillende optimalisaties proberen uit te voeren. Vanuit de resultaten die dit oplevert zal hij een algemene methode abstraheren die hij op gelijkaardige scenario's zal toepassen.

Of dit als 'denken' beschouwt kan worden is natuurlijk een andere kwestie. Alle artificiële intelligentie algortmen, blijven uiteindelijk algoritmen door de mens geschreven.
De titel is nogal misleidend.
Weet je, eigenlijk is het nogal verspilde moeite om te reageren op mensen die duidelijk niet (veel) verder hebben gelezen dan de titel. ;) Dit soort ononderbouwde posts komen toch wel vaak voor en lokken altijd weer sarcastische reacties uit...

(Het is trouwens "paranoïde", niet "paranoia".)
Och, hij kan slechts broncode die door mensen is geschreven beter compileren en leren hoe hij door mensen geschreven broncode beter kan compileren. Dit lijkt niet niets, dit is nog 'niets', al is het wel een leuke doorbraak :)

[Reactie gewijzigd door graey op 4 juli 2009 11:44]

ja zeker |:( combineer je 1 miljoen aan dit soort computers sluit ze aan internet en...
"Skynet is online" _/-\o_
Klinkt verdacht veel als Profile Guided Optimisation zoals het in Visual Studio/MSVC zit.
Dat kijkt vooral naar waar de hotspots zijn, om daar zwaardere optimalisaties door te voeren, ten koste van de grootte van de code en het nodige geheugen. Denk bijvoorbeeld aan inlining. Als je dat te aggresief doet wordt de code veel te groot (wat op zich weer negatief is voor de prestaties doordat de instructiecache overloopt). Je kan het dus beter enkel daar toepassen waar nodig.

De compiler van IBM lijkt nog een grote stap verder te gaan. Het gaat niet éénmaal kijken waar de hotspots zijn, maar bekijkt het gevolg van elke optimalisatiebeslissing en stuurt het keer op keer bij.

Maar enige gelijkenis met 'Profile Guided Optimisations' is er wel.
is dit niets anders dan wat compilers zoals die van FORTRAN doen? code meerdere malen analyseren om zo ver mogelijk te kunnen optimaliseren. Het enigste verschil hierbij is dat dit versnellingen oplevert bij single-pass compilers, omdat de compiler leert uit vorige passes bij andere programma's. Zouden alle programmeertalen multipass compilers gebruiken zou dit allemaal niet veel extra zoden aan de dijk brengen.
Nog steeds wel, omdat die multipass niet nodig is, wat tijd scheelt.

Overigens is het idee niet zo heel nieuw. Tenminste, ik speelde al met het idee om een GA te gebruiken voor peephole optimization van ARM code, zo'n 15 jaar terug. En ik was vast niet de eerste :D. Dit zal echter vast wel een stuk geavanceerder zijn.
Volgens mij ben je nu wel de controle over de code kwijt en bestaat de kans dat de compiler ook bugs creëerd of veiligheids lekken...
Die controle was je al een hele tijd kwijt. Een compiler doet sowieso al diverse optimalisaties, waarvan dit er gewoon ook een aantal zijn. En ja, een code optimalisatie kan soms voor een bug zorgen. En dat kan dan of een fout van de programmeur zijn (die bepaalde aannames heeft gemaakt) of van de optimalisatie. En uiteraard, in het laatste geval wordt de optimalisatie aangepast.

Het blijft mensenwerk ;-)
Ze zouden wel wat meer detail mogen geven over het machine learning gedeelte. Hun FAQ vertelt net niks. Machine Learning is zo'n brede term, daar valt bijna alles onder.

Hier mijn eigen machine learning compiler:

for x in 1-4:
gcc -O x mijnFile.c -o test
if size(test) < size(best):
best = x
return best

Niet erg indrukwekkend, maar technisch gezien machine learning.
Wat mensen boven mij 'doemscenario' en 'Skynet' noemen heeft een officiele naam, de Singulariteit. Op dit punt zullen computers slimmer worden dan mensen en zal de technologische vooruitgang heel erg snel gaan (volgens sommigen zelfs oneindig snel).

Het idee is, dat de mens een zelflerende robot in zijn 'evenbeeld' kan maken, en het misschien zelfs iets kan verbeteren, maar niet veel. Echter, als de mens dat kan, kan die verbeterde robot dat ook. Maar die was al iets slimmer, en zal dan nog iets slimmer worden, enz.

Dit is een van de mogelijke uitleggen van de Singulariteit. Het blijft de toekomst, dus flink koffiedik kijken. Maar dat het punt in de nabije toekomst er komt, dat mensen een AI maken die even slim is, dat staat bijna wel vast :)
Mja, het is natuurlijk de vraag of de mens iets kan scheppen dat intelligenter is dan zichzelf. Want op het moment dat de mens het schept, en we het dus kunnen vatten, valt de intelligentie weg.
Leren? Hm. Met welk doel?
Compilen tot een zo compact mogelijk bestand? Of zo optimaal mogelijke instructies? Minimale processorbelasting? Of optimaal geheugengebruik?
Gaat ie leren om rubuust te zijn? Of elegant? Kiest de compiler dan voor onafhankelijkheid of is het zaakje dan gelinkt aan bestaande tech?
Of gaat ie voor alles en sluit de compiler op alle fronten compromissen? :?

Het poldermodel leeft voort in intelligente compilers... :+

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True