Ошибки, баги, вопросы - страница 1573

[Alexey Navoykov]

Anton Zverev:

Проект на 100Кб исходников компилируется меньше секунды на 1325 билде. Сплошной ООП, много виртуальных функций и перегрузок, шаблоны, указатели, модификатор const (везде, где только возможно). Без DLL и OpenCL.

 

Хотелось бы выяснить причину Ваших тормозов. Возможно, именно const помогает компилятору быстро оптимизировать. С тормозами ни разу не сталкивался. Приведите, пожалуйста, исходник из кодобазы, который тормозит.

Ну дык 100 кб - это ж разве много?  У меня почти мегабайт.    Присутствует всё то же, что и у вас.  Плюс к этому много макросов.   Только вот const проставлено не везде.  Но это не повод для таких сумасшедших тормозов.  Тем более что в билде 1159 всё компилировалось почти мгновенно.

В 1325 билде я протестировать не могу, поскольку там проект вообще не компилируется, возникает целая гора ошибок, причём на ровном месте.  Вон и товарищ A100 отписывался о куче появившихся багов в новом билде.   У меня нет желания впустую тратить своё время на ковыряние этих багов.  Подожду когда выпустят рабочий билд.

Поэтому сказанное мной про тормоза относилось к 1241 билду.  Если у вас есть возможность протестировать на нём, попробуйте сравнить с последним билдом.  Но я сомневаюсь, что в новом билде могли значительно ускорить. Скорее наоборот.  Ведь скорость компиляции мало заботит разработчиков МТ,  им бы только выжать дополнительные наносекунды в рантайме, чтоб потом делать маркетинговые заявления о быстродействии MQL программ, сравнимом с C++ (правда лишь на абстрактных примерах).   А об эффективности оптимизации не заморачиваются, как я понял.  Т.е. стоит ли овчинка выделки.

Поискать исходники в кодебазе - попробую, но не факт что удастся найти аналогичный.  Это ведь должен быть большой проект. А там в основном небольшие поделки выкладываются в свободный доступ.

[Alexey Navoykov]

Renat Fatkhullin:

Скорее всего у него гигантские функции в виде портянок текста.

На таких портянках оптимизатор вынужден делать много проходов, раз за разом улучшая код. Достаточно уменьшить размеры функций, чтобы скорость оптимизатора резко возросла.

Ну и на последние билды обязательно переходить, так как мы в них постоянно улучшаем и качество и скорость.

Гигантских функций нет.  Максимум в 150 строк (или это считается гигантской?).  Да и если так рассуждать, то при чём здесь размер функции, если компилятор с таким же успехом будет перебирать кучу маленьких функций?   Допустим большую функцию он пробегает 10 раз.   Ну разобью я её на 5 маленьких.  И каждая из них будет перебираться по 2 раза.  Получаем тот же результат.   Т.е. важен общий объём кода, так ведь?   Но пусть даже результат чуть ускорится от дробления больших функций, что с того?  Ведь речь идёт о торможении компиляции в 10 (!) раз. 

 Понятно ваше желание максимально ускорить выполнение программы, поэтому вы делаете кучу проходов в попытках улучшить что-нибудь.  И чем дальше вы будете усложнять язык, тем дольше будут выполняться эти проходы, отнимая время у программиста.  И тут закономерно встаёт вопрос об эффективности всего этого.  Насколько существенно ускорение программы от вашей оптимизации по сравнению с простоем программиста, ожидающего завершения оптимизации?

Можно конечно пытаться искать какие-то компромиссы, но гораздо эффективнее сделать разные режимы компиляции, о чём я писал выше.  Релиз программы со всем оптимизациями нужен только в самом конце.  А 99% времени программист тратит на написание и отладку кода,  когда ваши оптимизации ему даром не нужны. 

[Vasiliy Sokolov]

Alexey Navoykov:

Доколе ж это будет продолжаться, что после каждого обновления билда перестают компилироваться коды!  А если и компилируются, то начинают работать не так, как прежде (что ещё страшнее).  Кому нужен такой язык программирования?

...

Не понимаю о чем Вы. Имею несколько нереально сложных проектов на MQL с объемами кода более 20 000 тысяч строк кода. В новых билдах компилироуется на раз два. За все время только два раза проблемы были. Один раз из-за моего косяка, другой из-за косяка разработчика. 

[Vasiliy Sokolov]

Alexey Navoykov:

Максимум в 150 строк

Это очень большая и неправильная функция.

[Alexey Navoykov]

Vasiliy Sokolov:
Не понимаю о чем Вы. Имею несколько нереально сложных проектов на MQL с объемами кода более 20 000 тысяч строк кода. В новых билдах компилироуется на раз два. За все время только два раза проблемы были. Один раз из-за моего косяка, другой из-за косяка разработчика. 

Ну значит вы счастливчик. В вашем коде не встретились конструкции, имеющиеся в моём коде.  Что тут странного?

Пролистайте пару страниц выше, там человек тоже поймал кучу багов в новом билде, некоторые из которых трудноуловимые.  Думаете, он их нарочно выискивал?

[Renat Fatkhullin]

Alexey Navoykov:

Ну значит вы счастливчик. В вашем коде не встретились конструкции, имеющиеся в моём коде.  Что тут странного?

Пролистайте пару страниц выше, там человек тоже поймал кучу багов в новом билде, некоторые из которых трудноуловимые.  Думаете, он их нарочно выискивал?

Продемонстриуйте пример тормоза с возможностью воспроизведения, пожалуйста.

К сожалению, пока вы делаете голословные заявления, включая прямые наезды на разработчиков.

Про размеры функций и общий размер программы вы неправы. Размер отдельных функций прямо и нелинейно влияет на оптимизацию каждой конкретной функции как из-за увеличения синтаксического дерева, так и из-за многопроходности оптимизатора. Мелкие функции оптимизируются влет.

[Vasiliy Sokolov]

Alexey Navoykov:

Ну значит вы счастливчик. В вашем коде не встретились конструкции, имеющиеся в моём коде.  Что тут странного?

Пролистайте пару страниц выше, там человек тоже поймал кучу багов в новом билде, некоторые из которых трудноуловимые.  Думаете, он их нарочно выискивал?

1) Это интересно какие же такие конструкции Вы использовали, что в моем коде их нет? Объем моего кода многие тысячи строк, а Ваших конструкций нет? Это что-то супер уникальное наверное?

2) По факту, в предыдущем билде действительно была ошибка internal commpiler error возникающая в случае взаимной ссылки классов друг на друга. Это косяк разрабов, но ее пофиксили. Других ошибок не припомню.

[A100]

Vasiliy Sokolov:

2) По факту, в предыдущем билде действительно была ошибка internal commpiler error возникающая в случае взаимной ссылки классов друг на друга. Это косяк разрабов, но ее пофиксили. Других ошибок не припомню.

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

И где здесь взаимная ссылка классов друг на друга?

Здесь еще больше упростил, для вашего удобства поиска взаимных ссылок и понимания какие конструкции вы не используете

[Vasiliy Sokolov]

A100:

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

И где здесь взаимная ссылка классов друг на друга?

Здесь еще больше упростил, для вашего удобства поиска взаимных ссылок и понимания какие конструкции вы не используете

Вы занимаетесь реверсинженерингом. Работа полезная для улучшения компилятора, но с точки зрения практического программирования не применимая. Я не знаю ни одного программиста, кто на практике стал бы использовать приведенный вами код:

//+------------------------------------------------------------------+
//|                                                      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:

Продемонстриуйте пример тормоза с возможностью воспроизведения, пожалуйста.

К сожалению, пока вы делаете голословные заявления, включая прямые наезды на разработчиков..

Я же писал, что это большой проект, общим объём всех исходников около 1 Мб.   Как же вам продемонстрировать тормоза?  Выслать все коды чтоль?  Сам понимаете, это невозможно.  А компиляция отдельных кусочков, разумеется, идёт значительно быстрее.

И что вы имеете ввиду под "голословными заявлениями"?  То что ваш  оптимизирующий компилятор существенно тормозит?  И то что вас это мало волнует?  Что здесь голословного?

Вот ссылка на обсуждение из октября прошлого года, когда вы только ввели эту глобальную оптимизацию:  https://www.mql5.com/ru/forum/1111/page1424#comment_1981722

Человек пишет:

Другой код - обратите внимание на время - оно выросло наверное в 20 раз

 

И далее вы отвечаете:

Это новый оптимизирующий компилятор для MQL5 (в MQL4 его нет) так работает.

За более качественный целевой код приходится платить более долгой компиляцией

Ну и далее там ещё несколько человек, включая меня, также пожаловались на медленную компиляцию.  Но по вашим ответам видно, что вас заботит лишь "более качественный целевой код", и некий мифический "прирост скорости исполнения от 2 до 10 раз",  хотя в реальных рабочих проектах я таких ускорений и близко не наблюдал.

Как я уже говорил, на последнем билде (от 22 апреля) я протестировать не смог, т.к. возникли баги при компиляции.  Но я полагаю, что скорость компиляции там такая же медленная,  коль вы нигде не анонсировали ускорение компилятора в новом билде.