Login

Important information

This site uses cookies to store information on your computer. By continuing to use our site, you consent to our cookies.

ARM websites use two types of cookie: (1) those that enable the site to function and perform as required; and (2) analytical cookies which anonymously track visitors only while using the site. If you are not happy with this use of these cookies please review our Privacy Policy to learn how they can be disabled. By disabling cookies some features of the site will not work.

ARM Community: Software Enablement - ARM Community

Jump to content

Comparison of JavaScript execution modes of the WebKit browser engine

Nowadays web browsers are among the most widely used software tools. You can find them being used everywhere on devices ranging from phones and tablets to personal computers. The heart of all browsers is a browser engine. We, at the Department of Software Engineering, University of Szeged, Hungary, are long time contributors of a well-known browser engine called WebKit. We have worked on quite a few areas of WebKit including the JavaScript engine, multicore support, graphics and the building and testing environment. In this blog post we show the different execution modes of the JavaScript engine and compare their performance.

JavaScriptCore
The JavaScript execution engine of WebKit is called JavaScriptCore. It is a profiling virtual machine which supports various optimization levels. A higher optimization level offers better runtime performance, but its trade-off is longer compilation time. Each optimization level corresponds to an execution mode. At the moment JavaScriptCore has three execution modes. The basic execution mode is the interpreted execution model provided by the LLInt (Low Level Interpreter) component. The next level is translating the JavaScript source code into native code by the JIT (Just-in-t...

New Platform Bring-Up with ARM® Development Studio 5 (DS-5™)

I am an FAE at ARM, and part of my job is to support users bringing up new silicon and hardware platforms, so that they can start to develop software on them. For this task, I use the ARM DSTREAM™ debug and trace unit and the various bring-up utilities provided with the DS-5 toolchain, which enable the creation of device support in the DS-5 Debugger. I decided to write this blog to describe how I use these tools, and to encourage you to do the same. Our configuration database is aware of over 100 standard platforms today. We would like to add many more, and you can help.

I will talk about the configuration tools provided to get you going quickly and easy, as well as diagnosis tools should things go wrong. If you need to go further, the python based Debug and Trace Services Layer (DTSL) provides the key to unlocking all the debug features.

In the below examples I use the ARM ...

DS-5 Streamline Performance Analyzer on Allwinner Android 4.0 HDMI Dongle

ARM® DS-5TM Streamline Performance Analyzer, part of the ARM DS-5 toolchain, is an useful tool for developers doing system level software optimization for ARM Linux and Android platforms. Streamline makes it easy for platform and app developers to mitigate performance bottlenecks, improve code parallelization, extend battery life, and enhance user experience. With Streamline Performance Analyzer you can:
Find out where the CPU is spending more time, optimize it and speed up your codeMonitor actual power, current and voltage, and optimize compute tasks for the best efficiency Analyze and optimize Mali™ GPU, monitor CPU and GPU cache usage and system memory
To use the DS-5 Streamline Performance Analyzer users/developers first have to build DS-5 Gator driver/daemon to setup their own target. It is very inconvenient, especially for those application/app middleware developers who do not care what the target device is and do not have easy access to the ke...

Spotlight on the Linux Software Ecosystem - openSUSE

Continuing my “Spotlight on the Linux software Ecosystem”, this time I am going to cover the openSUSE Project.

Attached Image

openSUSE is not only one of the major Linux distributions, but is also one of the oldest distributions tracing its history back to 1996 when it was called S.u.S.E. (an acronym for Software und System Entwicklung); it is also the upstream project for the well known SUSE Linux Enterprise distribution (SLE). As with many distributions, it offers a large array of Open Source software as part of the core distribution and much more via the Open Build Service. In contrast to its peers, openSUSE is a relatively new comer to the ARM community with a concerted effort over the past two years to enable support for ARM. The project focuses the current ARMv7 and upcoming ARMv8 versio...

ARM Cortex-A Processors and GCC Command Lines

The GNU Compiler Collection’s (GCC) command line options for ARM processors were originally designed many years ago when the list of available processors and variants was much shorter than it is today. As the ARM architecture has evolved, the options needed to get the best code out of the GCC have also changed, but attempts have been made to ensure that existing sets of options don't change their meaning. The design of the compiler means that the options needed to get the best out of your ARM CortexTM-A processor are now quite complex. This blog covers three areas of GCC’s command line options: CPU, floating point and SIMD (Single Instruction, Multiple Data) acceleration.

What options should I use for my CPU?
Firstly, let's look at the key options for telling the compiler about the CPU you are using; later on we'll discuss some more advanced options that can be used in special cases.

Whenever you compile a file, the compiler needs to know the type of CPU that you intend to use to run the resulting code. The primary option for doing this is the -mcpu=<cpu-name> option. As you might expect, t...
  • (25 Pages)
  • +
  • 1
  • 2
  • 3
  • Last »
All company and product names appearing in the ARM Blogs are trademarks and/or registered trademarks of ARM Limited per ARM’s official trademark list. All other product or service names mentioned herein are the trademarks of their respective owners.