Re: Rocket Science

From: Beth (BethStone21_at_hotmail.NOSPICEDHAM.com)
Date: 02/01/04 

Date: Sun, 1 Feb 2004 06:46:15 -0000

Frankie say:
> Beth wrote:
> > Randy wrote:
> >
> >>Does this upset me? Not at all. I've never claimed HLA to be 20x
> >>faster than
> >>MASM. HLA v1.x is a prototype and speed was almost never a
> >>consideration
> >>in its design. Have no fear, though, HLA v2.0 is going to blow
MASM
> >> away
> >>(based on early measurements I've made).
> >
> > Also, logically, if MASM is the underlying assembler being used by
HLA
> > v1.x for these tests, then it's slightly on the impossible side
for
> > HLA to beat MASM in that instance...

[ I presume you are getting my above point, though, Frank...if HLA
_uses_ MASM, then MASM must always be being run in addition to HLA so
it always includes MASM's figures as well as HLA's own, meaning that
it's, therefore, impossible - providing the same source code suitably
converted to both - for HLA to ever beat MASM...

And, on that point, of course, this also has to be factored into the
interpretation of HLA's results that it is implicitly also carrying
the MASM or FASM or whatever underlying assembler's speed into its own
figures because HLA doesn't (currently) work separately from these
tools...

That's why - also because Randy himself admits that the Yacc / Bison
implementation forced numerous "hacks" and not the best
implementation - HLA is coming out worst in these speed trials...and
it's amazing that Rene accuses Randy of trying to "fix" the results to
disgrace RosAsm and promote HLA...when HLA v1.x is so horribly slow
that if Randy was try to "impress" with test results to try to
persuade people over to HLA, the _LAST_ thing he'd be wise to do is
suggest and work on such a "speed trial" because it's a foregone
conclusion that, due to its implementation, HLA v1.x is going to
_fail_ against the other assemblers because it _depends_ on the other
assemblers to get things done (so, even if HLA was _instant_ and took
no time at all, then using MASM as the underlying assembler, the best
it could manage (which is slightly impossible to "instantly" process
these things - at least, using the "traditional" non-incremental
methods - that the figure will always be higher again) is to _match_
MASM's results... ]

> Using the "-sf -fasm" switches to HLA speeds up HLA a *lot* on some
> code. (Randy's test-bench generator, for example).

Out of interest, is FASM doing better in those tests than MASM by a
similar degree? If so, then I think we know where our true "culprit"
really is, eh? ;)

> If you've got a file
> where you'd like to have a large static array, Masm will be slow as
> molasses on it. Some people reduce the size of the array to get
around
> this problem. It seems to me that this is a pretty good definition
for
> "how slow is too slow". If you're changing the way you code because
of
> limitations in the tool you're using, it might be time to shop the
other
> available tools.

Yeah, that's a pretty good pragmatic definition of "how slow is too
slow"; If it's so slow that it's forcing you to code differently, then
it's gone passed "tolerable" and that kind of sounds like a nice
approach to defining "too slow"...

Mind you, I still say, what's the big fuss all about? Even if, as
Rene's been shouting about, something takes _minutes_ then go make a
cup of tea or coffee, or smoke a cigarette or something like
that...it'll be done when you come back...and you'll be refreshed,
ready to take on your code once more...

I mean, if it _is_ going to take minutes then you're actually being
slightly silly sitting there waiting for it..."a watched pot never
boils", you know...that's why, if you stop for a second and think
about it, it's somewhat ludicrous to be making such a fuss and
argument over 0.015 seconds or whatever...like, what on Earth are you
going to do in 0.015 seconds that it's so bloody crucial that you
"recover" this time??!

Exactly; What we have here is _psychology overriding common
sense_...do you know what would be much more useful? One of those
microwave "ting!" noises...yup, write a batch file that calls the
assembler and then calls "ting.com", which does something simple like
print an ASCII 7 to get that "bell" noise (perhaps repeat it a few
times or, under Windows or Linux or whatever, you could actually use a
waveform sound...something amusing like, for example, "Heeeeere's
Johnny!" from "the Shining" film...note, as daft as this sounds, we're
talking _psychology_ overriding common sense...trust me, from a
psychological perspective, then this makes the best "ting!"
noise...well, so long as you do find it amusing...feel free to
substitute some other funny "joke" noise instead...in actual fact,
even better for "psychology" reasons, have a whole bunch of different
"ting!" waveforms in a folder and then you're little "ting.exe"
program can select one at random and play that..._variety_ is very
healthy for the mind...you'd eventually go bananas listening to
"heeeere's Johnny!" every single time! ;)...

Then, if you know a process is going to take a few minutes, then put a
"ting!" noise after it to signal when it's finished then go off and
get yourself some quality "ME" time...start boiling the kettle for a
cup of your favourite hot beverage, light up a cigarette if you smoke
(no, not that type of cigarette, Frank!!! ;), read another chapter of
that book or whatever...stay within earshot of the "ting!" so you'll
hear it (the "volume" dial may be handy here...although, if there are
others around you, then please be considerate...for instance, if
you've only just got the baby to sleep then it's inadvisable to blast
"Heeeere's Johnny!" at maximum volume into the little dear's left
earhole...do that and it's not only the baby you'll never hear the
last of screaming, your "significant other" will no doubt join in, you
uncaring inconsiderate oath that you are!! ;)...

This is a psychological principle that we can call "a watched pot
never boils syndrome"...you are becoming impatient and it seems to
take forever, in fact, NOT because the thing is taking too long (a
0.15 second difference? Heck, even a 10 second difference? Who gives a
crap? ;)...but because you are _waiting_...

Hence, don't wait...as simple as that...employ my unpatented "ting!"
microwave technology and keep a lower priority "secondary task" to do
while you're waiting...in fact, it makes a lot of sense if this
"secondary task" is _completely irrelevent and completely
selfish_...yes, just read a book or have a cup of coffee or
whatever...you are not a machine and to treat yourself as if you are,
often results in very poor performance and productivity (which is
ironically very "un-machine-like", in fact ;)...but, look, you're
doing it already! Sure, _DOS_ is single-tasking one-at-a-time...but,
you know, _you_ don't have to pretend you're DOS or a machine or
anything...

I find playing your MP3 collection helps speed along those
compilations...I reckon I must get a 20x increase using MASM while a
good tune is playing, compared to without music!! Beat that in your
"time trials"!!

"Huh? What's she talking about? It's the same amount of time whether
music is playing or not!"; Correct, in so far as it's the same amount
of time in _seconds_ but it's a completely different "perceived
time"...and regards impatience for something to complete, only
"perceived time" matters...

Oh, and you're now thinking: "okay, but if I use a faster assembler
then I'll get my work done quicker!"...want to place money on that?
Make your assembler x10 slower and you know what happens? You simply
write more between assembles (hmmm, that word sounds odd but what is
the equivalent of "between compilations" using "assemble" rather than
"compiles"..."between assemblations" sounds even more silly again
;)...faster tools actually tend to make you compile and stuff much
more often so you have to factor in that if you're gaining 3.5 seconds
every time, does this balance up with the fact that you're compiling
twice as often as you normally do? If you're sitting there working
yourself up with stress and "mental chatter" and so forth, fuming at
the speed of your tools then you're putting yourself in a terrible
frame of mind...that'll harm your productivity...possibly to the point
where the damage "impatience" is doing to your coding far outweighs
the "time lost" to a slow compilation in "productivity" terms...you're
not a machine and mistreating yourself as if you are is actually
_counter-productive_..._work with_ your nature and you will get better
results...

Mind you, no-one's to blame here...this is an amazingly common mistake
people make...they get this fool notion that "time management" is
about measuring seconds and that sort of thing...that "productivity"
is only a "statistical" measurement...that sitting around staring hard
at a boiling kettle, you can force it by mental will to heat up
quicker (ask a physicist about "specific heat capacity" and why you're
barking up the wrong tree...in fact, if you can actually manage to
mentally "will" a kettle to boil in less than 3 seconds then give up
programming immediately! You've clearly got fantastic mental powers
that are better employed elsewhere - perhaps in a "superhero"
capacity - and you'll probably also have to be constantly on the run
from the legions of "scientists" who want to crack open your skull to
do "experiments", seeing as you appear to be able to consistently
break multiple laws in science, purely at will ;)...and it's also
common to make the terrible mistake of thinking that "productivity" is
"harmed" by taking some time for yourself rather than greatly
enhanced...yeah, it's common as muck for people to think backwards on
this issue...

If you're really amazingly "hung up" about "assembly time" (and you're
not just doing this for "phallic extension" reasons only or whatever
:), then, simply, you're going about things all wrong:

Once upon a time, there was a farmer who had a whole bunch of
geese...the geese would lay eggs and he'd take them down to the local
market and sell them (geese eggs are more "unusual" than ordinary
chicken eggs so he could charge his customers a few groats extra on
them ;)...he'd got his own stall and regular customers he'd chat to
and everything...it was a living, granted, but not much of a living,
as you don't exactly become a billionaire selling geese eggs, as I'm
sure you can imagine...but it was a nice life, as he was his own boss
in this farming business and that Liberty to do what he liked most
times was something he cherished...then, one morning, he woke up, had
his breakfast and went to check on his geese, as he would do every
morning...he collected up some eggs from the geese, as normal, until
he saw a shiny golden egg amongst them...picking it up, it was very
heavy and he realised that it was _solid gold_...after standing around
in shock for a while, then his eyes darting around to see if anyone
had seen this event, a grin shot across his face and he started
dancing and prancing around his barn in celebration...a solid gold
goose egg! He was rich! He first melted it down in a pot over the fire
in his farmhouse (if it was goose egg-shaped, that would kind of be a
"give-away" to other people where he got it and those geese were his
living so he didn't want people coming up to the farm to harass
them...well, he might be a rich farmer but he was still a farmer and
he took the care of his animals seriously, as all farmers must
:)...then he rushed it over to the gold merchant at the market - an
old friend, as his shop was across the market from his egg stall -
who, though shocked to see an ordinary farmer with such a haul of
gold, knew never to ask any questions about where any gold might come
from and handed over a bug bagful of groats to buy the egg off the
farmer...

The next morning, the farmer woke up and, though he'd decided to have
a day off to actually spend some of his new fortune at the market over
in the city, he was still a farmer at heart and went to look in on his
animals to see that they were okay...he was bowled over when looking
in on the geese this time, to find _another_ golden egg...well, he
took that, as he had the last one, to the market to get more groats,
doubling his already impressive fortune...this time, though, he
decided to separate out his geese into different pens so that he could
work out which of them was laying these golden eggs...sure enough, the
next morning, there was another golden egg and he'd worked out which
one of the geese was laying them...he fed that goose so much food that
day, Hoping this would mean the goose would lay bigger eggs...the next
morning, there was another egg and, yes, it was a touch bigger than
the other ones...so, that goose was fed as if it was a pig...and every
morning, the goose was laying more golden eggs, as regular as
clockwork...

Well, as you might imagine, the farmhouse got replaced by a massive
mansion with gold decorations everywhere and the most expensive
furniture and art decorating the walls...it was a palace...and then he
hired servants to look after it and cooks to put on massive feasts in
the banqueting hall for all the "new friends" he was making by being
exceedingly and absurdly rich...he drank the finest wines and eat the
finest foods and lived a life of pure luxury...he took up gambling and
made donations to charities and everything...because, after all, he
had a guaranteed income...every morning the goose would lay another
egg as regular as clockwork...

But his expensive tastes exceeded his means; The goose just wasn't
laying these eggs fast enough! He needed more to build that grand
extra "wing" onto his palace and an awful lot more...he also had built
up massive debts through gambling with his "new" friends because he
wasn't particularly good at cards...so, he went over to the barn
impatiently and up to his "golden" goose...and, taking a big, sharp
knife, he was going to get all of the eggs in one go..."the goose must
be full to the brim with solid gold eggs!", he reasoned...and then he
took the knife and opened up the goose...inside, he found
_NOTHING_...absolutely nothing but goose innards...no eggs, let alone
golden eggs...

And then it dawned on him what he'd just done: no goose, no golden
eggs...no golden eggs, no income...no income, no means to pay his
servants or pay off his debts...no means to pay off his debts but to
sell off his fine mansion...no fine mansion, all his "new friends"
would disappear...in one stroke of the knife, he'd slid right down a
snake from square 99, right back to square 1 (every "snakes and
ladders" board seems to have that "most cruel of serpents" who steals
it all away but one square away from winning, ever noticed that? ;)...

He sold off the mansion and paid off most of his debts...a few more
months of selling his now very ordindary goose eggs at his market
stall and he should work off the few small remaining debts...and now
he was back at his farmhouse (he'd luckily not knocked it down or
anything ;), back with his old friends and back to tending his geese
as before...

[ Adaption of Aesop's "The Goose That Laid Golden Eggs" fable :) ]

This infamous fable has a simple underlying message - in addition to
the obvious as daylight "don't be greedy!" moral to the tale - in
order to get golden eggs, you _must_ look after your goose...pretty
logical, huh? Kill off the goose, no more golden eggs...of _equal
importance_ here is the _goose_...if you get too obsessed with the
golden eggs only and forget about the importance of looking after the
goose, you're actually cutting off your own oxygen...

Well, in a sense, if the software you're developing is a "golden egg",
then the "goose" here is actually _YOU_ (no insult intended; It's just
a _metaphor_ only ;)...as the programmer, you are pretty much a
"mandatory" thing when it comes to software "golden eggs"...no you, no
software...exactly like the goose and the eggs...

Hence, as well as the more obvious "don't be greedy!" moral when it
comes to the "*** waving" aspects, I'm actually wanting to draw your
attention to the further message in the fable...if you concentrate
only on the "golden egg" to the detriment of yourself - the "goose" -
then you are actually making a false economy there...if obsessing over
"golden eggs" is making the goose - you - "ill" with impatience,
constant stopping and starting, frustration, losing track of what
you're doing all the time...then your "productivity" will be _crap_
and NO TOOL - however good it is - will cure that...

Take this also in the context of "a watched pot never boils" and you
might start to get my point...I consider the speed of a tool to be
totally _irrelevent_ so long as it's "reasonable" (or "good enough",
for those that prefer that term :) and not prohibitively slow...we're
going to be doing other things - looking out for the "goose" in
ourselves and getting ourselves some quality "ME" time - while this
happens, anyway..."ting.com" can tell us when it's finished so that we
can get back to work once more...

And, totally, this will "statistically" waste all those 0.015 seconds
and such every assemble and accumulate to so much time overall and
what-not...but if you think you're managing your time better obsessing
over these "golden eggs", then you should perhaps give that idea a
serious re-think...

> HLA has an unanticipated(?) feature here! You can write your code
any
> way you like in HLA, and select the assembler which does the best
job on
> the particular sort of code you've generated.

Hmmm, yes; But it's an odd "feature" in that it's quicker still to use
FASM and MASM more directly, if "speed" is this big worry...if you're
already using HLA, then, sure, that's a groovy idea to take note
of...but it's not a "feature" in the sense of all the MASM and FASM
users rushing off to HLA to take advantage of it...

A "feature" that would not feature in the "feature list" on the back
of the box as a "sales pitch", anyway ;)

> For large static arrays,
> Masm is one to avoid. I haven't used Fasm enough to find out what
it's
> bad at, but I assume there *is* something - every chain has a
weakest
> link.

"You are the weakest link...goodbye!" ;)

