при работе с одним скриптом и изменении в нем только значения периода с последующей оптимизацией замечен глюк "скорости"

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

система XP32 sp3 Intel core 2 duo доступной RAM для программы 2049 гигобайта использует не более 500 хотя в настройках указал возможность 1024мег , потоков в опциях для оптимизации по умолчанию 0

А окна с выполненными оптимизациями закрываете? Или "копите"? Лучше закрывать.
1024 - это хорошо, но fram все равно не даст использовать больше 1000 если винда 32. Попробуйте поставить 256 вместо 1024, обновление будет чаще, может поможет ... Потоков в Вашем случае надо поставить 1, если комп будет "тянуть" и прога не будет выбрасываться с непонятными окнами, тогда со временем попробуйте 2.

да окна закрываю оптимизация 10 000 вариантов в первых пару запусков проходит за 10-15 секунд а после за минуту , полторы и все медленнее до 5 минут и больше
при этом загрузка проца в первые разы под 90% а когда тормозит только 50%
в настройках потоков для оптимизации пытался ставить 1,2,3
не чего по сути не меняло ни ускоряло ни замедляло все так же пару раз быстро а потом медляк
спасает только полный выход из программы при чем когда выходишь приходиться прилично ждать, сама программа закрывается за долю сек но если войти сразу то в логах пишет что не может запуститть скрипты и так красным несколько строк
не могу запустить скрипт
а если подождать подольше пару минут то все ок и скорость оптимизации востанавливается

P.S.в винде 32 любая прога может получить реальной оперативки до 2 гигов а не 1 гиг как вы пишите, если она имеется свободная конечно, у меня 2465мегов свободной ram не считая свапа по менеджеру процессов TSLAB при оптимизации максимум что я видел брал под себя 600мегов

примерно 1 гб - ограничение NET Framework, связанное с резервированием памяти под сборку мусора. Проявляется в том, что при занятии приложением 1-1.2гб начинают идти OutOfMemoryException (не хватка памяти). 2гб - 32бит NET Framework не может занять.

А комп Ваш не ноут ли часом? Какая температура процессоров после второй оптимизации? Вообще странно, я думаю у Вас на самом деле все в порядке, скорее, то , что Ваш копьютер 10000 проходов за 10 секунд делает - вот это что-то непонятное. Да и 5 минут для 10000 проходов это что то очень хороший показатель. У меня 4 ядра с такой скоростью не считают. Хотя кол-во свечей же ....

4 гигагерца 4 гигабайта ram шина памяти 1200 магагерц со мной по тестам на равне идут только 8 процессорные машины но оптимизация обычно только под 2 проца так что у меня приоритет обычно да и для мусора у меня в RAM виртуальный диск на 1 гиг создан

проц совсем не греется по сравнению с Orthos и S&M

да и оптимизировал я всего недельку в тиках

все же явная проблема не очень удобно все время программу перезапускать
может вы оптимизацию в виде внешней библиотеки на С написалибы?
и уж побыстрей было и глюков поменьше

Товарищи разработчики, я то же промоделировал эту ситуацию!
Простой скрипт пересечение средних, часовик. Начинаем оптимизацию с 01/07/06 по 01/10/06, т.е. за три месяца(не так много данных).Время оптимизации 25 секунд. Моделируем торговлю с 01/10/06 по 01/11/06, т.е. за месяц. Далее снова оптимизация 01/08/06 по 01/11/06 за три месяца, время оптимизации 34 секунды, меняем даты на с 01/11/06 по 01/12/06, смотрим что скрипт сделал за месяц. Далее снова оптимизация, вообщем смысл понятен ... На пятой оптимизации время составляло уже 2 минуты.. На восьмой 3 минуты. Так что баг имеет место быть! XP32 SP3 4 по 2.4 8ram Настройки tslab: 4 потока 1024гб
P.S. Правда после 11 раза время стабилизировалось в районе 3 мин 20 секунд

" Настройки tslab: 4 потока 1024гб"
т.е. кеш 1гб?
А версия 64бит используется?

Гонял сейчас 29тыщ свечей на 2MA. 10тыщ проходов.
Время стабильное - 10мин, +-20сек. Загрузка памяти TSLab тоже не растет, держится в районе 200-250мб.

Не 32

Не могли бы вы уменьшить кэш до 512 мб?

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

Ага! Когда просто большую историю с максимальным кол-вом проходом, то тормозов со временем не замечено. Время начинает прыгать, когда небольшое кол-во севечей небольшое, 380, кол-во проходов то же небольшое а даты меняются(у меня так)

512 то же самое

