Re: 6502 illegal opcodes questions

["mdj" <mdj.mdj@gmail.com>]

Michael J. Mahon wrote:

> > Not necessarily. A common design fault in a C program is a counted
> > iteration over a buffer where the loop end condition was faulty
> > (someone picked <= instead of <, etc)
> >
> > Often this results in a program appearing to run fine, until some other
> > loop relying on null termination fails to stop, overwriting data and
> > code in the process.
>
> Um, so people should not be able to get the termination
> condition for a loop wrong?  It's going to be hard to change all
> those programmers' diapers, don't you think?  ;-)

I don't believe you should be able to get the termination condition
wrong, when it happens to be related the bounds of a data collection.
If only strings where the only area where this problem existed. But
then, it's been solved, the overhead is small, I can't understand the
resistance to it.

Of course, the problem is much harder when we're talking computational
loops :-)

> BTW, I independently invented FOR i OVER <subrange type> DO ... OD
> prior to ADA, so I know there are ways to simplify things--I just don't
> think it's likely that anyone will be able to eliminate the possibility
> of errors!

these days Java also has the rather cute for(reference:collection) {}
statement as well which is very nice, as it lacks the ability to handle
subtypes (grumble)

> Overwriting data is a classic problem, and is usually pretty easily
> found if it's literally a bad conditional or an off-by-1 error, since
> the error is always misbehaving.
>
> (Overwriting code is another matter, but code pages should be protected
> from self-modification except in unusual cases.)

A big problem is how to avoid execution of code within data pages, when
its been put there by a malicious perpeprator exploiting a flaw. Code
overwrite is easy, lock the codepages against writes. Can't easily lock
the data pages though :-)

> I didn't say anything about "pointer arithmetic" (though it can be
> *very* useful to a storage allocator ;-).  I just want unrestricted
> pointers so I can construct arbitrary data structures, and have the
> ability to re-thread the pointers as I wish.

This is my main gripe with pointers - you don't actually need them to
have there full 'power' in order to get the full use from them.
reference style pointers are all you need, and I'm happy to keep these,
they're easily defined in a portable way.

> >>>In short, my motivation for removing such features, is one of
> >>>pragmatism, not ideology. When engaging in projects for personal use, I
> >>>prefer 'unconstrained' tools as well.
> >>
> >>OK, so you just want to keep guns away from children...  ;-)
> >>
> >>My preferred approach is not to have children in the "army" in the first
> >>place.  ;-)
> >
> >
> > Unfortunately though, this approach doesn't work in practice. The
> > industry is full of children :-)
>
> Then we are accountable for the consequences.

We, being the people who pay time and time again for the mistakes made
by either their predecessors in a code maintenence role, or as
customers of shoddy software...

Actual accountability stopping where it should is something that almost
never happens in practice.

> I see where you're coming from, and I wish you luck in getting the
> guns back from the children, particularly those who've developed a
> fondness for shooting.  ;-)
>
> You should take some solace from the fact that probably the most
> frequently used "higher level language" is Excel, and it is completely
> pointer safe.  ;-)  The only mistakes you can make in Excel are the
> ones that will bankrupt your company!  (Get my point?)

No it isn't! Excel spreadsheets routinely refer to a cell that hasn't
been defined. This brings a whole new meaning to segmentation
violation. Don't get me started about the number of "databases" that
exist in spreadsheets :-)

There's no restriction whatsoever in Excel code over what part of the
"address space" you reference in an expression. You can even reference
a sheet that doesn't exist (a genuine "bus error" :) )

> >>It is well known that the only long-term effective way of removing old
> >>methods from the playing field is through generational succession.  ;-)
> >>
> >>Actually, for it to be maximally effective, though, the process of
> >>cultural transmission of (mistaken) ideas must also be weakened.
> >
> >
> > This is what I'm doing in this thread ;-) Misinformation spread over
> > communication mediums like this one is a major source of said
> > transmission.
>
> Hmmm.  I expect that a letter to the editor of any trade rag would
> reach a much larger audience...

