Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
MQL5 код собранный на х32 проигрывает по скорости работы по сравнению с х64 кодом - так как терминал х64 использует более мощную систему оптимизации кода.
Да, помню, Ринат об этом говорил. Кстати, доделываю тест с цифровым фильтром, это уже ближе к реальной работе, а не какое-то вычисление PI. Проверим...
---
А насчет, где взять версию 32-бит, ну неужели лень потратить 10 минут на установку виртуалки с 32-битной виндой? Вот не понимаю людей...
Существует ли в природе 32 битная версия MetaTrader5? Просто есть в наличии VPS с 32 битной Windows. Ключ /32 уже не помогает.
Скорее у вас нет никакой 32 битной vps, так как на 32 битной операционке автоматически поставится 32 битная версия терминала.
Вообще конечно это полная дикость и непонимание реальности ставить 32 битные версии в 64 битном окружении. Там не просто экономии ресурсов нет, на что надеются люди, но и реально тормознее итоговое решение. Если говорить об MQL5, то разница в скорости кратная вплоть до 20 раз.
Мы полностью нацелены на полное вытестение 32 битных версий МТ5 программ:
Скорее у вас нет никакой 32 битной vps, так как на 32 битной операционке автоматически поставится 32 битная версия терминала.
Вообще конечно это полная дикость и непонимание реальности ставить 32 битные версии в 64 битном окружении. Там не просто экономии ресурсов нет, на что надеются люди, но и реально тормознее итоговое решение. Если говорить об MQL5, то разница в скорости кратная вплоть до 20 раз.
т е VPS на которой установлена Windows 2003 это по вашему 64 битная операционка? (хотя есть и такие варианты но их мало).
По поводу 64-битности: если я тестирую на 64 битном терминале на домашнем компе и почему у меня не должно быть альтернативы оставить в 32-битном окружении уже отлаженного советника, которому не требуется супермега пупер ресурсов для работы.
Один и тот же скрипт можно сгенирировать какими либо генераторами стратегий или написать так что он будет требовать очень много ресурсов, а можно его написать более компактно (с минимальным количеством вызова ресурсоёмких подпрограмм) и ваше преимущество скорости 64 битных программ испарится.
Так что не судите строго - я просто попросил
Мы полностью нацелены на полное вытестение 32 битных версий МТ5 программ:
+++ Уже года так с 2009 на 64-битных операционках, ужетогда смысла в 32-бит не было. Ну а сейчас просто анахронизм.
Сейчас тесты доделаю с ЦФ, мне интересно другое - насколько будет быстрее или, наоборот, медленнее делать расчеты в float вместо double.
И еще попробую тряхнуть стариной, когда-то работал с DSP без FPU, приходилось работать в сетках типа 4.28 в формате int. Хотя на новых процах сейчас FPU быстрое, но интересно.
т е VPS на которой установлена Windows 2003 это по вашему 64 битная операционка? (хотя есть и такие варианты но их мало).
По поводу 64-битности: если я тестирую на 64 битном терминале на домашнем компе и почему у меня не должно быть альтернативы оставить в 32-битном окружении уже отлаженного советника, которому не требуется супермега пупер ресурсов для работы.
Один и тот же скрипт можно сгенирировать какими либо генераторами стратегий или написать так что он будет требовать очень много ресурсов, а можно его написать более компактно (с минимальным количеством вызова ресурсоёмких подпрограмм) и ваше преимущество скорости 64 битных программ испарится.
Так что не судите строго - я просто попросил
Вы утверждаете, что 32 битном windows 2003 не поставилась 32 битная платформа? Не верю
Альтернатива стоит денег и ее больше не будет как по экономическим, так и по технологическим причинам.
+++ Уже года так с 2009 на 64-битных операционках, ужетогда смысла в 32-бит не было. Ну а сейчас просто анахронизм.
Сейчас тесты доделаю с ЦФ, мне интересно другое - насколько будет быстрее или, наоборот, медленнее делать расчеты в float вместо double.
И еще попробую тряхнуть стариной, когда-то работал с DSP без FPU, приходилось работать в сетках типа 4.28 в формате int. Хотя на новых процах сейчас FPU быстрое, но интересно.
Математические расчеты во флоате делать категорически нельзя.
Еще в 2000 году я смеялся над "королем аналитики" MetaStock, у которого внутреннее представление данных баров и математики было float. Там дикие погрешности были уже при сложении десятка чисел, а индикаторы просто плавали по сравнению с нашим тогдашним FX Charts. Другой "король" Tradestation вообще в вычислениях постоянно переполнялся и выдавал откровенные ошибки.
Да и double слабоват и для точной математики не подходит. Мы уже думали над включением 80 битных вещественных чисел в качестве штатного формата данных.
Ладно если затронули тему float и double.
Можно ли использовать int (int32 или int64)? Просто использовать пункты. Даже такой момент как a = b, на целочисленных данных работает значительно быстрее.
Во многих моментах мы используем double co значением от 0 до 1, и максимум точность в 15—17 десятичных цифр. А вот в int64 точность уже 18-20 десятичных чисел.
Я не против 64 бит. Я против необдуманного перерасхода ресурсов.
Ладно если затронули тему float и double.
Можно ли использовать int (int32 или int64)? Просто использовать пункты. Даже такой момент как a = b, на целочисленных данных работает значительно быстрее.
Но сейчас на х64, с полным фаршем SSExxx смысла переводить в целочисленную математику нет никакого. Там дикие расходы ресурсов памяти и процессора на двойную перекодировку. А если нет перекодировки в нормальный формат(а такая перекодировка вынуждена), то считайте, что у вас остается только область узкой наколенной математики без связи с внешним миром.
И int64 вам не поможет на переполнениях. Фактически каждый алгоритм на int64 должен иметь доказательства, что не будет переполнений. Что практически невозможно, даже если у вас есть простой цикл с неизвестным количеством итераций.
Общая мысль: большинство методов оптимизаций из 199х годов нужно выкинуть. Все кардинально поменялось. Пишу это, так как сам с 1990 года бился за каждый байт и такт ускорения. И сейчас тем же самым занимаюсь, но на более важном уровне.