MQL5 vs V8 - страница 4
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Честно говоря скорость - это последнее что меня волновало. Если недостаточно производительности компьютера, то можно купить более быстрый, мало одно ядра купите двух-шести и более ядерный и N процессорный, можно перенести вычисления в графический процессор, на другие компьютеры. Есть куча других способов нарастить аппаратную производительность.
И это говорится про заранее тормозной язык, который еле-еле позволяет управлять серьезным количеством объектов в броузере? :)
Потеря скорости в разы - это еще цветочки. А вот потери ресурсов по памяти при оперировании с объемами выборок в сотню мегабайт вообще вынесут этот V8 (в котором нет явного управления памятью, а лишь неявный Garbage Collector) в зону невозможности применения.
Никакой графический процессор для базовой (стандартной нематричной и немассовой) математики не поможет. Это к тому, что "куча других способов нарастить аппаратную производительность" является маркетинговым бредом производителей, пытающихся пристроить свои продукты (речь об CUDA) куда угодно. Аппаратно производительность обычно повышают на десяток (грубо) процентов в год, а вот алгоритмически (софтверно) производительность обычно повышают в разы или десятки раз.
Но! Только если язык позволяет вынести вычисления за рамки платформы с минимальными накладными издержками. Меня в большей мере беспокоят возможности языка, как такового. Придется ли опять придумывать всевозможные подпорки для конструкций, которые стали базовыми во многих других языках или по крайней мере существуют эффективные реализации - работа с регулярными выражениями, хэш таблицы, объекты/классы со свойствами и методами, исключения, передача неопределенного количества параметров в функции, приведение типов, перегрузка функций, беспроблемный вызов системных и других внешних библиотек и прочее, прочее.
MQL5 - это упрощенный C++ язык. Куда уж стандартнее и понятнее? А вот дополнительный функционал в виде библиотек (математика, списки, коллекции, хеши и тд) будет доступен в исходниках.
Честно говоря скорость - это последнее что меня волновало. Если недостаточно производительности компьютера, то можно купить более быстрый, мало одно ядра купите двух-шести и более ядерный и N процессорный, можно перенести вычисления в графический процессор, на другие компьютеры. Есть куча других способов нарастить аппаратную производительность.
Но! Только если язык позволяет вынести вычисления за рамки платформы с минимальными накладными издержками. Меня в большей мере беспокоят возможности языка, как такового. Придется ли опять придумывать всевозможные подпорки для конструкций, которые стали базовыми во многих других языках или по крайней мере существуют эффективные реализации - работа с регулярными выражениями, хэш таблицы, объекты/классы со свойствами и методами, исключения, передача неопределенного количества параметров в функции, приведение типов, перегрузка функций, беспроблемный вызов системных и других внешних библиотек и прочее, прочее.
Очень похоже на программирование ради программирования, т.е. самоценность процесса как такового.
Потеря скорости в разы - это еще цветочки. А вот потери ресурсов по памяти при оперировании с объемами выборок в сотню мегабайт вообще вынесут этот V8 (в котором нет явного управления памятью, а лишь неявный Garbage Collector) в зону невозможности применения.
Да, согласен, что явная работа с памятьюболее эффективно чем использование мусоросборщика, который с другой стороны прощает ошибки разработчика. У меня нет никакой информации на эффективность реализации работы с памятью в движке V8.
Никакой графический процессор для базовой (стандартной нематричной и немассовой) математики не поможет. Это к тому, что "куча других способов нарастить аппаратную производительность" является маркетинговым бредом производителей, пытающихся пристроить свои продукты (речь об CUDA) куда угодно. Аппаратно производительность обычно повышают на десяток (грубо) процентов в год, а вот алгоритмически (софтверно) производительность обычно повышают в разы или десятки раз.
Маркетинг да, бывает туманит наши мозги. Необходимость использования сопроцессорных или распределенных вычислений зависит от конкретного алгоритма. И вы же не будете отрицать, что генетические алгоритмы и многие
классифицирующие алгоритмы работающие на N-мерных данных как раз хорошо распараллеливаются и задействуют матричные вычисления.
MQL5 - это упрощенный C++ язык. Куда уж стандартнее и понятнее? А вот дополнительный функционал в виде библиотек (математика, списки, коллекции, хеши и тд) будет доступен в исходниках.
Вот я и боюсь этого упрощения. Как бы с водой не выплеснуть и ребенка. MQL4 - тоже упрощенный Си, сильно упрощенный...
Ну это уже не смешно. ...цать лет опыта разработки не дает Вам права плевать на всех с высокой колокольни. Я тоже не мальчик.
Я ни в коей мере не хотел вас оскорбить. Мы все сильны в чем-то и слабы в другом. Я тоже не дорос до многих вещей. Если вас задели мои слова, то приношу свои извинения.
Очень похоже на программирование ради программирования, т.е. самоценность процесса как такового.
Процесс тоже должен приносить удовольствие.
Renat, поясните, пожалуйста, свою точку зрения по этому поводу:
Никакой графический процессор для базовой (стандартной нематричной и немассовой) математики не поможет. Это к тому, что "куча других способов нарастить аппаратную производительность" является маркетинговым бредом производителей, пытающихся пристроить свои продукты (речь об CUDA) куда угодно.
И что вы имели в виду здесь:
MQL5 - это упрощенный C++ язык. Куда уж стандартнее и понятнее? А вот дополнительный функционал в виде библиотек (математика, списки, коллекции, хеши и тд) будет доступен в исходниках.
И что вы имели в виду здесь:
Renat писал(а) >>
MQL5 - это упрощенный C++ язык. Куда уж стандартнее и понятнее? А вот дополнительный функционал в виде библиотек (математика, списки, коллекции, хеши и тд) будет доступен в исходниках.
Я не Ренат, но по-моему тут ответ достаточно очевиден - то же самое, что сейчас есть в терминале. Индикаторы реализованные нативно, также реализованы на MQL4 и эти исходные коды свободно доступны для изучения и модификации. Загляните в папку вашего терминала - они там должны лежать. То же самое видимо будет и с MQL5. Хорошая практика.
Маркетинг да, бывает туманит наши мозги. Необходимость использования сопроцессорных или распределенных вычислений зависит от конкретного алгоритма. И вы же не будете отрицать, что генетические алгоритмы и многие
классифицирующие алгоритмы работающие на N-мерных данных как раз хорошо распараллеливаются и задействуют матричные вычисления.
Генетические алгоритмы - это алгоритмическая (софтверная) оптимизация.
Сложные матричные расчеты требуют абсолютно нетривиального и кропотливого переписывания под тот же самый CUDA. Что практически недоступно непрофессиональным (не GPU программерам) разработчикам. А ускорение вообще не гарантировано, особенно с учетом того, что в том же самом CUDA базовая математика - это float (этого хватает для оперирования цветов в графике), а не double. В математике float ну никак не подходит (ибо точность никакая), даже на double некоторые плюются.
Применение CUDA в расчетах останавливает вот что (на CUDA 2.0, GT200):
Что касается вычислений с двойной точностью(double), их скорость на текущем аппаратном поколении ниже одинарной точности в несколько раз.
....
Реально производительность может быть даже ещё меньше, так как архитектура оптимизирована для 32-битного чтения из памяти и регистров, кроме того, двойная точность не нужна в графических приложениях, и в GT200 она сделана скорее для того, чтобы просто была.
Бенчмарки (расчитанные на float математике) GPU при переписывании под double сольют по полной и вполне вероятно, что никакого ускорения вообще не будет. Скорее даже падение производительности будет.
Я даже не говорю о стоимости времени копирования 50-100 мегабайт исторических данных во внутреннюю память видеокарты, а потом возвращения результата назад в оперативку. И так для 10-20 индикаторов на каждый тик. Не забывайте, что видеокарта еще и по прямому назначению применяется, перерисовывая великолепие интерфейсов некоторых операционок :)
TedBeer : +2
Сам хотел высказать такую же идею - джава есть - цепляйте JNI -
Java машина только вызовы раздает, ошибки там не дождетесь.
Кроме того, я что-то не понимаю, или джава машина Sun стала OpenSource GPLv2 ?
.
Когда пытался сунуть сишный файл в mql4, вдруг оказалось, что в компиляторе
mql4 даже с циферками проблема :-), а щас в mql5 добавят еще и кастомное
наследование override / hide :-), так сказать, самобытное, не по спецификации -
а по своему разумению.
.
Тонкости:
Обработка унарного оператора: в mql4 написать int y = -+3; это проблема, в java - не проблема
int h = -9 * -8; - опять в mql4 - проблема, в java - не проблема
double h = .8; - в mql4 компилируется (удивительно!), но double h = .8 * .5; - это проблема, в java - не проблема
double h = -.8; - в mql4 - проблема - программист решил, что нефиг точку ставить после минуса (!), в java - не пролема.
Не знает разработчик ответ на вопросы "как задать число с плавающей точкой", "что такое унарные операторы языка Си".
.
Можно "залатать" эти конкретные прорехи...
но отсутствие спецификации и специалистов по парсерам / лексерам - оставит еще множество таких ляпов.
.
Да напишите просто программу
...если разработчику языка программирования никто не объяснил, почему компилятор должен выдать
А не
То стоит ожидать по меньшей мере новых парадигм программирования...
.
Можете написать
Если опять есть вопрос почему оно должно работать - это опять же, странно.
Доказан тезис о том, что программировать можно и не зная базовых основ языка.
.
Это, по большому счету, для себя можно писать такие компиляторы.
.
У меня начальник на мое поделье улыбался и сказал пару слов - лексер, парсер...
Я про себя обозвал начальника дураком - программа-то работала (!).
Смысл его слов дошел до меня года через 3...
Но моя работа была именно поделкой.
А ведь Mql4 по уровню от этой поделки недалеко ушел.
И никто не признается, что это именно поделка - говорят, продукт (!).
Но ведь вся стратегия компании Metaquotes строится именно на языке mql4...
.
P.S.:
перед разработкой своего языка очень неплохо изучить хотя бы один существующий язык.
Еще лучше - сертификацию пройти.
.
P.S.2:
Но мотивацию разработчиков понять можно :-)
.
P.S.3:
Интересно, что ответят на это сообщение разработчики? ;-)
.
RTFM.
P.S.3:
Интересно, что ответят на это сообщение разработчики? ;-)