IDF: Intel bouwt javascript-extensie voor parallele dataverwerking

Intel heeft op de IDF onder de naam River Trail nieuwe extensies voor javascript aangekondigd die de scripttaal parallel taken laat afwerken op multicore-processors. De River Trail-code is door de chipfabrikant opensource gemaakt.

Volgens Intel is javascript, dat onder andere wordt gebruikt voor het draaien van webapplicaties, niet efficiënt genoeg omdat het geen toegang geeft tot meerdere cores op een moderne processor. River Trail, momenteel beschikbaar als een Firefox-extensie, moet daar verandering in brengen.

Intel meent dat River Trail het voor ontwikkelaars mogelijk maakt om javascript-code toegang te verschaffen tot meerdere cores waardoor taken parallel verwerkt kunnen worden, waaronder vector-instructies. De javascript-extensie zou onder andere gebruikt kunnen worden bij toepassingen die html 5 en de grafische opmaaktaal WebGL gebruiken.

Helaas!
De video die je probeert te bekijken is niet langer beschikbaar op Tweakers.net.

Op de IDF toonde Intel een particle demo waarbij River Trail dankzij parallele javascriptcode tot vijftien maal sneller zou presteren dan de huidige javascript-implementaties die code serieel verwerken. Intel gebruikte daarbij een processor met acht cores.

Intel heeft de broncode van River Trail online gezet en het een opensource-licentie meegegeven. Ook wil de chipfabrikant zijn extensies voordragen bij Ecma International, de standaardenorganisatie die over de javascript-standaard waakt. Onder andere Mozilla zou al zijn steun hebben toegezegd aan het Intel-initiatief.

Reacties (38)

[TheNameless]

Om te zeggen dat Javascript geen gebruik kan maken van multi-core systemen is niet helemaal waar.
Sinds de introductie van Web-workers, is het wel mogelijk om bepaalde zaken op een aparte thread te draaien.
Nadeel is alleen dat wat je er mee kan doen vrij beperkt is, omdat je bijvoorbeeld niet bij de DOM kan komen vanuit zo'n worker

[Verwijderd]

Dat geeft helemaal niet, je kunt nog steeds wel "DOM jobs" schedulen vanuit een worker welke dan sequentieel uitgevoerd kunnen worden. Als je veel DOM acties wilt uitvoeren dan is het hele idee van parallelisatie verdwenen, maar het is nu niet meer dan logisch om slechts met 1 thread tegelijk de DOM te beheren. Als je echt superintensief de DOM wilt lezen/ bewerken, dan ben je uberhaupt niet goed bezig me dunkt. Tenminste, ik kan me geen voorbeeld bedenken waar je dat zou willen boven een andere oplossing.

[MSalters]

Je hebt maar 1 DOM, dat is het fundamentele probleem. Als je bijvoorbeeld een app bouwt met meerdere outputvelden, dan kun je niet elke thread z'n eigen outputveld geven.

[Squee]

Een ex-collega van mij werkt hier ook aan bij Intel Labs. Hij heeft een video op youtube staan waar hij nog iets meer over de details van deze technologie verteld, met ook nog een demo;

http://www.youtube.com/watch?v=Ps_1ptUFuUo
(Hij heeft ook een iets minder vervelende stem dan de video hierboven )

Hier zie je ook duidelijk dat er meer cores benut worden omdat ze de taskmanager tegelijkertijd open hebben staan. Wel een goeie ontwikkeling, dat data-parallel javascript

Edit: en nog een bijgaand artikeltje van hem;
http://blogs.intel.com/research/2011/09/pjs.php

[Reactie gewijzigd door Squee op 28 juli 2024 02:09]

[84hannes]

Ik heb in mijn leven weinig JavScript hoeven schrijven, maar begrijp van veel mensen dan het een verveldende gebeurtenis is. Het feit dat parallel gebruik van meerdere cores ook nog niet beschikbaar is steunt mij in de gedachte dat JavaScript nog wel eens niet de ideale taal is voor moderne, immersive als je Microsoft's buzz word wilt gebruiken, applicaties. Er zijn in mijn ogen twee mogelijkheden

