Re: The never ending assembly vs. HLL war

>The problem is that you then generalize your results and say "see,
>using assembly isn't worthwhile!"

Before, or after you came along I did not say using assembly isn't
worthwhile. It is, but very RARELY. In this case with the strlen() in
C++ vs. x86 assembly for instance it isn't worthwhile.

>And that's the argument that I'm not buying. The fact that in some
>controlled situation you can cajole a C++ compiler into producing code
>about as optimal as one can expect does not imply that the compiler
>will do this all the time. You are dispelling no myth, I'm afraid.

The point is that most of the time it doesn't pay off in any way other
than warm fuzzy feeling. When it does, it does, that is not being
disputed here.


>that an optimization on Hutch's machine isn't as valid on your machine
>should prove to be no surprise here. It's one of the main reasons I
>quit "counting cycles" when the Pentium first arrived -- there's no
>sense in in anymore.

The point is that it doesn't make any other difference than neglible,
if you feel that assembly is a good idea for neglible performance
increase, I don't want to agree with that stance being a particularly
good idea. SInce that is the opinion you are opposing here.


>assembly code. How many people, for example, will find the C++ strlen
>function you've written to be any more understandable than the assembly
>version (from an algorithmic point of view, obviously)?

You are asking a quantity out of undefined set, which is one way to
make a point, if I knew you better I might know what's happening here.
No smiley, check.

>associated with them. Even in plain C, you get performance problems
>when people do things like:
>
>strcpy( a, b );
>strcat( a, c );
>strcat( a, d );

Context specific. No matter what you do, how fast you do, it can turn
out to be a performance problem.

>Precisely my point. The optimizations are not portable. For this
>particular example, you're limited to 32-bit processors.

Application using this library is portable to platforms the library is
ported to, portable does not imply or equal universal. This is a useful
feature, I would say that the C++ code is MORE portable than the x86
(MASM!) specific assembly function.

>IOW, the "trick" isn't portable and you're suffering from some of the
>same problems as assembly language.

As does everyone else, who are writing portable code will face.


>> I would surmise the code is order of magnitude more useful than x86
>> specific assembly snip.
>
>By what reasoning?

By the reasoning that the snip only works with x86 clone, compiles only
with MASM and is generally only useful in WIndows software. It does not
make the snip useless, but C++ code which compiles to verbatim same
binary and also supports large number of OTHER platforms could be
reasoned to be "more useful", maybe the word "order" was a red flag for
you, I shall remove it from front of your eyes.


>Given that about 90% of the world's computers today are x86 CPUs, I
>don't see how having the code in portable C++ is going to make it an
>order of magnitude more useful. Certainly we can find *some* people

Sourcecode is useful only for software developers, x86 constitures a
large number of customer base for software developers but there are
uses for other platforms aswell and that is where the "more useful" (<-
revised!) comes into effect.

>I don't question your claim; from a mathematical perspective I'm sure
>we could find a group of people amongst whom the need to have a
>portable strlen function that compiles on 10 different 32-bit (non-x86)
>processors is important, but...

That is rich, you are consistently ignoring my stance on this issue: I
do not think optimized strlen() is very useful at all. I don't expect
anyone else to find such a thing useful either.

I am merely saying that A > B, that C++ version which produces
identical binary to compared to version B, which is single platform
single assembler only code is MORE useful.

The rest is your extrapolation, let's clarify. I never said such "group
of people" is existing or how many such groups of people exist or
anything to that effect. You are plain malicious, simple as that.

>When you look at the number of people (end users) who will actually
>benefit from the code, however, it becomes real clear that the choice
>of HLL or x86 assembly is *mostly* irrelevant because most end-users
>are running x86 boxes.

Ofcourse, who said it weren't?


>isn't *always* better with one example, buy you cannot make a claim
>that there is no need to use assembly language on the basis of one
>example.

So what, I didn't make a claim that there is no need to use assembly
language in general. I claim that in this case it doesn't bring
anything substential into the solution.


>And you're assuming that Hutch got it right? That his example is the
>absolute pinnacle of what can be done in assembly?

I am not assuming such a thing. I am assuming that until he provides us
with something better that is the best _he_ can come up with in
assembly, or rather, what dr. Fog does come up with.


>That will probably run slower than the output of a good compiler for
>the above C code. Yes, scasb is *that* bad.

Yes, it is indeed.


>> Labourous and error prone process.
>Changing the subject?

Where you get that notion from? Doing register allocation and spilling
by hand IS laborous among other things, this is stuff compiler does in
fraction of the time thus saving time and money.


>And sometimes the compiler is brilliant when doing this, and sometimes
>it is real bone-headed. Your point?

That it isn't laborous and error prone..?


>Again, we're back to the argument of "this makes life so much easier
>for the programmer" rather than "the compiler does as good a job of
>this as the programmer could do himself."

I didn't make such generalized claim, sorry, only one that did present
that argument here is you.

I am saying that the C++ code compiled with Visual C++ 8.1 Beta 2
produces the precisely the same innerloop as the assembly code it was
being compared with. That is not what you claim I am "presenting as
argument".


>Sorry, you've lost me along the road somewhere. Perhaps you could be
>more articulate. It really seems to me that all you've done here is
>switch from "compilers produce code as good as humans do" to "it isn't
>cost-effective for humans to write code this way, so we live with what
>the compilers produce." A very different argument. But for some reason,

I haven't done such a thing. What I wrote originally is not what you
present it to be, the later posts are responses to ongoing discussion
adding to what is being discussed, mainly, how I see thing being under
discussion.

You bet it is a very different argument: it is mine, the earlier one
was yours presented as mine.


>that's where this argument always winds up. I guess that means we've
>reached the end of the debate.

Hitler?


>Well, maybe that's the difference between us. You see, I've got about
>25 years' experience as a professional programmer and I've worked both
>in the times when assembly was mandatory (to get any kind of
>performance at all) and I've been around during the past 15 years when

z80 assembly was the first programming language I learned, so what?

>these languages are good for. OTOH, I don't go around claiming that
>there is no reason to use assembly because compilers today are as good
>as humans. I may very well say that it makes *economic* sense to use

Neither do I. It is different to say that using assembly for a
specific, well defined task rather than in general.


>code efficiently in C. If you *really* want to debunk the myth that
>assembly has no advantage over HLLs, you need to move beyond strlen.

I don't nor intend to do that, and I didn't either. You have got this
idea into your head, because, you think you know me, or "my kind".

You might want to read the FIRST reply to the original poster, that was
written by me. E-V-E-R-Y-T-H-I-N-G you accuse me of and "correct" with
your post, was already said there. Store string length. Don't optimize
this, it doesn't matter.

This ongoing discussion is replies to your criticism over points that
were covered already earlier.


>trivial strlen function (byte at a time) will outperform the craziness
>embodied in the examples in this thread, because of the intrinsic
>overhead.

The overhead is alignment, which costs: -,-,+,&

The alignment "innerloop" is virtually same as the trivial strlen()
innerloop, if we want the short strings < 10 to go with the less
overhead path we can add 8 into the alignment count to force that code
being ran for the first 1 to 11 characters, this will eliminate the
overhead at the end which is far greater with multiple branches.

Four arithmetic operations overhead only for the cheap cases, I could
live with that if it was important issue.


> This is one reason why I argue that xstrlen is a ridiculous
>example.

It's only purpose is to be compared to the x86 assembly strlen() in
context of this thread, it produces identical code for the most time
critical sections so it works more than well for the discussion that
was going on before you came along. The one I am having with you is
about Philosophy of Programming and Optimization or somesuch, or is it
maybe about Putting Jukka In His Place? ;-)


>So when Hutch talks about saving all the function setup and tear-down
>code, this is not an insignificant matter. It reduces the overhead of
>the function call, thus vastly improving performance for small strings
>(which this older research suggests is a common situation). Now the

