Re: Thinking assembly?
From: Beth (BethStone21_at_hotmail.NOSPICEDHAM.com)
Date: 01/31/04
- Next message: Octavio: "Re: Assembler Benchmarks"
- Previous message: Octavio: "Re: New Benchmark Generator Code Available"
- In reply to: T.M. Sommers: "Re: Thinking assembly?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 31 Jan 2004 09:42:25 -0000
T.M. Sommers wrote:
> Beth wrote:
> > but let us remember that your
> > case here is "not worth the bother" and that is NOT a technical
> > argument but a practical development argument...
>
> Practicality and economy are as much a part of engineering as
> physics and math. A bridge (or whatever) design that would be
> too expensive to ever build is a bad design, regardless of any
> alleged 'technical' merits. The same applies to programs.
Indeed; But, as you confirm from the way you use "technical" yourself
in the above, though these are, without doubt, also very, very much
part of engineering and must be fully accounted for, they are not
"technical" in the usual sense people use that term...
Of course, being "not technical" does NOT in any way detract from its
importance...I just wanted it correctly categorised, so to speak...if
we _only_ look at "technical", ignoring the practicality and economics
and so forth then there actually exists no _technical_ reason why
should not do these things...
Now, of course, as you rightly state, there's a whole lot more to this
than simple "technical only" considerations...if you don't have the
time, then you don't have the time...if you don't have the money or
resources, then you don't have the money or resources...and, usually,
there's absolutely nothing you can do about that...you must work
within these limitations placed upon you by the reality of your
situation...indeed, though "non-technical", these are, in a sense,
solid brick walls...ignore them at your peril because if you go slap
bang into one of these brick walls at 90mph because you didn't keep
within those limits, then you can expect a bloody nose for doing so at
the very least but perhaps far worse...
But I was trying to establish what was "technical" and what was "not
technical"...there was NOT intended to be any kind of "only technical
is important" argument applied at all..._all_ of these things are
significant, as they all conspire to be the "limits" under which you
_must_ work...and let us emphasise "must" there...we _mean_
"non-optional", as we're talking _hard realities_, not just "fancy
theories"...if the budget don't stretch that far, then it _won't_
happen, regardless of the "technical considerations" involved...
Although, I would again take issue not with what you're saying but how
you say it...generally, people would read the wrong impression from
calling a bridge a "bad design"...an _impractical_ design, sure...a
design that's useless to us because we can't do it...but calling it
"bad design" would normally be taken by most people to imply that it's
_technically flawed_...which isn't the case...I can work out what
you're trying to say there and you're right...but your choice of words
needs to be more carefully selected and diplomatic..."being firm" is
good when you're sure of what you're saying but watch you don't overdo
it and start accidentally misleading people with "undiplomatic"
language...in fact, as we've just established, there is more than
merely "technical" aspects to these kinds of things...you don't just
have to be right because one "practicality" and "reality" of your
situation is that you're talking to human beings, who take things in
different ways according to how they are phrased...this is a similar
"non-technical" thing that an engineer should _also_ be taking account
of...
Because, for example, the architect who designed the Sydney Opera
House fell out "politically" with the people holding the purse
strings...and though he designed an interior for the place, the
"politics" and his lack of "official" qualification in acoustics meant
that it was never built (not a money thing or technical thing...a
_political_ thing :)...not too long ago, they took those blueprints
and fed it into a computer simulation to see what it might have been
like...and, on that virtual reality screen, it looked absolutely
gorgeous...as, if not more, visually stunning as the outside of the
building...and as to his lack of qualifications in acoustics? The
computer calculated the acoustics to have been spectacularly
good...perhaps some of the best ever designed for a building like
this...had the "politics" been right then it could have been _THE_
best arena ever constructed - both inside and out - for conducting
performances in the whole world...they missed a trick due to silly
"politics"...
Hence, an engineer has to also take account of the _thoroughly
non-technical_ aspect of politics, diplomatic language, etc....it's
not "good enough" to simple be correct with human beings,
unfortunately...you've also got to serve up that truth on a silver
platter with a silver tongue..."non-technical"? Sure...but as we know,
that doesn't matter...a brick wall is a brick wall, be it a
"technical" or "non-technical" brick wall ;)
> > that is, the reduced
> > function _is_ better...but, indeed, in practice, the effort
> required
> > to make it so would far outweigh the benefits that you'd be
> foolishly
> > wasting your time when you have better and more productive
> things to
> > be doing...
>
> Exactly what I have been trying to say.
Well, we agree then...good :)
> The mistake often made
> is to ignore the costs, especially the opportunity costs, which
> you quite correctly bring up.
Yes; Indeed...but it's fair to stress that a "10% speedup" is equally
an "opportunity" that can often be useful, if not very significant, to
a particular application...where focussing too much on "costs" -
saving a cent here and there - ended up as the thing that made us miss
a great opportunity...you don't want to waste your money, of course,
but _nothing_ occurs at all unless you make some kind of
investment..."speculate to accumulate" and all that...it's not about
one or the other, it's about getting the _balance_ between them
exactly right...and, indeed, that's a particularly difficult tightrope
walk on most occasions...
Though, granted, in most cases, it tends to be the other way around
and engineers tend to get "geeky" and "technical", forgetting the
important "other considerations" of practicality, time, budget,
politics, etc....but I'd stress emphasising the _balance_ needed
rather than only trying to "cancel out" one extreme by insisting on
the opposite...
> > Basically, you're confusing two types of "constant" (I note
> that you
> > earlier referred it as a "constant" and, therefore, it was
>
> It was Randy, not me, who brought up the constant.
Then, apologies, consider it addressed to Randy...
> > Well, in a sense, if try to do a simple "pseudo-mapping" of a
> > "running-time" calculation into a similar form of
> "pseudo-equation",
> > we find something like:
> >
> > running-time = (language * (x ^ algorithm)) +
> one-time-only-overhead
>
> The problem with this is that run time is only one factor. This
> equation ignores such things as development time, debugging time,
> maintenance time, and so forth. In other words, it ignores the
> costs, and focuses only on the benefits.
Yes; But, in this case, that was the intention...an "abstraction" to
focus on "running-time"...such an "equation" does not mean that there
are not other factors - and, as you've said, I correctly gave mention
to exactly the kinds of "other factors" involved elsewhere - but is a
means to focus on that one particular factor to show what goes into
just that factor...
If you like, you can try writing some "exhaustive" equation that
includes every single possible factor...but, if one was to get
absolute pedantic to the letter of the law, so to speak, that would
actually be an _infinitely long_ task (after all, if one includes
"politics" as a factor in your "exhaustive equation" then we should
further break down what goes into the "politics" factor: "The boss
doesn't like me because I made a silly comment while about his wife at
the Christmas party" / "John still hasn't forgiven me for wiping that
floppy disk" / etc. and then further break this down again and
again...otherwise, unless it is infinitely divided into every single
factor of an infinity of them that conspires towards a particular
project then someone could still accuse you of "This focuses only on
certain factors! You're ignoring that Christmas party where you pissed
off the boss that he never gives you any proper work appropriate to
your position anymore! If you hadn't said that at the party, then you
wouldn't be constantly made to be the one who goes to fetch everyone a
coffee all the time!" ;)...
Myself, on consideration that it's _practically impossible_ to create
some "pedantically exhaustive equation" of every single factor that
has any kind of influence on a project, as it's effectively an
"infinite task", I decided to focus on a particularly relevent factor
that I wanted to highlight...but, by all means, you can waste the rest
of your natural life trying it and still not succeeding, if you
like...just don't ask me to go doing that as some kind of "punishment"
for not just nodding silently in agreement to your every point and
actually trying to discuss them...
Let me guess: You're usually "the boss" in a "leadership role"? You're
giving off that whole boss "firm and decisive" vibe that's commonly
used to keep everyone on schedule and on the same page...the "bash
their heads" together style of "boss" language...yeah, ever since my
little brother got a more "managerial" position in his job, he's
become a lot more "bossy" about things too...you know, turning up to
see me with "plans" and telling me I should do this and do that,
undoubtedly exactly he has to do for his job, that it's a case of not
knowing when to "switch off"...I soon remind him, though, that you can
be "boss" in one place and "peer" in another and "sub-ordinate" in yet
another...so "flexibility" of perspective can come in very
handy...although, in this case, I'm not your big sister, so I don't
really have the same kind of "right" to be immensely cheeky about it
with you, as I am with him...but that's the kind of "flexibility of
perspective" I'm talking about...choose your wording according to your
audience and you get the best results...when you're "boss", you can
order people around but if you try something like that in a volunteer
OpenSource project on the internet, you could knock noses out of joint
because, of course, you ain't their boss so they don't actually have
to tolerate your "orders" at all, if they don't want to...like I say,
"politics" is certainly one of those "other factors" people regularly
forget to account for...but, often, it can even be the biggest factor,
if you do go and drunkenly insult your boss's wife at the Christmas
party...oh dear, he'll have you working as a "glorified tea-boy" for
weeks at least as "punishment"! ;)
Beth :)
- Next message: Octavio: "Re: Assembler Benchmarks"
- Previous message: Octavio: "Re: New Benchmark Generator Code Available"
- In reply to: T.M. Sommers: "Re: Thinking assembly?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