I think they gave up publishing such things years ago, unfortunately.

> >>>>A great designer can do great things in any language, but it will
> >>>>be much harder to do all the great things he can do in just one
> >>>>language.  Imagination will not be contained.
> >>>
> >>>
> >>>It doesn't need to be. I agree with you completely on this point. I
> >>>challenge anyone to come up with a piece of code that relies on this
> >>>freedom that cannot be expressed another way.
> >>
> >>Turing equivalence argues that there are no such examples--but there
> >>are many examples of people's imaginations being truncated by the lack
> >>of a concrete machine execution model.  (I cited two.)
> >
> >
> > Then the issue is a lack of understanding of the execution models used
> > by the newer tools, as obviously they DO have concrete execution
> > models.
>
> Yes, that seems to be a problem with "high level languages"--they are
> falsely advertised as "freeing their users from concern over petty
> details--like how much memory is used, how many processor cycles,
> and how many cache misses."  As a result, tools to determine these
> critical numbers are hard to find and harder to use.
>
> Now *there's* a common belief that needs to be stamped out!

Agreed. It's right up there with the belief that a tool that leaves
them up to the programmer to decide for themselves is a solution ;-)

> I've generally been a bottom-up thinker (which I guess is like being
> a geometer vs. an arithmetician ;-), so I've often approached questions
> of performance with a blunt instrument.

I'm fairly similar in this regard - many it seems approach it
guesswork; look over source code, spot 'slow' bit, fix it, get 2% gain,
repeat ;-)

> For example, after implementing a compiler and getting it mostly
> working, I became curious about whether it had any significant hot
> spots that I could squash to get significant performance improvements.
>
> I went to the console of the (mainframe) machine as it was compiling
> itself, and manually hit the stop key a couple of dozen times, each
> time writing down the program counter address.
>
> If a part of the program was using more than 25% of the time, I should
> have seen its PC value represented in my sample about 6 times, plus or
> minus the square root of 6, or between 4 and 8 times.  If no range
> of addresses was sampled that often, then there was no procedure in
> the compiler taking at least 25% of the time.
>
> I found a spot that was taking about a third of the time, and another
> taking about a fifth, so I looked at them and sped them up by about
> a factor of 4 or 5 each.
>
> Less than an hour after taking my PC samples, the compiler was running
> almost twice as fast.
>
> Not rocket science, but thinking across several levels of abstraction--
> and all I needed was a piece of paper, a pencil, and a load map for the
> compiler!
>
> (BTW, this method can be applied to *many* performance issues, but it
> helped that wall clock time was identical to process time in this case.)

Most development environments today provide profiling tools that make
it simple to spot such hotspots. The tricky areas now are usually where
programs are I/O bound.

> I can buy that--just as long as someone introduces the kiddies to the
> power tools at some point in their development.  In my experience,
> they can get old and gray and never see a real power tool...so where
> are the great programmers of the future going to be raised?

In their own houses, more than likely. Most great programmers end up
learning most of what they know outside of structured learning
environments.  I don't think we need worry about them not discovering
the power tools, they're already inventing their own :-)

> >>I'm also a big believer in "anihilating the problem" rather than solving
> >>it a piece at a time.  But surely the best we can hope for from the
> >>tools you are espousing is a reduction in the number of problems--not
> >>the *elimination* of problems.  The argument is only quantitative, not
> >>qualitative.
> >
> >
> > Absolutely. I'm not naive enough to believe it'll solve all problems.
> > Hopefully though, it'll mitigate enough of the old ones to allow us
> > more time to start exploring new ones. It's an evolutionary model of
> > course.
>
> I sure hope so.  But, again, experience indicates that every time we
> take away 50% of someone's freedom to make mistakes, we also take away
> *at least* 50% of their freedom to learn something wonderful.

I'd agree, if I was convinced the ideas I proposed actually cause any
such loss of freedom.

> Remember, good judgement comes from experience, and experience comes
> from poor judgement.

And the tools we use, just like the tool users, should evolve to
include this experience.

> I'd rather see people *learn* to avoid mistakes by making them, rather
> than have them "protected" from mistakes and never learning about the
> law of gravity.
>
> BTW, I don't care what languages people use once they've learned what's
> what.  They will choose beautiful languates when they are appropriate
> and dangerous languages when *they* are appropriate.  And if they
> *haven't* learned this lesson, why should you trust them to write
> code at all?
>
> See, the world doesn't need millions of coders--it needs thousands
> of *great* programmers.
>
> There's a *reason* that we scatter broken glass around in there--but
> some clown is always coming around selling thick rubber shoes, so
> it's hard to keep the bozos out.  ;-)

Come now, the broken glass was scattered by those who didn't know any
better, not to provide an entry barrier :-)

> Ever get the feeling that you may be solving a much-needed problem?  ;-)

Ever get sick of tiptoeing through the broken glass, moving appreciably
slower and occasionally cutting you feet? Battlescars make for nice war
stories, I suppose, but really, do we need to have so many? :-)

> What would happen if we provided simple programs that would allow
> people to design bridges without an engineering degree?  I know that
> I'd start avoiding bridges!

Hmm, hasn't this actually been happening for years? ;-)

> <rant off>  ;-)
>
> >>>>>>It is certainly possible to write non-portable code in any sufficiently
> >>>>>>complex system, simply by exploiting some irregular behavior--and there
> >>>>>>will *always* be some irregular behavior to be exploited.  ;-)
> >>>>>
> >>>>>
> >>>>>The hardest part of the problem, and one yet unsolved by language
> >>>>>design.
> >>>>
> >>>>Not only unsolved, but unsolvable in any finite system.
> >>>
> >>>
> >>>While you're completely right, this doesn't provide justification for
> >>>not minimising the problem when it's easy to do so. Failure to mitigate
> >>>this as complexity grows will send you flying into a glass ceiling that
> >>>could have been considerably higher.
> >>
> >>We agree about the need for abstraction.  Perhaps our disagreement is
> >>just about whether the "floor" of our abstraction should be opaque or
> >>transparent.
> >>
> >>For most people, opaque floors are necessary if tall structures are to
> >>be built--it avoids vertigo when looking down.  ;-)  But for great
> >>designers, floors should be transparent, so that they can see the
> >>lower-level implications of everything done at a higher level of
> >>abstraction.  (It's their discipline that allows them to avoid
> >>abstraction vertigo, and enables them to see the possiblity and
> >>utility of new underlying structures.)
> >
> >
> > No no no! A great designer doesn't require transparent floors either!
> > He's read and comprehended the blueprints, and can tell you about the
> > structure with his eyes shut :-)
>
> But what he needs to see is *not* what his models tell him is happening
> below, but what is *actually* happening--that's where all the learning
> happens!  That's how he grows from merely great to mega-great!
>
> If you think you understand the behavior of a complex system, then you
> are woefully misinformed.  It is time to meditate on bubbles blowing
> in the wind, or the fractal nature of network traffic...

This is why I advocate tools and languages that allow you observe
complexity. Nobody can understand complex systems in their entirety.

> >>  >>I only note that there are successful patterns which are *not* made
> >>
> >>>>of OO concepts, as well.  Perhaps some of the most useful ones...
> >>>
> >>>
> >>>Indeed many of the patterns are also applicable to non-OO designs. OO
> >>>at the end of the day is just another level of abstraction above
> >>>structures and functions, allowing convenient paring of related
> >>>structures and functions, resulting in more manageable code. Going back
> >>>to languages that lack it is very 'constraining' :-)
> >>
> >>I have always maintained this pairing, even in assembly language.
> >>
> >>It's nice when a language supports something you know is a good idea,
> >>but you can generally do it even without explicit support.
> >
> >
> > True. It's very hard though when you drop down 2 or 3 levels of
> > abstraction to recreate them well, as you're ultimately implementing
> > poor-mans tools as you do so.
>
> I have not often found it so.
>
> Most often, I find that I am exploiting a pattern of behavior that
> spans multiple levels of abstraction, and often couples code and data
> that are surprisingly distant in conceptual space.
>
> In most cases like this, no one looking at the high level code would
> ever have imagined that there was any such relationship to be exploited.
>
> The world of behavior is much stranger and more wonderful than our
> abstract models suggest--that's what makes them "abstract".
>
> There is enlightenment here, for those who would find it.