> The big problem with Gas is that you have to write the code...
> unless you ask HLA to write it for you :) I don't know what
> circumstances would make it an advantage to use Gas, but there might
be
> some.

Perhaps, though, GAS might actually be faster because it is "the GCC
back-end" more than anything...much like GAS has been maligned for
not-so-great error checking...because, as the GCC "back-end", it's
always handed perfectly valid code that error-checking is not too
useful there...there would be, in fact, not much point having it at
all, if it wasn't possible to use GAS separately as well as with
GCC...and, so it is reported by GAS users (I confess to not having all
that much to do with it, as that AT&T syntax is a task in itself to
get used to ;), GAS does tend to be "GCC back-end...but, oh, let's add
this here and there in case someone uses it directly"...

Hence, it might actually possibly do well in speed comparisons from
not doing as much error-checking and that kind of thing as the other
assemblers...you know, the old thing that an assembler with _no_
"features" at all will probably easily outpace one full of "features",
simply because it's doing less work and not necessarily because it's
faster (the "feature-full" assembler is actually brilliantly coded to
run really fast BUT because it's doing ten times the work, it doesn't
look so good in the speed comparisons ;)...although, of course, that's
a "general" thing...in these "time trials", every assembler is being
fed "equivalent" code that this doesn't show up as well as with actual
"real-life" use...

