[edit] I just realized that this is basically a complete rehash of Monday's post. I am stupid. Feel free to skip this if you already read the Monday entry. [/edit]


As I am prone to do, I've changed my mind on the prioritization of Epoch work in the near future.

Previously, my big push for Release 6 was to get the Era IDE working and in place, or at least a skeletal toolset that offered a GUI alternative to the now-unified command line interface. The rationale was that working on a non-trivial Windows app would reveal shortcomings of the language, which I could then shore up accordingly.

However, the more I thought about this, the less happy I was with the arrangement. The whole point here is to get a good demo ready for showing off at GDC; my intention is to show off the technology and hopefully drum up some interest.

The problem is that what I plan to be Epoch's core strength - asymmetric multiprocessing - is not even close to being implemented yet. And while there is still a long way to go before I can get true AMP support in place, I can at least get rough SMP support done. Specifically, I can build in a basic actor/message-passing model that uses OS threads to run multiple instances of the Epoch VM.

At the moment, it's very hard to point at the language and say "now imagine this with all this magic cross-processor stuff and you've got the idea." Instead, I'd like to be able to point at real, working threaded code and say "now imagine adding one keyword to this source code, and suddenly it runs on the GPU instead of the CPU."

The latter is obviously much more impressive, and much easier to understand (especially in a chaotic environment like GDC where giving a true presentation of a technology is more or less impossible unless you're actually a speaker). It leaves a lot less to the imagination and simultaneously hints that the actual technology is not too far away from being ready.

So my current priorities have shifted. I have roughly 2.5 weeks before GDC; some of that time will be needed for working up pitch documents and other paperwork that needs to go with any copy of the demo. A good chunk of that time needs to be spent on the multiprocessing work. Lastly, there is a lot of small-time code improvement I can do, which serves two purposes - it makes the code base cleaner and more efficient, and better illustrates my abilities and discipline.


I'm going to keep a running account of things going here; my goal is to write at least one entry per day. This should keep me on a good pace and ensure that work is progressing steadily, even if it is slow. It'll be a tight month, to be sure, but it should be worth it if I can nail this GDC demo.