Errors, bugs, questions - page 1573

[Alexey Navoykov]

Anton Zverev:

A 100Kb source project compiles in less than a second on 1325 build. Solid OOP, lots of virtual functions and overloads, templates, pointers, const modifier (wherever possible). No DLL and OpenCL.

I would like to find out the reason for your lags. Maybe it's const that helps the compiler to optimize quickly. I have never encountered lags. Please provide me the source code from kodobase which is slowing down.

Well, 100 Kb is too much, isn't it? I've got almost 1 Mbyte. All the same stuff you've got is present here plus a lot of macros. Except that const isn't set everywhere. But that's no reason for such crazy lags, especially since everything compiled almost instantly in build 1159.

I cannot test in build 1325 because the project doesn't compile at all and a whole bunch of bugs appear, all in the evenings. Comrade A100 reported a whole bunch of bugs in the new build too. I've got no desire to waste my time on poking around these bugs, I will wait until they release the working build.

That is why I told you about the lags referring to build 1241. If you have the opportunity to test it, try to compare it with the latest build. But I doubt that the new build can significantly speed up. Quite the contrary, MT developers do not really care about the compilation speed, they only want to squeeze additional nanoseconds out of the runtime in order to then make marketing claims about the speed of MQL programs being comparable with C++ (though only on some abstract examples).As far as I understand, they do not care about the optimization efficiency, i.e. whether the game is worth the cost.

I'll try to search for source code in the code base but not necessarily that I will manage to find a similar one. It must be a large project, while there mostly small projects are openly available.

[Alexey Navoykov]

Renat Fatkhullin:

Most likely he has giant functions in the form of spools of text.

The optimizer has to make a lot of passes at such code fragments improving the code over and over again. It is enough to reduce the size of functions for the optimizer to dramatically increase the speed.

Well, you must switch to the latest builds since we are constantly improving both quality and speed in them.

No giant functions. 150 lines at the most (or is it considered gigantic?). And if you think about it this way, why does the size of a function have to do with the compiler trying a bunch of small functions? Suppose it goes through the large function 10 times.So I break it up into 5 small ones and it goes through each of them 2 times. We get the same result. So, the whole amount of code is important, right? But even if the result speeds up a bit when breaking up big functions, so what? We are talking about a 10 (!) times slower compilation.

It's clear that you want to speed up execution of the program as much as possible, so you make a lot of passes trying to improve something. And the further you complicate the language, the longer these passes will be, which will consume the programmer's time. And there is a natural question about efficiency of all this. How much faster is the program speeded up by your optimization compared to the programmer's idle time waiting for optimization to be completed?

Of course, you may try to look for some compromises but it's much more efficient to make different compilation modes as I wrote above. The program release with all the optimizations is needed only at the very end - 99% of programmers' time is spent on writing and debugging the code when they don't need your optimizations at all.

[Vasiliy Sokolov]

Alexey Navoykov:

How long will it go on that every time you update the build, the code stops compiling! And if it does compile, it doesn't work the same way as before (which is even worse). Who needs such a programming language?

...

I don't know what you mean. I have several very complex projects in MQL with more than 20 000 000 lines of code. The new builds may be compiled in no time at all. There have been only two issues during the entire time. Once because of my bug and the other time due to the developer's bug.

[Vasiliy Sokolov]

Alexey Navoykov:

A maximum of 150 lines

This is a very large and incorrect function.

[Alexey Navoykov]

Vasiliy Sokolov:
I don't know what you mean. I have several very complex projects in MQL with code size of over 20 000 000 lines. The new builds are compiled in no time at all. There have been only two issues during the entire time. Once because of my bug and the other time due to the developer's bug.

Well, then you're lucky. Your code doesn't have any of the constructs in my code. What's so strange about that?

Flip through the man above a couple of pages and there he also caught a lot of bugs in the new build, some of which are hard to catch. Do you think he was looking for them on purpose?

[Renat Fatkhullin]

Alexey Navoykov:

Well, then you're lucky. Your code doesn't have any of the constructs in my code. What's so strange about that?

Flip through a couple of pages above, the man there also caught a bunch of bugs in the new build, some of which are hard to catch. Do you think he was looking for them on purpose?

Demonstrate an example of a replayable brake, please.

Unfortunately, so far you are making unsubstantiated statements, including direct attacks on the developers.

You are wrong about the size of functions and overall size of the program. The size of individual functions directly and non-linearly influences the optimization of each particular function due to both increase of the syntax tree and multi-pass optimization. Smaller functions are optimized on the fly.

