Владимир (Все сообщения пользователя)

Выбрать дату в календареВыбрать дату в календаре

Страницы: Пред. 1 ... 14 15 16 17 18 19 20 21 22 23 24 ... 41 След.
string.dump не верно работает
 
Anton, Да я давал на Хабре даже исходники своего "сортира" - те, кто получали, умолкали, кто нет - визжали что-то непотребное, да тыкали в третий том Кнута. :smile: Программисты ВЫМЕРЛИ!
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
TGB, У меня как раз НИКАКИХ проблем. Но даже я заметил, что Квик всё чаще стал отвисать. Да и может ли быть иначе, если в него вставлять все эти идиотские "доработки", наподобие той, которая вынесена в топик этой ветки?
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
TGB, Да мне плевать! Как любой браузер должен корректно отображать любой сайт, так и любая версия Квика должна позволять корректно вести торговлю - тем более, рекомендованная самим брокером! У него просто не будет отмазки "используете неправильную версию".  :smile:  
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
TGB, Потому что страшно! Перестанет ведь работать и то, что работает, если реализовывать все эти идиотские "пожелания"!
string.dump не верно работает
 
Алексей, Я дельное и посоветовал: используйте файлы .lua и не занимайтесь хернёй.
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
TGB, Я же сказал, почему: мне ВСЁ РАВНО какая версия. Брокер рекомендует вот эту? Берём под козырёк.
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
TGB, У МЕНЯ?! А у кого ИНОЙ опыт - поднимите руки! :smile:

Я за свою жизнь написал немало программ, мне доводилось видеть работу СУПЕР-профессионалов! А сейчас я задаю конкретный вопрос: что сделано из программного обеспечения за весь XXI век? Вернее, не так: сделано ли ХОТЬ ЧТО-НИБУДЬ? Огласите весь список, пжалста!

Мне пока что насрать на новые версии QUIK - мой скрипт пока что уживаются со всеми. А вот что будет через год - даже боюсь себе представить. Кстати, я понятия не имею, какую версию я использую сейчас... 8.7.1.3 у одного брокера и 8.13.3.1 у другого. Обе сейчас работают, часа два назад одна из них отвисла, пришлось убить Квик. Обе несколько раз обновлял, исключительно по рекомендациям брокеров.
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
TGB, Моё мнение сроду не было "не пущать". Ни секунды не сомневаюсь, что "будут новые версии QUIK". Ни секунды не сомневаюсь, что каждая новая будет хуже предыдущей. Но ЮЗЕРАМ-то за каким хреном всё это надо? Ещё чёрте когда, ещё в 2011 году я писал (про браузеры):

Все компании, как заведенные, штампуют очередные версии, невзирая на реальное количество новшеств в них. Более того, они теперь приловчились и обновлять их автоматически, втихаря от юзера. Иными словами, значительная часть пользователей перейдёт на обновленную версию... даже не заметив этого "радостного" момента! Господа, но ведь это же ДОКАЗАТЕЛЬСТВО, что все эти браузеры есть полное дерьмо - ВСЕ ДО ЕДИНОГО! Если уж даже САМИ РАЗРАБОТЧИКИ не выдерживают - менее, чем через месяц выбрасывают очередное свое поделие на свалку... какие уж тут "новые возможности"!
- Не успел опробовать мозиллу 364 как уже 366 пришла...
- А я даже скачать не успел. Там вроде всей разницы - увеличили таймаут, по которому плагин считается зависшим. Но, видимо, сочли это настолько значимым, что даже пропустили цифру.
Так почему же юзеры, как заведённые, с упорством носорога, качают и качают эти очередные версии?! Ну нельзя же быть настолько тупыми, господа!
(...)
Ещё более смешны разговоры о безопасности применительно к браузеру - ведь это всего лишь паршивая прикладная задача. Более того - та самая, которая постоянно лазит по всяким помойкам, и тащит в рот всякую гадость. И Вы поверили, что именно эту программу и отрядили, чтобы "противостоять попыткам проникновения в систему"?! ДА КАКОЕ ЕЁ СОБАЧЬЕ ДЕЛО?! Пусть ковырятся в своей выделенной песочнице - и дело с концом Успокойтесь господа! Все эти "шпионские страсти" и "вирусные инфекции" - ничто, по сравнению с кошмариками в исполнении тупорылых "защитничков" - вот кого нам действительно следует бояться! С другой стороны, бояться какого-то тупорылого стада... стыд и позор! Так что успокойтесь господа. Если вам всё равно страшно - накапайте себе валерьянки. Или выпейте водки. Или возьмите топор, да изрубите ваш комп в капусту. Или хотя бы послушайте, что говорят про безопасность сами тупорылые - да, да, те самые, которые вас и пугают!
Эта характеристика сколь важна, столь и сложна в оценке. К сожалению, здесь нет (!) четких критериев, а каждое (!) исследование вызывает подозрения со стороны как пользователей, так и экспертов. Поэтому говорить собственно о безопасности браузера пока преждевременно (!). В общем-то, и материалов на эту тему найти не удалось (!).
Как видим, никто даже и не знает, что такое "безопасность браузера" - так, мычат что-то невразумительное насчёт "результатов ежегодных хакерских соревнований, на которых предлагается взламывать браузеры". Так чего же вы все так дружно обоср... испугались-то, господа? Да разве тупорылые дадут нас в обиду? Смотрите:
Вопрос сохранности частной жизни (!) приобретает особую (!) важность: если за ваш (!) компьютер кто-то (!) сел... Но работы над совершенствованием различных аспектов безопасности браузеров не прекращаются, и новые решения появляются практически в каждой (!) очередной версии. Все современные браузеры поддерживают приватный режим функционирования, в котором не сохраняются (!) следы посещённых веб-сайтов. Кроме того, реализован механизм, блокирующий на веб-страницах элементы, следящие (!) за перемещением пользователя. Полезная новинка - автоматическое упрощение URL в том случае, когда реальное имя сайта назначения передается (как правило, злонамеренно) в качестве параметра.
Примеры можно приводить бесконечно - от подобной бредятины Интернет просто ломится. Тем не менее, сказка про безопасность остается одной из самых популярных. Ну нельзя же быть настолько тупыми, господа!
(...)
Так что же это за таинственные "новые технологии", которые, оказывается, даже умудрились "войти в обиход"? Назовёт мне хоть кто-нибудь, хоть когда-нибудь, хотя бы одну? А вдруг окажется, что о них И НЕ НАДО было "думать"? Вдруг о них перестанут думать уже к выходу следующей версии браузера? А ведь перестанут - зуб даю! И куда, скажите на милость, подевались СТАРЫЕ технологии? Зачем их сп... гхм... украли?
Адаптировать браузер также не имеет смысла: придётся ограничить или вообще убрать практически все нововведения, так что он потеряет и свои преимущества.
Огласите весь список, пжалста! Хоть "нововведений", хоть "преимуществ". И вы немедленно убедитесь, что список этот даже не смехотворно мал - он просто-напросто ПУСТ! Ну нельзя же быть настолько тупыми, господа!
(...)
Война браузеров (грязная, беспощадная!) действительно была, я её и сам видел. Но она была между NN и IE! И в этой войне любые технические нюансы, достоинства и недостатки самих браузеров, не имели НИ МАЛЕЙШЕГО значения! А весь этот нынешний ублюдочный зоопарк из оперных хромированных лис есть лишь ИМИТАЦИЯ войны, лишь разводка для лохов. Я понимаю - вся эта погань из W3C и ниже мечтает рулить финансовыми потоками, она только на этом поганом клиенте ворует бабло десятками миллиардов долларов. НО НАМ-ТО КАКОЕ ДО ЭТОГО ДЕЛО?! Воруют - да и хер бы с ними, но они же еще и СРАТЬ ПРИХОДЯТ НА НАШИ КОМПЫ! Ну почему вы это терпите?! Ну нельзя же быть настолько тупыми, господа!
(...)
Был такой анекдот: "Абрам - нас, кажется, учат коммерции"! Не нужно считать одну из самых успешных компаний толпой идиотов: разводка для быдла КЛАССНАЯ! Дать им возможность почувствовать собственную состоятельность, поспорить, повыдвигать предложения, как нужно писать браузер... Они относятся к юзеру с полнейшим презрением - и правильно: он такого отношения более, чем заслуживает. Пока зомбированное быдло считает себя продвинутыми пользователеми, бизнес тупорылых будет успешным. Ну нельзя же быть настолько тупыми, господа!
(...)
Можно, например, проводить разнообразные тесты на "качество" браузеров. И неважно, что подобные тесты никогда не охватывают весь стандарт, неважно, что сами спецификации всё ещё находится на стадии обсуждения, и номинальная их поддержка мало о чем говорит, неважно, что на других аналогичных тестах результаты и лидеры могут быть совершено иными! Теперь можно вываливать на вконец одуревшего юзера ещё порцию макулатуры в стиле: Полезность такой новинки, как голосовой ввод, сомнительна, зато (!) она демонстрирует возможности HTML5. Надо признать, что и в этом лохотроне тупорылые одержали блестящую победу - мы лишь дружно надуваем щёки, да с важностью покачиваем головами: "Да, да, HTML5 - это круто, это прорыв". Ну нельзя же быть настолько тупыми, господа!
(...)
Тупорылые успели так загадить клиента, что знаменитые Авгиевы конюшни выглядят на этом фоне чуть ли не благоухающим садом! Одних только лохотронов о браузере (о каждом из которых можно писать многотомные опупеи) бесчисленное множество - файловая система и менеджер вкладок, плагины и расширения, меню и библиотеки, редактирование и поиск, графика и анимация, асинхроность и синхронизация, тормоза и глюки, не говоря уже про более конкретный зверинец: DOM, jQuery, GWT, AJAX, PHP, SEAM, Wicket, Greasemonkey, Silverlight, и прочую мерзость. Но ведь нужно же когда-то заканчивать статью!

А теперь замените "браузер" на QUIK и перечитайте ещё раз. :smile:  
string.dump не верно работает
 
Anton, В интерпретируемом коде сорцы попрятать?! Воистину, программисты вымерли! Ах, да - ОТ СТЫДА попрятать! :smile:  
string.dump не верно работает
 
Вопрос из спортивного интереса: а на кой вообще нужны эти .luac? Я всегда запускаю файл .lua, он всегда компилируется при запуске и прекрасно работает. Время на компиляцию стремится к нулю...
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
TGB, Началось!.. Вернее, продолжилось: сначала меня с Борькой посчитал "одним человеком" какой-то придурошный "опер", теперь снова... нет у меня никаких ников, и не было никогда. А если nikolz писал то же самое, то а данном случае я с ним согласен.
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
TGB,
Цитата
Ну и как вы объясните 16-ти кратную разницу времени выполнения скрипт
Некачественными замерами. :smile:  
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
TGB, Я не зачисляюсь в сотрудники - ни штатные, ни нештатные. Всё, пенсионер я! :smile:

Ну да, я и "начал с простых стратегий, не требующих много данных и вычислений" - ими же и закончил! :smile:

Не знаю, не знаю - много лет считаю, что любой диалог можно делать только на событиях, и это как раз существенно упрощает программирование. Другое дело, что здесь диалога вообще нет - даже редактирования полей нет. Но не особо-то и надо.

Колбеки следует использовать по минимуму - согласен. Потому-то у меня их всего два: OnStop, да OnTrade. И заявки у меня только лимитированные, с самого начала. И задержку при подаче заявок сделал не более, чем раз в полсекунды, чтобы Квик не захлебнулся при бурных событиях на рынке (организовал для этого стек заявок), и снятие заявок не раньше, чем через полминуты, чтобы гарантированно пришла вся эта колода прерываний на одно событие, и качество канала связи с моими брокерами меня полностью устраивает, хотя инструмент для создания скриптов именно «корявый» - даже не знаю, видел ли я когда-нить худший язык. Но вот скорость создания таблиц в OLua меня совершенно не волнует - пусть выполняется хоть в 160 раз дольше, чем до изменения - слова против не скажу!

Да, я понимаю, что "в QLua фактически единственный тип это таблица с индексами/ключами". У меня почти мгновенно ключи стали косить под индексы, то бишь все числовые, и доступ к элементам разветвлённого дерева вроде:
SetColor(T,a[i][0][9],4,D[X(a[i][2][2])],0,-1,-1);
или:
a[i][2][4]=a[i][2][0]/a[i][4][0][a[i][1][4][0]-1]*100-100;
проходит с вполне приличной скоростью, и создание вместе с инициализацией этой (фактически единственной) таблицы в мейне проходит в 100500 раз быстрее, чем загрузка самого Квика - ну что ещё желать-то? А больше всего боюсь именно очередного изменения QUIK, после которого перестанет работать то, что хоть как-то работает.

Ох, не уверен, что "есть возможность выбрать существующую версию с «любимыми» вами глюками и оставаться на ней столько, сколько вам захочется! Я бы никогда не ушёл с NT5/Win-2000, а сейчас из последних сил держусь на Хрюше на одном из моих компов (на других, увы, десятки). А недавно Яндекс залудил: "Ваш браузер устарел и не поддерживает новые возможности" - это в сраной-то почте?! Старый софт выдавливают, и буквально заставляют переходить на новое говно! Давайте хотя бы Квик не будем трогать, пока он ещё позволяет торговать!
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
_sk_, Серьёзно?! И КАК ЖЕ "большое количество таблиц может появляться в реальной программе"? Прям заинтриговали! :smile:

Ща посчитаем, сколько у меня... одна таблица для тикеров, одна для формирования транзакций, две таблицы Квика (одна для тикеров, другая для контекстного меню), да 10 служебных, "никакого" объёма, проинициализированных прямо в коде - И ВСЁ! Сейчас у меня запущено три скрипта, то бишь общее число таблиц 14*3=42. Процессор у меня 2 ядра по 2 ГГц, ОЗУ 2 ГБ, запустил я их сегодня где-то в 8 утра, так все три и работают. Обслуживают они в общей сложности 194+919+1934=3047 тикеров, у каждого по 10 таймфреймов, причём минимальный даже не минутный, а 7.5 секунд, т.е. свечи у каждого тикера только на 4 младших таймфреймах обновляются 15 раз в минуту. Мало того: все свечи скрипт считает САМ!
Цитата
Предположим, что скрипту нужно хранить в памяти для работы 3000 свечей
Нет, ТАКОГО мы предполагать не будем, ибо НЕ СУЩЕСТВУЕТ В ПРИРОДЕ скриптов, которым нужно хранить в памяти для работы 3000 свечей! А вот что "столько отдаёт сервер при запросе данных по ликвидным инструментам" - это алгоритмический КРЕТИНИЗМ, и только от меня дважды регистрировали пожелание заменить этот БСК нормальной структурой данных.

Я понятия не имею, на кой вообще нужно время - мне, как и моему скрипту, совершенно безразлично, когда сработала заявка: сейчас или через час, но загонять это дело в таблицу - ещё один кретинизм, ибо порядковый номер свечи, который даже хранить не надо, ОДНОЗНАЧНО идентифицирует её время (если известна база и период свечей, а они по определению известны).

В общем, повторная просьба: отвяжитесь от разработчиков, не заставляйте их гробить софт реализацией своих идиотских пожеланий - он и без того глючный до невозможности. Учитесь лучше программировать, и будет вам ЩАСТЬЕ!
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
TGB, Нет никакой "проблемы производительности скриптов в QUIK". Обсуждается проблема: "как можно засрать код на Lua, чтобы процессор сдох". По-моему, я уже советовал здесь обратиться к Биллу Гейтсу как к профессионалу высочайшего класса в таких делах.
Обновляемая таблица в заданном ценовом диапазоне
 
Сергей, Нет, не появилось. Ваших вопросов я вообще не видел (разве что Вы и Александр одно и то же лицо). Вопрос же Александра был: "Как  мне нужно изменить код?". В переводе на русский - "напишите код за меня".
Обновляемая таблица в заданном ценовом диапазоне
 
Сергей, Это и есть помощь. А вот написать код вместо него - это никакая не помощь.
Обновляемая таблица в заданном ценовом диапазоне
 
Александр, Этот код нужно не сменить - его нужно выбросить. Инициализацию строк, как и их заполнение, все нормальные люди делают в цикле, "цена и все данные" у Вас и так изменяются после вызовов getInfoParam и getParamEx. Что такое "цена выходит за пределы заданного (!) диапазона", покрыто мраком. Равно как и то, где Вы берёте свою "Table" и столбцы для неё.Затем Вы лепите все эти данные в первую строку таблицы, по три раза в каждую из её ячеек - видимо, для надёжности. Ну и картинка, конечно, весьма информативная... :smile:  
Как сохранить в файл координаты таблицы?
 
Ой! Обращение было, разумеется, к Васе.
Как сохранить в файл координаты таблицы?
 
Игорь Б, Ну так сдвигайте не руками.  :smile: Хотя я вообще не вижу смысла в перемещении таблицы по экрану. Тем более, если она вообще в экран не влезает (обычная ситуация для моего скрипта).

А чего непонятного? Хранить данные в таблицах Lua (T={}), как минимум, в миллион раз быстрее и примерно во столько же раз надёжнее. А уже из них "выводить информацию, которую хотите видеть".
Как сохранить в файл координаты таблицы?
 
Вася, Ничего не понимаю. А таблицу кто рисует? Разве не скрипт? И что значит "я сдвигаю таблицу перед  сохранением"? Руками, что ли? Наконец, нафига вообще хранить данные в таблицах Квика? Есть же таблицы Lua!
Ошибка запуска скомпилированного файла
 
Nikolay,
Цитата
Но покупать алгоритм - то еще занятие. Тем более, что они все давно исследованы вдоль и поперёк.
Ну так уж прям уж "все"... я свой ещё только-только начинаю исследовать. Да и старый непонятно как работает...  :smile:  
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
nikolz, Господи, .NET-то здесь при чём?! А файлы с драйверами каким боком? А размеры свободной памяти и/или файл свопинга? Да экономнее меня к памяти вообще не относится никто на этом форуме! Когда-то наша шахматная программа, прошитая в 16К ПЗУ (это и на программу, и на дебютный справочник, и на какую-то пародию на операционку!) с процессором 8086 и частотой 4.7 МГц официально выполнила норму КМС! И что, эта сраная задача организации торговли СЛОЖНЕЕ?! Какой только херни ни понапихают, а потом ещё удивляемся, что глючит! Да за одно только единожды выскочившее "неизвестное программное исключение" я бы тут же поувольнял к чертям собачьим всю эту шоблу так называемых "программеров"! А уж за регулярное появление, да ещё и с чередованием с "unknown hard error"!.. Верните на место самую старую версию, которая когда-то работала, что ли, И НЕ ПРИКАСАЙТЕСЬ БОЛЬШЕ К НЕЙ!!!
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
Anton, Так он и вылетать бы не должен, а час назад снова "неизвестное программное исключение", но на этот раз с убийством Квика и снова без малейших телодвижений с моей стороны.
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
Anton, Сегодня, после нескольких часов работы, снова получил "неизвестное программное исключение". В "спящий режим не входил и вообще к компу не прикасался. Правда, на этот раз Квик остался в живых, "зато" этот ублюдок самопроизвольно сменил режим экрана, и я всё равно был вынужден перезагрузиться. На этот раз все три запущенных скрипта завершились корректно, через OnStop - ура, товарищи!

Коллапс! Абсолютный коллапс! Всё перестаёт работать! Абсолютно всё! И починить уже некому.  :cry:  
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
Anton,
Цитата
Луа для квика - черный ящик.
Я и говорю: программисты вымерли. До знакомства с Квиком мне и в страшном сне не могло привидеться, что интерпретируемый код способен подвесить задачу.

Согласен, "слава богу, арка вроде не пытается ее ломать под каждое пожелание трудящихся, бо ничего кроме аццких глюков это не принесет".

В моих диалоговых задачах любой обработчик всегда сбрасывал обработанные им события, а остаток передавал следующему - никогда никаких проблем это не вызывало, даже если следующих обработчиков на момент передачи ещё не существовало. А здесь...  :cry:
Цитата
Табличка как в иконку превращается, чай, очищается в колбеке? Тогда засада:
Честно говоря, не помню. Подачу заявок я точно из коллбека выбросил, но это мало помогло... да, блин, именно там и сидит, зараза! Спасибо, попробую вынести. Кстати, именно там же и точно так же я лечу по Enter глюк "пропадание текста в ячейках", именно через DestroyTable с последующим AllocTable - уже несколько месяцев работает, как часы!  :smile:  
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
Anton, Да что там "предполагать" - ты же сам мой код интерпретируешь, ты же видишь, что это МОЁ событие, ты же знаешь, что я его перехватил и обработал! Какого хрена ты ещё и со своим обработчиком путаешься под ногами?!

Та же хрень по клику правой кнопкой: по нему у меня вызывается контекстное меню (единое в трёх лицах, в зависимости от того, по какой группе столбцов кликнуть), но и тут выскакивает это дурацкое "сортрировать?".

Вот же гнида! Опять один из Квиков выбила - "неизвестное исключение", панимаш! ВААПЩЕ ничего не делал, даже к компу не подходил! :evil:  
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
Anton, Но я же не вытаскивал столбец из таблицы за заголовок! Тыщу раз кликал по заголовкам столбцов таблицы - никогда ничего подобного не было, просто строки сортировались по нему. Ну или в одном из видов контекстного меню у меня клик по столбцу перехватывается и меню переписывается уже с этим столбцом как с текущим. А, ну да - там ведь тоже порядок строк меняется перед перезаписью меню! То есть эта сволочь всё равно запускает и свой обработчик вместе с моим. Но у "спящего режима" даже строк нет, сортировать нечего! Может, поэтому у этого придурка крыша и едет, и всё заканчивается "internal error". Что, ещё и строчку ему завести, шоб было что сортировать?

Ну да, "и без чистильщика широк простор убица на ровном месте". Кстати, Хром так до сих пор на сайт зайти и не может. На другие сайты - пожалуйста, но здесь - табу! :smile:  
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
Anton, Повесил я тут в своём скрипте на Escape "спящий режим" - таблица сворачивается в небольшую иконку и никакой выдачи туда не производится, только тикает чего-то по SetWindowCaption - типа, "работаем, а не висим". А по любому событию в этой таблице прорисовывается снова "нормальная". Так вот: несколько раз при этом выскакивало: "Вы уверены, что хотите удалить столбец"? Какой, в жопу, "столбец"?! Вся иконка состоит из одного столбца, а в том лишь один заголовок "Спящий режим" и больше нихрена нет! А пару раз при попытке выхода из спящего режима и вообще Квик вылетал по "internal error"! У меня просто фантазии не хватает, КАК можно изуродовать программу, чтобы она вытворяла ТАКОЕ! Вероятно, этот долбаный "чистильщик" чего-то там "начистил".

И ещё: сегодня меня перестало пускать на форум: Хром в ожидании, "да и нет не говорит", загрузка крутится... полчаса, час - она всё крутится. Зашёл через Оперу - пока пускает. Софт просто ППЦ! А народ загрузка CPU не устраивает, панимаш! :smile:  
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
БорисД, Борь, ну я уже сегодня с утра опять успел "internal exeption" схлопотать! А в пятницу Квик опять вылетал по "unknown hard error"! При таких страшных глюках производительность CPU - это ПОСЛЕДНЕЕ, о чём должна голова болеть!

Запустил все 4, как грозился - пока всё работает. Но "соревнование устроить" пока не получаются: все затаились и ждут - ни одной сделки ни у одного из скриптов. Впрочем, рано ещё, торги толком не начались, подождём...

Да, но ведь и сложность выросла в разы! Причём как моими стараниями, так и твоими. Но всё-таки о наших с тобой делах давай лучше не здесь.
Обнаружение айсбергов в стаканах
 
Если бы у меня были деньги на айсберг, я бы никогда не ставил его по спреду, а порубил бы его на кусочки и игрался бы в "купи-продай" в устраивающем меня ценовом диапазоне, только бы покупал в 2-3 раза больше, чем продавал (или наоборот, в зависимости от типа айсберга). Ещё и заработал бы на этом! И что Вы увидите в стакане при такой технологии? Один такой кусочек! Ну или два.
Обнаружение айсбергов в стаканах
 
Vladimir, Айсберг заявка на то и айсберг, чтобы её трудно было обнаружить. Лично я считаю, что вообще невозможно при грамотной её подаче. А решение зависит от того, что Вы, собственно, хотите от айсберга. Скормить ему излишек Ваших акций? Прикупить вместе с ним "на вырост"? Придержать свои акции или деньги, пока айсберг не рассосётся? Чисто интуитивно, айсберг - это большие объёмы при почти стоящем курсе. А зачем нам стоящие курсы? Вот когда двинется куда-нибудь, тогда и посмотрим. :smile:  
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
boolean.rat, Но Вы же сами сказали, что положение улучшилось. Значит, вполне возможно, что Ваша реализация "KILL+NEW" просто менее эффективна, чем она же внутри найденной Вами функции "MOVE". А вот объединить скрипты "на каждый инструмент" в один "на все" просто настоятельно рекомендую!
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
boolean.rat, Совершенно верно, "прям это является ужасной ошибкой". Жуткие тормоза и бесконечный кладезь самых разнообразных проблем, начиная с синхронизации.

Меня не интересует, что там "было сначала". Просто я терпеть не могу непрофессионализма, особенно воинствующего, как в этой ветке. Кстати, "смена заявки вместо снять-поставить" ничуть не быстрее, она всё равно реализована через "снять-поставить", только уже "внутре".

Вот и замените несколько скриптом одним на все инструменты и проблема исчезнет сама по себе.

Удалять/редактировать здесь нельзя. Маразм, конечно, но "такова селява".
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
КАТЕГОРИЧЕСКИ против любой модификации софта в угоду производительности! Надёжность падает, а любую производительность мгновенно загадят. Вон, пожалуйста "каждый скрипт отдельный инструмент", а несколько месяцев назад кто-то вообще бахвалился про "86 одновременно запущенных скриптов"!

Я дважды собирался обсудить здесь и довести до ума коды основных утилит для торговли (подача и снятие заявок, организация диалога и тому подобные "технические" моменты). Оба раза дело кончилось визгами и вонью, так что больше я этим делом заниматься не собираюсь. Просто говорю как профессионал: НИКАКИХ проблем с производительностью в Квике НЕТ! В понедельник с началом торгов я намерен опробовать новую версию своего скрипта, запуская её (без подачи заявок, только с её имитацией) параллельно с "боевым" скриптом, который ведёт реальную торговлю. Процессор у меня на 2 ядра, 2 ГБ ОЗУ, 2 ГГц, будут работать 2 Квика от разных брокеров, в каждом будет запущено по 2 скрипта (новый и старый). Обслуживать они будут в общей сложности около 4000 инструментов. И они прекрасно справятся с этой задачей! Говорю так уверенно потому, что в пятницу я отлаживал этот скрипт почти в том же режиме, только запускал его на одном из Квиков. Какое вам ещё быстродействие надобно?! Оставьте софт в покое, господа!
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
TGB, ДА НИКОМУ от Qlua почти ничего не нужно! Просто нужно правильно ставить задачу, а не засирать процессор и память всякой фигнёй просто потому, что это МОЖНО сделать. Хотите честно? Я НЕ ВЕРЮ, что кто-либо использует больше входной информации, чем я (не объёмов данных, а именно информации для принятия решений). И у меня ОДНА таблица Lua на все эти дела! Ну, не считая нескольких служебных. Но в этой ОДНОЙ таблице есть ВСЕ нужные данные по ВСЕМ контролируемым скриптом тикерам! И времени на своё создание или чтение/редактирование данных из неё почти не требует. А данных там просто немеряно! Например, в ячейке в ячейке a[0][a[i][0][2]][0] находится текущее состояние кошелька пользователя (избыток/нехватка наличности) по валюте i-го тикера, в a[0][6][0] - размер стека заявок, в a[i][0][9] - ID строки i-го тикера в таблице визуализации, в ячейке a[i][1][1][j] - значение последней свечи i-го тикера по j-му таймфрейму, в ячейке a[i][4][j][a[i][1][4][j]-1] - цена самой дешёвой сделки i-го тикера по j-му таймфрейму, в a[i][3][j][0] - ID j-ой незакрытой заявки i-го тикера либо ID транзакции, если ID заявки ещё неизвестно). И т.д., и т.п. Таблица, повторяю, ОДНА! Проблем с производительностью, повторяю, НИКАКИХ! А тикеров у меня СОТНИ или даже ТЫСЯЧИ! Что, кто-то из местных "скулящих" обрабатывает больше? Ха-ха-ха!

