информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
За кого нас держат?Портрет посетителяСетевые кракеры и правда о деле Левина
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Крупный взлом GoDaddy 
 Просроченный сертификат ломает... 
 Phrack #70/0x46 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Что ты подразумеваешь под "скоростью"? 09.11.06 06:03  Число просмотров: 3459
Автор: Zef <Alloo Zef> Статус: Elderman
<"чистая" ссылка>
Если скорость чтения, то тут ничего улучшить не удастся. Если время отработки проги, то - да. Но, самый быстрыи и незаметный вариант - внедрить сей код в чужой процесс. Мона написать на С консольное приложение - то же будет быстро.
<programming>
Кто-нибудь ещё помнит ASM ? 08.11.06 11:35  
Автор: dub Статус: Member
<"чистая" ссылка>
Стала необходимость написать прогу, которая бы сливала по быстрому данные с LPT в файл, сходу слепил на TP6, получилось где-то 3мкс на чтение, вот думаю, если написать на ASMе быстрее будет?

USES crt;
VAR
filename : string;
f : text;

BEGIN
clrscr;
write('Enter the logfilename: ');
readln(filename);
IF filename <>'' THEN
BEGIN
assign(f, filename);
rewrite(f);
REPEAT
write(f,port[$379]);
UNTIL keypressed;
close(f);
END;
END.
Нет, принципиально быстрее не будет 08.11.06 13:53  
Автор: leo <Леонид Юрьев> Статус: Elderman
<"чистая" ссылка>
С чего вы взяли? 08.11.06 13:59  
Автор: dub Статус: Member
<"чистая" ссылка>
Я мерил как-то скорость чтения из принтерного порта -... 09.11.06 10:00  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
<"чистая" ссылка>
Я мерил как-то скорость чтения из принтерного порта - получилось около милиона в секунду. Стало быть можно поднять до одной микросекунды теоретически, реально до двух-полутра, вряд ли больше. С СОМ портом примерно то же самое, да и с другими полагаю тоже.
В проедположении, что программа будет работать на порядка гигагерцовом проце, способном выполнять инструкции менее, чем за наносекунду, получается что накладные расходы на проверки условий, организацию цикла и вызов функций будут на один-два десятичных порядка меньше, чем обращение к порту, скорость работы которого ограничена аппаратно. Пэтому танцы с бубном над кодом хоть какого-либо заметного выигрыша не дадут. В принципе мег в секунду и так уже не плохо. Ну было бы гиг или сотня мег - что б вы с этим делали. Замер в несколько секунд был бы не возможен, поскольку скорость винта далека до достижения в сотни мег. А если запоминать в оперативку, то ее тоже на долго не хватит.
Я как-то мерил скорость пули СОМ портом. В предположении того, что расстояние между парой датчиков не очень мало результаты получались достаточно правильные, поскольку хоть с момента пролета пули до фиксирования времени и проходило относительно не малое время, но такое же время проходило и после срабатывания второго датчика. Получалось все достаточно точно.
Это я к тому, что немаловажную роль может играть не латентность системы измерения а методология.
А вот есть ещё режим работы порта т.н. ECP -- он не сможет помочь? 09.11.06 16:07  
Автор: HandleX <Александр М.> Статус: The Elderman
<"чистая" ссылка>
Там вроде есть аппаратная буферизация и DMA трансферы. -))
О! То-то чуствовал, что забыл что-то достаточно важное. 09.11.06 18:14  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
<"чистая" ссылка>
> Там вроде есть аппаратная буферизация и DMA трансферы. -))
О! То-то чуствовал, что забыл что-то достаточно важное.
Да, есть, кроме Standart и Bidirectional, еще EPP и ECP. Были они придуманы с момента разработки быстропечатающих лазерных принтеров "высокого" разрешения (300 ДПИ). Тогда приходилось прогонять на страничку достаточно большой объем данных так, что прокачка по интерфейсу получалась медленнее, чем выход самой странички. Эти режимы позволяют прокачивать "в принтер" с более "высокой" скоростью!
Я досконально с этими режимами не разбирался, но насколько понял, используется режим ДМА и аппаратное стробирование. То есть при прокачке байта в принтер надо пулить порт состояния готовности принтера, устанавливать бит строба на небольшой промежуток времени и снимать его. Итого довольно много микросекундных обращений к портам. Так вот боюсь, что эти режимы не сработают на чтение из порта, да и прироста скорости не дадут, если не используется аппаратная синхронизация. Хотя чем черт не шутит. Пусть энтузиасты, у которых есть интерес и время поковыряются и напишут.
Да, и еще, есть определенные предложения: 1) Сделать девайс, к которому нужно обращаться не по портам, а по адресам памяти. Не "inp al, dx", а "mov ax, [dx]". 2) Слышал, что для увеличения скорости обращения к портам их можно отмэпить на оперативку и все так же mov'ом обращаться.
Дак ведь уже обсуждали 09.11.06 18:26  
Автор: leo <Леонид Юрьев> Статус: Elderman
<"чистая" ссылка>
http://www.bugtraq.ru/cgi-bin/forum.mcgi?type=sb&b=7&m=133006
Потому что на вызов пары-тройки лишних функций высокоуровнего компилятора уходит ничтожное время относительно чтения данных процессором из порта ввода-вывода. 08.11.06 18:49  
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 08.11.06 18:53  Количество правок: 1
<"чистая" ссылка>
Ещё можно попробовать буферизовать ввод-вывод. Читать данные из порта в буфер, и по таймеру параллельно (!) сбрасывать буфер в файл.
не дурите 09.11.06 09:50  
Автор: NKritsky <Nickolay A. Kritsky> Статус: Elderman
<"чистая" ссылка>
> Ещё можно попробовать буферизовать ввод-вывод. Читать
> данные из порта в буфер, и по таймеру параллельно (!)
> сбрасывать буфер в файл.