> Never tried HLA with the "-st -tasm" switches - alleged to be the
> world's fastest assembler - up to you to investigate that, Beth :)

I can't actually; The TASM support on HLA isn't actually
"generic"...that is, it works for a newer version of TASM that goes
along with "Delphi" or something...Randy added it to make using HLA
with Delphi easier, apparently...if you've got _that_ particular
version of TASM then you could test it out but I've only got the
latest version from when TASM was "stand-alone"...HLA uses some of the
"features" this Delphi-TASM (to give it a name :) has and it can't,
therefore, be used on other versions...

No, in fact; That was a kind of annoying thing with wanting to link up
HLA code with Borland C++ (re-do my own "lean and mean" C startup code
and "libc" using HLA, for example, so that I can write a C program and
not automatically lose 40KB or whatever doing absolutely nothing
useful at all ;)...the TASM option isn't actually helpful unless
you've also got Delphi (I've only got an old C++ Builder in the
"Borland HLL" direction (well, also a standard boring old "Borland
C++" before Borland added all the VCL widgets and "visual
editing"...plus, that free command-line tools thing they had on their
website...unfortunately, none of which carry the particular
Delphi-TASM version needed ;), which doesn't have the right
stuff)...so, bizarrely, Randy suggested using MASM with OMF instead of
actually using the TASM option...I never actually got around to trying
that out, mind you, because after hitting the "dead end", I adopted an
"alternative" method instead...TASM in "IDEAL" mode...except that TASM
in "IDEAL" mode I've discovered is incredibly "flakey"...it crashes on
large include files and gave a really bizarre set of error messages
that turned out to have nothing at all to do with the actual
problem...and, basically, "IDEAL" mode's a nice idea but the
implementation is quite unstable in places...kind of like using
RosAsm; You can't be sure if it'll still work once you expand your
files to be twice as big as you work on it...sure, it works _now_ but
big files do make it blow up, so can we be sure it'll still work as
the application grows...I mean, imagine working months on a project
that's sailing along just fine and then finding the tool explodes if
you add just one more character...what are you going to do?? Indeed,
perhaps it's a better idea to not head down that path at all...

