Multicore-toolkit Intel opensource gemaakt

Intel heeft aangekondigd dat het zijn ontwikkeltools voor het programmeren van multithreaded applicaties opensource zal maken. Threading Building Blocks (TBB) 2.0 draait cross-platform en krijgt een gpl v2-licentie.

De chipmaker zal de commerciële versie handhaven, waarbij het bedrijf de klant ondersteuning zal verlenen. Intel is nog bezig om de gpl v3-licentie te bestuderen, maar of de software ooit onder die licentie zal verschijnen is nog maar de vraag. Met TBB richt Intel zich op C++-programmeurs; de tools moeten het ontwikkelaars eenvoudiger maken om met behulp van templates optimaal gebruik te maken van multithreading. Intel zou ook overwegen om soortgelijke ontwikkelsoftware voor Java en .Net uit te brengen. Opvallend is dat het vrijgegeven programmeergereedschap ook kan draaien op systemen die niet zijn voorzien van een Intel-cpu, zoals een Macintosh met G5-processor.

Door de opkomst van dual-, quad- en andere multicore-processors stijgt de vraag naar software die optimaal gebruik weet te maken van de extra rekeneenheden in moderne cpu's. De chipmaker hoopt dat, nu de software is voorzien van een opensourcelicentie, TBB zal uitgroeien tot een standaardtool voor het ontwikkelen van multithreaded programmatuur. Om de opensourcegemeenschap op weg te helpen is door Intel een website in het leven geroepen. Concurrent AMD blijft niet aan de zijlijn toekijken; ook deze processorfabrikant belooft programmeurs die hun code willen optimaliseren voor multi-core-cpu's een warm bedje.

Reacties (33)

[MrMr]

Mooi dat ze dit beschikbaar stellen, maar als ik in de tutorial kijk lijkt het toch wel erg op een variant van mpi. Waarom gaat dit nu opeens die programmeurs overhalen die al jaren soortgelijke parallelisatie tools laten liggen?

[mensoc]

En wederom bewijst Intel de betere partij te zijn voor software ontwikkelaars.
amd loopt altijd ver achter bij de ondersteuning van ontwikkelaars, en als deze dan met een tool komt is deze altijd van inferieure kwaliteit.

Intel is zoals gewoonlijk goed bezig.

[arjankoole]

amd loopt altijd ver achter bij de ondersteuning van ontwikkelaars

Pardon? Toen AMD bezig was met de ontwikkeling van x86_64 hadden ze daarbij de beste ondersteuning voor ontwikkelaars denkbaar. Niet alleen werkten ze intensief samen met Microsoft, maar ze leverden ook tools (inclusief een virtualisatie pakket) aan opensource ontwikkelaars om voor deze nieuw architectuur te ontwikkelen.

Mede daarom heeft Intel uiteindelijk geen keuze gehad, en hebben ze EM64T/Intel64/x86_64 ook in hun eigen CPU's moeten implementeren, juist omdat AMD het zo goed deed bij ontwikkelaars.

[xerix]

Gek he, dat AMD betere ondersteuning bood voor hun eigen instructieset. Het zou niet best zijn dat intel ook daarin betere ondersteuning (destijds) zou leveren.
Maar het is inderdaad goed te merken de goede ondersteuning van AMD aan developers... 4 jaar na dato is een verwaarloosbaar klein deel van de software reeds beschikbaar in een 64bits versie. Chapeau!
Feit is dat intel veel betere ontwikkeltools levert dan AMD en de community ook veel meer biedt. Zie bijvoorbeeld het opensource maken van deze toolkit.

[arjankoole]

4 jaar na dato is een verwaarloosbaar klein deel van de software reeds beschikbaar in een 64bits versie. Chapeau!

misschien doordat het merendeel van de mensen die een 64-bit cpu hebben, nog steeds een 32-bit OS instaleren?

oh ja.

En de meeste developers hebben blijkbaar domweg geen zin om een 64-bit versie te bouwen, omdat de 32-bit versie 'ook werkt'.

[EIo]

En zo'n beetje overal werkt. Zolang het voor performance niet nodig is kan je dus inderdaad beter 32 bit blijven developpen...

[Verwijderd]

En wederom bewijst Intel de betere partij te zijn voor software ontwikkelaars.

Ik wacht nog steeds op een gratis VTune, zoals AMD een gratis CodeAnalyst heeft...

[Verwijderd]

lijkt me zeer goed nieuws aangezien er toch nog behoorlijk wat applicaties enkel singlecore ondersteunen... en dan doel ik vooral op video/muziek-conversieprogrammaatjes... voorlopig gaan de meesten niet boven 60% processorgebruik hier. Beetje zonde van de extra kracht die ongenut blijft.

dbPoweramp 12 Reference is zowat het enige audioconversieprogramma dat 100% inneemt en dat is ook vrij logisch, als je 2 cores hebt, conveert hij gewoon 2 liedjes tegelijk, en 4 als je 4 cores hebt, enz... door gewoon extra instances te creëren die elks een eigen cpu pakken.

[Ge Someone]

Ja dat komt omdat compressie algoritmes erg moeilijk over meer threads gesplitst kunnen worden. Multiple instances zijn daar een goede oplossing voor (Trouwens foobar2000 doet dat net als dbPoweramp.)
Ik denk alleen niet dat je daar deze toolkit voor nodig hebt.

