Author Topic: Need for Speed - C++ versus Assembly Language  (Read 3197 times)

nidud

  • Member
  • *****
  • Posts: 1411
    • https://github.com/nidud/asmc
Re: Need for Speed - C++ versus Assembly Language
« Reply #15 on: April 20, 2017, 06:44:48 AM »
 :biggrin:

A simple test case could be Asmc versus (H)JWasm where a few time-critical functions are converted to assembly in the former. If this theory is correct you should then be able to compile a faster version of latter by just adding some switches and use the latest version of VS to build it.

for %%q in (\masm32\m32lib\*.asm) do echo %%q >> ml.rsp
Code: [Select]
3775 ClockTicks: asmc.exe -c -q @ml.rsp
4680 ClockTicks: jwasm.exe -c -q @ml.rsp
6287 ClockTicks: hjwasm32.exe -c -q @ml.rsp
4680 ClockTicks: hjwasm64.exe -c -q @ml.rsp

jj2007

  • Member
  • *****
  • Posts: 7756
  • Assembler is fun ;-)
    • MasmBasic
Re: Need for Speed - C++ versus Assembly Language
« Reply #16 on: April 20, 2017, 08:00:20 AM »
You should add a test for ML.exe ;)

nidud

  • Member
  • *****
  • Posts: 1411
    • https://github.com/nidud/asmc

jj2007

  • Member
  • *****
  • Posts: 7756
  • Assembler is fun ;-)
    • MasmBasic
Re: Need for Speed - C++ versus Assembly Language
« Reply #18 on: April 20, 2017, 08:57:35 AM »
Yep, this is what I meant :biggrin:
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

  • Member
  • ***
  • Posts: 259
Re: Need for Speed - C++ versus Assembly Language
« Reply #19 on: April 20, 2017, 03:52:32 PM »
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

  • Member
  • ****
  • Posts: 855
  • Let's Make ASM Great Again!
Re: Need for Speed - C++ versus Assembly Language
« Reply #20 on: April 20, 2017, 05:50:38 PM »
but there are those PUSH-POPs, there is the shl which is slow.
You appear to know a lot about these things.

Quote
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.

Quote
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

  • Member
  • *****
  • Posts: 7756
  • Assembler is fun ;-)
    • MasmBasic
Re: Need for Speed - C++ versus Assembly Language
« Reply #21 on: April 20, 2017, 06:44:52 PM »
... 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

  • Member
  • ***
  • Posts: 264
Re: Need for Speed - C++ versus Assembly Language
« Reply #22 on: April 20, 2017, 06:56:13 PM »
olá!

Quote
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.

Quote
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

  • Member
  • ***
  • Posts: 264
Re: Need for Speed - C++ versus Assembly Language
« Reply #23 on: April 20, 2017, 07:01:20 PM »
Quote
Which compiler produced that ultra-fast assembler code you are showing there...?
You wont like the answer.. :badgrin:

aw27

  • Member
  • ****
  • Posts: 855
  • Let's Make ASM Great Again!
Re: Need for Speed - C++ versus Assembly Language
« Reply #24 on: April 20, 2017, 07:12:11 PM »
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

  • Member
  • ****
  • Posts: 855
  • Let's Make ASM Great Again!
Re: Need for Speed - C++ versus Assembly Language
« Reply #25 on: April 20, 2017, 07:15:26 PM »
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

  • Member
  • ****
  • Posts: 855
  • Let's Make ASM Great Again!
Re: Need for Speed - C++ versus Assembly Language
« Reply #26 on: April 20, 2017, 07:19:07 PM »
Quote
Which compiler produced that ultra-fast assembler code you are showing there...?
You wont like the answer.. :badgrin:
Probably, I will start disregarding your provocations.

jj2007

  • Member
  • *****
  • Posts: 7756
  • Assembler is fun ;-)
    • MasmBasic
Re: Need for Speed - C++ versus Assembly Language
« Reply #27 on: April 20, 2017, 07:20:21 PM »
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

  • Member
  • ****
  • Posts: 855
  • Let's Make ASM Great Again!
Re: Need for Speed - C++ versus Assembly Language
« Reply #28 on: April 20, 2017, 07:26:45 PM »
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

  • Member
  • ***
  • Posts: 264
Re: Need for Speed - C++ versus Assembly Language
« Reply #29 on: April 20, 2017, 07:30:08 PM »
Quote
Which compiler produced that ultra-fast assembler code you are showing there...?
You wont like the answer.. :badgrin:
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?