Context
The early 1980s were magical times in the
parallel programming field.
The
conventional wisdom was that
uniprocessors had almost reached their performance limits and the only way to build machines to tackle the really big computational problems was to build what were called medium and large scale
parallel systems.
Conception
In the summer of 1983, a group of people living in
Edmonton,
Alberta,
Canada started to get together to discuss a new parallel programming model.
The goal was simple: to figure out how to build a massively parallel computer using off-the-shelf components.
By massively parallel, we meant thousands if not millions of CPUs (there was nothing modest about our goals).
Sidebar:
Based on my recollection, the original members of this group were (in alphabetical order by last name) Daniel Boulet (i.e. dabcanboulet), Colin Broughton, Jim Savage, Chris Thomson and Daniel Wilson.
Once it became clear that we had something that might be worth trying to commercialize, we were joined by Jamie Bater (a potential VP Finance type).
When the time came to actually form the company, I felt that I just didn't have the time required to properly participate and I left the group (BIG MISTAKE).
By this time, Ken Gordon had joined the group (he would become the company's President).
The founders were Colin, Jamie, Jim, Ken, Chris and Dan.
The very early ideas were rather crude but it didn't take all that long for things to
coalesce around a basic approach which we called PARDO.
The discussions soon turned to figuring out how to fund and commercialize the idea.
I can distinctly remember one meeting which took place on a sunny afternoon in Jamie's apartment overlooking the North Saskatchewan River in downtown Edmonton (the Edmonton equivalent of an apartment overlooking New York City's Central Park but without the muggers).
The topic of the day was to come up with a name for the company.
A bunch of possibilities were thrown around and the eventual "winner" was Myrias - a coined word derived from myrios which is Greek for 10,000.
In December of 1983, Myrias Research Corporation was founded with the mission to develop and market a world-class massively parallel computer system.
Fund raising consumed most of 1984.
Seed funding was provided by the founders themselves (some of whom mortgaged their homes to raise money) along with their friends and relatives.
Eventually, four million dollars was raised and the real work of trying to commercialize the idea began (a total of about 45 million dollars was raised over the next five years).
Early days
Things bogged down for a while due to the all too common "startup diseases" of differing corporate and technological visions (it didn't help that the idea itself was of a pretty grand scale and still needed serious effort in order to work out the details).
Eventually, Chris wrote the
G Principles of Operation - a document born out of a combination of desperation and necessity which described the software architecture of what was being built.
It was and still is an impressive document.
In many ways, it was patterned after
IBM's
System/370 Principles of Operation manual and it was to form the foundation of everything the software folks created over the coming years.
Meanwhile, Jim and Colin were working away trying to implement the first generation of hardware (the details of which are probably still best left untold) and all of the founding technical folks (i.e. Colin, Jim, Chris and Dan) were figuring out how to implement the Myrias Programming Model.
Sidebar:
The Myrias Programming Model's core idea was the PARDO construct (strictly speaking, the core idea was how to implement the PARDO construct using a distributed operating system running on hundreds or possibly even thousands of processors).
I intend to provide a much more detailed description in another node but the essence of the idea was that a PARDO construct was a section of code which was performed in parallel according to some very specific and actually fairly simple semantics.
For example, here's a short PARDO construct written in FORTRAN:
PARDO I = 1, 1000
A(I) = F(I)
EPARDO
In this example, F is a function which computes a value which is dependent upon I.
As written above, it looks pretty trivial but there were two wrinkles.
The first one was that the starting conditions for each iteration of the PARDO body was the memory state of the program at the moment before the PARDO started - i.e. vaguely equivalent to the following C code written for any standard Unix platform:
for ( i = 0; i < 1000; i += 1 ) {
if ( fork() == 0 ) {
a[i] = f(i+1);
}
}
The second wrinkle was that the final memory spaces for each of the iterations were automatically merged back together to form a new memory space for the parent.
A quick (and hopelessly inefficient) example of how to reverse the elements of an array should be instructive:
PARDO I = 1, 1000
A(1001-I) = A(I)
EPARDO
This works because the value of A(I) on the right hand side of the assignment statement in each "iteration" is the value BEFORE the PARDO construct started.
There are a lot of other implications resulting from this idea (some of which took a while to truly grasp) and it's actually possible to implement this PARDO construct much more efficiently than is implied by the above description.
This writeup is intended to be a brief history of the company so I'm going to leave the technical details for another day.
At a superficial level, the Myrias PARDO construct is similar to the OpenMP parallel do construct (and other PARDO constructs invented by other folks).
The similarity is more apparent than real as each "iteration" of a Myrias PARDO construct runs in a separate address space whereas every "iteration" of an OpenMP parallel do construct run in the same address space.
The first generation hardware project
By the time that I re-joined Myrias as an employee in January of 1986, the software project was up and running (i.e. developing lots of software) and the hardware project was making reasonable progress.
The first generation of hardware was based around Motorola 68000 processors (the rather twisted task of implementing a purely software based virtual memory mechanism on a microprocessor which isn't capable of recovering from a page fault was the part of the project that I was involved in - explaining how this was done is worth a writeup itself (maybe someday)).
At this point in time (1986), Myrias' funding was coming from a combination of VC money and a development contract with a couple of governmental entities (which shall remain nameless but whose names didn't start with a D - sorry inside joke and clarification) with an interest in possibly someday exploiting the Myrias technology.
The government agencies were called "the sponsors" in order to avoid having to use their names too often (they were, shall we say, more than a little publicity shy).
One day in late August or early September of 1986, the sponsors were on site for a planning meeting and to see a demonstration of the hardware and software in action.
The terms of the demonstration were simple - it either worked or the funding stopped and the company died.
At about 1000am, the sponsors are ready to see the demo so they're taken to the machine room and the demo works (perfectly).
Happy with the demo, they return to the planning meeting while the rest of the technical folks continue to work with the (very very pre-alpha) system.
Shortly after 1pm, the system stops working and simply refuses to work for the rest of the afternoon (the problem was eventually found and fixed but the entire atmosphere was pretty strange as the company would have died if the demo for the sponsors had been delayed by three hours).
We were eventually able to deliver two prototype 128 processor systems based on this hardware to the sponsors (i.e. it did eventually work reasonably well).
The second generation hardware project
The rest of 1986 and the early part of 1987 were spent gradually improving the software and trying to determine if there was any way that the hardware could be manufactured.
It soon became apparent that the hardware needed to go through a major redevelopment cycle (is that sufficiently diplomatic?) and we embarked on determining what the second generation hardware should look like.
By the middle of 1987, the second generation hardware requirements were reasonably well understood and we contracted with a company in Los Angeles to develop and implement the hardware (this generation of hardware was Motorola 68020 based and the project was launched just a bit too early for the 68030 to be used).
I became involved in the hardware project as sort of a liason person between the hardware and software groups and because I had a pretty strong understanding of what the hardware needed to do.
Meanwhile, the software project continued (we were developing an operating system kernel designed to operate efficiently on thousands of processors at the same time that we were writing our own C and FORTRAN compiler not to mention a way to actually run programs on the system from conventional workstations).
I was busy working with two more junior folks on the acceptance test suite for the hardware project (a test suite intended to verify that the Los Angeles company had satisfied the terms of their contract).
In about May of 1988, the hardware project reached the point where it was about time to start acceptance testing.
I flew to Los Angeles for a couple of weeks to set the stage for the actual acceptance testing.
The plan was that the acceptance testing would be done by the end of August.
Shortly after I arrived, it became clear that the hardware project was, shall we say, just a bit behind schedule (i.e. it didn't work and nobody had any idea when it would work - one of the three board types had over three hundred patch wires on it and the other two board types had about one hundred patch wires each).
The Los Angeles Myrias team gradually grew to about ten people as we tried to rescue the hardware project (and save the company).
In the early stages, we tried to share rental cars between multiple Myriods (a Myriod is someone who worked at Myrias).
This soon became impossible as the stress levels required that people had their own cars (i.e. some vague level of control of their lives after working hours).
Sidebar:
I was one of the only two people in the "away team" with a credit card that provided automatic rental car insurance.
Consequently, either I or the other fellow would rent all of the rental cars (carrying an average of a half dozen or so rental cars on your credit card at any given time plus living out of a suitcase, buying an average of just under two round trip Edmonton-Los Angeles-Edmonton tickets per month and dining out a lot results in fairly impressive credit card bills).
By early December 1988, the hardware project was still in a lot of trouble but it was starting to come together.
Unfortunately, I was burned out big time and returned to Edmonton (it's a strange feeling to be practically living in Los Angeles (see
Trabuco Oaks for a tiny taste) and then one day hop on a plane and never return - I want to go back someday but the opportunity hasn't come up yet).
Back in Edmonton, I proceeded to almost get myself fired.
Fortunately, I was able to get settled down and moved into the Applications group (I'd already worked in the Compiler, Kernel, Test, Unix API and Hardware groups so I guess that it was time to work for the only technical group that I hadn't worked for yet).
The hardware project was moved to Edmonton in March of 1989 and by the summer of 1989 we had hardware that was reasonably solid.
We delivered a 256 processor system to each of our two primary sponsor sites and had a few hundred processors in Edmonton that came together into large systems or were split into smaller systems as appropriate.
Sometime in 1989, we were lent 7.5 million dollars (Canadian) by the Alberta government.
A decision was made at about this time to refer to the first generation hardware as the SPS-1 and the second generation hardware as the SPS-2.
A world record
Late in 1989 found us ready to replace all of the existing processor boards in the two sponsor systems with new hardware.
They agreed to send us their old boards just before Christmas and we agreed to send them the new boards just after Christmas.
This gave us an opportunity to build a very large system.
We put together a 960 processor system using solid hardware (i.e. all four processors per board in working order) and managed to find almost one hundred more working processors on partially functioning boards.
In the end, we assembled and ran programs on a system with 1049 processors.
This was, as far as I know, a world record at the time (our marketing folks totally dropped the ball - no press release and no publicity).
The largest system that I ran a program on was 1039 processors (the last couple dozen processors were quite flakey and I was just never lucky enough to get a program to run to completion on more than 1039 processors although my 1039 processor run may have been a world record for a few hours).
The third generation hardware project
As 1990 got rolling, we sent the new hardware to the sponsors and found ourselves with a 512 processor SPS-2 system (it used slightly older hardware than what the sponsors had).
It became an almost routine event to run a program on 512 processors (I quickly found running programs on a mere 64 or even 128 processors to be pretty dull).
Meanwhile, in the fall of 1989 we'd hired an entire hardware development team in Toronto and had embarked on the third generation hardware development project.
This one was absolutely intended to be a world class system (the first generation was really prototype hardware and the second generation took so long to get working that it was commercially boring before it was stable).
In September of 1989 we had a project development plan that called for the third generation (called the SPS-3) to be ready for first beta customer ship on the 12th of September, 1990.
The applications folks were using the existing SPS-2 hardware so I didn't have much to do with the SPS-3 project.
One night in late August of 1990, I happened to drop in on a project status meeting that had just started at 10pm (we were determined to hit the September 12th date).
It soon became apparent that the hardware folks in Toronto could benefit from having a serious software person on site for a few days.
Since I was still working in the Applications group, I didn't have any commitments to the SPS-3 project so I offered to go for a few days.
Imagine my surprise when the person chairing the meeting asked if I could go that night!
I agreed and less than two hours later I was on the 1245am flight to Toronto (from Edmonton).
I arrived, slept for a few hours and dropped by the Toronto office at around noon.
As it turned out, their issues weren't all that major and it only took me a few days to get things going.
Back in Edmonton, I was now firmly in the SPS-3 project and jumped in to help get things going (99% of the hard work was already done - i.e. I didn't play a very big role although I was a fresh set of experienced eyes).
In the end, we shipped the first SPS-3 system to the beta customer on the 12th of September, 1990 - i.e. on the exact date predicted a year earlier (we were the first company in the world to ship a product based on the Motorola 68040 - this is a fancy way of saying that we helped Motorola to debug the 68040).
All good things . . .
Unfortunately, although the SPS-3 project was a technical success, the market for what we were building simply didn't exist.
The end of the
Cold War didn't help but the fundamental problem was that it had proved possible to continue to improve the performance of uniprocessors (i.e.
Moore's Law still applied) and the expected market for massively parallel computers had simply never developed.
In order to survive, the company had already had to lay off about a quarter of the workforce in early August and the need for more financing was becoming critical.
I was giving a presentation to a potential customer on the afternoon of the 25th of October, 1990.
When the presentation was over, I noticed unusual activity in and around the President's office (I've never been able to figure out what was "unusual" about what I saw but I knew as I walked back to my office that something important was going on).
As I drove into the parking garage the next morning, I saw people carrying boxes to their cars.
It was over.
The Alberta government had triggered the end by calling the loan that they'd made to us in 1989 but that was just the straw that broke the camel's back - the camel was doomed regardless of what the Province did.
I can distinctly remember telling someone a few weeks after Myrias went under that I had no idea how people would be programming parallel computers in fifteen years but "it wouldn't be with message passing and it wouldn't be with shared memory".
I went on to say that it wouldn't be the Myrias way either but that I felt that we had been closer to a solution than anyone else at the time.
Well . . . here we are twelve years later and people are still programming parallel computers using some combination of either explicit message passing or shared memory programming techniques.
Hmmm . . . only three years to go . . .
I still believe that if we are to be able to make effective use of thousands of processors then we're going to need something a lot less baroque than either shared memory or message passing.
In fact, I continue to believe that Myrias got closer to "a better way" than anyone else has managed to get so far.
A short update added on 2009/12/01:
Well . . . it is now nineteen years since Myrias went under. I guess that the fifteen year horizon in my prediction a couple paragraphs back was a bit ambitious. People still program high end parallel supercomputers using a combination of pretty much bare knuckles message passing and regular old fashioned shared memory techniques. Sigh. I guess that the wheels of progress turn rather slowly in this realm.
Notes
- Myrias was a serious attempt to commercialize an idea.
There was nothing fundamentally wrong with the idea.
Unfortunately, we had failed to realize and/or know certain things:
- that it would continue to be possible to make uniprocessors go a LOT faster than they ran in the early 1980s (this may seem quaint today but many of the technological "truths" that we know today will look just as quaint in fifteen years).
- that building a massively parallel system using off-the-shelf components was doomed to failure because of a phenomenon known as Amdahl's Law.
We figured this out fairly early on but not understanding it at the beginning didn't help.
- that the nature of the high performance computing game is really quite simple - the market is very small and the programs run for a very long time.
Consequently, the folks working in this area are prepared to expend an astonishing amount of effort to gain really quite minor improvements (e.g. a couple of man-weeks to achieve a saving of 1% or less).
The net result is that a parallel programming model which introduces ANY inefficiencies is doomed to being a commercial failure (this was true in the 1980s and is still true today).
- that the Cold War would end (almost all government funding for parallel computing dried up with the end of the Cold War and there really weren't any other sources of funding upon which a parallel computing company could build a viable revenue stream).
If any one of these had been false then we might have succeeded.
As it was, we never stood a chance.
It used to really bother me to see Myrias used by the Edmonton newspapers as an example of a government
boondoggle (this was happening even before we went under).
The Chairman of Myrias tried to explain things to the journalist who was giving us the hardest time.
The response was classic
yellow journalism - he didn't care what the truth was as all he was interested in was a good story.
Myrias was one of the best times of my life (burning out at the end of 1988 and the six months recovery would have been one of the worst times of my life had I not been married to who I'm married to and had I not been a part of the Myrias family).
Each sentence in the above writeup brought forth memories that would take pages to describe in full.
Maybe I'll get a chance to elaborate on some of them from time to time.
Myrias developed a fairly impressive set of software in addition to the three generations of hardware. The software development effort tended to be structured to coincide with the evolution of the hardware.
Consequently, it is easier to describe events by associating them with the three generations of hardware.
There was a well meaning but ultimately futile attempt to keep Myrias alive as a pure software product company.
It never employed more than about a dozen people as compared to a peak of slightly over 100 people employed by the original Myrias Research Corporation in July of 1990.
The last remnants of Myrias ceased operation a couple of years ago (1999 if I recall correctly).
One more story - at one of the project status review meetings, one of the "sponsor" representatives is reported to have said "That's the only time I've seen that many processors together doing anything more useful than generating heat". Considering who was saying it, this was very high praise indeed!
This meeting probably took place during the second generation hardware era.
References
- personal recollections (if there are any Myriods reading this who remember things differently, please feel free to remind me about what really happened).