feature article
Subscribe Now

Measuring Air

Browser Benchmark Diagnoses End-to-End Connections

How fast is your browser? Not fast enough, I’m sure. But pinning down the actual speed of a Web browser is a tricky thing. It might be fast at rendering images but be stuck with a slow TCP/IP stack. Or it may be quick at interpreting JavaScript applets but suck at Flash animation. If you’re a programmer, creating and debugging an embedded browser is a big, complex project that opens up a whole big stack of interrelated bits and pieces that can go wrong.

To help you wade through this complexity, the nice folks at the Embedded Microprocessor Benchmark Consortium (EEMBC for short) have created BrowsingBench, “a tool that determines the effectiveness of hardware and software in processing and displaying Web pages.” BrowsingBench digs into why your browser is slow—or where it’s fast—so that you know where to focus your efforts. 

There are a couple of browser benchmarks available already, but EEMBC believes its BrowsingBench is unique in providing an end-to-end diagnostic of all the layers and components that make up the end user’s experience. For example, it measures everything from the first mouse click (or screen tap) on a link all the way until the entire page is loaded and rendered. BrowsingBench is available to any EEMBC member.

To make it more of a “real world” test than other synthetic benchmarks, BrowsingBench uses actual Web content, such as Google, Yahoo, Wikipedia, and other sites that an end user is likely to visit. (The content has been frozen to avoid day-to-day variances in benchmark results.) All the content is delivered from a live Apache server, so there are no canned or cached pages as part of the test. It’s that server, not the client being tested, that measures loading and rendering times. This avoids problems (and outright cheating) by clients that don’t have accurate clocks or timers, and makes results more repeatable and verifiable.

BrowsingBench works on pretty much any of the standard browsers, including Internet Explorer, Safari, Firefox, and Opera. JavaScript is about the only required element. You can even dial-in extra latency to simulate slow wireless connections. The Flash component can be turned off for browsers that (ahem) choose not to support it. If you’re building a device with an embedded browser, you should check it out.

In other news, last week saw the conclusion of the 23rd annual Hot Chip conference at Stanford University. Held at, though not by, Leland Junior’s eponymous campus, it featured the usual assortment of nerds with PowerPoint slides. Adding to the milieu was your humble narrator, hosting an evening panel entitled “The Ecosystem Wars: It’s Not Just About Architecture.”

On the panel, we had representatives from Intel and ARM, the two processor companies that come most readily to mind for embedded designers; speakers from two software companies; and for variety one participant who was a PhD CPU designer, Air Force pilot, and IEEE Fellow.

We quickly agreed that yes, ecosystems are important, but rapidly diverged on what “ecosystem” means in the context of engineering development. Sure, it includes the compilers and debuggers available for a specific chip; maybe also the operating systems and EDA tools. But are motherboards part of the ecosystem? What about batteries, open-source software, or training courses? To some, the ecosystem included absolutely everything but the chip itself. Which may be correct.

Interestingly, the ARM speaker credited that company’s business model for the growth and success of its ecosystem. ARM’s customers—the company prefers to call them partners—succeed precisely because ARM doesn’t make chips. Instead, it provides a “framework” or a “platform” on which software, tool, and silicon companies can base their own products.

In direct contrast, the Intel representative made the same claim by crediting his employer’s business model, even though it’s diametrically opposed to ARM’s. The two companies could not be more different in terms of how they engage with developers, yet both were convinced (in public, at least) that their approach was the exact right one for nurturing a big, strong, happy ecosystem. Such is the nature of competition.

It’s hard to argue with success. At last count, there were 12 times more ARM processors in the world than Intel processors. Twelve times! That’s a whole order of magnitude and then some. Use that factoid to win your next bar bet. And ARM is a much younger company than Intel, so it’s achieved this remarkable popularity in less time.

And yet ARM isn’t nearly as rich as Intel. Wall Street values ARM at $30 billion while Intel is worth $100 billion. So even though ARM’s chips are more popular, Intel is still worth more as a company. That’s because Intel builds and sells actual chips, while ARM merely waves its corporate hands pontifically, intoning “thou art hereby granted permission to make chips in my image.” ARM collects a small royalty (on the order of 5–25 cents) for each chip, while Intel sells physical chips at full price and keeps all the money. For all of ARM’s popularity and success, Intel still seems to have the more lucrative business model.

Toward the end of the panel, we tossed around the idea of new CPUs succeeding in today’s market. If you introduced a brand new CPU architecture today, would it have any chance of success? Or would the combined ecosystems of all the established processor vendors present an irresistible force that’s impossible to overcome?

Certainly ecosystems present a strong barrier to entry. The established players (Intel, ARM, MIPS, Freescale, PowerPC, etc.) all have tools and software that a newcomer wouldn’t have. Any neophyte processor company would have to develop a parallel ecosystem, a process that takes years and costs million of dollars. Any new processor family would have to be clearly superior to—not just different from—existing chips to stand any chance of survival. Making processors is the easy part; building third-party support for them is a killer. 

Leave a Reply

featured blogs
Sep 26, 2022
Most engineers are of the view that all mesh generators use an underlying geometry that is discrete in nature, but in fact, Fidelity Pointwise can import and mesh both analytic and discrete geometry. Analytic geometry defines curves and surfaces with mathematical functions. T...
Sep 22, 2022
On Monday 26 September 2022, Earth and Jupiter will be only 365 million miles apart, which is around half of their worst-case separation....
Sep 22, 2022
Learn how to design safe and stylish interior and exterior automotive lighting systems with a look at important lighting categories and lighting design tools. The post How to Design Safe, Appealing, Functional Automotive Lighting Systems appeared first on From Silicon To Sof...

featured video

PCIe Gen5 x16 Running on the Achronix VectorPath Accelerator Card

Sponsored by Achronix

In this demo, Achronix engineers show the VectorPath Accelerator Card successfully linking up to a PCIe Gen5 x16 host and write data to and read data from GDDR6 memory. The VectorPath accelerator card featuring the Speedster7t FPGA is one of the first FPGAs that can natively support this interface within its PCIe subsystem. Speedster7t FPGAs offer a revolutionary new architecture that Achronix developed to address the highest performance data acceleration challenges.

Click here for more information about the VectorPath Accelerator Card

featured paper

Algorithm Verification with FPGAs and ASICs

Sponsored by MathWorks

Developing new FPGA and ASIC designs involves implementing new algorithms, which presents challenges for verification for algorithm developers, hardware designers, and verification engineers. This eBook explores different aspects of hardware design verification and how you can use MATLAB and Simulink to reduce development effort and improve the quality of end products.

Click here to read more

featured chalk talk

Tackling Automotive Software Cost and Complexity

Sponsored by Mouser Electronics and NXP Semiconductors

With the sheer amount of automotive software cost and complexity today, we need a way to maximize software reuse across our process platforms. In this episode of Chalk Talk, Amelia Dalton and Daniel Balser from NXP take a closer look at the software ecosystem for NXP’s S32K3 MCU. They investigate how real-time drivers, a comprehensive safety software platform, and high performance security system will help you tackle the cost and complexity of automotive software development.

Click here for more information about NXP Semiconductors S32K3 Automotive General Purpose MCUs