Предложение по улучшению многопоточности тестирования - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Распараллеливания как возможности языка не будет.
Для распараллеливания расчёта не связанных данных(не требующих синхронизации) действительно можно использовать несколько экспертов или индикаторов(на разных символах).Из-за проблем синхронизации доступа к данным, это на порядок усложнит язык и создаст огромное поле для пользовательских (в том числе) ошибок.
P.S.: Ещё раз повторюсь, в планах развития языка стоит разработка математических библиотек, которые будут использовать железо на 100%, в том числе
и распараллеливание, если позволяет алгоритм.
Распараллеливания как возможности языка не будет.
Для распараллеливания расчёта не связанных данных(не требующих синхронизации) действительно можно использовать несколько экспертов или индикаторов(на разных символах).Из-за проблем синхронизации доступа к данным, это на порядок усложнит язык и создаст огромное поле для пользовательских (в том числе) ошибок.
P.S.: Ещё раз повторюсь, в планах развития языка стоит разработка математических библиотек, которые будут использовать железо на 100%, в том числе
и распараллеливание, если позволяет алгоритм.
1) Для распараллеливания расчёта не связанных данных(не требующих синхронизации) действительно можно использовать несколько экспертов или индикаторов(на разных символах).
2) P.S.: Ещё раз повторюсь, в планах развития языка стоит разработка математических библиотек, которые будут использовать железо на 100%, в том числе
и распараллеливание, если позволяет алгоритм.
1) Вот. Моя идея подтверждена разработчиками, хотел писать статью на эту тему, но всё руки не доходят и есть сомнения в большой целесообразности. Так, в последних моих экспериментах, ускорение работы при использовании dll для обработки массивов можно получить до 6,7 раза по сравнению с .ех5. Если писать dll с параллельной архитектурой, то получится соответственно ещё большее ускорение.
Вопрос разработчикам - является ли порогом текущая скорость работы ех5, или будут ещё применяться какие нибудь оптимизации?
2) Надо полагать, библиотеки будут уже скомпилированными и пользовательский код в них использовать уже будет невозможно?
ЗЫ. тема реально актуальная для меня. в последней разработке, над которой тружусь в данный момент, обучается сеть, у которой >3000 весов. Не трудно представить, какие требуются ресурсы для обучения такой сети на более-менее объёмной истории (1000-2000 примеров).
1) Ускорение будет, работа над оптимизатором языка ещё не завершена.
2) Имелись в виду EX5 библиотеки, код в них естественно не вставить.