NEC: multicore-optimalisatie kan automatisch

Het Japanse NEC zegt technologie te hebben ontwikkeld die software automatisch in een aantal parallelle draden op kan splitsen. Parallellisatie is van groot belang voor een optimale benutting van multicoretechnologie, en bestaat aan de software-ontwerpkant uit het specificeren hoe berekeningen van andere berekeningen afhangen. De softwarewereld zou zich hier voor nieuwe software veel te weinig mee bezig houden; voor bestaande software is het probleem dat het parallelliseren een tijdrovende klus is, vooral bij oudere (vaak slecht gedocumenteerde) code. NEC's technologie, die hardware-embedded is, gaat aan de hand van profiler-informatie op zoek naar parallelisatiepatronen in de assemblycode en hercompileert de code voor het gebruik op een multicoreprocessor. De technologie maakt hierbij gebruik van een 'veiligheidsnet' om zo nu en dan optredende missers af te vangen, waardoor de correctheid van de programma-executie gegarandeerd zou kunnen worden terwijl het algoritme radicale beslissingen kan nemen om zoveel mogelijk parallellisatie te bewerkstelligen.

Volgens NEC gaat het om de eerste praktisch toepasbare multicore-optimalisatietechnologie. De tijd die gaat zitten in het berekenen van de parallellisatie en het eventueel heruitvoeren van ten onrechte opgesplitste draden zou teniet worden gedaan door de tijdwinst in de algehele programma-executie. Het bedrijf noemt een geval waarin een persoon vier maanden nodig had om een stuk software handmatig aan te passen, terwijl het algoritme slechts drie minuten nodig had om de code om te vormen. De automatisch aangepaste versie zou daarnaast bijna driemaal zo snel draaien als de onaangepaste versie, terwijl de handmatige aangepaste code slechts ongeveer tweemaal zo snel was. NEC zet het onderzoek voorlopig voort; het is nog onduidelijk wanneer het met de eerste producten komt die de technologie huisvesten.

Reacties (53)

Helemaal mee eens!

Helaas leven we in een kapitalistisch stelsel.
Eerder op de markt is belangrijker dan kwaliteit en snelheid.

Het credo is tegenwoordig: we patchen achteraf wel!
Mijn tenen trekken er regelmatig krom van!

Ik verlang terug naar m'n commodore64 en ZX-Spectrum. Toen was alles in assembly gemaakt en naar verhouding retesnel.

En de beste software kwam uit de landen waar ze het minste geld hadden en dus creatief MOESTEN zijn.

Ik wil best wel een paar maanden wachten op een game en iets meer betalen, i.p.v. naar de winkel rennen voor een nieuwe videokaart.

Ik heb dan ook besloten niet meer aan deze gekte mee te doen. Het scheelt je een hoop pegels!

Hear hear!
Als je tegenwoordig iets nieuws koopt (hardware of software, maakt niet uit) moet je eerst het internet op om te zoeken naar updates of patches ... vroeger heetten dat prototypes

Nou je het zegt, zit wel iets in.

Neem bijv. Sata, minimale performance verbeteringen. Daar zaten we echt op te wachten. En dan die eerste brakke aansluitingen erbij, hoe verzinnen ze het. Of PCI-Express, dat hadden we ook echt nodig. AGPx8 werd/word nog amper 100% benut, maar daar is de nieuwe bus al. Oja, die doet ook SLI ! Leuk voor die 2% die daar ook echt aan begint. Hadden ze ook echt niet in een soort APG-x8 Pro ofzo kunnen doen ? (backwards compatible).

Tuurlijk niet, dat verdient te weinig. Kom met dingen die mensen niet nodig hebben en maak vooral duidelijk dat ze het moeten hebben, NU

Wat ik ook niet snap, hoe kunnen die brakke condensators nou ineens weer boven komen drijven.
Leren ze dan echt nooit van gemaakte fouten in het verleden

Neem bijv. Sata, minimale performance verbeteringen.

