MQL5 vs V8 - страница 4

 
TedBeer >>:


Честно говоря скорость - это последнее что меня волновало. Если недостаточно производительности компьютера, то можно купить более быстрый, мало одно ядра купите двух-шести и более ядерный и N процессорный, можно перенести вычисления в графический процессор, на другие компьютеры. Есть куча других способов нарастить аппаратную производительность.

И это говорится про заранее тормозной язык, который еле-еле позволяет управлять серьезным количеством объектов в броузере? :)

Потеря скорости в разы - это еще цветочки. А вот потери ресурсов по памяти при оперировании с объемами выборок в сотню мегабайт вообще вынесут этот V8 (в котором нет явного управления памятью, а лишь неявный Garbage Collector) в зону невозможности применения.


Никакой графический процессор для базовой (стандартной нематричной и немассовой) математики не поможет. Это к тому, что "куча других способов нарастить аппаратную производительность" является маркетинговым бредом производителей, пытающихся пристроить свои продукты (речь об CUDA) куда угодно. Аппаратно производительность обычно повышают на десяток (грубо) процентов в год, а вот алгоритмически (софтверно) производительность обычно повышают в разы или десятки раз.

Но! Только если язык позволяет вынести вычисления за рамки платформы с минимальными накладными издержками. Меня в большей мере беспокоят возможности языка, как такового. Придется ли опять придумывать всевозможные подпорки для конструкций, которые стали базовыми во многих других языках или по крайней мере существуют эффективные реализации - работа с регулярными выражениями, хэш таблицы, объекты/классы со свойствами и методами, исключения, передача неопределенного количества параметров в функции, приведение типов, перегрузка функций, беспроблемный вызов системных и других внешних библиотек и прочее, прочее.

MQL5 - это упрощенный C++ язык. Куда уж стандартнее и понятнее? А вот дополнительный функционал в виде библиотек (математика, списки, коллекции, хеши и тд) будет доступен в исходниках.

 
TedBeer писал(а) >>

Честно говоря скорость - это последнее что меня волновало. Если недостаточно производительности компьютера, то можно купить более быстрый, мало одно ядра купите двух-шести и более ядерный и N процессорный, можно перенести вычисления в графический процессор, на другие компьютеры. Есть куча других способов нарастить аппаратную производительность.

Но! Только если язык позволяет вынести вычисления за рамки платформы с минимальными накладными издержками. Меня в большей мере беспокоят возможности языка, как такового. Придется ли опять придумывать всевозможные подпорки для конструкций, которые стали базовыми во многих других языках или по крайней мере существуют эффективные реализации - работа с регулярными выражениями, хэш таблицы, объекты/классы со свойствами и методами, исключения, передача неопределенного количества параметров в функции, приведение типов, перегрузка функций, беспроблемный вызов системных и других внешних библиотек и прочее, прочее.

Очень похоже на программирование ради программирования, т.е. самоценность процесса как такового.

 
Renat >>:

Потеря скорости в разы - это еще цветочки. А вот потери ресурсов по памяти при оперировании с объемами выборок в сотню мегабайт вообще вынесут этот V8 (в котором нет явного управления памятью, а лишь неявный Garbage Collector) в зону невозможности применения.

Да, согласен, что явная работа с памятьюболее эффективно чем использование мусоросборщика, который с другой стороны прощает ошибки разработчика. У меня нет никакой информации на эффективность реализации работы с памятью в движке V8.


Никакой графический процессор для базовой (стандартной нематричной и немассовой) математики не поможет. Это к тому, что "куча других способов нарастить аппаратную производительность" является маркетинговым бредом производителей, пытающихся пристроить свои продукты (речь об CUDA) куда угодно. Аппаратно производительность обычно повышают на десяток (грубо) процентов в год, а вот алгоритмически (софтверно) производительность обычно повышают в разы или десятки раз.

Маркетинг да, бывает туманит наши мозги. Необходимость использования сопроцессорных или распределенных вычислений зависит от конкретного алгоритма. И вы же не будете отрицать, что генетические  алгоритмы и многие 

классифицирующие алгоритмы работающие на N-мерных данных как раз хорошо распараллеливаются и задействуют матричные вычисления.


