Re: Not normal for the same program to be faster in C# than in C++ [Visual Studio 2019]

gah4 <>
Sun, 8 Aug 2021 12:38:51 -0700 (PDT)

          From comp.compilers

Related articles
| List of all articles for this month |

From: gah4 <>
Newsgroups: comp.compilers
Date: Sun, 8 Aug 2021 12:38:51 -0700 (PDT)
Organization: Compilers Central
References: 21-08-001 21-08-003 21-08-005
Injection-Info:; posting-host=""; logging-data="14123"; mail-complaints-to=""
Keywords: performance, comment
Posted-Date: 08 Aug 2021 16:01:54 EDT
In-Reply-To: 21-08-005

On Sunday, August 8, 2021 at 8:14:17 AM UTC-7, Dmitry A. Kazakov wrote:


> P.S. Optimizations is a usual suspect of ruining benchmark measures.

Yes. But in this case, one might want to include some optimizations.

Note, though, that a good optimizer could optimize out all the loops, as no
output depends on them. Some programs I know output the total number
of primes found, which stops that from happening.

Also, compilers can do some calculations at compile time. I don't expect
it for this, but that does ruin some benchmarks. There are stories of complicated
benchmarks being done entirely at compile time, except for output of the result.

I would have used a j += i loop. Not that multiply is that slow on modern processors,
but that it a big part of the loop. One compiler might optimize that one for you.

One might store the array as bits (8 bool/byte), the other as bytes. It isn't so
obvious which one is faster, but often the 1 bool/byte is faster, until you run out
of real memory.

How much real memory do you have? And the speed might depend in complicated
ways on the memory management system.

And note that you aren't comparing languages, but two compilers implementing
those languages (which is why it goes here).
[In this case, the documentation says they both allocate a byte for each bool but the other
stuff is all possible. Also remember C++ is a traditional compiler, while C# is bytecode and JIT. -John]

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.