Declaring variables behind the loop or inside the loop? - page 10

[Alexey Navoykov]

Vict:

time = 1018
sum = 894782460
time = 371
sum = 894782460

I don't know why, but µl overtakes it (and more intricate rand() variants as well).

And for me it's obvious - take it out of the loop.

Yes, you're right, I tried it in VS too and for some reason it didn't optimize at all, although such a simple variant seems... In fact it comes down to this:

char *st = new char[23];
memcpy(st, "12345678qwertyuioasdfgh", 23);
sum += st[i % 23];
delete[] st;

[Alexey Volchanskiy]

Alexey Navoykov:

Yes, you're right, I've tried it in VS too - for some reason it's not optimised in the slightest, although such a simple option, it would seem... In essence it comes down to this:

Are you sure you enabled all optimization in project settings? In strange cases I switch on generation of assembly listing and look through it, it's very instructive.

[Alexey Navoykov]

I decided to test it in C# too for the sake of curiosity. Not only the results are nearly the same in speed, but they also work much faster than C++.

public class Program
{
  public static void Main()
    {
        int count = (int)10 e6;

        {
            var watch = System.Diagnostics.Stopwatch.StartNew();
            int sum = 0;
            for (int i = 0; i < count; i++)
            {
                string st;
                st = "12345678qwertyuioasdfgh";
                sum += st[i % 23];
            }
            Console.WriteLine("Sum: {0}, Time: {1} ms", sum, watch.ElapsedMilliseconds);
        }

        {
            var watch = System.Diagnostics.Stopwatch.StartNew();
            int sum = 0;
            string st;
            for (int i = 0; i < count; i++)
            {
                st = "12345678qwertyuioasdfgh";
                sum += st[i % 23];
            }
            Console.WriteLine("Sum: {0}, Time: {1} ms", sum, watch.ElapsedMilliseconds);
        }

        Console.ReadKey();
    }
}

Results:

Sum: 894782460, Time: 69 ms.

Sum: 894782460, Time: 56 ms

And here is an analogue in C++:

Sum: 894782460, Time: 2947 ms

Sum: 894782460, Time: 684 ms

I test it in VS 2019.All optimization is enabled .

Screw such a C++.)

p.s. Results in C# vary pleasantly from test to test, but on the average both variants are equally fast.

[[Deleted]]

Alexey Navoykov

You need to understand the reasons for the brakes first. I've done a little digging, and everything is inline except the call

0x41a727 <main()+119>   callq  0x48e1a0 <_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceEmmPKcm>

which sits in libstdc++. That is, on the background of almost naked loop the bottleneck is function calls themselves (and there are a couple of calls from ...replaceEmmPKcm too). The compiler can optimize within a single translation unit. You can try to use LTO (link time optimization), ie this allows to optimize at linking stage. But I have not used it, I will not do it now. Well, there's nothing particularly complicated - pass to compiler/linker -flto option (but I have some plugin missing), too lazy to figure it out + may have to rebuild libstdc++.

How it will be with code optimisation in connection with forthcoming modules screwing (since C++20) ? I don't know, you can try in vs, though everything is raw and experimentalhttps://habr.com/en/company/pvs-studio/blog/328482/

c++'u will be missed )).

[Alexey Volchanskiy]

Alexey Navoykov:

For the sake of interest, I decided to test in C# as well. Not only are the results almost the same in terms of speed, but they also work an order of magnitude faster than C++.

Results:

Sum: 894782460, Time: 69 ms

Sum: 894782460, Time: 56 ms

And here is an analogue in C++:

Sum: 894782460, Time: 2947 ms.

Sum: 894782460, Time: 684 ms

I test it in VS 2019.All optimization is enabled .

Screw such a C++.)

p.s. Results in C# fluctuate significantly from test to test, but on the average both variants are equal in speed.

Br-r-r-r-r, no way! Sharp always beat the pure pros by a factor of two, you put the project out plz.

[prostotrader]

Little kids :)

They've stretched the toy to 10 pages...

[Alexey Navoykov]

Vict:

Here we should understand the reasons of slowness at first. I did a little digging and everything is inline except for the call

which sits in libstdc++.

So it seems to have figured out that it allocates and deletes memory every time even in this case:

char *str = new char[23];
...
delete str;

By the way, I may have given wrong results last time. It was most likely in x86 mode. Now I am testing in x64 mode and the results by C++ are much better:

1) ~ 2000 msec

2) ~ 200 ms (it is 3 times faster).

Although I also updated Studio to the latest version, it must have influenced it too since even x86 is faster now than previous tests.

Well, now C++ is not so shamefully lagging behind Sharp. Only by 3 times approximately )

[[Deleted]]

Alexey Navoykov:

So it seems to have figured out that it allocates and deletes memory every time, even in this case:

By the way, I may have given wrong results last time. It was most likely in x86 mode. Now I am testing in x64 mode and the results by C++ are much better:

1) ~ 2000 msec

2) ~ 200 ms (it is 3 times faster).

Although I also updated Studio to the latest version, it must have influenced it too since even x86 is faster now than previous tests.

Well, now C++ is not so shamefully losing to Sharp. Only by 3 times approximately )

you don't understand, that's not what I mean. In general, the test is a toy - a bare loop with no payload. I was trying to tell you that losses on function calls which cannot get inline. Better test plus modules, more interesting results there, although it may be still undeveloped.

[Alexey Navoykov]

Alexey Volchanskiy:

Brrr-r-rr, no way! Sharp has always been twice as good as clean pluses, you put the project out plz.

[[Deleted]]

Vict:
Better test the plus modules, the results are more interesting there, although they may still be undocumented.

I looked it up, it turns out that no https://en.cppreference.com/w/cpp/compiler_support compiler has finished the modules, so there's nothing to see.