Dat is niet de belangrijkste feature van SATA. Veel belangrijker zijn de dunne kabels, de veel kleinere ruimte die een connector inneemt (op het moederbord en op de drive) en zo.
Idem voor PCI-Express, dat is niet alleen een vervanging voor AGP, maar ook voor gewoon PCI.

Voor beiden is verder nog een voordeel dat het minder pinnetjes op de chip kost (ook een kostenfactor).

Bovendien zat ATA zo ongeveer aan de top van zijn kunnen met 133 MB/s en biedt SATA nog mogelijkheden om verder te gaan.

De eerste SATA bood dus bijzonder weinig, behalve de dunne kabeltjes.... ik bedoel maar. We doen al tien jaar + met flatkabels, alsof die dunne kabels nou zo nodig waren (niet dat het niet handig is hoor, daar gaat het niet om).

Dat PCI-Express ook voor de gewone PCI een vervanger is mooi, dat verandert nog niets aan het AGP verhaal.

Bovendien: uberkaarten gebruiken de PCI-Express bus nog steeds minimaal; 256/512 MB onboard videogeheugen met 256/512bits transport maken dat nml. overbodig. Wat ook al gelde voor AGP.

Wat me stoort is de haast om deze technieken op de markt te zetten, technieken die vaak nog niet af zijn.
Nuja, dit zijn maar pc-onderdelen. Kijken of je dat zo leuk zou vinden met je nieuwe auto

Tuurlijk niet, dat verdient te weinig. Kom met dingen die mensen niet nodig hebben en maak vooral duidelijk dat ze het moeten hebben, NU
Dat komt ook door de markt hoor. Mensen willen steeds iets nieuws, snellers, mooiers. Of ze het dan wel of niet nodig hebben is weer een heel ander verhaal.

Hoewel het natuurlijk een beetje kip-en-ei verhaal is. Wil de consument sneller, mooier, nieuwer omdat het er is, of wordt er steeds verder ontwikkelt om te kunnen voldoen aan de vraag?

met de plannen van Intel en AMD om het aantal cores ipv het aantal MHz bij elke generatie te verdubbelen , zou dit wel eens HET "ei van colombus" kunnen zijn.

immers in 2007 zou intel met een zogenaamde Quad-core (Bloomfield) uitkomen en in 2008 met een dubbel Quad-core (Yorkfield en Harpertown) nieuws: Intel onthult plannen voor 4-core en 8-core desktopchips


uiteraard moet je zo'n nieuws altijd met de nodige scepsis behandelen: men spreekt immers van manueel 1.95x sneller op een quad-core en automatisch 2.83x sneller. de vraag is natuurlijk of men niet een speciale case eruit heeft genomen om hun gelijk te halen. want bij mijn weten kan er manueel wel hogere ratings gehaald worden.

dat hangt natuurlijk ook af van de kwaliteiten en het geduld van de programmeur

In principe is een programma geschreven in assembly het efficiënst geschreven; de programmeur kan mits kennis en geduld élk stapje gaan optimaliseren. Maar dat is niet te doen: te veel werk.
Vandaar dat er gewerkt wordt met andere talen en compilers, die de code vertalen naar assembly en hierbij gegarandeed niet 100% efficiënt zijn. Maar dat is niet erg: performance hebben we meestal genoeg, en liever een programma dat klaar is en 2% trager is dan een dat nooit klaar zal geraken!
Dat een gelijkaardig iets nu ook kan voor dual core optimalistaie is prachtig!

Microsoft zal dit wel fantastisch vinden die 8 core processoren.
En Als NEC slim is verkopen ze de licentie ook per Core.
Kunnen ze flink wat geld aan verdienen.

Microsoft zal dit wel fantastisch vinden die 8 core processoren.
En Als NEC slim is verkopen ze de licentie ook per Core.
Kunnen ze flink wat geld aan verdienen.

Microsoft heeft vorig jaar al aangegeven dat de licenties per processor worden gerekend in plaats van per core.

