Comments on: The Eadline Split: The Growing Chasm of Multicore Programming http://insidehpc.com/2009/06/11/the-eadline-split-the-growing-chasm-of-multicore-programming/ HPC News Without the Noise for Supercomputing Professionals | insideHPC Sun, 19 May 2013 10:46:54 +0000 hourly 1 http://wordpress.org/?v=3.1.1 By: iphone development http://insidehpc.com/2009/06/11/the-eadline-split-the-growing-chasm-of-multicore-programming/#comment-201987 iphone development Sat, 02 Jan 2010 12:02:31 +0000 http://insidehpc.com/?p=5576#comment-201987 A great infroamtion about the Multicore Programming .i also finding for this type of the programming blog so its very useful for me so thanks to post. A great infroamtion about the Multicore Programming .i also finding for this type of the programming blog so its very useful for me so thanks to post.

]]> By: bob ilgner http://insidehpc.com/2009/06/11/the-eadline-split-the-growing-chasm-of-multicore-programming/#comment-169608 bob ilgner Mon, 15 Jun 2009 19:06:15 +0000 http://insidehpc.com/?p=5576#comment-169608 What Eadline says is correct and does make sense. I believe though that the direction for HPC will come not from the tech apps available now, but by the commercial generated by Joe Blogs for applications we have not even conceived yet. We are at the start of a new era of architectures and programming paradigms. Number crunching is a nice showpiece for performance, but will not satisfy many business models. Everyone can see the 2nd computer revolution is starting, none of us know where it is heading though. Intel now at 4 cores per chip, AMD at 6, as of this writing. What Eadline says is correct and does make sense. I believe though that the direction for HPC will come not from the tech apps available now, but by the commercial generated by Joe Blogs for applications we have not even conceived yet. We are at the start of a new era of architectures and programming paradigms. Number crunching is a nice showpiece for performance, but will not satisfy many business models. Everyone can see the 2nd computer revolution is starting, none of us know where it is heading though. Intel now at 4 cores per chip, AMD at 6, as of this writing.

]]> By: John Leidel http://insidehpc.com/2009/06/11/the-eadline-split-the-growing-chasm-of-multicore-programming/#comment-169219 John Leidel Fri, 12 Jun 2009 19:04:11 +0000 http://insidehpc.com/?p=5576#comment-169219 Kevin, Grand Central Dispatch definitely looks like an interesting methodology. It has the musings of being efficient from the development side as the thread parallelism is natively hidden from the user. However, I haven't read/seen enough of its actual implementation to comment on whether I think it would be a good fit for HPC/scientific apps. One of the specific features I'm curious about is individual task affinity. Given a NUMA SMP [eg, Intel Nehalem-EX], can one natively control where the threads land on the system in relation to allocated memory blocks? [so as not to stall the memory units within each socket searching for blocks]. Kevin, Grand Central Dispatch definitely looks like an interesting methodology. It has the musings of being efficient from the development side as the thread parallelism is natively hidden from the user. However, I haven’t read/seen enough of its actual implementation to comment on whether I think it would be a good fit for HPC/scientific apps.
One of the specific features I’m curious about is individual task affinity. Given a NUMA SMP [eg, Intel Nehalem-EX], can one natively control where the threads land on the system in relation to allocated memory blocks? [so as not to stall the memory units within each socket searching for blocks].

]]> By: Kevin Buterbaugh http://insidehpc.com/2009/06/11/the-eadline-split-the-growing-chasm-of-multicore-programming/#comment-169212 Kevin Buterbaugh Fri, 12 Jun 2009 18:31:12 +0000 http://insidehpc.com/?p=5576#comment-169212 John, I don't have a comment, but rather a question. What do you think of what Apple is doing with Grand Central Dispatch in Snow Leopard? Thanks... Kevin John,

I don’t have a comment, but rather a question. What do you think of what Apple is doing with Grand Central Dispatch in Snow Leopard? Thanks…