The interesting elements of behavior only manifest when it's possible
to observe them, and observations of complex system behaviors are
difficult with current toolsets.

> >>The only truly annoying thing is when a language obstructs you from
> >>doing something that should be done, while making inferior approaches
> >>easier.  (Block structure is a nice local concept, but not enough for
> >>a robust global structure.)
> >>
> >>
> >>>I found the hype around OO that flew about over the last 15 years to be
> >>>quite ridiculous. Had it been sold for what it actually is, rate of
> >>>adoption would be far higher.
> >>
> >>A practical problem, though, is that any team that newly adopts an
> >>OO approach for a project *will* throw out their false start sometime
> >>between 6 and 12 months down the road, and restart the project.
> >>
> >>This is a good thing, since it is evidence of real learning, but it
> >>strikes fear into the hearts of schedule-driven management.  ;-)
> >>(Note my .sig line.  ;-)
> >
> >
> > Indeed. It's a growing pain that must be experienced at some point, if
> > progress is to be made. I'm a pretty big fan of the 'plan to throw one
> > away' school of thought. Often on a smaller scale single man
> > implementation (that I still do a lot of) I'll hack together very
> > quickly a prototype that solves the problem, and then once I truly
> > understand the issues, reimplement.
>
> *Excellent* plan!  (Of course, the subtle part is making the prototype
> real enough that all the hard parts manifest themselves.)
>
> A related development philosophy (actually, quite bottom-up) is to
> code the hardest parts of a program first--and be honest about what
> they are!

Indeed, and if time doesn't permit a full prototype, this is the next
path I follow - prototype the difficult components

> > JVM's have been doing this for a number of years, and with each passing
> > year they do it better. The .NET CLR also does it, at least if you use
> > a language that allows it.
>
> Glad to hear it.  When I last looked seriously (2000), I was arguing
> that the CLR should try to do this *very* well.

There's a lot of incremental improvement going on in this field.
Building the optimisers is taking a long time, but the ones we have now
are already very impressive, and very hard to beat in any reasonable
time frame 'by hand'. I imagine it won't be too long before they're
impossible to beat for any relatively complex program.

> > Indeed. There seems to be some disagreement about what must be
> > sacrificed to achieve these levels of efficiency though.
>
> Actually, almost *nothing* needs to be sacrificed if the optimization
> is based on run-time truth.
>
> All you have to do is generate a predicate that ensures that the
> preconditions you have measured continue to exist prior to executing
> the optimized code.  If that predicate fails, then it's time to fall
> back to the original code and do some more measurement to see if a
> new, perhaps more general, behavioral pattern has emerged.
>
> Compiler technology is based on theorem proving in a fairly weak
> axiom system.  You want to strengthen the axioms to allow more
> theorems to be proved (optimizations to be done) statically.  But
> it is not necessary to limit yourself to static knowledge, as you
> know.  You can replace "proof" with "probable inference" on the
> basis of observed behavior, and then generate code to verify that
> this inference is still valid--or escape to the old "interpretive"
> approach if it is not.  This is a much more robust system design
> than one based on static proof rules, and, in fact, it largely
> obsoletes the static approaches.
>
> Of course, separate compilation of applications as *hundreds* of
> separate modules already almost totally invalidates any hope of
> strong axioms holding across all modules.  Better to just rely
> on dynamic inference anyway.

This is precisely why I argue so strongly against using C/C++, you lose
any ability to do this kind of optimisation when you have no runtime,
and no runtime typing.