Приблизительно так же погонял вчера. Правда у меня чуть живее считал. То же ничего не заметил. И параметры менял. Движуху со временем начал замечать только когда стал изменять даты и параметры.

1024 поставил опытным путем. Система одинаково ебя ведет и при 512 и при 1024, ну разве что при расчетах с 512 чаще обновляется, но ни на скорость ни на стабильность никак не влияет(у меня так)

jarilo Вы то же только даты меняли?

Я неделю уже гоняю исторические текстовые данные.1999-2010.Добился результат на 10мин.Просадка макс.-6-7%.После решил проверит с эти ми же параметрами на этих же данных по годам отдельно.И получил в некоторых случаях просадку 23%-а это уже перебор.Или я что то не до понимаю в системе или это глюк.

Считаете одним лотом? Или фиксированным числом? С реинвестицией?

Если проверяли одним лотом, то ничего удивительного нет.
Когда проверяешь на 10ти годах - депозит мог вырасти в разы. Поэтому просадка в 200р с 1000р - это 20%, а когда зафиксирован профит в 5000р - то это всего 5%.
Надо тестировать включив режим "Имитация портфеля", чтобы количество лотов бралось от количества денег. Тогда примерно одинаково все будет.

Когда задан большой кеш на 32бит и много данных при оптимизации начинают идти OutOfMemoryException, а они тормозят сам процесс.
У вас памяти много, используйте 64бит версию. Правда она с Транзак не совместима, только текстовые данные можно будет использовать.

По умолчанию стоит.Я ничего не менял.Одними лотом.

Никогда не пользовал 64бит. Говорят там много проблем с установкой?

ну если XP - то 64бит не стоит брать, драйверов мало, а с вистой и вин7 никаких проблем нет.

Не пудрите людям голову 64 битами они нужны только для специальных приложений требующих 64 и более гигобайта памяти и специально под это заточенные фаша нетвраимворк от 64 бит лучьше работать не станет а вот проблем люди поимеют по тому как 64 бита не для домашнего использования только для специальных нужд от сюда и проблемы совместимости и прочее у людей половина программ перестанет нормально работать потому как ни кто не оптимизирует под работу в 64 бит винде
не говоря уж того насколько все 64 бит версии сырые по сравнению с 32 битными вылезаннами потому как и процент использования 32/64 где то 10%/90%
даже не думайте а то наслушаетесь а потом погрязнете только в одинх проблемах этих "масдаев"
P.S. Не знаете что посоветовать лучьше промолчите.

в опциях параметр количество потоков 0,1,2,3
и кеш для скриптов 256,512,1024
не производят ни каких сколько нибудь заметных глазом изменений

и памать TSLAB не хочет забирать больше 250 мегов плюс вирт 450

зато заметил при закрывании полностью программы и наблюдении этого процесса в таскменеджере видно что процесс TSLAB продолжает висеть после закрытия программы еще целую минуту при этом видно как он в момент выхода из программ сразу высвобождает порядка 50-70 мегов а с остальной памятью висит и грузит процессор от 20 до 50% видать это все теже его попытки очистить память что и во время оптимизации (может и нет это моя догадка)

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

проясните ситуацию с внешними данными если используется источник данных "текстовый фаил" взятый с финама по этой технологии
http://www.tslab.ru/ubb/ubbthreads.php?ubb=showflat&Number=635&nt=4&page=1

то расчет оптимизации и график строится основываясь только на импортированном текстовом файле ????

я опытным путем убедился что это не так! если не выбраны даты "от" и "до" то источником не смотря на то что выбран текстовый файл является вся накопленная история в TSLAB

это нормально ? мне кажется нет, уж если выбран за источник внешний фаил то и все расчеты и график должны быть произведены из его данных не смотря на даты иначе какой то венегрет из данных получается

Да бардак вообще с оптимизацией.Хоть лотом хоть суммой и хоть расчётной цифрой.Всё равно на исторических данных просадка считается от конечной цифры прибыли а не от фактической на момент просадки.Скрипты показывающие 5-8% просадки на десятилетнем графике 10мин.Потом на одно или двух летнем дают до 23% лося.А на том что открывается в онлайн 16%.
Может я опять что то перепутал но это мне кажется не правильно.
Смысл тестировать на больших графиков вообще отсутствует.Только в моменте если что отстроить так на это у вас нет секундных данных нормальных.

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

а при выбранном источнике TRANSAQ моглибы уж сделать предупреждающее окно при попытке выбора секунд и тиков что этот источник таких данных не потдерживает

