Google has announced that the latest beta for Chrome, their web browser, will compile Javascript in a background thread. In the current release version, scripts are converted to instructions, executed, monitored for performance, and swapped with a more optimized set of instructions that accomplishes the same tasks. Converting script into optimized instructions takes time. Doing it on a background thread frees up that computation time for something else.
This stutter was 628 milliseconds, or about 38 consecutive frames at 60 FPS.
Image Credit: Chromium Project Blog
Web browsers are designed under the assumption that a single thread of instructions will weave through every task, one by one, until everything is done. At some point, since the early 1990s, computers have been give multiple cores (and some of those designs can have multiple threads shoved through at once). The problem is now that, since "Task A" was designed to occur before "Task B", doing them separately… can break stuff good.
A simplified browser execution flowchart. Execution follows the arrow.
Image Credit: Mozilla
Background Javascript optimization will be most effective for mobile SoCs. These processors tend to have a lot of fairly slow cores; the exact opposite of what a web browser wants. Also, video games have many tasks which occur every frame. Freeing up time on the main thread gives these apps more time to be more complex – and with less stutter (if optimizing blocks execution… which it is trying to optimize). This might also allow browsers more time to try more aggressive optimization strategies.
In case you are wondering, Mozilla started to move compilation to a background thread as of Firefox 21. Firefox 29 will move the entire just-in-time (JIT) compilation process off the main thread. This is currently in their "Aurora" release channel. To the rest of the world: it's an alpha.
This optimization is currently available in Google Chrome Beta (33).
“At some point, since the
“At some point, since the early 1990s, computers have been give multiple cores (and some of those designs can have multiple threads shoved through at once).”
Multithreasing an multitasking has been around since the early 1960, if not a little bit before in research and government labs!
All this stuff the script kiddys think is new and shiny!
Microprocessors were just starting to get what the mainframe computers had as standard 30 years before, and by the 1990s, 24 years before this article was hacked out.
And Multithreasing an multitasking are not a consequence of multicore CPUs it has been available starting with single core processors, long before there were multicore CPUs on microprocessors. You can make a TRS-80 multithread(in software), it is not going to look pretty, or run seamless, but it can be done. Note this is not related to hardware threading done in the CPU core(hyperthreading, etc). but most of the gee whiz stuff incorperated into microprocessors to this day, was invented in the 1960s, 1970s, and early 1980s. the fab processes are new, but the CPU architectural designs in use today were mostly developed in those three decades, and refined to this day.
They are just reinventing the wheel over at the chocolate factory! They need to get some Linux full distro goodness running on those devices, and running on bare metal.
edit Multithreasing to:
edit Multithreasing to: multithreading.
Damn even missspelled words (not the edited word above but some misspellings) are starting to get hits on google searches, those dictionary websites are pure trash now, just there to get more webpage hits, and flash more ads.