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
-
Fedora 41 Released with New Features
If you're a Fedora fan or just looking for a Linux distribution to help you migrate from Windows, Fedora 41 might be just the ticket.
-
AlmaLinux OS Kitten 10 Gives Power Users a Sneak Preview
If you're looking to kick the tires of AlmaLinux's upstream version, the developers have a purrfect solution.
-
Gnome 47.1 Released with a Few Fixes
The latest release of the Gnome desktop is all about fixing a few nagging issues and not about bringing new features into the mix.
-
System76 Unveils an Ampere-Powered Thelio Desktop
If you're looking for a new desktop system for developing autonomous driving and software-defined vehicle solutions. System76 has you covered.
-
VirtualBox 7.1.4 Includes Initial Support for Linux kernel 6.12
The latest version of VirtualBox has arrived and it not only adds initial support for kernel 6.12 but another feature that will make using the virtual machine tool much easier.
-
New Slimbook EVO with Raw AMD Ryzen Power
If you're looking for serious power in a 14" ultrabook that is powered by Linux, Slimbook has just the thing for you.
-
The Gnome Foundation Struggling to Stay Afloat
The foundation behind the Gnome desktop environment is having to go through some serious belt-tightening due to continued financial problems.
-
Thousands of Linux Servers Infected with Stealth Malware Since 2021
Perfctl is capable of remaining undetected, which makes it dangerous and hard to mitigate.
-
Halcyon Creates Anti-Ransomware Protection for Linux
As more Linux systems are targeted by ransomware, Halcyon is stepping up its protection.
-
Valve and Arch Linux Announce Collaboration
Valve and Arch have come together for two projects that will have a serious impact on the Linux distribution.
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.