Slashdot Mirror
River Trail — Intel's Parallel JavaScript
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?"
CPUs
People who want their Windows 8 tablet to have a real world battery life longer than two hours?
So, what - 4 or 5 people?
#DeleteChrome
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.
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.
I am TheRaven on Soylent News
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.
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 all.
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?
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.