Intel komt met multicore-threadingtool voor C++

Intel heeft een collectie ontwikkeltools vrijgegeven waarmee het voor programmeurs eenvoudiger is om multithreaded programma's te ontwikkelen. Threading Building Blocks 1.0, zoals de nieuwe verzameling tools heet, maakt gebruik van C++ templates om de programmeertaal uit te breiden met threading-mogelijkheden. Door deze aanpak is het nieuwe pakket van Intel geschikt voor verschillende compilers (Intel, Microsoft en GNU) en meerdere besturingssystemen (Windows, Linux en Mac OS X). Helaas is de software niet gratis, Intel vraagt er bijna 300 dollar voor.

In tegenstelling tot talen als C# en Java heeft C++ standaard geen ondersteuning voor het eenvoudig benutten van multithreading. Hierdoor moeten C++-programmeurs zelf vaak het wiel opnieuw uitvinden wat een lastige opgave is. Met de opkomst van processors met meerdere cores is het van essentieel belang dat veel software van parallelle processen gebruik maken om de afzonderelijke rekeneenheden die aanwezig zijn op de processor optimaal te kunnen benutten. Intel spant zich daarom in om software-ontwikkelaars te stimuleren om meerdere threads te gebruiken in programma's. Onder andere een onderwijsprogramma op 45 universiteiten waarin parallelle programmeertechnieken worden gepromoot moet hiervoor zorgen.

Reacties (62)

[Verwijderd]

Hierdoor moeten C++-programmeurs zelf vaak het wiel opnieuw uitvinden

Huh, wat is er mis met pthread_create()?

[.oisyn]

Huh, wat is er mis met pthread_create()?

Volgens intel, dit

Hier staat het hele artikel.

Van wat ik ervan begrijp is het een library die je kunt gebruiken om jobs te schedulen, waarbij die library zorgt voor juiste balancing over de meerdere CPU's en dat alle jobs in de juiste volgorde uitgevoerd worden. Met POSIX threads (of elke andere kale threading library for that matter) kun je threads creëren en voor synchronisatie zorgen. Dat de workload goed verdeeld wordt zul je nog helemaal zelf moeten programmeren.

Je kunt trouwens ook een evaluation version downloaden, even proberen...

[Verwijderd]

Aan het voorbeeld te zien is het eerder een vervanging van OpenMP en niet van pthreads.

Met OpenMP kan je heel makkelijk synchroniseren en krijg je ook altijd automatisch het aantal threads dat je hardware aankan. Het zou best kunnen dat ze onder water toch weer pthreads (of wat dan ook) gebruiken.

[.oisyn]

Idd. Het punt is dat je voor OpenMP compiler support nodig hebt. Met deze library hoeft dat dus niet. Het zal idd wel gewoon bouwen op een onderliggende threading API (en dan waarschijnlijk de native API van het OS, zodat je meer controle hebt dan een extra abstractielaag je kan bieden - de evaluation downloads verschillen ook voor elk OS)

[OpenMinded]

ik zie in je links geen verhaal over wat mis is met pthread_create?

[zeroxcool]

En CreateThread() onder Windows .

[Little Penguin]

Dat ze niet in C++ maar in C geschreven zijn?

In Java en Delphi (en waarschijnlijk ook in c-sharp) zijn er namelijk standaard al classes aanwezig waarmee men dit probleem op een OO manier kan oplossen.

Edit: Overbodig?

OK - even een inkoppertje: Intel biedt nu een hulpmiddel aan voor C++ programmeurs die ook nog eens een keer Object Oriented is!

[.oisyn]

boost::thread, 'nuff said. Boost is the next best thing na de ISO C++ standaard zelf, waarvan vele componenten een goede kans maken om in de volgende C++ revisie opgenomen te worden. Elke zichzelf respecterende C++ developer zou 'm geinstalleerd hebben moeten staan.

[Olaf van der Spek]

waarvan vele componenten een goede kans maken om in de volgende C++ revisie opgenomen te worden.

Helaas duurt dat nog tig jaar.

[.oisyn]

Het is idd te hopen dat de 0 in C++0x ook echt een 0 blijft . Maar goed, tot dan hebben we dus boost

[Verwijderd]

Elke zichzelf respecterende C++ developer zou 'm geinstalleerd hebben moeten staan.

Ik heb hem niet en respecteer mijzelf.

Mijn software is dan ook vrij low-level en performantie-kritisch. Dus ik wil (moet) alles zelf onder controle hebben. Dit geldt bijvoorbeeld ook voor drivers, waar je niet zomaar op bepaalde bibliotheken kan rekenen. Het zal dan ook nooit gebeuren dat dingen aan C++ worden toegevoegd die beletten om low-level te gaan, of die afhankelijk zijn van het besturingssysteem.

Voor andere toepassingen is boost uiteraard zeer waardevol.

[Olaf van der Spek]

Het zal dan ook nooit gebeuren dat dingen aan C++ worden toegevoegd die beletten om low-level te gaan, of die afhankelijk zijn van het besturingssysteem.

Networking en threading support lijken met per definitie afhankelijk van het besturingssysteem, evenals file support.
File support zit er al in.
En ik denk dat de twee anderen uitstekende toevoegingen zouden zijn aan de standaard C++ libraries.

[Roland684]

Krijg je daarmee wel echte threads? die echt op verschillende cores kunnen worden uitgevoerd? (en dan nog thread-safe zijn?)

[.oisyn]

Wat zijn niet-echte threads dan

[Wolfboy]

Ik verwacht dat Rolang user threads bedoeld met niet-echte threads, en kernel threads bij 'echte' threading. Al ben ik het er niet zo mee eens eerlijk gezegd, beide methoden hebben voor en nadelen

[zeroxcool]

Daar kan een 'hoge' taal als C of C++ weinig aan doen. Dat is aan de implementatie van de architectuur.

[defusion]

Ik neem aan dat er iets uitgebreidere templates komen, waarbij het allemaal makkelijker te integreren is.
Hoe je data kunt delen etc. Dat soort dingen hoeft niet iedere keer opnieuw gedaan te worden

[Verwijderd]

Helaas is de software niet gratis, Intel vraagt er bijna 300 dollar voor.

Dit heb ik nooit begrepen. Ook hun fantastische VTune optimalisatiesoftware is verre van gratis, terwijl het juist de software sneller maakt op Intel processors. Hierdoor kunnen ze een kleine maar niet onbelangrijke voorsprong nemen op AMD. De tools van AMD zijn trouwens wel gratis...

[Kalief]

Hoe wordt eigenlijk bepaald wanneer een proces een eigen thread moet krijgen? Gebeurt dat in de ontwerpfase (vooraf) of is het deel van de optimalisatie (achteraf).

[Little Penguin]

Enigszins offtopic - want het heeft niets met het nieuwsbericht te maken.

Bij een goed ontwerp wordt vooraf bepaald of de applicatie multi-threaded is of juist niet. Doe je dit achteraf pas dan loop je het risico dat de reeds geschreven code vrijwel geheel herschreven moet worden omdat ze niet threadsafe is. (Bijvoorbeeld bij het gebruik van globale variabelen).

(Bij een goed ontwerp wordt vooral ook al gekeken waar er eventueel bottlenecks zijn en is er dus vooraf al gekeken of, en zo ja waar, er geoptimaliseerde code nodig is...)

[farlane]

Ben ik niet met je eens. Een goed ontwerp functioneert in beide situaties goed.

Als hij door een wijziging geheel herschreven moet worden is je ontwerp zelfs bar slecht IMHO

[Little Penguin]

farlane, heb je wel eens gewerkt met multi-threading?

Er zijn diverse oplossingen die in een normaal programma geen enkele probleem opleveren, maar in een multi-threaded omgeving wel voor enorme issues/bugs/crashes zorgen!

[smokalot]

het threaden kun je niet aan een compiler overlaten, dat moet je echt in je code zelf doen.

Threaden maakt de code helaas een stukje complexer, dus veel developers doen dat liever niet, ook niet als het een stukje performance scheelt.

[Roland684]

Er zijn wel degelijk performancewinsten te boeken door de compiler. Ik weet niet of het gebruikt wordt, maar je zou bijvoorbeeld een tweede thread alvast een verderop gelegen stukje code kunnen laten processen. Natuurlijk was dat verspilde moeite als blijkt dat dat op basis van net gewijzigde variabelen had gemoeten, maar branch-prediction werkt ook ongeveer zo. Daar wordt dat alvast aan instructies van de 'then' begonnen, voordat de 'if' is geevalueerd.
Mogelijk was het verspilde moeite, maar anders had je tweede core/pipe toch stil gestaan, dus maakt het toch niet uit.

Iets als
x=moeilijkeberekening(42);
y=moeilijkeberekening(684);
zou best door de compiler herkend kunnen worden, (inclusief of er misschien nog globale variabelen zijn die een rol spelen) en automatisch worden verdeeld over verschillende threads.

