As you point out, things have evolved. While people writing kernel code might still try to bum instructions, "efficient code" now has to do with reuse and maintenance. Code that is easy to read, well commented, and properly modularized is "efficient" in the current environment.Writing fast or efficient code means using the minimum number of instructions required to perform a task. Each instruction is assigned a fixed number of clock cycles to perform its function. You have to know the instruction set of a machine intimately in order to do this. At a slightly higher level, when using a programming language lice C, you need to know the internals of how the compiler generates machine instructions in order to evaluate alternative coding strategies.
A long time ago this was a vital exercise at a time when machine time cost $1000.00/hour and programmers worked for $2.25 per hour. Now that you can buy a more powerful computer than the ones we programmed in 1962 for $1000.00 total, and a fair to middling programmer makes $75.00/hour (150,000.00/yr) we are content to let the cheap machine waste it's time so you don't have to anymore.
Excellent point, which I alluded to in mentioning the cost of a programmer. There is no worse feeling among management types when a good programmer refuses to touch a piece of legacy software out of fear for what he might find. OTOH there are programmers who will milk that situation for all it is worth. I have done both.As you point out, things have evolved. While people writing kernel code might still try to bum instructions, "efficient code" now has to do with reuse and maintenance. Code that is easy to read, well commented, and properly modularized is "efficient" in the current environment.
I program is assembly and use pre-proven routines in a library.What does it mean to write efficient and fast code?
How do you write fast and efficient code?
And if I remember correctly, the method used to draw vector lines was based on Bresenham's algorithm... which is computationally the most efficient way to draw a line to this day.As already mentioned, there is a trade off to be made between efficiency of the program vs efficiency of the programmer.
When considering the efficiency of the program, one has to look at the most inner loop of highly iterative processes. This is where the CPU will spend most of its time.
The inner loop of computer graphics programs is where a lot of time is spent, e.g. draw a line from (x1, y1) to (x2, y2).
The primitive graphics functions on the original Apple Macintosh computer was created by Bill Atkinson, called QuickDraw. This was derived from an earlier version called LisaGraf on the Lisa computer. Bill wrote the functions in Pascal. Then, in order to squeeze the maximum efficiency of the program, the most fundamental core was hand written in 68000 assembler.
I worked with a Calcomp plotter when I was an undergraduate and working in the time-sharing business. I'm familiar with the algorithm, but not with the name or the origin story. Thanks very much for that vignette.And if I remember correctly, the method used to draw vector lines was based on Bresenham's algorithm... which is computationally the most efficient way to draw a line to this day.
Here's another fun fact: Mr Bresenham also designed the most efficient algorithm to draw circles and arcs.I worked with a Calcomp plotter when I was an undergraduate and working in the time-sharing business. I'm familiar with the algorithm, but not with the name or the origin story. Thanks very much for that vignette.