Ассемблер: memcpy (В чем подвох?)

[frp]

Ну CPU придётся проапгрейдить до i7, но ведь это мелочь!

Не поможет.

[drBatty]

разве апгрейд CPU сильно поможет? Там же в доступе к памяти затыки, а не CPU?

а вы всунете i7 в материнскую плату для iPIII?
нет. Потому, купив CPU, вам придётся докупить ещё и материнскую плату+память. А работать такой код(на i7) будет скорее всего как раз именно со скоростью memcpy из glibc на iPIII.
CPU тут упомянут просто для краткости, ибо всем понятно, что к i7 не пойдут DIMM-1.

Не поможет.

кстати, может и поможет. Если кеш там в 10 раз больше, то возможно будет меньше промахов, если мы кидаем например маленькие (~50b) куски памяти внутри маленького (~100K) файла - большая часть файла будет в кеше внутри CPU, и всё будет работать быстрее (точнее, не настолько медленно, как оно обычно).

[BratSinot]

Из -Os на десктопе смысл нулевой. А терять из-за нескольких байт производительность в разы - это не улучшение ИМХО.

-Os itak teraet skorost'.

BratSinot,
раз ужь взялись переписывать libc, не забудьте улучшить qsort. Сортировка пузырьком вместо используемого в glibc громоздкого алгоритма позволит сохранить куда больше памяти, чем улучшение memcpy.

Voobsheto qsort nety v ANSI C.

[frp]

кстати, может и поможет. Если кеш там в 10 раз больше, то возможно будет меньше промахов, если мы кидаем например маленькие (~50b) куски памяти внутри маленького (~100K) файла - большая часть файла будет в кеше внутри CPU, и всё будет работать быстрее (точнее, не настолько медленно, как оно обычно).

И это как-то сделает возможной сортировку массива из 1 миллиона int-ов? Что-то очень сомневаюсь. А merge или qsort могут сделать это за секунду и даже меньше. На селероне с маленьким кэшем.

Voobsheto qsort nety v ANSI C.

В ANSI C его нет, а вот в любой реализации libc он есть.

PS. А почему транслитом?

Voobsheto qsort nety v ANSI C.

И как раз qsort таки можно улучшить, а memcpy - вряд ли.

[watashiwa_daredeska]

Voobsheto qsort nety v ANSI C.

У меня другие сведения.

[drBatty]

не помню как в ANSI C, но в mslibc & glibc есть qsort
Os = оптимизация по размеру. На асм не действует. Учите матчасть.

[watashiwa_daredeska]

не помню как в ANSI C

Хотя, если именно ANSI C, то может быть. А если IEEE, то уже over 20 лет как qsort есть в стандарте.

[drBatty]

кстати, может и поможет. Если кеш там в 10 раз больше, то возможно будет меньше промахов, если мы кидаем например маленькие (~50b) куски памяти внутри маленького (~100K) файла - большая часть файла будет в кеше внутри CPU, и всё будет работать быстрее (точнее, не настолько медленно, как оно обычно).

И это как-то сделает возможной сортировку массива из 1 миллиона int-ов? Что-то очень сомневаюсь. А merge или qsort могут сделать это за секунду и даже меньше. На селероне с маленьким кэшем.

никак. я о другом случае. 1М intов это 4Мб даже на 32х битах.
BratSinot
толсто...

[frp]

толсто...

У нас не ЛОР же.

[taaroa]

У нас не ЛОР же.

…но один фиг по ссылкам не ходят. в самом первом сообщении отсылка к ответам на все вопросы по glibc.

[BratSinot]

Os = оптимизация по размеру. На асм не действует. Учите матчасть.

НО ДЕЙСТВУЕТ НА ФУНКЦИИ ВЫЗЫВАЕМЫЕ ИЗ glibc!!! Если ты указал -Os, он явно не будет вызывать _memcpy_sse42!

[frp]

НО ДЕЙСТВУЕТ НА ФУНКЦИИ ВЫЗЫВАЕМЫЕ ИЗ glibc!!! Если ты указал -Os, он явно не будет вызывать _memcpy_sse42!

На внешние библиотеки тоже не влияет. Если без оптимизации был бы вызван _memcpy_sse42 - он и будет вызван. Да и это никак не повлияет на размер бинарника - все равно нужная функция хранится в libc.so.6, а не в вашем бинарнике.

PS. Чего орать? И зачем нужна оптимизация по размеру кода на x86_64?

[Nazyvaemykh]

и да, в этом треде столько раз была упомянута какая-то оптимизация memcpy с использованием sse2, что мне уже стало любопытно. Можно посмотреть на исходники?

[frp]

quote name='Nazyvaemykh' date='19th September 2011 - в 19:40' post=1181961]
и да, в этом треде столько раз была упомянута какая-то оптимизация memcpy с использованием sse2, что мне уже стало любопытно. Можно посмотреть на исходники?
[quote]
Честно говоря, хз, какой профит может дать sse2 для memcpy. Мне тоже интересно, но исходников скачанных нет, а скачать смогу только завтра.

[BratSinot]

и да, в этом треде столько раз была упомянута какая-то оптимизация memcpy с использованием sse2, что мне уже стало любопытно. Можно посмотреть на исходники?

Во первых, я упоминал sse42, хотя вроде есть и sse3 и sse2.
Вообще, в SSE42 что-то про строки упоминается.

[drBatty]

НО ДЕЙСТВУЕТ НА ФУНКЦИИ ВЫЗЫВАЕМЫЕ ИЗ glibc!!! Если ты указал -Os, он явно не будет вызывать _memcpy_sse42!

1. не надо орать.
2. какое отношение имеет ваш код к glibc?
3. мне лениво смотреть исходники, есть много других мест, где можно сэкономить. И не только можно, но и нужно.

Честно говоря, хз, какой профит может дать sse2 для memcpy.

наверное речь идёт об увеличении числа бит. К примеру, MMX оперировала 64х битными числами на 32х битных компьютерах, SSE1 уже 128и битными числами. По идее, возможно перебрасывать данные из памяти в память по 128 бит. С другой стороны, если операции переброски 64х битных чисел спариваются, то разницы никакой. На практике похоже разница есть, но небольшая, и неоднозначная.


и кстати, макросы в memcpy() для i586 никак не зависят от -O, ибо также написаны на ассемблере. смотрел glibc-2.13