Ваш друг, возможно, бесконечно круче меня как программист и/или как трейдер, но как алгоритмист я крутой, как варёное яйцо! :smile:  
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
TGB, Таблицы Lua и я очень активно использую (я думал, речь идёт о таблицах Квика), и НИ МАЛЕЙШИХ проблем с ними не имел. И если СОЗДАНИЕ таблиц вдруг замедлится в 16,25 раз, меня это НИСКОЛЬКО не обеспокоит. Доступ к ячейкам этих таблиц - другое дело, но это лечится нормальной организацией таблиц, а не запихиванием туда громадных массивов.

У меня дохленький ноут (даже не знаю, что там... ну да, два ядра, два гигагерца, два гигабайта), куплен специально для торговли, на нём постоянно крутятся два Квика от двух брокеров. Работает себе... ну, иногда Квики вылетают, как я писал выше. Но чтобы С ПРОИЗВОДИТЕЛЬНОСТЬЮ были какие проблемы...

Я забочусь о том, чтобы разработчик QUIK не ВНОСИЛ новые глюки! Не надо его провоцировать!
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
TGB, А какая разница, папуасы они или нет? Код Квика глючный до невозможности, работа с таблицами просто слёзы, и это медицинский факт. Нет у них никаких тестов - они им нафиг не нужны: все глюки оплачивает пользователь, а у них прямо противоположная задача: бесконечно выпускать всё новые и новые версии, имитируя бурную деятельность.. Код ПОКА ЕЩЁ позволяет вести торговлю, но, боюсь, вскоре перестанет это делать.
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
TGB, Когда-то давно одного моего знакомого (крутейшего программиста) послали на курсы повышения квалификации. Мода такая была, хотя его квалификиция была намного выше, чем у любого из преподавателей. Дали задание: написать на С разложение в ряд Тейлора. Он и написал:
for(чего-то там);
то есть тело цикла у него получилось пустым. Препод посмотрел: "Я это решение проверять не буду"!

На месте техподдержки я бы то же самое сказал и о приведенном коде. Ну, выполняется эта хрень в 16,25 раз дольше чем в QUIK 8.13.1.16 - и чего? Самое разумное - отправить весь код на помойку, не читая.
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
nikolz, Ну, и на Квик, и на язык я в своё время предостаточно матерился, так что "добротной" эту телегу я бы не назвал. :smile:  Но она, по крайней мере, позволяет нормально торговать, а все эти долбаные "нововведения" лишают её этой возможности. Деньги же всё-таки, надёжность превыше всего! Любые изменения, снижающие надёжность, должны отбрасываться без рассуждений. А если не снижают - тут уже можно и выпендриваться.
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
Что-то вы, ребятки, не то делаете... какая-то _G, панимаш... про которую пишут, что "в новых версиях Lua вместо _G теперь _ENV"... У одного вообще без обращений, у другого к паре переменных туеву хучу раз... ВОТ ТАК в моём понимании создаются локальные переменные:

Ах, у loadstring с локальными переменными проблемы - ну, сделаем глобальной.
Код
f=true;
N=1000;
J=0;
function main()
 local i;
 for i=0,N do
  loadstring("v"..i.."="..i%100)();
 end;
 F=io.open(getScriptPath().."//TEST","w");
 for i=0,N do
  loadstring("J=v"..i)();
  F:write("i="..i.." v"..i.."="..J.."\n");
 end;
 F:close();         -- закрываем входной файл

-- while f do
--  sleep(500);
-- end;

end;

function OnStop()
 f=false;
 return 500;
end;
Ну да, и в TEST всё в порядке:
Код
i=0 v0=0
i=1 v1=1
i=2 v2=2
...
i=99 v99=99
i=100 v100=0
...
А в закомментированных строчках к ним должны бы быть протестированы обращения к этим переменным, но мне лень думать, как это делать, ибо НОРМАЛЬНАЯ у Квика производительность! НОРМАЛЬНАЯ! Не нравится "нормальная" - скажу "идеальная"! Она непригодна разве что для этой долбаной HFT, но тому нужно чесать прямиком на биржу, чтобы ловить там свои сраные сотые доли процента. Просто писать надо уметь, а не плакаться здесь в жилетку по самым идиотским "проблемам". :wink:  
LUA скрипт жрет память
 
kbrobot.ru, Таблицу я как раз создавал стандартными средствами LUA. Только не таблицу Квика, а таблицу самого LUA. :smile:  
Баги QUIK 8.13
 
