Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!purdue!i.cc.purdue.edu!k.cc.purdue.edu!l.cc.purdue.edu!cik
From: cik@l.cc.purdue.edu (Herman Rubin)
Newsgroups: comp.lang.c
Subject: Re: Array indexing vs. pointers...
Summary: The same applies to understanding the machine
Message-ID: <957@l.cc.purdue.edu>
Date: 30 Sep 88 11:50:28 GMT
References: <8809191521.AA17824@ucbvax.Berkeley.EDU> <68995@sun.uucp> <836@proxftl.UUCP>
Organization: Purdue University Statistics Department
Lines: 29

In article <836@proxftl.UUCP>, bill@proxftl.UUCP (T. William Wells) writes:
> In article <607@ardent.UUCP> mec@ardent.UUCP (Michael Chastain) writes:
> : Good grief.  Say NO to low-level performance tweaking.
> 
> Good grief.  Say NO to understanding the language well enough
> that "low-level performance tweaking" is natural to the
> programmer.  Grrr.  Note that the quotes here are because I
> disagree that the programming practices being condemned
> constitute "low-level performance tweaking".

<	Good grief.  Say NO to understanding the MACHINE well enough
	that "low-level performance tweaking" is natural to the
	programmer.  Grrr.  Note that the quotes here are because I
	disagree that the programming practices being condemned
	constitute "low-level performance tweaking".                       >

I frequently have less difficulty thinking in terms of the machine structure
than the arbitrary obfuscated language constructs.  The gains are frequently
greater at this level.  If one thinks this way, it is not at all difficult to
find situations in which factors of 10 arise.

If I have so little difficulty in understanding machine operations for many
different machines, why should it be considered so overwhelmingly difficult
for others to be able to read and maintain code written with those
considerations in mind?
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)