Comments on: Where’s the Parallel Beef? http://www.linux-mag.com/id/8577/ Open Source, Open Standards Sat, 05 Oct 2013 13:48:18 +0000 hourly 1 http://wordpress.org/?v=3.1 By: Planchas GHD http://www.linux-mag.com/id/8577/#comment-866177 Planchas GHD Fri, 12 Apr 2013 10:09:51 +0000 http://www.linux-mag.com/?p=8577#comment-866177 This can be a great publish. My partner and i loved the information great deal. I'm going to search for these pages. Appreciate your discussing this review. This can be a great publish. My partner and i loved the information great deal. I’m going to search for these pages. Appreciate your discussing this review.

]]> By: Hacking and Downloads http://www.linux-mag.com/id/8577/#comment-62295 Hacking and Downloads Wed, 30 Nov 2011 00:14:29 +0000 http://www.linux-mag.com/?p=8577#comment-62295 Hello there, just was aware of your weblog thru Google, and found that it is truly informative. I'm gonna watch out for brussels. I'll be grateful if you proceed this in future. Numerous folks might be benefited from your writing. Cheers! Hello there, just was aware of your weblog thru Google, and found that it is truly informative. I’m gonna watch out for brussels. I’ll be grateful if you proceed this in future. Numerous folks might be benefited from your writing. Cheers!

]]> By: pgilroy http://www.linux-mag.com/id/8577/#comment-9556 pgilroy Tue, 07 Jun 2011 12:46:45 +0000 http://www.linux-mag.com/?p=8577#comment-9556 Interesting article with a lot of good points. What I have observed is that the shops who are interested in HPC parallelism like the National Labs have migrated their algorithms to data flow, SIMD, format a long time ago and are well positioned to take advantate of the multicore and GP-GPU architectures as they appear. The problem is those who are not already programming in a SIMD mode need to make a paradigm shift in their thinking and approach to convert their specific algorithm to SIMD. As noted vendors are providing some tools to alow serial programs to be converted to SIMD bet they are not often efficent. In fact if the wrong programming model is used on certain muticore processors a negative performance number can occure. Interesting article with a lot of good points. What I have observed is that the shops who are interested in HPC parallelism like the National Labs have migrated their algorithms to data flow, SIMD, format a long time ago and are well positioned to take advantate of the multicore and GP-GPU architectures as they appear. The problem is those who are not already programming in a SIMD mode need to make a paradigm shift in their thinking and approach to convert their specific algorithm to SIMD. As noted vendors are providing some tools to alow serial programs to be converted to SIMD bet they are not often efficent. In fact if the wrong programming model is used on certain muticore processors a negative performance number can occure.

]]> By: przemek http://www.linux-mag.com/id/8577/#comment-9450 przemek Fri, 22 Apr 2011 03:49:59 +0000 http://www.linux-mag.com/?p=8577#comment-9450 If you can't use explicit parallelism via message passing (PVM/MPI) there's OpenMP, which is essentially a set of compiler directives that you can sprinkle around regular C/Fortran code to enable parallelism by loop distribution, etc. GCC supported OpenMP since version 4.2 or thereabouts: http://gcc.gnu.org/wiki/openmp If you can’t use explicit parallelism via message passing (PVM/MPI) there’s OpenMP, which is essentially a set of compiler directives that you can sprinkle around regular C/Fortran code to enable parallelism by loop distribution, etc. GCC supported OpenMP since version 4.2 or thereabouts:
http://gcc.gnu.org/wiki/openmp

]]> By: Peter Morris http://www.linux-mag.com/id/8577/#comment-9412 Peter Morris Thu, 14 Apr 2011 13:49:39 +0000 http://www.linux-mag.com/?p=8577#comment-9412 Although Ada was designed for multi-tasking, its possible use for parallel programming is discussed at this link. http://softtalkblog.com/2010/07/07/could-ada-be-the-answer-to-our-parallel-programming-prayers/ However distribution of Ada tasks onto processors requires use of a rather complex "Distributed Systems Annex". It would be easier if Ada had available something like the parallel extensions of XC. But it could be a promising language and some high quality GPL Ada compilers are available here. http://libre.adacore.com/libre/tools/gnat-gpl-edition/ Although Ada was designed for multi-tasking, its possible use for parallel programming is discussed at this link.

http://softtalkblog.com/2010/07/07/could-ada-be-the-answer-to-our-parallel-programming-prayers/

However distribution of Ada tasks onto processors requires use of a rather complex “Distributed Systems Annex”. It would be easier if Ada had available something like the parallel extensions of XC.

But it could be a promising language and some high quality GPL Ada compilers are available here.
http://libre.adacore.com/libre/tools/gnat-gpl-edition/

]]> By: Peter Morris http://www.linux-mag.com/id/8577/#comment-9411 Peter Morris Thu, 14 Apr 2011 13:06:03 +0000 http://www.linux-mag.com/?p=8577#comment-9411 These tools have some very good features. I think they are currently available only for the Xmos family of microprocessors, but perhaps they could be ported to others. http://www.xmos.com/technology Language The XC concurrent programming language extends the sequential programming capabilities of the C language, providing explicit control of concurrency, communication, timing and input-output. It supports deterministic concurrent programming; compile-time checks eliminate race-conditions. Development Tools and Software IP The XMOS development tools are built on industry-standard platforms making use of open-source compiler technology. They enable the XC language to be combined with C and C++. Using XC, accurate timing of critical paths through programs guarantee that deadlines are met, enabling programs to behave as predictably as hardware. A library of reference designs for popular applications and software modules makes it easy to start designing. These tools have some very good features. I think they are currently available only for the Xmos family of microprocessors, but perhaps they could be ported to others.

http://www.xmos.com/technology

Language

The XC concurrent programming language extends the sequential programming capabilities of the C language, providing explicit control of concurrency, communication, timing and input-output. It supports deterministic concurrent programming; compile-time checks eliminate race-conditions.

Development Tools and Software IP

The XMOS development tools are built on industry-standard platforms making use of open-source compiler technology. They enable the XC language to be combined with C and C++. Using XC, accurate timing of critical paths through programs guarantee that deadlines are met, enabling programs to behave as predictably as hardware.

A library of reference designs for popular applications and software modules makes it easy to start designing.

]]> By: buckiller http://www.linux-mag.com/id/8577/#comment-9394 buckiller Mon, 11 Apr 2011 04:35:57 +0000 http://www.linux-mag.com/?p=8577#comment-9394 I was going to mention data-flow programming (see VHDL) but figured I would just leave my comment more general. But yeah, going data flow makes a lot of problems simpler and more parallel, if a little bit unfamiliar (to the typical programmer) I was going to mention data-flow programming (see VHDL) but figured I would just leave my comment more general. But yeah, going data flow makes a lot of problems simpler and more parallel, if a little bit unfamiliar (to the typical programmer)

]]> By: lgunsch http://www.linux-mag.com/id/8577/#comment-9389 lgunsch Sat, 09 Apr 2011 18:06:51 +0000 http://www.linux-mag.com/?p=8577#comment-9389 ZeroMQ is an excellent parallel tool. By removing all locks, semaphores, memory barriers, etc. from an application you can speed up parallel applications and also get rid of concurrency bugs that appear when a system is under load. <a href="http://www.zeromq.org/" rel="nofollow">http://www.zeromq.org/</a> ZeroMQ is an excellent parallel tool. By removing all locks, semaphores, memory barriers, etc. from an application you can speed up parallel applications and also get rid of concurrency bugs that appear when a system is under load.

http://www.zeromq.org/

]]> By: Ionut Georgescu http://www.linux-mag.com/id/8577/#comment-9387 Ionut Georgescu Fri, 08 Apr 2011 21:44:43 +0000 http://www.linux-mag.com/?p=8577#comment-9387 Exactly, where is the beef? There are a few tools out there, names such Eclipse PTP, TotalView, DDT, Intel Amplifier, Intel Cluster Tools, VampireTrace, Scalasca and many others come to mind ... it would ne nice if somebody tried to analyze these tools against each other. I have been so far a very satisfied user of TotalView and Intel Amplifier, but I would appreciate an overview of the field. Exactly, where is the beef?

There are a few tools out there, names such Eclipse PTP, TotalView, DDT, Intel Amplifier, Intel Cluster Tools, VampireTrace, Scalasca and many others come to mind … it would ne nice if somebody tried to analyze these tools against each other.

I have been so far a very satisfied user of TotalView and Intel Amplifier, but I would appreciate an overview of the field.

]]> By: ekkehard http://www.linux-mag.com/id/8577/#comment-9385 ekkehard Fri, 08 Apr 2011 17:19:02 +0000 http://www.linux-mag.com/?p=8577#comment-9385 Everything said in the article is correct. But where is the journalistic/novelty beef??? Everything said in the article is correct. But where is the journalistic/novelty beef???

]]> By: cdsteinkuehler http://www.linux-mag.com/id/8577/#comment-9384 cdsteinkuehler Fri, 08 Apr 2011 14:05:14 +0000 http://www.linux-mag.com/?p=8577#comment-9384 IMHO, you're looking in the wrong place. I write *HIGHLY* parallel code on a daily bases, in an obscure language called VHDL (yes, it's a Hardware description language, not what most folks think of as "software"). The hardware world is inherently parallel, and you cannot code for it using the same abstractions that have made simplistic serial programming all the rage. Until the SW world sheds the single execution paradigm and truly begins to think in parallel at the lowest level, I think the best hope for significant progress is going to come from advances already made in the realm of hardware design. Today I write code that turns into millions of gates inside an FPGA. At the big chip vendors, they're managing code that executes in parallel on *BILLIONS* of individual logic elements. It's far less of a stretch to imagine that code running on millions of individual execution units (CPU/GPU/Whatever) than crafting a magic compiler that can effectively turn a sequential C program into millions of parallel instructions. IMHO, you’re looking in the wrong place. I write *HIGHLY* parallel code on a daily bases, in an obscure language called VHDL (yes, it’s a Hardware description language, not what most folks think of as “software”).

The hardware world is inherently parallel, and you cannot code for it using the same abstractions that have made simplistic serial programming all the rage. Until the SW world sheds the single execution paradigm and truly begins to think in parallel at the lowest level, I think the best hope for significant progress is going to come from advances already made in the realm of hardware design.

Today I write code that turns into millions of gates inside an FPGA. At the big chip vendors, they’re managing code that executes in parallel on *BILLIONS* of individual logic elements. It’s far less of a stretch to imagine that code running on millions of individual execution units (CPU/GPU/Whatever) than crafting a magic compiler that can effectively turn a sequential C program into millions of parallel instructions.

]]> By: kalloyd http://www.linux-mag.com/id/8577/#comment-9383 kalloyd Fri, 08 Apr 2011 12:32:30 +0000 http://www.linux-mag.com/?p=8577#comment-9383 Parallelism, while an important part of HPC is only part of the picture. Intel has done a lot with TBB, ABB, and it's Parallel Studio to help us optimize the parallel aspects of software. But there are memory and process affinities within and among compute components that become important. The compute fabric is a system - made more complicated by the dynamic nature of the software 'task' structure, and various data partitioning strategies. Often, there is more than one right answer, and looking exclusively at (massive) parallelization may sometimes be misguided. Parallelism, while an important part of HPC is only part of the picture. Intel has done a lot with TBB, ABB, and it’s Parallel Studio to help us optimize the parallel aspects of software. But there are memory and process affinities within and among compute components that become important. The compute fabric is a system – made more complicated by the dynamic nature of the software ‘task’ structure, and various data partitioning strategies. Often, there is more than one right answer, and looking exclusively at (massive) parallelization may sometimes be misguided.

]]> By: buckiller http://www.linux-mag.com/id/8577/#comment-9381 buckiller Fri, 08 Apr 2011 05:58:44 +0000 http://www.linux-mag.com/?p=8577#comment-9381 Intel has a bunch of pretty decent looking stuff for C++ <a href="http://software.intel.com/en-us/articles/intel-sdp-products/" rel="nofollow">intel-sdp-products</a> (TBB, IPP) Matlab is also finally getting their stuff better parallelized. But basically you want a program (compiler?) to analyze your as-is (kind-of serial) code (any language) and spit out parallel instructions that exhibit the same behavior (I mean, correctness)? So would everyone else! The easiest thing to do, I would think, is to move straight to a parallel language (or one that makes it simple) when possible. Those languages exist, but I suspect most developers want their Java, C/C++, Python etc. to be parallel. Intel has a bunch of pretty decent looking stuff for C++ intel-sdp-products (TBB, IPP) Matlab is also finally getting their stuff better parallelized.

But basically you want a program (compiler?) to analyze your as-is (kind-of serial) code (any language) and spit out parallel instructions that exhibit the same behavior (I mean, correctness)? So would everyone else! The easiest thing to do, I would think, is to move straight to a parallel language (or one that makes it simple) when possible. Those languages exist, but I suspect most developers want their Java, C/C++, Python etc. to be parallel.

]]>