Cleve’s Corner: Cleve Moler on Mathematics and Computing

The Ardent Titan, part 2 2

Posted by Cleve Moler,

Even though I am one of the founders of the MathWorks, I only acted as an advisor to the company for its first five years. During that time, from 1985 to 1989, I was trying my luck with two Silicon Valley computer startup companies. Both enterprises failed as businesses, but the experience taught me a great deal about the computer industry, and influenced how I viewed the eventual development of MATLAB. The second startup was known as Ardent Computer for most of its brief existence.


MathWorks and Ardent

As soon as we could, we ported MATLAB to the Titan, and MathWorks established a working business relationship with Ardent Computer. On a trip to the West Coast, Jack Little and Jim Tung from MathWorks visited Ardent. In a meeting at Ardent, I gave Jack and Jim my Ardent business card and I gave the Ardent folks my MathWorks business card. The Ardent Titan eventually became the only computer in the world to ever have MATLAB delivered with its bundled software.

Matrix Laboratory

MATLAB and the Titan were excellent companions. The Titan's computational power came from its vector processor and, back then, MATLAB was still "Matrix Laboratory". We could demonstrate the Linpack Benchmark with one MATLAB command, or with one mouse click. The Linpack Benchmark provided the starting point of a deeper discussion of the capabilities of MATLAB.

MATLAB ran on top of Ardent's math libraries. Recall that Linpack was more than just a benchmark. Linpack and Eispack were the Fortran matrix libraries that got us started in this whole business. Randy Allen, who was one of Ken Kennedy's students, had come to Ardent to write vectorizing Fortran and C compilers. Vectorizing the Linpack code was easy because we had written it with vectoriziation in mind. Vectorizing the Eispack code is harder, both because the algorithms are more complex and because the coding style did not anticipate vector operations.

We also needed to have vectorized versions of the transcendental math functions. I had worked on the trig and exponential functions before Ardent because I had a research project at the University of New Mexico sponsored by IBM and a consulting gig at Convex that both involved vectorized math libraries. That work carried over readily to the MIPS chip that we were using on the Titan.

I had avoided the power function, $x^y$. That's harder because it involves two arguments. Which is the vector? I had rationalized not thinking about it saying by "Nobody ever wants to call the power function on a vector." But then one day we had a visit from a potential customer -- a large, international bank who shall remain nameless except to say their headquarters is in San Francisco. They were impressed with how easy it was to do their mortgage portfolio simulations in MATLAB, but we were concerned about performance. It turns out that most of the time was being spent in the power function on a vector. Fortunately, it was interest calculations of the form $s^{(n/365)}$ where $s$ is a scalar and $n$ is an integer vector containing numbers of days. That was easy to vectorize and add to the library.


Gustave Dore was a nineteenth century French engraver who illustrated works by Milton, Lord Byron, and Edgar Allen Poe, among others. Dore Avenue is an exit off the Bayshore Freeway on the way from Silicon Valley to the SFO Airport. When Michael Kaplan drove past Dore, the exit, it reminded him of Dore, the artist, and he decided to use the acronym for his Dynamic Object Rendering Environment.

I had met Michael in Oregon when he was trying to put Dore on the Intel Hypercube. That seemed like a good idea because ray tracing is computationally intensive and embarrassingly parallel. But the iPSC was pretty hopeless because, among other things, it didn't yet have a graphics output device. But Dore and the Titan were made for each other. The Titan had hardware support for all the tasks that Dore required, as well as a large frame buffer and a fast, high resolution display. Dore became the cornerstone of Ardent's graphics software environment.

In 1988 the graphics in MATLAB itself was still pretty basic. We did not yet have three dimensional color in our shipping product, and would not have it until 1992, with MATLAB version 4.0. So by linking MATLAB to Dore on the Titan we were able to anticipate capabilities that would not be available on other machines for another three or four years.

The September, 1988, issue of Computer, published by the IEEE Computer Society, included an extensive technical article by Ardent engineers about the Titan. The graphic on the cover shown above was chosen by the journal's editors. It is a generalization of the Moebius strip and was computed in MATLAB and rendered by Dore. Today we can create this graphic in MATLAB itself by applying shading and lighting to a surf plot

For me the even more exciting graphic is the vibrating membrane, an animation of the solution to the wave equation that underlies the MathWorks logo. This is my recreation in an animated .gif of something I first saw in Michael Kaplan's darkened office at Ardent sometime in 1988. It was the first time I had ever seen the membrane moving on a computer screen and it nearly brought tears to my eyes.

Much of what I know about computer graphics, I learned by accessing Dore from MATLAB while I was at Ardent. And many of the demos that Ardent used to show off the Titan at trade shows and customers visits involved MATLAB driving Dore. It was a terrific marriage -- while it lasted.


It took longer to bring the Titan to market than the original business plan called for. The machine was ultimately more expensive than the original business plan called for. It was bigger and heavier. It was noisier. And it required 220 volts.

It turned out to be harder to vectorize and much harder to parallelize most programs than everybody had hoped. The big-time applications on the big-time supercomputers like the Crays had been doing it for years, but most scientific and engineering applications that had been running on Vaxes and Sun workstations had not. We were beginning to see that Linpack performance was not so strongly correlated with the performance of more complicated programs as the machine architecture grew more complex. This is certainly true today.

Forest Baskett is a friend of mine. He has been at Stanford, at Los Alamos, and for a while he ran a Palo Alto research lab for DEC. He is now a venture capitalist in The Valley. But for a long time, including the time I was at Ardent, he was a VP at Silicon Graphics. In early 1989, he gave a seminar talk at Stanford about RISC with a deliberately provocative title like "Vector Computing is Dead". In the question period, I marched to the front of the seminar room and triumphantly produced my own overhead transparency with the latest performance numbers from the Titan. But Forest was right. We were the last of a dying breed.

But the biggest problem was competition. Direct competition from Stellar. And increasing competition from the workstations as Silicon Graphics and Sun increased their computing power. It took too long for customers to decide what to buy. Our sales people had to work too hard for each sale. Competitive benchmarks were often involved. These machines usually cost over \$100K and were not impulsive decisions.

On the East Coast, Stellar Computer was also having difficulties selling their machines. They did not have a vector machine, and I know less about the specifics of their frustrations, but I do know they were also suffering.

Stardent Computer Company

One morning in the fall of 1989, everybody at Ardent was summoned to an auditorium near Mountain View that could hold us all. We were connected via satellite to a similar auditorium near Waltham, Mass, that could hold everybody from Stellar. In that auditorium Al Michaels, CEO of Ardent, stood next to Bill Poduska, CEO of Stellar. I forget whether either was smiling. They announced that Stellar Computer and Ardent Computer had been merged to form Stardent Computer.

It was a shotgun marriage with the financial backers calling the shots. If there was any chance of saving their investments, it would have to be through combining the two companies.

Production and marketing of the first generation machines of both companies were terminated. Ardent had a second generation machine well along in development, and that was going to be Stardent's next product. It was an actual desk side workstation, using Intel's ill-fated excursion into RISC processing, the i860. There was no vector processor. There was considerable reuse of the successful graphics components from the Titan. This machine was to be known as the "Stiletto". I still have a hand-out from a preview -- an actual stiletto, a serious weapon with a long slender blade. I know we wanted to be viewed as cutting edge, but that was going too far. Fortunately, that machine never reached the marketplace.

From its beginning, Stardent had no chance. Key people began to leave almost immediately. Whatever management was left became concentrated in Massachusetts, but development was centered in California. The subsequent implosion and eventual failure was the largest in the history of the computer industry, at least before the dot com era. The combined companies had lost hundreds of millions of dollars of investment capital.

There is an interesting Wikipedia article about Stardent that is primarily about the period after I left. It is all about law suits and counter law suits. I know some of the players, but I have no personal knowledge of the events in that article.

NA Digest Job Announcement

The NA Digest is an electronic newsletter for the community of numerical analysis and mathematical software that has been going since the early 1980's. I was its editor for a long time, including the period around the breakup of Stardent. In late October, 1989, I ran this announcement. (Note the MathWorks phone number at the time.)

From: Cleve Moler <>
Date: Sun Oct 29 10:39:38 PST 1989
Subject: Positions at The MathWorks
  The MathWorks is the company which develops and markets MATLAB.
  The company currently employs about 30 people and expects to
  add three or four more soon. The company headquarters is in
  East Natick, Massachusetts, which is about a half hour drive
  west of Boston.
  The background and interests expected for the various positions
  available range from numerical linear algebra and matrix computation
  to systems programming and graphics. Educational level and
  experience expected range from inexperienced beginner willing
  to learn to seasoned Ph.D. with a personal library of M-files.
  For more information, send email to
  or phone me at 408-732-0400. Or, contact the MathWorks' president,
  John Little, with email to ******, phone 508-653-1415,
  or write to:
  The MathWorks
  21 Eliot Street
  South Natick, MA 01760

A couple of weeks after posting this announcement in the NA Digest, I decided to resign my position at Stardent and take one of the jobs at MathWorks that I had advertised. I've been a regular full time employee of MathWorks ever since.

Further Reading

Michael R. Kaplan, The Design of the Dore Graphics System, in E. H. Blake and Peter Wisskirchen, editors, Advances in Object-Oriented Graphics I, Springer, pp 177-198, 1991, <>

Get the MATLAB code

Published with MATLAB® R2013b

2 CommentsOldest to Newest

Thanks for writing about this Cleve. I was at Stellar at the time, so it brings back a lot of memories.

I know the answer to this part of your post.

> On the East Coast, Stellar Computer was also having
> difficulties selling their machines. They did not have
> a vector machine, and I know less about the specifics
> of their frustrations, but I do know they were also
> suffering.

The Stellar GS 1000 did have a vector unit. You’ll find some details in chapter 7.5 of the first edition of Hennessy & Patterson’s “Computer Architecture a Quantitative Approach” (1), but you would really need a copy of “An Introduction to the architecture of the Stellar Graphics supercomputer” by Sporer, Mathias & Moss for all of the details. The short version is that the vector registers were quite a bit narrower than the ones in the Titan, but it had enough memory bandwidth that overall throughput was pretty similar for well vectorized code.

The problem we hit was when we ran scalar code. We had a 20Mhz scalar processor which was time-sliced so that each of the 4 threads only saw 5 Mhz of that. This meant that whenever we hit code we couldn’t vectorize or keep multiple threads busy, we were way behind machines like the Titan with its 12.5 Mhz (I believe) scalar processor. And because we had implemented the scalar unit with FPGA’s, we couldn’t keep up with the clock rate increases that companies like MIPS were hitting with each new generation of their chips.

I actually spent a lot of my spare time (when I wasn’t working on the graphics system) helping Mark Davis (2) get customer code to vectorize or run parallel. It was the only way we could compete, but in the end it was kind of hopeless. We would always seem to hit some bottleneck which could only run on a single 5 Mhz core, and then we couldn’t keep up.

1) They dropped the entire chapter on vector machines in later editions of the book because they decided that vector machines weren’t mainstream enough anymore.

2) One of our compiler gurus, now head of Intel’s VTune team

These postings are the author's and don't necessarily represent the opinions of MathWorks.