Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

River Trail — Intel's Parallel JavaScript

Soulskill posted more than 2 years ago | from the perpendicular-javascript-coming-soon dept.

Intel 134

mikejuk writes "Intel has just announced River Trail, an extension of JavaScript that brings parallel programming into the browser. The code looks like JavaScript and it works with HTML5, including Canvas and WebGL, so 2D and 3D graphics are easy. A demo video shows an in-browser simulation going from 3 to 45 fps and using all eight cores of the processor. This is the sort of performance needed if 3D in-browser games are going to be practical. You can download River Trail as a Firefox add-on and start coding now. Who needs native code?"

cancel ×

134 comments

Sorry! There are no comments related to the filter you selected.

Oblig (1, Funny)

grub (11606) | more than 2 years ago | (#37423498)


What about a beowulf.js cluster of these?

Re:Oblig (0)

Ceriel Nosforit (682174) | more than 2 years ago | (#37423792)

I think you mean node.js [nodejs.org] .
(Features non-blocking hot action, just like C.)

Who needs native code? (5, Funny)

nicholas22 (1945330) | more than 2 years ago | (#37423506)

CPUs

100 (-1)

Anonymous Coward | more than 2 years ago | (#37423510)

Don't cum in my ass, I want it in my mouth.

Re:100 (0)

Anonymous Coward | more than 2 years ago | (#37426202)

Don't worry, there's plenty of dick for both of your holes.

Fuck parallel programming. (-1, Troll)

unity100 (970058) | more than 2 years ago | (#37423524)

When amd finally brings the concept of assigning more than 1 cores to a single thread in a few iterations after bulldozer, we wont have to deal with parallel programming shit. instead of creating parallel programming languages, intel itself should have worked on this apparent, most needed, but unimplemented revolutionary concept.

Re:Fuck parallel programming. (0)

Anonymous Coward | more than 2 years ago | (#37423576)

Scala is awesome. If you write in the functional style, you get "parallel" for free.

Re:Fuck parallel programming. (2)

ZankerH (1401751) | more than 2 years ago | (#37423598)

the concept of assigning more than 1 cores to a single thread

Computing doesn't work that way. At least not with any meaningful speed increase. That may decrease power usage, but you'll still need "parallel programming shit" to make proper use of parallel processing hardware.

Re:Fuck parallel programming. (0)

Anonymous Coward | more than 2 years ago | (#37423652)

You do realize you are responding to a troll, right? This guy is just some loser php "programmer" who knows jack and shit about real programming.

Re:Fuck parallel programming. (5, Insightful)

TheRaven64 (641858) | more than 2 years ago | (#37423846)

Not entirely. One of the features of Sun's cancelled Rock CPU was something they called Thread Scout. The idea was to run one core ahead of another, skipping most computation, to pre-fault memory addresses. This ensured that data was in cache when it was needed. There was also an idea to use multiple cores to extend the superscalar concept, so when you encountered a branch one core took each potential path and you discarded the wrong one. A lot of GPUs used to do this, but no general purpose CPUs (that I'm aware of, although ARM and Itanium do something similar with their predicated instructions).

You're right that you won't get the full benefit of writing proper concurrent code, but you will get some.

Re:Fuck parallel programming. (1)

Wrath0fb0b (302444) | more than 2 years ago | (#37424124)

There was also an idea to use multiple cores to extend the superscalar concept, so when you encountered a branch one core took each potential path and you discarded the wrong one.

Given how accurate branch predictors are, what's the point in computing the non-predicted paths?

Re:Fuck parallel programming. (4, Interesting)

Renegrade (698801) | more than 2 years ago | (#37424144)

Not entirely. One of the features of Sun's cancelled Rock CPU was something they called Thread Scout. The idea was to run one core ahead of another, skipping most computation, to pre-fault memory addresses.

That was done back in the days with the original 68000. They were put in tandem in some machines, and one processor ran slightly ahead of the other. If it hit a bus fault, the second 68000 was used to recover, as the original 68K could not recover normally from a bus fault. Obviously this was not for performance purposes, but rather for reliability, but it's amazingly similar.

The oh-ten could recover from bus faults, and the 020 had a full-scale (although external) MMU option, so the technique ceased to be used.

Re:Fuck parallel programming. (1)

jgagnon (1663075) | more than 2 years ago | (#37424036)

So... what? It's an advanced form of out-of-order execution. Big deal, it's been around a LONG time. Revolutionary my ass.

Re:Fuck parallel programming. (1)

godrik (1287354) | more than 2 years ago | (#37425106)

It might not only be out of order execution. It might must be cache. 8 cores certainly run on more than 1 L3 cache. More cache=>(possibly superlinearly) faster

Who needs native code (1)

afidel (530433) | more than 2 years ago | (#37423626)

People who don't have 8 cores available and who want acceptable performance? People who want their Windows 8 tablet to have a real world battery life longer than two hours?

Re:Who needs native code (4, Funny)

93 Escort Wagon (326346) | more than 2 years ago | (#37423662)

People who want their Windows 8 tablet to have a real world battery life longer than two hours?

So, what - 4 or 5 people?

Re:Who needs native code (3, Funny)

kelemvor4 (1980226) | more than 2 years ago | (#37423822)

People who want their Windows 8 tablet to have a real world battery life longer than two hours?

So, what - 4 or 5 people?

I think you overestimate the sales potential for windows8 tablets.

Re:Who needs native code (0)

Anonymous Coward | more than 2 years ago | (#37424214)

Just like everyone over estimated the iPad...

They integrate it with their media center and it will be a very cool app...

Re:Who needs native code (0)

Anonymous Coward | more than 2 years ago | (#37424580)

People who want their Windows 8 tablet to have a real world battery life longer than two hours?

So, what - 4 or 5 people?

I think you overestimate the sales potential for windows8 tablets.

In 4 or 5 units.

Re:Who needs native code (1)

Lennie (16154) | more than 2 years ago | (#37423696)

Actually, I heared if you can do your computing in a short time in parallel or a long time. Choose parallel it is usually more power efficient (this means: it is possible to turn off as many parts of a CPU as soon as possible and frequency scaling can be done when nothing is running).

Re:Who needs native code (0)

Anonymous Coward | more than 2 years ago | (#37423810)

Seems theres some 13 year olds on Slashdot with 5 digit UIDs now...

Re:Who needs native code (1)

Anonymous Coward | more than 2 years ago | (#37424520)

I thought all slashdotters registered their kids an account when they were born. We have to endoctrine them into the system as soon as possible after all.

Re:Who needs native code (1)

increment1 (1722312) | more than 2 years ago | (#37423950)

Unfortunately, that does not make it more efficient to run Javascript, through however many layers of indirection and abstraction it undergoes, than it does to run native code. Doing a remarkably inefficient task in parallel only parallels your inefficiency, it does not remove it.

I am not advocating for native code, but if you want good performance on today's hardware then Javascript is not really the number 1 candidate, regardless of whether it can be executed in parallel or not.

Re:Who needs native code (0)

Anonymous Coward | more than 2 years ago | (#37423942)

Poor mentaly challenge people, looking for battery life in a windows product.

Re:Who needs native code (1)

afidel (530433) | more than 2 years ago | (#37424222)

Uh, Windows still gets battery life than Linux. OSX though generally gets better life than Windows.

Re:Who needs native code (0)

Anonymous Coward | more than 2 years ago | (#37425494)

Uh, Windows still gets battery life than Linux. OSX though generally gets better life than Windows.

You're missing an adverb and a noun. I'm guessing the former to be "less" and the latter to be "sex".

Re:Who needs native code (0)

Anonymous Coward | more than 2 years ago | (#37425294)

Soon everybody will have 8 cores available and acceptable performance. Some of them will also have a real world battery life longer than two hours.
--
This announcement was brought to you by the Nvidia Corporation

who needs native code? (1)

nimbius (983462) | more than 2 years ago | (#37423646)

anyone who recognizes you'll pay a pittance to the browser for your share of the fun.

Superlinear speedup (1)

timeOday (582209) | more than 2 years ago | (#37423664)

Ha ha, a 15x speedup by going from 1 to 8 cores? No. It's hard to invent a situation in which you would get a genuine 8x speedup, let alone somehow making each core almost twice as fast.

Re:Superlinear speedup (2)

jeffb (2.718) (1189693) | more than 2 years ago | (#37423746)

Since JS is normally single-threaded, I'm guessing that the one-core scenario is spending more than half its time on things other than the simulation. Additional cores can be dedicated entirely to the simulation. Under those circumstances, 15x speedup isn't the least bit surprising.

Re:Superlinear speedup (1)

atisss (1661313) | more than 2 years ago | (#37423806)

They probably will be pushing addition to Javascript, because the only things it missed so far was multithreading/semaphores/memory management.
Finally the JavaScript will be complete

Re:Superlinear speedup (1)

Ceriel Nosforit (682174) | more than 2 years ago | (#37423778)

Is it now? If the CPU spends half its time unparallellizable preparing its computation and that preparation can just be copied to the other cores, the max theoretical speedup is just under 16x.

Re:Superlinear speedup (1)

jeffb (2.718) (1189693) | more than 2 years ago | (#37423834)

You're looking at it the wrong way. Adding more cores allows more work to be done in a given interval -- in this case, computing and displaying more frames.

The "other stuff" I was referring to is stuff external to the simulation, that doesn't have to be done repeatedly on other cores.

Re:Superlinear speedup (0)

Anonymous Coward | more than 2 years ago | (#37423948)

I know! I know! It's like the thing with one woman making a baby in nine months, so nine women should be able to make a baby in 2 months!

Re:Superlinear speedup (-1)

Anonymous Coward | more than 2 years ago | (#37424052)

You should realize that parroting things you don't understand in situations where they don't apply actually makes you seem like a much bigger dumbshit than if you just kept your mouth shut.

Re:Superlinear speedup (0)

Anonymous Coward | more than 2 years ago | (#37424470)

wait why doesn't it apply? why not tell us that instead of indulging yourself in gratuitous insults?

Re:Superlinear speedup (1)

AmberBlackCat (829689) | more than 2 years ago | (#37424096)

Is it now? If the CPU spends half its time unparallellizable preparing its computation and that preparation can just be copied to the other cores, the max theoretical speedup is just under 16x.

If every process is going to work with exactly the same data then it doesn't matter if you have 1 core or 8. The data only has to be prepared one time. So the multiple cores won't save you time preparing that data with each cycle.

Re:Superlinear speedup (4, Informative)

yakovlev (210738) | more than 2 years ago | (#37424454)

No.

If half the work is unparallelizable then the max theoretical speedup is 2x.

This is a simple application of Amdahl's law:

speedup = 1 / ( (1-P) + (P/S) )
where P is the amount of the workload that is parallelizable and S is the number of cores.
speedup = 1 / ( (1-0.5) + (0.5/S) )
lim S-> infinity (speedup) is 1/ 0.5 = 2x

The likely reason the speedup appears superlinear here is that there are actually two speedups.

1.) Speedup from parallelizing on multiple threads. From looking at the usage graphs, this is probably about 4x.
2.) Speedup from vectorizing to use processor AVX extensions: This could be another 4x.

Total speedup: 16x.

A 16x speedup is totally believable for vectorizing and parallelizing a simple scientific simulation like the one shown in the video.

Re:Superlinear speedup (1)

timeOday (582209) | more than 2 years ago | (#37424560)

2.) Speedup from vectorizing to use processor AVX extensions: This could be another 4x.

OK, that makes sense (although I would hope vector instructions could normally be tapped by optimizing libraries instead exposing the vector api to the programmer).

You win "IMHO the best answer to my question."

Re:Superlinear speedup (1)

yakovlev (210738) | more than 2 years ago | (#37424902)

I'll go you one better. I would hope that vector instructions are utilized by the compiler even for code that doesn't explicitly go after using them.

At a minimum, it should be possible to provide a "write your code like this, and it will be easy for the compiler to detect that what you really want is vector instructions."

However, sometimes interpreted languages can work against this due to things like strict exception checking.

Re:Superlinear speedup (1)

adri (173121) | more than 2 years ago | (#37425842)

.. err, I think you missed the point with vectorised instructions and interpreted languages.

If your interpreted language has no vector operations, then although your compiled binary interpreter can vectorise, the data operations being given to your interpreter is not vectorised. Think about it for a minute. Your interpreter is just doing while (read VM opcode) (call func[VM opcode]) ; the data isn't in a parallelable/vectorised form; nor will the CPU ever see it that way. The CPU just sees the VM opcode stream.

For JITs this is different. I haven't done much digging here, but again getting vectorised performance out of a JIT requires the underlying data be in the right format.

This is why out of order, parallel instruction execution is a lot "better" for random applications (including interpreters and JITs) - because you're parallelising the instructions themselves, rather than trying to operate on vectored data. Your VM environment and/or application likely doesn't give you the correctly formatted data set.

I tinkered with vectorised instructions in a FORTH style bytecode stream. Where you pass the data list to vectored instructions. This provided a huge speed benefit. Trouble was, it was FORTH. :)

Re:Superlinear speedup (1)

LWATCDR (28044) | more than 2 years ago | (#37423812)

8 cores X 2 threads per core =16X
Since the cores are also running the OS, Browser and goodness knows what else 15 X could be possible with more cores. Sort of like like your 40 megabyte program getting a massive speed up when you go from 512Mb of RAM to 2 Gb of RAM. PCs today are not like computers back in the day. They are often running a lot of other code besides your application. That is one reason that DOS is still popular for some tasks. Once your code is running pretty much that is all that is running.

Re:Superlinear speedup (1)

timeOday (582209) | more than 2 years ago | (#37424498)

8 cores X 2 threads per core =16X

Only if the CPU can run 2 threads each as fast as it could run 1. I've never heard of such a thing. (Hyperthreading certainly doesn't come close.) If there were such a beast, it would be marketed as a 16 core chip.

Since the cores are also running the OS, Browser and goodness knows what else 15 X could be possible with more cores.

If you have a multi-core machine, you don't need multithreaded javascript to run javascript on one core and other things on other cores.

Re:Superlinear speedup (1)

LWATCDR (28044) | more than 2 years ago | (#37424546)

Yes but it runs in more than one of those other cores. This also support SSE which may help a lot for some benchmarks as well. Of course you do not get a linar increase with cores but this may be in the range of possible with some specific benchmarks.

Re:Superlinear speedup (2)

TheRaven64 (641858) | more than 2 years ago | (#37423872)

It's not totally unbelievable, when you consider the fact that it's using WebGL. Doubling the speed at which the CPU prepares data for the GPU to render can more than double the overall throughput.

Re:Superlinear speedup (0)

Anonymous Coward | more than 2 years ago | (#37423934)

Superlinear speeds up isn't actually all that hard, if the problem is: embarrassingly parallelizable, and splitting it up causes a significant change is how much fits into the L1/2/3 layers of the cache.

Re:Superlinear speedup (1)

WorBlux (1751716) | more than 2 years ago | (#37424156)

Not necessarily. Some things will only need to be done once. Say currently that takes 2/3 of the cycle time. Some things will have to be done 15 times to speedup 15 times. These things look 1/3 of the original process. Add in the setup fee and it's not hard to see how you can get 15 times the performance in terms of fps.

Re:Superlinear speedup (0)

Anonymous Coward | more than 2 years ago | (#37424292)

Ha ha, a 15x speedup by going from 1 to 8 cores? No. It's hard to invent a situation in which you would get a genuine 8x speedup, let alone somehow making each core almost twice as fast.

This is Intel we're talking about. You forgot to consider Hyper-Threading!

Re:Superlinear speedup (0)

Anonymous Coward | more than 2 years ago | (#37424452)

RiverTrail also takes advantage of the vector instructions.

Re:Superlinear speedup (1)

kramulous (977841) | more than 2 years ago | (#37424710)

There are numerous ways to get superlinear speedup. Turns out that it is not that hard. There is more to parallel programming that just 'cores'. Of course, it depends on the algorithm.

eg
Matrix Multiply 101 [intel.com]

Wow, that is a terrible page to read (1)

danielcolchete (1088383) | more than 2 years ago | (#37423672)

We need some sort of metrics here. The I Programmer article content here is using only 314x1213 pixels on my laptop. The whole page have 1160x2078! Only about 16% of my screen area is the article's content. This is like listening to 50 minutes of commercials every hour on the radio. No one would accept that on the radio and I say we shouldn't here. Thanks!

Re:Wow, that is a terrible page to read (0)

Anonymous Coward | more than 2 years ago | (#37424258)

We need some sort of metrics here. The I Programmer article content here is using only 314x1213 pixels on my laptop. The whole page have 1160x2078! Only about 16% of my screen area is the article's content. This is like listening to 50 minutes of commercials every hour on the radio. No one would accept that on the radio and I say we shouldn't here.

Thanks!

http://www.readability.com/bookmarklets

Web Workers (1)

ttong (2459466) | more than 2 years ago | (#37423694)

We already have Web Workers, they just can't access the DOM. Why can't they just try to improve the existing framework instead of inventing their own?

Re:Web Workers (0)

Anonymous Coward | more than 2 years ago | (#37424080)

This. They should improve the web worker spec, support IT with hardware acceleration. Those things are extremely handy.

Although the DOM system is still a HUGE slowdown.
While we have Canvas now, people would rather not have to sit down and create an entire interface from the ground up just to save generating huge overhead with elements that don't require even half the data that is generated on creation.
Worse, people doing the spec are trying to make Canvas "accessible", AKA, slow it the HELL down, negating the ENTIRE PURPOSE OF IT.
Most of the data simply isn't required for most things, but is generated anyway, why? Why fill a page with thousands of useless attributes on elements when they aren't even needed? No border set, why state that? The fact it was undefined isn't enough? It's not like it is any slower to generate that value on the fly, it wouldn't be noticeable with the fact that practically every other craptibute isn't there and the whole process / browser / whatever is much faster overall anyway.
Why is XUL not used? XUL seems nice for interfacing. With a few changes here and there to make it less "dull", it'd be perfect for the web.
Better yet, why are we still serving applications over the web instead of having a different system entirely? Things like Native Code or whatever it is that Google was doing, I kinda want to see that actually succeed in some way. HTTP also needs to be ditched already, it is terrible, old and broken. SPDY has already shown massive improvement over HTTP.

In short, screw developers, they suck. They don't know what they want, they don't know what everyone else wants, they just do their own nonsense and hope people like it.

Re:Web Workers (1)

georgesdev (1987622) | more than 2 years ago | (#37424118)

which standard has Microsoft improved in the past?

Re:Web Workers (1)

Billly Gates (198444) | more than 2 years ago | (#37424600)

Actually Microsoft is doing a 180 since IE 8 due to losing marketshare and the threat of HTML 5 and the IPad.

IE 9 is a decent browser. It truly has caught up and supports SVG, HTML 5 canvas elements, hardware acceleration, CSS 3 (even animations), xhtml (about damn time), and so on. You no longer need the horrible hacks to get anything done in it like tricking it to read xhtml when it does not support it.

Windows 8 supports Web Workers with IE 10 and according www.html5test.com its HTML 5 is on par with Chrome and Firefox making it a lead browser. The only reason it did not get a perfect score is the lack of WebGL due to security issues, but IE 9/10 support CSS 3D.

If the Windows 8 Pad/Tablet takes off you can bet mass adodption of web workers. Also Microsoft is switching now from a 2.5 year to a 1 year release browser cycle. In 5 years IE 14 will be out. It will be a very different place than where we were with IE 6 for 7 years.

Even if you want to scoff at my comment and NEVER use IE this is great news. It means webmasters can finally use things like webworkers and advanced designs in their pages as IE 7 always held them back. It is great at work too if you are stuck with IE. IE 9/10 is at least modern and finally doesn't suck even if it is not the best.

Re:Mod parent (1)

Billly Gates (198444) | more than 2 years ago | (#37424648)

Web workers takes care of this and launches things in different processes. The only browser that doesn't support it is IE, but that will change with Windows 8 next spring.

It can take care of this without Intel's code

Re:Web Workers (1)

Gyrony (2463308) | more than 2 years ago | (#37426156)

"A ParallelArray abstraction for JavaScript and a Firefox add-on to enable parallel programming in JavaScript targeting multi-core CPUs and vector SSE/AVX instructions." Sounds to me as though this is not Multithreaded JavaScript or a replacement for Web Workers, but an implementation of vector processing for JavaScript, using OpenCL

so 8x parallelism yields 15x speedup? (0)

Anonymous Coward | more than 2 years ago | (#37423700)

What kind of magic gives > linear speedup?

Re:so 8x parallelism yields 15x speedup? (0)

Anonymous Coward | more than 2 years ago | (#37423818)

This is not uncommon. You're amortizing the cost of managing the particular function. The management processes takes a proportionally smaller percentage of the total workload.

Re:so 8x parallelism yields 15x speedup? (1)

Nadaka (224565) | more than 2 years ago | (#37423962)

wait time bound magic.

multiple independent processes on a single core can cause a speedup over the same tasks in a single process because other processes can run while one is waiting for IO.

Looks like their blog server... (1)

jeffb (2.718) (1189693) | more than 2 years ago | (#37423726)

...could use a bit of multicore speedup itself.

JS Threading without intervals/timeouts! (1)

Ryyuajnin (862754) | more than 2 years ago | (#37423776)

Its about time!

Re:JS Threading without intervals/timeouts! (2)

mrjb (547783) | more than 2 years ago | (#37424288)

Now all we need is a "sleep" function.

And around and around it goes... (0)

Anonymous Coward | more than 2 years ago | (#37423832)

Personally, I think we should just throw away all the other languages and use JS for everything. Why not - it's the future! Between it and the HTMLx (can't really say 5 - it's a 'living standard' afterall), I expect that it will not only slice my bread but also make it for me too. I say we reinvent the wheel just once more for the hell of it. Afterall, it's all cool-like and really awesome (insert other superlatives here). Well, erm, until it's not - and then we rinse and repeat. Oh, the joy!

Re:And around and around it goes... (0)

Anonymous Coward | more than 2 years ago | (#37424576)

Wasn't Java supposed to do this back in the late 90s? Become the be-all and end-all of programming languages where the network was the computer. It would be funny and a bit ironic if it's ill-named, step-cousin with it's little understood prototyped inheritance model became THE language. Meanwhile all the perl, python, ruby and lua enthusiasts get to see a lesser scripting language dominate. Oh well, PHP already did that. At least it's relegated to the back-end. JS is threatening to be all things, if you believe half of what is being written.

I understand what their doing... (0)

Anonymous Coward | more than 2 years ago | (#37423866)

I just don't know why.

JavaScript is a hateful, spiteful language. If you're trying to write a real application PLEASE switch to a language more appropriate -- like COBOL. Or even INTERCAL.

Re:I understand what their doing... (1)

Pino Grigio (2232472) | more than 2 years ago | (#37424020)

It's frightening how rumpsmackingly crap JS is as a language, yet it seems to be the Next Big Thing for software development according to all of the dribbling articles I keep reading about it.

Re:I understand what their doing... (0)

Anonymous Coward | more than 2 years ago | (#37424046)

Yeah, because Cobol works so much better in Firefox.

Not wait, it doesn't.

Re:I understand what their doing... (1)

Toonol (1057698) | more than 2 years ago | (#37424076)

Javascript's not a bad language. The pain in javascript programming is usually caused by the DOM and browser cruft... and you'd have to deal with that regardless of what web-scripting language you used.

Re:I understand what their doing... (0)

Anonymous Coward | more than 2 years ago | (#37424168)

God dammit! It's "they're" not "their".
Sometimes I'm an idiot.

Re:I understand what their doing... (0)

Anonymous Coward | more than 2 years ago | (#37424276)

Sometimes?

I was going to suggest switching to ENGLISH. But Slashdot thinks I've posted enough insightful, clever, and interesting posts today.

Re:I understand what their doing... (0)

Anonymous Coward | more than 2 years ago | (#37425150)

Yeah, only sometimes.
Mainly when I feel like posting Slashdot comments.

it's room for better (-1)

Anonymous Coward | more than 2 years ago | (#37423900)

The I Programmer article content here is using only 314x1213 pixels on my laptop. I'm waiting your opinion about 7secondcar.com

When your GPU sucks (1)

gr8_phk (621180) | more than 2 years ago | (#37423932)

If your GPU sucks, try to get people to buy 8 CPU cores and do graphics on those. Seriously, doesn't WebGL allow use of the GPU? If not, fix that.

But does it run on Linux? (0)

Anonymous Coward | more than 2 years ago | (#37423936)

The browser plugin only seems to work with Windows and MacOS X.

Re:But does it run on Linux? (0)

Anonymous Coward | more than 2 years ago | (#37424068)

Linux still exists? I thought anyone who wasn't an idiot threw that shit in the garbage can 10 years ago.

Re:But does it run on Linux? (0)

Anonymous Coward | more than 2 years ago | (#37426208)

You're in denial.

Square Peg meet Round Hole (1)

trcollinson (1331857) | more than 2 years ago | (#37424120)

I see no problem at all with a parallel version of JavaScript. But the question I have is who is really going to use this? Granted, some might say "anyone who wants to make money, this is the future of gaming and entertainment". I certainly hope it isn't! Is a browser really the platform of choice for high performance graphics? I think not. Is there anything really wrong with having a native client to produce something so specialized as a graphics intensive platform? Must we really look to a future where everything runs inside of a browser?

Re:Square Peg meet Round Hole (1)

Coren22 (1625475) | more than 2 years ago | (#37424330)

This is the next best thing for Zynga though :)

Oh boy!!! (5, Insightful)

frank_adrian314159 (469671) | more than 2 years ago | (#37424162)

That means the animated ads can now suck up all of my CPU, rather than just one core's worth. I can't wait!

that is the future? (2, Insightful)

devent (1627873) | more than 2 years ago | (#37424176)

Instead of get a 50$ graphics card and play Doom3 on it, we need now 8 cores CPU to play JavaScript games in the browser? That is the bright future we can look for with ChromeOS and "the browser is the OS" future?

Re:that is the future? (0)

blackfrancis75 (911664) | more than 2 years ago | (#37424196)

could someone with mod points please deal with parent appropriately?

Re:that is the future? (1)

Toonol (1057698) | more than 2 years ago | (#37425076)

I honestly don't know which direction of modding you think is appropriate for that comment.

Re:that is the future? (1)

blackfrancis75 (911664) | more than 2 years ago | (#37425696)

well that's just sad. There's no talk of *needing* 8 processors for anything - that was just part of the set-up for the demonstration. Also the code isn't JavaScript - it 'looks like' JavaScript and would replace it. Also no-one's going to stop you playing Doom3, but why not compare with the hardware required for a semi-recent game.. Crysis for example? Oh, because that wouldn't support your trolling..

Re:that is the future? (0)

Anonymous Coward | more than 2 years ago | (#37424390)

The future will be bright only for cloud owners, who will be above the cloud btw. For everybody else below the cloud, not so.

Re:that is the future? (0)

Anonymous Coward | more than 2 years ago | (#37426560)

Well, actually Intel wants to sell you 8 graphics cards with 32 cores each so you can play ray-traced Wolfenstein in your browser.

http://tech.slashdot.org/story/11/09/15/1714237/Wolfenstein-Ray-Traced-and-Anti-Aliased-At-1080p

People who have 8 cores (1)

drolli (522659) | more than 2 years ago | (#37424180)

but rather prefer to use them for something meaningful but the weirdly scrolling ad annoying them in some partialy visible background window....

Re:People who have 8 cores (1)

Yvan256 (722131) | more than 2 years ago | (#37424414)

I think it means people with single-core computer will only get a scrolling banner ad.

People with a multi-core computer will get a scrolling banner ad with parallax scrolling backgrounds!

For programmers: What DO the extensions look like? (1)

mrjb (547783) | more than 2 years ago | (#37424260)

According to this page [infoq.com] , RiverTrail "adds the ParallelArray data type to JavaScript [...] accessible by functions like combine [github.com] , filter [github.com] , map [github.com] , reduce [github.com] , etc. which perform work in parallel." Hope that saved you some searching.

Application load balancing (4, Insightful)

sunfly (1248694) | more than 2 years ago | (#37424264)

Why should an application decide the best way to split a load over multiple cpu cores? How does it know what else is going on in the OS to balance this load? Shouldn't the OS handle this behind the scenes?

Re:Application load balancing (0)

Anonymous Coward | more than 2 years ago | (#37424516)

Yes, the OS should be doing but until recently it wasn't done that way for a number of reasons. This is changing. See http://en.wikipedia.org/wiki/Grand_Central_Dispatch

Re:Application load balancing (0)

Anonymous Coward | more than 2 years ago | (#37424824)

Standard JavaScript is single threaded so the JS for a browser's tab can run only on one core. I might be wrong but the OS can't do anything to improve on that.

Re:Application load balancing (2)

CentTW (1882968) | more than 2 years ago | (#37424860)

Short answer: It doesn't work that way. Programs can only be split over multiple cores if they are designed to use those cores. Most programs aren't because it's harder to write, maintain, and the extra processing power often isn't necessary.

Long answer: A program is a sequence of instructions that normally have to be run one after another to complete a task. Imagine a program designed to make a peanut butter and jelly sandwich. The highest level of the program might look something like this (the rest of the program would ultimately describe what these steps mean):

  1. Obtain ingredients()
  2. Open(Peanut butter)
  3. Open(Jelly)
  4. Spread(Peanut butter,Bread0)
  5. Spread(Jelly,Bread1)
  6. Combine(Bread0,Bread1)
  7. Clean Up()

These steps can easily be followed directly by 1 cook to create 1 PB&J sandwich. Adding extra cooks won't speed up the process, because most of the tasks rely on a previous task being finished. If you're only interested in 1 PB&J sandwich, chances are pretty good you're best bet is to just let one cook make the one sandwich.

Now, if you want to make a hundred PB&J sandwiches, you'll be able to take advantage of extra cooks, but you'll need to change your instructions a bit so that they don't run into each other (too often) and don't waste time opening and closing jars after each sandwich.

The biggest problem is that the operating system doesn't know when it has a task that can be split across multiple processors to improve the speed. makeSandwich(1) looks no different to it than makeSandwich(100). Even if it could figure out that the task could be done across processors, it wouldn't know where to split the task, or how to put the pieces back together.

Generally speaking, in the software world, when you hear about people talking about threads, they are trying to split a task across multiple processors. So, a thread is a piece of code that has work to do, won't (typically) interfere with other threads, and can be run on any processor. So, when an operating system sees a new thread, it'll run it on whichever processor it thinks will get the job done the fastest, which is how load balancing is done.

Re:Application load balancing (1)

martin-boundary (547041) | more than 2 years ago | (#37425548)

Short answer: It doesn't work that way. Programs can only be split over multiple cores if they are designed to use those cores. Most programs aren't because it's harder to write, maintain, and the extra processing power often isn't necessary.

Short reply: Most programs call system services and libraries to do specialized work. The internals of those system calls and library calls do not matter to the programmer, only their interface does. If the tasks they perform is sufficiently high level, then the parallelism can be inbuilt and transparent.

Re:Application load balancing (1)

optymizer (1944916) | more than 2 years ago | (#37425602)

Because only the application knows how to split its own inputs so that multiple worker threads can each work independently on an input chunk. The job of the OS is to figure out how much CPU time each worker gets, based on a variety of factors (such as thread and process priority/nice-ness). If you have multiple CPUs and they're not at 100% usage, this results in parallel processing of those inputs.

Awesome (0)

Anonymous Coward | more than 2 years ago | (#37424318)

Gee, why would I need native code when I can push 45 fps on 8 cores using HTML5, instead of maxing out the latest source engine games (300fps) at 1900x1200 with max graphical settings using 4 cores (l4d2, portal2)?

Screw that native code!

Parallelism : crashing the browser 8 times quicker (1)

billcopc (196330) | more than 2 years ago | (#37424550)

Just to make sure I got this straight:

Intel took one of the slowest interpreted languages, though the most popular one, and added parallel data primitives and functions. Then they used a pointless little particle fountain demo to show off its benefits.

So rather than try to make Javascript execute faster, they spread its disease to all 8 cores. How is this an improvement ? The last thing I want is for a web page to sap my CPU and battery life, doing things web pages should not be doing in the first place. Save that Javascript for friendly client-side form validation and UI animation. Everything else is a hack. 3D graphics in the Javascript is a hack. Heavy number crunching in Javascript is a hack. Fuck off with your hacks! If I want fancy graphics and high framerates, I'll run native code.

benchmarks (1)

suitti (447395) | more than 2 years ago | (#37424956)

I have a couple benchmarks i've run over the years, in multiple languages. For CPU intensive jobs on the same machine:

C: 1
Java: 1.1-3
javascript: 117

Javascript is in IE8 on win xp.

Javascript on IE has restrictive time limits for execution, though there are work arounds.
But If you have 8 cores, you're still 14.6x slower than C.

IMO, Java, which already runs in the browser, is the better solution. That said, compared to C, Java also has huge memory requirements.
It would make more sense to allow mutli-core execution in Java in the browser.

Re:benchmarks (2)

BZ (40346) | more than 2 years ago | (#37425068)

> Javascript is in IE8 on win xp.

Uh.... This is the same IE8 that doesn't have a JIT, right? Unlike every single browser actually shipping now?

Here's a relevant graph: http://ie.microsoft.com/testdrive/benchmarks/sunspider/default.html [microsoft.com]

It's a bit out of date, since all browsers have gotten faster since then, but it shows IE8 being about 18x slower than any modern browser on this particular benchmark. And this is a benchmark that hammers a lot on the VM (dates, regular expressions, etc), not the language itself.

On code that runs for longer than a few ms and is actually compute-intensive the difference between IE8 and any modern browser is even more pronounced.

Heck, at this point you can compile C code to JavaScript and then run it in some browsers and have it be only about 5x slower than the original C code. That's with (typed) arrays representing the C stack and heap and so forth...

I'd love to see your benchmark code, by the way. Or for you to rerun the benchmark in something that actually tries to run Javascript quickly, as opposed to IE8.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>