MQL5 - это упрощенный C++ язык. Куда уж стандартнее и понятнее? А вот дополнительный функционал в виде библиотек (математика, списки, коллекции, хеши и тд) будет доступен в исходниках.


Вот я и боюсь этого упрощения. Как бы с водой не выплеснуть и ребенка. MQL4 - тоже упрощенный Си, сильно упрощенный...

 
TheXpert >>:

Ну это уже не смешно. ...цать лет опыта разработки не дает Вам права плевать на всех с высокой колокольни. Я тоже не мальчик.


Я ни в коей мере не хотел вас оскорбить. Мы все сильны в чем-то и слабы в другом. Я тоже не дорос до многих вещей. Если вас задели мои слова, то приношу свои извинения.

 
Vita >>:

Очень похоже на программирование ради программирования, т.е. самоценность процесса как такового.

Процесс тоже должен приносить удовольствие. 

 

Renat, поясните, пожалуйста, свою точку зрения по этому поводу:

Renat >>:

Никакой графический процессор для базовой (стандартной нематричной и немассовой) математики не поможет. Это к тому, что "куча других способов нарастить аппаратную производительность" является маркетинговым бредом производителей, пытающихся пристроить свои продукты (речь об CUDA) куда угодно.


И что вы имели в виду здесь:

Renat >>:

MQL5 - это упрощенный C++ язык. Куда уж стандартнее и понятнее? А вот дополнительный функционал в виде библиотек (математика, списки, коллекции, хеши и тд) будет доступен в исходниках.

 
mql4com >>:

И что вы имели в виду здесь:

Renat писал(а) >>

MQL5 - это упрощенный C++ язык. Куда уж стандартнее и понятнее? А вот дополнительный функционал в виде библиотек (математика, списки, коллекции, хеши и тд) будет доступен в исходниках.

Я не Ренат, но по-моему тут ответ достаточно очевиден - то же самое, что сейчас есть в терминале. Индикаторы реализованные нативно, также реализованы на MQL4 и эти исходные коды свободно доступны для изучения и модификации. Загляните в папку вашего терминала - они там должны лежать. То же самое видимо будет и с MQL5. Хорошая практика.

 
TedBeer >>:

Маркетинг да, бывает туманит наши мозги. Необходимость использования сопроцессорных или распределенных вычислений зависит от конкретного алгоритма. И вы же не будете отрицать, что генетические алгоритмы и многие

классифицирующие алгоритмы работающие на 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 - не пролема.

Не знает разработчик ответ на вопросы "как задать число с плавающей точкой", "что такое унарные операторы языка Си".

.

Можно "залатать" эти конкретные прорехи...

но отсутствие спецификации и специалистов по парсерам / лексерам - оставит еще множество таких ляпов.

.

Да напишите просто программу

void f() { double k = 0 }
int start() { }

...если разработчику языка программирования никто не объяснил, почему компилятор должен выдать

File.mq4: 18: ';' expected

А не

'\end_of_program' - incomplete initialization File.mq4

То стоит ожидать по меньшей мере новых парадигм программирования...

.

Можете написать

int i = 9;
int j = 9 + ++i;

Если опять есть вопрос почему оно должно работать - это опять же, странно.

Доказан тезис о том, что программировать можно и не зная базовых основ языка.

.

Это, по большому счету, для себя можно писать такие компиляторы.

.

У меня начальник на мое поделье улыбался и сказал пару слов - лексер, парсер...

Я про себя обозвал начальника дураком - программа-то работала (!).

Смысл его слов дошел до меня года через 3...

Но моя работа была именно поделкой.

А ведь Mql4 по уровню от этой поделки недалеко ушел.

И никто не признается, что это именно поделка - говорят, продукт (!).

Но ведь вся стратегия компании Metaquotes строится именно на языке mql4...

.

P.S.:

перед разработкой своего языка очень неплохо изучить хотя бы один существующий язык.

Еще лучше - сертификацию пройти.

.

P.S.2:

Но мотивацию разработчиков понять можно :-)

.

P.S.3:

Интересно, что ответят на это сообщение разработчики? ;-)

.

RTFM.

 
jartmailru >>:

P.S.3:

Интересно, что ответят на это сообщение разработчики? ;-)

Разработчики только улыбнутся на Вашу наивность. :)