Изменение поведения memcpy в glibc привело к странным ошибкам

>А ты хочешь, чтобы было так: http://habrahabr.ru/blogs/Old_New_Thing/103598/ ?

это обычный closed source софт.

Он всегда был таким и таким будет. Микрософт не на что жаловаться. Каждая купленая быдлософтина тянет за собой покупку их ненужного вендувса.

Еще раз. Совместимость сломали, а зачем, непонятно.

Точно также недавно сломали совместимость vmware server с glibc. произошло это летом и все, vmware server больше не обновлялся. Его просто прикрыли и теперь его у нас под линуксом нет. Ура, поздравляю...

его из за патчей на LD_AUDIT вроде сломали, если не ошибаюсь ?

bash-4.1$ nm `which gzip` | grep memcpy
bash-4.1$ nm `which awk` | grep memcpy
bash-4.1$ nm `which bash` | grep memcpy
         U memcpy

cat cлинкован статически

Похоже, зависит от версии gcc, флагов и фазы луны. Или исходники пропатчили.

или вы думаете что флеш компилят без -O2 ? )

А может, он из-за этого и тормозит :)

>> как выяснилось, авторы многих проектов документацию не читали.

но хотя бы осуждают?

Осуждают не словом, но делом.

Тут кто-нибудь уже написал, что ошибка проявляется не в чём-нибудь, а в флэше*

GCC 4.3 (собственно с этой версии в выхлопе появляется rep movsl


http://gcc.gnu.org/gcc-4.3/changes.html
Code generation of block move (memcpy) and block set (memset) was rewritten. GCC can now pick the best algorithm (loop, unrolled loop, instruction with rep prefix or a library call) based on the size of the block being copied and the CPU being optimized for. A new option -minline-stringops-dynamically has been added. With this option string operations of unknown size are expanded such that small blocks are copied by in-line code, while for large blocks a library call is used. This results in faster code than -minline-all-stringops when the library implementation is capable of using cache hierarchy hints. The heuristic choosing the particular algorithm can be overwritten via -mstringop-strategy. Newly also memset of values different from 0 is inlined.


обратите внимание на
small blocks are copied by in-line code
НО (!)
while for large blocks a library call is used

достаточно любопытно получилось:

$ /bin/rm -f mcpy.s; cc43 -march=i486 -O2 -S mcpy.c && cat mcpy.s|grep -e «rep movsl» -e «memcpy»
rep movsl
$ /bin/rm -f mcpy.s; cc43 -march=i586 -O2 -S mcpy.c && cat mcpy.s|grep -e «rep movsl» -e «memcpy»
call memcpy
$ /bin/rm -f mcpy.s; cc43 -march=i686 -O2 -S mcpy.c && cat mcpy.s|grep -e «rep movsl» -e «memcpy»
call memcpy
$ /bin/rm -f mcpy.s; cc43 -march=pentium3 -O2 -S mcpy.c && cat mcpy.s|grep -e «rep movsl» -e «memcpy»
rep movsl
$ /bin/rm -f mcpy.s; cc43 -march=pentium4 -O2 -S mcpy.c && cat mcpy.s|grep -e «rep movsl» -e «memcpy»
rep movsl

или вы думаете что флеш компилят без -O2 ? )

А может, он из-за этого и тормозит :)

я так и подумала )

ввиду того что эвристика gcc зависит от кода, вот то на чем тестировала - http://paste.org.ru/?xgu6lp

Сильв, чем можно померять производительность реализаций memmove/memcopy?

написать код , который вызывает эти функции в цикле,
замерить время выполнения,
пересчитать количество вызванных циклов, перемещенных или скопированных байт на время выполнение, получить значение в GB/sec

На 4.2.1 все намного стабильнее.

$ /bin/rm -f mcpy.s; gcc -march=i486 -O2 -S mcpy.c && cat mcpy.s|grep -e "rep movsl" -e "memcpy"
	call	memcpy
$ /bin/rm -f mcpy.s; gcc -march=i586 -O2 -S mcpy.c && cat mcpy.s|grep -e "rep movsl" -e "memcpy"
	call	memcpy
$ /bin/rm -f mcpy.s; gcc -march=i686 -O2 -S mcpy.c && cat mcpy.s|grep -e "rep movsl" -e "memcpy"
	call	memcpy
$ /bin/rm -f mcpy.s; gcc -march=pentium3 -O2 -S mcpy.c && cat mcpy.s|grep -e "rep movsl" -e "memcpy"
	call	memcpy
$ /bin/rm -f mcpy.s; gcc -march=pentium4 -O2 -S mcpy.c && cat mcpy.s|grep -e "rep movsl" -e "memcpy"
	call	memcpy