[Reactie gewijzigd door Ge Someone op 4 augustus 2024 00:01]

[vgroenewold]

Wow, nice! Kan ik zonder al teveel poespas m'n programmatuur optimaliseren. Intel is goed bezig zo, dit soort initiatieven zorgt wellicht eindelijk eens voor een grotere keur aan gespecialiseerde software voor multi-cores.

[Reactie gewijzigd door vgroenewold op 4 augustus 2024 00:01]

[arjankoole]

Wow, nice! Kan ik zonder al teveel poespas m'n programmatuur optimaliseren.

Ik denk dat je, als je al een goeie C++ progger bent, al prima in staat bent je code te optimaliseren. Deze tools helpen je alleen maar, ik denk dat de fundering onder je code nog wel geschikt moet zijn voor deze optimalisatie.

[Wim-Bart]

Klopt helemaal. Geldt overigens niet alleen voor C++ maar ook onder bijvoorbeeld .NET (VB, C++, C#) of in Pascal, bijvoorbeeld Delphi.

De toolkit van Intel is er alleen maar om het programmeren te veréénvoudigen. Een heel simpel iets, bijvoorbeeld een Wordprocessor, maakt veelal gebruik van Multithreading waarbij threads onder verschillende cores lopen.

Het gaat hierbij niet om het geschikt maken van ieder programma voor dual/quad/etc.. cores maar alleen specifieke. De toepassing moet geschikt zijn om in separate simultaan lopende threads geprogrammeerd worden.

Een MT programma is bijvoorbeeld een game. Thread 1 handeld de besturing af, nr 2 berekend de baan en impact van je kogel, #3 t/m #n zijn je oponenten en een thread voor je grafisch subsysteem, en 1 voor de sound etc.

Een ander programma is bijvoorbeeld zeer ongeschikt voor MT. Bijvoorbeeld een disk formateer programma. Het heeft namelijk geen zin om meerdere stukken van je disk tegelijk te formateren. IO is de bottleneck en zal de boel vertragen.

MT software is sterk afhankelijk van de deelbaarheid van onderdelen waarbij synchronisatie zo min mogelijke impact moet hebben. Niets is zo vervelend dat thread 1 30 seconden bezig is en thread 2 1 seconde en thread 2 moet wachten tot thread 1 klaar is. Dit kost resources, overhead en nog veel meer ellende.

[Verwijderd]

Goed initiatief Intel kan hier winst uithalen, omdat er meer software is voor multicore systemen en de consument krijgt beter op multicore presterende applicaties.

[_Apache_]

Ben benieuwd in wat voor concrete prestatie verschillen dit gaat maken.. Enkele procenten of delen door het aantal cores..

[Verwijderd]

Dit kan ook wel een hoop problemen veroorzaken. Als met deze toolkit dingen voor Linux worden gemaakt krijg je conflicten als bv. een GCC gecompileerd programma een intel library wil gebruiken. Ik heb in een ouder artikel in de CT gelezen dat de executable en dynamische lib uit dezelfde compiler moeten komen. Als er meerdere populaire compilers in omloop raken vergroot de kans dat je met het binnenhalen van packages GCC libs met intel libs overschrijft met alle gevolgen van dien. Er is namelijk geen methode om de applicatie te vertellen dat de lib met dezelfde naam toch anders is.

Dat de kit ook op andere processors draait is niet zo vreemd, dit zal zijn om te cross-compilen. Ik kan me heel goed voorstellen dat een MAC-dev thuis op z'n G5 voor intel-MAC's op het werk wil ontwikkelen.

[humbug]

Ook de CT lult wel eens uit zijn nek. Ik heb hier bv Delphi programma's die gebruik maken van dynamische libs die zijn gecompileerd met Visual Studio. Pure nonsense dus.

Ook is het niet zo héél logisch dat Intel dit beschikbaar stelt op andere platformen. De Intel C++ compiler (zo ongeveer de beste die bestaat) is ook enkel op intel platformen beschikbaar.

[Verwijderd]

Nu pas ? hoelang zijn ze niet al multi core's aant maken ... ik kocht myn eerste multi core 2 en half jaar geleden als de Pendium D830. die staat al mooi onder in de kelder met nog 2 jongere broertjes .. GEK denk je .. ik gebruik ze als server's en extra rekenkracht by sommige van myn app's

[Wim-Bart]

Ach een framework is een ondersteunende tool. Niets let een goede programmeur om al jaren een MT programma te schrijven....

[freaq]

ik zie toch emer in reverse-threading . dat de cpu zelf beslist welke taken belangerijk zijn en deze deelt over meerdere cores ( mogelijk kan men in de toekomst 1 core laten sturen en de ander (7,15,31) laten rekenen.
daar zie ik wel wat in, het zal moeilijk zijn maar van single naar dual core was dat ook,
err was een gerucht dat barcelona zó'n soort feature zou krijgen maar dat is ontkend door amd.

[FSVZ]

Leuke ontwikkeling door deze aan de community te geven.

Ben helaas wel een beetje sceptisch. Lijkt erop dat we nu een soort van matrix gaan krijgen waarin naast cross-platform ontwikkeling (Windows, Linux, Mac) ook cross-cpu ontwikkeling kan worden toegevoegd.