Опять вопрос про быстродействие. - страница 5

 
Academic:
В смысле? Я хочу Вас поэксплуатировать? "Заставить" по работать? Да ну, бросьте. :) не смешите. Я просто уверен, что Вы даже не вникли в то что тот индикаторр делает. Посмотрите, это в чем-то грааль. :) Это ИМХО ( при определенных и весьма существенных, и далеко не для всех приемлимых по финансовым причинам ) одна и не многих прибыльных стратегий на "случайном" шумном рынке таком как форекс.

))) с Вашим появлением на форуме я стал чаще улыбаться

Спасибо

 
Academic:
Ну нужно не получение на нулевом баре. Посмотрите ( сохраните и запустите на графике ) индикатор который я показал. Надо как минимум четыре точки ZigZag

Стоп, вы КАЖДЫЙ РАЗ после КАЖДОЙ ЗАГРУЗКИ ищете точки? И хотите, чтобы это быстро пахало?

Тогда вам надо как минимум выражать больше уважения к собеседникам и меньше уверенности в собственных силах :) .

 
Integer:

Наверно что-то такое было в четверке, но в ней память загружалось несколько индикаторов с одинаковыми наборами параметров (если они вызывались из разных программ). А здесь только один индикатор загружается, но пользоваться им могут все. Это экономит память. Тики  по разным символам идут не синхронно, из советника работающего на одном символе при обращении к индикатору с другого символа можно нарваться на процесс его расчета... Выполнять расчет непосредственно при обращении к индикаторы - от этого как раз ушли, индикатор живет собственной жизнью и вычисляется только один раз при тике по своему символу, а не всегда, когда к нему кто-то обращается. И т.д. и т.п. Можно много рассуждать, думаю, что MQ лучше знают как писать терминалы.

 

Это не проблема, если таких вещей бояться, то тогда точно надо обращаться к специалисту по высокопроизводитльному вычислению. Такой подход ведет в тупик. 300 советеников пользуются одним индикатором и каждый скопирует себе его буфер, это по сути ровно тоже самое что и запускать каждый отдельный индикатор. Суть ровно таже самая, тут только иллюзия оптимального использования. Что 300 раз скопировать буфер быстрее на каждый тик, чем 300 раз насчитать индикатор без организации изоляции доступа к данным?

Еще раз - если уж есть компилятор, то можно просто например "занопить" ( выкинуть ) операции записи в буфер индикатора. Это КОЛОСАЛЬНОЕ повышение быстродействия и памяти. Все же в руках компилятор.

 
TheXpert:

Стоп, вы КАЖДЫЙ РАЗ после КАЖДОЙ ЗАГРУЗКИ ищете точки? И хотите, чтобы это быстро пахало?

Тогда вам надо как минимум выражать больше уважения к собеседникам и меньше уверенности в собственных силах :) .

Выражаю уважение.

но тем не менее -

А кто сказал что ZigZag не перерисовывается - он именно что перерисовывается. :)

 
2011.02.04 15:56:09 Core 1 EURUSD,M1: 793434 ticks (12818 bars) generated within 22558 ms (total bars in history 401341, total time 26442 ms)
2011.02.04 15:56:09 Core 1 OnTester result 0

2011.02.04 15:55:48 Core 1 2011.01.24 00:00:00   Array out of range in 'is40x.mq5' (87,17)

вот такую ошибку выдает  


 
Academic:

А кто сказал что ZigZag не перерисовывается - он именно что перерисовывается. :)

))) Вы его алгоритм посмотрите.... только последний луч может....

т.е. последняя точка

 
Academic:

Выражаю уважение.

Уже лучше :)

Надеюсь, помогу, если скажу, что знаю как сделать это раз в 10 быстрее?

 
AlexSTAL:

))) Вы его алгоритм посмотрите.... только последний луч может....

т.е. последняя точка

Ну дак о том и речь. :)
 
TheXpert:

Уже лучше :)

Надеюсь, помогу, если скажу, что знаю как сделать это раз в 10 быстрее?

Ну тут как бы именно что помощь то и не требуется - требуется понять "подход" как делать быстрее для перерисовывающихся индикаторов ( в том числе ) . :)
 
Academic:

Это не проблема, если таких вещей бояться, то тогда точно надо обращаться к специалисту по высокопроизводитльному вычислению. Такой подход ведет в тупик. 300 советеников пользуются одним индикатором и каждый скопирует себе его буфер, это по сути ровно тоже самое что и запускать каждый отдельный индикатор. Суть ровно таже самая, тут только иллюзия оптимального использования. Что 300 раз скопировать буфер быстрее на каждый тик, чем 300 раз насчитать индикатор без организации изоляции доступа к данным?

Еще раз - если уж есть компилятор, то можно просто например "занопить" ( выкинуть ) операции записи в буфер индикатора. Это КОЛОСАЛЬНОЕ повышение быстродействия и памяти. Все же в руках компилятор.

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

 

Причина обращения: