MIPS’ MT technology boosts performance 43 percent; combined MT & MC boosts performance 150 percent

By Eyal Barzilay, Applications and Benchmarking Manager

The use of multi-core technology to deliver more CPU horsepower is one of the increasingly common methods to providing higher system performance in hardware. This is true even for high volume consumer applications where cost and power can be very important. However, upgrading to a multi-core system doesn’t automatically guarantee performance improvements or an enhanced user experience. It’s not just a hardware problem – software must be written in a way that can make use of parallel hardware resources. But software is adapting – systems are getting much more complex, such that multiple processes and threads are running simultaneously in many cases, and applications are being written to take better advantage of multiprocessing hardware trends.

With that in mind, we recently used the BrowsingBench™ benchmark from EEMBC to evaluate the performance benefits of MIPS’ multi-core (MC) and multi-threading (MT) technologies. Our objective was to find out how these technologies enhance the user experience of a very popular and very real consumer application – web browsing on the Android™ software platform.

BrowsingBench is a credible and widely used tool that is trusted and cited by leading technology companies. It measures web page loading and rendering time for a large set of web pages with diverse content, and it does this in a reliable way which leads to repeatable and meaningful results. It will run on any connected device with a web browser. And rather than performing a synthetic test, BrowsingBench performs the same operations which a human would perform on the device. We’ve used several other benchmarks in the past that were suitable for evaluating MC/MT system performance; however none represented the real-world user experience on connected devices as well as BrowsingBench.

We ran BrowsingBench on a system based on the MIPS32® 1004K™ Coherent Processing System (CPS). In its maximum implementation, the 1004K CPS can support up to four cores and two hardware threads (also known as Virtual Processing Elements or VPEs) per core. To keep things simple for this test however, the configuration we used was dual core with two VPEs per core, for a total of 4 VPEs. VPEs are essentially logical CPUs that share one physical pipeline in each 1004K core, based on MIPS’ multi-threading technology.

The software platform running on our system was Android, and the web browser we used was the Android browser which comes with every Android-based system.

To evaluate the benefits of multiple cores and VPEs on web browser performance, we ran BrowsingBench using the 4 different configurations listed in the table below. In all cases, the tests were executed on the same dual-core 1004K system; however we used the operating system to enable and disable cores and VPEs.

The big question we wanted to answer was whether Android would be able to take advantage of these multiple processing resources to load and render web pages faster, thereby enhancing the user experience. To do that, Android would have to use parallel processes and threads while executing the browsing workload.
The results, which are shown in the table and chart below, leave no doubt: Android based web browsing performance is greatly enhanced by MC and MT technologies.

The main observation is that browsing performance improves more than 2.5x when comparing the full configuration to the basic configuration. With a great deal of parallel execution under Android, the browser can truly benefit from the combination of MT and MC. A closer look at what’s happening under the hood in the Android system indeed shows that a lot of processes are running in parallel. The two main processes in the system are the Android Browser itself and another process called “system server,” which manages many components of Android including the display system, and is kept very busy during the BrowsingBench run.

Even if we limit the system to a single core, the MIPS MT technology gives us a BrowsingBench performance boost of 43 percent. One of the primary attributes of MT is to improve performance efficiency of a core, which it does by increasing the pipeline utilization of that core when multiple processes and/or threads are running. So for systems where silicon real estate is at a premium, choosing a multithreaded core can be a great way to boost system performance.

When multi-core and multi-threading systems were first introduced into the marketplace, most existing software was not optimized to make good use of these technologies. Today this is changing. Android is a complex software platform, and a perfect example of a high volume consumer platform that is quickly evolving and being optimized for optimal user experience in a Web-connected world.

At MIPS we are very pleased with the benchmark results because they demonstrate that our MC and MT technologies deliver much higher performance than the standard hardware used only a few years ago, and make a significant impact to end users of many connected devices from smart phones and tablets to connected DTVs.

MIPS Moves Quickly with Android 4.0.3 and LLVM

Android 4.0.3 came out from Google on Friday December 16th and who could resist the challenge? So, MIPS engineers picked up the release from the Google source tree and ported it to MIPS within 24 hours. In fact, they decided to push through the weekend and bring 4.0.3 up on the Ingenic/Ainol tablet. Thus we were able to give Ainol a head start towards an over the air (OTA) upgrade for tablets sold to-date plus schedule a switch over to 4.0.3 for new tablets.

But there is more here than just our dedication to supporting MIPS’ licensees and the Android community …

Android 4.0 expands on Google’s use of LLVM, and MIPS completely supports this initiative – in fact, when Google adopted LLVM 3.0 as the basis of Renderscript in Android 4.0.3, MIPS support was already available. So, what is LLVM, and why is it important for the Android community?

LLVM – Low Level Virtual Machine – is an umbrella for modular compiler technologies. It includes a C/C++ compiler front-end, a portable code generator supporting a wide variety of architectures, an aggressive optimizer, and an efficient just-in-time (JIT) compiler on the back-end. Renderscript, the first technology in Android to use LLVM, first became popular in HoneyComb (Android 3.0)–as a set of low-level APIs targeting 3D rendering and compute operations. In fact Renderscript is an example of using the  high-performance APIs provided by LLVM to achieve the same level of system performance that developers could expect were they instead to  use native code on the underlying device. But unlike the existing Android native development kit (NDK), this solution is cross-platform – meaning that applications built using this technology can run on several architectures supported by LLVM.

The inclusion of MIPS optimizations for LLVM in Google’s Android 4.0.3 release takes a great step in making LLVM available for more general use by app developers seeking to exploit native processor performance and capabilities while retaining complete portability in the Android universe.

So what’s behind this LLVM push for Android?

MIPS actually became involved in the industry’s LLVM initiative over a year ago – before it became generally available in Android. This was when MIPS’ compiler group realized that LLVM was going to be a major basis for applications in the future. LLVM had already been the basis of Apple’s application environment for the iPhone and iPad. Our engineers felt that it was only a matter of time before it became the basis of application development environments in the wider market.

We were clearly not alone in our thinking, and so LLVM first appeared in Android.

By supplying our LLVM technology for the MIPS architecture to Google, we have enabled all MIPS licensees, their OEMs and application developers targeting their platforms to have access to the best possible execution environment on MIPS-based platforms, starting with Android 4.0.3. Of course, as Android moves forward, MIPS will make further refinements to LLVM on the MIPS architecture available to Google. We will also make available other optimizations and software related to improving Android’s “out of the box” support for the MIPS architecture.

Android has become an enormous force in the consumer electronics market – a market in which MIPS’ legendary performance, power efficiency and cost effectiveness have been well recognized. The MIPS architecture has already been adopted widely on just about every type of consumer device … cell phones, tablets, set-top boxes, and digital TVs to name a few.

The inclusion of support for the MIPS architecture directly in this latest key facility of Android provides an even more attractive future for all of our licensees and their customers – and ultimately for the end users who continually seek out the best price/performance products available in the market and rely on those products in their day to day lives.

MIPS is moving forward with Android – as always, we are focused on going beyond simply what the market is demanding. We know that providing an enriched apps development environment benefits all end users. More apps, anywhere and any time, running on Android, running on MIPS!

Baseband processors for mobile devices typically run at as slow a clock speed as possible in order to minimize power consumption, generally in the order of 250-500MHz. However, the latest air interface standards are dramatically increasing throughputs, which is putting pressure on baseband processors to increase their performance, while simultaneously reducing latency.

It doesn’t take a rocket scientist to figure out why. LTE, or Long Term Evolution, is the latest air interface standard and is currently available from operators like Verizon, NTT DoCoMo and Telia Sonera. LTE represents a greater than 50x increase in maximum user data from its 3G predecessor, W-CDMA, in its maximum configuration (of course, we all know that theoretical maximum data rates are never achieved, nevertheless, the point is still valid). Due to the real time nature of baseband data, this huge increase in data must still be processed in real time. So the only way for a baseband system to compensate for the increased throughput is to significantly decrease latency. For this reason, the Time Transmission Interval (TTI) for LTE is a mere 1ms, compared to 10ms for W-CDMA. TTI is essentially the length of time to transmit a block of data. Bottom line, the need to process and transmit more than an order-of-magnitude increase in data is creating significant performance demands on cellular baseband processors. This is also true of the next generation WiFi standard, 802.11ac, which promises 1Gbps of data.

Typically, performance increases in both the user and control plane come from increasing the clock frequency of the processor. Of course, this is counter-productive to power consumption, which is why this is generally not favored in the first place. Hence, another alternative is to go multi-core, which is a common means of distributing the processing load to achieve higher performance without having to greatly increase the clock frequency. While this does increase static power consumption due to the increase in transistor count, it is less significant than the increased dynamic power consumption associated with doubling the clock frequency. Multi-core also has the downside of the potential additional licensing and royalties of the 2nd core, as well as the increased manufacturing cost from the greater die size.

Fortunately, these are not the only possibilities. Another possibility is to use hardware multi-threading, which can made a processor core look like two cores, each of which could run an independent OS or RTOS. In this case, the processing load is distributed across what appears to the RTOS to be two cores. In the MIPS32® 34K® core, these are known as VPEs, or Virtual Processing Elements. With a multi-threaded core, the increase in die size is relatively small and there is no need to pay a license fee or royalties for a second core. Furthermore, latency can be significantly decreased since threads can be parked and revived with a zero overhead context switch, hence achieving the two main technical requirements. One of our baseband customers simulated its multi-mode modem and found that with MIPS multi-threading, processor stalls were reduced by over 20%! All of this leads to an improved mobile device user experience, as responsiveness is greatly increased.

The biggest downside to usage of hardware multi-threading is some increase of software complexity, and porting of legacy software. Software which runs single-threaded must be re-architected in order to fully exploit the benefits of multi-threading. While this is not a complete re-write, it can be substantial. Of course, the same is also true of multi-core, so software which supports multi-threading is an inevitability. So regardless, this needs to be done. The exact level of effort depends largely on how well the code is structured (the more modular, the better), written, and documented. For a multi-mode modem, the code can be partitioned in a few different ways to exploit multi-threading while minimizing the porting cost. Stay tuned for my next post to learn more!

So the answer to the question above is, of course, it depends. It depends on the application requirements, particularly the power threshold. But for mobile baseband processors, clearly multi-threading provides a solution that increases performance significantly in a much more power friendly manner than doubling the clock speed or going multi-core.

For additional information on multi-threading, please go to: http://www.mips.com/mtp/.