Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU |
On 07/13/2010 10:26 AM, Dan Ritter wrote: >> > A number of processes make sense for parallel processing, but its ha= rd=20 >> > to do. People in the industry are complaining that it is a "language= =20 >> > issue" in that we don't have the languages to express parallel=20 >> > processing well. Maybe. >> =20 > It's a brain issue, because it's hard for users and programmers to thin= k > in parallel terms. > > =20 We've had language extensions for parallel computing for many years, such as Posix Threads as well as spawning and forking. We've had compilers, assemblers, and chips that can reorder instructions to improve parallel computing. In my experience, most application programmers have little or no experience with threads, or other forms of parallelism. In addition, a lot of the stock math libraries, like LAPACK, don't take parallelism into account. But, in support of Mark's comment, a good parallelized application needs to take parallelism into account by design. Most modern computer languages are relatively easy to program for threads or forking, but a poor design could make the entire parallelized applicaiton slower. --=20 Jerry Feldman <gaf-mNDKBlG2WHs at public.gmane.org> Boston Linux and Unix PGP key id: 537C5846 PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB CA3B 4607 4319 537C 5846
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |