Увидел свет (http://sourceware.org/ml/libc-alpha/2012-03/msg00836.html) релиз системной библиотеки GNU C Library (http://ftp.gnu.org/gnu/glibc/) (glibc) 2.15, которая полностью следует требованиям стандартов ISO C99 и POSIX.1-2008. В подготовке нового выпуска использованы патчи от 32 разработчиков. Новая версия отличается добавлением утилиты pldd, реализацией большой порции оптимизаций для систем x86-32 и x86-64, а также добавлением поддержки программных интерфейсов, появившихся в последних выпусках ядра Linux.
Glibc является основой большинства Linux-дистрибутивов, за исключением OpenWrt, Debian и Ubuntu, которые перешли на использование системной библиотеки Eglibc (http://www.eglibc.org/). Библиотека Eglibc построена на актуальной кодовой базе Glibc и полностью совместима с ней на уровне API и ABI, отличаясь (http://www.eglibc.org/faq) интеграцией некоторых дополнительных наработок для встраиваемых систем, более низкими системными требованиями (поддерживается сборка с отключенными компонентами для обеспечения совместимости), возможностью гибкой настройки компонентов, улучшенной поддержкой кросс-компиляции и кросс-тестирования.
Из добавленных в Glibc 2.15 улучшений можно отметить:
- В состав включена утилита pldd для вывода списка загруженных объектов для заданного процесса;- Поддержка новых программных интерфейсов:
- scandirat и scandirat64 (http://article.gmane.org/gmane.linux.man/2419) - для сканирования директории, связанной с указанным файловым дескриптором;- process_vm_readv, process_vm_writev (http://ozlabs.org/~cyeoh/cma/process_vm_readv.txt) (поддерживаются только ядром Linux начиная с версии 3.2) - для организации прямого обращения к областям памяти других процессов. Главной идеей технологии доступа к внешним областям памяти является решение задачи по предоставлению MPI-приложениям эффективных средств для взаимодействия между процессами внутри одного узла кластера, например, вместо дополнительного копирования сообщения через разделяемую память можно обеспечить прямой доступ к одной копии сообщения;
- Оптимизации:
- Для математических функций реализованы многочисленные оптимизиации производительности, специфичные для 64-разрядных систем;
- С задействованием инструкций SSE2 и SSSE3 оптимизированы функции strcpy, strncpy, stpcpy и stpncpy для архитектур x86-32 и x86-64.
- Оптимизированы варианты функций strcat и strncat для архитектуры x86-64, а также функций wcscmp, wcslen и strnlen для x86-32 и x86-64;
- C использованием SSE-инструкций оптимизирваны функции strchr и strrchr для архитектуры x86-32 ;
- Оптимизированы функции memchr, memrchr, rawmemchr, memcmp, wmemcmp, wcschr, wcscpy для архитектур x86-64 и x86-32;- Оптимизированы функции strcasecmp и strncasecmp с использованием инструкций AVX для систем x86-64;
- Оптимизированы strcasecmp и strncasecmp с использованием инструкций SSSE3 и SSE4.2 для архитектуры x86-32;
- Для платформы PPC оптимизированы функции nearbyint и strcasecmp;
- Возобновлена поддержка nss_db, которая теперь избавлена от зависимости от BerkeleyDB и поддерживает выборки через initgroups (http://linux.die.net/man/3/initgroups);
- В nscd реализовано кэширование базы netgroup;- Обеспечение сборки libm с поддержкой опции gcc "-ffinite-math-onlylibm";
- Добавлена проверка версий FD_SET, FD_CLR и FD_ISSET;
- Новые локали: bho_IN, unm_US, es_CU, ta_LK;
- Исправлено 67 ошибок.
В следующей версии Glibc 2.16 ожидается (http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=NEWS;h...) поддержка режима совместимости со стандартом ISO C11 (добавление timespec_get, aligned_alloc, static_assert, at_quick_exit и quick_exit, скрытие gets, поддержка uchar.h); удаление из состава поддержки архитектуры IA-64 и форматов исполняемых файлов, отличных от ELF; продолжение оптимизации производительности для 64-разрядных архитектур.URL: http://sourceware.org/ml/libc-alpha/2012-03/msg00836.html
Новость: http://www.opennet.me/opennews/art.shtml?num=33418
Молодцы! Так держать!)
А где найти сравнение и руководство выбора между glibc и elibc и еще ulibc? В чем между ними разница? Для каких задач лучше одно, для каких - второе, для каких - третье?
http://www.etalabs.net/compare_libcs.html
Возможно, сравнение не самое свежее, но общее представление даёт.
Ух, ты...
А что "поломали"? Или добротно сделали?
На арчеводах уже три месяца обкатывают.
И правда, а я и не заметил :)
Гы, второй параграф впихнули в качестве тематического наброса. =)
Видимо абзац добавили с учетом того, что прошлые обсуждения новых Glibc перерастали в ликбез, что eglibc это не форк :-)
Вот за SSE, SSE2, SSSE3, SSE4.2 и AVX отдельное им спасибо.
> С задействованием инструкций SSE2 и SSSE3 оптимизированы функции strcpy, strncpy, stpcpy и stpncpyПростите за глупый вопрос, но это что, реально ТОЛЬКО СЕЙЧАС было сделано? И что, до сих пор любые, сколь угодно современные процессоры, под Линукс перегоняют строки по байтику?
Возможно до этого было MMX и SSE1.
Это понятно.
Но SSE2 появилось в Pentium4, который уже успел устареть!
А реализация базовых функций, используемых тысячи раз в секунду, до сих пор об этом не знает?
вы прям как с луны свалились, чесслово.
ну посмотрите какие версии рантайма си в вашей винде стоят и успокойтесь.
а потом представьте на минутку - делали ли пересмотр всех >50'000 функций винапи на тему "чтобы там такое улучшить под новые процы и ничего не поломать в совместимости" при условии, что я постоянно сталкиваюсь с багами в винапи, которые за 15 лет так и не починили (а может уже и не нужно, а то старые проги что их обходили через сами_знаете_что вообще перестанут работать)
На винду мне, честно говоря, наплевать. Там оптимизации бесполезны.
Но, поставив дома дистрибутив Линукс, скомпилированный под AMD64, я предполагал, что библиотеки этого дистрибутива знают о возможностях этой платформы...
Да ладно, библиотеки - glibc же! Через нее же, насколько я понимаю, любое копирование строки в любой программе пойдет. Очевиднейшее узкое место.
Во первых, читайте новости. Говорили о конкретных функциях, многие другие (например, толи memcpy, толи strcpy) уже давно на SSE 4.2 сидят.А во вторых, amd64 включает в себя только до SSE2.
> memcpy, толи strcpy) уже давно на SSE 4.2 сидят.А, это когда Линус завозмущался.
> А во вторых, amd64 включает в себя только до SSE2.
Бывают разные amd64: Athlon 64 3000+ - да. Phenom II X4 850 уже с SSE3, SSE4a. Ну а бульздозер, наконец-то с SSE4.1, 4.2
бывают.
но дело то не в этом.чуть ниже написал - важно ещё и кем, когда, какой версией компилятора, с какими параметрами собрана сама glibc.
есть оптимизации на уровне кода, а есть на уровне компилятора.
это ведь не блоб 10-летней давности, а свеже-собранный.
Извините, если написать код strcpy в стиле учебников для начинающих, компилятор вряд ли сможет это превратить в инструкции с использованием SSE2.
Иначе и glibc незачем было переписывать - перекомпилировал, и все.
А вы видели код strcpy?
Он не настолько прост и однозначен.Зыж
Если посмотреть поверхностно — а там точно нужны ссе2?
А если не поверхностно, то с учётом одних регистров для ссеХХ/ммх/фпу/.., контекстов переключения, кэширования лХ... — результат выбора не однозначен.
GCC, насколько я помню, эти функции реализует сам.
именно.
даже при -march=native -О2.но одно дело когда оптимизатор компилятора постарался и другое, когда сама функция так написана байдезигн.
вот рантайм от какого-нибудь vc6 или vb6 не изменится ни при каких обстоятельствах.
даже если его очередная винда будет запускать в режиме совместимости/виртуализации/следующий_костыль. :D
Пример "бага" WinAPI приведёте?
ха! ванюша в своём репертуаре. :D
навскидку - читать/писать из ком-порта (и усб-девайса, представляющегося ком-портом - а таких очь много) можно только по-байтово. в линухе и соляре работает с буфером бОльшего размера, в винде - нет. бага со времён вин95.
тоже самое с сокетами - но там буфер не может быть больше 64кб. так пишешь прогу и в тестах она работает. сдал, а там пришли пакеты 64кб+1 - всё, дрындец. пишешь цыкл по обработке такой ситуёвины.
или "подождите неколько (без 'с') минут" просуществовал весь жизненный цикл. так и помер:D
и так постоянно! читаешь мсдн - должно работать. прямым текстом написано - буфер для компорта такойто, для сокета - вообще не ограничен.
но не работает!
результат - у каждого (!!!) разраба есть список форумов с рецептами обхода/костылей!
зыж
если в опенсорсе есть традиция - нашёл баг, пхни разрабов, исправят. а пока правят, накладывай свой патч и работай со своеё прогой правильно.
ха, попробуй пнуть мастодонта мс - в лучшем случае ушиб голеностопа заработаешь.
баг-треккер то для винапи хоть появился? или о таких траблах до сих пор с манагерами приходится разговаривать? а это разговор глухонемого со слепым. и у обоих болезнь альцгеймера.
Вы указали особенности реализации, а "баг" - это ошибка, когда функция делает не то, что от неё ожидается.> читаешь мсдн - должно работать. прямым текстом написано - буфер для компорта такойто, для сокета - вообще не ограничен.
но не работает!
Ссылку на MSDN дайте, пожалуйста.
Хм.
Найди обратное в мсдн и я признаю что был не прав.
>навскидку - читать/писать из ком-порта (и усб-девайса, представляющегося ком-портом - а таких очь много) можно только по-байтово. в линухе и соляре работает с буфером бОльшего размера, в винде - нет.Бред сивой кобылы. WinAPI - окаменелое сборище костылей с кучей недостатков, но конкретно вот это - чтение/запись в COM-порт в количестве более одного байта на один вызов ReadFile/WriteFile - там работает. Проверял на всех версиях венды, начиная с 2000 и заканчивая семеркой SP1.
Не работает.
Точка.
Проверено на куче весов (от магазинных, до 50 тонных)Ещё раз — не работает.
Если не хотите получить вес предыдущей фуры и сесть лет на 5.
Нету там багов :) Нету багтрекера - нету багов :)
> Нету там багов :) Нету багтрекера - нету багов :)То что вы и другие называете "багами" в большинстве своём описано под описанием функционала с разделе "Решение проблем" ("Troubleshooting") с указанием конкретных методов решения. Наиболее часто там идёт что-то вроде:
- данная функция устарела ("obsolete"), используйте функцию ***
- данная библиотека (какая-нить DLL) больше не поддерживается и включается в состав ОС для совместимости, используйте ***
- в ряди сценариев при размере буфера больше *** байт функция может возвращать ошибку. Уменьшите размер буфера или используйте функцию ***Это "баг"? Нет. А "баг-трекер" присутствует, но выглядит и называется иначе - support. Разве что это не 1% юзеров, а 85%, поэтому и отвечать каждому об изменении статуса сообщения (а если она есть обращений приходит много) никто не будет - морда лопнет.
Ну для вас это может быть и решение проблем.
Как говорится кому и кобыла невеста.
А для вас лучше, как это принято в СПО, изменить API? Ну-ну... Половина ПО нахрен отвалилась и должна обновляться вслед за платформой, старое ПО не факт что работает и не проверишь пока не ёкнется.
Да, да. Расскажите нам еще этих сказок про то как в винде старое ПО никогда не отваливается.
В Win7 до сих пор работает ПО из Win3 (1990), прикинь?
https://encrypted.google.com/search?q=mechwarrior+4+windows+xp
пасьянс косынка?
Иди гугли по словам список несовместимых программ windows7. А если будешь рассказывать про это было давно, включи режим совместимости... Посоветую тебе в линухе поставить виртуалку со старым софтом, либо взять более новую версию.
> В Win7 до сих пор работает ПО из Win3 (1990), прикинь?Зато не работает кое-что, что писалось в 2005 и прекрасно работало в XP, прикинь? Даже VirtualPC с XP внутри (ни разу не костыль, да) не всегда спасает. Компатибилити, однако.
На удивление ПО из Win3 работает в большом количестве ОС.
Но проблема в том, что народу нужно ПО из Win5, которое в Win6+ почему-то массово дохнет и, о ужас, разрабам приходится тяжело пилить софт, делая выпуски новостей а-ля "теперь работает и в Vista/Win7"
шито? 12 лет на линуксе - все работает как часы, и для апдейта ядра, сис. библиотеки, DE – мне не нужно переустанавливать систему.
У меня wasm 12-летней давности запускается до сих пор, а у вас запустится GCC 12-летней давности?
ХА! ДА!!! :D
sys-devel/gcc
Available versions:
(2.95) *2.95.3-r9 ~*2.95.3-r10!s
(3.1) *3.1.1-r2
(3.2) **3.2.2!s *3.2.3-r4
(3.3) ~3.3.6-r1!s
(3.4) 3.4.6-r2!s
(4.0) ~*4.0.4!s
(4.1) 4.1.2!s
(4.2) ~4.2.4-r1!s
(4.3) ~4.3.3-r2!s 4.3.4!s ~4.3.5!s 4.3.6-r1!s
(4.4) ~4.4.2!s ~4.4.3-r3!s 4.4.4-r2!s 4.4.5!s 4.4.6-r1!s
(4.5) ~4.5.1-r1!s ~4.5.2!s 4.5.3-r1!s 4.5.3-r2!s{tbz2}
(4.6) [M]**4.6.0!s [M]**4.6.1-r1!s [M]**4.6.2!s
зыж
ну когда ж уже ты хоть немного будешь компетентен?
мне и то за тебя стыдно (неужели все ванюши подстилки корпорастные?)
> ну когда ж уже ты хоть немного будешь компетентен?не раньше, чем закончит запихивать float в один бит.
> То что вы и другие называете "багами" в большинстве своём описано под
> описанием функционала с разделе "Решение проблем" ("Troubleshooting")
>...
> Это "баг"? Нет.Подобные вещи, это не просто баги - это баги, которые они же сами признают, находят пути обхода, но исправлять не собираются (и другим не дают). Даже производители процессоров исправляют баги, а не только описывают их в errata с возможными workarounds (а им-то уж на порядок сложнее и дороже это делать). Но можно, конечно, и внушением: "есть обход, значит не баг" (повторять перед сном не менее 10 раз).
>> Нету там багов :) Нету багтрекера - нету багов :)
> То что вы и другие называете "багами" в большинстве своём описано под
> описанием функционала с разделе "Решение проблем" ("Troubleshooting")Ладно, пусть на ms speak это будут не баги, а траблы. Им там не привыкать и дырки называть "функциональностью".
> А "баг-трекер" присутствует, но выглядит и называется иначе - support.
Багтрекер оперирует багрепортами, а суппорт -- траблтикетами. Всё правильно. Главное, чтобы ни один функционал не пострадал.
:-/
Ну, например, мне часто приходится в программах полностью формировать вывод на печать.
Так что я не первый год помню, что размер шрифта в выводе не должен равняться 70 пунктам (не кегль шрифта, а именно результирующий размер на печати). Иначе надпись превратится в тыкву.
Это, наверное, не баг, а пасхальное яйцо?
Хмм.. Пример кода прислать готовы? Или выложить сюда. Не встречал ограничений, тем более связанных с "магическими" цифрами.
А что там кодировать?
Создаем графический контекст, задаем шрифт (у меня чаще всего Arial используется), выводим надписи шрифтом нескольких размеров. На 70 пунктах будет провал - надпись будет раз в 10 меньше, чем ей положено.
Попробовал, работает. Видимо лажаете в другом или просто ***.
Была у меня такая ощибка. Точно помню на 2000 (без сервиспаков еще) и помойму на NT
в дельфи делал так, если магическое число тогда магическое число -1 и все похало
> Пример "бага" WinAPI приведёте?Да фигня вопрос. Если уж тут народ с COM-портами вылез, извольте, я добавлю:
Мы -> API: "дайте нам 921600, нам впадлу телепать на 115200!"
API -> мы: "окей, ваши параметры установлены успешно!"
По факту: драйвер столько не умеет. Но мы никогда об этом не узнаем. Нам соврут что все зашибись.Итого: нет никакой реальной возможности понять, поддерживается ли некий baud драйвером и уж тем более нет никакой возможности проверить успешно ли этот baud установился. Нам всегда врут что все замечательно.
ЗЫ а в пингвине эквивалентные сисколы на раз возвращают ошибку если бауд не поддерживается драйвером. Забавно, да? Вообще, программить микроконтроллеры под линуксом явно удобнее. Там еще и usb работает намного менее криво ;)
Я тоже в шоке. Это ж надо преждевременной оптимизацией в каждой(!) своей программке немного заниматься, думать, где бы копирование сэкономить. А надо было просто один(!) раз пойти в glibc и один раз и навсегда оптимизировать там. И программить дальше себе тихо и спокойною.
>А надо было просто один(!) раз пойти в glibc и один раз и навсегда оптимизировать там.как старый пердун, преподававший асм, скажу - сейчас порой ГОРАЗДО надёжней положиться на оптимизацию компилятора, чем пытаться оптимизировать самому.
сколько раз уже сталкивался - вот соптемизировал, а работать стало медленнее. смотришь, а оно теперь в кэшЪ номер N не влазит и все конвейеры пошли лесом.
> сколько раз уже сталкивался - вот соптемизировал,Ну если оптЕмизируешь так же пишешь - тогда все понятно... :)
да кого интересуют мнение гумманитариев...зыж
>тогда все понятно... :)понятно так же, как:
а) запятые расставлять,
б) "тыкать" не знакомым,
в) путать орфографию с программированием
? :D
Вообще то он прав. Оптимизация до конвейера делать бессмыслено, кэш лишь увеличивается, так что используя напр. "align 64" можно быть уверенным что медленнее не будет (это если знать что такое "align 64" и уметь его применять к месту).Весь проект на ассемблере писать нет смысла, хотя мой опыт показывает что при наличии проекта на С++ + Win32 его можно за очень небольшое время перегнать на ассемблер, получив сокращение кода в 3-4 раза и ускорение на 5-15% безо всяких оптимизаций.
Ассемблерная оптимизация в коде на ЯВУ может дать прибавку в 20-500% производительности, но требует значительных затрат времени на отладку и приличное знание как ассемблера, так и методик оптимизации. Напр. код рисования линии по Брезенхейму без использования WinAPI (отрисовка виртуального окна производилась в другой функции), прогнанная чёрти сколько раз, на С++ выполнялась 200 мс, на оптимизированном асме 25, встроенная LineTo (она, правда, использует ускоритель видеокарты) лишь 3.
Тест в стиле форониксов? Зачетно.
Но перегон всего проекта на асм ради 5-15% ускорения - это ОЧЕНЬ по-студенчески. Как и замечание про "сокращение кода в 3-4 раза". Ассемблерного. По сравнению с "плюсами". Что не с размером объектного файла сравниваем?
Цель была оценить, а заодно проверить теорию что разработка на функциональном ЯВУ с последующим переписыванием на ассемблер быстрее, чем разработка на ассемблере изначально.Сравнивались размеры скомпилированных EXE-файлов за вычетом размеров ресурсов (= бинарный код).
> а заодно проверить теорию что разработка на функциональном ЯВУ
> с последующим переписыванием на ассемблер быстрее,
> чем разработка на ассемблере изначально.Так это не теория, а давно известная практика прототипирования. Как-то работали с ирландцами, где один на местности рисовал быренько переходники на php до рабочего вида, а второй у себя читал, переписывал на плюсах и доводил до эксплуатационного вида.
> путать орфографию с программированиемДядьку, ну я бы тоже с опаской слушал асм у преподавателя, который делает грубые ошибки в русском. Он может быть неплохим специалистом в том, что рассказывает -- но если позволяет себе спустя рукава относиться к родному языку, то откуда знать, что он и к студентам (или предмету) так же не отнесётся?
Это не теория -- когда брался за *nix, одними из наиболее интересных и авторитетных людей на почитать или послушать были Виктор Вагнер, Валентин Нечаев, "Андрей Зубинский". Все они писали по крайней мере тогда весьма грамотно и тщательно, и у всех можно было почерпнуть больше, чем строго по обсуждаемой теме. Надо и нам тянуться, даже отпреподавав :)
PS: спасибо, интересно. А с винды что взять -- там хорошо хоть работу с файликами досдевайсного вида заткнули, весело было прислать LPT1:. :)
>Дядьку, ну я бы тоже с опаской слушал асм у преподавателя, который делает грубые ошибки в русском. Он может быть неплохим специалистом в том, что рассказывает -- но если позволяет себе спустя рукава относиться к родному языку, то откуда знать, что он и к студентам (или предмету) так же не отнесётся?вам с таким подходом только президентов избирать - кто красивее и правильнее скажет.
да на ридной мове (или как там?).
и не важно, что в математике он как Пушкин.зыж
не все, кто красиво и правильно говорит, под амбразуру лягут.
угу.
а скорее даже наоборот.
+1, переставил местами 2 стейтмента (сохраняя логику) — меняется время выполнения. Просто где-то какая-то эвристика предсказания начала промахиваться, и вот ты уже проиграл 5% времени выполнения.
add ax,bx
add bx,cx
add ax,cxи
add bx,cx
add ax,bxПервый код выполнится быстрее (инструкции спарятся), второй займёт меньше места. Эвристика, мля... И магия. Разумеетя "леноровская".
> мля... И магия. Разумеетя "леноровская".Нет, дядя, эта магия называется некромансией. Потому что 16-битный асм это сильно, да :)
> Линукс перегоняют строки по байтику?Опух? Там давно уже оптимизации, тем более что у x86 есть команды копирования в цикле.
rep movsq медленнее копирования через MMX, копирование через MMX медленнее, чем через SSE.
> тем более что у x86 есть команды копирования в цикле.которые до относительно недавнего времени нещадно тормозили из-за бага в микрокоде.
> process_vm_readv, process_vm_writev (поддерживаются только ядром Linux начиная с версии 3.2) - для организации прямого обращения к областям памяти других процессов.Они изобрели наконец-то kvm(3) ?
hint.
$ man -k kvm
kvm(3) - kernel memory interface
Нет, это не то. Учитесь читать.
ждем в debian testing, хотя это, наверное, будет уже после выпуска 7.0...