A little knowledge is dangerous

Paw Prints: Writings of the maddog
From time to time I advocate that every programmer learn at least one assembler language. Not that I would ever advocate writing in assembler language when a higher-level language would do, but because assembler allows you to see how the machine really works, and can help you understand other topics such as operating system architecture and compiler design. In fact, I advocate that programmers learn a little bit about digital logic and how digital gates such as AND and OR gates combine to create registers, memory and other computer structures.
Many years ago I started work for Aetna Life and Casualty as a young programmer.
One of the other programmers had written a program that ran very slowly on an IBM mainframe. Interestingly enough, when his program ran, all of the other programs on the system ran slower, and even all the programs on any system even remotely connected with that system ran slower.
Mystified, my boss asked me to look at his program and see if I could figure out what was wrong.
The first thing I found was that he had written part of the program in Fortran, part in Cobol, part in assembly language, part in PL/1 and part in SNOBOL. It was fortunate that I knew all of those languages, so I waded into the code to see if I could find what was wrong.
After a while I decided to run a profiler on the code, which would show me how much real time each of the modules was taking. I found that the assembly language program was taking the bulk of the processing time. Next I profiled just the assembly language program and found that one machine language instruction was taking about 99% of the wall clock time that the program was using.
I got out the Principals of Operations of the IBM 370 computer, which told how each assembly language instruction worked, and what it did, and found that the instruction that he was using was “read the clock”. Now this would seem like a harmless enough instruction, until you realized how “read the clock” was typically used. It was used to synchronize locks for controlling multiple CPUs. Therefore, before the clock value could be read, all of the I/O had to some to a halt and all of the caches had to be
flushed not only on your system, but every system that was communicating with that mainframe. Then, after the entire machine was quiescent, the clock would be read, assuring that there would be only one value of that clock in the whole system. Then everything started up again, with the caches refilling and the tape and disk drives starting to fill their caches.
And the program was executing that instruction for every tape record the program read, typically millions of them every night.
I asked the programmer why he was using that instruction in his program. “I wanted to find out what day my program was running,” he said. “What DAY?”, I asked. “If that was the goal, couldn't you have just read the value one time and stored it in a variable?”
“Then I would be wasting memory.” he said.
But I made him change his program and instead of taking ten hours a night to run, it ran in only fifteen minutes, and all the other programs executing simultaneously on every other CPU just kept running normally, not slowing down to a crawl when his program ran.
As I put away the profiling charts, I asked him, “Why did you write your program in so many different languages?”
“Oh,” he said, “I was taking a course which compared different languages, so I wrote in whatever language I was studying that week.”
I congratulated him for having a job for life, as nobody at Aetna other than he and I knew all of those languages.
Carpe Diem!
Comments
comments powered by DisqusIssue 220/2019
Buy this issue as a PDF
News
-
Linux Kernel Continues To Offer Mitigation for Spectre Mitigation
Kernel 4.19 has added another family of Spectre vulnerabilities to its list of mitigating the mitigation.
-
SpeakUp Trojan Targets Linux Servers
It’s exploiting a known vulnerability.
-
KDE Plasma 5.15 Beta Arrives
Major improvements to software management.
-
Canonical Announces Latest Ubuntu Core for IoT
Now offers 10 years of support.
-
GitHub Offers Free Private Repositories
Popular source code collaboration site makes a major change to feature set.
-
Linus Torvalds Welcomes 2019 with Linux 5.x
Better support for GPUs and CPUs.
-
Keep your edge with these powerful Linux administration tools:
Watching the Bad Guys with Cowrie
Trigger Admin Tasks with Systemd
Become a certified Linux Admin professional with the Linux Professional Institute LPIC-1 Systems Administrator certification.
-
Microsoft Gets an Open Source Web Browser
The company will use Google Chromium web browser as the foundation for its next browser.
-
Canonical Launches MicroK8s
Deploy Kubernetes in a few seconds.
-
A New Raspberry Pi Board
The new board packs everything that you get in Raspberry Pi 3B+ in a smaller package.
Assembly language
I couldn't agree more with your recommendation to learn a bit of assembly - by giving you a "glance under the hood" at how the underlying system actually works, the perspective gained can be invaluable.
When I was in high school back in the '70s, our school was hooked up to a regional timesharing system (SETS in Waltham, MA, if you remember them) that ran a DEC PDP-8/i, with a PDP-8/e handling the I/O. After familiarizing myself with the DEC BASIC that was the primary programming language available on the PDP-8s, I sent away to Maynard for the book on the PAL III assembly language that the PDP-8 family used, and wrote a few small programs in that.
I may not have done all that much with the language overall, but merely having been exposed to the concepts involved was all the reward I could have asked for, for the time invested. I cannot count how many times that added perspective has come in handy, on pretty much every platform with which I've worked over the years that followed.
Terrific article, and sage advice.