Большой проект! При самостоятельной разработке (одним человеком) сколько строк кода у Вас получается при создании Вами Большого проекта? - страница 3

 

Папка моего проекта в строках (*.mqh файлы)

 

Там тоже очень много касающегося пользовательского интерфейса

 

Время компиляции:

 

 

Тормозов самой программы не замечено 

 
Yuriy Asaulenko:

Пример не оч корректный.

Давайте за 1 тик сложную мат обработку сделаем. Недавно в одной из тем читал. - Смоделировали несложного эксперта -он что-то втупую складывал 100 раз на каждом тике, на каждом 10-м тике что-то дополнительно делал, на каждом сотом еще что-то. Результаты впечатляют.

Где-то еще попадалась тема с жором памяти.

В общем, имхо разумеется, сложный советник на MQL никуда не успеет.

Интересно посмотреть на результаты Ваших тестов.

Yuriy Asaulenko:
Интерпретируемый код, типа VB.

Ссылка на тесты: MQL4, MQL2, EasyLanguage, Wealth-Lab 3.0 и VC++: сравнение скорости. Где-то уже были новые результаты, надо поискать. 

Renat:

...

MQL4 - это оптимизируемый и компилируемый в байт код язык. Очень быстрый. На проводимых ранее тестах были показаны следующие результаты: чем меньше значение, тем быстрее язык. 

...

//---

Вот нашёл из последних с MQL5: Посмотрите на тест сравнения C++, MQL4, MQL5 

 

По результатам такое себе вполне нормальное распределение с максимумом на 5000 строк (в смысле 5000 в среднем можно считать большим проектом).

Смущает только длинный хвост на 125000. Это вероятнее всего какие то графические интерфейсы, они обычно занимают больше всего строк. 

 
А однажды, обнаружилось вот такое "пасхальное яйцо", которое очень интересно компилируется )

struct TCoord {
        int x, y;
};

void OnInit() {        
        TCoord coord = {100, 100};
        TCoord defaultCoord = {0,0};
        coord = (2 == 2) ? coord : defaultCoord;
}
Убил уйму времени чтобы найти проблемное место.
 
Anatoli Kazharski:

Интересно посмотреть на результаты Ваших тестов.

Я не тестировал. Все есть в темах на форуме. Поиск здесь не оч рулит. ( М.б. автор сам здесь объявится, недавно было.

Предполагаю, что не будет MQL работать быстрее, чем VB6.

Моя программа на С# о четырех потоках с информацией о фьючах между тиков не справлялась. Приходилось часть пропускать, не обрабатывать. Но и информации в стандартном терминале побольше, чем в МТ.

Ваши ссылки посмотрю позже. ( Убежал.

 
Yuriy Asaulenko:

Я не тестировал. Все есть в темах на форуме. Поиск здесь не оч рулит. ( М.б. автор сам здесь объявится, недавно было.

Предполагаю, что не будет MQL работать быстрее, чем VB6.

Моя программа на С# о четырех потоках с информацией о фьючах между тиков не справлялась. Приходилось часть пропускать, не обрабатывать. Но и информации в стандартном терминале побольше, чем в МТ.

Ваши ссылки посмотрю позже. ( Убежал.

Посмотрите. Там есть информация и ответы по этому вопросу.

Вот ещё:

Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий

Недоработка компилятор или чудеса программирования на MQL5

Renat Fatkhullin, 2014.08.11 20:19

...

Мы наоборот расширяем сам язык так, чтобы не нужно было мучиться с внешними системами и DLL. Для связи с внешними ресурсами есть штатные WebRequest и пайпы.

Скоро мы выпустим очередную версию MQL4/MQL5 среды, скорость которой будет на уровне абсолютно нативных C++ программ. То есть, код на MQL5 будет работать так, что больше никто не сможет сказать "я пишу DLL, так как там быстрее работает мой код".

Функционала в MQL сейчас столько, что можно написать почти все что угодно для расчетов, контроля и принятия решений:

  • расчеты быстрые
  • доступ ко всему рыночному окружению
  • визуализация, включая массу графических объектов, 32 битный канвас, звук
  • взаимодействие с пользователем, ввод данных, управление мышью, таскаемые объекты и панели
  • все торговые операции, включая асинхронные
  • пуш уведомления на мобильные
  • связь со внешними системами через вебслужбы (WebRequest), включая SSL
  • связь со внешними системами по пайп каналам/серверам
  • защищенность и безопасность программ
  • и тд

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

 
Anatoli Kazharski:

Посмотрите. Там есть информация и ответы по этому вопросу.

Вот ещё:

Да, спасибо, прочитал. Мои предположения полностью подтвердились.

Тест сравнения С++ и MQL

Renat: Видно, что MQL5 отстает от С++ где-то в 5 раз, MQL4 от C++ в 50 раз, а MQL4 от MQL5 в 10 раз.

Да, тут в тесте простейший цикл, с которым С++ справился без проблем.

//----------------------------------------------------

Т.е., скорее всего, на реальных задачах (тестах) С++ будет опережать по быстродействию MQL5 где-то, ориентировочно в 10-15 раз. MQL4, мы видим, вообще отдыхает.

Никаких более свежих данных не существует, только слова, что вот-вот по быстродействию MQL не уступит С++. Но это, типа, свежо предание....

Возвращаясь к C# - код С# медленнее С++ кода, примерно на 10-80%  в серии тестов. Что похоже на правду.

Возвращаясь к моему первоначальному тезису - сколь-нибудь сложный эксперт, реал-тайм обрабатывающий тиковые данные в MQL написать нереально.

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

 
Yuriy Asaulenko:

Да, спасибо, прочитал. Мои предположения полностью подтвердились.

...

Вот ещё есть более свежая тема с результатами тестов: Тестирование нового компилятора MQL5 для x64 платформ - ускорение расчетов от 2 до 10 раз! 

 
Vladimir Pastushak:

Может есть смысл измерять проекты в байтах/ мегабайтах ?

Да так и делают в основном
Когда изучал исходники операционных систем обратил внимание
Как программисты США оформляли коды
Комментариев больше чем кода
Им платят именно за объёмы 
 
Yuriy Zaytsev:
Да так и делают в основном
Когда изучал исходники операционных систем обратил внимание
Как программисты США оформляли коды
Комментариев больше чем кода
Им платят именно за объёмы 

Упс, в таком подходе есть проблемка: класс описывается как совокупность объявленной памяти и методов реализованных в нём.

Все объекты класса имеют одну общую таблицу методов и свой набор памяти для каждого объекта. Чуете где собака порылась?

Объём объекта в байтах определяет сколько памяти объявлено в классе, между тем как работа программиста в основном заключается в написании методов.

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

В общем пока что лучшей методики оценки не выработали.

Самая лучшая метода была бы та, которая стимулировала бы программиста писать наиболее эффективный (с точки зрения быстроты и экономии памяти) код. А уж сколько там строк и какой объём памяти у класса не важно.

Причина обращения: