• Home
• Reviews
• News
• Downloads
• CNET TV

About me

My posting summary

1 to 6 of 6

My comments

• Multicore is here ? dual cores have been out for a couple years now, and quad-cores are fairly common. In fact, it?s hard to find a single-core desktop machine on any vendor site. This scenario is playing out in a similar manner in the data center, where increasingly ?fatter? nodes are featuring more and more cores. Indeed, just a couple months ago, Intel announced a 6-core Xeon processor.
  
  So, multicore is here, yet the vast majority of applications have not been multicore-enabled. Why? Well, here?s the rough calculus done today by software development teams: On a dual-core system (the typical configuration today), one can typically expect a two-fold improvement at best. This performance improvement is just not compelling enough to make the (potentially considerable) development investment. Once the 8- and 16-core systems become mainstream, however, a single-threaded application may be leaving an order of magnitude in performance and throughput on the table. That?s when multicore enablement moves from ?nice to have? to a ?must have.?
  
  Here's an e-Book on multicore programming: http://www.cilk.com/multicore-e-book/ In reply to: "Gartner: Multicore chips leave software trailing"

  January 30, 2009

  0 replies

• Multicore is here ? dual cores have been out for a couple years now, and quad-cores are fairly common. In fact, it?s hard to find a single-core desktop machine on any vendor site. This scenario is playing out in a similar manner in the data center, where increasingly ?fatter? nodes are featuring more and more cores. Indeed, just a couple months ago, Intel announced a 6-core Xeon processor.
  
  Yet the vast majority of applications have not been multicore-enabled. Why? Well, first of all, parallel programming is hard ? in fact viewed by many as an unsolved problem. And second, here?s the rough calculus done today by software development teams: On a dual-core system (the typical configuration today), one can typically expect a two-fold improvement at best. This performance improvement is just not compelling enough to make the (potentially considerable) development investment. Once the 8- and 16-core systems become mainstream, however, a single-threaded application may be leaving an order of magnitude in performance and throughput on the table. That?s when multicore enablement moves from ?nice to have? to a ?must have.?
  
  For more about the multicore challenge, check out this e-Book: http://www.cilk.com/multicore-e-book/ In reply to: "Intel's Barrett leaves chipmaking legacy, shortfall"

  January 26, 2009

  0 replies

• With the arrival of these CPUs, multicore programming will be a competitive imperative for software developers within 12-18 months.
  
  Here's an e-Book on multicore programming. Covers programming approaches including OpenMP, Intel's TBB, Pthreads, Cilk++, MPI.
  
  http://www.cilk.com/multicore-e-book

  August 18, 2008

  0 replies

• With the arrival of these CPUs, multicore programming will be a competitive imperative for software developers within 12-18 months.
  
  Here's an e-Book on multicore programming. Covers programming approaches including OpenMP, Intel's TBB, Pthreads, Cilk++, MPI.
  
  http://www.cilk.com/multicore-e-book

  August 18, 2008

  0 replies

• I see a couple things a bit differently:
  
  1) First, I am more optimistic than "most desktop apps are not inherently parallel". The good news is that for the compute-intensive portion of an app - which are often the bottleneck and impact user experience - there's plenty of parallelism available. Think about a ray-tracing app, or the meshing algorithm for a finite element package, the image processing tasks in a photo editing app, etc etc. Of all the FOR loops out there, a large portion can take place in parallel, without needing info from a previous iteration. So I would argue that there's plenty of parallelism that - if exposed - can materially impact user experiences.
  
  Here's one blog post related to this topic: http://www.cilk.com/multicore-blog/bid/5365/What-the-is-Parallelism-Anyhow
  
  2) Second, I am less optimistic about functionally decomposing an application ("However, each chip can be dedicated to certain tasks"). Manually programming the threads can be pretty complicated, may not balance well, and may need to be re-written for each microprocessor generation.
  
  Here's a post addressing this topic in more detail: http://www.cilk.com/multicore-blog/bid/5847/The-Folly-Of-Do-It-Yourself-Multithreading In reply to: "Intel says to prepare for 'thousands of cores'"

  July 10, 2008

  0 replies

• I see a couple things a bit differently:
  
  1) First, I am more optimistic than "most desktop apps are not inherently parallel". The good news is that for the compute-intensive portion of an app - which are often the bottleneck and impact user experience - there's plenty of parallelism available. Think about a ray-tracing app, or the meshing algorithm for a finite element package, the image processing tasks in a photo editing app, etc etc. Of all the FOR loops out there, a large portion can take place in parallel, without needing info from a previous iteration. So I would argue that there's plenty of parallelism that - if exposed - can materially impact user experiences.
  
  Here's one blog post related to this topic: http://www.cilk.com/multicore-blog/bid/5365/What-the-is-Parallelism-Anyhow
  
  2) Second, I am less optimistic about functionally decomposing an application ("However, each chip can be dedicated to certain tasks"). Manually programming the threads can be pretty complicated, may not balance well, and may need to be re-written for each microprocessor generation.
  
  Here's a post addressing this topic in more detail: http://www.cilk.com/multicore-blog/bid/5847/The-Folly-Of-Do-It-Yourself-Multithreading In reply to: "Intel says to prepare for 'thousands of cores'"

  July 10, 2008

  0 replies