Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Скорость сравнения строк в Ansi и Unicode формате.

Страницы: < 1 2 3
Riply © (2007-10-31 03:51:00)
Здравствуйте !
Допустим, у нас есть две строки:
wBuf1, wBuf2: WideString;
и они же, "переведенные в Ansi": aBuf1, aBuf2: string;
Верно ли следующее утверждение:
регистро-зависимое сравнение aBuf1 и aBuf2 будет выполняться быстрее,
чем регистро-зависимое сравнение wBuf1 и wBuf2 ?

guav (2007-10-31 21:26:00) [41]

> медленная аггрегатная команда REPE CMPSD

Ну если так придиратся то стоит заглянуть на http://fastcode.sourceforge.net/:)

И всё таки, разве различные формы не существуют ?
Откуда такая информация:

> Anatoly Podgoretsky © (31.10.07 13:11) [4]

> Если не брать разные платформы, но никаких других форм не
> существует.

Anatoly Podgoretsky (2007-10-31 19:26:00) [42]
> clickmaker (31.10.2007 17:36:15) [15]

Это хорошо, но в тоже время задействована медленная аггрегатная команда REPE CMPSD

clickmaker (2007-10-31 17:55:00) [43]

> потом оставшиеся 2

тьфу, оставшиеся от 1 до 3, разумеется )

Riply (2007-10-31 17:46:00) [44]
> [15] clickmaker © (31.10.07 17:36)
Спасибо.

clickmaker (2007-10-31 17:36:00) [45]

> [14] Riply © (31.10.07 17:25)

REPE CMPSD
JNE @@2
MOV ECX,EDX
REPE CMPSB
JNE @@2
@@1: INC EAX
@@2: POP EDI

сравнение в 2 приема: сначала 4 байта, потом оставшиеся 2
так что 32-битная логика задействована

Riply (2007-10-31 17:25:00) [46]
> [13] clickmaker © (31.10.07 17:17)
> SysUtils.pas
А можно "на пальцах" для тех, кто в ассемблере "как в апельсинах" ?

clickmaker (2007-10-31 17:17:00) [47]

> [12] Anatoly Podgoretsky © (31.10.07 16:20)

SysUtils.pas

Anatoly Podgoretsky (2007-10-31 16:20:00) [48]
Мне неизвестно внутреннее устройство CompareMem

guav (2007-10-31 14:51:00) [49]
> [10] Anatoly Podgoretsky © (31.10.07 14:36)

А разве стандартная CompareMem таковой не является ?

> Если не брать разные платформы, но никаких других форм не
> существует.

То есть ?
http://ru.wikipedia.org/wiki/%D0%AE%D0%BD%D0%B8%D0%BA%D0%BE%D0%B4#.D0.9C.D0.BE.D0.B4.D0.B8.D1.84.D0.B8.D1.86.D0.B8.D1.80.D1.83.D1.8E.D1.89.D0.B8.D0.B5_.D1.81.D0.B8.D0.BC.D0.B2.D0.BE.D0.BB.D1.8B - разве это не едино для всех платформ ?

Anatoly Podgoretsky (2007-10-31 14:36:00) [50]
Я имею в виду, что если CompareMem, то надо заменить на свою функцию, которая сравнивает четыре байта за раз.

Anatoly Podgoretsky (2007-10-31 14:35:00) [51]

> Например, если используется CompareMem :)

Шурик это не наш метод.

Riply (2007-10-31 14:32:00) [52]
> [7] clickmaker © (31.10.07 14:29)
> а с чего бы? если windows nt насквозь уникодная

Имелось ввиду что не рассматриваются варианты
"что один и тот же символ может быть представлен разными способами".

clickmaker (2007-10-31 14:29:00) [53]

> Реализации RtlCompareString и RtlCompareUnicodeString ничем
> не отличаются.

а с чего бы? если windows nt насквозь уникодная

Riply (2007-10-31 14:27:00) [54]
>[4] Anatoly Podgoretsky © (31.10.07 13:11)
> Если не брать разные платформы, но никаких других форм не существует.

Это радует :)

> [5] Anatoly Podgoretsky © (31.10.07 13:14)
> Думаешь сравнение байта по сравнению со словом сильно отличается по скорости

Нет, я исходила из того, что в результате нужно сравнивать "меньший объем памяти :"
Например, если используется CompareMem :)

P.S.
Если кому интересно...

CompareStringA работает через CompareStringW,
которая, в свою очередь, использует RtlCompareUnicodeString.

Реализации RtlCompareString и RtlCompareUnicodeString ничем не отличаются.
Т.е. никакого учета "других форм" там нет. (Или я не умею смотреть)
(сравнение посимвольное)

Anatoly Podgoretsky (2007-10-31 13:14:00) [55]
> Riply (31.10.2007 03:51:00) [0]

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

Anatoly Podgoretsky (2007-10-31 13:11:00) [56]
> Reindeer Moss Eater (31.10.2007 11:12:02) [2]

Если не брать разные платформы, но никаких других форм не существует.

Riply (2007-10-31 11:49:00) [57]
> [1] guav © (31.10.07 10:56)
> Если считать что регистрозависимое сравнение - это сравнение памяти, то если длина известна и используется,
>то может быть быстрее анси версия, там этой сравниваемой памяти меньше, а если длина не известна,
>то сравнение должно осуществлятся по одному символу, чтобы искать #0 в процессе сравнения,
>тогда сравнивать число сравнений одинаково, потому и скорость может быть (почти) одинакова.

Примерно так же я и начала рассуждать и застопорилась.

> [2] Reindeer Moss Eater © (31.10.07 11:12)
> Куски памяти могут быть разные, а стороки ими представленные будут фактически одни и те же.
К своему стыду, вынуждена признать, что это для меня открытие :(

P.S.
Придется покопаться в ReactOS. Иногда там можно найти ответы на подобные вопросы.

Reindeer Moss Eater (2007-10-31 11:12:00) [58]
Наверное правильная реализация для юникода будет медленнее, с учетом того, что один и тот же символ может быть представлен разными способами.
То есть если для анси можно просто тупо сравнить целиком непрерывные куски памяти и если не совпало, то строки неравны, то для юникода такое может и не прокатить. Куски памяти могут быть разные, а стороки ими представленные будут фактически одни и те же.

guav (2007-10-31 10:56:00) [59]
В общем, быстрее или медленнее может быть какая-либо конкретная реализация сравнения, а не сравнение вообще.
Можно порассуждать о возможной реализации.
Если считать что регистрозависимое сравнение - это сравнение памяти, то если длина известна и используется, то может быть быстрее анси версия, там этой сравниваемой памяти меньше, а если длина не известна, то сравнение должно осуществлятся по одному символу, чтобы искать #0 в процессе сравнения, тогда сравнивать число сравнений одинаково, потому и скорость может быть (почти) одинакова.
Сравнение может и не быть побайтным сравнением. Например, если при сравненни учитывать, что в Unicode у некоторых символов моет быть много форм, и сравнение не должно давать разные результаты, или если сравнение используется для сортировки, то возможно прийдётся рассматривать Ansi строку как возможно мультибайтную и сравнивать положения символов в конкретном алфавите.

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

Страницы: < 1 2 3

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »