<commit_before><!--- WARNING: Auto-generated with wikize-refs.py from ApolloGuidanceComputerPart1.md --->
# Celebrating Apollo's 50th Anniversary: When 100 FLOPS/Watt Was a Giant Leap

**Hero Image:**

- <img src='https://github.com/betterscientificsoftware/images/raw/master/Blog_0429_Apollo1.jpg'/>[Image Source: NASA (see below)]

#### Contributed by [<NAME>](https://github.com/markcmiller86)
#### Publication date: May 10, 2019

*First of a three-part series to commemorate the 50th anniversary of the Moon landings.*

<br>

This year, July 20 will mark the 50th anniversary of the 1969 Apollo 11 Moon
landing.<sup>[1],[2]</sup> Between 1958 and 1965, both Russian and American space
programs attempted a total of over 36 unmanned Moon missions.<sup>[3]</sup>
Of the 6 that succeeded, none were survivable soft landings. Just crashing into
the Moon proved exceedingly difficult. Developing a guidance, navigation, and
control (GNC) system for manned Apollo missions<sup>[4],[9]</sup> was an
enormous challenge. At its heart was a revolutionary new computer: the Apollo
Guidance Computer (AGC).<sup>[5],[6],[7]</sup>

In commemoration of that historical achievement, this is the first of three
articles about the AGC. Part 1 describes the hardware. Part 2 will describe
the software and part 3 its application in Moon missions. In the years since its
development, jargon may have changed, but the HPC community will recognize
many common themes such as flops/watt power constraints, checkpoint and restart
strategies, and the need for performance portability.

### The AGC architecture: A giant leap in FLOPS<sup>a</sup> per W, Kg, m<sup>3</sup> 

Apollo needed a computer orders of magnitude better than those typical of the
era:<sup>[36]</sup> lower power, lighter weight, smaller size, greater reliability,
and able to operate in the extreme environmental conditions of space flight.
In mid-1961, NASA accorded MIT/Draper Labs “sole source” status to design the AGC
and soon after selected Raytheon to manufacture it.<sup>[7]</sup> Both organizations
had been involved in development of the Polaris missile GNC system.<sup>[17]</sup>

<br> 

[The AGC (left) with its Display and Keyboard Interface (DSKY - right). Image Source: NASA]<img src='https://github.com/betterscientificsoftware/images/raw/master/Blog_0429_computer_600_318.png' class='page lightbox' />

<br> 

The AGC was the first computer to use integrated circuits. It was constructed
entirely from dual-packaged, 3-input NOR gate flat-packs produced by Fairchild
Semiconductor<sup>[18]</sup> in an area that would eventually become known as
Silicon Valley.<sup>[25],[26]</sup> At its peak, the effort consumed over 60%
of all ICs produced in the country. The AGC used a total of 5,600 NOR gates,
operated at 1.024 MHz with a 16-bit word, and had 34 basic instructions each
micro-coded into a 12-step sequence. It had 4 central registers plus 15
special-purpose registers.<sup>[16]</sup> The table below compares key AGC
performance metrics with an early model of the IBM 360. Both systems were
released in 1966, the same year initial designs of the first massively parallel
computer, ILLIAC IV,<sup>[22]</sup> were completed. Costing nearly $5 billion
to develop, 20% of the entire Apollo budget, IBM's System 360 was a big gamble
and even bigger success.<sup>[30]</sup> In the table below, we also include a
row for comparison with IBM’s newest AC922<sup>[27]</sup> based systems
(Summit<sup>[20]</sup> / Sierra<sup>[24]</sup>).

<br> 

System | Kb | Flops (F) | (Watts) F/W | (Kg) F/Kg | (m<sup>3</sup>) F/m<sup>3</sup>
:--- | :---: | :---: | :---: | :---: | :---:
AGC Block II<sup>[12]</sup> | 76 | 14,245 | (55) 259.0 | (32) 445 | (00.03) 50000
IBM 360-20<sup>[10],[11]</sup> | 32 | 3,011 | (5000) 0.6 | (600) 5 | (30.00) 100
IBM AC922<br>(Summit<sup>[20],[21],[24]</sup>) | 1E12 | 14E16| (97E5) 14E9 | (31E4) 45E10 | (930) 15E13

<sup>a</sup>FLOP = single precision multiply + add

### Rope core: A new type of nonvolatile memory

The AGC utilized two types of *core* memory<sup>[14]</sup>: erasable memory
using coincident current cores and fixed (read-only) memory using rope
cores,<sup>[15]</sup> technology specifically designed for and unique to the
AGC. Both were nonvolatile, providing extra protection against data loss during
faults. The advantages of rope core were superlative robustness and
significantly higher density because a single core was used to store
24 bits.<sup>[5]</sup> On the other hand, rope core took weeks of painstaking
labor to hand-weave<sup>[13]</sup> thin wires through (logical ‘1’) or around
(logical ‘0’) arrays of cores. Bugs were costly to correct and often were just
worked around with additional steps in astronaut checklists or even by revising
mission parameters. Unable to fully automate this crucial manufacturing step,
Raytheon instead hired an army of experienced textile workers from the New
England area, all women. Remarkably, weaving and its place in computing date
back more than 150 years *earlier* to the Jacquard loom.<sup>[23],[28]</sup>
Present day operating system terms such as *core dump* or *core image* are
derived from this early memory technology.

<br> 

[A worker weaves copper wires through an array of cores for the AGC (Photo courtesy of Raytheon Company)]
<img src='https://github.com/betterscientificsoftware/images/raw/master/Blog_0429_RaytheonWorker_575_528.jpg' class='page lightbox' />

### The Executive: An operating system with checkpoint/restart services
The AGC used a priority-driven, collaborative, multitasking operating system
called the *Executive*.<sup>[5]</sup> Priority-based job scheduling was
revolutionary for its time. The Executive could detect a variety of hardware
and software faults and had restart utilities to recover. But, only the most
critical programs were restart protected.<sup>[19]</sup> This involved careful
design with periodic updates of *waypoints* (redundant copies of essential state
throughout program execution). Restart support consumed resources and
complicated testing. In 1968, an internal NASA report<sup>[19]</sup> raised
significant doubts about its value. In Part 3 of this series, we’ll describe why
it would later be proven invaluable during the Apollo 11 landing.

### The Interpreter: A domain-specific language
The Executive and other system functions were all implemented in AGC native
assembly code<sup>[31]</sup>. However, solving complex, 3D spatial navigation
problems with this simple instruction set was tedious, error prone, and memory
consuming. Early on, engineers designed a higher-level language, called the
*Interpreter*,<sup>[5]</sup> to support the complex software required for GNC
operations. Operands were scalar, vector, and matrix data types in single,
double, and even triple precision. Instructions included vector and matrix
arithmetic functions, transcendental functions, float normalization functions
and other miscellaneous control-flow functions. Similar to p-code,<sup>[33]</sup>
it was still a form of assembly language. But, it operated at a much higher
level of abstraction easing development, improving overall reliability and,
most importantly, reducing memory usage.

### Multiple spacecraft configurations: A performance portability challenge
Apollo wasn't just a single spacecraft. It was two: the Command and Service
Module (CSM) and the Lunar Module (LM). Each had its own AGC and was further
divided into two stages. Depending on the phase of a mission<sup>[1]</sup>,
the vehicles were joined together in various configurations with dramatically
different operating characteristics. Developing a single program, the Digital
Auto Pilot (DAP),<sup>[8]</sup> to provide effective GNC for any configuration,
even off-nominal cases, presented what amounts to a significant performance
portability problem. In Part 2 of this series we'll discuss how software
developers met this challenge.

<br> 

[Early NASA artist's rendition of Apollo Spacecraft. Command and Service Module (left) Lunar Module Ascent and Descent Stages (right)]<img src='https://github.com/betterscientificsoftware/images/raw/master/Blog_0429_CSM_and_LM_600_338.png' class='page lightbox' />

<br>

### An MTBF of 40,000 Hours: Extremely Reliable Computing
The AGC may not have been extreme in scale but it was extreme in reliability.
Of the 42 Block II systems delivered and an aggregate of 11,000 hours of
vibration exposure and thermal cycling plus 32,500 hours of normal operation,
only 4 hardware faults were observed,<sup>[12]</sup> none of which occurred in
actual Moon missions. A conservative estimate of the MTBF of the AGC was later
calculated to be over 40,000 hours, more than an order of magnitude better than
machines typical of that era. Little did AGC hardware engineers know that writing
the software would present even greater challenges, ultimately becoming the
rate-determining factor in delivering flight-ready units.

Autonomous guidance was so critical for Apollo, NASA funded the development of
this revolutionary new computer to support it.<sup>[35]</sup> Half a century
later, self-driving is so critical in the auto industry, Tesla has
developed their own custom, proprietary AI chip to support it.<sup>[32]</sup>

<br>
<commit_msg>defined MTBF<commit_after><!--- WARNING: Auto-generated with wikize-refs.py from ApolloGuidanceComputerPart1.md --->
# Celebrating Apollo's 50th Anniversary: When 100 FLOPS/Watt Was a Giant Leap

**Hero Image:**

- <img src='https://github.com/betterscientificsoftware/images/raw/master/Blog_0429_Apollo1.jpg'/>[Image Source: NASA (see below)]

#### Contributed by [<NAME>](https://github.com/markcmiller86)
#### Publication date: May 10, 2019

*First of a three-part series to commemorate the 50th anniversary of the Moon landings.*

<br>

This year, July 20 will mark the 50th anniversary of the 1969 Apollo 11 Moon
landing.<sup>[1],[2]</sup> Between 1958 and 1965, both Russian and American space
programs attempted a total of over 36 unmanned Moon missions.<sup>[3]</sup>
Of the 6 that succeeded, none were survivable soft landings. Just crashing into
the Moon proved exceedingly difficult. Developing a guidance, navigation, and
control (GNC) system for manned Apollo missions<sup>[4],[9]</sup> was an
enormous challenge. At its heart was a revolutionary new computer: the Apollo
Guidance Computer (AGC).<sup>[5],[6],[7]</sup>

In commemoration of that historical achievement, this is the first of three
articles about the AGC. Part 1 describes the hardware. Part 2 will describe
the software and part 3 its application in Moon missions. In the years since its
development, jargon may have changed, but the HPC community will recognize
many common themes such as flops/watt power constraints, checkpoint and restart
strategies, and the need for performance portability.

### The AGC architecture: A giant leap in FLOPS<sup>a</sup> per W, Kg, m<sup>3</sup> 

Apollo needed a computer orders of magnitude better than those typical of the
era:<sup>[36]</sup> lower power, lighter weight, smaller size, greater reliability,
and able to operate in the extreme environmental conditions of space flight.
In mid-1961, NASA accorded MIT/Draper Labs “sole source” status to design the AGC
and soon after selected Raytheon to manufacture it.<sup>[7]</sup> Both organizations
had been involved in development of the Polaris missile GNC system.<sup>[17]</sup>

<br> 

[The AGC (left) with its Display and Keyboard Interface (DSKY - right). Image Source: NASA]<img src='https://github.com/betterscientificsoftware/images/raw/master/Blog_0429_computer_600_318.png' class='page lightbox' />

<br> 

The AGC was the first computer to use integrated circuits. It was constructed
entirely from dual-packaged, 3-input NOR gate flat-packs produced by Fairchild
Semiconductor<sup>[18]</sup> in an area that would eventually become known as
Silicon Valley.<sup>[25],[26]</sup> At its peak, the effort consumed over 60%
of all ICs produced in the country. The AGC used a total of 5,600 NOR gates,
operated at 1.024 MHz with a 16-bit word, and had 34 basic instructions each
micro-coded into a 12-step sequence. It had 4 central registers plus 15
special-purpose registers.<sup>[16]</sup> The table below compares key AGC
performance metrics with an early model of the IBM 360. Both systems were
released in 1966, the same year initial designs of the first massively parallel
computer, ILLIAC IV,<sup>[22]</sup> were completed. Costing nearly $5 billion
to develop, 20% of the entire Apollo budget, IBM's System 360 was a big gamble
and even bigger success.<sup>[30]</sup> In the table below, we also include a
row for comparison with IBM’s newest AC922<sup>[27]</sup> based systems
(Summit<sup>[20]</sup> / Sierra<sup>[24]</sup>).

<br> 

System | Kb | Flops (F) | (Watts) F/W | (Kg) F/Kg | (m<sup>3</sup>) F/m<sup>3</sup>
:--- | :---: | :---: | :---: | :---: | :---:
AGC Block II<sup>[12]</sup> | 76 | 14,245 | (55) 259.0 | (32) 445 | (00.03) 50000
IBM 360-20<sup>[10],[11]</sup> | 32 | 3,011 | (5000) 0.6 | (600) 5 | (30.00) 100
IBM AC922<br>(Summit<sup>[20],[21],[24]</sup>) | 1E12 | 14E16| (97E5) 14E9 | (31E4) 45E10 | (930) 15E13

<sup>a</sup>FLOP = single precision multiply + add

### Rope core: A new type of nonvolatile memory

The AGC utilized two types of *core* memory<sup>[14]</sup>: erasable memory
using coincident current cores and fixed (read-only) memory using rope
cores,<sup>[15]</sup> technology specifically designed for and unique to the
AGC. Both were nonvolatile, providing extra protection against data loss during
faults. The advantages of rope core were superlative robustness and
significantly higher density because a single core was used to store
24 bits.<sup>[5]</sup> On the other hand, rope core took weeks of painstaking
labor to hand-weave<sup>[13]</sup> thin wires through (logical ‘1’) or around
(logical ‘0’) arrays of cores. Bugs were costly to correct and often were just
worked around with additional steps in astronaut checklists or even by revising
mission parameters. Unable to fully automate this crucial manufacturing step,
Raytheon instead hired an army of experienced textile workers from the New
England area, all women. Remarkably, weaving and its place in computing date
back more than 150 years *earlier* to the Jacquard loom.<sup>[23],[28]</sup>
Present day operating system terms such as *core dump* or *core image* are
derived from this early memory technology.

<br> 

[A worker weaves copper wires through an array of cores for the AGC (Photo courtesy of Raytheon Company)]
<img src='https://github.com/betterscientificsoftware/images/raw/master/Blog_0429_RaytheonWorker_575_528.jpg' class='page lightbox' />

### The Executive: An operating system with checkpoint/restart services
The AGC used a priority-driven, collaborative, multitasking operating system
called the *Executive*.<sup>[5]</sup> Priority-based job scheduling was
revolutionary for its time. The Executive could detect a variety of hardware
and software faults and had restart utilities to recover. But, only the most
critical programs were restart protected.<sup>[19]</sup> This involved careful
design with periodic updates of *waypoints* (redundant copies of essential state
throughout program execution). Restart support consumed resources and
complicated testing. In 1968, an internal NASA report<sup>[19]</sup> raised
significant doubts about its value. In Part 3 of this series, we’ll describe why
it would later be proven invaluable during the Apollo 11 landing.

### The Interpreter: A domain-specific language
The Executive and other system functions were all implemented in AGC native
assembly code<sup>[31]</sup>. However, solving complex, 3D spatial navigation
problems with this simple instruction set was tedious, error prone, and memory
consuming. Early on, engineers designed a higher-level language, called the
*Interpreter*,<sup>[5]</sup> to support the complex software required for GNC
operations. Operands were scalar, vector, and matrix data types in single,
double, and even triple precision. Instructions included vector and matrix
arithmetic functions, transcendental functions, float normalization functions
and other miscellaneous control-flow functions. Similar to p-code,<sup>[33]</sup>
it was still a form of assembly language. But, it operated at a much higher
level of abstraction easing development, improving overall reliability and,
most importantly, reducing memory usage.

### Multiple spacecraft configurations: A performance portability challenge
Apollo wasn't just a single spacecraft. It was two: the Command and Service
Module (CSM) and the Lunar Module (LM). Each had its own AGC and was further
divided into two stages. Depending on the phase of a mission<sup>[1]</sup>,
the vehicles were joined together in various configurations with dramatically
different operating characteristics. Developing a single program, the Digital
Auto Pilot (DAP),<sup>[8]</sup> to provide effective GNC for any configuration,
even off-nominal cases, presented what amounts to a significant performance
portability problem. In Part 2 of this series we'll discuss how software
developers met this challenge.

<br> 

[Early NASA artist's rendition of Apollo Spacecraft. Command and Service Module (left) Lunar Module Ascent and Descent Stages (right)]<img src='https://github.com/betterscientificsoftware/images/raw/master/Blog_0429_CSM_and_LM_600_338.png' class='page lightbox' />

<br>

### An MTBF of 40,000 hours: Extremely reliable computing
The AGC may not have been extreme in scale but it was extreme in reliability.
Of the 42 Block II systems delivered and an aggregate of 11,000 hours of
vibration exposure and thermal cycling plus 32,500 hours of normal operation,
only 4 hardware faults were observed,<sup>[12]</sup> none of which occurred in
actual Moon missions. A conservative estimate of the mean time between failures (MTBF) of the AGC was later
calculated to be over 40,000 hours, more than an order of magnitude better than
machines typical of that era. Little did AGC hardware engineers know that writing
the software would present even greater challenges, ultimately becoming the
rate-determining factor in delivering flight-ready units.

Autonomous guidance was so critical for Apollo, NASA funded the development of
this revolutionary new computer to support it.<sup>[35]</sup> Half a century
later, self-driving is so critical in the auto industry, Tesla has
developed their own custom, proprietary AI chip to support it.<sup>[32]</sup>

<br>

{'fraction_non_alphanumeric': 0.08468002585649645, 'fraction_numerical': 0.033828916181857356, 'mean_word_length': 5.086885245901639, 'pattern_counts': {'":': 0, '<': 189, '<?xml version=': 0, '>': 189, 'https://': 10, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 4, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '3626820', 'n_tokens_mistral': 5750, 'n_tokens_neox': 4925, 'n_words': 2467}