Monday, July 31, 2006

Intel, AMD, Sun... Xilinx?

Article discusses the potential for FPGA-targetted software. Touches upon Intel's EPIC project that was supposed to make the Itanium rule the world. I think the problem is that the scope of the Itanium processor pushed it to far out of reach. FPGAs on the other hand have the nice property of sweeping across many markets, price points and even usage patterns (embedded controller, DSP, HPC accelerator---what I've been calling "versatility value"). A vendor selling rack-mountable black boxes for application specific enterprise computing needs, has only to demonstrate performance/cost improvements for the application in order to be a viable competitor. If an FPGA solution costs less than an Itanium and can get the job done. then why not go with it?

This market is wide and open. Reconfigurable computing could potentially have an enormous effect on the next revision of the internet infrastructure. Lack of developers is the only reason I can see why this hasn't taken off already. Most people who observe these issues would agree that current FPGA tools mostly suck, and that concurrent application development requires some amount of "magical power." Today it would be almost obscene to go into an enterprise software company and suggest that they should target a reconfigurable computer with their application.

Ah, but look at the way things are headed. Multi-core processors. Virtual Machines. Interpretted web interfaces. For much of the web server market it doesn't really matter whose chip you use as long as you can support Linux, Apache, MySQL, and PHP. Throw in Java and you'll get a huge chunk of the enterprise market too... In fact, start with a Java VM to grab some compute intensive financial service companies. Deliver more bang for the buck in that market, and lots of people will start listening...

Thursday, July 27, 2006

scratch scratch

someone else's blog. another confirmation of what i've been spewing... i especially like this comment: "...there is something decidedly unsexy about High Performance Computing..."

a supercomputer with sex appeal... maybe if Apple were to brand it.

Tuesday, July 25, 2006

fpgawiki.com

A wiki for reconfigurable computing. feel free to contribute. feel free to rip articles off wikipedia too. I will start to publicize it more (mailing lists, usenet and such) once I take care of the hosting issues.

coming soon: fpgaos.com -- As soon as I get back to MIT I will be hosting a website on an FPGA and allow people to actively contribute to the development of the hosting platform.

Monday, July 24, 2006

ee times article

EE Times article asks an interesting question in its last sentence. The answer is "I do." I just need a team of 7 to 10 young (not bound to wives/children) hackers who can work 25 hours a day 8 days a week for the next year. This will also require a bunch of mountain dew and maybe some adult supervision--perhaps a $300,000 in initial funding to buy equipment and pay for the mountain dew. Sounds like oh so much fun.

Tuesday, July 18, 2006

resource sharing

poppy.snu.ac.kr/~ykim/resume/DATE_05.pdf

Friday, July 14, 2006

a concurrent evaluator

standard press release.


been thinking about Virtual Machines and FPGAs. Both of those two terms are increasing in relevance. they will also start to sync up in co-relevance.

i've made some headway on my thesis work lately. i'm working on a "parallel evaluator" for scheme right now that uses multiple evaluators each with their own strategies.

an evaluator consists of:
evaluation-strategy
listening-strategy
parent
children
partners
objective

an evaluator uses it's listening strategy to communicate with its parent, children and partners. the listening strategy assigns priorities to the different ports. The parent spawned the evaluator. The children are spawned by the evaluator. The "partners" are the other evaluators (non parent or children) that the evaluator shares a port with. the objective of an evaluator is its current process.

with this framework i'm going to start to define different ways of computing things. for example: an evaluator might get a request from his parent to do (foo x). he responds with a promise to do (foo x). he might call out to all his partners and children "can anyone do (foo x)" if someone responds and says "i will do (foo x)" when the parent tries to force the promise, he will tell his parent to talk to them for the answer. if he cannot find someone else to do (foo x) he will compute it himself when it is forced. this is the "laziest" evalutation strategy I could think of on the spot.

I need some descriptive language for managing "evaluator teams" in order to handle the complexity of using multiple parallel evaluators. I want to be able to fit notions like combinatorial functions, memory, state machines, datapaths and processing units into this evaluator framework. i made something similar for 6.891 last semester, by creating an array of nodes that acted on their ports, with surface reconfigurability (using "CONFIGURE" messages) however, the most complex functionality I could demonstrate with that was simple arithmetic pipelines.

This gets closer and closer to the "big idea."

--whoa, this blog entry comes up number one on google search for "concurrent evaluator"