• Andere talen in browsers implementeren (chrome native client, een Java/.net runtime, Ruby in je browser etc.)
• Haast maken met het verbeteren van de JavaScript taal (dus niet allen betere interpreters, maar echt nieuwe functionaliteit, al dan niet backwards compatible

Fijn om te zien dat Intel aan dat tweede punt werkt.

[Dreamvoid]

Achteraf gezien is het misschien niet de beste beslissing geweest van Netscape om ooit, lang geleden, juist JavaScript in de browser toe te laten en waren we beter af geweest als ze een moderne taal als Java of C# hadden gekozen.

Maar de praktijk is helaas dat het te laat is om nog terug te gaan, en elke keuze voor een betere nieuwe native webtaal wordt een mega politiek gevecht. Java in de browser leek ooit de toekomst (JS voor simpele scripting, Java voor apps), maar Sun heeft het verknoeid en Microsoft, Google, Apple en Mozilla hebben uiteindelijk Java (als client-side platform) met zijn vieren de nek om gedraaid. C# in de browser: objectief misschien wel het beste, maar anno 2011 gunt niemand MS zo'n overwinning. Google's nieuwe Dart taal? Wie weet, maar Google moet flink gaan lobbyen bij Mozilla, MS en Apple om dat erdoor te krijgen. En ActionScript? Tsja...Adobe heeft waarschijnlijk nog minder fans dan Microsoft op dit moment.

Nee, de 'least worst' lijkt te zijn: fix zoveel mogelijk tekortkomingen van JS, en leer ermee leven. Het is misschien niet ideaal, maar het is het enige dat echt crossplatform werkt.

[Reactie gewijzigd door Dreamvoid op 28 juli 2024 02:09]

[Spockz]

Java kwam in de tijd van Netscape nog maar net om de hoek zetten, en van C# was ook nog niet echt sprake. Zeker niet in de vorm zoals het nu is, er zijn zeer veel ontwikkelingen geweest in de informatica de laatste 10 jaar die ervoor gezorgd hebben dat C# nu is wat het is.

Java is niet zozeer de nek omgedraaid omdat het Java is of omdat het van Sun is. Maar het is gewoon een te logge taal om mee te programmeren en het hele concept van een applet dat eigenlijk in de browser draait is te outdated en daar kan je niet snel iets mee. Dat het bij flash wel heeft gewerkt is omdat daar een sterkere marketing achter zit/zat en omdat daar veel flashy dingen mee gemaakt werden.

C# in de browser heb je eigenlijk al, namelijk Silverlight. Daarmee heb je niet het gehele .NET framework en zijn mogelijkheden tot je beschikking maar je wel het grootste gedeelte.

Ik ben het wel met je eens dat het patchen van JS een goed idee is. De syntax is eigenlijk prima en dat het prototype-based is is verder ook niet zo erg. Verder zijn er al nieuwe features zoals list-comprehensions toegevoegd, dus het wordt allemaal wel bruikbaarder. Het wachten is alleen op dat alle browsers een uniforme JS API gaan ondersteunen. Zolang ze dit niet doen zullen we de problemen blijven houden zoals we die nu al hebben.

[MneoreJ]

Achteraf gezien is het misschien niet de beste beslissing geweest van Netscape om ooit, lang geleden, juist JavaScript in de browser toe te laten en waren we beter af geweest als ze een moderne taal als Java of C# hadden gekozen.

Achteraf kijken is altijd het makkelijkst...

Java was in de browser beschikbaar. JS en Java zijn ongeveer tegelijk ontstaan, (maar niet samen ontwikkeld -- het "Java" in "JavaScript" was juist marketing om op het hippe nieuwe Java mee te liften). Dat je C# noemt (dat nog niet *bestond* toen Java en JS opkwamen) getuigt evenmin van veel historisch besef. Netscape was al praktisch dood toen C# het licht zag, zoveel tijd zat ertussen.

Als Netscape de beschikking had gehad over een tijdmachine bestonden ze nu nog, dat is een feit. Het is hoe dan ook te makkelijk om te zeggen "hadden ze 15 jaar geleden maar alvast een platform geoptimaliseerd voor multiprocessed multiplatform tablet-apps erin gebakken". De geschiedenis is een raar ding en dat we nu met JS opgezadeld zitten ook, dat is het enige dat zeker is.

[fdm391]

Er zijn toch genoeg pogingen gedaan om je eerste punt te realiseren? Java heeft applets, .NET heeft Silverlight om maar een paar voorbeelden te noemen.

Het nadeel is dat er geen enkele standaard is. Alleen een JavaScript engine wordt door vrijwel alle browsers standaard meegeleverd...

[Dreamvoid]

Probleem is dat het allemaal plugins zijn en niet native in de browser zitten. We hebben gezien dat Apple (iOS), Microsoft (Metro) en anderen (Blackberry, etc) niet erg happig zijn om plugins toe te laten op hun platform. Of dat nou evil is (geen concurrentie voor hun native platform, dwarszitten van de concurrent) of juist goed (geen versplintering, geen vertragende extra frameworks, minder kans op security problemen, klantvriendelijker) daar kan je over discussieren, maar het resultaat is hetzelfde.

En gebruikers hebben al helemaal een hekel aan losse plugins, lees de comments maar hier op T.net

[Reactie gewijzigd door Dreamvoid op 28 juli 2024 02:09]

[Q]

Voor de toepassingen waarvoor deze processing power zinvol is, lijkt het mij verstandiger om een native applicatie te bouwen.

Als ik muti-core javascript ga draaien op een mobiel apparaat dan is mijn batterij zo leeg, dus voor die categorie van apparaten wil je dit denk ik niet.

Technisch gezien heel tof, maar wat gaan we er dus mee doen?

Dit is alleen spannen voor dekstop systemen. En zolang dit niet door alle browsers ondersteund gaat worden blijft het een gimmick.

[Reactie gewijzigd door Q op 28 juli 2024 02:09]

[Vytek]

Euhm die opmerking van "Als ik muti-core javascript ga draaien op een mobiel apparaat dan is mijn batterij zo leeg" gaat niet op. Het gaat om efficiëntie, hoe beter je hardware benut wordt hoe beter. Als je je batterij niet snel leeg wilt moet je geen 3D game spelen op je smartphone.

[PuzzleSolver]

Die opmerking gaat wel degelijk op. Als advertentie banners hier gebruik van gaan maken om fancy reclame te tonen op sites. Dan zal die site op jouw multicore mobiel de batterij wel degelijk sneller legen.

Op de IDF toonde Intel een particle demo waarbij River Trail dankzij parallele javascriptcode tot vijftien maal sneller zou presteren dan de huidige javascript-implementaties die code serieel verwerken. Intel gebruikte daarbij een processor met acht cores.

Was dan zeker 1 met hyperthreading anders haal je niet 15 maal zo snel. Het hangt waarschijnlijk heel erg af van de gebruikte code. Bij een simpele particle engine hebben de afzonderlijke particles vaak geen invloed op elkaar, daardoor schalen ze erg goed over meerdere core's.

Ben wel benieuwd of ze nu dan ook locking en events toegevoegd hebben aan de taal aangezien die ook nodig zijn voor een goede multithreaded implementatie.

[mad_max234]

Er is ooit een artikel verschenen van onderzoek dat aantoonde dat actieve reclame op websites onze x bedrag per jaar kost(en bijbehorende co2 uitstoot) aan stroom omdat de cpu extra belast word. Dat zal met dit soort technieken alleen maar erger gemaakt worden vrees ik. Staat je quad core straks 100% te draaien als je website bezoekt.

[Guru Evi]

Dat is al het geval met Flash.

[bbob]

Je moet dan uitgaan van reclame die specifiek ziet dat je een multicore hebt en daar dan ook een specifieke banner voor geeft. Dit is een beetje ja maar als.

In de praktijk is het gewoon dat iets sneller dan draaien. Nu heeft 1 core er zeg 10 seconden voor nodig en dat kost zeg 10 aan energie. Met Multicore duurt het nu zeg nog maar 2 seconden en 8 aan energie.

Het gaat er gewoon om dat alles sneller kan lopen en als het het goed lees bij een 8 core loopt het 15 keer sneller als bij een single core. Als dat een single core is die op dezelfde snelheid als 1 van de 8 cores loopt zou dat betekenen dat je zeker energie gaat bespraren.

[metalmania_666]

Je vergeet ook dat als het programma op meerdere cores kan draaien, het ook weer eerder klaar is

[Verwijderd]

Behalve als het een animatie of iets anders is wat blijft draaien, dan gebruikt het wel meer energie.

[Joolee]

Als je ziet dat niet alleen Google in Chrome OS maar ook MS in Windows 8 erop richt dat je ook applicaties kunt gaan schrijven in HTML5, JS en CSS is het een goede ontwikkeling waar zeker dankbaar gebruik van gemaakt zal worden door webprogrammeurs.

[Dreamvoid]

Voor de toepassingen waarvoor deze processing power zinvol is, lijkt het mij verstandiger om een native applicatie te bouwen.

Met de nieuwe WinRT API in Windows 8 is JavaScript (op 1 platform tenminste) al 'native' geworden.

[Reactie gewijzigd door Dreamvoid op 28 juli 2024 02:09]

[MSalters]

"Native" betekent in deze context "direct door de CPU uit te voeren", zonder een batterij-vretende vertaalslag. Dat verklaart waarom zelfs .Net soms als "non-native" wordt beschreven.

[poepkop]

Ik weet niet of ik hier nou op zit te wachten, wat DreamVoid hierboven zegt: the least worst solution.

Ik schrijf aardige stukjes Javascript, maar dat is eigenlijk meer door gebrek aan betere talen. Het zou mooi zijn als Javascript net zo'n stap zou maken als Adobe met As2 -> As3 heeft gedaan.
In mijn ogen zou een onafhankelijke partij zich moeten gaan bezig houden met het ontwikkelen van een nieuwe taal, want zaken als Silverlight en straks Dart zullen ook niet echt van de grond komen.

[Dreamvoid]

Dat klinkt leuk, maar wie is er werkelijk onafhankelijk? Zo'n 'onafhankelijke' praatgroep met alle partijen erin heeft ons na twaalf jaar bakkeleien met het compromisprodukt JavaScript/HTML5 opgezadeld, waar uiteindelijk niemand (zelfs Google niet, zie Dart) echt blij mee is. Hoe lang zou een volgende overleg ronde gaan duren?

In feite zijn er al twee grote onafhankelijke partijen (lees: zonder specifieke hardware of OS belangen): Adobe en Oracle - en zelfs met de miljarden daarachter hebben die het al moeilijk genoeg om een plekje te veroveren aan de client kant.

[Reactie gewijzigd door Dreamvoid op 28 juli 2024 02:09]

[R4gnax]

Het zou mooi zijn als Javascript net zo'n stap zou maken als Adobe met As2 -> As3 heeft gedaan.

Je bedoelt neem ik aan AS1 -> AS2?

Qua taalconstructies is er nl. niet veel nieuws gebeurd bij de overgang van ActionScript 2 naar ActionScript 3. De voornaamste wijzigingen zijn te vinden in het verbeterde display list model en het verbeterde event model (wat feitelijk een kopie v/h DOM model is). Geen van beiden zijn echter kernverbeteringen in de taal zelf.

[WernerL]

Wat? AS2 naar AS3 was juist een enorme vooruitgang terwijl as2 slechts een uitgebreidere AS1 was. AS2 werkte nog volledig procedureel terwijl met AS3 de taal volledig object-oriented is geworden. Wel degelijk een grote stap dus.

AS2 is waar JS nu staat, dus ik ben het wel eens met R4gnax zijn comment. JS moet echt flink op de schop genomen.

[ZpAz]

In JS heb je ook OOP.

[Verwijderd]

Mja, in principe wel. Maar ik vind het niet erg goed uitwerkt.

[ZpAz]

Het is anders. True. Dat je in JS veel werkt met callbacks en closures is imho wel nice.

[R4gnax]

Wat? AS2 naar AS3 was juist een enorme vooruitgang terwijl as2 slechts een uitgebreidere AS1 was. AS2 werkte nog volledig procedureel terwijl met AS3 de taal volledig object-oriented is geworden. Wel degelijk een grote stap dus.

Complete onzin.

ActionScript 2 had reeds de mogelijkheid om classes zoals in klassiek OO programmeren te schrijven. Er werd met AS2 dan ook van alle kanten al vol ingezet op het schrijven van classes, niet in het minste door Adobe zelf.

En anders lees je dit even voordat je zomaar wat gaat roepen:
http://www.kirupa.com/dev...AS2OOPChangedAndAdded.htm

[Jo-W]

De meeste problemen met javascript in de browser ligt bij de API en niet de taal zelf. Het enige echte struikelblok van de taal zelf die ik soms tegenkom is het niet ondersteunen van 64 bit integers, je hebt alleen 64 bit floating points (en dus 52 bits precisie + 1 bit sign).

Ik heb veel talen gebruikt (C, java, python, perl, basic, etc) en javascript is toch wel 1 van mijn favorieten (vooral in combinatie met node.js).

In veel talen gebruik je threads voor dingen zoals blocking I/O. In node.js gebruik je ze alleen maar (momenteel als forks) voor reken intensieve doeleinden. Naar mijn mening is dat ook hetgene waar threads voor bedoeld zijn. Ik heb veel met applicaties gewerkt waarin threads de boel ontzettend complex maken, terwijl ze alleen maar gebruikt werden voor I/O.
Node.js gebruikt natuurlijk threads in de achtergrond, maar in mijn javascript code geeft ik simpel weg een callback mee als ik bijvoorbeeld moet wachten op het lezen van een file, data van een netwerk socket, etc.

Een ander "probleem" met javascript is dat mensen van bijvoorbeeld een java achtergrond komen en gefrustreerd raken dat hun manier van werken slecht toepasbaar is. Je hebt bijvoorbeeld geen echte classes, maar je gebruikt prototype's.

[Verwijderd]

tja, ik denk dat het ook aan de developer ligt: de een werkt het liefst in C#, de ander in Python en weer een ander in Javascript.

persoonlijk denk ik echter dat het juist daarom wenselijk zou zijn om meer dan alleen javascript toe te staan in de browser en dan bedoel ik dat zonder plugins. Wat de threads betreft: soms maken ze dingen onnodig ingewikkeld maar er zijn ook zeker momenten waarop ze erg van pas zouden komen en waar ze gewoon echt performance verbeteringen op zouden leveren. ik hoop dus zeker dat dit initiatief overgenomen wordt door de browser makers.

[Dreamvoid]

persoonlijk denk ik echter dat het juist daarom wenselijk zou zijn om meer dan alleen javascript toe te staan in de browser en dan bedoel ik dat zonder plugins.

Dat wil iedereen, maar bij elk alternatief is er wel een grote browser maker die het niet in *wil* bouwen. Mexican standoff.

[Dreamvoid]

En zo wordt Javascript langzaam nog eens een echte taal.

Er is een hoop gaande rond JS de laatste tijd, Intel nu met deze nieuwe extensie, de aankondiging dat Microsoft JS nu volledig omarmt met WinRT, en Google (altijd *de* grote JS gebruiker) die deze maand een nieuwe webtaal Dart introduceerde die juist JS moet vervangen vanwege 'fundamental flaws'.

Anyway, goed nieuws voor JS devs, er blijft nog wel even brood op de plank.

[Reactie gewijzigd door Dreamvoid op 28 juli 2024 02:09]

[Verwijderd]

Mooi om te zien dat er steeds meer nieuwe pogingen worden om parallel computing languages naar de browser te brengen. Is het straks alleen niet een probleem dat er teveel specifieke oplossingen zijn voor verschillende hardware.

Is deze software ook van toepassing op de GPU of alleen op bepaalde CPU's (van intel). Ik denk dat het belangrijk is om 1 standaard aan te houden omdat de developers community alleen 1 universele taal zal accepteren. Persoonlijk denk ik dat webCL een zeer goeie parallelle oplossing is die parallel computations mogelijk maakt in het browser. Vooral omdat dit universeel i.v.m dat bijna alle grote vendors meedoen. en dat het een zeer robuuste taal is die met bijna alle parallelle hardware werkt ivm CPU's, GPU's en DSP's. Ook is de kans dat dit de grote standaard word veel groter omdat deze standaard word voorgeschreven door The khronos group.

Persoonlijk denk ik daarom ook dat de WebCL (Als computing language) in combinatie met webGL (Als graphical language) de dominerende technieken voor de komende tijd zullen zijn. Het enige probleem met webCL is nu alleen nog dat de ondersteuning nog niet groot genoeg is (I.V.M. oude hardware), en dat er voordat deze support groot genoeg is altijd een fallback oplossing zal moeten worden gebouwd (Wat met zware berekeningen moeilijk danwel onmogelijk is), zal het nog niet massaal worden toegepast. Maar dit is een kwestie van tijd. En voor Smart phones is dit laatste trouwens niet het geval. Omdat smartphones een ontwikkeling is van de laatste tijd is de ondersteuning van webCL op de smartphone veel groter.

PS. Wat die vrouw zegt dat dit waarschijnlijk de eerste snelle simulatie is die in het browser mogelijk is gemaakt klopt niet helemaal omdat er al een heleboel parallelle/native plugins zijn die volledig in het browser draaien.

[Reactie gewijzigd door Verwijderd op 28 juli 2024 02:09]

[Ducky.nL]

Bespeur ik hier een potentiele Minecraft performance upgrade?

[ZpAz]

Minecraft is gemaakt in Java, een totaal andere taal dan JS. Welke niets met elkaar te maken hebben.

[kikker81]

Wat een gemopper op Javascript zeg, ik vind Javascript dus echt wel de leukste programmeertaal... go intel!!