> > It's probably a combination of obstinacy and caution. On todays
> > hardware, you can do some pretty amazing numerics on GPU's rather than
> > CPU's, which have orders of magnitude more computational power than
> > CPU's with regards to numerical calculations. Getting it *right* for
> > numerics is hard, and given the rate of change in the hardware arena
> > thus far, it may prove to be more sensible to have left it until the
> > dust settles a little.
>
> Whoops--cop out.  There is essentially universal agreement on IEEE
> FP, with the only holdouts being...LANGUAGE DESIGNERS!  It's at least
> a decade past time to get with the program!

A decade sounds about right :-) As I noted, these changes can be made,
and should be. Let's just hope it does eventually happen.

> And don't worry about the GPUs and DSPs, not only are they moving to
> IEEE FP as well, but their computations are practically *never* well
> described in a conventional high level language, despite lots of
> publicity to the contrary.

I think things will be much easier once there's universal adoption.

> Any 2-bit (!) DSP coder can run rings around your favorite high level
> language on any algorithm whose performance matters.  This will
> continue to be true as long as the DSP/GPU actually has lots of
> various kinds of parallelism--and for that matter, it also applies
> to the various multimedia extensions (SIMD) in popular desktop
> processors, as well.  The only known "solution" to this problem
> is providing libraries of carefully hand-tuned code for applications
> to call--and it changes radically with each generation.

There's actually a great absence of such libraries though.

> > It's important to note one obvious area of parallelism that many fail
> > to consider: garbage collection. In older environments where you're
> > forced to collect garbage yourself, you end up with your collection
> > being executed sequentially with your other code. While it's arguable
> > that this is more efficient in terms of number of cycles than collector
> > based approaches, you lose out on the obvious ability to collect
> > garbage concurrently, which on todays hardware is a big inefficiency.
>
> Actually, in older environments, there *is* no garbage collection!

I mean you must do it manually :-)

