У меня появилось желание не просто вызывать уже скомпилированные методы библиотеки glibc, но и иметь возможность работать с исходным кодом этой библиотеки (для чего я уже скачал исходники). Сейчас у этого решения вижу такие плюсы:

1. При отладке можно заглянуть как реализованы методы и возможно как-то оптимизировать их под свой частный случай.
2. Появится возможность некоторые "тяжелые" методы подобным же способом вызывать из других библиотек: Сравнение библиотек
3. Библиотечный код попадет под действие оптимизирующих ключей компилятора, что может повысить производительность.
4. Имея весь код можно более полноценно использовать Profile-guided optimization
5. Можно попробовать собрать итоговый код программы другими компиляторами. Я пробовал собрать всю glibc с помощью компиляторов Clang и Intel, но это не удалось из- за ошибок (а вот gcc собрал). Так как в программе используется только часть функционала glibc, то возможно удастся собрать итоговую программу с помощью Clang и Intel.

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

BarloneА какие "тяжелые методы" есть в glibc? qsort и strstr?
Там же в основном обертки для системных вызовов и платформенно-зависимых вещей.

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

Я привел сравнение производительности библиотек для нескольких методов. Это сравнение показывает, что не всегда glibc имеет самую лучшую производительность.

Dima TКак понимаю ты хочешь получить ускорение за счет inline кода библиотеки в твой код во время компиляции.

Не получится, т.к. то что может инлайнится уже инлайнится. Это особенность С++: если все прописано в *.h то код инлайнится, но если код в *.cpp то - нет, т.к. это отдельная единица компиляции.

Но это не критично. Уйдя от этого ты многократно не ускоришь свой код. ИМХО станет быстрее на проценты, может 10+%, но не в разы.

Про inline нигде не писал, а вот в комментариях к статье из п.4 один товарищ написал о двукратном повышении производительности. Да и п.1 может хорошо сыграть: библиотека написана "на все случаи жизни", поэтому делает кучу лишних телодвижений, которые я могу сэкономить.

kealon(Ruslan)AlekseySQL,

мне кажется не нужно с исходниками заморачиваться, тынц

кстати, для glibc есть много альтернативных реализаций

PS: а зачем вам сишная библиотека?

Спасибо, за советы по теме топика.

В предлагаемой ссылке рассматривается статическое связывание ВСЕГО glibc (и говорится что это невозможно). Но у меня нет такой задачи: я хочу всего- навсего оптимизировать несколько "горячих" функций из библиотеки, подставив их исходный код, и проведя над ним оптимизацию. А остальные вызовы glibc пусть остаются динамическими.

В частности мои "горячие" вызовы:
Vtune Amplifier__GI_____strtoll_l_internal libc.so.6 113.956s
__GI_strchr libc.so.6 73.730s
pow libm.so.6 13.097s
strtol libc.so.6 5.755s

В настоящий момент трудность в том, чтобы сопоставить вызовам функций конкретные файлы библиотеки glibc (для включения конкретных файлов в проект).

1. При вызове методов библиотеки мы использует директивы include, указывая для нее весьма абстрактные называния. Например,



но при распаковке исходников у меня целая папка "cstdlib", в которой куча с- файлов для нужных мне методов. Например:



Но я не вижу h- файла, который бы содержал интерфейс для метода "strtol".

2. В своем изначальном коде я НЕ использовал директиву



, но несмотря на это для функий atoi, atol и atoll система каким-то чудом нашла библиотеку glibc и начала ее использовать (это показывает Vtune Amplifier). Как такое возможно?

kealon(Ruslan)AlekseySQL,

$ ldd <prog>

покажет тебе что использует либа\приложуха

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

Dimitry SibiryakovAlekseySQL(так я смогу взять из библиотеки только то, что нужно).

Зачем тебе брать такие тривиальные функции? Они же пишутся с нуля левой пяткой.


Я, например, не знаю как эффективно написать преобразование строки в число. Скорее всего последовательный перебор всех символов, их преобразование по таблице ASCII и суммирование различных степеней 10 - будет самым медленным решением.

Например, "184" = 1 * pow(10,2) + 8 * pow(10,1) + 4

Dimitry SibiryakovAlekseySQLЯ, например, не знаю как эффективно написать преобразование строки в число.





Надеюсь проседание производительности будет хотя бы в 10 раз...

AlekseySQLНадеюсь проседание производительности будет хотя бы в 10 раз...

Оказывается я пернул в лужу! :)

При собственной реализации функции преобразования строки в число полное время выполнения программы сократилось до 43 секунд против 62 секунд для библиотечной реализации. Странно, в википедиях написано, что glibc даже ассемблерные оптимизации использует. Никогда бы не подумал, что замена библиотечных вызовов самописками может так сильно поднять производительность (теперь буду знать, что после определения профайлером "горячих" мест надо попробывать переписать их руками).

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

Продолжу самобичевание :)

Профайлер показал, что библиотечное преобразование занимало 102 секунды процессорного времени, а самописное настолько маленькое, что вовсе пропало из результатов анализа (при этом общее процессорное время сократилось на 103 секунды). При этом я проверял отладчиком: самописное преобразование работает корректно.

Народ, а почему происходит такая адовая просадка производительности при вызове библиотечных функций?

p.s. Если заглянуть в исходники glibc, то некоторые функции имеют аналоги для sse2! Никогда бы не подумал, что будет такая просадка производительности.