Re: 12 Misconceptions

hutch-- wrote:
smile,

Oh look mommy, once again hutch ignored the fact that VC++ code
generation is 3.5x better than PowerBASIC, coming with binaries *as
well as source* for both the PowerBASIC and the VC++ example:
http://f0dder.reteam.org/misc/pb_c_circle.zip . Could this be
because it's inconvenient to him?

Did you write it yourself or did you pick a slow example to benchmark
against,

Brad wrote the PowerBASIC example, I did a direct conversion of the
algorithm to C++.

just like Jibz did with another piece of learners code from the PB web
site ?

So you're saying that PowerBASIC's built-in "ArraySort" (or whatever) is a
slow piece of learners code? Because that *is* what Jibz tested against,
isn't it? :)


Why don't you take up the example you have with Brad, I did not write it
so I cannot help you there.

That's what I did :) - http://f0dder.reteam.org/misc/pb_c_circle.zip . If he
posted any other example, you'll have to refresh my memory.


Why did you refuse to produce the binaries against the ones I posted
years ago ? Afraid of being shown up again by a low level basic
compiler ?

Because I'm not interested in benchmarking C++ code generation against
handwritten assembly. As I've said countless times, that kind of test has
nothing to do with benchmarking compiler code generation.


He also doesn't have much to say on PowerBASIC's lack of obj and lib
file linking support; could this be an inconvenience as well, since
missing lib support is one of his main attack vectors against
RosASM? Too bad this also means PowerBASIC is limited to inline
assembly, where VC++ has both inline assembly and the ability to
link with masm, fasm, nasm, goasm, poasm, ... external modules, if
need be.

Who cares when it is capable of directly porting MASM mnemonic code
with only minor notation difference.

"Who cares?" - better stop harping at Betov for not including static library
and .obj file support, then :). And I assume that PowerBASIC doesn't support
MASM macros, structure definitions, etc...


When does he noise stop and the binaries start ? The binaries were
posted years ago and you have still not delivered.

http://f0dder.reteam.org/misc/pb_c_circle.zip .


You wanted a "hand-written
assembly vs. C++ compiler" with your binaries, which is hardly
interesting,

Native code from a PowerBASIC compiler is fortunately not written
according to the gospel according to f0dder. Even worse, I can use
just about ANY MASM code any time I need it due to the portability
between industry standard Intel notation assembler.

Well duh, "I can use just about ANY MASM code any time I need it" as well in
inline asm in MSVC, but that doesn't make it C++ code, just as little as
inline asm in PowerBASIC is BASIC code.


Why won't you post your binaries f0dder, not willing to take on a
humble basic compiler in native code output ?

If you write something in pure PowerBASIC without inline assembly and
publish the source so I can see you're not cheating, I'll write the same
algorithm in C++ without inline assembly, and the code generation of the
compilers can be compared head-to-head.

That's the only way it makes sense to compare them in the light of my claim,
namely that "PowerBASIC code generation sucks".


I have not untangled the entire mess yet as it is uncommented code with
many un-named variables with a number of data type errors but with the
existing code that f0dder has made available complete with Brad's code
I find Brad's second test consistently about 5% faster than the C code
where you have a direct FOR loop comparison on the Northwood core PIV I
am testing on. So much for the three times faster.

Heh, you're comparing the Arc() version, not the native code. Try csieve.exe
vs. CircleSieve2.exe, and compare the "C version" vs "PB SUMMATION TEST".

I just did a more proper comparison: "warming up" CPUs before test (*very*
important for power-saving CPUs), run each test 10 times, pick smallest
value, and here's the results. So not 3.5x faster as I originally claimed...
Shows how important warm-up and repeated tests are.

==== AMD64x2 4400+ (2.21GHz) ================
PB version: 8117328
C++ version: 3866057
C++ code is a factor 2,0996 faster.

==== Celeron-M 1.5GHz =======================
PB version: 18089
C++ version: 10358
C++ code is a factor 1,7464 faster.

==== Turion64 1.79 Ghz ML-32 ================
PB version: 33281
C++ version: 18710
C++ code is a factor 1,7788 faster.

==== Pentium4 2.53 Ghz ======================
PB version: 28400
C++ version: 18096
C++ code is a factor 1,5694 faster.

==== Pentium3 750 MHz =======================
PB version: 142526
C++ version: 129561
C++ code is a factor 1,1001 faster.


And, as silly as it is, on my AMD64x2 the best result of 10 runs of the
WinAPI Arc() function:
C++: 5013908
PB: 5344740
C++ code is a factor 1,0659 faster.


.

Relevant Pages

  • compiler profiling
    ... I am trying to compare the performance of MS compiler with ARM's rvct ... Is some optimization done by MS assembler? ...
    (microsoft.public.windowsce.embedded.vc)
  • Re: What micros do you actually hate to work with?
    ... with less than tiny asm ... hassle to work with 32 bit longs in assembler for an 8 bit uP, ... Microchip's C compiler tools and their assembly under MPLAB. ... is that other programmers for C are easier to find. ...
    (comp.arch.embedded)
  • Re: The Promise of Forth
    ... Declare variables, declare locals, let the compiler do the work ... Forth could be considered the assembler for a simplified virtual ... If you use locals then you have to initialise them each time. ... there are likely to be libraries that could be profitably used within ...
    (comp.lang.forth)
  • 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: the quality of assembly language code
    ... Intel's compiler is supposed to ... I have found that I prefer 'C' and assembler roughly in inverse ... >> code than human beings writing raw assembly language. ... > assembly programmers and compilers. ...
    (comp.lang.asm.x86)