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

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

Никто и не вставлял. Форкай libc или поддерживай патчи, кто же запретит то. А в центральную ветку со своими псевдоязыками лезть не надо.

Ню-ню.

Тем более, что никому эта поддержка не мешает.

Очевидно мешает. Например я не хочу качать ни одного байта из этих переводов на псевдоязыки, когда качаю исходники glibc.

А я не хочу качать ни одного байта из переводов, нужных тебе. Давай и их выкинем заодно? :-)

Не хочешь - делай форк под названием «руссишglibc» и люди к тебе потянутся.

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

А я не хочу качать ни одного байта из переводов, нужных тебе. Давай и их выкинем заодно? :-)

давно пора локали держать отдельно, а не тащить весь зоопарк.

Проверки можно перед настройкой DMA вставить, все равно на латентность это не повлияет существенно. В любом случае, придется адреса проверять, чтобы не позволить разрушить систему.

давно пора локали держать отдельно, а не тащить весь зоопарк.

Согласен.

Я про стандарты вообще ни одного слова не говорил.

А я не хочу качать ни одного байта из переводов, нужных тебе. Давай и их выкинем заодно? :-)

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

Не хочешь - делай форк под названием «руссишglibc» и люди к тебе потянутся.

Не хочешь эсперанто в glibc - делай форк под названием retardglibc. И соответствующие люди к тебе потянутся.

Но с тем, что кто-то придумывает новые языки непонятно зачем я смириться не готов.

Зря ты так нелюбишь языки. Они - хорошие.

Учить языки — интересно и полезно. К эсперанто, впрочем, это не относится.

Что же в них хорошего? Разнообразие языков - один из основных тормозов на пути прогресса.

извиняюсь, никого не хотел обидеть, просто слегка гиперболизировал для ясности.

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

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

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

предположение, что qsort используется в этих ваших ПРИЛОЖЕНИЯХ считаю самоочевидным.

Что же в них хорошего? Разнообразие языков - один из основных тормозов на пути прогресса.

А я думал, что один из основных тормозов на пути прогресса - неумение / нежелание познать новое (в частности, выучить еще один язык).

Лови - мопед не мой, я просто запустил valgrind. :-) Там три дефайна для управления размером данных и memcpy/memmove, см. makefile.

sorting.rar

DMA настраивать дольше, чем пара проверок, как минимум надо контекст переключать.

Зависит от реализации DMA engine и объема компируемых данных.

Продолжай.

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

считается, что эсперанто очень прост для изучения. я сам не в теме, но 2 миллиона эсперантистов не могут ошибаться :)

и, кстати, для цифрового распознавания текста

В общем если dst > src то копировать нужно от конца к началу. Вариант который проверен и работает :)

＞когда качаю исходники

Это проблемы индейцев, а у нас тут вендекапец, десктопы и прочее народное счастье.

Зависит от реализации DMA engine и объема компируемых данных.

А можно пример подходящего DMA engine? Мне интересно как это работает :)

Зато в мэйллистах теперь все будут вежливые и почтительные. :D

Вообще-то я про Дреппера...

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

А это странно, они по идее одним ветвлением различаются. Будем считать, что ты меня убедил.

А можно пример подходящего DMA engine?

А на какой-то архитектуре есть устрйоство для DMA-копирования памяти. Ну и обычный здравый смысл подсказывает, что сколько бы не стоил setup/teardown, он окупится на достаточно большом объеме копирования.

То, что какому-нибудь папуасу не нужен эсперанто

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

содержащий ВСЮ релевантную инфу

Ну так UB вполне себе релевантна. Релевантнее некуда.

А знаешь, анон, до меня дошло. Прочитал вон комментом выше:

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

и дошло.

memcpy может быть встроена компилятором прямо в код. Поэтому её нельзя прятать в шкаф от программиста.

Никто и не вставлял. Форкай libc или поддерживай патчи, кто же запретит то.

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

Например я не хочу качать ни одного байта из этих переводов на псевдоязыки, когда качаю исходники glibc.

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

Не думаю что это хоть как-то скажется на производительности системы вцелом.

уже сказалось. 60% оверхед, бенчмарк выше по треду

Не думаю что это хоть как-то скажется на производительности системы вцелом.

Если DMA настолько шустрое, что копирует за сопоставимое время, то разница будет ощутима.

Это как сравнивать 1 нм и 1,5 нм. Вроде бы больше всего на 0,5 нм, но при этом в полтора раза.

если разработчик memcpy отныне обязан копировать перекрывающиеся регионы особым образом, то UB в доках - прямое 4.2

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

Спасибо.

Кто сказал «обязан»?

Вообще-то я про Дреппера...

Ну, я этого не понял из контекста :)

Пока что разработчик обязан делать систему соответствующюю текущему стандарту. А в стандарте UB. И, видимо, еще долго там будет. потому что задача memcpy - скопировать побыстрее. А на разных архитектурах это реализуется по-разному.

просто откатить изменения в глибц будет недостаточно

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

а если бы у бабушки был пенис, она была бы дедушкой

убедитесь, что memcpy инлайнится, а memmove - нет, потом оспаривайте надежность теста.

Поэтому её нельзя прятать в шкаф от программиста.

инкапсулировать можно все что угодно

Я не «оспаривал надежность теста». Вы неадекватны. Выпейте таблеточку и ложитесь спать.

линус сказал. и еще табун анонимусов-юзерофилов

Линусопроблемы.

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

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

с учетом этого, откатывание тут при том, что баг обнаружили уже после релиза глибц

аргументы к личности не рассматриваю

поясните тогда, пожалуйста, что вы имели ввиду:

А знаешь, анон, до меня дошло. Прочитал вон комментом выше:

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

и дошло.

memcpy может быть встроена компилятором прямо в код. Поэтому её нельзя прятать в шкаф от программиста.

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

И забить на переносимость? эта самая memcpy может инлайниться автоматически, на уровне компилятора.