ввод-вывод в ТП уже буферизован по дефолту. А если и не буферизован то проще запустить smartdrv.exe перед программой чем заниматься извратом. :)

А вот переписывание проги на асме может дать прирост. Дело в том что наверняка паскаль обёртывает port I/O routines какими-нибудь делэями. Тут надо пробовать и смотреть. Хотя по-моему 3мкс - отличная скорость для LPT. Зачем больше-то?
Нет, тут все чисто - конструкция типа Port[$379]... 09.11.06 13:35  
Автор: :-) <:-)> Статус: Elderman
<"чистая" ссылка>
> А вот переписывание проги на асме может дать прирост. Дело
> в том что наверняка паскаль обёртывает port I/O routines
> какими-нибудь делэями. Тут надо пробовать и смотреть.

Нет, тут все чисто - конструкция типа Port[$379] транслируется в
mov dx, 379h
in al, dx

А вот работу с файлами можно улучшить.
Ведь у него же используется текстовый файл! То есть каждый прочитанный из порта байт преобразовывается в строковое представление, занимающее 1-3 байта, и уже оно записывается в файл.
Надо хотя бы сделать var F:File и использовать для записи BlockWrite, и размер буфера увеличить (могу ошибаться, но кажется это делается чем-то вроде F.BufSize := 4096; перед открытием файла).
smartdrv непредсказуем, будут неконтролируемые "провалы" при чтении из порта. 09.11.06 11:50  
Автор: HandleX <Александр М.> Статус: The Elderman
<"чистая" ссылка>
А я наталкивался (при снятии параметров с двигателя), что... 09.11.06 12:31  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 09.11.06 12:31  Количество правок: 1
<"чистая" ссылка>
А я наталкивался (при снятии параметров с двигателя), что немалое вличние на точность измерения влияет обработка прерываний таймера, которя происходит 18.2 раза в секунду. Маскировать в контроллере прерываний надо на время измерений, а потом время восстанавливать, а то системные часы отстанут, не забывать что таймер не тикает, то есть в зависимости от веремени ничего не "сливать", да и другие пропущеные прерывания как-нибудь обработать.
Уточнение 09.11.06 00:11  
Автор: leo <Леонид Юрьев> Статус: Elderman
<"чистая" ссылка>
Львиную долю времени (~99%) будет занимать чтение из порта и оптимизировать тут нечего. Максимум, что можно сделать так это не проверять KeyPressed каждую итерацию, а сделать вложенный цикл (например на 4096).

Писать по таймеру особого смысла нет. Пока будет выполняться запись в файл, чтение из порта всё равно никак не сделать (не распараллелить).

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

Если "поманьячить", то можно сделать чтение через insb (только 286+). Но как уже говорилось, на современных CPU это не даст заметной прибавки скорости.
Согласен, с таймером может и перебор, а запись в файл да, лучше делать не побайтно, как в примере, а посекторно, 512 байт, это займёт столько же времени, сколько и запись одного байта. Там же и проверять KeyPressed. 09.11.06 06:40  
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 09.11.06 06:42  Количество правок: 1
<"чистая" ссылка>
маленькое уточнение, не посекторно, а покластерно. 09.11.06 14:16  
Автор: kstati <Евгений Борисов> Статус: Elderman
<"чистая" ссылка>
Что ты подразумеваешь под "скоростью"? 09.11.06 06:03  
Автор: Zef <Alloo Zef> Статус: Elderman
<"чистая" ссылка>
Если скорость чтения, то тут ничего улучшить не удастся. Если время отработки проги, то - да. Но, самый быстрыи и незаметный вариант - внедрить сей код в чужой процесс. Мона написать на С консольное приложение - то же будет быстро.
У него вроде вообще всё под доской колбасится. 09.11.06 06:41  
Автор: HandleX <Александр М.> Статус: The Elderman
<"чистая" ссылка>
1






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2021 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach