Intel wijzigt aanpak compiler-bouw

De Automatiseringgids meldt dat Intel de aanpak van de compiler-bouw heeft gewijzigd. Intel heeft een aantal schrijvers van software uitgenodigd om deel te nemen aan een werkgroep. Deze werkgroep moet gezamenlijk een raamwerk voor compilers voor de Itanium gaan maken. Door deze zet hoopt Intel sneller resultaten te kunnen brengen.

Microprocessor Research Lab (MRL) heeft de controle over de werkgroep. Het MRL houdt zich bezig met toekomstige hardware, ruw gezegd de processoren die over vijf tot acht jaar pas op de markt zullen komen:

Intel wil zo mogelijk afstappen van de huidige rigide manier van compilerbouw. De onderneming streeft naar het opzetten van een raamwerk, op basis waarvan nieuwe compilers eenvoudig geschreven kunnen worden.

Reacties (19)

[Stephan Oudmaijer]

Dit is een goede ontwikkeling voor alle tweakers die het maximale uit hun software willen halen.. Al je programma`s geoptimised voor je eigen cpu.. nu nog van alle programma`s de source code, kun je zelf de boel compilen

[Verwijderd]

Al je programma`s geoptimised voor je eigen cpu.. nu nog van alle programma`s de source code, kun je zelf de boel compilen

Misschien een voor de hand liggende opmerking, maar dit kan al, en heet heet Linux (of freeBSD of zo).

Je hebt alle sourcecode, en je kunt alles voor je eigen CPU geoptimalizeerd compilen.

Dit gaat over een framework waarin meerdere compilers gebouwd kunnen worden. Vergelijkbaar wat bij het EGCS project is gedaan. Daar is vanuit een framework ook een compiler systeem gemaakt dat meerdere platforms ondersteund (alpha, ultrasparc, x86), en ik geloof ook meerdere programmeertalen ondersteund, maar dat laatste weet ik eerlijk gezegd niet zeker.

[The End]

Dat vinden bedrijven nou niet echt handig om de sourcecode vrij te geven. Dan kan een programma niet alleen gecopieerd worden, maar zelfs onder een andere naam.
Ik denk ook niet dat het leuk is om op je PC windows 2000 te gaan compileren. Tegen de tijd dat je klaar bent is Windows 3000 al uit...

[curry684]

Zal mij benieuwen of ze een ruimte groot genoeg kunnen vinden om met alle GCC-ontwikkelaars om de tafel te gaan zitten... iedereen met megafoons om een tafel van 5km doorsnede

Maar even serieus, dit is welzeker een hele slimme en goede zet: Intel weet als ontwikkelaar iedere ranzigheid en bijwerking die de chip heeft, en kan daardoor waarschijnlijk nu al lijsten van honderden simpele optimalisaties geven waar Borland en het MS Visual Studio team anders jaren naar op zoek zouden zijn. Je hoeft die jongens echt niet meer uit te leggen hoe een compiler geschreven moet worden, maar de effectiviteit van optimalisaties blijven 100% CPU-afhankelijk.

[Jit]

de effectiviteit van optimalisaties blijven 100% CPU-afhankelijk.

Sorry, maar dat klopt van geen kanten. De meeste optimalisaties zijn eerder te halen uit het goed verwerken van je programma naar een intermediate code. Daarna wordt pas de boel omgezet naar iets als c-code, assembly of machine code zelf.

Daar vrijwel niemand direct machine code gaat zitten spuien, maken ze of gebruik van de lokale assembler of van spuwen van c code (die ook weer de assembler gaat gebruiken).
De enige compiler die dan ook echt enige optimalisaties op basis van de diverse processorinstrucities zou moeten kennen is de assembler. Dat Intel voor die laatste de hulp van anderen inroept, kan ik enerzijds wel begrijpen, alhoewel ik betwijfel of ze veel mensen zullen vinden die niet al bij hen werken... compilers schrijven wordt al niet door veel mensen gedaan, laat staan het schrijven van assemblers.

Oh ja, de suggestie om dit automatisch te doen is erg leuk, maar behalve een aantal van de eerste delen van het geheel dat compilen heet is er in onderzoek daarnaar nog weinig suc6 geboekt.

* 786562 Jit

[Verwijderd]

Sorry hoor, volgens mij is de taak van een compiler nog altijd menselijke code (C++ / PAscal / Basic /fortran /whatever) te vertalen naar machine code. en volgens mij is asm toch ook direct 1 op 1 te vertalen naar instructies op de proc dwz. een asm programma van 100 regels zijn 100 instructies voor de proc.

kortom het verhaal in de eerste allinia vindt ik een "beetje" wazig. het gaat er toch om dat de compiler van ene 3e generatie taal een zo efficient mogelijke assambler code maakt??

[Verwijderd]

Intel is in mijn ogen een beetje raar bezig. Ze kunnen zich beter afvragen wat de programmeurs van een nieuwe processor zouden willen en die features dan toevoegen, in plaats van zelf eerst iets te bedenken en dan de programmeurs proberen over te halen om zo snel mogelijk hun programmatuur te optimalizeren.

Als ze eerst even gepollt hadden wat de gemiddelde programmeur verbeterd wil zien en dat ook gedaan hadden, waren de programmeurs maar al te graag aan de slag gegaan.

[Verwijderd]

