January 2008 Archive

What real physics can do for animation (video)

posted by Sean Koehl on January 25, 2008

Check this video out. These are special effect animations using physical modeling techniques, devloped Prof. Ron Fedkiw’s group at Stanford (see Jerry’s previous blog). Intel collaborates with Ron’s group to parallelize, analyze, and scale the performance of Prof. Fedkiw’s PhysBAM, physical simulation package for present and future Intel multi-core processor platforms.

Continued

Comments (1)
tagged: physical modeling, terascale

C for Throughput Computing

posted by Anwar Ghuloum (葛安华) on January 03, 2008

One of the challenges of enabling parallel computing broadly is that there is (understandably) some inertia around migrating programming tools, build environments, and, generally, 100’s of thousands or millions of lines of code to new programming models or compilers (especially those of a proprietary nature). This was at the forefront of our minds when we started researching a programming model for Throughput Computing. More generally, there is little value to the software developer in designing a programming model or language from the bottom-up (from micro-architecture) or in an applications vacuum. (We’ll let the architectures evolve to efficiently support a useful programming abstraction, though we’re not too far away from that.) We came to the inescapable conclusion that, at least for the near term, any successful effort at building a new programming model had to satisfy the following requirements:

1. It has to work with the prevailing tools. This includes VC++, GCC, and ICC to start with, then all the libraries/APIs/frameworks that are already being used.
2. It has to be adoptable incrementally, without placing undue burden on the programmer to completely restructure their application. The typical tuning nightmare for parallelization or vectorization optimizations is the “transposing” of performance paths out of their natural locations, embedded within and across various object hierarchies.
3. It cannot force the programmer to fundamentally change the algorithmic and data-container idioms of their applications.

With this in mind, I’m going to introduce Ct, which is short for C (really, C++) for Throughput Computing. An overly facile view of Ct is that it is simply a parallel-ready version of the container types C++ programmers already use (e.g. valarray). However, even a cursory inspection will reveal that there is much more to Ct than this. In this blog, I’ll describe briefly what Ct is now and what it will be in the not-too-distant future. We know Ct isn’t perfect (is any programming model?), but we’re striving to make it as close as possible so your comments and criticisms are most welcome.

Continued

Comments (7)
tagged: parallel programming, programming models, software development