Intel Plans for Arbb

Intel Plans for Arbb

Can anyone tell me what, if anything, is Intel's plan with respect to Array Building Blocks. I saw on a sticky post that the project was moved from "Beta" to "Whatif". I also see that some of the key people involved in it have moved on to other companies. Based on these two points, I guess the project must be a dead end. Am I correct in my assessment that it is essentially a dead-end ?

7 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Hi Paul, thanks for your message. I'm a consulting engineer (I work with customers)as part of the ArBB team and can answer all of your questions. I'll try to address things line by line, and we can also talk offline.

First things first, your companyis full of really originalideas that have a lot of potential. I'd be very interested in learning how you were planning on using ArBB and any of the other Intel developer tools that are now bundled into the larger Parallel Studio XE product.

Let me address the move from Beta to Whatif. Whatif is our research portal, and ArBB is actually two different technologies. First you have the ArBB C++ front end. Then you have the ArBB Virtual Machine which is a very powerful "back-end" that can give rise to new front ends, such as Python or C#. The primary purpose of the Beta was to gather as much product feedback on the C++ front-end and gauge how people were using it. We are working with customers that want to use the C++ front-end, and we are also working with people like Joel Svensson who are doing some pretty amazing things with the ArBB Virtual Machine, creating new front-ends for this data parallel virtual machine, which is the "brain" of ArBB. It turns out that there is just as much interest in the C++ front-end as the ArBB Virtual Machine. If you think about what theArBB Virtual Machine does, it most certainly falls within research and exploration. It's forward thinking, and true pioneers in the field are kickingits tires. I am syncing with them nowwith the help of the engineering team and supporting them with their research endeavors.

As far as key people moving on to other companies, considering I'm on the team, I know of no one that has left? If anything, there are even more people around, and even more opportunities to work with us.

So in conclusion, ArBB is far from a dead-end. It is now a part of the research and exploration armof our developer products that can give way to new sets of forward-thinking technologies geared around real-time code generation and metaprogramming.

One other thing - I think there are some hang ups on the whole "move to whatif" idea. Let me clear that up. I mentioned that we have more commercial customers trying out the C++ front-end, andwe have researchers in the field trying out the ArBB Virtual Machine, but for those interested in creating vectorization and threading for their own commercial products, we highly recommend trying out the Intel Cilk Plus which is already included in the Intel C++ Compiler and also has inroads with GCC. In that scenario you are working with a full-fledged commercial product, to where if you have already bought Parallel Studio XE, "it's already in there".


Are you planning to support ArBB Virtual Machine on Intel MIC?
Gaston Hillar

Thanks Noah. I'm glad to hear that Arbb is still on the forward path. I've been following it, passively, for quite a while now and I think it has great potential (especially in the context of MIC). When I heard that it was moved from "Beta" to "whatif" that made me nervous, as it almost seemed like a step back.

My particular interest is in the C++ front-end. As long as that works, I have no real interest in Python, or what-have-you. And so, it seems like, from my perspective, there is not a compelling need to look in to the VMAPI.
I have been also looking at OpenCL and Cuda as well as Accelereys ArrayFire and some open source stuff. Still in the process of learning more about the overall space and seeing what technologies make sense.
Some things that attract me about Arbb:
1. The high-level nature (in contrast to e.g. OpenCL).
2. The native support for segmented parallelism to facilitate use of data parallelism on more complicated problems
3. The compositionality of the operations. In contrast to something like ArrayFire
The parts that concern me are:
1. The lack of really good platforms to take advangage of the tool. Xeon Phi isn't yet released. And Arbb (for obvious and understandable reasons) doesn't support either Radeon or Gtx processors. Dual 8-core Xeons are good, but still no match for the top-end GPUs for certain things.
2. The less than robust commitment from Intel.
3. The non-standard nature of the API. By this, I mean that with OpenCL, I know that whatever hardware I have, it can run OpenCL software that we might create. If I use ArrayFire, I can run the same code on AMD/Nvidia/Intel hardware with not even a recompile (it does under the hood, but...). If Nvidia comes up with some super-duper processor, it is only a matter of buying that new card and everything will work.
I'm not sure there are any good solutions to my concerns with regards to Arbb, but I just wanted to bring them up.

Thanks for the feedback. Wetie allfeedback back into our developer tools. The more the better. The key message in the transition to whatif is thatthis is well suited for theresearch and exploration category.If one has a commercial product with a deadlineinvolving needing higher level vectorization and threading abstractions, there'sso much stuffin Parallel Studio XE that can do the trick (Cilk, TBB, MKL, IPP). So less"ivory tower", more"project deadlineis this month"with Parallel Studio.

Hi Gaston, we don't have any official public announcements on ArBB VM support for the forthcoming products based on the Intel Many Core Integrated Architecturethat I can go into right now. Sorry about that!

Leave a Comment

Please sign in to add a comment. Not a member? Join today