БорисД, Не, "опробовать возможности следить сразу за всеми  существующими и торгуемыми  нашими российскими брокерами  инструментами на всех инструментах, рынках и  биржах к которым они предосталяют доступ  своим трейдерам" можешь чем угодно, токо не моим скриптом. Ты прям как Старатель - загадить мой распрекрасный скрипт всяким говном и смотреть, что случится.  :smile:

Ну или классика:
Купили как-то суровым сибирским лесорубам японскую бензопилу.
Собрались в кружок лесорубы, решили ее испытать. Завели, подсунули ей деревце.
— Вжик! — сказала японская пила.
— У,  * ! — сказали лесорубы.
Подсунули ей деревце потолще.
— Вж-ж-жик! — сказала пила.
— У,  * ! — сказали лесорубы.
Подсунули ей толстенный кедр.
— Вж-ж-ж-ж-ж-ж-ж-жик! — сказала пила.
— Ууух,  * ! — сказали лесорубы.
Подсунули ей железный лом.
— КРЯК! — сказала пила.
— Ага,  * ! — укоризненно сказали суровые сибирские лесорубы. И пошли валить лес топорами.
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
Старатель, Лапуль, я прекрасно понимаю о чём тема, и в первом же своём сообщении написал: "Вся тема есть чистейший флуд на 146%".

А чуть дальше столь же русским языком написал: "ЕСЛИ интерпретатору подсунули десятки тысяч переменных, ТО при ОБРАЩЕНИИ к любой из них он должен среди всей этой навозной кучи как-то НАЙТИ нужную".
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
Старатель, А обращаться к этим "миллионам переменных" Пушкин будет? :wink: Вы всего лишь создали навозную кучу, но не ковырялись в ней в поисках нужной переменной.
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
Старатель, Создание - снижает, это нагрузка на таблицы Квика. Собственно, не на создание, а на "созерцание". Тем более, не просто таблицы, а ТОС, которая нафиг никому не нужна. Индикаторы, тоже снижают, по той же причине. А вот если не заниматься подобной фигнёй и оставить только OnTrade, да обработчики, устанавливаемые по SetTableNotificationCallback, да поставить не sleep(1), а хотя бы sleep(500), то "производительность при вызовах колбеков" не просто удовлетворительная, а почти идеальная.
Баги QUIK 8.13
 
БорисД, Так ведь у нас УЖЕ от 20 тысяч тикеров остались рожки, да ножки - менее 9000, насколько я помню. Всё остальное УЖЕ ушло в класс "говно", а ещё не вечер. А с говном должен работать уже не боевой скрипт, а именно тест, запускаемый уж никак не чаще, чем раз в неделю и очень лёгкий сам по себе: его задача всего лишь проверить, не появилось ли среди этого говна что-то интересное.

Боевой, конечно, намного тяжелее, но... денег-то у тебя хватит, чтобы загрузить его на полную мощность? :smile: Да чо там "на полную" - хотя бы на 10%.
Получение из таблицы текущих торгов всех доступных на текущий момент фьючерсов по инструменту
 
БорисД, Ты тоже не вводи. :smile:

Нужные  в данном случае - это как раз все, за которыми следит скрипт, то есть "все" в твоей терминологии. А про те "нужные", про которые ты говоришь, никто не знает, кроме нас с тобой - к тому же, они в новой версии вообще отменены.

Да, "все" - это "мой урезанный мною список", который ещё до тебя был "урезан и без самых дерьмовых  по оборотам  и волатильности тикерам". Только мне не нравятся данные по объёмам (если бы свечи считались по-нормальному, как мат ожидание, а не дурацкие OHLC, то туда бы органично вошли и объёмы естественным образом), так что я предпочитаю частоту сделок в единицу времени. Если там вообще народ ковыряется - значит, и нам можно.

Я дважды предлагал собрать нормальный "технический" набор утилит для торговли - один раз до тебя, один при тебе. Та знаешь, чем это закончилось. Так что меня больше не волнуют проблемы "большинства  посетителей этого форума", а ты прекрасно знаешь, что с несколькими тысячами тикеров МОЙ скрипт справится без проблем.
Баги QUIK 8.13
 
БорисД, Что, и ты не выдержал, опять сюда влез? :smile:

Да знаю я, что ты лентяй ещё больший, чем я. Ну, не выключай. А мне комп тоже жалко - пусть отдохнёт от этой биржи. Может быть, глючить будет меньше в качестве благодарности. :smile:  
Баги QUIK 8.13
 
Anton, Не зааю как там "не везде", а у меня именно так. :smile:

А кто говорил про "заранее назначенное время"? Я вот совершенно без понятия, когда я его завтра включу и когда выключу. Ах, да - завтра торгов нет. Ну, сегодня был без понятия, выключил минуту назад.
Страницы: Пред. 1 ... 14 15 16 17 18 19 20 21 22 23 24 ... 41 След.
Наверх