Bedrijven kunnen tussen nu en 5 jaar het echt niet meer maken om per core te rekenen. Aangezien de concurrentie dat ook niet doet en klanten anders dus voor de concurrentie gaan kiezen.. (aangezien ik echt wel aan zie komen dat er over 5 jaar 16+ core processors zijn)

Microsoft heeft vorig jaar al aangegeven dat de licenties per processor worden gerekend in plaats van per core.
Hou er wel rekening mee dat het beleid van vorig jaar niet per se het beleid van komend jaar hoeft te zijn...

[disclaimer]
Licenties uit het verleden bieden geen garantie voor de toekomst.
[/disclaimer]

Theoretisch gezien zou volgens mij het manueel paralliseren inderdaad sneller moeten zijn jah omdat dan het parallellisatie algoritme niet hoeft uitgevoerd te worden. Dit geld dan echter alleen als de code zo optimaal mogelijk geoptimaliseerd is, en aangezien programmeurs ook nog steeds mensen zijn, acht ik de kans groot dat niet alle cores op elk moment evenveel belast zullen worden. Ik denk daarom dat de multicore-optimalisatietechnologie van NEC voorlopig sneller zal zijn dan het manueel paralliseren.

Inderdaad, maar je moet natuurlijk ook rekening houden met de CPU-cycles die dat bijkomende algoritme nodig heeft. Als je bvb daarvoor een aparte CPU moet gaan installeren zodat (n-1) CPU's optimaal worden gebruikt, dan zou ik toch mijn eieren niet teveel in die ene mand leggen.

ze kunnen hun eigen code dan ook voor n-1 processoren optimaliseren...

maw: in theorie zou het snelheidsverlies bij het opschalen van de cores minimaal moeten zijn.

Ik denk dat jij een fout maakt! Vergeet niet dat ja manueel apart moet herprogrammeren voor het aantal cores dat er is terwijl hier in de automatische versie geen rekening mee hoeft te worden gehouden daar dit al is ingebakken. Deze kijkt namelijk naar het aantal cores en splitst daar de programma's op. De manuele methode betekent dat je eerst dit moet doen voor een dual core dan apart weer voor een quad core daarna voor een octa core dan een hexadeca core enz enz!

De manuele methode vergt veel vooraf werk terwijl de automatische code on-the-fly kan worden gedaan. Dit levert dus altijd tijdswinst op!

Ter vergelijking: probeer maar eens een 5 voudige vergelijking met 10 variabelen uit te rekenen en dit dan voor 200 verschillende beginwaarden. Als je hier een programma voor hebt dan hoef je alleen maar je beginwaarden in te geven en de rest gaat automatisch en veel sneller dan jij met de hand voor elkaar krijgt!

Dit geldt hier net zo goed! Als de code goed is dan is de foutmarge ook veel kleiner dn wanneer iemand dit met de hand moet doen. Een programma krijgt namelijk geen last van vermoeidheid, dorst, honger en hoeft niet naar de WC! Probeer dat als mens maar eens uit te houden!

Dat denk ik dus ook, maar dan toch anders: ik denk dat het (tenminste zo zou ik het doen) manueel herprogrammeren gewoon zorgen dat het programma het maximale haalt uit de aanwezige cores, bv door het maximaal te paralleliseren, en de (op een gegeven moment tijdens executie) "actieve" parallele taken te laten verdelen over de aanwezige cores door het os of zo. Zo programmeer je in ieder geval NrCores onafhankelijk, en daardoor meer hardware onafhankelijk (zoals het hoort).

De automatische optimalisatie is misschien wel te cachen oid, zodat die 3 minuten alleen de eerste keer dat het programma opgestart wordt nodig zijn.

met de plannen van Intel en AMD om het aantal cores ipv het aantal MHz bij elke generatie te verdubbelen , zou dit wel eens HET "ei van colombus" kunnen zijn.

1 miljoen Z80's op één chip.

Laten we het bij 65536 houden, en het "the connection machine" noemen.... rings a bell ?

De automatisch aangepaste versie zou daarnaast bijna driemaal zo snel draaien als de onaangepaste versie, terwijl de handmatige aangepaste code slechts ongeveer tweemaal zo snel was.

Dan was er dus sprake van meer dan 2 cores. ff gecheckt:

in addition, the application program that has been parallelized manually runs 1.95 times faster with four processors than the original application program running with one processor. However, the application program that has been parallelized automatically runs 2.83 times faster with four processors

Interessant, ik vraag me af of zoiets uiteindelijk in de processor zelf kan worden opgenomen, hoewel je dan wel iets moet inbouwen voor software die al geoptimaliseerd is, anders gaat hij die ook weer optimaliseren

Alsof dat erg is...
wie weet krijgt dat "chipje" het voor mekaar om het nog verder te optimaliseren

edit: typo

Ik zit niet te wachten op een systeem waar software on the fly wordt geoptimaliseerd, dat gaat veel te veel tijd kosten bij het inladen/starten. Je kan dit soort optimalisaties prima eenmalig doen, en dan in vervolg de geoptimaliseerde versie gebruiken.
On the fly? ik zie de toegevoegde waarde (nog) niet.

Dit is denk ik wel de toekomst. Bijvoorbeeld alle software wordt in byte-code geleverd (Java, .NET of nog iets heel anders) en wordt optimaal voor jouw processor JIT gecompileerd en eventueel geparalelliseerd specifiek voor jouw hardware. Mogelijk daarna op de harddisk in een cache opgeslagen, zodat het alleen de eerste keer hoeft te worden geJIT.

En of het dan in de processor zelf gebeurt (in hardware), of in software die op de processor draait, doet er in feite niet toe.

Toch blijft het zo, dat wanneer je je eigen code goed schrijft er meer rendement uit te halen valt! Software schrijvers zouden wat mij betreft eens wat vaker optimalisatie moeten toepassen, ipv te wachten op een nog snellere processor.

Nja, aan de andere kant is je tijd natuurlijk waardevol. Je code wordt evengoed sneller als je een jaar wacht op een nieuwe processor dan als je een jaar aan optimaliseren besteed voor dezelfde processor. Wat zou jij doen?
In deze tijd is het nauwelijks waard specifiek te optimaliseren voor specifieke hardware, want deze zijn al achterhaald tegen de tijd dat ze uit zijn.

Het goede algoritme gebruiken maakt veel meer uit dan het verschil tussen een P3 en P4. Als je een kwadratisch algoritme gebruikt ipv lineair, dan zal je met alle optimalisaties van de wereld niet snel genoeg worden.
Ik ben met je eens dat je niet verder moet gaan optimaliseren. Daar heb je compilers voor, toch? Hebben die ook nog wat te doen

Nee, natuurlijk moet je niet proberen het werk van je compiler over te nemen. Wat ik bedoel is dat het toch wel beter zou zijn, als meer software ontwikkelaars uberhaubt eens gebruik gaan maken van threading.... Daar zit de snelheidswinst! En als je meteen begint met de juiste code te schrijven, kost het dus helemaal niet meer tijd. (Soms kost het zelfs minder, omdat je gewoon betere code schrijft)

Ik vraag het mij af. Als je ooit de handleidingen van bv Intel gelezen hebt over hoe je moet optimaliseren voor, om maar een CPU te noemen, de XScale weet je minimaal 3 dingen.
- Het werkt eigenlijk alleen optimaal met de Intel C++ compiler. Gnu C++ en MS C++ compiler ondersteunen de speciale commando's niet allemaal.
- Het hangt allemaal sterk af van de eigenschappen van de CPU waarvoor je optimaliseert.
- Het zit hem in de details.

Optimalisaties die fantastische resultaten op de ene chip opleveren, werken soms voor geen meter op een andere, compatibele, chip. Automatische optimalisatie kan de code aanpassen aan de chip waar die op dat moment op draait en kan rekening houden met alle zaken die voor optimalisatie van belang zijn. Dit kan best wel eens betere resultaten geven dan een oplossing die op alle processors die een bepaalde instructieset gebruiken moet werken.

