Intel introduceert servicepack voor Parallel Studio

Tijdens zijn Software Media Day heeft Intel een servicepack voor Parallel Studio aangekondigd. De software wordt gebruik om software voor computersystemen met een groot aantal cores of processors te schrijven.

Het schrijven van software voor computersystemen met een groot aantal processors, cores of combinaties daarvan stelt ontwikkelaars voor een aantal problemen, waaronder het zo efficiënt mogelijk gebruikmaken van de beschikbare rekenkracht. Het ontwikkelen van software die is geoptimaliseerd voor verdelen van taken over de beschikbare cores in hpc-systemen of many-core-computers en clusters, is onder meer met Intels Parallel Studio XE 2011 mogelijk. Voor dat softwarepakket heeft Intel nu een servicepack uitgebracht.

Het upgradepakket voor Parallel Studio XE 2011 verbetert de schaalbaarheid van het aantal cores dat instructies kan verwerken. De compilers zouden bovendien een stuk sneller zijn dan voorgaande versies: volgens Intel-engineer James Reinders zouden integer- en floating-point-C++-compilers en Fortran-compilers respectievelijk 47, 21,en 27 procent sneller zijn geworden. Tevens zijn een aantal nieuwe standaarden toegevoegd.

De nieuwe standaarden betreffen versie 4.0 van Intels Threading Building Blocks. Deze door Intel ontwikkelde opensourcespecificatie werkt samen met Cilk Plus: samen maken de standaarden taken geschikt voor parallelisme om deeltaken beter over cores te verdelen. De nieuwe versie van Parallel Studio XE 2011 met SP1 kost voor Linux 2249 dollar; een Windows-versie kost 1899 dollar.

Interessant detail van de nieuwe compilers die Intel in zijn Parallel Studio gebruikt, is de ondersteuning voor een decimale representatie van floating point. De meeste floating-point-getallen zijn repeterende getallen, maar zijn dat niet in binaire vorm. Zo wordt het decimale 0,1 in binaire representatie als 0,00011001100110011... voorgesteld. De herhaling leidt tot afrondingsfouten. Deze techniek wordt vooralsnog alleen in software ondersteund, maar in toekomstige versies van Intel-processors zou het, net als bijvoorbeeld IBM al doet, in hardware ondersteund worden.

Reacties (13)

[TD-er]

Zo wordt het decimale 0,1 als 0,0001100110011011... in binaire representatie voorgesteld. De herhaling leidt tot afrondingsfouten. Deze techniek wordt vooralsnog alleen in software ondersteund, maar in toekomstige versies van Intel-processors zou het, net als bijvoorbeeld IBM al doet, in hardware ondersteund worden.

Wij stappen binnenkort over op deze compiler van Intel, maar goed om te weten dat alle effort die de laatste tijd bij ons in de math-lib gestopt is om dergelijke afrondfouten te minimaliseren (oa. door de Kahan summing te gebruiken en dergelijke) mogelijk nog een keer nodig is om alles na te lopen.
* TD-er zal de komende tijd wel even over wat unit tests na gaan denken.

Dat pakket van Intel is trouwens niet alleen handig voor gebruik met veel processoren. Je kunt ook al redelijk wat winst halen met een paar cores, zoals in de desktop-PC van tegenwoordig, doordat je met minimale programmeer-effort dingen parallel kunt uitvoeren.
Een for-lus kun je gewoon hernoemen en dan zal de compiler de code in de lus zoveel mogelijk parallel uitvoeren.

[MSalters]

Je hoeft je bestaande code niet na te lopen. Ten eerste zijn dit nieuwe types, naast de bestaande float/double. Je bestaande code gebruikt die niet. Ten tweede klopt het hele vehaal over "afrondingsfouten" niet echt. Decimale floating-point systemen hebben even goed afrondfouten, alleen met andere getallen. Je kunt maximaal 4 miljard getallen representeren met 32 bits, en andere getallen moeten afgerond worden. Ten derde wekt Kahan summing ook gewoon met decimale floating point; het algoritme is exponent-onafhankelijk.

[ipaqlinux48]

HEt .Net framework bezit ook al een framework PLINQ (parallel LINQ) om op een vrij eenvoudige manier .Net software te schrijven die ook meerdere cores/threads gebruikt.