$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-unknown-openbsd4.8/4.2.1/specs
Target: i386-unknown-openbsd4.8
Configured with: OpenBSD/i386 system compiler
Thread model: posix
gcc version 4.2.1 20070719 

замена идет с 4.3.x

пример:

http://paste.org.ru/?uwyqjn

вот код, который вызывает memcpy на 10Gb (желательно брать больше)
для примера там написана переопределенная функция memcpy() на си

а вот результаты:

«rep movsl» inline: real 0m10.212s user 0m9.942s sys 0m0.005s
glibc: real 0m10.249s user 0m9.983s sys 0m0.003s
замена на си: real 0m15.197s user 0m14.813s sys 0m0.007s

> чем можно померять производительность реализаций memmove/memcopy?

lmbench, но даже сравнит library call и не call.

> вот код, который вызывает memcpy на 10Gb (желательно брать больше)

главное желательно различать что за память вы копируете, должна быть просто больше L2 кэша. Или меньше чтобы была заметна разница от разных наборов инструкций :)

о! спасибо. Хочу посмотреть советы мыщъха по поводу memmove.

>А при чём тут «щепки летят», если выясняется, что некоторые кодеры прикладного софта манов не читают и лепят бажный код.

Внезапно, да?! :)

>Остаётся всё же неясным вопрос, почему бы разработчики glibc должны писать лишний код понижать скорость работы memcpy ради тех, кто не удосужился узнать, что ему необходима memmove? И самое главное, сколько ещё в glibc функций, которых кто-то использует неправильно за пределами документированного поведения?

Вопрос: а почему нельзя устраивать падение по ассертам в дебаг режиме?

Хотя, конечно, кто этот debug режим будет гонять? Valgrind и так умеет эту ошибку показывать, а толку то...

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

Добавили неприятный баг.

Какой баг?! Это не баг, это правильная работа функции описанная, в черт знает каком количестве документов.

Кхе-кхе, а что мешало разработчикам glibc реализовать корректную работу функции с самого начала, не?

Несмотря на то, что Линус довольно тонко там троллит, при этом успевая быстроенько накатать workaround, да ещё и показав что «оптимизация» не очень-то что-либо ускорила, его позиция всё-таки не очень понятна.

Как раз таки и понятна - в свете вышесказанного...

Понаписали-то, понаписали. Баг, не баг; сломали, не сломали. Шваб всё правильно сделал. Вот Microsoft тоже прилагает кучу усилий, чтобы программы/сайты, бывшие сломанными изначально, не «сломались» заметно сразу после апгрейда системы/браузера. В результате имеют неиллюзорный гемор на поддержке всей этой обратной совместимости и вызывают общественное порицание со стороны тех, кто заботится о соответствии своих программ/сайтов стандартам.

Алсо, Международный стандарт ISO/IEC 9899:1999(E) “Programming Languages — C”, статья 7.21.12.1 “The memcpy function”, пункт второй: “If copying takes place between objects that overlap, the behavior is undefined”. “The behavior is undefined”, а не “should not overlap”, как в мане. Зарепортите кто-нибудь баг в документации — s/should not/MUST NOT/, со ссылкой на RFC 2119.

>Несмотря на то, что Линус довольно тонко там троллит, при этом успевая быстроенько накатать workaround, да ещё и показав что «оптимизация» не очень-то что-либо ускорила, его позиция всё-таки не очень понятна.

Очень понятная позиция. Поработайте годик-другой, а лучше поруководите, крупным проектом и поймёте его позицию.

> пример:

http://paste.org.ru/?uwyqjn

вот код, который вызывает memcpy на 10Gb (желательно брать больше) для примера там написана переопределенная функция memcpy() на си

Пример не совсем корректный. Перед проведением каких-либо измерений следует инициализировать память, например с помощью memset. Иначе из-за copy-on-write, буфер, из которого проводится копирование, будет замаплен на единственную нулевую страницу и идеально закеширован. И результаты теста выглядят намного лучше, чем оно есть на самом деле.

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

что бы устранить баг руки не из того места растут легче костыль склепать

Линус ещё и подкалывает: «Вы действительно собираетесь выпустить Fedora-14, зная, что не работает Adobe flash?»

конечно, он тролль - ему положено :) лично мне же не совсем ясно с какого перепугу откладывать выпуск дистрибутива - из-за отвалившегося flash? так это не часть дистра, а проприетарная прокладка, которую не каждый-то и использует

Линуса, я смотрю, asm'ом не корми :)

>glibc в принципе всегда отличались тем, что пытаются переписывать на ассемблер то, что можно переписать, и активно используют новые расширения

это у вас откуда такая информация? SSE4 появилось в 2007 а патч исправляющий, между прочим, ошибку датируется как Fri Jul 02 2010 нихрена себе активно...