> If
> Nasm should prove best at something, it would be trivial(?) to add
Nasm
> syntax output to HLA (or converting the Fasm code is easy). I don't
see
> much advantage to Nasm here - Randy's right to make it a low
priority. I
> don't think RosAsm output is in the cards :)

Why, it would be "unethical" to actually _use_ RosAsm...it's more a
kind of "display piece"...something to invite the neighbours around to
see that you can boast about having...but using it for a purpose?!?
Frank, how could you be so "unethical" to even consider such an idea!!
;)

> Nasm's performance on the "early version" of Randy's benchmark runs
over
> two *minutes* on my screaming K6-300. Pulling in a macro file to do
> "if"s is going to be measurable with a sundial. Add a few
conditional
> jumps and turn on multi-pass optimization, and we'll need Stephen
> Hawking as a consultant to measure it!
>
> Nasm loses this "battle" badly... provided the tests are run on an
x86.
> On a Sparc, Nasm makes the other assemblers look like a "crippled
concept".

Ah, NASM probably has trouble from a development perspective...there
is the "written in C" thing but it shouldn't make a grave difference,
if well designed...but that's probably where NASM has troubles in that
it was put together in a very "ad-hoc" fashion...a "patch" added
somewhere might be dragging this all down or whatever...the "one
person" projects have the advantage on NASM that there can be an
"overall vision", so to speak, and the assembler can be structured and
"tweaked" with this "one person" comprehending all the little nooks
and crannies in the code...

