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 DisqusSubscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
News
-
TUXEDO Computers Unveils Linux Laptop Featuring AMD Ryzen CPU
This latest release is the first laptop to include the new CPU from Ryzen and Linux preinstalled.
-
XZ Gets the All-Clear
The back door xz vulnerability has been officially reverted for Fedora 40 and versions 38 and 39 were never affected.
-
Canonical Collaborates with Qualcomm on New Venture
This new joint effort is geared toward bringing Ubuntu and Ubuntu Core to Qualcomm-powered devices.
-
Kodi 21.0 Open-Source Entertainment Hub Released
After a year of development, the award-winning Kodi cross-platform, media center software is now available with many new additions and improvements.
-
Linux Usage Increases in Two Key Areas
If market share is your thing, you'll be happy to know that Linux is on the rise in two areas that, if they keep climbing, could have serious meaning for Linux's future.
-
Vulnerability Discovered in xz Libraries
An urgent alert for Fedora 40 has been posted and users should pay attention.
-
Canonical Bumps LTS Support to 12 years
If you're worried that your Ubuntu LTS release won't be supported long enough to last, Canonical has a surprise for you in the form of 12 years of security coverage.
-
Fedora 40 Beta Released Soon
With the official release of Fedora 40 coming in April, it's almost time to download the beta and see what's new.
-
New Pentesting Distribution to Compete with Kali Linux
SnoopGod is now available for your testing needs
-
Juno Computers Launches Another Linux Laptop
If you're looking for a powerhouse laptop that runs Ubuntu, the Juno Computers Neptune 17 v6 should be on your radar.
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.