и исправте при выбранном внешнем чтоб только из него данные были а то оптимизируешь как ребенок на какихто выдуманных разрозненых исторических данных будто поиграться сделали так что не поймешь что вообще использузет TSLAB за историю
а это самое основное если данные неверны истории то какие тогда можно сделать на их основе заключения ??!!!!

Какой должен быть комп вообще?Допустим 100000 проходов что бы делал за несколько минут.1000000 проходов для моего пк вообще фантастика.Может где то в аренду есть такие супер пк.?.В выходные так погрузить несколько часов супер комп.

У нас крутится идейка использовать облачные вычисления.
Причем технологически у нас все для этого есть.
Из TSLab выделяются необходмые модули движка оптимизации размещается в облаке и делается сервис для Клиентов.
Например Azure.

Далее вопросы в студию :-)
1. Безопасность скрипта, размещенного на внешней площадке.
Необходимо сделать контейнер и зашивровать его. Сделать можно.
2. Azure стоит денег. Плюс что-то захочет TSLab за сервис. Короче денег будет стоить :-)
3. Исходя из пункта 1-2, никому не доверяю свой супер-мега скрипт + денег стоит сервис, не купить ли мега комп о 4 головах и спать спокойно ?

Такие мысли. Возможно в некотором будущем все это и реализуется, если будет спрос. Люди естественным образом дозреют до скриптов сильно сложнее чем 2MA и компов о 4 головах перестанет хватать, возникнет потребность в кластере, ну и тд ... :-)

Это вполне логично.Я завтра поеду на радио рынок к самоделкину по поводу абгрейда.По этому интересуюсь какие нужны параметры.Вообще я так понял чем больше тем лучше.Минимум 4головы и 4 памяти.А дальше как позволяет бюджет.

У меня до си пор просто скрипт не получился даже.А у вас супер-мега.Это заслуживает уважения.Какими индикаторами рулится ваш скрипт?

Сколько индикаторов должны одновременно считать в хорошем скритпе.?

ОДИН! Но супер-мега, мега-супер!

С 4 головами, то же после 60000 проходов не ахти!
А вот так нельзя сделать?:

Как вы себе представляете запуск скрипта на языке c# из обычного си?

Если я правильно понял вопрос, то сейчас это совсем не проблема:
http://support.microsoft.com/kb/828736

Господа разработчики вы так и не ответили на весьма серьезный вопрос когда выбран внешний источник данных TSLAB использует данные откуда ей хочется и какие ей хочется понять на чем идет оптимизация не возможно!

Если вы выбрали в Менеджере Провайдеров Данных источник данных Tranzaq, то оптимизация идет только по данным с сервера Tranzaq.
Если вы выбрали текстовые файлы истории с Финама и подключили по этой статье
http://www.tslab.ru/ubb/ubbthreads.php?ubb=showflat&Number=635&nt=4&page=1
то оптимизация идет только по этим данным.
Если одновременно подключены оба источника данных, то Трейдер сам следит на чем он и что оптимизирует.

А что изменится от того, что си будет вызывать скрипт в виртуальной машине?

Было бы неплохо привести здесь путь, которым вы пришли, к этому заключению. На чем основано это утверждение.

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

вы случайно склейкой не пользуетесь данных?

вручную склеиваю и потом проверяю все дни начало и конец сессий с оригигнальными скачанными с финама файлами если хотите могу скинуть их вам скажите куда
но ошибка явно не отслеживается в TSLAB конкретный источник данных для истории

Ну так вы сами сказали, что склеиваете с финамовскими данными. Соответсвенно, если даты от и до не выставлены, то и будет браться все что есть.

в том то и дело что я думал что берется то что склеил и указал в источнике а берется на самом деле накопленная разрозненая история TSLAB вместо указанного файла !!!!!!!!!!!

можете расписать все настройки, как вы склеивали?
можно скриншотом

да при чем тут склеивание ?
можно и один день взять нечего не склеивая с финама
а проблема в том что в программе ошибка устал говорить, вместо указанного файла TSLAB использует свои набранные кое как за время подключений к серверу данные вместо файла, или точней вместе с этим фалом, создавая венегрет из данных

P.S. потратьте 3 минуты создайте источник из текстового файла и в простейшем скрипте укажите его использование но при этом посмотрите разницу между использованием даты "от" и "к" и без нее. На сколько я понимаю указание даты не должно менять источник а оно меняет если дата не выбрана TSLAB берет не только данные из файла но и свой накопленный венегрет

Если бы у меня получилось это повторить, я бы не писал здесь одно и тоже по нескольку раз. Я и пытаюсь понять, как вы этого добились. Как вообще могли данные из одного источника в другой попасть. Без принудительно склеивания это не возможно.

