Асинхронное и многопоточное программирование в MQL - страница 16
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Я же уже писал вам, вы же пытаетесь строить НС, вам ли не нужна в данном случае асинхронность?
Но вы строите НС на простых функциях активации, по этому не сталкивались с нехваткой параллельности.
А вот кода начнёте строить глобальные модели НС, тогда и поймёте прелесть асинхронности.
плохой пример - не нужна!
в топике писал уже @Roffild "В современном мире программист должен знать несколько языков, чтобы правильно выбирать инструмент под конкретную задачу."
это истина!
В в MQL нет выбора пакетов для МО (НС) - только AlgLib - мне хочется рассмотреть пример найденный на хабре, я беру и подключаю C# или Python к MQL - все, я занимаюсь тем чем хотел заняться,а не занимаюсь портированием кода в MQL
Сейчас языки программирования интересны не своими возможностями, а готовыми фреймворками! - если в MQL будут новые пакеты МО, тогда и будут другие задачи и проблемы!
ЗЫ: еще раз на пальцах, Вы вцепились в "идею фикс" которая выросла из кросплатформенных языков Python и Java, жертвой за переносимостью и гибкостью языка был ущерб быстродействию, теперь эти языки обросли разными способами увеличить быстродействие, но в Си-подобных языках разработчики всегда достигают максимального быстродействия и нет необходимости (в большинстве случаев) делить задачу на отдельные потоки (задачи клиент - сервер не в счет, там проблема в скорости обмена данных и это другая специфика)
плохой пример - не нужна!
в топике писал уже @Roffild "В современном мире программист должен знать несколько языков, чтобы правильно выбирать инструмент под конкретную задачу."
это истина!
В в MQL нет выбора пакетов для МО (НС) - только AlgLib - мне хочется рассмотреть пример найденный на хабре, я беру и подключаю C# или Python к MQL - все, я занимаюсь тем чем хотел заняться,а не занимаюсь портированием кода в MQL
Сейчас языки программирования интересны не своими возможностями, а готовыми фреймворками! - если в MQL будут новые пакеты МО, тогда и будут другие задачи и проблемы!
ЗЫ: еще раз на пальцах, Вы вцепились в "идею фикс" которая выросла из кросплатформенных языков Python и Java, жертвой за переносимостью и гибкостью языка был ущерб быстродействию, теперь эти языки обросли разными способами увеличить быстродействие, но в Си-подобных языках разработчики всегда достигают максимального быстродействия и нет необходимости (в большинстве случаев) делить задачу на отдельные потоки (задачи клиент - сервер не в счет, там проблема в скорости обмена данных и это другая специфика)
Вы постоянно игнорируете следующие вещи:
1. Распостронение программ использующих внешние подключения не может осуществлятся через Маркет.
2. Программы использующие внешние подключения требуют от пользователю быть "профессором", чтобы все правильно подключить. Инструкция использования такой программы - портянка.
3. Программы использующие внешние подключения подходят только для личного пользования, что значительно сужает смысл их создания.
4. Программы для личного пользования имеют более низкое качество, чем программы предназначенные для продажи, ведь для себя можно сделать как попало... и НЕВОЗМОЖНО БЫТЬ ОДИНАКОВЫМ СПЕЦИАЛИСТОМ СРАЗУ В НЕСКОЛЬКИХ ЯЗЫКАХ. Какие то языки будешь знать с пятого на десятое и это отразиться на качестве продукта.
5. Есть масса задач требующих асинхронности и многопоточности. МQL-программы еще не доросли до этих задач, но это не значит, что они не должны к ним стремиться.
...
Чем достигается асинхронность в одном потоке.
Не, ну асинхронность без многопоточности - это реально дичь какая-то, нужен как минимум один дополнительный поток. Думаю, ваш EventLoop можно сделать через подгружаемые индикаторы. Общение между эксперт-индикаторы через сокеты, например. Появилась задача, подцепили индикатор, отправили задание, индикатор отчитался о выполнении, запросили из эксперта статус задачи, удалили индикатор. Через костыли, но всё же многопоточность.
Да та статья очень хорошая, для единичного решения, подумать покрутить может что и ещё можно будет выжать из данного подхода.
В моём случае я то определился с направлением своей задачи, спасибо Андрею за направление.
То что Вы прочитали одну статью это уже хорошо.
Не потоки, а именно не блокирующие вызовы через колбэк функции, управляющиеся с помощью EventLoop.
Чем достигается асинхронность в одном потоке.
Как Вы умудрились не найти этого в документации?
Может Вам таки её прочитать?
Вы постоянно игнорируете следующие вещи:
у нас с Вами задачи разные, Вы не учитываете, что при написании ПО есть 2 больших этапа: разработка ПО и сама реализация.
Для разработки ПО нужны готовые решения - это время, если в ходе разработки выясняется, что ПО не будет выполнять свои задачи как планировалось - это в мусор. А сама реализация - это уже механическая работа под возможности конкретной платформы.
5. Есть масса задач требующих асинхронности и многопоточности. МQL-программы еще не доросли до этих задач, но это не значит, что они не должны к ним стремиться.
ОК, давайте теперь с Вами:
ответьте на вопрос зачем это нужно торговому терминалу?
То что Вы прочитали одну статью это уже хорошо.
Как Вы умудрились не найти этого в документации?
Может Вам таки её прочитать?
Представьте не нашёл.
Поиск по callback и eventloop не находит не чего подобного в документации.
Если вас не затруднит, дайте линк без лишних сарказмов.
1. у нас с Вами задачи разные, Вы не учитываете, что при написании ПО есть 2 больших этапа: разработка ПО и сама реализация.
Для разработки ПО нужны готовые решения - это время, если в ходе разработки выясняется, что ПО не будет выполнять свои задачи как планировалось - это в мусор. А сама реализация - это уже механическая работа под возможности конкретной платформы.
ОК, давайте теперь с Вами:
2. ответьте на вопрос зачем это нужно торговому терминалу?
1. Я только и занимаюсь, что разработкой. Врядли за 6 лет беспрерывной разработки я не понимаю что это. )) Считаю, что готовые чужие решения выдираемые из контекста других программ или абстрагированные от каких либо программ, плохо интегрируются в структуру узкоспециализированного кода, и может получится жуткий винегрет, а чтобы он не получился, нужно постараться. Трудозатраты при этом выше, чем разработка своего решения, а конечное качество кода ниже. Не говоря уже о потенциале развития. Это реалии разработки. Но, это не имеет отношение к нашему вопросу. Вообще, причем здесь это?
2. Вы задаете неверный вопрос. Главный вопрос - "Зачем это нужно конечному пользователю?". Затем, что пользователю всегда мало предлагаемых возможностей. Поэтому, их надо добавлять, чтобы он не потерял интерес. Если возможности исчерпаны и новых не добавить из за технических ограничений, то пользователь уйдет. Возможности нужны чтобы удержать пользователей у терминала и распостронение программ для этого нужно. Поэтому, программы которые не могут распостраняться бессмысленны для сообщества, какие бы языки они не использовали.
На самом деле, Вы смотрите только на собственные потребности и не учитываете потребности других пользователей. Вы не делаете и не хотите делать бизнес в этом сообществе, и транслируете только мотивацию заработать на рынке. А на рынке можно зарабатывать и без программ вообще.
плохой пример - не нужна!
в топике писал уже @Roffild "В современном мире программист должен знать несколько языков, чтобы правильно выбирать инструмент под конкретную задачу."
это истина!
В в MQL нет выбора пакетов для МО (НС) - только AlgLib - мне хочется рассмотреть пример найденный на хабре, я беру и подключаю C# или Python к MQL - все, я занимаюсь тем чем хотел заняться,а не занимаюсь портированием кода в MQL
Сейчас языки программирования интересны не своими возможностями, а готовыми фреймворками! - если в MQL будут новые пакеты МО, тогда и будут другие задачи и проблемы!
ЗЫ: еще раз на пальцах, Вы вцепились в "идею фикс" которая выросла из кросплатформенных языков Python и Java, жертвой за переносимостью и гибкостью языка был ущерб быстродействию, теперь эти языки обросли разными способами увеличить быстродействие, но в Си-подобных языках разработчики всегда достигают максимального быстродействия и нет необходимости (в большинстве случаев) делить задачу на отдельные потоки (задачи клиент - сервер не в счет, там проблема в скорости обмена данных и это другая специфика)
Игорь, вы иногда противоречите сами себе.
В прошлый раз вы писали, что скорость mql расчёта сравнима с скоростью C++
Ок, это действительно так и многие об этом знают.
Но тут же вы приводите пример подключения сторонних фреймворков, для переноса расчетов, как вы выражаетесь на тормознутые языки.
И агитируете за стороннее подключение пакетов. То есть вы жертвуете скоростью ради готового фрейморка?
И тем самым как написал Peter наглухо лишаетесь переносимости своей программы.
Не айс решение. Для личного пользования да, для массовых решений нет.
Представьте не нашёл.
Поиск по callback и eventloop не находит не чего подобного в документации.
Если вас не затруднит, дайте линк без лишних сарказмов.
Надо не поиск делать, а читать всё. Я уверен, что там для Вас есть много неожиданного.
Никаких линков не будет.
Я здесь не раз помогал тем, кто хотя бы попытался сам что-то сделать.
А что сделали Вы?
Только чешете языком на форуме?
Ну так я же в этом Вам помогаю.