En ik kan mij goed voorstellen dat een compiler kan zien dat je in een functie je return-variabelen al klaar hebt en nog wat andere dingen gaat doen die geen invloed meer hebben op de rest van het programma (zoals wat logging, vrijgeven van geheugen, etc) en besluit een thread alvast door te laten gaan met het hoofdprogramma terwijl een andere thread de zaken in de subroutine nog afrond.

Of alvast de volgende iteratie van een for-loopje laten processen door een extra thread.

Op een hoog niveau zal dat moeilijk worden, maar zeker op een laag niveau kan een compiler veel van die kleine dingen doen terwijl dat voor een mens veel te tijdrovend zou zijn.

En garbage-collection is ook iets waar vrijwel niemand iets aan programmeert, maar wat wel enorm zal profiteren van meerdere cores.

[Jeroen V]

Vooraf, is een redelijk belangrijk onderdeel van het ontwerp. (ongeacht de taal die je gebruikt) Als je het later alsnog zou willen toevoegen dan krijgt dat niet alleen een vrij hoog knutselgehalte, de kans op fouten is erg groot.

[Verwijderd]

Multi threading is iets wat van voor tot achter door je ontwerp heen loopt. Niet een sausje wat je er achteraf overheen giet.

Om zinvol te multithreaden moet dat meestal in de ontwerp fase gebeuren. Je moet immers niet alleen de code in threads opdelen, maar bijvoorbeeld ook zorgen dat je geen situaties krijgt waarin twee threads op elkaar wachten op een signaal om daar te mogen gaan. (zgn. deadlock)

[Verwijderd]

Ze zijn nog wat vergeten bij het stukje: apps, tools, services, drivers and platforms. Games!

Meeste mensen kopen een zware dual core cpu om te gamen, Word of zo zal er niet zo gek veel sneller op draaien.

[Verwijderd]

@_eduard_:

Games hebben meestal van zichzelf niet heel veel te doen, het echte zware werk wordt gedaan door de onderliggende API.
Tegenwoordig dus eigenlijk uitsluitend Direct-X en OpenGL.

Je kan als game programmeur wel wat dingetjes in andere threads doen, maar 99% van wat er gebeurt wordt gedaan via de API waardoor de winst minimaal zou zijn (terwijl het wel flink wat meer kost).

De API laat aan de andere kant ook weer een hoop over aan de drivers (niet alleen de videokaart, ook netwerk, geluid etc).

Het is dus meer een zaak om te richten op multi-threaded drivers en een API die daar goed mee om kan gaan.

Drivers zijn nu eenmaal niet de makkelijkste zaken om multithreaded te maken (en ook nog efficient te laten werken). Gelukkig wordt er aan alle kanten hard aan gewerkt.

Ik denk dat we begin volgend jaar met Direct-X 10 en alle drivers/hardware van dan flink gebruik maken van de meerdere cores in spellen.

Bijkomend nadeel is dat iemand met een enkele core een enorme achterstand heeft. Gelukkig komen begin volgend jaar ook de budget dual-core CPU's uit.

[.oisyn]

Sorry maar dit is echt onzin, wat je met de 3d api's kunt is -kort door de bocht- alleen tekenopdrachten geven. De game zal moeten bepalen wát en hoe getekend moet worden, en die opdrachten zo efficient mogelijk geven. Een API gaat bijvoorbeeld echt geen visible surface determination doen.

Traditioneel gezien hebben games vaak weinig aan meerdere threads omdat de opbouw nogal serieel is - je hebt een lijst met processen (input, AI / gamelogic, physics, rendering) waarbij elk proces weer afhankelijk is van het vorige, dus die zijn moeilijk parallel aan elkaar uit te voeren. Voor de afzonderlijke processen zelf is het vaak ook heel lastig om die op te delen over meerdere processoren.

[.oisyn]

Heb je zelf ooit met Direct-X gewerkt?

Heb je op m'n profiel geklikt voor je deze reactie tikte? Vast niet. Doe het eens . Ja, ik heb dus met DirectX gewerkt (en OpenGL, en de console API's, en direct met hun hardware), maar ik denk dat je er zelf geen idee van hebt wat een game allemaal nog meer moet doen om het allemaal efficient te laten lopen. De DirectX API is daar maar een heel erg kleine fractie van.

En dat engines meestal ingekocht worden is lang niet altijd waar. Zo zijn er maar weinig echte cross-platform engines (en met cross-platform bedoel ik dus de consoles, niet windows vs. linux), en daarnaast ben je met een in-house engine veel vrijer en kan er bovendien beter geoptimaliseerd worden (elke game heeft immers een eigen use-pattern)

Daarnaast:

Het is zeker veel meer als alleen een 3D renderer

Ja, maar als je het in één adem met OpenGL noemt ga ik ervanuit dat je het over Direct3D hebt, wat in de volksmond ook gewoon DirectX wordt genoemd.

[Verwijderd]

Heb je zelf ooit met Direct-X gewerkt? Het is zeker veel meer als alleen een 3D renderer, het is een volledig framework wat heel veel werk van je overneemt.

Dat een game lastig multithreaded te maken is is natuurlijk een gegeven. Was het simpel geweest dan was dit artikel er niet geweest

Daarnaast zijn er zeker type games die er wel veel aan hebben zoals Olaf al terecht zei.

Ook gaan de meeste game programmeurs zich niet bezig houden met zaken als visible surface determination, dit laten ze over aan de ingekochte engine.

Ook die engines zouden ze beter multithreaded moeten maken.

[hansg]

99%? Get real. De dingen die serieus tijd kosten in moderne spellen zijn o.a. AI, collision detection, en physics - allemaal zaken die uitstekend in threads afgehandeld kunnen worden, en op applicatie nivo hun werk doen.

Renderen _lijkt_ misschien het zware werk, maar dat valt wel mee. De grafische kaart heeft het er maar druk mee, maar de CPU hoeft er niet vreselijk veel tijd aan te besteden. En grafische kaarten blinken nu toevallig al uit in parallelle operaties...

[SG]

Jep
De CPU moet wel voor elke frame het werk voorbereiden wat de GPU moet doen. Dit is ook intensief. De CPU is met de tijd zwaar ontlast maar GPU zijn dan ook tov CPU zo krachtig in hun toepassing. Dat de omvang van die voorbereiding task ook zeer geroeied is. Games zijn dus niet alleen GPU afhankelijk maar in een bepaalde verhouding CPU GPU afhankelijk wat nog eens afhankelijk is van de Game settings.
De Grafische last kan enigzins ingesteld worden. AI vaak niet. enkele games hebben AI sliders. de meeste niet.
'n CPU moet dus veel taken doen. Ook delegatie is een taak. Aangezien met delegatie naar special hardware voor die taak de laod ook 'n orde groter is.

Direct3D is één API voor één game module. de render module.
Server
AI
Net
Physics
render
(3D)Sound
Load

Quake 4 heeft laten zien dat met SMP De CPU toch veel kan betekenen voor games.
Maar die IDsoft games zijn vaak ook de meer redlijk CPU afhankelijke games.

Als games zeer GPU afhankelijk zijn zoals Fear. Dan denk ik. Waarom hebben ze zoveel CPU potentie laten liggen. Voor AI en Physics

De meeste nextgen gelicenceerde game engine ondersteunen SMP.
denk ook niet dat toepassing die aardig baat hebben aan SMP even gaan wachten op iNTel voor tools.
Unreal3engine
Crytek 2 engine
Zijn allemaal enigzins SMP supporting.

Die hebbendus zelf voor een thread save oplossing en load balancing gezorgd.

Ook zijn veel Game engine ook geschikt voor console Development en de
Xbox 360 met Triple core en 6 threads simultaan vretend is voor zijn ware potentie afhankelijk van goed SMP gebruik. Net zo als de PS3 Cell met 8 van die dingen.

Dus Crossplatform Games krijgen door console ondersteuning al snel te maken met 'n grote drang voor SMP.

[Olaf van der Spek]

Games hebben meestal van zichzelf niet heel veel te doen, het echte zware werk wordt gedaan door de onderliggende API.
Tegenwoordig dus eigenlijk uitsluitend Direct-X en OpenGL.

Eh? Volgens mij gaat er (bijvoorbeeld zeker bij RTS) redelijk wat tijd in zaken als AI en pathfinding zitten.

[Verwijderd]

Ik had het meer over het algemeen (de meeste veel verkochte spellen zijn first person shoot um ups).

Daarnaast is het bij een RTS niet echt nodig om een enorme framerate te hebben. Een RTS kan inderdaad met multithreaden wel een winst behalen. (En veel game programmeurs weten dat en zullen bij een RTS van te voren al multithreading opnemen in het ontwerp)

De Sims kan ook een flinke snelheidswinst behalen, toch denk ik niet dat ze daar de moeite gaan doen

[Maurits van Baerle]

Dit is best een boeiend stuk over Multi-threaded OpenGL op OS X:
http://www.macworld.com/n.../16/multithread/index.php

