4 ms·

GameTales: Cray 6400 (2015)

53 points by mariuz 4y ago

belthesar 4y ago
Huddled around a table at the local Mongolian grill restaurant, 3 young punk nerds cooked up a wild idea: One of us had found a Cray T3E was for sale on eBay. We mused: What would happen if a truck rolled up on Quakecon, and we asked Carmack "will it play Doom?" 15 years later, I got my answer: https://twitter.com/belthesar/status/1341185861392740358 https://twitter.com/belthesar/status/1341185861392740358
sillywalk 4y ago
"Each person would have a hardware interface board that had keyboard and mouse inputs with video output on it." Interesting. I wonder if Solaris (I assume it would be running Solaris) would support that kind of multi-head thing.
mariuz 4y ago
via https://twitter.com/pikuma/status/1634222216463409152 https://twitter.com/pikuma/status/1634222216463409152
dfox 4y ago
It is probably of note that 6400 was not supercomputer per-se but Cray's attempt to produce bussines oriented mainframe. It was SPARC based more or less sun4d machine. As it did not exactly fit into SGI's lineup, after the SGI aquisition it was quickly sold to Sun who then made larger UltraSPARC based variant known as Enterprise 10000. From the technical perspective it is a large single system image multiprocessor system running solaris with hardware support for logical partitioning (which famously involves configuring the backplane logic through JTAG from attached sun4 machine with somewhat non-trivial software).
- neilv 4y ago
  If it's like the Cray S-MP, it was a very powerful SunOS/Solaris box. Plus a lot of Cray mystique. I was fortunate as a teen to visit Cray Research Superservers (a cab ride away), to port our workstation software to it. The port was trivial, and took less than a day. (One of our marketing people was exploring a partnership with Cray, and I guess no real software engineers were available, so they sent the intern.)
fulafel 4y ago
> Shortly after I released Quake on June 22, 1996, John decided that developing on Windows NT 3.1 was the way to go. His first project was porting QuakeEd over to Win32. I left id on August 6, 1996. I guess there's different ways to parse the subtext. He didn't want to work on Windows? I can emphatise. Also interesting is the Carmack reply in the comments section which says the point of this model was its potential NextSTEP/SPARC compatibility.
- bluedino 4y ago
  > He didn't want to work on Windows? I can emphatise. You didn't really have a choice when it comes to making games. Other than the consoles.
  - fulafel 4y ago
    NeXT was their existing workflow, they built the content on tools running on NeXT and then targeted DOS.
    - bluedino 4y ago
      Sure, but NeXT was basically dead by that time and there wasn't any way they could develop a modern (at the time) game on it (say Quake III). And even though they ran the level editor, I doubt whatever the top of the line NeXT machine was at the time could even run Quake 1 at a decent framerate.
      - fulafel 4y ago
        Yep, NeXT was long in the tooth, but they could have moved the content tools and cross build env to another other *ix platform. (And even for running the game .. Q3 was OpenGL, and PC gaming GPUs had yet to overtake the workstation 3D hardware).
        bluedino 4y ago
        If they weren't terrible they might have. You've probably read this before: https://rmitz.org/carmack.on.operating.systems.html https://rmitz.org/carmack.on.operating.systems.html
phkamp 4y ago
The "Cray" 6400 was really the "Sun Sparcenter 4000". I dont know if Sun paid Cray to get their name on it, but I'm sure Cray did not pick it up because of the fantastic CPU performance. The entire sun4d series had the same fundamental issue: When a CPU missed local cache and fetched across the "X-Bus", instead of returning a single word as fast as possible in a 2-cycle packet, the memory board did four sequential memory accesses and sent a 9-cycle packet. The net effect of this was to turn it into an 8MHz machine, if your program did not fit well in the 1Mbyte CPU-cache. On the plus side, you could stick amazing numbers of S-bus cards into those boxes, for instance if you needed a lot of disks for statistical seek-time reduction. We had five SS1000's as file servers, they had 9 differential SCSI controllers each, with each controller servicing three Seagate 2GB "Elite" drives - a whopping total of 270 GB, mirrored and striped with Veritas.
- dfox 4y ago
  CS6400 is not exactly the same thing as SC4000/6000, but the same design slightly improved by people at Cray's business systems division (which originally was FPS Inc.). On the other hand it is still fundamentally sun4d (ie. non-NUMA) machine with partitioning support bolted onto the XDbus architecture.