Het is logisch dat programmeurs hun software steeds multi-threaded moeten gaan schrijven omdat de GHz wedstrijd enkele jaren is stilgevallen. In de nabije toekomst zitten we wellicht met 256 cores/CPU. Elk process binnen een OS zijn eigen dedicated core.

[TD-er]

De GHz race is dan wel sinds 2001 zo rond de 3 GHz stil komen te liggen, maar leg eens een Core i7 Sandy Bridge naast een Pentium 4, beide op 3 GHz en dan is die Sandy Bridge toch echt een stuk sneller met 1 core.

Een hoop taken kun je trouwens al prima splitsen. De UI wil je bijvoorbeeld wel in een aparte thread hebben tov de rest en dat gaat ook prima met bijvoorbeeld Qt.
En zo zijn er best wel veel dingen die redelijk makkelijk te splitsen zijn.
Hardware I/O wil je vaak ook in een aparte thread en dan een buffer ertussen en wat simpele gates eromheen om aan te geven of er nieuwe data is.

Voor de liefhebber wat leesvoer over non-locking buffers (in volgorde van verschijnen):
Lock-Free Code: A False Sense of Security
http://drdobbs.com/cpp/210600279

Writing Lock-Free Code: A Corrected Queue
http://drdobbs.com/high-performance-computing/210604448

Writing a Generalized Concurrent Queue
http://drdobbs.com/high-performance-computing/211601363

Measuring Parallel Performance: Optimizing a Concurrent Queue
http://drdobbs.com/cpp/212201163

[.oisyn]

Een hoop taken kun je trouwens al prima splitsen. De UI wil je bijvoorbeeld wel in een aparte thread hebben tov de rest en dat gaat ook prima met bijvoorbeeld Qt.
En zo zijn er best wel veel dingen die redelijk makkelijk te splitsen zijn.

Alleen heb je meestal geen drol aan een dergelijke splitsing wat performance betreft. Dat je de UI in een aparte thread wil is omdat dat handige werkt en de UI dan responsive blijft als er op de achtergrond werk verzet moet worden (en eigenlijk doe je dat werk dan ook op een aparte thread, niet de UI, maar goed, het is maar net van welke kant je het benadert ). De UI thread staat 99,9% van de tijd toch te idlen, en daarom biedt het wat performance betreft geen enkel voordeel om die in een aparte thread te zetten.

Parallel programming is ook niet simpelweg "meerdere threads gebruiken". Als je écht multicore wilt programmeren dan zul je je algoritmen zo moeten ontwerpen dat ze van meerdere cores tegelijk gebruik kunnen maken. Dat doe je door het te verzetten werk op te delen in kleinere workloads die parallel aan elkaar uitgevoerd kunnen worden. Op een hoog niveau zijn ze dan feitelijk nog steeds serieel, maar alle cores werken mee aan het resultaat, dus de daarwerkelijke implementatie is parallel. En daar zijn libraries als Intel's Thread Building Blocks handig voor.

[Reactie gewijzigd door .oisyn op 29 juli 2024 04:26]

[TD-er]

De UI thread staat 99,9% van de tijd toch te idlen, en daarom biedt het wat performance betreft geen enkel voordeel om die in een aparte thread te zetten.

Ligt er maar net aan wat je onder 'performance' verstaat.
In mijn werk is dat veelal zorgen dat de applicatie rap blijft reageren en dat je real-time deadlines kunt blijven halen (vandaar ook hardware-I/O in andere thread).
Als het gaat om meer te kunnen uitvoeren in dezelfde tijd, of minder tijd kwijt zijn voor hetzelfde werk, dan moet je inderdaad het werk verdelen.
Ook dat kun je op meerdere manieren doen.
- algoritme zo opzetten dat er een hoop rekenwerk vooraf verdeeld wordt en achteraf bij elkaar komt.
- taken sequentieel opdelen in een hoop kleine taken die je als een pipeline gaat uitvoeren en elke aparte pipeline stap kan dan op een eigen thread draaien. Nadeel is dat je wel een latency krijgt. Voordeel is dat je dingen nog steeds realtime kunt doen.

