Hoofdcategorieën
Device Settings

[RSS] [quick] Index » Nieuws » Pro » Development » Multicore-toolkit Intel opensource gemaakt

Multicore-toolkit Intel opensource gemaakt

Door Dimitri Reijerman, woensdag 25 juli 2007 13:20
Bron: Ars Technica, views: 11.336

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.

Thread Buildinging BlocksDe 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.

Volgende 14:03 Ook Xen krijgt plaatsje in Linux-kernel
Vorige 12:52 Interview met makers opensourcetelefoon
Advertentie

Categorieën

Gerelateerde content

Gerelateerde jobs

Reacties

Flat modeFlat mode Sorteer aflopendSorteer aflopend Moderatie FAQModfaq
Niveaufilter: -1 Ongewenst: 33 reacties zichtbaar330 Off-topic / Irrelevant: 31 reacties zichtbaar31+1 On-topic: 4 reacties zichtbaar4+2 Informatief: 3 reacties zichtbaar3+3 Spotlight: 1 reactie zichtbaar1
«  1  2  »

Door Clueless, woensdag 25 juli 2007 13:23

Score: 0
Dit is goed nieuws. Ben toch wel benieuwd naar het soort impact dat dit zal gaan hebben op applicatie en de optimalisatie voor meerdere cores.

Door bbob1970, woensdag 25 juli 2007 13:42

Score: 1
het zal wel een positive impact gaan hebben. Het nadeel van het multicore geweld is gewoon dat de meeste software er nog achteraan loopt en niet echt optimaal gebruik kan maken van multicores.
Het is dan zeker ook voor intel van belang dat dat wel zo is. Immer hoe meer software er optimaal gebruik van maakt hoe meer de klant het nu voor nog sneller zal gaan inzien.

Door blouweKip, woensdag 25 juli 2007 14:40

Score: 0
Commerciele software zal er dus geen gebrui van kunnen maken...
Commerciele software zal de source niet kunnen misbruiken, maar je kunt er prima closed source software mee maken.

vergeet niet: alle restrictieve licensies (zoals shared source en de standaard windows licensie) beperken je als eindgebruiker/developer heel wat meer dan bijv de gpl(2/3)

Door czubin, woensdag 25 juli 2007 17:48

Score: 0
Nope, gplv2 met 'runtime exception'. Wat inhoudt dat je er legaal gesloten software mee kunt bouwen.

quote van de onder gelinkte artikel:

"Q: How is that different from the GNU {Lesser,Library} GPL?
A: The LGPL requires that users be able to replace the LGPL code with a modified version; this is trivial if the library in question is a C shared library. But there's no way to make that work with C++, where much of the library consists of inline functions and templates, which are expanded inside the code that uses the library. So to allow people to replace the library code, someone using the library would have to distribute their own source, rendering the LGPL equivalent to the GPL."

http://gcc.gnu.org/online...c++/17_intro/license.html

Door Jeanpaul145, donderdag 26 juli 2007 03:20

Score: 0
Volgens het artikel zal Intel de commerciele variant handhaven. ;)

Door 108886, woensdag 25 juli 2007 13:28

Score: 0
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.

Door Ge Someone, woensdag 25 juli 2007 18:00

Score: 0
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 woensdag 25 juli 2007 18:01]

Door mensoc, woensdag 25 juli 2007 13:28

Score: 0
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.

Door arjankoole, woensdag 25 juli 2007 14:12

Score: 3
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.

Door xerix, woensdag 25 juli 2007 14:59

Score: 0
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.

Door arjankoole, woensdag 25 juli 2007 15:55

Score: 0
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'.

Door EIo, donderdag 26 juli 2007 10:34

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

Door c0d1f1ed, woensdag 25 juli 2007 15:38

Score: 2
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...

Door vgroenewold, woensdag 25 juli 2007 13:29

Score: 0
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 woensdag 25 juli 2007 13:30]

Door arjankoole, woensdag 25 juli 2007 14:14

Score: 0
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.

Door Wim-Bart, donderdag 26 juli 2007 00:29

Score: 0
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.

Door MrMr, woensdag 25 juli 2007 13:49

Score: 2
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?

Door hylke1982, woensdag 25 juli 2007 13:54

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

Door _Apache_, woensdag 25 juli 2007 13:55

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

Door FozzytheBear, woensdag 25 juli 2007 14:05

Score: 0
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.

Door humbug, woensdag 25 juli 2007 14:16

Score: 0
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.

Door dapkor, woensdag 25 juli 2007 14:09

Score: 0
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

Door Wim-Bart, donderdag 26 juli 2007 00:30

Score: 0
Ach een framework is een ondersteunende tool. Niets let een goede programmeur om al jaren een MT programma te schrijven....
«  1  2  »

Op dit item kan niet meer gereageerd worden.

Volgende 14:03 Ook Xen krijgt plaatsje in Linux-kernel
Vorige 12:52 Interview met makers opensourcetelefoon
VNU Media logo Hosted by True

© 1998 - 2012 Tweakers.net B.V. - Alle rechten voorbehouden - Contact - Jouw privacy - Algemene Voorwaarden

Uitgever van:

Website van het jaar 2011