Ещё раз о многопоточности - страница 4

 
meat:

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

В MQL5 есть все необходимое, просто надо научиться этим пользоваться.

Перенесите часть расчетов в индикатор, и запускайте его из эксперта.

 

А делать штатное распараллеливание для 2-х десятков (оптимистично) пользователей никто не будет.

Документация по MQL5: Основы языка / Функции / Функции обработки событий
Документация по MQL5: Основы языка / Функции / Функции обработки событий
  • www.mql5.com
Основы языка / Функции / Функции обработки событий - Документация по MQL5
 
TheXpert:
Так скрипты ж есть для многопоточности. А в тестере она нафиг не нужна

А как скрипт запустить из эксперта?

 
komposter:

Перенесите часть расчетов в индикатор, и запускайте его из эксперта.

Ну вот, опять вы мне про танцы с бубнами. Речь шла о нормальной реализации.

 А делать штатное распараллеливание для 2-х десятков (оптимистично) пользователей никто не будет.

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

Постоянно решать вопрос оптимизации через одно место, как тут многие предлагают - это совсем не то, чем хочется заниматься.

И кроме того, я же в самом начале сказал о том, что я и не прошу их делать штатное распараллеливание. Я вполне в состоянии распараллелить всё сам, используя WinApi. Всё что требуется - это адрес функции. Поэтому я и просил добавить лишь указатели на функции.  Желательно конечно ещё поддержка директивы __stdcall, но это тоже необязательно, можно и своими силами сделать необходимые манипуляции.

Указатели на функции - это вообще-то очень полезная вещь. Использование их для создания потоков - это лишь одно из множества применений. Они также используются например для задания функции обратного вызова в различных асинхронных операциях. Кроме того, они будут архи-полезными при передачи их в свою ДЛЛ, за счёт чего упрощается связь между ДЛЛ и импортировавшим её экспертом, т.е. по сути происходит полная интеграция. В ходе выполнения, ДЛЛ может непосредственно вызвать MQL функцию и из неё получить какую-нибудь необходимую информацию. А сейчас для этого нужно генерировать какое-то событие (наприме тик), провоцирующее запуск эксперта, который затем будет передавать требуемую инфу в ДЛЛ... В общем лишний геморрой и затраты времени

 
По поводу многопоточности.
  1. Добавление многопоточности в язык предполагает создание специального API поддерживающего многопоточность,
    который в свою очередь будет работать медленнее чем API без такой поддержки, надеюсь это понятно (локи и т.п.).
  2. Придётся переписывать оптимизатор компилятора MQL5 - фактически ухудшить оптимизации.
  3. Это место для трудноуловимых пользовательских ошибок.
Ну и последнее, нужно это не очень малому числу пользователей и отсутствие поддержки можно обойти.


Про указатели на функции.
Вопрос открыт по использованию их внутри MQL5 кода.
К сожалению, передать указатель в DLL не получится - в угоду кроссплатформенности x86/x64 пришлось пожертвовать соглашением о вызовах.
 
mql5:
По поводу многопоточности.

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

По факту у него даже реальной задачи нет на параллельность.

 

mql5:
 ...Ну и последнее, нужно это не очень малому числу пользователей и отсутствие поддержки можно обойти.

Мне понравилась идея использования скриптов, но как их вызвать из эксперта?

 
DC2008:

Мне понравилась идея использования скриптов, но как их вызвать из эксперта?

К сожалению, запуск скриптов из MQL5 не предусмотрен.

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

Что за задача у Вас?
Почему бы не имееть на готове запущенный эксперт на соседнем чарте, который получив Event сделает свою работу?
Запуск новой MQL5 программы дело накладное в связи с защитой EX5 файлов.
 
mql5:
К сожалению, запуск скриптов из MQL5 не предусмотрен.

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

Что за задача у Вас?
Почему бы не имееть на готове запущенный эксперт на соседнем чарте, который получив Event сделает свою работу?
Запуск новой MQL5 программы дело накладное в связи с защитой EX5 файлов.

У меня тысячи графических объектов, которые надо анализировать: удалять ненужные, менять свойства, расчитывать статхарактеристики и т.д. Даже на одном графике тормоза, а если их несколько?

 
Для графических обьектов многопоточность не поможет даже теоретически.

Проблему работы с графическими обьектами надо решать алгоритмически. Экономно и не смешивать команды изменения и чтения обьектов. Например, 1000 раз прочитать и только потом 1000 раз записать будет сильно быстрее, чем 1000 раз считать и записать.
 
mql5:
По поводу многопоточности.
  1. Добавление многопоточности в язык предполагает создание специального API поддерживающего многопоточность,
    который в свою очередь будет работать медленнее чем API без такой поддержки, надеюсь это понятно (локи и т.п.).
  2. Придётся переписывать оптимизатор компилятора MQL5 - фактически ухудшить оптимизации.
  3. Это место для трудноуловимых пользовательских ошибок.
Ну и последнее, нужно это не очень малому числу пользователей и отсутствие поддержки можно обойти.


Про указатели на функции.
Вопрос открыт по использованию их внутри MQL5 кода.
К сожалению, передать указатель в DLL не получится - в угоду кроссплатформенности x86/x64 пришлось пожертвовать соглашением о вызовах.
Благодарю за развёрнутый ответ. Теперь всё стало более-менее понятно. Единственное, что касается невозможности передачи указателя в DLL, то я так понимаю, вы имели ввиду системные DLL (т.е. соглашение __stdcall)?  А в своей собственной DLL то я могу прописать любое другое соглашение. Или оно у вас вообще эксклюзивное, не соответствуещее никаким стандартам?
Причина обращения: