Ещё раз о многопоточности
Уважаемые раработчики, порывшись в поиске по теме многопоточности, нашёл сказанную вами фразу о том, что функции по созданию и управления потоками вы не собираетесь добавлять в MQL5. Это было сказано более полутора лет назад. Вот хотелось бы узнать, не изменились ли ваши взгляды с тех пор?
И если по-прежнему не хотите с этим заморчиваться, то может тогда дадите пользователям возможность самим реализовать это? Для этого нам требуется указатель на функцию. Как насчёт добавить такую возможность? Т.е. GetPointer(myfunc)
И также, если не трудно, поясните пожалуйста, почему вы не стали реализовывать многопоточность в MQL5, в чём вы увидели конкретные сложности? Или это просто принципиальная позиция?
Хотелось бы напомнить, что на дворе уже давно не 2000-й год, и мультиядерность процессоров уже давно стала для всех нормой, количество ядер будет только расти с каждым годом. Сейчас 4, через пару лет уже 6-8, и т.д. А вы не даёте пользоватям нормально задействовать процессор исполняемой программой.
Какой тогда смысл в ваших постоянных сравнениях MQL с С++ по скорости, если вы сравниваете только работу в одном потоке? Ведь ни один здравомыслящий программист в С++ не станет вешать ресурсоёмкую задачу на один поток, когда в распоряжнии имеются несколько процессоров, благодря которым производительсность можно увеличить в разы. Поэтому все эти ваши тесты имеют мало отношения к реальной жизни. Через несколько лет ядерность процессоров вырастет до 10, а вы так и будете гордиться своими однопоточными тестами MQL?
А что касается использования OpenCL, то это уже шаманство, тем более в таком виде, как это тут реализовано - через текстовую строку. Т.е. отладкой кода занимаешься где-то в другом месте, потом копипастишь в MQL5... Цирк какой-то! Проще тогда сразу реализовать всё это в DLL и импортировать. Тем более мало кому охота писать программу на нескольких языках.
Многопоточность в MQL5 всё такие есть, но в отличии от С++ она реализована в виде виртуальной среды исполнения именуемой чартом.
Каждый чарт работает в отдельном потоке, сделано это чтоб ваш тот самый пользователь не заморачивался с синхронизацией потоков, доступа к данным, и другие вопросы возникающие при общении потоков.
Кривенько? да, но для массового пользователя (который и так жалуется на сложности языка) самое то.
По OpenCL вообще отдельный вопрос. Его даже в планах развития платформы не было. С начало продвинутые форумчане привлекли интерес разработчиков к этой теме, но официальный ответ был "нет и не будет". Но потом руководство MQ сменили гнев на милость (спасибо Ильязу).
Про Dll : MQ считает их потенциально опасными, поэтому везде где есть возможность обойтись без них старается реализовать это, особенно это касается публичных сервисов. Но при этом не запрещает их вообще, ведь программисты пишут не только на публику, но и для междусобойчиков.
В общем, похоже на чистые теоретические заявления.
С многопоточностью и полнотой использования процессоров в терминале все отлично. Посмотрите, сколько потоков запущено у терминала и как меняется во времени количество этих потоков. Принципы многопоточной работы терминала многократно объяснялись и показывались. Например, как работают независимые потоки пересчета индикаторов, символов, подкачки данных чартов, независимая работа всех экспертов и скриптов.
Чтобы параллелить расчеты чего-либо, надо для начала осознать, что распараллелить можно лишь мизерную часть математики.
Посмотрите на многоядерный тестер, MQL5 Cloud Network и OpenCL. Мы давно уже впереди паровоза бежим, особенно в облачных вычислениях. Вот прямо сейчас включите себе MQL5 Cloud Network в тестере и получите до 14 000 CPU себе в помощь:
Похоже, про OpenCL тоже не в курсе. Представление кода программ в исходном виде для отсылки OpenCL компилятору - это обычный и стандартный путь работы. Учтите, что разные OpenCL обработчики (Ndivia, AMD, Intel и тд) должны получить код и переработать его под себя.
- cloud.mql5.com
Что такое мультипотоковость в MetaTrader 5:
Вот прям только что нажал на тест, мгновенно получил 5 743 агента/CPU в работу и за 6 минут исполнил 381 468 проходов в оптимизаторе. Каждый проход занимал от 1 до 2 секунд просчета. Если бы я вел тест на своем компьютере с 8 ядрами, то потратил бы вместо 6 минут от 800 до 1600 минут (381468 / 8 = 47683 секунд = 794 минуты).
Причем кроме нажатия на кнопку "Старт" мне больше ничего делать не пришлось. Некий скайнет поднялся, самостоятельно синхронизировал всю нужную историю чартов, распределил задачу по тысячам компов по всему миру и массово отработал их.
Добро пожаловать в реальность...
Ренат,
вопрос про создание потоков внутри MQL5 эксперта.
Ренат,
вопрос про создание потоков внутри MQL5 эксперта.
Я в курсе.
Просто я не стал писать о том, что человеку, который не понимает, почему нет многопоточности в прикладном расчетном языке, лучше не говорить про многопоточность. Вся инфраструктурная многопоточность терминала нами реализована в полной и эффективной мере.
Реальная многопоточность нужна в местах, где можно реально параллелить задачи. Это тестер. И именно это место мы реализовали так, что многим далеко до понимания качества, контроля и объема произведенной работы.
Мой пример с клаудом является простым доказательном качества и уровня проработки задачи.
Да, Ренат, вы что-то невнимательно прочитали мой пост. Речь вовсе не о многопоточности МТ5, а о многопоточности MQL5. Мы же не можем самостоятельно создавать эти потоки в выполняемой программе. А программное открытие нового чарта с индикатором - это, согласитетесь, танцы с бубном, а не решение.
Ведь что самое удивительное, вы нагородили в MQL5 столько всего лишнего, если брать во внимание массового пользователя. Ведь насколько я понимаю, вы ориентируетесь в основном на чайников, а не на грамотных программистов. Отсюда и куча ограничений, невозможность работы с памятью напрямую и т.д. Так вот спрашивается, зачем чайникам нужны например классы?
Если же вы позиционируете свой продукт не только для чайников, то почему не можете дать опытым программистам возможность эффективно использовать ресурсы системы?
Ведь отсутствие многопоточности не компенсируешь никакими классами. Как бы изящно не выглядела программа, но если она неэффективно использует системные ресурсы, то грош цена всему этого. Видимо вы идимо в погоне за новаторством позабыли, что язык MQL предназначен в первую очередь для написания торгово-аналитических программ, а не для программирования ради программирования. Поэтому на первом месте должна быть скорость и эффективность работы программы, а не скорость написания кода. Ведь априори предполагается работа с большими объёмами данных.
Думаю, для большинства пользователей вполне достаточно было и возможностей MQL4. Для полного счастья не хвататало лишь поддержки структур, указателей на переменные и указателей на функции (ну либо встроенной поддержки callback-функций). И всё. Имея этот арсенал, можно создавать любые программы, работающие очень эффективно, самому создавать требуемое количество потоков, callback'ов и т.д.
meat, не обижайтесь, но с таким уровнем понимания проблематики в детский сад.
Я все внимательно читал, но не имею возможности проводить полномасштабный ликбез. У меня за плечами 11 лет работы над MQL/MQL2/MQL4/MQL5 языками.
Речь вовсе не о многопоточности МТ5, а о многопоточности MQL5. Мы же не можем самостоятельно создавать эти потоки в выполняемой программе. А программное открытие нового чарта с индикатором - это, согласитетесь, танцы с бубном, а не решение.
Ведь что самое удивительное, вы нагородили в MQL5 столько всего лишнего, если брать во внимание массового пользователя.
Если брать единичного пользователя, то может быть и много лишнего. А когда начинаешь расширять свой кругозор и требуются дополнительные возможности, то выясняется, что наоборот, чего-то уже есть, а чего-то не хватает.
MQL5 пока еще в стадии развития. Постепенно что-то добавляется новое. Хотя конечно же есть и недостатки, например, невозможно создать свои события, нет обработчиков исключений и многопоточности. Надеюсь, что все это когда нибудь появится? Но сомневаюсь, что все это будет реализовано уже завтра.
Если сильно захотеть, то многопоточность есть у агентов тестирования и в OpenCL. Не совсем удобно, но все таки она есть и распараллелить задачи можно.
meat, не обижайтесь, но с таким уровнем понимания проблематики в детский сад.
А Вы говорите не корпоративный стандарт))
Если вопросы задаются, значит ответы не на поверхности...
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
И если по-прежнему не хотите с этим заморчиваться, то может тогда дадите пользователям возможность самим реализовать это? Для этого нам требуется указатель на функцию. Как насчёт добавить такую возможность? Т.е. GetPointer(myfunc)
И также, если не трудно, поясните пожалуйста, почему вы не стали реализовывать многопоточность в MQL5, в чём вы увидели конкретные сложности? Или это просто принципиальная позиция?
Хотелось бы напомнить, что на дворе уже давно не 2000-й год, и мультиядерность процессоров уже давно стала для всех нормой, количество ядер будет только расти с каждым годом. Сейчас 4, через пару лет уже 6-8, и т.д. А вы не даёте пользоватям нормально задействовать процессор исполняемой программой.
Какой тогда смысл в ваших постоянных сравнениях MQL с С++ по скорости, если вы сравниваете только работу в одном потоке? Ведь ни один здравомыслящий программист в С++ не станет вешать ресурсоёмкую задачу на один поток, когда в распоряжнии имеются несколько процессоров, благодря которым производительсность можно увеличить в разы. Поэтому все эти ваши тесты имеют мало отношения к реальной жизни. Через несколько лет ядерность процессоров вырастет до 10, а вы так и будете гордиться своими однопоточными тестами MQL?
А что касается использования OpenCL, то это уже шаманство, тем более в таком виде, как это тут реализовано - через текстовую строку. Т.е. отладкой кода занимаешься где-то в другом месте, потом копипастишь в MQL5... Цирк какой-то! Проще тогда сразу реализовать всё это в DLL и импортировать. Тем более мало кому охота писать программу на нескольких языках.