Everything about Web and Network Monitoring

For Performance, Use Parallel Processing

by | Jun 14, 2012

If a client machine’s CPU is over-utilized and it has only one processor, parallel processing will not improve performance; it may actually make it worse. However, if the machine has multiple processors and low CPU utilization, parallel processing will improve performance.Parallel processing occurs when sequences of code are executed simultaneously. There is some small overhead to set up and manage this process, which is why parallel processing can negatively impact performance on maxed-out computers. However, it is expected that the majority of client machines, even those with only one processor, will show performance improvements.EcmaScript’s and JavaScript’s definitions do not define any level of parallel processing. These languages are usually thought of as single-threaded, but there is some Internet discussion about how to remove that restriction.

Is It Worth the Effort

Fortuna, et aladdresses the potential impact of parallel processing in JavaScript. It concludes that “JavaScript exhibits great potential for parallelization – speedups over sequential execution are 8.9x on average and as high as 45.5x.” That’s not a micro-optimization!Tasks are the finest granularity at which this paper considers parallelism. A task is defined as “any consecutive stream of executed opcodes in an event, delimited either by a function call, a function return, an outermost loop entrance, an outermost loop back-edge, or an outermost loop exit.” Because of this approach, other possible parallelisms are ignored, which means the potential for performance improvements may be larger than what this paper finds.

The Silence of the Standards

Because the perception of fast is more important than actually being fast, achieving interactivity at the earliest possible moment is the developer’s key performance objective. If the point of interactivity has to wait for components to be downloaded and scripts to be executed, a negative perception of performance is created. There are several tips that tell us how to download and execute after achieving interactivity, but the most popular ones are mostly kludges and none are standardized.EcmaScript, the base language upon which JavaScript is built, is defined in ECMA-262. ECMA-262 does not mention threads, concurrency, atomic operations, or any form of multitasking. It’s left totally up in the air.JavaScript wraps EcmaScript in a web-browser environment, but does not add parallel processing to the language.While the standards leave the language open to parallel processing, they define nothing to support it. Being completely open will lead to multiple approaches and definitions, which will cause confusion. However, since parallel processing in JavaScript is in its infancy, this openness is necessary to foster creativity. Eventually, though, standards will be needed.

Preemptive Multitasking and Priority-Based Scheduling

To reach interactivity at the earliest possible moment, the developer needs to be able to spin off tasks that can be executed after interactivity has been achieved. However, it is important that we be able to prioritize these tasks without jumping through too many hoops. Tasks that lead up to the point of interactivity, including above-the-fold images, are the highest priority. Tasks that populate the rest of the page are a lower priority. Third-party components and ads can be even lower. Tasks that download and cache components that will be used on the next page are last.Priority-based scheduling allows us to download the needed-now components before the needed-soon components, and the needed-soon components before the maybe-needed-latercomponents.Tasks that are assigned priorities and spun off can be executed sequentially (like they are now), but the order in which they are executed should be determined by their priority levels. Creating a priority-based scheduling system is a simple change to the EcmaScript standard, and it would make it easier for programmers to execute deferred code in the order that yields the best performance.Although parallel processing and preemptive multitasking are not strictly required for us to have priority-based scheduling, they are expected to further enhance performance. They can be added later, after we properly consider interprocess (or interthread) communication, atomicity, race conditions, and all the other complexities that go along with parallelism.

Preemptive multitasking and priority-based scheduling are already available in most operating systems. Perhaps this wheel does not have to be reinvented.

The Developer’s Role

Even if we do achieve true parallelism in JavaScript, developers will need to write parallelism-friendly code. Not many have this skill today. Some form of training will be required, and not just for the few.

Conclusion

Priority-based scheduling allows the developer to execute deferred code in the order that yields the best performance. This is a simple change to the EcmaScript standard.True parallelism, along with preemptive multitasking, will further enhance performance. Adding it to the standard is not quite as easy, so it should be done as a second step. Hooking into the operating system’s scheduler would save us from reinventing the wheel, but is this a viable approach?

References

“A Limit Study of JavaScript Parallelism” by Emily Fortuna, Owen Anderson, Luis Ceze, & Susan Eggers.  Published by the University of Washington at cs.washington.edu/homes/luisceze/publications/fortuna-iiswc2010.pdf.
Post Tagged with

Category: Website Performance | Tagged No Comments.

About Warren Gaebel

Warren wrote his first computer program in 1970 (yes, it was Fortran).  He earned his Bachelor of Arts degree from the University of Waterloo and his Bachelor of Computer Science degree at the University of Windsor.  After a few years at IBM, he worked on a Master of Mathematics (Computer Science) degree at the University of Waterloo.  He decided to stay home to take care of his newborn son rather than complete that degree.  That decision cost him his career, but he would gladly make the same decision again. Warren is now retired, but he finds it hard to do nothing, so he writes web performance articles for the Monitor.Us blog.  Life is good!