BOINC is intended to accommodate participant hosts with a wide range of operating systems and hardware architectures. For example, the hosts may run many versions of Windows (95, 98, ME, 2000, XP) on many processors (486, Pentium, AMD) with many architectural extensions (ATI or NVidia graphics coprocessors). BOINC addresses the following goals:

• The system should avoid sending code that the host can't execute.
• Applications should be able to exploit specific architectural features, i.e. to use nonstandard instructions or coprocessors if available.
• Enough architectural information should be stored on the server so that statistics can be broken down according to specific features.
• Simplicity. The combinatorial explosion of versions and architectures should be excluded from the internals of BOINC.

Design

A platform is a compilation target. A set of platforms is maintained in the BOINC database of each project. Each platform has a name and a description of the range of architectures it can handle. Each BOINC program (core client and application) is linked to a platform.

At the minimum, a platform is a combination of a CPU architecture and an operating system. Examples might include:

name	description
windows_intelx86	Microsoft Windows (95 or later) running on an Intel x86-compatible processor
linux_xxx	Linux running on an Intel x86-compatible processor
macos_ppc	Mac OS 9.0 or later running on Motorola PowerPC
sparc_solaris	Solaris 2.1 or later running on a SPARC-compatible processor

The name of a platform should specify a particular version (e.g. of an OS) only if it uses features new to that version. For example, the platform sparc_solaris2.8 should apply to SPARC machines running Solaris 2.8 or greater.

For simplicity, platforms are assumed to be mutually exclusive: i.e. an application for platform X is not assumed to work on a host running core client platform Y if X <> Y. The BOINC scheduling server will send work to a host only if there is an application version for the same platform.

There should be as few platforms as possible. For example, suppose that there are both Solaris2.6 and Solaris2.7 platforms. Then any host running the Solaris2.6 core client will only be able to run Solaris2.6 applications. Application developers will have to create versions for both 2.6 and 2.7, even if they're identical.

Application optimization for specific architectures

BOINC allows applications to exploit specific architectures, but places the burden of recognizing the architecture on the application developer.

In other words, if you want to make a version of your application that can use the AMD 3DNow instruction set, don't create a new windows_amd_3dnow platform. Instead, make a version for the windows_intelx86 platform that recognizes when it's running on a 3DNow machine, and branches to the appropriate code.

Web-site statistics breakdown by archicture

BOINC collects architecture details about each completed result to allow detailed statistical breakdowns.

First, the core client attempts to find the CPU vendor, the CPU model, the OS name, and the OS version. These are stored in the host record.

Second, applications that recognize even more specific architecure information can pass it back to the core client using the boinc_architecture() function from the BOINC API. This passes a string (project-specific, but typically in XML) to the core client, which records it in the architecture_xml field of the result database record. For example, the application might pass a description like

<has_3dnow_instructions/>
<graphics_board>ATI Rage 64MB

Avoiding platform anarchy

Each BOINC project is free to create its own platforms. To avoid anarchy, however, we recommend that platform creation and naming be coordinated by a single group (currently the SETI@home project at UCB).

Tools

Platforms are maintained in the platform table in the BOINC DB, and can be created using the add utility. "; page_tail(); ?>