NASM could do with a "re-write" that puts all the "ad-hoc" stuff
that's been accumulated together into one more "consistent" whole, I
reckon...all that stuff is good, it's just when you "add on" things
like that, there's an inevitable slide towards it becoming "hacky" and
difficult to fine-tune to perfection...in fact, though they'd never
admit it, Microsoft's stuff suffers a similar problem because they
tend to "ad-hoc" everything and take "code re-use" to new levels of
semantics...but, from time to time, Microsoft do sometimes do
"re-write" things and when they do, that's usually a "reasonable"
improvement...unfortunately, most of the time, it's "ad-hoc" and they
obsess with "feature" after "feature" - all bolted on in this "ad-hoc"
fashion - until the thing becomes an "Unholy Mess" of pure "bloat" and
crapness...in fact, a big reason why Microsoft are so crap is that
they follow such patterns almost religiously...the reason being, I
assume, that re-writes take time and cost money...sitting down to plan
something "consistent" is the same...and they are "time to market"
rushers, to which this kind of development "strategy" (if can call it
that because, of course, the whole basic problem is a _lack_ of
"strategy"...it's, instead, thought up then bolted on, thought up then
bolted on, etc., etc. until it's just a messy patchwork quilt tangle
of "bolts" all over the place ;)...

NASM isn't anywhere near Microsoft on that scale, mind you...but the
essential problem is that you are on the same scale, unfortunately,
due to the way development naturally happens on such an "open-source"
project like that...the "lack of strategy" is actually the one place
where "OpenSource" can fall behind other development methods...

Well, that is, it _can_ be a problem...for LuxAsm, that's why I'm
jumping in with the basic "framework" suggestions right at the
start...as you correctly noted, when building a "house of cards", you
should pay particular attention to the foundations...but, get those
right and it should be perfectly possible to build skyscrapers on top
of it...it's not actually "OpenSource's" fault, so to speak...but more
that it can foster a more "casual" approach and, from that, there's
not enough care put into the "foundations" and "framework" to make
sure the bigger project will actually hold...though, the good and big
OpenSource projects all do it right which, I'd say, is exactly why
they worked, while quite a few projects - not through a lack of skill
or motivation - can fall flat on their faces because, well,
"open-source" doesn't come with "discipline" forced on you, like
working a commercial job, so you have to remember to put some
"discipline" into the project yourself (not necessarily "strict"
discipline or "hierarchies" or any of that nonsense...but _some_ kind
of "hook" on which everyone can hang their coats :)...

Beth :)

Quantcast