Ещё раз о многопоточности - страница 3
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Рекомендую перечитать Ваше исходное сообщение, обратить внимание на все свои эпитеты, потом пойти ниже к ответам.
Ответы звучали спокойно, попутно ставились мягкие вопросы "Чтобы параллелить расчеты чего-либо, надо для начала осознать", давались ответы и объяснялось текущее положение вещей "что реально нужно параллелить".
Но вместо быстрого обучения Вы выдали еще больше бреда и навешали на нас собак. В результате получили жесткий ответ.
Ок, с эпитетами, соглашусь, я действительно перебрал немного, за это приношу свои извинения. Хотя ничего грубого я ведь не сказал, просто излишне эмоциональная критика, но это же совершенно не адекватно той резкости, с который вы реагируете на это. Я нигде не говорил, что разработчики бездари и ничего не понимают, так что не стоит утрировать.
Раз я поднял эту тему, то значит вполне осознаю, для чего это необходимо, и распараллеливать есть что. Далеко не все алгоритмы ограничиваются "hello world!", есть куда более сложные и ресурсоёмкие. Поэтому весьма странно слышать такие нравоучения о том, что нужно распараллеливать, а что нет, при том что вы даже не видели алгоритм.
Что касается реализации кода в ДЛЛ, равно как и использовании OpenCL, то это уже не относится к MQL. А речь шла о программировании именно на MQL.
OpenCL работает в рамках MQL5 кода.
Вот пример кода.
Что касается реализации кода в ДЛЛ, равно как и использовании OpenCL, то это уже не относится к MQL. А речь шла о программировании именно на MQL.
И что вы мне ответили? Вы начали рассказывать, какой у вас замечательный терминал и тестер, работающие в неколько потоков. А я ни словом не заикался о вашем терминале. Речь шла совсем о другом: о многопоточности в коде MQL. Когда алгоритм можно разбить на несколько частей, и каждая выполняется параллельно. А вы, даже не вникнув в суть, начинаете грубить. Ладно, как я вижу с таким подходом ни о каком конструктиве говорить не приходится, так что нет смысла продолжать обсуждение.
Конструктивные решения есть и при существующем положении дел. Несколько mql-программ (экспертов и/или индикаторов) могут обмениваться сообщениями, а следовательно и заданиями и результатами выполнения заданий - естественно, если вы создадите и организуете соответствующий протокол обмена. Все эксперты работают в разных потоках (каждый в своём), следовательно такая схема совместных расчётов является заведомо многопоточной, и при наличии нескольких ядер будет достаточно равномерно их нагружать.
Обмен сообщениями (средствами mql5) возможен через:
1. события терминала
2. именованные каналы
3. DLL
4. файлы
5. и т.п.
Из этого набора средств можно выбрать наиболее подходящий или использовать более одного (хоть все сразу). У каждого способа есть свои преимущества и недостатки, например именованные пайпы позволяют передавать информацию по локальной сети, следовательно есть возможность распараллелить задачу более чем для одного многоядерного процессора.
Успехов.
OpenCL работает в рамках MQL5 кода.
Вот пример кода.
Ну то что работает - это ещё полдела. А как его потом редактировать и отлаживать то? Если он находится в строковой константе, то как искать ошибку? Значит его нужно разрабатывать во внешней программе, а потом вставлять в MQL. Но если постоянно заниматься таким переносом - это ж с ума сойти можно, о чём я и писал в первом посте. Поскольку разработка кода всё-равно ведётся в другом месте, то какой смысл тогда пихать всё это в MQL. Проще сразу компилировать в виде ДЛЛ и импортировать.
Я конечно понимаю, что тут преследуется цель создания открытого исходника, без использования самописных ДЛЛ и прочего. Но это уже частные случаи. Обычно ведь программа пишется для себя, а не для окружающих. И мало кто захочет постоянно заниматься бессмысленными манипуляциями по перетаскиванию кода из одной программы в другую.
Вот если бы вы сделали встроенный компилятор всего этого, тогда другое дело. И кстати, почему бы и нет? Там же вроде сишный синтаксис. Т.е. можно было бы использовать это всё в составе обычного mql-кода, просто добавив дополнительные функции в ваш МетаЕдитор. А потом бы компилятор форматировал соответствующий фрагмент кода в соответствующем виде, добавляя \r\n и т.д.
Ну то что работает - это ещё полдела. А как его потом редактировать и отлаживать то? Если он находится в строковой константе, то как искать ошибку? Значит его нужно разрабатывать во внешней программе, а потом вставлять в MQL. Но если постоянно заниматься таким переносом - это ж с ума сойти можно, о чём я и писал в первом посте. Поскольку разработка кода всё-равно ведётся в другом месте, то какой смысл тогда пихать всё это в MQL. Проще сразу компилировать в виде ДЛЛ и импортировать.
Я конечно понимаю, что тут преследуется цель создания открытого исходника, без использования самописных ДЛЛ и прочего. Но это уже частные случаи. Обычно ведь программа пишется для себя, а не для окружающих. И мало кто захочет постоянно заниматься бессмысленными манипуляциями по перетаскиванию кода из одной программы в другую.
Вот если бы вы сделали встроенный компилятор всего этого, тогда другое дело. И кстати, почему бы и нет? Там же вроде сишный синтаксис. Т.е. можно было бы использовать это всё в составе обычного mql-кода, просто добавив дополнительные функции в ваш МетаЕдитор. А потом бы компилятор форматировал соответствующий фрагмент кода в соответствующем виде, добавляя \r\n и т.д.
Кто хочет, ищет возможности. Кто не хочет, причины © Поговорка
Конструктивные решения есть и при существующем положении дел. Несколько mql-программ (экспертов и/или индикаторов) могут обмениваться сообщениями, а следовательно и заданиями и результатами выполнения заданий - естественно, если вы создадите и организуете соответствующий протокол обмена. Все эксперты работают в разных потоках (каждый в своём), следовательно такая схема совместных расчётов является заведомо многопоточной, и при наличии нескольких ядер будет достаточно равномерно их нагружать.
Обмен сообщениями (средствами mql5) возможен через:
1. события терминала
2. именованные каналы
3. DLL
4. файлы
5. и т.п.
Из этого набора средств можно выбрать наиболее подходящий или использовать более одного (хоть все сразу). У каждого способа есть свои преимущества и недостатки, например именованные пайпы позволяют передавать информацию по локальной сети, следовательно есть возможность распараллелить задачу более чем для одного многоядерного процессора.
Успехов.
Ну, скажем так, отнюдь не всё из перечисленного вами относится к средствам mql5 :) Да и речь шла вовсе не о том, как решить (обойти) этот вопрос. Найти какой-то выход всегда можно, об этом спору нет. А разговор идёт о том, почему бы не добавить соответствующий функционал в mql5, чтобы не приходилось извращаться.
Согласитесь, запускать множество экспертов с соответствующими графиками просто ради того чтобы организовать обработку в несколько потоков - это не рационально, да и ненадёжно.
Кто хочет, ищет возможности. Кто не хочет, причины © Поговорка
Для начала нужно понять целесообразность :) Имею ввиду целесообразность использования MQL5 вообще, и соответственно МТ5, стоит ли переходить на эту платформу. Ведь если тут, также как и в МТ4, для нормальной работы придётся заниматься шаманством, запуском нескольких экспертов и т.д., либо необходимо переносить код в ДЛЛ, то тогда нет смысла менять шило на мыло. Если код приходится писать в ДЛЛ, тогда проще и надёжней сразу использовать платформу с открытым АПИ, чем иметь лишний довесок в виде эксперта (и запущенного терминала в целом).
Для начала нужно понять целесообразность :) Имею ввиду целесообразность использования MQL5 вообще, и соответственно МТ5, стоит ли переходить на эту платформу. Ведь если тут, также как и в МТ4, для нормальной работы придётся заниматься шаманством, запуском нескольких экспертов и т.д., либо необходимо переносить код в ДЛЛ, то тогда нет смысла менять шило на мыло. Если код приходится писать в ДЛЛ, тогда проще и надёжней сразу использовать платформу с открытым АПИ, чем иметь лишний довесок в виде эксперта (и запущенного терминала в целом).
Никто насильно переходить на MQL5 не заставляет. Мне, к примеру, не хватало функционала на MQL4, поэтому пришлось переходить на пятеру.
Но в принципе можно, например, на С++ весь функционал выполнить, а в MQL5 оставить лишь исполнительную часть и завязать все это хозяйство протоколом через именованные каналы. Вариантов море. Было бы желание.