Fourmilog: None Dare Call It Reason

Reading List: The Berlin Project

Saturday, December 9, 2017 00:31

Benford, Gregory. The Berlin Project. New York: Saga Press, 2017. ISBN 978-1-4814-8765-8.
In September 1938, Karl Cohen returned from a postdoctoral position in France to the chemistry department at Columbia University in New York, where he had obtained his Ph.D. two years earlier. Accompanying him was his new wife, Marthe, daughter of a senior officer in the French army. Cohen went to work for Harold Urey, professor of chemistry at Columbia and winner of the 1934 Nobel Prize in chemistry for the discovery of deuterium. At the start of 1939, the fields of chemistry and nuclear physics were stunned by the discovery of nuclear fission: researchers at the Kaiser Wilhelm Institute in Berlin had discovered that the nucleus of Uranium-235 could be split into two lighter nuclei when it absorbed a neutron, releasing a large amount of energy and additional neutrons which might be able to fission other uranium nuclei, creating a “chain reaction” which might permitting tapping the enormous binding energy of the nucleus to produce abundant power—or a bomb.

The discovery seemed to open a path to nuclear power, but it was clear from the outset that the practical challenges were going to be daunting. Natural uranium is composed of two principal isotopes, U-238 and U-235. The heavier U-238 isotope makes up 99.27% of natural uranium, while U-235 accounts for only 0.72%. Only U-235 can readily be fissioned, so in order to build a bomb, it would be necessary to separate the two isotopes and isolate near-pure U-235. Isotopes differ only in the number of neutrons in their nuclei, but have the same number of protons and electrons. Since chemistry is exclusively determined by the electron structure of an atom, no chemical process can separate two isotopes: it must be done physically, based upon their mass difference. And since U-235 and U-238 differ in mass only by around 1.25%, any process, however clever, would necessarily be inefficient and expensive. It was clear that nuclear energy or weapons would require an industrial-scale effort, not something which could be done in a university laboratory.

Several candidate processes were suggested: electromagnetic separation, thermal or gaseous diffusion, and centrifuges. Harold Urey believed a cascade of high-speed centrifuges, fed with uranium hexafluoride gas, was the best approach, and he was the world's foremost expert on gas centrifuges. The nascent uranium project, eventually to become the Manhattan Project, was inclined toward the electromagnetic and gaseous diffusion processes, since they were believed to be well-understood and only required a vast scaling up as opposed to demonstration of a novel and untested technology.

Up to this point, everything in this alternative history novel is completely factual, and all of the characters existed in the real world (Karl Cohen is the author's father in-law). Historically, Urey was unable to raise the funds to demonstrate the centrifuge technology, and the Manhattan project proceeded with the electromagnetic and gaseous diffusion routes to separate U-235 while, in parallel, pursuing plutonium production from natural uranium in graphite-moderated reactors. Benford adheres strictly to the rules of the alternative history game in that only one thing is changed, and everything else follows as consequences of that change.

Here, Karl Cohen contacts a prominent Manhattan rabbi known to his mother who, seeing a way to combine protecting Jews in Europe from Hitler, advancing the Zionist cause, and making money from patents on a strategic technology, assembles a syndicate of wealthy and like-minded investors, raising a total of a hundred thousand dollars (US$ 1.8 million in today's funny money) to fund Urey's prototype centrifuge project in return for rights to patents on the technology. Urey succeeds, and by mid-1941 the centrifuge has been demonstrated and contacts made with Union Carbide to mass-produce and operate a centrifuge separation plant. Then, in early December of that year, everything changed, and by early 1942 the Manhattan Project had bought out the investors at a handsome profit and put the centrifuge separation project in high gear. As Urey's lead on the centrifuge project, Karl Cohen finds himself in the midst of the rapidly-developing bomb project, meeting and working with all of the principals.

Thus begins the story of a very different Manhattan Project and World War II. With the centrifuge project starting in earnest shortly after Pearl Harbor, by June 6th, 1944 the first uranium bomb is ready, and the Allies decide to use it on Berlin as a decapitation strike simultaneous with the D-Day landings in Normandy. The war takes a very different course, both in Europe and the Pacific, and a new Nazi terror weapon, first hinted at in a science fiction story, complicates the conflict. A different world is the outcome, seen from a retrospective at the end.

Karl Cohen's central position in the Manhattan Project introduces us to a panoply of key players including Leslie Groves, J. Robert Oppenheimer, Edward Teller, Leo Szilard, Freeman Dyson, John W. Campbell, Jr., and Samuel Goudsmit. He participates in a secret mission to Switzerland to assess German progress toward a bomb in the company of professional baseball catcher become spy Moe Berg, who is charged with assassinating Heisenberg if Cohen judges he knows too much.

This is a masterpiece of alternative history, based firmly in fact, and entirely plausible. The description of the postwar consequences is of a world in which I would prefer to have been born. I won't discuss the details to avoid spoiling your discovery of how they all work out in the hands of a master storyteller who really knows his stuff (Gregory Benford is a Professor Emeritus of physics at the University of California, Irvine).


Marinchip Systems: Three New Documents

Thursday, December 7, 2017 21:52

I have just added three new documents to the Marinchip Systems: Documents and Images collection.

M9900 CPU Assembly Instructions
PDF scan of the assembly instructions provided with the M9900 CPU kit. While production values were modest and there were no illustrations, I tried to be thorough and even occasionally humorous.
M9900 CPU: New Product Announcement
Concurrent with running our first advertisement, this new product press release was sent to all the personal computer and electronics magazines.
M9900 CPU Brochure (March 1978)
When we introduced the M9900 CPU at the West Coast Computer Faire, we weren't yet ready to take and ship orders. This is the brochure we gave away to visitors of our booth.


Univac Document Archive: 1107 FORTRAN Programmer's Guide Added

Tuesday, December 5, 2017 16:26

I have added the following document to the Univac 1107 section of the Univac Document Archive.

This is a PDF of a scanned paper document in my collection. This document is more than fifty years old (published in 1966) and may appear wonky to contemporary eyes: text is sometimes misaligned on the page and multiple fonts are intermixed like a ransom note. These are not artefacts of scanning—it's how the document actually appears. Recall that only around 38 Univac 1107s were sold, so documents describing it were produced in small numbers and didn't, in the eyes of Univac, merit the expense of the high production values of contemporary IBM manuals.

Univac 1107 FORTRAN was developed by Computer Sciences Corporation (CSC) and then maintained and extended by Univac programmers. It is based upon the dialect of Fortran which IBM originally released in 1965 under the name FORTRAN IV. This dialect, with a few minor changes, was standardised in 1966 as X3.9-1966 FORTRAN 66 by the American Standards Association (now ANSI), but many people continued to refer to it as FORTRAN IV. The CSC/Univac implementation is essentially compatible with FORTRAN 66 and IBM FORTRAN IV. Many Univac customers referred to the compiler as FORTRAN IV, although Univac never called it that.

This is the manual from which, along with Daniel McCracken's A Guide to Fortran IV Programming, I learned Fortran programming fifty years ago. The manual was intended as an introduction to the Fortran language and informal reference. It is a companion to U-3569, Univac 1107 FORTRAN Programmer's Reference Manual, of which I do not have a copy (and can't recall having ever seen).

The manual contains two sample programs: a simple iterative approximation program and a sort subroutine. Of course I had to type them in and see if they'd work more than half a century later. They both did, although the sort subroutine required a few minor syntactic tweaks. You can download an archive containing source code for these programs. See the README file in the archive for details.

When the Univac 1108 was released, the Fortran compiler was modified to exploit the 1108's new instructions, in particular native hardware support for 72-bit double precision floating point arithmetic (the 1107 compiler supported double precision with a different format implemented in software). The language was extended to include some additional features such as the PARAMETER declaration. Univac called this compiler FORTRAN V, and it remained the standard FORTRAN for the 1100 series until the introduction of ASCII Fortran, which was compatible with the FORTRAN 77 standard and used the ASCII character set.


Univac Document Archive: 1107 EXEC II Manual Added

Thursday, November 30, 2017 23:36

I have added the following document to the Univac 1107 section of the Univac Document Archive.

This is a PDF of a scanned paper document in my collection. This document is more than fifty years old and may appear wonky to contemporary eyes: text is sometimes misaligned on the page and multiple fonts are intermixed like a ransom note. These are not artefacts of scanning—it's how the document actually appears. Recall that only around 38 Univac 1107s were sold, so documents describing it were produced in small numbers and didn't, in the eyes of Univac, merit the expense of the high production values of contemporary IBM manuals.

EXEC II was originally developed by Computer Sciences Corporation (CSC) and dubbed the “1107 Monitor System”. When Univac adopted it as an alternative high-performance serial batch system, they renamed it “EXEC II”, redesignating their own multi-tasking system “EXEC I”. This manual was produced from CSC's manual by pasting corrections which changed the name of the system and some of its terminology over the original text. The replacement text was typewritten in a different font, and is obvious. Although EXEC II ran a single user job at a time, it had the ability to operate peripherals such as card readers, card punches, and line printers simultaneously with computation via interrupt-driven background tasks. CSC called these “parasites”, but Univac deemed this terminology infelicitous and renamed them “symbionts”, crudely replacing the text throughout the manual. Well, almost everywhere. Eagle-eyed readers will be amused to discover they missed a few.

EXEC II was also available for the Univac 1108, and as late as 1973 I worked for a site which still ran it. The Univac Document Archive also includes a 1966 1108 EXEC II manual which has been entirely re-set from the 1963 original and includes additional information. There was little difference between the 1107 and 1108 versions of EXEC II: on the 1108 the system did not take advantage of the 1108's memory relocation or guard mode facilities, and remained vulnerable to rogue programs which could destroy it.


Floating Point Benchmark: Modula-2 Language Added, Python 3.x Added

Friday, November 24, 2017 22:25

I have posted a new edition of the floating point benchmark collection which adds the Modula-2 language to those in which the benchmark has been implemented. In addition, this release adds a version of the benchmark compatible with Python version 3.x (a Python 2.x version of the benchmark has been included in the collection since November 2006).

Modula-2 was developed by Niklaus Wirth between 1977 and 1985. He viewed the language as the successor to Pascal and Modula, and used it for all system and application programming for his Lilith workstation. Modula-2 extended the earlier languages by supporting separate compilation and encapsulation with a module mechanism, coroutines for concurrent processes, and facilities for access to low-level data structures for system programming. Several versions of Modula-2 were released between 1983 and 1988, refining the language specification. In 1996 and 1998, ISO issued three standards under ISO/IEC 10514 for the base language and extensions for object-oriented programming and generics.

Modula-2 is a conventional imperative programming language. Programmers familiar with Pascal will have little difficulty mastering Modula-2. Modula-2 has been used for a number of projects in industry including embedded systems including General Motors' first engine control computer.

Philippe Guiochon developed a Modula-2 version of the benchmark, starting from the FreeBASIC version of the program. He contributed two versions of the program for different compilers: J.P.I. TopSpeed v3.1 for MS-DOS and Excelsior XDS v2.60 beta for Windows 32. Due to small differences in the libraries supported by these compilers, two different versions of the benchmark source code are supplied as fbench_JPI.mod and fbench_XDS.mod. M. Guiochon ran timing tests on a variety of computers, which are included in the source code for the benchmarks.

Since I do not have a machine which can run these programs (Fourmilab is Microsoft free), I was unable to run an archival benchmark and comparison against C for the language comparison table. Since there is a GNU Modula-2 compiler, built atop the GCC (GNU Compiler Collection) infrastructure, that supports the ISO dialect of the language, I decided to see if I could get the code working with it.

I used fbench_JPI.mod as the point of departure to develop a version compatible with GNU Modula-2 in ISO mode with its ISO libraries. I restructured the program, removed the INTRIG code (I'm interested in comparing languages, not their library mathematical functions), and tried to make it more in keeping with the style of Modula-2 than its Basic ancestor. This program, fbench.mod, compiled with GNU Modula-2 version gm2-1.6.4, which is built on gcc-6.4.0 with:

gm2 -O3 -fiso -flibs=iso,pim -Wpedantic fbench.mod -o fbench
is the basis for the timing tests.

After a preliminary run to estimate an iteration count, I ran five runs of 175,495,723 iterations on an idle machine with a mean run time of 294.85 seconds, or 1.6801 microseconds per iteration. This compares with the reference C implementation, which on GCC 5.4.0 ran 166,051,660 iterations in a mean time of 296.536, or 1.7858 microseconds per iteration.

Thus the execution time is 0.941 times that of C (Modula2 is about 6% faster than C). Note that this is almost precisely the speed ratio of the C++ version of the benchmark (0.939) compiled with GCC compared to the C implementation compiled with the same compiler. This makes sense since the back-end of the compiler is the same for both the G++ and GM2 compilers, and the structure of the programs they're compiling is similar.

Philippe Guiochon then re-tested the fbench.mod program with the Excelsior XDS Modula-2 compiler on Windows 32, and encountered both compile errors and accuracy problems. The XDS compiler defines the REAL type to be 32-bit single-precision floating point, which is insufficient for the accuracy needs of this algorithm, and requires variables to be declared as LONGREAL to use 64-bit double precision (which then requires importing the trigonometric functions from the LongMath module). In addition, this compiler does not permit enumeration types to be used as array indices or bounds in FOR statements and requires them to be explicitly converted to CARDINAL with the ORD() function. Using the ORD() function is ugly but compatible with GNU Modula-2, but declaring variables as LONGREAL causes that compiler to use the Intel 80-bit floating point type (GCC's “long double”) instead of the standard 64-bit data type it uses for REAL. Since this may affect the timing (and still other compilers may define REAL and LONGREAL in yet other ways), I have kept this version separate as fbench_iso_XDS.mod and used the original fbench.mod for the timing tests with GNU Modula-2.

Source code for all of these programs is included in the modula2 directory of the distribution.

Completely unrelated to Modula-2, this release of the benchmark collection adds an implementation of the benchmark compatible with version 3 of the Python language. The original version of the Python benchmark, developed in November 2006, was based upon version 2 of Python. Python version 3 made some incompatible changes to the syntax and semantics of the language, requiring changes in many programs. The impact of the changes on the benchmark were relatively minor and required only the following modifications:

  • Change print statements to calls on the eponymous function.
  • Use the end="" mechanism to indicate no carriage return and new line at the end of a print instead of the Python 2 trailing comma.
  • Add a call to sys.stdout.flush() after printing prompts to guarantee the buffer is flushed to the console.
  • Change reference to string.atoi() to locale.atoi() and import locale to define it.
With these changes, the benchmark ran with no errors or warnings on Python 3.5.2 and PyPy 5.9.0-beta0, which is based upon Python 3.5.3. The timings were comparable to those on Python 2.7.6 and PyPy 2.2.1, so I did not bother re-running archival timing tests.

I have restructured the python directory in the distribution to contain two subdirectories, python2 and python3, which contain files for their respective versions of the language.

Download floating point benchmark collection

Language Relative
C 1 GCC 3.2.3 -O3, Linux
JavaScript 0.372
Mozilla Firefox 55.0.2, Linux
Safari 11.0, MacOS X
Brave 0.18.36, Linux
Google Chrome 61.0.3163.91, Linux
Chromium 60.0.3112.113, Linux
Node.js v6.11.3, Linux
Chapel 0.528
Chapel 1.16.0, -fast, Linux
Parallel, 64 threads
Visual Basic .NET 0.866 All optimisations, Windows XP
C++ 0.939
G++ 5.4.0, -O3, Linux, double
long double (80 bit)
__float128 (128 bit)
MPFR (128 bit)
MPFR (512 bit)
Modula-2 0.941 GNU Modula-2 gm2-1.6.4 -O3, Linux
FORTRAN 1.008 GNU Fortran (g77) 3.2.3 -O3, Linux
Pascal 1.027
Free Pascal 2.2.0 -O3, Linux
GNU Pascal 2.1 (GCC 2.95.2) -O3, Linux
Swift 1.054 Swift 3.0.1, -O, Linux
Rust 1.077 Rust 0.13.0, --release, Linux
Java 1.121 Sun JDK 1.5.0_04-b05, Linux
Visual Basic 6 1.132 All optimisations, Windows XP
Haskell 1.223 GHC 7.4.1-O2 -funbox-strict-fields, Linux
Scala 1.263 Scala 2.12.3, OpenJDK 9, Linux
FreeBASIC 1.306 FreeBASIC 1.05.0, Linux
Ada 1.401 GNAT/GCC 3.4.4 -O3, Linux
Go 1.481 Go version go1.1.1 linux/amd64, Linux
Julia 1.501 Julia version 0.6.1 64-bit -O2 --check-bounds=no, Linux
Simula 2.099 GNU Cim 5.1, GCC 4.8.1 -O2, Linux
Lua 2.515
LuaJIT 2.0.3, Linux
Lua 5.2.3, Linux
Python 2.633
PyPy 2.2.1 (Python 2.7.3), Linux
Python 2.7.6, Linux
Erlang 3.663
Erlang/OTP 17, emulator 6.0, HiPE [native, {hipe, [o3]}]
Byte code (BEAM), Linux
ALGOL 60 3.951 MARST 2.7, GCC 4.8.1 -O3, Linux
PL/I 5.667 Iron Spring PL/I 0.9.9b beta, Linux
Lisp 7.41
GNU Common Lisp 2.6.7, Compiled, Linux
GNU Common Lisp 2.6.7, Interpreted
Smalltalk 7.59 GNU Smalltalk 2.3.5, Linux
Ruby 7.832 Ruby 2.4.2p198, Linux
Forth 9.92 Gforth 0.7.0, Linux
Prolog 11.72
SWI-Prolog 7.6.0-rc2, Linux
GNU Prolog 1.4.4, Linux, (limited iterations)
COBOL 12.5
Micro Focus Visual COBOL 2010, Windows 7
Fixed decimal instead of computational-2
Algol 68 15.2 Algol 68 Genie 2.4.1 -O3, Linux
Perl 23.6 Perl v5.8.0, Linux
BASICA/GW-BASIC 53.42 Bas 2.4, Linux
QBasic 148.3 MS-DOS QBasic 1.1, Windows XP Console
Mathematica 391.6 Mathematica, Raspberry Pi 3, Raspbian