Computers are A Devolutionary Scam

TerryinMD · Jan 30, 2002

Way back when.... mid 70's or so. We use to write the initial code in Fortran or another favorite high level language. Our compilers typically had the option of converting the code to assembly. The resulting code was somewhat cumbersome, but we could then go in a fine tune the code in assembly language.

Another feature on those older compilers was an optimization level during compilation. When you cranked up the optimization level, the compiler would parse the resulting code to remove ineffecentcies and rearrange the code to take advantage of the machines built in capabilities. You could sometimes gain a 10% decrease in runtime.

Ahhhh..... the good ol' days.... coffee, cigarettes, late nights, and late night team sessions after work at the local watering hole celebrating a small victory. /w3tcompact/icons/wink.gif/w3tcompact/icons/smile.gif

Terry

MJB · Jan 30, 2002

That sure sounds familiar./w3tcompact/icons/smile.gif I am a firm believer in the practice of using the slowest machine you can find to test new software. If the code will run at an acceptable speed on the "old clunker" then it should run at a blazing speed on the newer machines. My current "test bed" computer is an old Pentium 133MHz with 32Mb RAM and a 1Gb hard drive. With WinNT 4.0 installed that old thing is a real slug. You get pretty good at optimizing code when it has to run on a machine like that./w3tcompact/icons/smile.gif

Chuck52 · Jan 30, 2002

You could sometimes gain a 10% decrease in runtime.

Or....you could get code that didn't do anything like what you wanted. I remember trying to use optimizing compilers on old FORTRAN66 programs. Often if the resulting code ran at all it gave really interesting calculations./w3tcompact/icons/grin.gif I recall the joy of getting ORTEP, the primordial molecular graphics program, written in FORTRAN66, running on my brand spanking new IBM AT and driving a Tektronix flatbed plotter in about 1984. In fact, I still have the PLOTT66 device driver package I used sitting on my bookshelf staring at me right now. Do I throw stuff out? Never!

Chuck

TerryinMD · Jan 30, 2002

Chuck,

A lot depended on the vendor. I worked for Control Data at the time and they prided themselves in their code effeciency. Off course, their compilers only ran on their computers!!

Terry

glennmac · Jan 30, 2002

their compilers only ran on their computers!!

Ah, yes, Terry, another good argument why programmer euthanasia should have started in the '50s...... Everyone's code only ran on their own hardware. Like having to have brand-specific film for every different camera, or brand-specific records for every different record player. It took the hardware cloning engineers like Gene Amdahl and the Japanese to undo this ridiculous state of affairs. ... Apple held out, resulting in their now miniscule market share, even though they have better hardware, software, ease-of-use, and style than IBM-Wintel.

TerryinMD · Jan 30, 2002

glennmac,

Back in the 50's, 60's, 70's and into the 80's you had no choice but to use CDC compilers on CDC hardware. IBM compilers on IBM hardware, etc.

This was not necessarily a bad thing. Most computer vendors targeted certain market segments. IBM,Burrows, UNIVAC did business. CDC and DEC did Engineering/Scientific.

What you have now are programmers that prototype their software on a NT system and then port it over to another OS. The compilers are generic and really don't lend themsevles to any particular hardware functionality. The magic of optimization lies with the developers. Methinks that they really don't know how or care. They just throw more hardware at the problem.

Let me pose a question. What software or hardware determines how fast a web page loads on your PC computer?

Is it memory?

Is it your hard drive?

Is it your channel speed?

Is it your network connection?

Is it your CPU speed?

Is it your browser?

Is it your vitual memory?

Is it the number of task concurrently loaded and running?

One of the above is the predominant determiner. And they all have a role to play in the web page load speed - real or apparent.

Terry

glennmac · Jan 30, 2002

What is this, a test???..........Computer whiz tries to toy with mere lawyer in public forum, eh!!!!......Ok, I'll guess: my network connection, especially the part of it that programmers are responsible for.

Knight9 · Jan 30, 2002

Harv,

If you like the colorful spicy look to a 'puter....check out these guys. <A target="_blank" HREF=http://www.alienware.com/main/main.asp>AlienWare</A> A few of their boxes are pretty colorful...and a few of them are VERY fast.

Kevin

ronjhall · Jan 30, 2002

Glenn
 .Computer whiz tries to toy with mere lawyer in public forum, eh!!!!......
This could get very interesting. /w3tcompact/icons/eyes.gif

TerryinMD · Jan 30, 2002

Good job glennmac. /w3tcompact/icons/king.gif I must confess, I was trolling.....

Astute observation!! Yes it was a quiz. You know a lot more than you think (or me second guessing you). However, what I was trying to emphasize was that there are many factors in a computers performance. Your computer works as fast as your slowest link. Most of the time it's waiting for something to do. All the hardware and all of the new software in the world will not make a computer fast!! /w3tcompact/icons/crazy.gif Also, buying a new OS and computer is sometimes very frustrating. We have all been there and done that.... /w3tcompact/icons/eyes.gif

I'm no computer whiz (would like to whiz on a computer now and then /w3tcompact/icons/shocked.gif). Just an older programmer who is amazed at all of the wonderful tools and gee whiz hardware available to the average Joe and the programming turks who develop these mind bending apparations for us.

