The Next Big Innovation in Microprocessors: Anant Agarwal (Part 11)
Check other articles in the series...One of the greatest challenges with Massively Parallel Computing is Programmability. Anant explains Tilera’s approach to software and tools in more detail, and his “gentle slope programming” concept.
SM: You created all of the tools from scratch, or did you base them on existing tools? AA: We invented all of this, and it is very practical. We invented the plumbing to make this mode of computing work. Users may care how fast their processor is running, or what the average cache level across the chip is. We have predefined views for the user as well. We have a grid view where we give the complete pictorial representation, and the user can select cores. They can analyze performance and do profiling. We really thought through multicore tools and provided a complete suite to our users.
SM: You have given developers analysis tools, but what about programming? AA: Programming is the next thing, and we made some pretty big breakthroughs there as well. Today’s users have a tough choice. On one hand they can use existing tools and software, but they don’t get significant performance. The alternate is to go to some funky architecture, throw out their existing software, maybe reprogram or use esoteric approaches, but they have to redo everything from scratch.
Maybe a year later they would have something limping along. It takes forever to do.
We have developed, what I think is a promising approach. We call it the “gentle slope” programming approach. We will ease people into multicore.
How do we do that? It is a two step process. First, we tell people they can take their existing software. Our markets are embedded networking and video. Linux is common. Software is mostly written in C. We say, take existing software, compile that and run the existing stuff on our chip. It will run in minutes.
SM: Then you can start to make changes. AA: Exactly – get it working first, and now that you have something working you will be much more comfortable tweaking performance rather than spending years re-writing the whole thing.
Users can then start setting new performance goals. We give them a library of optimizations they can use for those efforts. For one example, we have an interface library called iLib, from which users are able to employ mechanisms to create streaming channels of processes. For example, if I have a process, and it is a packet inspecting application process, I want to inspect the packet and check for viruses.
Let’s say, that afterwards I want to send the packet to a different application which is going to count some statistics about the packet. What I can do is quickly set up the channel from process 1 to process 2; it is a very light weight sockets-like API. We built it to appear very much like sockets because sockets are familiar to people. The processes can then open a connection and set a streaming channel between them. The compiler and software system automatically maps that streaming channel onto the processor interconnect.
It is very efficient and does not have to go through a great deal of memory. The first process can then inspect the packet and will stream the packet to the second process. You can get the packet, inspect it, and so, an API of that sort leads to performance improvement gradually and attempts to reach the set performance goals.
This “gentle slope” programming approach is a practical way to get past the multicore programming issue. There is no magical silver bullet that will tackle this entire problem, but the realistic approach is to provide a world class suite of next generation tools. These will transition people to multicore, and I believe that is the way to succeed.
SM: Evolution, not Revolution.
This segment is part 11 in a 15 part series Segment 12 →
Jump to part: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15