Это еще может быть из-за "разгона индикаторов". В ТС лабе индикаторы считаются с первой свечи, в не зависимости от их периода.

что могу сказать у меня тоже сейчас не получается это повторить
я правда за время обсуждения скачивал ваше обновление какое то в zip файле номер версии не поменялся 1.1.4.0 но в архиве были явно другие обновленные файлы я их сравнивал перед обновлением
еще и источники данных удалял и пересоздал заново

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

и почему вы используете дата "к" - как то не по русски я только опытным путем понял что это значит "до" не включая последнюю указанную дату, не правильней ли было использовать "до" или если изменить что последняя указанная дата включается то "по" ?

посмотрите вот на этом текстовом файле от финама при использовании его как источника данных на 2MA бар 5 минут EMA1 25 EMA2 65 скрипт пишет что он имеет 315943 бара ?? в логах
где он за неделю на 5 минутках нашел такое количество это как минимум 3 года ?
в тоже время в точности на таком же файле только на неделю раньше с 5 по 9 апреля скрипт пишет 505 баров и вроде нормально работает
в чем дело ?

вот и он решил тоже выложить

Это тиковые данные и там действительно 315943 бара (тика).
Ошибка была в том, что из-за наличия там постсессии (18.49) не правильно определялся интервал данных (5мин), вместо тиков.
Будет исправлено в сегодняшней сборке.

спасибо
а сборка будет автообновлением или вручную качать ?

Автообновление будет в четверг-пятницу.
Если нужно сейчас то вручную, после 21.00.

не правильно считается на вкладке скрипта "результаты"
"Чистый П/У%" он не учитывает количество которое можно задать в скрипте при открытии позиции
например если вместо количества 1 указать 20 то и "Чистый П/У%" умножится на 20
надо дописать в формулу чтоб делило на количество

Чистый П/У считается исходя из торговли одним лотом. Можно в скрипте иметь 10 разных позиций, одна будет торговать 1м лотом, другая 2, треятья 3мя и т.д.
Как в данном случае считать общий П/У в %?

получается торговля смешанным лотом так можно сложить все лоты и потом на их общее количество поделить так получиться процент на 1 смешанный лот
мне кажется лучше чем процент умноженный на количество лотов

версия TSLAB 1.1.4.16 вроде более стабильна в скорости оптимизации и научилась забирать памяти до 2 гигов но на этом ее опетит не останавливается и она вылетает с ошибками. процессор грузит лучше от 70 до 90% (раньше только первых 2 раза так а потом не более 50% загружала) и если раньше после двух оптимизаций торможение было уже чуть ли не в 2 раза то сейчас после десятка скорость падает процентов на 30-40 , очень точно не подсчитывал но гораздо быстрей к примеру 900 баров на 250000 вариантов за 6,5 минут
надо только если много оптимизируешь следить за тем сколько TSLAB уже скушала памяти когда подбирается к 2 гигам надо просто выходить и запускать ее заново но так лучше чем каждые 2 оптимизации )

Просьба - а не могли бы вы рядом с выводимым прогнозом времени по завершинию расчета выводить количество операций в секунду, по ним тормоза легче будет определить и прекинуть по этой цифре самому на сколько ставить проходов удобней
к примеру у меня вроде 641 опер/сек и если этот показатель сильно упадет пора произвести перезапуск программы ))

Еще замечено как писал раньше что TSLAB долгое время после закрытия программы высвыбождает память а при занятых 2 гигов мне даж ждать надоело (скорей всего это фраимворк так чудно мусор в памяти трет) так вот совет тем кто много оптимизирует - просто после закрытия программы запустите менеджер задач и убейте там процес TSLAB все займет 2 секунды и опятьможно запускать любимый экспериментатор.
P.S. В избежание лишних не пониманий и вопросов - тем кто торгует и не мучает оптимизатор вообще до этого нет дела TSLAB ест память только при оптимизациях, если торгуете то и торгуйте некуда не перегружаясь )

Если честно, ничего с оптимизацией не делалось.

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

как можно ожидать (операций/сек) рядом с прогнозом времени оптимизации ??

какие-еще операции в секунду? как их вычислять?

так вы же их в любом случае рассчитываете чтоб время прикидывать требуемое на выполнение оптимизации

а я прошу просто выводить этот параметр он поможет ориентироваться в потере скорости

Время рассчитывается очень просто. Есть заданное количество проходов оптимизации, есть пройденное за известное время. Составим несложную пропорцию не сложно рассчитать оставшееся время.

вот об этом я и говорю то есть опер/сек и его просто вывести рядом с прогнозом времени