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
-
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.
-
ZorinOS 17.1 Released, Includes Improved Windows App Support
If you need or desire to run Windows applications on Linux, there's one distribution intent on making that easier for you and its new release further improves that feature.
-
Linux Market Share Surpasses 4% for the First Time
Look out Windows and macOS, Linux is on the rise and has even topped ChromeOS to become the fourth most widely used OS around the globe.
-
KDE’s Plasma 6 Officially Available
KDE’s Plasma 6.0 "Megarelease" has happened, and it's brimming with new features, polish, and performance.
-
Latest Version of Tails Unleashed
Tails 6.0 is based on Debian 12 and includes GNOME 43.
-
KDE Announces New Slimbook V with Plenty of Power and KDE’s Plasma 6
If you're a fan of KDE Plasma, you'll be thrilled to hear they've announced a new Slimbook with an AMD CPU and the latest version of KDE Plasma desktop.
-
Monthly Sponsorship Includes Early Access to elementary OS 8
If you want to get a glimpse of what's in the pipeline for elementary OS 8, just set up a monthly sponsorship to help fund its continued existence.
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.