BenchmarkXPRT Blog banner

Tag Archives: Chromium

Web APIs: Possible paths for the AI-focused WebXPRT 4 auxiliary workload

In our last blog post, we discussed one of the major decision points we’re facing as we work on what we hope will be the first new AI-focused WebXPRT 4 auxiliary workload: choosing a Web AI framework. In today’s blog, we’re discussing another significant decision that we need to make for the future workload’s development path: choosing a web API.

Many of you are familiar with the concept of an application programming interface (API). Simply put, APIs implement sets of software rules, tools, and/or protocols that serve as intermediaries that make it possible for different computer programs or components to communicate with each other. APIs simplify many development tasks for programmers and provide standardized ways for applications to share data, functions, and system resources.

Web APIs fulfill the intermediary role of an API—through HTTP-based communication—for web servers (on the server side) or web browsers (on the client side). Client-side web APIs make it possible for browser-based applications to expand browser functionality. They execute the kinds of JavaScript, HTML5, and WebAssembly (Wasm) workloads—among other examples—that support the wide variety of browser extensions many of us use every day. WebXPRT uses those types of browser-based workloads to evaluate system performance. To lay a solid foundation for the first future browser-based AI workload, we need to choose a web API that will be compatible with WebXPRT and the Web AI framework and AI inference workload(s) we ultimately choose.

Currently, there are three main web API paths for running AI inference in a web browser: Web Neural Network (WebNN), Wasm, and WebGPU. These three web technologies are in various stages of development and standardization. Each has different levels of support within the major browsers. Here are basic overviews of each of the three options, as well as a few of our thoughts on the benefits and limitations that each may bring to the table for a future WebXPRT AI workload:

  • WebNN is a JavaScript API that enables developers to directly execute machine learning (ML) tasks on neural networks within web-based applications. WebNN makes it easier to integrate ML models into web apps, and it allows web apps to leverage the power of neural processing units (NPUs). WebNN has a lot going for it. It’s hardware-agnostic and works with various ML frameworks. It’s likely to be a major player in future browser-based inference applications. However, as a web standard, WebNN is still in the development stage and is only available in developer previews for Chromium-based browsers. Full default WebNN support could take a year or more.
  • Wasm is a binary instruction format that works across all modern browsers. Wasm provides a sandboxed environment that operates at near-native speeds and takes advantage of common hardware specs across platforms. Wasm’s capabilities offer web developers a great deal of flexibility for running complex client applications in the browser. Simply put, Wasm can help developers adapt their existing code for additional platforms and browser-based applications without requiring extensive code rewrites. Wasm’s flexibility and cross-platform compatibility is one of the reasons that we’ve already made use of Wasm in two existing WebXPRT 4 workloads that feature AI tasks: Organize Album using AI, and Encrypt Notes and OCR Scan. Wasm can also work together with other web APIs, such as WebGPU.
  • WebGPU enables web-based applications to directly access the graphics rendering and computational capabilities of a system’s GPU. The parallel computational abilities of GPUs make them especially well-suited to efficiently handle some of the demands of AI inference workloads, including image-based GenAI workloads or large language models. Google Chrome and Microsoft Edge currently support WebGPU, and it’s available in Safari through a tech preview.

Right now, we don’t think that WebNN will be fully out of the development phase in time to serve as our go-to web API for a new WebXPRT AI workload. Wasm and/or WebGPU appear to our best options for now. When WebNN is fully baked and available in mainstream browsers, it’s possible that we could port any existing Wasm- or WebGPU-based WebXPRT AI workloads to WebNN, which may open the possibility of cross-platform browser-based NPU performance comparisons.

All that said and as we mentioned in our previous post about Web AI frameworks, we have not made any final decisions about a web API or any aspect of the future workload. We’re still in the early stages of this project. We want your input.

If this discussion has sparked web AI ideas that you think would benefit the process, or if you have feedback you’d like to share, please feel free to contact us!

Justin

An update on Chrome OS XPRT benchmark development

In July, we discussed the Chrome OS team’s decision to end support for Chrome apps, and how that will prevent us from publishing any future fixes or updates for CrXPRT 2. We also announced our goal of beginning development of an all-new Chrome OS XPRT benchmark by the end of this year. While we are actively discussing this benchmark and researching workload technologies and scenarios, we don’t foresee releasing a preview build this year.

The good news is that, in spite of a lack of formal support from the Chrome OS team, the CrXPRT 2 performance and battery life tests currently run without any known issues. We continue to monitor the status of CrXPRT and will inform our blog readers of any significant changes.

If you have any questions about CrXPRT, or ideas about the types of features or workloads you’d like to see in a new Chrome OS benchmark, please let us know!

Justin

CrXPRT support through 2022

CrXPRT testers may remember that back around the time that we began the CrXPRT 2 development process, the Chrome team announced that they were phasing out support for Portable Native Client (PNaCL) in favor of WebAssembly (WASM). As a first step, they changed the Chrome OS setting that enabled PNaCL by default. At the time, this caused problems with the Photo Collage workload in CrXPRT 2015, and even though we identified a workaround, details in the Chrome team’s announcement led us to conclude that the workaround might stop working in June 2021. Because of this change, we decided that the best decision would be to remove the workload from CrXPRT 2, and keep existing CrXPRT 2015 testers informed of any changes with the workaround.

In 2020, the Chrome team also announced that they would be phasing out support for Chrome Apps altogether starting in June 2021, and would shift their focus to Chrome extensions. This change would have required us to reassess the viability of CrXPRT in anything like its current form.

We’re happy to report that the Chrome team has extended support for PNaCL and existing Chrome Apps through June 2022. Barring further changes, this means that CrXPRT 2015 (with the workaround) and CrXPRT 2 should continue to serve as reliable Chrome OS evaluation tools for some time.

If you have any questions about CrXPRT 2, please let us know!

Justin

A CrXPRT fix for Chrome 76

After Chrome OS version 76 moved from Chrome’s Beta channel to the Stable channel last week, we became aware of an issue that occurs when CrXPRT’s Photo Collage workload runs on a Chrome 76 system. We found that the Photo Collage workload produces an error message—“This plugin is not supported on this device”—and the test run does not complete.

The error occurs because the Photo Collage workload uses Portable Native Client (PNaCl), and starting with version 76, the Chrome team changed the way the OS handles PNaCl tasks. Technically, Chrome still supports PNaCl, but the OS now disables the capability by default. Chrome’s current plan is to end support for PNaCl by the end of this year, focusing related development efforts on WebAssembly instead.

We’ll investigate the best path forward during this transition, but for now, testers can use the following workaround that allows CrXPRT to complete successfully. Simply navigate to chrome://flags on the test system, and find the Native Client flag, which is set to “Disabled” by default. Click the toggle switch to “Enabled” to allow native client capabilities, restart the system, and kick off a CrXPRT test in the normal manner.

We’ll update the CrXPRT web page and test documentation to include information about the workaround. In the long term, we’re interested in any suggestions you have for CrXPRT—whether they’re related to PNaCl or not. Please let us know your thoughts!

Justin

A new playing field for WebXPRT

WebXPRT is one of the go-to benchmarks for evaluating browser performance, so we’re always interested in browser development news. Recently, Microsoft created a development channel where anyone can download early versions of an all-new Microsoft Edge browser. Unlike previous versions of Edge, Microsoft constructed the new browser using the Chromium open-source project, the same foundation underlying the Google Chrome browser and Chrome OS.

One interesting aspect of the new Edge development strategy is the changes that Microsoft is making to more than 50 services that Chromium has included. If you use Chrome daily, you’ve likely become accustomed to certain built-in services such as ad block, spellcheck, translate, maps integration, and form fill, among many others. While each of these is useful, a large number of background services running simultaneously can slow browsing and sap battery life. In the new Edge, Microsoft is either reworking each service or removing it altogether, with the hope of winning users by providing a cleaner, faster, and more power-efficient experience. You can read more about Microsoft’s goals for the new project on the Microsoft Edge Insider site.

As we’ve discussed before, many factors contribute to the speed of a browsing experience and its WebXPRT score. It’s too early to know how the new Microsoft Edge will stack up against other browsers, but when the full version comes out of development, you can be sure that we’ll be publishing some comparison scores. I’ve installed the Dev Channel version of Edge on my personal machine and run WebXPRT 3. While I can’t publish the scores from this early version, I can tell you that the results were interesting. Have you run WebXPRT 3 on the new Microsoft Edge? How do you think it compares to competitors? We’d love to hear your thoughts.

Justin

Check out the other XPRTs:

Forgot your password?