Euthanizing all of the programmers is not a bad idea at times. I would venture to say that that exact thought has passed through many a business executives mind. Hmmmm... in fact, I remember wanting to off a few programmers when I WAS a programmer. /w3tcompact/icons/shocked.gif Why they let some of these turkeys out of the basement of the science building is beyond me!! Give them more twinkies and jolt!!

This is all interesting stuff. Many viewpoints from people with varying degrees of Geekness.

Terry

glennmac · Jan 30, 2002

I am profoundly psychologically disturbed (no pause) by this huggy-smoochy agreement-to-agree between Buck and Harv. They seem to have smugly stipulated that there is a socially acceptable difference between (1) a programmer who produces efficient code and (2) an efficient programmer.........Let me translate this devolutionary horror for those of you who know even less than I do about their geektalk........Assume you have a brain surgeon in 1970, Dr. Capillary, who does all his surgery with a small scalpel. He takes pride in his ability to precisely cut out the tumor without damaging the surrounding tissue. He spends hours practicing how to avoid the unnecessary cutting of adjacent capillaries so as to mininimize later headaches for his patient. It takes him 3 hours to do an average brain surgery.......Flash forward to Dr. Niagara in 2002. He uses a Walmart chainsaw to do brain surgery. It takes him 30 minutes to do an average brain surgery. His patients have lots of headaches, or worse..... According to Generally Accepted Programmer Theology, as evidenced by the Buck-Harv Concordat, Dr. Niagara is recognized and promoted as the more efficient and productive brain surgeon (programmer)........There you have it, ladies and gentlemen of the juryrig, the smoking gun of devolution......QED

Harv · Jan 30, 2002

There you have it, ladies and gentlemen of the juryrig, the smoking gun of devolution

Careful, Glenn. I'm getting that huggy-smoochy feeling all over again. /w3tcompact/icons/laugh.gif

brewerbob · Jan 31, 2002

Which brings a joke to mind. How many programmers does it take to install a light bulb??? Answer: None, it's a hardware problem.
Bob

GlueGuy · Jan 31, 2002

Our compilers typically had the option of converting the code to assembly

Terry,

They still do, only now they're on steroids (or at least the compilers that we use are). We have so many knobs and dials to use when we compile things it's almost ridiculous. It's true that "sometimes" you can optimize yourself into a black hole, but "most" of the time, you get very good results.

We usually have optimization set to compromise between size and speed. This works better than 99.9% of the time. If things seem slow, we will take the performance-sensitive bits and dial them down, or analyze the assembler to see what we can do to step it up.

Heck, when I started in the biz, I used to do a bunch of stuff one step down from assembler; machine code. I could fat-finger in a routine through the console faster than most people could type.

The more things change, the more they stay the same....

SimS · Jan 31, 2002

BB:

Your joke reminded me of another programmer joke.

How many Microsoft programmers does it take to change a light bulb?

None. They just change the standard to darkness!

Sim

TerryinMD · Feb 1, 2002

Glueguy,

I'm far removed from the actual coding now. /w3tcompact/icons/smile.gif/w3tcompact/icons/smile.gif/w3tcompact/icons/smile.gif

What platform are you programming on? I never hear of our guys tweaking their code with any compiler switches. Like I previously said, all they ask for is bigger, better, faster.... /w3tcompact/icons/crazy.gif The only ones I see trying to improve upon performance are the database guys. Not so much in code optimization, but in table sizes and DB tuning.

I understand about what your saying concerning fudging around with machine code. I looked over some code that did the same thing. I helped develop new display screens for the system console and had to understand how the console driver worked. We had 4096 bytes to work in. So, that meant that we had to use overlays to drive the console. One particular overlay had an byte left open (set to zero) preceded by a jump instruction. Sometimes, you would jump. However, sometimes the jump instruction was replaced by a different instruction in machine code to perform a completely different task. I called it self-abusive coding. The first time you hand checked the code, you couldn't believe your eyes (documentation - ha!!). You expected to jump to a previous address and guess what, the instruction was changed!! Oh, those devious assembly programmers.....

Terry

MikePA · Feb 1, 2002

Classic way to patch code. Replace an existing instruction with a branch. Branch to the code, do various things and branch back. Although I've never dealt with self-modifying code. Yuck.

Harv · Feb 1, 2002

never dealt with self-modifying code

Brings to mind an incident I had with a young "hot-shot" programmer I used to work with. I was project leader, all code had been submitted as "fully debugged and tested" (we know there's not such thing, but you get the idea) and was scheduled for the first production run on Monday. So there I was, spending my weekend trying to figure out why the prototype was intermittently crashing.

I eventually figured out that Mr. HotShot ("I can write smaller, faster code than anybody") had written several self-modifying subroutines just to make his code smaller than everybody else's. To be fair, his stuff was very small and ran pretty fast. Too bad he wasn't around to test it that weekend when I burned the whole thing into PROM. /w3tcompact/icons/laugh.gif /w3tcompact/icons/tongue.gif

GlueGuy · Feb 1, 2002

What platform are you programming on?

Terry,

We do this on several platforms: Compaq, HP, Sun; and in several languages, but mostly C, C++, and Java.

GlueGuy · Feb 1, 2002

All of the early Tandem systems had a CPU architecture that separated "code space" from "data space". So the stack and all data structures by definition went into the data space. Only the memory manager was allowed to write into code space, which was under kernel control.

It didn't eliminate bugs, but the self-modifying code variety were non-existent.