I have MASM, I *link* not compile with __asm {} block within the c++
sourcecode, I don't do that if it can be avoided. That is taken into
consideration when I do the timings, the C++ code is as presented, too.


>Oh, I've read it. That's not what you said earlier. But I'll allow you
>to back out of that gracefully. This is, after all, USENET and we have
>to allow for considerable "unstateds" and "misreads".

Alright, so what I said earlier that is relevant to that outburst? What
opinion or statement, or claim I reversed or what ever it is you seem
to think that I did, I don't follow you.


>Amazing, isn't it? Something so *basic* trips up 99% of the program out
>there. Exactly the point I'm making. You won't see mistakes like this
>made in a typical assembly program.

I don't quite follow you, the question that springs to mind is WHY you
are making that point.

There is no substitute knowing what you are doing in either language,
so?


>And when we look in your code, we'll never see an example of this,
>right?

Depends on what you are looking for.


>As in the way you've written xstrlen.

What's the unique characteristic in xstrlen() I should be looking for?


> they would expect it to be written that way.

You still didn't explain what you mean "that way"


>As for insulting, please check your own post. There are a few too many
>profanities and inferences on your part for you to be able to play this
>card here.

I'm not playing any card. I'm writing what I think, how's that compute?


> That makes us even. I don't care what I think about you either :-)

So I assume you didn't verify what I wrote, my conversation prediction
logic seems to br working flawlessly.


>Good for you. You escaped the problems of our industry over the past
>four years. But discussions of your experience and how long you've been

You referring to some situation in USA? I wouldn't know about that,
because I don't care.


>Again, one example of idiocy does not imply that all attempts to write
>fast code are worthless. And you never know -- It could turn out that
>this person you're talking about has a real-time foreground application

I happen to know precisely what he was doing for reasons outside the
scope of this discussion.


>And, in your experience you call C an assembly language. That speaks
>volumes about your experience, I'm afraid.

"The way I see it is that C is portable assembler, which makes it a
jack
of all trades but master of none."

The language syntax is crafted to be close to hardware, that's where
this point of view originates from-- that is how I "see" the C
programming language. That is why it is so trivial for me to write C
code while thinking in assembly. It is just plain trivial.

If you think that's funny, go ahead and laugh my ego can take it.


>No, I'm simply pointing out that this thread is second only to the
>memcpy threads that pop up. What this would have to do with your
>intelligence is beyond me.

So far, you have not said or teached me ANYTHING I don't already know.
And I don't expect to have done neither to you either.


>FAQ #2: Here's my strlen function, how can I make it faster.
>FAQ #3: Aren't compilers as good at generating machine code as human

Go ahead and write the FAQ then.

.

Relevant Pages

  • Re: HLA StdLib2 criticism
    ... HLC.EXE with an already existing C compiler and calls it HLC system. ... Suppose someone creates a new language and calls it "High Level ... Assembler" (HLA). ...
    (alt.lang.asm)
  • Re: HLA StdLib2 criticism
    ... Assembler" (HLA). ... Can that person call this the "FASM language?" ... but also of course not he can call it an assembler ... Therefore HLC.EXE can't be called a compiler. ...
    (alt.lang.asm)
  • Re: Why no C++ in Windows itself?
    ... >Do you mean that C is faster executing? ... I wasn't trying to start a language war. ... compiled by a C++ compiler). ... you have to "deobjectify" any data you want to access from assembler ...
    (microsoft.public.windowsxp.general)
  • Re: Why no C++ in Windows itself?
    ... >Do you mean that C is faster executing? ... I wasn't trying to start a language war. ... compiled by a C++ compiler). ... you have to "deobjectify" any data you want to access from assembler ...
    (microsoft.public.vc.language)
  • Re: Why no C++ in Windows itself?
    ... >Do you mean that C is faster executing? ... I wasn't trying to start a language war. ... compiled by a C++ compiler). ... you have to "deobjectify" any data you want to access from assembler ...
    (microsoft.public.dotnet.general)