From: zrepachol@cc.curtin.edu.au (Paul Repacholi)
Subject: Re: The need for an assembler (was: Favorite CPU)
Organization: Curtin University of Technology
Date: Sat, 15 Aug 1992 18:14:58 GMT

In article <1992Aug13.184835.1@cc.curtin.edu.au>, zcookbruc@cc.curtin.edu.au writes:
> In article <1992Aug12.160850.13091@sctc.com>, smith@sctc.com (Rick Smith) writes:
>> peter@ferranti.com (Peter da Silva) responds to Charles Lasner's
...
> 2) High-level language programmers who don't understand what their
> languge is doing in my experiance create the most in-efficient
> high-level code I have ever come accross. A friend of mine told me
> about a programmer doing a report run through RDB that took 30 Minutes.
> when the code was looked at and an understanding of what was happening
> was achieved, that report was reduced to 30 seconds (Please correct
> any mi-information here reptile).

Argh, why did I get draged into this... on a flakey modem line too...
The problem was one of people not understanding the SYSTEM, or the tools
they were using. All programing was done on a vax cluster in PLI. This
had several intersting effects. The standard set of definitions included
TRUE=1 and FALSE=0, stored in a *BYTE*. ( IBMs don't have bits... ) Plus
a hacked on PLI to RMS package that 'fixed' problems with PLI v1.

The program in question was very simple, read record, if either field x or y
was non zero, save for 2 reports the we print. This was coded up 'by the book'
and took 17 cpu min to run on the test file ( 200 records ) on a 750. I got 
him to flush ALL the PLIRMS  stuff, and read the syslib, PLI, and linker
manuals. He then re-did the program to read the file and insert non-zero
records into 2 trees, at the end, doing 2 tree walks to print the results. It
didn't work. He couldn't use the test files cause 'someone' was rewriting them
with exclusive access locking, so he ran it on a copy of the production data,
about 6K records. The program bombed after 10 secs or so. He came back to me
for more help. Run it again, same result. "What's in the file?" "Don't know.
It failed so I didn't bother to look" After we printed 2 perfect reports,
he went away much wiser...

It was not the programers fault. He had NEVER seen the VAX syslib manuals,
or been told that they existed! The PLIRMS crud was *REALY* bad. I came back
from hols one day and logged in... After getting a coffee, saying Hi to various
people, and still not being logged in I thought this was a bit much, even
for a 750. So I asked around. " Oh, it hasn't worked for a couple of days..."
Well it transpired that someone had changed their terminal setup a little,
probably to change the default colours or simular, and had trashed the test
for interactive use on the 'set terminal/inquire'. This had sent DCL into a
hard CPU loop on Thursday, and it was now Monday... 4 CPU days for one HLL
statement!!  :-)

Everone piling onto the 3 remaining 750s pulled another nigger out of the
wood pile. PLIRMS did a ferocious amount of Enques/deques. The extra load
on the systems slowed thing down a *LITTLE* more. The deadlock timer on a ENQ
request timed out, the cluster disapeared up it fundement as it scurried through
the entire lock data-base looking for the deadlock. None found, the problem
was que length, not deadlocks. Returned to a volley of expired ENQ timers!!
After about 10-15 minutes of this, thing would go back to 'normal' for a while.
I 'fixed' it by changing the deadlock timeout to 1000 sec! The 'correct' fix
of getting rid of PLIRMS was not possible. Despite the fact that the problem
it was written to work around had been fixed!!

> 
> 3) Very few high-level languages (C in particular) are intrinsicly
> portible. Any portible C program is achieved through programmer
> disipline, with the programmer knowing what will break.
> 
Would some-one who has a copy, please post the "Hackmem" item on the portable
non-decreasing funtcion of X.

> 4) All my C code uses system interface libraries written in assembler
> and taylored to the system I'm running the code on. This gets rid of
> stupid conditions that don't matter on one system, and make the
> world of difference on others.
> 
> Sorry I agree with Peter - If you don't know your assembler you
> don't know what's going on ! 
> 
If you don't know your SYSTEM, you are on thin ice... THis includes the machine,
the OS, the compiler(s), and the aplication. The number of times I see a post
of "... I need to foork my process on VMS, how do I do it..." is a damming
indictment of the education system IMHO.

~Paul

Newsgroups: alt.folklore.computers