Так проблема всё же не в glibc, а во flash плагине. Ну и пофиг - не использую.

код, отвечающей во вселенной за солнце

Внимание! В новой версии фундаментальных законов вселенной количество выделяемого тепла для протон-протонной реакции приведено в соответствии со спецификацией! Всем астро архитекторам необходимо проверить и скорректировать параметры спроектированных звезд!

Малину портить думаю не получится. Волшебные изолирующие слои так или иначе спасут мир. Интел щас о них призадумался. И вон джобс параллельно думает не выкинуть ли интел в ведро. Интересная ситуация. :)

с какого перепугу откладывать выпуск дистрибутива - из-за отвалившегося flash? так это не часть дистра, а проприетарная прокладка, которую не каждый-то и использует

++

А если флеш не будет работать во всех дистрибутивах, появится реальный шанс развития html5 (хотя бы со стороны линуксоидов).

> SSE 4.2 (Intel Nehalem) же задействовали для сравнения строк

Адепты utf-8 дико ржут.

x86-64 KDE 4.5.3 Archlinux - УМВР ЧЯДН ?

glibc то какой?

2.12.1-3 видимо, в этом и дело :) Жаль, что в новости affected versions не пишут :(

>Зарепортите кто-нибудь баг в документации

Это не баг, а поведнние конкретной реализации. Всё ок.

Я так понимаю что юмористов на ЛОР-е полно, ослоумие так и хлещет, а вот с программистами напряг. Почитайте, пожалуйста, описание memcpy и его отличие от memmove. Это стандарт! Его обязаны соблюдать. Если раньше прощалось из-за того, что ранее не был использован потенциал для ускорения операции копирования, то сейчас этот потенциал использован. Надоговорить: молодцы! А тут стонут. Если кому интересно, в чём-то схожая ситуация была вокруг close(). Однако там обработка результата опциональна и Линус был прав. Сейчас же нужно первым пунктом потыкать мордой программистов в man. А вторым в нужном месте заменить на memmove. Да, это долго. Но нужно. Я вообще в шоке, этот man программистов второкурсников удивляет, а тут, по идее все гуру как один, сидят. Или вы предлагаете стандарт подправить? Может ещё проголосуем? Может заодно проголосуем и за отмену гравитации?

Да, так и бывает с кривым проприетарным софтом.

Я знал, что в адобе говнокодеры, ибо то же видео в мплеере не тормозило.

Теперь это подтвердилось.

О! Программист, наконец-то! Задрали неучи всякие, хоть один есть. Спасибо.

> Это не баг, а поведнние конкретной реализации. Всё ок.

Стоит добавить, одной из отстойных реализаций libc. А так всё ok.

> Может заодно проголосуем и за отмену гравитации?

Я за отмену!

Почитайте, пожалуйста, описание memcpy и его отличие от memmove. Это стандарт!

Стандарт никак не ограничивает реализацию memcpy он лишь говорит от том что при пересечении участков результат не определён, т.е он вполне может быть правильным в том числе. Это вопрос оптимизации. А оптимизация это слово о котором в проекте GNU знают лишь немногие.

Вот оно что... А я думал превью флеша кривой.

>его из за патчей на LD_AUDIT вроде сломали, если не ошибаюсь ?

Сильва, я сам глубоко не копал. Обнаружил, что в центос 5.4 оно уже ломается, а на 5.3 еще работает.

Да причём тут оптимизация? Вам нужно скопировать область памяти. Вы крутой программист. Мы знаете что что-то там про mem чего-то ам и нужно. В открываете man и читаете. Это школьники ничего не читают, потому-то знают. У специалистов всё не так, они читают, если конечно не каждый день этим пользуются. Если каждый, то и так должны наизусть знать. Они помнят: «Use memmove(3) if the memory areas do overlap». Всё, что ещё обсуждать. Ошибки нужно не признавать, а смывать (c) А они насмотрелись вещаний из конгресса и даже признавать не хотят. Ещё раз. Тут не место для голосований это техническая дисциплина. Вы ещё в теории рядов голосование проведите. Может вам БПФ не по душе.

Флеш кривой :) т.к. стандарт прямо запрещает передавать в memcpy пересекающиеся участки.

Стандарты для дураков. Маны читают только не осиляторы.

Даешь обратную совместимость со старыми багами!

Потом они приходят и говорят: нас больше, у нас демократия, давай делай как нам надо! Это повсеместное явление, не только среди программистов. Скорее для программистов редкое, тем более противное. Вон лемминги с винды сруливают на Ubuntu - тоже что-то там требуют. Нихрена понимать не хотят, но дай-подай. GNU/Linux - ОС для специалистов. И надо соответствовать. Или мы хотим новый Windows? Посмотрим прогнутся или нет.