ru.algorithms

 
 - RU.ALGORITHMS ----------------------------------------------------------------
 From : Vladislav Gusev                      2:5059/9.75    10 Sep 2002  18:22:49
 To : akrivosheev@utc.ru
 Subject : Re: поиск
 -------------------------------------------------------------------------------- 
 

                      Приветствую тебя akrivosheev@utc.ru !!!
  Было это [09 сентября 2002]. akrivosheev@utc.ru писал к Valentin Davydov.
 
  >> >> 4 байт в регистр процессора и последущего сравнения просто
  >> >> сдвигом на 8 разрядов.
  >>      > А смысл? Раз уж загрузили 4 байта, так и сранивать надо 4 байта.
  >>      > ;)
  >>
  >> А смысл? Всё равно на побайтное сравнение 4х байт тратися меньше времени,
  >> чем на один цикл чтения четырёхбайтного слова из памяти.
 
  Hу, не из памяти ,а скорее всего из кэша, строки все таки...
  на PI/PII это 1 такт/1 m.
 
  a> Посмотрел как реализованна StrPos в Delphi. Hаписано на ассемблере и
 
     Delphi ;))))
 
  a> использует при поиске
  a> REPNE SCASB. - инструкция процессора выполняется примерно за 8 тактов.
 
     по одному байту это конечно очень эффективно, на грани фантастики ;)
 
  a> (одно сравнение+загрузка и пр...) Для сравнения команда JMP - выполняется
  a> минимум за 7 тактов. Видимо с точки зрения быстродействия StrPos в Delphi
 
  А мы что под 386 пишем ? Там как раз JMP 7 тактов было ,только тогда
  REPNE SCASB никак не 8.
 
  PI/PII тратят 1 такт на правильно предсказанный выполненный переход.
 
  a> наиболее оптимален для Интел процессора, потому как если мы напишем свой
 
  Hаиболее оптимальный код можно получить используя Intel C++ с векторизацией
  и оптимизацией под MMX/SSE(ни всякий профи так напишет).
  А делать с оглядкой на дельфи это просто глупо. 
 
  a> алгоритм поиска при каждом сравнении потребуется как минимум одна команда
  a> перехода - 7 тактов, а ещё + загрузка, сравнение , сдвиг... выйдет как
  a> минимум больше 10 тактов процессора.
 
  a> Так что вообще-то компиляторы не дураки пишут и стоит использовать их
 
  Смотря какие компиляторы ;)
 
  a> команды... А то что файл в память не помещается весь, так это... его
  a> можно
  a> кусками считывать, сколько в память влезет,  хоть по килобайту - всё
  a> быстрее чем посимвольно. ;)
 
                                               С уважением Vlad.
 
                       [C++] [Rock] [I`ll be back]
 --- GoldED+/386 1.1.4.5
  * Origin: DEL * . * - 100 % сжатие !!! (2:5059/9.75)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор 

Тема:    Автор:    Дата:    поиск   Serj Okladnikov   08 Sep 2002 02:09:04   Re: поиск   Slavik Levchenko   08 Sep 2002 13:16:53   поиск   Serj Okladnikov   08 Sep 2002 19:29:01   Re: поиск   akrivosheev@utc.ru   08 Sep 2002 21:54:42   Re: поиск   Andrey Belyakov   09 Sep 2002 02:05:50   Re: поиск   akrivosheev@utc.ru   09 Sep 2002 07:20:51   поиск   Evgeniy Trubachev   10 Sep 2002 10:49:45   Re: поиск   Evgeniy Bezimyannikov   19 Sep 2002 14:40:36   Re: поиск   Valentin Davydov   09 Sep 2002 17:05:16   Re: поиск   akrivosheev@utc.ru   09 Sep 2002 18:49:25   Re: поиск   Vladislav Gusev   10 Sep 2002 18:22:49   Re: поиск   akrivosheev@utc.ru   10 Sep 2002 23:53:44   Re: поиск   Vladislav Gusev   11 Sep 2002 13:45:51   поиск   Georgy Plechanov   11 Sep 2002 19:42:50   Re: поиск   Andrew Ezhguroff   13 Sep 2002 15:22:25   поиск   Georgy Plechanov   13 Sep 2002 18:26:54   Re: поиск   Valentin Davydov   16 Sep 2002 03:13:47   Re: поиск   Vladislav Gusev   16 Sep 2002 12:56:32   Re: поиск   Andrey Belyakov   09 Sep 2002 19:44:29   Re: поиск   Sergiy Kanilo   08 Sep 2002 20:19:15   Re: поиск   Sergey Voloshchuk   16 Sep 2002 16:22:16