CodeGuru is proud to partner with Intel to help connect the developer community directly with Intel. We have available two "Special Guests" from Intel who have agreed to participate in this slow chat to answer your questions on:
Developing Multithreaded Applications
Who is participating?
There are two key special guests from Intel that will be fielding your questions and providing insights from Intel's perspective. Please help me welcome:
Dr.Clay Breshears and Aaron Tersteeg
Dr. Clay Breshears is the author of "The Art of Concurrency" published by O'Reilly. Clay has been involved with parallel and concurrent programming for over 25 years and is currently a Courseware Architect on the Intel Innovative Software Education team, specializing in multi-core and multithreaded programming and training.
Aaron Tersteeg is the community manager for the Intel Parallel Programming Community. Aaron started as a mechanical engineer (oil pump design didn't do it for me), moved on to Information Resource Management, worked as a Business Process Consultant, Fortune 500 Webmaster, Web Application Development VP of Sales and Marketing, Data Center Product Management and now Software Development.
Our guests will be in this forum throughout the week of April 19th to answer questions. Feel free to post questions now knowing they will be joining us on Monday to start answering questions and to discuss more on developing multithreaded development.
As a general note.... This forum will be for discussion the above topic. Other topics and normal forum questions should continue to be posted in the regular forum areas. We will allow some flexibility in questions, but note that off topics posts will be moved to the regular forum areas.
Last edited by Brad Jones; April 16th, 2010 at 02:59 PM.
Brad! Jones, CodeGuru.com Site Director
Developer.com Network Director / EiC
I'm Clay Breshears and I've been doing parallel, concurrent, and multithreaded programming for over 25 years. I've been with Intel for almost ten of those, starting as a Senior Parallel Application Engineer at the Intel Parallel Applications Center in Champaign, IL, implementing multithreaded and distributed solutions in customer applications. Right now I am a Courseware Architect on the Intel Innovative Software Education team, specializing in multi-core and multithreaded programming and training. Before joining Intel, I was a Research Scientist at Rice University helping Department of Defense researchers make best use of the latest High Performance Computing (HPC) platforms and resources.
I'm also the author of "The Art of Concurrency," published by O'Reilly last year.
I'll be here all week. Try the veal. And please remember to tip the waitress.
I am aware of the Intel TBB library and am impressed by it's feature list and claimed performance gains. However in the face of OpenCL being more widely supported accross platforms in the near future, is the TBB library still relevant?
I understand that the TBB library operates at a much higher level and scales to the hardware it is run on, however i believe OpenCL implementations will also scale not only to the CPU but any hardware which supports OpenCL. This means that a software written using OpenCL would automatically utilise any additional hardware(like the GPU) if present.
If i were to begin working on a new software project, why should i choose the TBB library over OpenCL?
I asked Tim Mattson, One of Intel's Parallel Programming Rock Stars to share his thoughts on this question and this is his reply:
OpenCL and TBB are like comparing Apples and Oranges. The question is “not do I need one or the other”. I need both.
TBB is great for C++ programmers working in a shared address space. It is a high level API and VERY Powerful. It is an open source project, but the API is tightly controlled by a small cadre of developers. I don’t make that comment to put it down. I like TBB very much and I am really excited that it is open source software. This has made it a powerful platform for research on shared address space programming in C++.
OpenCL is for C and C++ programmers wanting to write code for heterogeneous platforms. It is VERY low level. It is extremely portable but it does this by exposing the details of the underlying platform. I can write one program that runs on a CPU or a GPU, but I will be totally honest … to make this work you have to query the system for details of the target platform and adapt in your software. This is not the sort of thing the casual programmer can manage very well
OpenCL is an industry standard. If you judge openness by how many organizations are actively contributing to the standard, then OpenCL is one of the most Open standards out there today. Intel, AMD, Nvidia, Texas Instruments, national labs, electronic arts, Apple … the list of contributors is long. The standard is young. First commercial products supporting OpenCL only emerged in Fall of 2009. The standard is evolving steadily (1.0 is out there, 1.1 will be released soon and we are already working on 1.2 and 2.0). This evolution is critical. IF you look at how aggressively many core CPUs and GPUs are changing you will appreciate how aggressive we have to be in evolving OpenCL.
OpenCL is important and will become even more important over time. But it addresses a different market segment than TBB. Hence, Intel is committed to both APIs and working hard to support them on our platforms.
P.S. And don’t forget OpenMP. People tend to forget that if you want a mature multithreading standard that runs just about everywhere, its hard to beat OpenMP. And OpenMP works well for Fortran, C and C++.
I've been looking at OpenCL a lot lately, trying to get a feel for it. So far, I've got to say it strongly reminds me of the OpenGL+Cg combo. Cg shaders look a little different than OpenCL kernels, but the format is very familiar: CL async memory downloads are like OpenGL pixel buffer object DMAs, kernel compilation is JIT, etc.
I'll need to play with it a bit more before I form a real opinion though.