Dat laatste heb ik bijvoorbeeld mee te maken in mijn werk.
1) frame komt binnen (USB-communicatie thread)
2) frame moet worden geanalyseerd.
3) frame moet verwerkt worden tot een RGB-formaat
4) frame moet mathematisch geanalyseerd worden om dingen te herkennen.

Stap 1 en 2 duren even lang per frame, maar 3 en 4 duren langer (2 - 3x zo lang)
Echter heb je heel veel van dat soort frames, dus is het prima te schedulen over 6 - 8 threads. Meer threads zal in dat voorbeeld geen zin hebben, tenzij ik bijv stap 3 en 4 onderverdeel in kleinere taken.
Echter nu hoop ik dat die stappen beter te parallelliseren zijn door de Intel compiler, want als ik er zelf mee bezig moet, kost dat gewoon erg veel ontwikkeluren terwijl de Intel compiler daar hopelijk vrij simpel winst weet te halen.

[.oisyn]

Ligt er maar net aan wat je onder 'performance' verstaat.

Het soort performance waar deze compiler suite en library waar het artikel over gaat een hoop bij gaat helpen. De voorbeelden die jij gaf (UI en IO in aparte threads) zijn daarvoor juist totaal weer niet interessant, dan kun je prima uit de voeten met de threading API van het OS.

[Reactie gewijzigd door .oisyn op 29 juli 2024 04:26]

[.oisyn]

In de nabije toekomst zitten we wellicht met 256 cores/CPU. Elk process binnen een OS zijn eigen dedicated core.

Zodat een applicatie nog steeds singlecore is en de overige 255 cores uit hun neus staan te eten omdat die processen simpelweg niets te doen hebben? Niet echt handig dus . Je wil dat alle applicaties van alle cores gebruik kunnen maken, dan wordt de workload zo efficient mogelijk verdeeld.

[MSalters]

Dat is nu nog wel het geval. Maar er is een goede reden om te verwachten dat het kan veranderen. Nu moet je bij een context switch alle state uit de core vervangen. Dat is op zich niet nuttig, en produceert behoorlijk wat warmte.

Als je technologie het toestaat om veel cores te maken, maar de TDP het niet toestaat om ze allemaal tegelijk te runnen, dan kan het verstandig zijn om een zwik extra cores op een CPU te plakken en maar een selectie daarvan actief te maken. Je voorkomt daarmee context switches en extra warmteproductie.

[Memori]

Is dit niet ongeveer hetzelfde wat OpenMP doet?

[.oisyn]

Min of meer. OpenMP maakt het makkelijker om for-loopjes automatisch te parallelliseren, maar dat is het dan ook wel. Intel biedt een library die je ook in staat stelt zaken te synchroniseren, resultaten te combineren vanaf meerdere threads, etc.

[.oisyn]

Zo wordt het decimale 0,1 als 0,0001100110011011... in binaire representatie voorgesteld. De herhaling leidt tot afrondingsfouten.

Tja, persoonlijk zie ik niet zoveel nut in decimale representaties, behalve als je echt werkt met currencies, maar daarvoor wil je weer geen drijvendekommagetal gebruiken. Leuk dat menselijke invoer dan wel goed te representeren is, maar zodra je ermee gaat rekenen krijg je hoe dan ook afrondingsfouten. 10/3 is in het decimale stelsel ook niet zonder herhaling te representeren.

[Verwijderd]

Ik vind het wel zeer toevallig dat AMD net de eerste Bulldozer CPUs de deur heeft uitgezonden, en dat Intel nu op dat moment met een ServicePack uitkomt voor software die vooral van toepassing is op de markt waar de Bulldozer CPU voornamelijk voor bedoeld is (HPC/etc).

Het is niet de eerste keer dat een compiler er voor zorgt dat de benchmark resultaten in een verkeerd daglicht komen te staan. Intel is hier zelfs al vroeger van beschuldigt en als mijn geheugen me niet in de steek laat, zelfs schuldig voor verklaart.

Tuurlijk zitten er verbeteringen in deze Service Pack die ook een AMD CPU gebruiker goed van pas zullen komen, maar het zou me niks verbazen als Intel dit moment tevens gebruikt om hun CPU iets beter naar voren te schuiven. Op die manier geven ze zichzelf wat ademruimte voordat ze zelf uitkomen met een nieuwe architectuur.