DataGeneral v HewlettPackard
Functional verses Amazing
In the early 1970's, I worked on a few DG computers. Everything worked, as did the Altair, the Prime, the AT&T Bs, and the Basic4. However, they all suffered from simplicity. I wrote a disk handling system for the DG; it used Diablo 12-inch floppies. The Basic4 had a file system where names were two characters; Ira Baxter and I knew the programming team at Basic4. Ira offered for a low fee to convert the system to employ directories and 8 character file names. Basic4 claimed they had the project in hand; we had a running prototype in the SD systems by Ira. Basic4 disappeared within two years.
The CPU of the DG was faster than the CPU of the HP. And it had, as configured, more memory.
The DG initiated programs faster than the HP. One program reading from disk 1 was faster than the HP for the first two minutes or so. After that, on jobs of an hour or more, the HP would catch up and pass the DG. The HP might finish in 23 minutes, whereas the DG exceeded an hour. Nothing else about the DG was better.
In comparisons of four concurrent programs with disk intensive operations, by the end of the first minute, the HP was faster.
The HP backplane could handle sixteen concurrent data flows; DG basically one.
The HP disk controllers had caching and intelligence; DG borrowed from main memory and from the CPU to cache.
The HP disk controller during each clock cycle could read or write every other disk on the cable. Given six disks, three were idle and three active.
The DG was old fashioned daisy-chain. Only one disk at a time could read or write. Every other disk waited for that one before they could read or write.
On the DG, five clock cycles went into sending a message to the fifth disc on a controller. Talk about slower.
Thus, throughput on the HP was much faster.
Disk Throughput
With four disks on a controller cable, the HP could read or write 2 on every cycle while two sat idle.
With four disks on a daisy chain, the DG waited one cycle for the first disk, two cycles for the second, etc.
While the DG was waiting, no other data flow occurred.
In 100 cycles, the HP could do a combination of 200 reads and writes, such as 170 reads and 30 writes.
In 100 cycles, the DG could do on average (2.5 cycles per read or write) about 40 reads or writes in total.
Various read-after-writes slowed the DG down even more.
The HP had on disk caching, which could make the HP even faster.
Re-entrant Programs
The HP compilers yielded programs that did not change during execution. Within the object code, the iterators and the local variables were referenced as being in the user's stack and not in the program. When a user started running or resuming a program, nothing about the program changed, hence the term re-entrant. Consequently, an HP computer could have one database program serving up to 127 users. The HP never swapped the program out of memory; instead, after the last user left the program, the HP would simply drop the pointer to the program in memory.
The DG, on the other hand, required one copy per user. Each copy went in and out of memory as the user gained or lost CPU allocation. The disks went wild with swapping; the swapping took cycles from production reads and writes.
During the port of Ingres to the DG, we copied the HP data base techniques. We installed the HP locking strategy and made it comply with the standard Ingress controls.
Why me?
The vendor for the software for the project was Scientific Data Systems, a good company with good programmers. The project manager said that converting Ingres to the DG was out of scope for the project. I agreed. The SDS crew had expected Oracle or HP Image. So, an English guy named John and I did the conversion. The SDS guys enjoyed that our implementation acted like HP Image; no re-training or no program mods.
The CPU of the DG was faster than the CPU of the HP. And it had, as configured, more memory.
The DG initiated programs faster than the HP. One program reading from disk 1 was faster than the HP for the first two minutes or so. After that, on jobs of an hour or more, the HP would catch up and pass the DG. The HP might finish in 23 minutes, whereas the DG exceeded an hour. Nothing else about the DG was better.
In comparisons of four concurrent programs with disk intensive operations, by the end of the first minute, the HP was faster.
The HP backplane could handle sixteen concurrent data flows; DG basically one.
The HP disk controllers had caching and intelligence; DG borrowed from main memory and from the CPU to cache.
The HP disk controller during each clock cycle could read or write every other disk on the cable. Given six disks, three were idle and three active.
The DG was old fashioned daisy-chain. Only one disk at a time could read or write. Every other disk waited for that one before they could read or write.
On the DG, five clock cycles went into sending a message to the fifth disc on a controller. Talk about slower.
Thus, throughput on the HP was much faster.
Disk Throughput
With four disks on a controller cable, the HP could read or write 2 on every cycle while two sat idle.
With four disks on a daisy chain, the DG waited one cycle for the first disk, two cycles for the second, etc.
While the DG was waiting, no other data flow occurred.
In 100 cycles, the HP could do a combination of 200 reads and writes, such as 170 reads and 30 writes.
In 100 cycles, the DG could do on average (2.5 cycles per read or write) about 40 reads or writes in total.
Various read-after-writes slowed the DG down even more.
The HP had on disk caching, which could make the HP even faster.
Re-entrant Programs
The HP compilers yielded programs that did not change during execution. Within the object code, the iterators and the local variables were referenced as being in the user's stack and not in the program. When a user started running or resuming a program, nothing about the program changed, hence the term re-entrant. Consequently, an HP computer could have one database program serving up to 127 users. The HP never swapped the program out of memory; instead, after the last user left the program, the HP would simply drop the pointer to the program in memory.
The DG, on the other hand, required one copy per user. Each copy went in and out of memory as the user gained or lost CPU allocation. The disks went wild with swapping; the swapping took cycles from production reads and writes.
During the port of Ingres to the DG, we copied the HP data base techniques. We installed the HP locking strategy and made it comply with the standard Ingress controls.
Why me?
The vendor for the software for the project was Scientific Data Systems, a good company with good programmers. The project manager said that converting Ingres to the DG was out of scope for the project. I agreed. The SDS crew had expected Oracle or HP Image. So, an English guy named John and I did the conversion. The SDS guys enjoyed that our implementation acted like HP Image; no re-training or no program mods.