Dat is interessant. NEC gaat de productie van de Unisys ES7000 overnemen (zie http://www.unisys.nl/abou...s_a_events/2005261001.htm) maar vooralsnog niet het 'ontwerp'. Met zulke doorbraken, gecombineerd met de technologie van Unisys, krijg je leuke mogelijkheden!

Die site is zo goed als /. hehe, zouden dat allemaal tweakers zijn?

Wat bedoel je?

http://nl.wikipedia.org/wiki/Slashdot

Slashdot is roemrucht om zijn eigenschap veel websites genadeloos lam te leggen, het zogenoemde slashdoteffect.

Je zou zeggen dat handmatige parallelisatie sneller zou zijn.
maar goed, eerst zien dan geloven

Hangt er natuurlijk vooral vanaf wat je aan het optimaliseren bent.
Als het een gedocumenteerd stuk software is, of iets wat je zelf hebt geschreven dan is dat wel voor de hand liggend, maar als het een stuk ranzige oude assembly is waarvan je op zich niet eens snapt wat het doet, dan geef ik het je nog te doen.
En dat is natuurlijk precies de kracht van deze oplossing: NECs tool hoeft niet opnieuw te ontdekken wat de code eigenlijk doet op een hoger niveau, wat een progger juist wel moet.

Gezien optimaliseren tijd kost en het programma toch wel draait, zal een bedrijf hier niet snel in investeren.
Kosten/baten plaatje he....
Ongeacht de wens van gebruikers/ontwikkelaars.

Dus een tool die dit automatisch doet is dus zeer welkom.

Tijd is geld. Als jij een programma schrijft wat een taak uitvoert in 3 uur, en de concurrent kan het door multicore goed te benutten in 1 uur en 40 minuten, dan kun je al raden welk programma de voorkeur verdient (mits de prijzen een beetje gelijk liggen).

Als het eerste programma enkele maanden eerder op de markt is maakt het 2de niet veel kans meer op overleven. Overstappen van software doet men zo goed als nooit (waarom werkt iedereen anders nog met windows...) want de gebruikers zijn het gewoon.
Dus snel klaar en vol fouten en traag brengt meer op dan perfectionistisch en snel. (en dat laatste is meestal nog gratis ook)

Mischien een niet al te slimme vraag: Wat is het verschil tussen deze optimalistatie en de optimalisatie die je gebruikt voor grid computing? Ik dacht dat daar al heel erg volwassen optimalistatie technieken voor bestonden. Het is toch niet zo dat je met het handje voor duizenden processoren de optimale benutting moet gaan zitten bedenken?

Hoe lang is de wetenschap, dus op universitair nivo, daar al niet mee bezig.....

Bij Grid computing is er meestal sprake van grote simulaties aan bijvoorbeeld een kubus gevuld met atomen. Wat er dan gebeurt is dat de kubus in een root aantal gelijke stukjes wordt gehakt en dat elke node z'n eigen stukje gaat uitrekenen. Ze communiceren onderling constant over de tussenresultaten omdat die stukjes in de kubus elkaar beïnvloeden.

De softwarepakketten die dit regelen zijn vanaf het begin af aan al gebouwd om parallel te rekenen. Dat is dus een heel andere situatie dan een programma dat al af is gaan optimaliseren voor multi-processors.

Zag gisteren een programma dat dit voor after effects doet.
Als dit dus softwarematig kan voor AE, is Nec niet de eerste met dit soort plannen.

Dit is een totaale andere manier naar parallel, bij beeldbewerkings programma's word de code niet veranderd/opgedeeld. Maar word het plaatje gewoon in 2,4 of 8 stukken geknipt, waarbij elke core de zelfde (oude) code draait alleen dan op dat gedeelte van het plaatje.

Vandaar dat je dit programma gewoon als plugin installeerd, het is ook alleen toepasbaar op graphische programma's...