Inderdaad zou je dan als game developer zelf niet eens multi-threaded hoeven schrijven als je maar een API aanstuurt die dat wel doet en toch een aardige snelheidswinst behalen.

[.oisyn]

Fout. Dit zorgt alleen maar voor een snelheidswinst in de API zelf, niet in je game. Het is dus geen heilige multithreaded graal oid.

[ATS]

En een game is geen applicatie?

[Carbon]

Door deze aanpak is het nieuwe pakket van Intel geschikt voor verschillende compilers (Intel, Microsoft en GNU) en meerdere besturingssystemen (Windows, Linux en Mac OS X)

Ik heb net de eval versie bekeken.

Geen PPC support en geen sourcecode, maw voor het merendeel van de OSX ontwikkelaars is deze thread wrapper geen optie want die moeten voor de komende jaren zowel PPC als Intel ondersteunen.

[mashell]

Geen PPC support

En je vind dat je dat zou mogen verwachten van Intel?

[Carbon]

En je vind dat je dat zou mogen verwachten van Intel?

Als ze willen dat het daadwerkelijk gebruikt gaat worden onder MacOSX, eenduidig JA!

[mashell]

Tuurlijk is het een onbruikbare tool voor OS X als je universal binaries moet maken. Maar ik vind niet dat je van intel mag verwachten dat ze in een intel compiler legacy ondersteuning voor een compleet andere soort CPU van een andere fabrikant gaan stoppen. Bovendien, dit soort optimalisaties zitten al (of komen ook in) Xcode, toch?

[Carbon]

Maar ik vind niet dat je van intel mag verwachten dat ze in een intel compiler legacy ondersteuning voor een compleet andere soort CPU van een andere fabrikant gaan stoppen.

Compatibility
The Intel Threading Building Blocks are cross-platform (Windows, Linux, and Mac OS), support 32-bit/64-bit applications, and work with Intel, Microsoft and GNU compilers.

bron: http://www.intel.com/cd/s.../294797.htm#compatibility

Hoezo "intel compiler legacy ondersteuning"?
GCC wordt dus gewoon ondersteund!

[Verwijderd]

Persoonlijk gebruik ik liever pthread in C/C++ dan Java threading... zal wel aan mij liggen.

[sonix666]

Dat is dan echt jouw gemis. Ik heb sinds het ontdekken van de boost library (www.boost.org) nooit meer direct Windows of Linux threading APIs gebruikt. Ik zie ook niet in waarom dat dat nodig zou zijn. Enige minpunt op dit moment is dat je in de boost threading library nog niet de stacksize kunt aanpassen. Dat komt in de toekomst. Indien dat nodig is zul je de native APIs moeten gebruiken of de ACE library.

[defusion]

nouja, wat je in c singlethreaded maakt zal ongeveer hetzelfde draaien in java met threasing op een quad cpu bak

[Verwijderd]

En hoe wordt je performance van je threads dan?
Ik weet dat Microsoft LIbraries nou niet echt optimaal zijn om realtime berekeningen te doen.

En hoe stabiel zijn je applicaties als ze op een 1 core worden opgestart?

Kan deze library ook overweg met hyperthreading?

[Mr_Light]

instabiliteit mbt tot thread heeft eigelijk alleen met de programmeur te maken.

hyperthreading is een truukje aan de andere kant van het spectrum en heeft geen invloed op je programmeren, behalve dat het multithreaded moet zijn om effectief te zijn. Je programmeerd niet heel anders voor dual core of voor HT.

[Little Penguin]

Vanuit het standpunt van Intel is het natuurlijk heel belangrijk om, nu de (Intel) multi-core processoren standaard worden, er voor te zorgen dat zo veel mogelijk programma's hier mee overweg kunnen - wat dat betreft begrijp ik dus niet waarom men er toch geld voor vraagt.

Overigens zijn de crossplatform C++ libraries NSPR (waar vooral Mozilla producten gebruik van maken) en de APR (waar Apache producten gebruik van maken) beiden reeds voorzien van hulpmiddelen om van threads gebruik te maken.

[feelthepower]

Is dit dan gewoon de nieuwe verzameling ICC (intel compiler collection) of staat dit er los van?
Ik dacht zelf losstaand, dit lijkt me op programmeer niveau, terwijl de ICC een verzameling compilers is. Ik dacht dat intel een compiler had ontwikkeld die gebruik maakt / kan maken van "hulp-threads" weet iemand hoe het daar dan mee staat?

[stewie]

een beetje zoals IBM's octopyler voor de cell?