Смена власти в проекте Glibc, уход Ульриха Дреппера из управления проектом

VP, Technology Division at Goldman Sachs. Location: Greater New York City Area;

Чо, пацан к успеху пришел.

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

Поэтому, кстати, в стандарте ничего трогать нельзя.

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

У вас ничего не изменится, копируйте через DMA, кто вам запрещает? Только дополнительно придется настраивать DMA на копирование в нужном направлении.

в стандарте ничего трогать нельзя, потому что это стандарт, и этого аргумента достаточно. можно дополнять, но не ломая совместимость.

я лишь указываю, что требование вместо memcpy подсунуть memmove? если с ним согласиться, должно быть стандартизовано. следовательно стандарт должен быть изменен, следовательно, такое требование нелегитимно.

Вот такая политика и привела к тому, что с Ульриком вежливо распрощались.

Это Ульрих распрощался. Дело в том, что RedHat - контора куда более бедная, чем Goldman Sachs :)

а я все думал, из чего же на самом деле «сакс» в данном случае транслитерировано было :)

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

Относительно внутренней реализации memcpy в libc. Я не знаю, чем объясняется полуторное падение производительности в тесте (оно как-то не совсем логично), но мне лень выяснять. Поэтому будем считать, что на вопрос «а стоит ли в сорцах libc делать 2 функции вместо одной» имеет ответ «стоит».

s/\?/,/

А сама возможность копировать в нужном направлении зависит от реализации работы памяти и DMA. может там асинхронное мультипоточное копирование.

я лишь указываю, что требование вместо memcpy подсунуть memmove? если с ним согласиться, должно быть стандартизовано. следовательно стандарт должен быть изменен, следовательно, такое требование нелегитимно.

Нет, это не требование. Это вопрос из разряда «если функциональность memmove > функцональности memcpy, может не париться и сделать их одной и той же функцией?» Т.е. это частное решение разработчика библиотеки, не ломающее никаких стандартов. Тест анона показал, что таки нет — имеет смысл «париться».

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

вы, емнип, выступали за то, что дрепперу нужно было прогнуться под адоб (поправьте, если я ошибаюсь). я пытаюсь донести, что запрет на произвольное направление копирования в memcpy есть изменение стандарта, поскольку стандарт разрешает копировать в любом направлении.

но мне лень выяснять. ... Поэтому будем считать, что на вопрос «а стоит ли в сорцах libc делать 2 функции вместо одной» имеет ответ «стоит».

считайте.

и да, таки вы оспариваете надежность теста. но я об этом уже не говорю, поскольку «мне пох» с вашей стороны принято к сведению.

верно, имеет. еще и потому, что помимо glibc, есть другие реализации. и то, что мы делаем в глибц #define memcpy memmove, не спасает нас от возможных багов во флеше на альтернативах glibc.

В реальную qsort размер данных придёт как параметр, сама qsort не инлайнится. Поэтому компилятор ничего не сможет соптимизировать по константному размеру, несмотря на __builtin_memcpy. В примере sorting тоже вызываются именно generic версии обеих функций, убедился в этом по листингу. (glibc-2.5-81.el5_8.1, так, для справки).

Кстати, если увеличить размер данных - до 4096, разница будет ещё драматичнее: ~ 284m инструкций для memcpy против ~ 708m memmove, +150%

s/и да, таки вы оспариваете надежность теста. но я об этом уже не говорю, поскольку «мне пох» с вашей стороны принято к сведению.//

моя ошибка

поправьте, если я ошибаюсь

Ошибаетесь.

и да, таки вы оспариваете надежность теста

У вас сегодня логика сбоит уже который раз. Я не оспариваю надёжность теста. Тест показал, что один и тот же код, собранный с memcpy и memmove, отличается в полтора раза по производительности. Это именно то, что он и должен был показать: есть разница в производительности или нет. Если разницы нет, значит сабжевый вопрос имеет ответ «можно использовать одну реализацию и не париться». Если тест показал разницу, ответ всё еще: «недостаточно информации». Но поскольку да, как вы заметили, «мне пох», я не буду выяснять детали. А раз не буду, то автоматически признаю правоту собеденика.

Ферштейн?

В реальную qsort размер данных придёт как параметр, сама qsort не инлайнится. Поэтому компилятор ничего не сможет соптимизировать по константному размеру, несмотря на __builtin_memcpy. В примере sorting тоже вызываются именно generic версии обеих функций, убедился в этом по листингу.

Да. Я говорил про случай константного размера блока, а не про этот конкретно код.

А теперь смотрим в реализацию memcpy и memmove и видим почему так происходит. Еще из этого кода сразу становится понятно при каких условиях разницы в работе этих функций приктически не будет. Что подтверждается экспериментами.

src > dst
memcpy: 551539758 cpu cycles
memmove: 535040373 cpu cycles

dst < src
memcpy: 535672756 cpu cycles
memmove: 869030893 cpu cycles

И тут речь идет скорее о неоптимально написанном memmove а не о том, что проверка занимает такую кучу времени ибо это извините бред.

Это Ульрих распрощался. Дело в том, что RedHat - контора куда более бедная, чем Goldman Sachs :)

«Если ты плюнешь в народ - народ утрется. Если народ плюнет в тебя - ты утонешь.» (с) Вот в этом смысле, очевидно, и «распрощались».

Да. Я говорил про случай константного размера блока, а не про этот конкретно код.

Насколько я помню, gcc развернёт __builtin_memcpy для небольших размеров блока, выше некоторого порога полагается, что libc версия memcpy эффективнее, а оверхед на вызов уже незначителен.

Но в целом, мы пришли к согласию?

Что memcpy и memmove не зря существуют в двух версиях, и объединять их не стоит в том числе и по критерию производительности, а так, что исторически сложилось.

А теперь смотрим в реализацию memcpy и memmove и видим почему так происходит.

Я вижу условие dstp - srcp >= len. Сравнение unsigned. Поясни, что не так.

Эк ты ловко назвал папуасами 6998000000 человек.

Эк ловко ты приписал мне то, что я не утверждал.

Да ещё оказывается и у меня проблемы. Ню-ню.

Да, так и есть. Причём и с логикой тоже.

Да нет, тут все в порядке, сравни внимательно код прямого и обратного копирования в memmove. Прямое копирование это memcpy один в один, а вот обратное немного отличается. Возможно для обратного копирования попросту невозможно сделать такую же реализацию как для прямого, но я пока в этом не убежден.

«Если ты плюнешь в народ - народ утрется. Если народ плюнет в тебя - ты утонешь.» (с) Вот в этом смысле, очевидно, и «распрощались».

Забавно, что основная масса линуксобыдла не способна оценить, сколь высока квалификация Ульриха, и не понимает, от какого количества головной боли Ульрих оградил сообщество. Плюйтесь сколько угодно - сидящий на колокольне в ваших плевках не утонет, вы попросту не способны до него доплюнуть. Скорее, это похоже на плевки против ветра :)

Вот такая политика и привела к тому, что с Ульриком вежливо распрощались.

Вообще то это Ульрик распрощался по простой причине - он работает в другой компании и не может уделять достаточно времени.

Меньше чем «идиотский» сей «аргумент» нельзя назвать при всем желании. Не плачь и познакомься уже с системами контроля версий.

И чем мне поможет система контроля версий?

Нет, погоди. В каких случаях мы выполняем прямое копирование? Разве в случае неперекрывающихся буферов управление не будет всегда попадать в первую ветку?

Забавно, что основная масса линуксобыдла не способна оценить, сколь высока квалификация Ульриха, и не понимает, от какого количества головной боли Ульрих оградил сообщество.

Тонко. А примеры лютых винов будут?

Ну да, конечно, я имел в виду выполнение условия

if (dstp - srcp >= len)

И в случае перехода по else получаем менее эффективное копирование. Теперь меня мучает вопрос - почему оно такое медленное?

А примеры лютых винов будут?

Рекомендую ознакомиться с его статьями, там множество сакральных знаний: http://www.akkadia.org/drepper/ Действительно круто.

Ну а легко наблюдаемый на практике лютый вин заключается в том, что я могу собрать свой блоб с glibc 2.3.6, и он одинаково хорошо будет работать на всем зоопарке дистрибутивов, начиная от выпущенных 6+ лет назад, и заканчивая самыми свежими.

Добавил в закладки, потом посмотрю. Я сейчас немного того...

Ошибаетесь.

признаю. претензии к вам оказались не по адресу, бес попутал

Ферштейн?

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

Там не всё так просто.

В sysdeps/x86_64, sysdeps/x86_64/multiarch есть масса всяких разных memcpy и memmove, и какие именно собраны для x86_64 centos 5.8, который я использовал в тесте, одному аллаху известно. В некоторых случаях по тесту типа процессора - выбирается одна из N версий в runtime, типа sse2/sse3.

Во всяком случае, по факту получается, что код memcpy заоптимизирован по самые помидоры и берётся из какого-то platform-specific memcpy.S, а memmove собирается из string/memmove.c и platform-specific макросов типа WORD_COPY_FWD и менее оптимально.

Что, в общем и делает разницу в тесте такой драматичной. Blame glibc :)

Я тебе указал точное число каких-то папуасов, которым никакого дела нет до эсперанто. Перестань лепить отмазки и у тебя всё будет хорошо. А обо мне не беспокойся.

А примеры лютых винов будут?

в данном случае отсутствие множества лютых фейлов сойдет за один лютый вин.

Кхм... Для многих здесь отметившихся фейл с флешем настолько лютый в их системе ценностей, что пересилит любой, наперёд заданный, вин произвольной весовой категории во всех прочих областях, вместе взятых. :D

Я тебе указал точное число каких-то папуасов, которым никакого дела нет до эсперанто.

Ну и как ты их насчитал, точный ты наш? :) Решил, что я якобы утверждал, что все, кому не нужен эсператно - папуасы? Топай в школу, учи логику.

Комбинаторика сэр. Метод перестановок элементов подмножеств множества, разбитого на подмножества по определённому критерию. Мне как-то всё-равно, что ты там сказал. А прежде чем мне тыкать логикой, осильте арифметику. И да, одного папуаса, про которого ты (по твоим отмазкам) говорил, можешь откинуть и поделить на 6999999999 и стать счастливым и перестать волноваться по моему поводу.

Забавно, что основная масса линуксобыдла не способна оценить, сколь высока квалификация Ульриха, и не понимает, от какого количества головной боли Ульрих оградил сообщество.

Мне, конечно, лестно что вы «весь в белом» решили меня записать в категорию быдла. А «до кучи» - разработчиков eglibc, мейнтейнеров libc в дебиан и еще кучу народа.

Квалификация тут непричем. В сущности, никто в ней и не сомневается. Просто более умные люди понимают, что из нее не следует правильности каждого технического решения, принятого «диктаторски» Ульрихом.

Не, ну с флешем-то действительно фейл вышел. Тока при чем тут Ульрих? Непонятно.

// ладно, поверю, что ты Михаил.

Говорят, что история не знает сослогательного наклонения. Кто знает, быть может, без его характера не было бы такой библиотеки совсем. Сейчас вот он отстранен, что ж, пусть попробуют без него.

Как же ты мог забыть

Это потому что все про Поттеринга, а про него уже и не вспоминают

Комбинаторика сэр. Метод перестановок элементов подмножеств множества, разбитого на подмножества по определённому критерию.

Сам-то понял, что сказал? %)

А прежде чем мне тыкать логикой, осильте арифметику.

Похоже ты её переосилил. Рекомендую подышать свежим воздухом.

делать жит компиляцию 2 секунды при каждом запуске? это копейки. 5 секунд копейки! что? вы можете за наносекунду? да кому это надо? ок.

нет разницы каждый разговаривает на своём языке.

пыщ на арме то зачем глибц? на арме 97% эмбеддед глибц туда толст. такчто ССЗБ и я бы тоже ВОНТФИКС

Просто более умные люди понимают, что из нее не следует правильности каждого технического решения, принятого «диктаторски» Ульрихом.

А правильности *каждого* и не требуется. Достаточно, чтобы правильными были *ключевые* решения. В остальном, развлекался Ульрих в багзилле или занимался чем-нибудь более полезным --- это уже не так важно..

я отвечал на обобщение -_- но ладно неактуально уже

чтобы у вас не оставалось иллюзий:

исправление было необходимо и неизбежно

дреппер плохо его подал а потом попиарился на конфронтациях.

попытки выявить главную причину отметая чуть менее значимые приводят к провалу.

делать жит компиляцию 2 секунды при каждом запуске? это копейки.

Вы упороты.

так вот кто прячет мои носки когда они рвутся да? \\всегда сказать эта шутка