Butterfly effect

In the third year of University I worked on the CREC project. CREC stands for Calculator REConfigurabil which would be translated as Reconfigurable Computer.

During this project I was a co-author on several published papers:

• Octavian Creţ, Cristian Vancea, Balint Szente, Ligiu Uiorean, Florin Rusu. The CREC Reconfigurable Computer. Proceedings of the 1st Balkan Conference in Informatics, p. 476, November 21-23, Thessaloniki, Greece, Publishing Centre T.E.I. of Thessaloniki, 2003, ISBN 960-287-045-1.
• Balint Szente, Cristian Vancea, Ligiu Uiorean, Florin Rusu, Octavian Creţ, Kalman Pusztai. The CREC general purpose reconfigurable computer. Proceedings of the IP Based Design Workshop, p. 217, November 13-14, Grenoble, France, 2003.
• Octavian Creţ, Kalman Pusztai, Cristian Vancea, Balint Szente, Ligiu Uiorean, Adrian Dărăbant. A hardware / software codesign method for general purpose reconfigurable computing. In Proceedings of the 14th International Conference on Control Systems and Computer Science, July 2-5, Bucharest, Romania, Editura Politehnica Press, 2003, p. 57-63, ISBN 973-8449-18-9.

The project was interesting and gave me a chance to learn a bit about the mystical world of parsers and compilers. The most useful trade I learned was probably regular expressions. The work was interesting but I must say I disagreed to the concept of a general purpose computer. I strongly believed back than that a specialized processor would be a better suited application for the project.

My long term idea for the project was to build a reconfigurable coprocessor for a general computing architecture (like the x86). Bundled with a smart firmware (a hypervisor type software?) , the system could identify repetitive tasks and recompile them to a parallel architecture which in term would offload the main processor. Not sure if this would have been possible automatically but another option could have been to provide a high level API which would allow a software to explicitly offload tasks to the parallel coprocessor.

The processor would have been well suited for several tasks like:

• compression/encryption
• video/still image processing
• TCP offloading (or maybe a high performance iSCSI initiator/target)
• Graphics processor/accelerator

Using my concept of a API driven parallelization I suspect that whole applications could have been offloaded to the parallel coprocessor. How about a high performance web server that creates a new processor/”processing unit” per client?

However it seems the industry took another turn, they are still using parallel processors but just put a lot of pre-configured processing units (called cores these days) that do the job. The above concept might still be feasible for very specific applications but the price point of general purpose cores is so low that the problem lies somewhere else: the software. It’s difficult to write parallel software (especially if the branches are not fully independent) and it’s even more difficult to write parallelizing compilers. This is something that I attempted back then and came up with a very basic compiler for a C like language that could identify independent sequential instructions. This is as far as I got back than.

I am wondering if anyone in the industry implemented something similar to my concept, I would enjoy reading about the challenges and the solutions.

Acknowledgments

This research was supported by the Romanian Ministry of Research, Education and Youth, National University Research Council, under the AT grant, theme 140 / 2003.