Need for Speed - C++ versus Assembly Language

[nidud]

deleted

[jj2007]

You should add a test for ML.exe ;)

[nidud]

deleted

[jj2007]

Yep, this is what I meant

RichMasm assembles with asmc in less than 600 ms on my i5, as compared to 680 for JWasm and 1230 for ML :t

(Wow, that thread was long  ::))

[Raistlin]

I have a vested interest in this topic that continually seems to pop up from time to time (I wonder why?)

On the scholarly literature I've been able to accumulate the following conclusions have been drawn:
1) Handwritten assembly - properly done (the REAL POINT) - will ALWAYS out perform the compiler (ANY) for the same algorithm
2) Loop structures (unrolling) are a critical factor that need to target hardware L1 cache hierarchies - compilers are really bad at this
3) Data locality cannot be easily predicted by compiler heuristic transforms - and thus will always produce sub-optimal code
4) Compilers are really BAD at generating SIMD/AVX code that takes full advantage of the instruction set
    - in one large study of compilers, published in 2013, it was found that on average compilers miss 60% of the opportunity vectorize
     

[aw27]

but there are those PUSH-POPs, there is the shl which is slow.

You appear to know a lot about these things.

If I'm not mistaken lea is slower too and could be exchanged to mov - offset (can that be done in 64?).

You never heard that lea is an handy fast arithmetic calculator? I am using it like that, not to load an effective memory address.

What I'm saying is that a guy like Marinus, Johen and others could make this asm run faster than the C++ one. In this case, the point of the article looses ground.

I am also expecting that either of them or anyone else will restore my faith in a fair World. Compiler produced spaghetthi code should not perform better than well written hand made ASM.

[jj2007]

... will restore my faith in a fair World. Compiler produced spaghetthi code should not perform better than well written hand made ASM.

Your article clearly shows that a C++ compiler can beat assembler.

Your article is good, really. And it shows that a compiler can beat us. It does not prove, though, that it will beat us all the time. How easy will it be to write an article that, on the basis of one particular case, "proves" that the compiler can be beaten? Let's not be too superficial...

P.S.:

Continuing the saga on Matrix Transposing...
This is a solution for transposing matrixes of any size, squared or not. It supports as well small matrixes or matrixes with less than 4 rows or 4 columns.

Which compiler produced that ultra-fast assembler code you are showing there...?

[LordAdef]

olá!

You appear to know a lot about these things.

 Not really. I'm fairly new to asm myself. but I've been doing a really intensive training and learning from whatever source I can. As I'm currently writing I prog in asm myself, I happened to benchmark shl and can confirm it's a rather slow option, if you are aiming for speed.

You never heard that lea is an handy fast arithmetic calculator? I am using it like that, not to load an effective memory address.

I do! But I confess I only passed my eyes on the lea instructions. Sorry. Nevertheless, it's a place to check the clock and maybe see if it's the fastest option.

I'm very curious to see how you and these guys can optimize this algo and how asm will react afterwards.

there is also a suggestion from Hutch I read sometime ago one should take into consideration: building the asm side in a dedicated ide, not in VS.

[LordAdef]

Which compiler produced that ultra-fast assembler code you are showing there...?

You wont like the answer..

[aw27]

How easy will it be to write an article that, on the basis of one particular case, "proves" that the compiler can be beaten? Let's not be too superficial...

If you have a good case it will be easy. This is not a superficial answer.

Which compiler produced that ultra-fast assembler code you are showing there...?

Did I mention it was ultrafast? But you can always improve and show the outcome.

[aw27]

I happened to benchmark shl and can confirm it's a rather slow option, if you are aiming for speed.

Use "mul" instead, and show the benchmarks.

[aw27]

Which compiler produced that ultra-fast assembler code you are showing there...?

You wont like the answer..

Probably, I will start disregarding your provocations.

[jj2007]

Did I mention it was ultrafast? But you can always improve and show the outcome.

The point is that, as far as I know, you hand-coded it in assembler ;)

I happened to benchmark shl and can confirm it's a rather slow option, if you are aiming for speed.

Use "mul" instead, and show the benchmarks.

http://masm32.com/board/index.php?topic=6092.msg64629#msg64629

[aw27]

Did I mention it was ultrafast? But you can always improve and show the outcome.

The point is that, as far as I know, you hand-coded it in assembler. Right?

Ah, "assembler is fun" as you say under your logo and I never though about doing it in C/C++. I don't know whether it would be faster or not in this case (probably, not in this case).

[LordAdef]

Which compiler produced that ultra-fast assembler code you are showing there...?

You wont like the answer..

Probably, I will start disregarding your provocations.

It's not a provocation aw27, it's me actually teasing JJ!!!  He is Microsoft's enemy number 1. I never did anything to you... Why is that?