> Garbage collection arises as a necessity only when programmers are
> released from the obligation to return resources they are no longer
> using.
>
> Garbage collection generally means traceable data structures, and
> therefore disciplined data structures.  However, don't overlook the
> "catch all" discipline for garbage--simply allocating a chunk of
> resource and then reclaiming everything that wasn't "registered
> as persistent" at end-of-job.
>
> In any case, concurrent garbage collection is possible in any
> disciplined environment, at some level of time/space granularity
> for which the discipline applies.
>
> > There's also the issue around algorithmic complexity going up with
> > inline collection (try implementing a fast B+ tree that doesn't leak)
> > so there's another big payoff to a more abstract approach.
>
> Actually, there are a lot of good reasons not to prefer a
> concurrent garbage collector, if it can be avoided.

Other than not having plenty of free concurrent processing power
available, what are they?

Any non-trivial program creates data then needs to dispose of it. What
purpose does it serve for that program to waste sequential running time
doing so?

> >>>>When I first saw Java, and heard it proposed as a "universal"
> >>>>language, I noticed that it had vectors of vectors, rather than
> >>>>multidimensional arrays.  I knew immediately that this would be
> >>>>a huge performance issue for numerical programming, since I had
> >>>>the pleasure of working with Burroughs machines that had exactly
> >>>>the same limitation--and the same fundamental inefficiencies.
> >>>
> >>>
> >>>Java supports multidimensional arrays as well. Always has.
> >>>Interestingly, people tend when comparing Java to C/C++ to pick the
> >>>worst way to implement something in Java and the best way in C++.
> >>
> >>Hmmm. This wasn't the case in 1994--or it wasn't the case in the
> >>extant implementations...  And this comparison was done by someone
> >>trying to do the best matrix package possible in Java.
> >
> >
> > Perhaps the implementations at the time treated multidimensional arrays
> > as vectors. Of course had explicit pointer arithmetic been allows we'd
> > have been stuck with that implementation.
>
> No, they treated multidimensional objects as vectors of vectors of...
> The workaround was to declare a one-dimensional vector of numbers, say,
> and take responsibility for the multi-dimensional mapping yourself--
> a much less "automatic" approach.  And pointers were not necessary,
> since all the arithmetic could be index arithmetic.

The main point for me is that the language allows a portable definition
of multidimensional structures. Whether or not a particular
implementation compiles it one way or another is not really an issue.

Once we rely on techniques that bind us to architectures we lose. It's
easy to avoid them, and we should do so.

> >>>This is essentially why I bother with these discussions. Obviously the
> >>>lack of primitive array types in Java would be a major impediment to
> >>>performance (At least until the VM's improve to the point of being able
> >>>to optimise Collection classes down to discrete implementations when
> >>>possible), but it simply isn't true.
> >>
> >>A major source of inefficiency without dense, multidimensional matrices,
> >>is the inabliity to rely on simple address arithmetic to navigate a
> >>matrix.  Introducing levels of indirection is a performance disaster.
> >
> >
> > Of course, it's simply arithmetic on an index to an ultimately
> > sequential structure, and treating it as multidimensional is just an
> > abstraction that can be implemented just as efficiently without
> > explicit pointers.
>
> Of course, this explicit approach makes compiler optimization of the
> element address calculations much harder to optimize.  Better to have
> real multidimensional arrays.

Which implementation model is more efficient for a given calculation is
something that must be determined, possibly even at runtime. This is
part of my argument for using portable language definitions.

> >>We're in substantial agreement about this.  I've been enough on both
> >>sides of "advocacy" that I tend to resist much of it as overstated--
> >>both positively and negatively.
> >>
> >>The real problems remain, and there are no silver bullets.
> >
> >
> > Absolutely. It is important in the absence of silver bullets to make
> > incremental improvements instead - which is more or less the approach I
> > advocate. Sort of a Darwinian model for software engineering if you
> > like.
>
> Just be careful that the "incremental improvements" don't take the
> place of the fundamental restructuring of computation that is needed
> to get to the parallel future.  That would be a case of "fiddling
> while Rome burns".

Absolutely

> >>>Unfortunately this is the case. I'm trying very hard to retain the
> >>>philosophy that this is a bad thing, rather than be thankful that it
> >>>increases my value as a professional as time goes by ;-)
> >>
> >>I hear that!  ;-)
> >>
> >>"Some of us were talking at lunch, and we hear that you've actually
> >>seen what 'bits' are..."
> >
> >
> > LOL! Fortunately for the moment at least, the computer scientist has a
> > substantially smaller hierarchy to navigate in his mind than the
> > philospher or scientist who's trying to fathom the fabric of the
> > universe ;-)
>
> Actually, not so.
>
> I invite you to make some lists.  You will find that there are more
> "levels of digital reality" than there are (known) levels of "real"
> reality.
>
> I have often opined that this is one reason that so many physicists
> have found computers attractive--because their "level navigating"
> skills and their understanding of invariants and conservation laws
> that apply across levels is so useful.

Of course :-) My point is that the levels of digital reality are all
knowable, where the levels of real reality are still being mapped, and
it's not even known whether or not the hierachy is finite, or indeed
that the models we have of the known levels are accurate.

You're correct that the digital realm has more known levels, but
whether or not the 'end' result is that the digital realm will have
more levels is a subject of great debate.

> >>Here we disagree.  No programmer should ever start a project without a
> >>specific performance and resource target.  To do so is like asking an
> >>engineer to build a bridge without specifying the span, the traffic, or
> >>the budget!
> >>
> >>Put another way, a programmer who doesn't understand the performance and
> >>resource utilization consequences of his design decisions is *not* a
> >>programmer, but a programmer's assistant.
> >
> >
> > These days, performance and resource consumption are very rarely issues
> > for developers to face, as the majority of projects utilise a small
> > fraction of the available machines.
>
> For little problems, yes--but operating systems are not such
> problems.  And neither are any programs on which people wait.
>
> And any "little class" that someone eventually wants to call
> a billion times before lunch has just become important.
>
> In these cases, too, there is a performance model--and for "little"
> or "infrequently used" code, the model suggests that performance is
> not an issue--but it still needs to be examined.
>
> I remember a case where a user wanted to write a very simple, 3-page
> program to find patterns in data of a certain kind.  Since he was only
> going to run it once, he didn't concern himself with resources--and
> proceeded to write a quadruply-nested loop over a three dimensional
> array with dimensions of 1000x1000x1000!
>
> Needless to say, his program wouldn't even load.  But if it had
> loaded, it would have run for weeks!  (Maybe now it would load if
> the machine had 16GB, and then it would run in only days.  ;-)