[Vasiliy Sokolov]

Alexey Navoykov:

Well, then you're lucky. Your code doesn't have any of the constructs in my code. What's so strange about that?

Flip through the pages above, the man there also caught a bunch of bugs in the new build, some of which are hard to catch. Do you think he was looking for them on purpose?

1) I wonder what constructs you used that my code doesn't contain them. The size of my code is many thousands of lines and your constructs don't exist? Surely it must be something super unique?

2) Actually, there was an internal commpiler error in the previous build which occurs when classes link to each other. It was a bug of the developers but they fixed it. I cannot recall any other errors.

[A100]

Vasiliy Sokolov:

2) In fact, the previous build actually had an internal commpiler error that occurs when classes link to each other. This is a bug in the development team, but it was fixed. I cannot recall any other errors.

https://www.mql5.com/ru/forum/1111/page1591#comment_2463820

And where is the mutual linking of classes to each other?

I have simplified it even more here for your convenience in searching for mutual references and understanding what constructs you are not using

[Vasiliy Sokolov]

A100:

https://www.mql5.com/ru/forum/1111/page1591#comment_2463820

And where is the mutual reference of classes to each other here?

Simplified it even further here, for your ease of searching for reciprocal references and understanding which constructs you are not using

You are doing reverse-engineering. The work is useful to improve the compiler, but in terms of practical programming is not applicable. I don't know a single programmer who would use the code you've cited in practice:

//+------------------------------------------------------------------+
//|                                                      Test116.mq5 |
//|                                                                  |
//+------------------------------------------------------------------+
bool is( const string type, bool )
{
        return ( type == "1" || type == "2" || type == "3" || type == NULL );
}
bool _is( string type ) { return is( type, false ); }
//+------------------------------------------------------------------+
template<typename T>
bool __is( T ) { return _is( typename( T )); }
//+------------------------------------------------------------------+
#define  IS( T )         __is( T(0))
//+------------------------------------------------------------------+
template<typename T>
int sh( T t )
{
        T tt = 0x1;
        for ( int i = 0; i < 4; i++, tt <<= 1 )
                if ( (t & tt) == tt )
                        return i;
        return -1;
}
//+------------------------------------------------------------------+
class D { public:
template<typename T1, typename T2>                                     
                        T2                              g( T1 t1, T2, int sh = -1 ); 
};                                                                     
template<typename T1, typename T2>                                     
T2 D::g( T1 t1, T2, int sh )
{                                                                      
        sh = sh( t1 );                                   
        T2 t2 = T2(t1) >> 1;
        return (sh( t1 ) & sh) == sh( t1 ) && IS( T2 ) ? 1 : 0;
}                                                                      
//+------------------------------------------------------------------+
class M : public D {
        virtual void f1() { g( 0, 0 ); }
};
//+------------------------------------------------------------------+
class A {};
void g( A* ) export {}
class B { public:
        void h() { A a; g( &a ); }
};
class C { public:
        void f() {}
};
void OnStart()
{
        C c;
        c.f();
}
//+------------------------------------------------------------------+

[Alexey Navoykov]

Renat Fatkhullin:

Demonstrate an example of a reproducible brake, please.

Unfortunately, so far you are making unsubstantiated statements, including direct attacks on the developers...

I told you that this is a large project, the total size of all the source code is about 1 Mb. How can you demonstrate the brakes? Send all the code or what? You understand that this is impossible. And compilation of individual pieces, of course, goes much faster.

And what do you mean by "unsubstantiated claims"? That your optimizing compiler is much slower? And that you don't care much about it? What's unsubstantiated here?

Here's a link to a discussion from October of last year when you just introduced this global optimization: https://www.mql5.com/ru/forum/1111/page1424#comment_1981722

The man writes:

Another code - note the time - it must have gone up by a factor of 20

And then you respond:

This is a new optimizing compiler for MQL5 (it's absent in MQL4).

You have to pay for better target code with longer compilation time.

And then there are several more people, including myself, who also complained about slow compilation. But your responses seem to suggest that you care only about "better quality target code" and some mythical "speed boost from 2 to 10 times", although I haven't seen such speed boosts in real working projects.

As I told above, I wasn't able to test it on the latest build (April 22nd) because I had some bugs during compilation. But I assume that the compilation speed is the same slow there, as you've never announced acceleration of the compiler in the new build.