tja.. het probleem is eigenlijk al bekend:
- RISC tegen CISC
Risc: (Reduced) weinig instructies, snel, maar meerdere instructies nodig om iets te (laten) doen.
Cisc: (Complex veel instructies voor zeer gespecialiseerde/complexe zaken, minder instructies nodig om iets te (laten) doen. Denk aan de Screaming Sindy (met een 's' dacht ik ?) of MMX

Nu kan ik Intel's positie begrijpen als zij bedoelen:
Onze processoren (=CISC) worden dusdanig complex en alhoewel deze (nieuwere) processoren backwards compatible zijn... is het toch handiger als er nieuwere instructiesets middels nieuwere compilers beter benut worden..

In deze context zou je kunnen zeggen: Vraag eerst aan de programmeur wat ie wil --> signaalbewerking --> bijv. MMX extensies bedacht etc..
Maar ik denk niet dat dit Intel's insteek is, maar eerder de wens om de nieuwere processoren (vanzelf) nog sneller te laten runnen door een nog optimalere vertaalslag (=compiler) voordat het gerund wordt..

Zou rotter zijn als de mega-hertzjes wel toenemen, maar dat de uiteindelijke totale applicatie niet evenredig sneller wordt (andere factoren zoals bussnelheid etc.. buiten beschouwing gelaten)

Ander factor is ook: Je kan meer in software oplossen dan je fabricageproces c.q. processorarchitectuur compleet te moeten herzien (lees:backwardscompatibiliteit..)

[arjenk|IA]

Het RISC vs. CISC debat is al lang over. Het gaat hier om Itanium en opvolgers die volgens een heel ander principe werken. Vanaf de 8088/86 is het een kwestie van evolutie geweest, met de i386 is de overstap van 16-bit naar 32-bit gemaakt, waarvan Intel geleerd heeft dat dit jaaaaaren kan duren. Voor acceptatie in de markt zijn compilers levensbelangrijk, want hardware is alleen maar interessant als er goede applicaties voor zijn. Dit initiatief moet er voor zorgen dat er veel sneller en betere software beschikbaar komt - primair belang van Intel is toch CPU's verkopen.

[BaronTankhe]

Juist ja, niks RISC CISC maar EPIC. En aangezien er bij EPIC van tevoren door de compiler word bepaald wat er parallel verwerkt word en wat niet is het dus van belang dat er goede compilers zijn.
Dit is dus ook geen strategie van Intel om programma's op hun proc sneller te laten lopen dit zorgt ervoor dat er straks programma's voor de Itanium kunnen worden geschreven. (en niet oude 32bits code vertalen).

Dus geen strijd tussen Intel en AMD maar gewoon Intel die zorgt dat hun nieuwe product straks ook gaat doen wat ie moet doen.

[Verwijderd]

Ze hebben het hier over software ontwikkelaars van compilers (Microsoft, Borland) en dus niet de gewone applicatie programmeurs.

[Verwijderd]

Intel wil er juist voor zorgen dat er flink geprogrammeerd gaat worden voor hun processor. Aangezien gewone applicatie-ontwikkelaars graag werken in Visual Studio of een bepaalde RAD-omgeving e.d. moeten er voor deze omgevingen wel compilers gemaakt worden. En ga maar eens een compiler bouwen, gebaseerd op een volledig nieuwe architectuur! Wie kan dan beter het raamwerk bouwen, Intel zelf of een "onafhankelijk bedrijf" die met specificaties moet gaan werken? Intel is hier heel slim bezig!

-edit- Hoe the * moet dit nu een flaimbait zijn??? Jezus! Modereer eens wat OBJECTIEVER -edit-

[gnimmeL_kraD]

intel wil gewoon dat de petium4 beter doorbreekt en dat amd dan minder in de (nieuwe) servermarkt komt, volens mij

[ThE_ED]

Idd want dan zijn alle procjes die op zo'n beest gecompiled zijn geoptimised voor dit systeem. Hoewel je tegenwoordig ook vaak al ziet bij proc tijd vretende programma's dat ze eerst detecten welke proc er eigenlijk inzit en dan de daarvoor nodige routines gebruiken.

[ThE_ED]

Het bericht is wat vaag kort.
Als ik het goed begrijk wil Intel voor z'n proc een soort standaard supergoed compiler opzetten die dan laater door 3rd party uitgewerkt kan worden. Dit dan om ervoor te zorgen dat de programma's vaker snel lopen op deze proc. (ofzo ) ?

[Verwijderd]

Als ik het goed begrijp is het slechts een framework dus geen compiler software die kan compilen maar slechts een algoritme voor het ontwikkelen van een compiler zodat die programma's kan compileren die efficient op hun processors draaien.

[Beaves]

Zijn ze daar niet een beetje laat mee, aangezien de Itanium nu echt bijna uitkomt? Aangezien de Itanium staat of valt met de kwaliteit van de compilers moeten die heel goed zijn, door de gebruikte EPIC techniek. Daarbij moet de compiler aangeven in welke volgorde de CPU instructies moet uitvoeren, de huidige CPU's doen dat zelf door o.a. branch-prediction.

Dus als die compiler niet snel genoeg is, wordt de Itanium niet volledig benut, wat natuurlijk een slechte zaak is.

[Ganymedus]

Waarom zie ik deze nieuws post in de lijst staan en enkel en alleen onder andere postings? Hm nouja zal wel aan mij liggen, vast omdezelfde reden dat mijn news postings nooit doorkomen.
verder no comment just Intel

[Verwijderd]

Raamwerk? Dat heet toch gewoon windows