A Stunning Parallel Multicore Approach

Having been at Multicore Expo a few months ago, I was stunned by what I read a few minutes ago. It was the "elephant on the table" that nobody talked about. Companies did not want to discuss it because of their vested interests and I can only imagine that the researchers were incredibly jealous or as ignorant as I.

Having worked in the area of multiprocessing for many years, the promise of automatic parallel behavior generated by a compiler was thought of as an ideal. We never got their in the 90s but it seems that we are making real progress today. A team at College Park have done some remarkable work to solve the fundamental parallelism issues that plague most computers with a technique called "explicit multithreading". You can find some details here and here. Wen and Vishkin both deserve a huge amount of credit for creating this solution.

The other approaches that approach this on a higher level from Peak Stream (now owned by Google) and Rapid Mind both assume that there is an automatic parallelizer to allocate chunks of work to processors and that all the parallelization is done for you. The disadvantage of their approaches is that everything must be an array. This approach is quite unnatural for most programmers although it is possible to learn it. Math majors would certainly like this approach.

Another disadvantage is that their efforts (Peak Stream and Rapid Mind) focus on trying to maximize resource utilization for standard Von Neuman machines in an attached processor model while this new approach seems much simpler and lends itself to static allocation because IPC times will be ignored.

The XMT approach doesn't use an attached model but assumes that the processor has inherent parallelism. The difference is that the scheduling seems to be much clearer and communication times become minimal. This approach also seems to suffer from the same limitation that resources go unused if there is nothing that can be done in parallel. In fact, it is this reason that has many semiconductor companies holding back on large multicore architectures.

I will look at the programming models in more detail next but it seems that this machine could benefit from both automation of parallel operations and the ability to explicitly code each parallel thread.

The future signal processors are going to be really fun if technology like this hits the market anytime soon. I wonder what the follow on to Niagara 2 will really look like?

Restarting And Marketing

I've been restarting a products company and the marketing has changed so much over the past few years! For example, on the good side:

• SugarCRM offers great value - open source, why spend 75K?
  
• SEO tools (I hope google's not reading this) - open source
• portals for Engineers - why leave your cube to find anything?
• and the best help a guy like me could ask for ...
• lots few trees cut down
• more time with the family
  

At the same time, there is some downside as well:

• the world has been replaced by voicemail
• email filters kill many requests
• shows are smaller and smaller
• margins are thinner
• channels are becoming lower cost
• prices are falling
• products are volume
  

It is sure a different place - and still lots of fun....

Comments

All Those Pesky DSP Functions

As DSP becomes mainstream and we incorporate it into all systems, we are left with a dillema: "how can we make this functionality simple enough for all to use effectively?" In short, we can't.

Signal processing is difficult by its nature. It can be done in fixed point, floating point or double precision floating point. It involves many different algorithms. Often at the front end, processing is data independent, while at the back end it is data dependent. Different array sizes are passed between modules, concepts are abstract and require deep mathematical understanding, and time constraints on processing make all this more difficult.

One might say: "Oh, well we'll use a graphical tool and it will solve all our problems" but this is not the case even though it might help in special cases where processing is always regular and data dependent processing is not done. As soon as branching is involved and interrupt processing is required, the need for better tools becomes apparent. In general, if the problem is more limited then this can work, but if it is complex and demanding it tends to be less than optimal.

Or does it? You tell me. How would you recommend people solve these problems?

DSP and FPGA Implementations

Hi All;

How many of you have looked at the rapidly dropping cost of fpgas and wondered how this is going to change the world of signal processing? I'd like to know too. I have some ideas summarized as follows:

• FPGAs offer competitive advantages in hardware implementations of signal processing algorithms with the cost and difficulty of implementation being a barrier
• DSPs offer competitive advantages where the algorithms are experimental and subject to rapid change or the ultimate idea is to push the processor to the limit by adding as many features as possible for the same hardware price.
• DSPs offer integrated A/D and D/A support - something not included in FPGAs to date.
• Serial D/A and A/D components can offer greater flexibility to designers of FPGAs.
• Drivers for PWM are generally integrated into DSP's including dead band timing - lots of work might go into recreation of the wheel in the FPGA world.
• FPGA prices relative to DSP prices are falling - this means that the cross over point from DSP to FPGA for development is changing - but how?

FPGA implementations are now cheaper but development is more expensive. And it is still not entirely clear what algorithms are possible with an FPGA compared to a DSP. For example, neural nets are computed on DSPs without difficulty even if it is time consuming. In comparison, this same algorithm would be extremly difficult to run in an FPGA if it was even possible.

How do we decide how to partition these problems? What thoughts to others have on this?

Pseudo Open Source

In years past we had proprietary solutions and people protected their IP. Today, many solutions are open source based on some type of "copyleft" license while other models range from Freemium to partially protected software.

I think that GPL is the ultimate bait and switch strategy. Support costs money and has to come from somewhere - the community support models are not suitable for production systems unless the software is extremely stable or the systems aren't critical. People end up purchasing support which is the real cost of the software but are unable to protect any modifications that are done as an add on.

Why does the GPL insist on having all associated code in GPL? What are they afraid of in proprietary technology?

The freemium model is much better supported by other license agreements.

Sun's agreement seems like the best of many worlds offering great freemium model support, ecosystem support and protection for those who require it.

Peak Stream - A New New Array Processor

The Peak team has great marketing. I really liked it and their new launch will be a great success I'm sure.

Myself, I prefer more standard calls that our industry has been working on for some time but it isn't a material difference. I do think that their tools are more limited than those of 20 years ago and their basic architecture is 30 years old or more for the most part. Why shouldn't we call it a new new thing - everyone else rehashes old technology into new all the time?

Myself, I would think that a combined programming model would be much stronger. After all, they have one multiprocessor application - why not make it all multi-threaded too and have the benefits of being able to program and debug on the underlying processors if requried? Why guess when it doesn't work - go and look (debugging rule number 6)? The dynamic allocation strategies and dynamic compiling (the new part) make this a bit tricky, but it should be possible.

I think that this will work well for many applications but we all really need some new thinking in the programming area. For real-time systems it seems much too limited in this form.