The Leading Source for Global News and Information Covering the Ecosystem of High Productivity Computing
December 01, 2006
Where Are We Today?
The general-purpose GPU (GPGPU or GP^2U) computing phenomenon has been gaining momentum over the last three years, and has reached the point where it has gained acceptance as an application acceleration technique. Various innovative uses of GPUs include computing game physics between frames, linear algebra (e.g., LU decomposition), in-situ signal and image processing, database "SELECT" processing, finite element and partial differential equation solvers, and tomography image reconstruction, to name a few. Applications continue to appear on the horizon that exploit the GPU's parallelism and vector capabilities, which was the original intent behind the Supercomputing '06 workshop, "General-Purpose GPU Computing: Practice And Experience".
More broadly, the GPGPU phenomenon belongs to a larger research and commercial area dubbed heterogeneous multi-core computing. Heterogeneous multi-core computing is the fraternal twin of homogeneous multi-core, the more traditional replicated execution unit/core/multiprocessor approach. Innovation in both of these system categories is being driven by a variety of factors that includes physics, "Moore's Gap", the need for increased operations/watt, the need to decrease total power consumption, and the rapidly diminishing "bag of tricks" in super-scalar processor design.
"Moore's Gap" refers to the relatively modest incremental performance gains brought about by the increased number of transistors on current uniprocessor dies despite increases in clock speeds. Today's uniprocessors tend follow a "90/10" rule, where 90 percent of the processor is passive and 10 percent is doing active work. By contrast, multi-core processors follow the same general rule but with 10 percent passive and 90 percent active when working at full throughput. An added benefit is energy efficiency, since inactive cores can be put into hibernation. Another benefit is improved heat dissipation, where workloads can be balanced across the various cores to evenly distribute the generated heat.
Given the rapid change in the multi-core and GPGPU landscapes, the "General-Purpose GPU Computing: Practice And Experience" workshop became dual-tracked. The first track remained true to the workshop's original intent, with current research, practice and experience in GPGPU. Presentations in the GPGPU track included Ian Buck (NVIDIA), Mark Segal (ATI), Dominik Goeddeke (University of Dortmund, Germany), PeakStream and Acceleware. The second track offered insights into the heterogeneous and homogeneous multi-core future, with presentations from IBM, the Los Alamos National Laboratories' "Roadrunner" team, and Burton Smith of Microsoft. The desired outcome from this workshop is a new set of ideas and research directions that help evolve today's multi-core ecosystem.
Heterogeneous multi-core computing itself isn't particularly new: systems have been around since the mid-80's where a problem's workload is split between a general-purpose processor and one or more specialized, problem-specific processors. Notable historical examples include Floating Point Systems' array processors, the Inmos "Transputer" and the Connection Machine. Today's attached processor systems, besides GPUs, include ClearSpeed's accelerator systems and the Ageia PHYSX physics processing unit. In the processor realm, the IBM Cell Broadband Engine (a.k.a., "Cell BE" or simply, "Cell") is the best example of an entirely heterogeneous multi-core processor. The difference today is packaging: these processor systems are delivered as systems-on-a-chip (SOC). The heterogeneous multi-core SOC integration trend is very likely to continue in the future if IBM's Cell or the AMD/ATI merger in the GPGPU domain are indications of commercial trends.
Heterogeneous Multi-Core Challenges
The challenges facing heterogeneous multi-core software development are entirely more interesting than those faced by homogeneous multi-core. At a very general level, homogeneous multi-core systems don't require much, if any, code modification to make existing software work. Code for these systems often requires refinement and tweaking when performance is not as expected, such as the thundering herd hot lock contention that can be experienced on the Sun Microsystems' UltraSparc T1 processors. Making spin locks adaptive, as Sun suggests, remedies the problem. Obviously, poorly implemented code won't run better on homogeneous multi-core, but it suffices to say that the porting challenges are less than would be experienced on heterogeneous multi-core systems.
On the other hand, the software ecosystem for heterogeneous multi-core has several stages of evolution to progress through -- and, hopefully, learning by making better mistakes along the way. The first evolutionary stage is making existing software work. As Rob Pike stated in Systems Software Research Is Irrelevant[1], "To be a viable computer system, one must honor a huge list of large, and often changing, standards: TCP/IP, HTTP, HTML, XML, CORBA, Unicode, POSIX, NFS, SMB, MIME, POP, IMAP, X,... A huge amount of work, but if you don't honor the standards you're marginalized." In the HPC arena, it's at least OpenMP, MPI and potentially PVM, as well as toolkits such as LAPACK, LAPACK++, BLAS, FFTW, VSIPL, VSIPL++, etc.
Task-level parallelism and workload partitioning have been and continue to be the dominant software development issues for multi-core platforms, heterogeneous and homogeneous alike. These issues are more acute on heterogeneous multi-core, since the specialized processors may have additional constraints. The IBM Cell is a good example, in which the symbiotic (or synergistic) processor units (SPUs) have a 256K local store memory. The SPU's local store holds all of the code and data. Consequently, message orchestration becomes another resource management task to keep the SPUs executing close to peak throughput. Another interesting feature of the IBM Cell is the SPU register set that contains 128, 128-bit vector registers ("AltiVec on steroids"). Data orchestration and organization is yet another software developer task required to ensure that the SPU's capabilities are used to maximal advantage. In particular, data orchestration devolves into organizing a problem's data such that it is properly aligned within the vector registers and minimizing the data shuffle overhead (i.e., data movement or realignment within vector registers). Neither data nor message orchestration are insurmountable problems, but they do require an amount of design and forethought to implement properly.
Page: 1 of 2(Digg, Technorati, more)
New Paper: Parallel Computing Without Parallel Programming
Learn how domain experts can run VHLL programs like MATLAB® on a variety of high-performance platforms without low-level reprogramming and how to work with the largest datasets and complex algorithms without sacrificing ease of use or reducing productivity.
Jul 09 | Engineer Live | The demand for computational tools to underpin the 3D seismic interpretation process has never been more apparent. Read more...
Jul 08 | EE Times | Unemployment for U.S. engineers has reached record levels, according to government figures. Read more...
Jul 08 | Network World | Global spending for 2009 projected to drop 6 percent, for a total of $3.2 trillion. Read more...
Jul 08 | Linux Magazine | Portability or efficiency? Neither is guaranteed when writing explicit parallel code. Read more...
Jul 07 | Ars Technica | Japanese company builds custom ASIC to accelerate real-time ray traced rendering for the auto industry. Read more...
Jul 10 | | Engineers, scientists, and other domain experts depend on the productivity enabled by very high-level language (VHLL) tools like MATLAB® and Python. However, as datasets grow larger and programs get more sophisticated, ordinary desktop computers can no longer keep up. The paper explores how to run VHLL programs on high-performance platforms without low-level reprogramming. Work with large datasets and complex algorithms without sacrificing ease of use or reducing productivity.
Apr 14 | | Many HPC IT departments are feeling the rising pressure to deliver more capacity computing and performance while trying to reduce the total cost of ownership. This white paper discusses how an environmentally-friendly and open-standards HPC building block based computing system using flexible interconnect options helps address capacity computing needs.
Source: Addison Snell, GM/VP, Tabor Research; sponsored by Dell
Many organizations that could benefit from the use of HPC clusters find that it is complicated to get the systems up and running because of limited IT resources or the complexities of the clusters themselves. Learn how the Intel Cluster Ready program, for which Dell was an original partner, seeks to address this challenge for entry level and mid-range HPC users.
BlueArc's Titan architecture represents an evolutionary step in file servers by creating a hardware-based file system that can scale bandwidth, IOPS, and overall data capacity well beyond conventional software-based devices. With its ability to virtualize a massive storage pool of up to four usable petabytes of tiered storage, Titan can scale with growing data requirements, offering a competitive advantage for businesses, researchers, or other enterprises seeking to better manage data growth while still ensuring optimal performance.
Sun Studio Compilers and Tools and Sun HPC ClusterTools allow you to create high performance parallel applications for OpenSolaris, Solaris and Linux. Sun Studio Express 11/08 includes MPI performance analysis capabilities and full OpenMP 3.0 compiler support. Learn about all this and the latest in Sun HPC ClusterTools 8.1.