53 points by mariuz 4y ago

Huddled around a table at the local Mongolian grill restaurant, 3 young punk nerds cooked up a wild idea: One of us had found a Cray T3E was for sale on eBay. We mused: What would happen if a truck rolled up on Quakecon, and we asked Carmack "will it play Doom?" 15 years later, I got my answer: https://twitter.com/belthesar/status/1341185861392740358 https://twitter.com/belthesar/status/1341185861392740358

sillywalk 4y ago

"Each person would have a hardware interface board that had keyboard and mouse inputs with video output on it." Interesting. I wonder if Solaris (I assume it would be running Solaris) would support that kind of multi-head thing.

mariuz 4y ago

via https://twitter.com/pikuma/status/1634222216463409152 https://twitter.com/pikuma/status/1634222216463409152

dfox 4y ago

It is probably of note that 6400 was not supercomputer per-se but Cray's attempt to produce bussines oriented mainframe. It was SPARC based more or less sun4d machine. As it did not exactly fit into SGI's lineup, after the SGI aquisition it was quickly sold to Sun who then made larger UltraSPARC based variant known as Enterprise 10000. From the technical perspective it is a large single system image multiprocessor system running solaris with hardware support for logical partitioning (which famously involves configuring the backplane logic through JTAG from attached sun4 machine with somewhat non-trivial software).

neilv 4y ago
If it's like the Cray S-MP, it was a very powerful SunOS/Solaris box. Plus a lot of Cray mystique. I was fortunate as a teen to visit Cray Research Superservers (a cab ride away), to port our workstation software to it. The port was trivial, and took less than a day. (One of our marketing people was exploring a partnership with Cray, and I guess no real software engineers were available, so they sent the intern.)

fulafel 4y ago

> Shortly after I released Quake on June 22, 1996, John decided that developing on Windows NT 3.1 was the way to go. His first project was porting QuakeEd over to Win32. I left id on August 6, 1996. I guess there's different ways to parse the subtext. He didn't want to work on Windows? I can emphatise. Also interesting is the Carmack reply in the comments section which says the point of this model was its potential NextSTEP/SPARC compatibility.

bluedino 4y ago
> He didn't want to work on Windows? I can emphatise. You didn't really have a choice when it comes to making games. Other than the consoles.
- fulafel 4y ago
  NeXT was their existing workflow, they built the content on tools running on NeXT and then targeted DOS.
  - bluedino 4y ago
    Sure, but NeXT was basically dead by that time and there wasn't any way they could develop a modern (at the time) game on it (say Quake III). And even though they ran the level editor, I doubt whatever the top of the line NeXT machine was at the time could even run Quake 1 at a decent framerate.
    - fulafel 4y ago
      Yep, NeXT was long in the tooth, but they could have moved the content tools and cross build env to another other *ix platform. (And even for running the game .. Q3 was OpenGL, and PC gaming GPUs had yet to overtake the workstation 3D hardware).
      - bluedino 4y ago
        If they weren't terrible they might have. You've probably read this before: https://rmitz.org/carmack.on.operating.systems.html https://rmitz.org/carmack.on.operating.systems.html

phkamp 4y ago

The "Cray" 6400 was really the "Sun Sparcenter 4000". I dont know if Sun paid Cray to get their name on it, but I'm sure Cray did not pick it up because of the fantastic CPU performance. The entire sun4d series had the same fundamental issue: When a CPU missed local cache and fetched across the "X-Bus", instead of returning a single word as fast as possible in a 2-cycle packet, the memory board did four sequential memory accesses and sent a 9-cycle packet. The net effect of this was to turn it into an 8MHz machine, if your program did not fit well in the 1Mbyte CPU-cache. On the plus side, you could stick amazing numbers of S-bus cards into those boxes, for instance if you needed a lot of disks for statistical seek-time reduction. We had five SS1000's as file servers, they had 9 differential SCSI controllers each, with each controller servicing three Seagate 2GB "Elite" drives - a whopping total of 270 GB, mirrored and striped with Veritas.

dfox 4y ago
CS6400 is not exactly the same thing as SC4000/6000, but the same design slightly improved by people at Cray's business systems division (which originally was FPS Inc.). On the other hand it is still fundamentally sun4d (ie. non-NUMA) machine with partitioning support bolted onto the XDbus architecture.