Re: Time this code, please!


Betov wrote:
"KiLVaiDeN" <kilvaiden@xxxxxxxxx> écrivait news:1161768741.868382.211780
@h48g2000cwc.googlegroups.com:

It's pretty funny to see you, Randall Hyde, the guy who supposedly
knows everything about assembly, ask people to test a program for
speed. The question is : Ain't you sufficiently qualified to time your
opcodes yourself ?

There are several other funny things, here...

* Definitively: Having the guy who wrote one of the _slowest_,
ever seen, HLL Pre-Parser applying his usual Propaganda methods
to Code Speed.

Actually, as you've created the term "HLL Pre-Parser" to specifically
describe HLA, it's also fair to say that it is the _fastest_, ever
seen, HLL Pre-Parser in existence. :-)

Now if you're comparing the speed of the HLA assembler against other
assemblers, there is no question that HLA is not the fastest assembler
out there. But at 50,000 lines/second when processing machine
instructions, it's not exactly the slowest product out there, either.


* Radicaly: Having a guy proposing Code Level Optimization, in
HLL.

???
Whatever.
We all realize that you don't know how to write optimized code.
Particularly, code that is optimized at the machine code level. Because
of your insecurities in your abilities in this matter, you simply
strike out and attack others who are interested in this facet of
assembly language programming (and I'm just the latest in the long line
of people you've attacked over this issue).

Why don't you just learn how to write fast machine code, so you don't
feel the need to attack others who know more about the subject than you
do?



* Sadly: Having so many guys really believing that the speed of
an Application could depend on Code Level Optimizations.

Well, the Mathisen and the div by sub algorithms run an order of
magnitude faster than the division algorithm. What algorithm were you
using in RosAsm, again?



* Black Humour: Having guys effectively _testing_ his bullshits.
I can't believe it...

You don't believe a lot of things, despite the fact that reality keeps
hitting you over the head with the truth.



What is way less funny, is that preaching Strategy Optimization,
on an Assembly News Group, is exactly the same as preaching in
the desert, dispiting any evidence. Well...

What is really sad here is that you don't even realize that the
algorithms I've posted for testing are *exactly* utilitizing your
principle of "strategic optimization". For example, take a look at the
code and note how I run specific code paths for numbers that are 1, 2,
3, 4, ..., 10 digits long. Specifically, I don't execute extra code
needed to process a full ten digits when outputting a three-digit
number.

You seem to think that you invented this concept of "picking the best
algorithm for the job" or "specializing the code to avoid extra
calculations", but the truth is that these concepts existed long before
you came along and renamed them "strategic optimization". The only
reason you have for thinking you're "preaching in the desert" is
because everybody around here already accepted the concept of "better
algorithms" long before you came along and you're adding nothing new to
the discussion. OTOH, people *are* interested in faster code, and once
you have the better algorithm, micro-optimizations in assembly language
is a good way to achieve that. You will note, however, that my code
does *not* employ any "micro-optimizations" because I specifically want
the code to be fairly decent on all x86 CPUs, and micro-optimization
doesn't achieve that.
Cheers,
Randy Hyde

.

Relevant Pages

  • Re: Population count in SSE2, again
    ... This is a crude version of the well-known code in AMD's optimization ... and is not as fast as the AMD code. ... oneself that the algorithm is mathematically sound. ... Yes I'm sure you are right, but a typo in assembler is easily made. ...
    (comp.lang.asm.x86)
  • The Case Against RosAsm (#7) (LONG)
    ... "Branch Displacement Optimization" is one of these ... The first assembler I recall that provided ... when a wanted short jump was longer than required, ...
    (alt.lang.asm)
  • Re: HLA v1.93 is now available
    ... Optimization is Strategy Optimization. ... You're claiming that an assembly language programmer using HLA ... Only in *your* assembler. ... FASM does branch displacement optimization. ...
    (alt.lang.asm)
  • The never ending assembly vs. HLL war
    ... > branch instruction excluded is not particularly effective optimization. ... > CPU, chances are pretty good it *won't* be optimal on a different CPU. ... > discussing the futility of optimizing it in *assembler* when the ... careful and consider the code the compiler is emitting (and adjust your ...
    (comp.lang.asm.x86)
  • Re: gcc optimization changes results
    ... my program comprises a new algorithm to determine the objects ... enabling optimization could screw it up. ... you can still enable debugging info while ... If you really understand assembler well and your code isn't ...
    (comp.os.linux.development.system)