Kevin

]]> By: John Leidel http://insidehpc.com/2009/06/11/the-eadline-split-the-growing-chasm-of-multicore-programming/#comment-169088 John Leidel Fri, 12 Jun 2009 02:05:18 +0000 http://insidehpc.com/?p=5576#comment-169088 Charles/Ilya, I've indeed used all of the concurrency platforms I mention in the article [and quite a few not mentioned]. Speaking from experience, Cilk is definitely a step in the right direction. I can't, however, say that it is 'the' answer. I deliberately mentioned it alongside other constructs due to its age. Cilk [as marketed/supported by CilkArts] is still relatively new as compared to POSIX threads, MPI, UPC and other constructs. I'm interested to see more general application use and general adoption of Cilk. Charles/Ilya, I’ve indeed used all of the concurrency platforms I mention in the article [and quite a few not mentioned]. Speaking from experience, Cilk is definitely a step in the right direction. I can’t, however, say that it is ‘the’ answer.

I deliberately mentioned it alongside other constructs due to its age. Cilk [as marketed/supported by CilkArts] is still relatively new as compared to POSIX threads, MPI, UPC and other constructs. I’m interested to see more general application use and general adoption of Cilk.

]]> By: Charles E. Leiserson http://insidehpc.com/2009/06/11/the-eadline-split-the-growing-chasm-of-multicore-programming/#comment-169083 Charles E. Leiserson Fri, 12 Jun 2009 01:29:05 +0000 http://insidehpc.com/?p=5576#comment-169083 You're lumping apples and oranges into the same bin. Is there a difference between programming in assembly language and a high-level language such as C++, Java, or Python? That's the difference between most of the concurrency platforms you mention and Cilk++. Even OpenMP, which is ostensibly high level, doesn't offer composable parallel performance the way that Cilk++ does. Have you actually used any of the concurrency platforms you mention? You’re lumping apples and oranges into the same bin. Is there a difference between programming in assembly language and a high-level language such as C++, Java, or Python? That’s the difference between most of the concurrency platforms you mention and Cilk++. Even OpenMP, which is ostensibly high level, doesn’t offer composable parallel performance the way that Cilk++ does. Have you actually used any of the concurrency platforms you mention?

]]> By: Ilya http://insidehpc.com/2009/06/11/the-eadline-split-the-growing-chasm-of-multicore-programming/#comment-169081 Ilya Fri, 12 Jun 2009 01:17:58 +0000 http://insidehpc.com/?p=5576#comment-169081 Ummm....sounds like a bit of a rant... 1) If the prerequisite for solving the multicore programming challenge is learning MPI - wow, the software field is screwed. Good luck getting the 99.9% of engineers who don't know MPI to learn it. And by the way - is that low-level protocol, arguably a necessary evil for distributed systems, really a must for shared memory boxes, which are outnumber clusters 100:1? For every million HPC systems out there, there's hundreds of millions of desktop multicore boxes getting shipped... 2) Not sure how helpful it is to lump native threads, MATLAB, OpenMP, Cilk++ et al together. This is apples and oranges, hammers and wrenches. If I'm a domain expert comfortable with MATLAB, I am probably not going to port my code to native threads; if I'm a software vendor who cares about performance, I'm probably not writing my app in MATLAB; etc. 3) I must admit, I am slightly perplexed at the inclusion of Cilk++, a product we first shipped a couple months ago, among the other approaches that are one or two decades old, in the "are these really any better" question. Did hundreds of schools download the MPI toolkit within the first month of it being available? They did for Cilk++. Are engineers able to write their first multicore program within an hour of buying a book on Pthreads? They can with Cilk++. Sorry about the rant :) ilya Ummm….sounds like a bit of a rant…

1) If the prerequisite for solving the multicore programming challenge is learning MPI – wow, the software field is screwed. Good luck getting the 99.9% of engineers who don’t know MPI to learn it. And by the way – is that low-level protocol, arguably a necessary evil for distributed systems, really a must for shared memory boxes, which are outnumber clusters 100:1? For every million HPC systems out there, there’s hundreds of millions of desktop multicore boxes getting shipped…

2) Not sure how helpful it is to lump native threads, MATLAB, OpenMP, Cilk++ et al together. This is apples and oranges, hammers and wrenches. If I’m a domain expert comfortable with MATLAB, I am probably not going to port my code to native threads; if I’m a software vendor who cares about performance, I’m probably not writing my app in MATLAB; etc.

3) I must admit, I am slightly perplexed at the inclusion of Cilk++, a product we first shipped a couple months ago, among the other approaches that are one or two decades old, in the “are these really any better” question. Did hundreds of schools download the MPI toolkit within the first month of it being available? They did for Cilk++. Are engineers able to write their first multicore program within an hour of buying a book on Pthreads? They can with Cilk++.

Sorry about the rant :)

ilya

]]>