You'll get no argument from me that a fundamental understanding of
computational complexity is important :-)

> > Of course, in specific cases I agree with your approach.
>
> I didn't think it was controversial.  ;-)
>
> >>>>>>There is *no* substitute for a low-level understanding of what is
> >>>>>>actually going on in a system.  Unfortunately, higher level tools tend
> >>>>>>to further obscure actual system behavior by making it more "esoteric".
> >>>>>
> >>>>>
> >>>>>I agree. I feel it's a problem we'll never really solve, only mitigate.
> >>>>>higher level tools certainly do eliminate the need for a lot of
> >>>>>low-level understanding, but as your example illustrates, it's when the
> >>>>>problems arise that low-level understanding is necessary.
> >>>>>
> >>>>>One has to ask though what an inexperienced developer was doing writing
> >>>>>process scheduler code!
> >>>>
> >>>>He wasn't inexperienced!  He had been doing OS code for several years,
> >>>>after a brilliant career in the field.  But he fell under the spell
> >>>>of "abstraction for the sake of abstraction", and began designing as
> >>>>if an OS were algebra instead of a powerful, finely tuned, throbbing
> >>>>engine that could be thrown out of balance by inattention to the
> >>>>realities of its execution.
> >>>
> >>>
> >>>This is certainly an area where better tools to perform analysis with
> >>>are needed.
> >>
> >>For sure.  And those tools are worthless without the mindset and
> >>training to use them.
> >>
> >>I used to talk about the "4 T's":  targets, tools, training, and
> >>tracking.  Leave even one of them out and you can forget about getting
> >>a predictably performing system.
> >
> >
> > Agreed.
> >
> >
> >>Of course premature *anything* is a bad idea!
> >>
> >>But the design phase is *exactly* the right place to be concerned
> >>with system performance.  If you design an inefficient system, then
> >>local optimizations aren't going to get it anywhere near where a
> >>performant design would have.
> >
> >
> > There's always the frequent issue that a problem domain is not fully
> > understood until you've implemented at least one solution, and realised
> > how little you actually understood the problem.
>
> How true--but we've discussed that, and we seem to be on the same page.
>
> BTW, many problems that have "formal solutions" will be revealed to
> be *very* difficult when performance modelling is done.  This level
> of resource modelling reveals where the formal model relies upon
> "infinite" resources.  ;-)
>
> >>Note that I'm talking about *high level*, structural optimization in
> >>the design phase, not niggly bit-fiddley stuff.
> >>
> >>Sometimes, the right approach is to make anything that could be
> >>critical to performance have a very clean interface, so that it can
> >>be replaced with a better one when: 1) we know how to do it, 2) there
> >>is time, or 3) it turns out to be a big problem.
> >
> >
> > I tend to believe it's a good idea to give everything a very clean
> > interface. Dynamic OO languages have a clear advantage here, where
> > every interdependancy in a system becomes a functional one, and if you
> > keep your interfaces coarse, then you can achieve the approach you
> > outline iteratively, which is an efficiency win for implementation.
>
> Yes, I generally agree--but there is always the problem of deciding
> what level of granularity for the "modules" is appropriate.  Things
> can go seriously wrong here if they are chosen either too big (structure
> deficient) or too small (unaffordable overhead).  (Again, a resource
> tradeoff.)
>
> Engineering is *all about* tradeoffs.  While they are sometimes painful,
> the *most* painful ones are the ones you find out later were tradeoffs
> that you didn't recognize!

I look forward to the day when we can easily manipulate structures. One
advantage of language techniques that promote fine granularity of
modules, is that they provide a lot of room for coalescing them out at
runtime once the scope is resolvable.

I find it frustrating that many still advocate toolsets that implicity
bind us tradeoffs we needn't have made.

> And a compiler/code generator can do much of it with minimal support
> from the OS/hardware.  Of course, it's much easier and more accurate
> with hardware/OS support.

Yes, I'd appreciate more featureful os's from this perspective too.

> It's bloat.  ;-)
>
> More seriously, the bloat is undeniable, and is, in large part, the
> reason that running much code is I/O bound--just loading the code!
>
> In the days before we could have a gigabyte of memory, the bloat caused
> lots of virtual memory I/O, which is the worst kind of I/O bound.
>
> I think that the time required to boot a machine is an interesting
> measure of performance.  Somehow, we continue to lose ground here
> (and I do realize that much of that is I/O time).  Still, disk I/O
> is many times faster than it was a decade ago...

Yet still the speed deficit between I/O and computation grows...

> > I think a certain degree of bloat is unavoidable, hopefully it evolves
> > out of systems over time.
>
> That would be a new evolutionary trend.  ;-)

LOL, true. I mean that much of it can be pruned off when it proves
extraneous, much like callouses on a toe or foot. In fact, that seems a
most appropriate analogy when discussing most of the UI frameworks I've
seen :-)

> Organisms usually get simpler only when some extreme stressor hits their
> environment.  Hand-cranked machines?  Boot times exceeding attention
> spans?  ;-)

Well, such things are on their way :-)

> >>The only schema that I can see approaching this level of structural
> >>optimization would be an aggressive genetic algorithm--and all the
> >>computers on the planet may not yet be quite enough to do the job
> >>in a reasonable amount of time.  Later...  ;-)
> >
> >
> > It may not ever be possible, given the raising complexity of software.
> > If the software we run can challenge the best machines, we'll never
> > have enough horsepower to evolve solutions...
>
> Here's a heuristic to apply...a solution should get more complex only
> if the problem it is solving gets more complex.  By this rule, there
> is some other factor besides problem complexity that is driving up
> solution complexity.  I think that it is because we have erroneously
> concluded that complexity has no intrinsic cost, so we can increase
> it with impunity.
>
> Perhaps this error is abetted by the hope that new tools will increase
> our ability to cope with any negative consequences of complexity.  ;-)
>
> This can't be good for survival...

Indeed not, but using more abstract languages means that the
human-maintained component of a solution reduces in complexity, owing
to reduction in size. While its runtime complexity may be higher than
necessary, the actual solution is simpler.

The old rule that the number of bugs is proportional to the number of
lines of code comes to mind, and this is certainly an area of
complexity we can do without.

> > Indeed. I believe though that minimising these decisions through
> > keeping interfaces highly abstract is the best way to provide space
> > down the track for optimisation. Generally speaking, it isn't that hard
> > to get it right, but getting everyone to agree is oft problematic :-)
>
> Hence the need for objective models, and the expertise to appreciate
> their results.

If only there was time to analyse them. Can I say more, better tools
one more time ? ;)
> >>Actually, they are long past the point of "improving" anything.  All
> >>the people that understood those programs or the environments used to
> >>create them are long gone.  These are truly "legacy" apps, in the sense
> >>that they are treated just like gears or bolts--taken completely for
> >>granted until something fails.
> >
> >
> > There are always fringe cases, that's for sure.
> >
> >
> >>I agree with your points, Matt.  But consider how much of the resistance
> >>you describe may be generated by *overselling* the "new" thing as the
> >>"solution to all our problems".  Successfully marketing new approaches
> >>requires subtlety (which I apparently lack ;-).
> >
> >
> > Indeed the overselling of the new is as much to blame as overselling
> > the old. The massive hype around OO is a testament to this.
>
> Well, "one hand washes the other", they say.  So the overselling will
> increase to match the perceived resistance to change.  Then the "echoes"
> of the overselling constitute the basis for the next wave of resistance
> to the *next* change.  Sounds like a setup for "deja vu all over again".

Heh. There's no doubt this pattern will continue for quite some time,
and with less and less developers out there being able to comprehend
the whole stack/heirarchy, the amount of nonsense that propogates will
like climb, unless we find ways to combat it :-(

Matt