Здравствуйте, Сергей Мухин, Вы писали:
СМ>может я не понимаю что предлагается, но я вижу, что код функций из библиотеки содержится один раз во всем процессе. Это так?
Нет, именно не так.
Еще раз.
Создаем свою static library, включающую в себя исходную library. Статически включающую, то есть код исходной static library просто находится в нашей static library. Статически влинкован.
Создаем еще одну свою static library, включающую в себя исходную library тем же образом
Итого имеем 2 свои static library и ничего больше пока. В первой library все имена функций начинаются на my1, во второй — на my2, все остальное одинаково.
Создаем EXE — проект.
Подключаю в него my1lib. Имею полное право. И буду из нее вызывать my1* функции. Они будут вызывать исходные функции, которые внутри my1lib.
Подключаю в него my2lib. Имею полное право. И буду из нее вызывать my2* функции. Они будут вызывать исходные функции, которые внутри my2lib.
Исходную library в проект EXE не включаем вообще, не нужно.
То есть в my1lib сидит код исходной lib, а в my2lib сидит его копия.
Здравствуйте, Pavel Dvorkin, Вы писали:
СМ>>может я не понимаю что предлагается, но я вижу, что код функций из библиотеки содержится один раз во всем процессе. Это так?
PD>Нет, именно не так.
PD>Еще раз.
PD>Создаем свою static library, включающую в себя исходную library. Статически включающую, то есть код исходной static library просто находится в нашей static library. Статически влинкован. PD>Создаем еще одну свою static library, включающую в себя исходную library тем же образом
PD>Итого имеем 2 свои static library и ничего больше пока. В первой library все имена функций начинаются на my1, во второй — на my2, все остальное одинаково.
PD>Создаем EXE — проект.
PD>Подключаю в него my1lib. Имею полное право. И буду из нее вызывать my1* функции. Они будут вызывать исходные функции, которые внутри my1lib. PD>Подключаю в него my2lib. Имею полное право. И буду из нее вызывать my2* функции. Они будут вызывать исходные функции, которые внутри my2lib.
PD>Исходную library в проект EXE не включаем вообще, не нужно.
PD>То есть в my1lib сидит код исходной lib, а в my2lib сидит его копия.
Дело в том, что lib (не импортная, для DLL) это всего лишь контейнер для объектных файлов (грубо говоря). Соответственно Вы будете иметь в каждой библиотеки копию объектников исходной библиотеки. При построении EXE будет выбор исходжнй объектников из первой подключенной библиотеки. Т.е. у Вас будет одна копия и всё что полагается для одной копии.
Здравствуйте, Сергей Мухин, Вы писали:
СМ>Дело в том, что lib (не импортная, для DLL) это всего лишь контейнер для объектных файлов (грубо говоря). Соответственно Вы будете иметь в каждой библиотеки копию объектников исходной библиотеки. При построении EXE будет выбор исходжнй объектников из первой подключенной библиотеки. Т.е. у Вас будет одна копия и всё что полагается для одной копии.
Хм... Может, я что-то не так понимаю.
Оставим эту задачу на минуту в стороне.
Допустим, я делаю свою static lib. Просто делаю.
Некая функция my_f из этой lib должна вызывать функцию other_f из сторонней библиотеки other.lib. Подключаю ее в проект для моей либы. Пишу свою функцию. Компилирую lib. В нее включается код other_f или нет ?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Допустим, я делаю свою static lib. Просто делаю.
PD>Некая функция my_f из этой lib должна вызывать функцию other_f из сторонней библиотеки other.lib. Подключаю ее в проект для моей либы. Пишу свою функцию. Компилирую lib. В нее включается код other_f или нет ?
Здравствуйте, Сергей Мухин, Вы писали:
PD>>Некая функция my_f из этой lib должна вызывать функцию other_f из сторонней библиотеки other.lib. Подключаю ее в проект для моей либы. Пишу свою функцию. Компилирую lib. В нее включается код other_f или нет ?
СМ>штатно нет.
Хм... Получается, что есть существенная разница между статической линковкой lib к EXE и lib к lib. В первом случае, несомненно, все нужные функции из lib копируются в EXE. Во втором, выходит, они не копируются, а та lib, из которйо они берутся, должна постоянно присутствовать при сборке будущего EXE...
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Хм... Получается, что есть существенная разница между статической линковкой lib к EXE и lib к lib. В первом случае, несомненно, все нужные функции из lib копируются в EXE. Во втором, выходит, они не копируются, а та lib, из которйо они берутся, должна постоянно присутствовать при сборке будущего EXE...
Еще раз. lib — это контейнер — набор .obj файлов. Можно руками взять из одной библ и добавить в другую библ, но когда она будет отображаться на .exe/.dll то будет выбрана одна копия .obj (все это приблизительно)
В вот exe/dll это не набор obj файлов.
при этом Lib строит утилита lib.exe, а exe/dll — link.exe (имена вымышленные, любые совпадения с реальными... )
И как после этого можно удивляться что они работают по разному?
PD>Если это так, то ты, конечно, прав, а я нет.
не часто встретишь на форумах такие признания
PD>Если это так...
хотя и с оговорками
ps
видимо я давно не писал на форумах, и имел неосторожность написать "ИМХО", т.к. уверен был всего на 99.9% Вот некоторые сразу пишут "глупость", а как по существу — проседают.
Здравствуйте, Сергей Мухин, Вы писали:
СМ>Еще раз. lib — это контейнер — набор .obj файлов. Можно руками взять из одной библ и добавить в другую библ, но когда она будет отображаться на .exe/.dll то будет выбрана одна копия .obj (все это приблизительно)
Это я понимаю, конечно, но почему-то полагал, что при сборке lib код, от которого она зависит, в нее "переползает". Видимо, повлиялаа на меня аналогия со сборкой EXE — там именно переползает.
Да, ты прав. Сейчас проверил. Для того, чтобы либу собрать, иметь либу, из которой ее функции вызываются, не требуется.
void g();
void f()
{
g();
}
и либа готова, хотя кода g вовсе и нет, и откуда он берется — пока что неизвестно.
СМ>В вот exe/dll это не набор obj файлов.
Конечно.
СМ>при этом Lib строит утилита lib.exe, а exe/dll — link.exe (имена вымышленные, любые совпадения с реальными... ) СМ>И как после этого можно удивляться что они работают по разному?
Вот это не аргумент ИМХО. Почему бы двум программам в чем-то не работать одинаково ?
СМ>не часто встретишь на форумах такие признания
Жаль. И все-таки : никаких принципиальных соображений, почему нельзя бы поместить в АП 2 копии одного и того же кода, я не вижу. То, что так не получилось — вопрос реализации, а не принципа.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Вот это не аргумент ИМХО. Почему бы двум программам в чем-то не работать одинаково ?
это программы одного производителя, если они бы работали одинаково, то и назывались одинаково. Но это конечно вторичный половой признак
PD>Жаль. И все-таки : никаких принципиальных соображений, почему нельзя бы поместить в АП 2 копии одного и того же кода, я не вижу. То, что так не получилось — вопрос реализации, а не принципа.
нет. Это вопрос принципа. Принципа построения выполнимого модуля в windows.
сразу говорю, что спорить не буду. Сошлюсь на авторитет, который сам генерит obj файлы и обрабатывает своим (почти) линкером obj и lib и строит exe/dll. т.е. на себя
СМ>это программы одного производителя, если они бы работали одинаково, то и назывались одинаково. Но это конечно вторичный половой признак
Очень вторичный
PD>>Жаль. И все-таки : никаких принципиальных соображений, почему нельзя бы поместить в АП 2 копии одного и того же кода, я не вижу. То, что так не получилось — вопрос реализации, а не принципа.
СМ>нет. Это вопрос принципа. Принципа построения выполнимого модуля в windows. СМ>сразу говорю, что спорить не буду. Сошлюсь на авторитет, который сам генерит obj файлы и обрабатывает своим (почти) линкером obj и lib и строит exe/dll. т.е. на себя
А не может ли этот авторитет все же объяснить, что в этой идее невозможного и почему это вопрос принципа ?
Давай проведем мысленный эксперимент.
Есть некая lib, в ней функции, все имена начинаются на a
Теперь каким-то чудом создалась другая lib, все абсолютно то же самое, но все функции начинаются на b
Не будешь же спорить, что можно подключить и первую, и вторую lib, и вызывать и атые и бэтые функции где угодно ? И что атые функции лежат в EXE, а бэтые тоже там лежат и с атыми не совпадают ?
А теперь чудом созданная b исчезла, мы опять только с a, но при разрешении внешних ссылок при сборке EXE некий чудо-линкер, встретив вызов атой функции, вставляет код исходной атой, а при вызове бэтой берет и вставляет еще раз код атой, но под именем бэтой. В итоге имеем 2 копии.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Что тут в принципе невозможного ?
Лежат под пальмой Маугли и Балу.
Маугли: Балу, вот Багира — она же кошка, ловкая, гибкая, она же может
залезть на пальму и достать кокос?
Балу: Нет, Маугли, не может!
Маугли: А тогда, Каа — он же удав, куда хочешь долезет, он сможет
достать кокос?
Балу: Нет, Маугли, он не сможет.
Маугли: Ну... Балу — тогда ты? Ты же самый умный, смелый — ты же сможешь
достать кокос?
Балу: И я не смогу...
Маугли: Ну я же — человек, царь природы, я смогу достать кокос?
Балу: Ты сможешь! Ты кого хочешь ДОСТАНЕШЬ!!!
---
С уважением,
Сергей Мухин
Re: Линкование либы в несколько потоков одного процесса.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ну ТС-то несложно. У него там аж 24 ядра. Интересно было бы посмотреть на картинку Task Manager с 24 ядрами — как он там их нарисовал
Ну 24 я показать не могу, а 32 легко Pzz>>Я не могу придумать никакого другого объяснения, почему привязка вычислительного потока к ядру может так повлиять на загрузку.
PD>Я тоже, но я сомневаюсь, в том, что это имеет место. Вообще-то игры с affinity mask обычно мало на что влияют при одном потоке. Когда-то проверял (в надежде получить именно ускорение за счет того, что сохраняется кеш при переключении) , получил 0).
Task Manager считает CPU Utilization не по ядрам, а суммирует ее по процессам + Hardware Interrupt. Поэтому даже визуально загрузка по ядрам отличается от общей загрузки.
В ARM linux — есть файлики, которые постоянно обновляются и показывают текущую загрузку проца и ядер...
Best regards,
Oleg Bekhter
Software Developer
Re[8]: Линкование либы в несколько потоков одного процесса.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Не думаю. Впрочем, проверить просто : Task manager — Perfomance и смотри на графики по ядрам.
Pzz>Кому просто, а кому для этого венду придется ставить
Pzz>Я не могу придумать никакого другого объяснения, почему привязка вычислительного потока к ядру может так повлиять на загрузку.
Могу подкинуть идею: Когда мы биндим "тяжелый" поток на какое-то конкретное ядро, оно просто перегревается. И проц начинает его либо троллить либо спидстепить.
Best regards,
Oleg Bekhter
Software Developer
Re[9]: Линкование либы в несколько потоков одного процесса.
Здравствуйте, Oleg Bekhter, Вы писали:
Pzz>>Я не могу придумать никакого другого объяснения, почему привязка вычислительного потока к ядру может так повлиять на загрузку. OB>Могу подкинуть идею: Когда мы биндим "тяжелый" поток на какое-то конкретное ядро, оно просто перегревается. И проц начинает его либо троллить либо спидстепить.
Это вряд ли. Нагрузка определяется по соотношению между временем работы и временем простоя процессора, а не по тому, сколько инструкций он успел перемолотить.
Если написать свой линкер, свой компилятор и свою windows, то это будет совсем другой мир (это форум С++Appl). Если у вас есть время на фантазии — вперед.
И даже если это сделать, то все равно не будет работать. Например либа открывает файл(ы) лог (или другой внешний ресурс с фикс именем). Или использует порт с номерм Х. А как обрабатывать коммунальные сегменты? их надо объеденять или замещать или отделять? так что все это какой то бред. Он родился от полного непонимания, что такое библиотека, и зачем то пытается обсуждать!!
плюс к этому решение не маштабируется.
PD>Впрочем, если я тебя достал — можешь не отвечать.
---
С уважением,
Сергей Мухин
Re[10]: Линкование либы в несколько потоков одного процесса.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, Oleg Bekhter, Вы писали:
Pzz>>>Я не могу придумать никакого другого объяснения, почему привязка вычислительного потока к ядру может так повлиять на загрузку. OB>>Могу подкинуть идею: Когда мы биндим "тяжелый" поток на какое-то конкретное ядро, оно просто перегревается. И проц начинает его либо троллить либо спидстепить.
Pzz>Это вряд ли. Нагрузка определяется по соотношению между временем работы и временем простоя процессора, а не по тому, сколько инструкций он успел перемолотить.
А! Пардон, невнимательно прочитал... Мне показалось, что меряешь время и оно растет при привязке к ядрам.
Кстати, а не мешало бы проверить, изменяется ли время выполнения с аффинити и без. Сразу и видно будет: если оно не меняется, значит TaskManager козлит. Если умельшилось — то все честно, назрузка на проц должна возрости. Если увеличилось — то SpeedStep или троллинг или не знаю что у AMD срабатывает...
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Вот это не аргумент ИМХО. Почему бы двум программам в чем-то не работать одинаково ?
Условный "lib.exe" это всего лишь архиватор obj файлов, то есть условно говоря можно вообще не делать статик либы, а таскать набор объектников в папке и подключать их все. Будет менее удобно, но эффект будет тот же самый. Не зря в gcc "lib.exe" называется ar.
PD>Жаль. И все-таки : никаких принципиальных соображений, почему нельзя бы поместить в АП 2 копии одного и того же кода, я не вижу. То, что так не получилось — вопрос реализации, а не принципа.
Не знаю как в VS, но в gcc, если реализовывать подобную схему, то линкер при сборке результирующего бинаря будет ругаться на дубликаты имен.
Здравствуйте, Сергей Мухин, Вы писали:
СМ>Если написать свой линкер,
Возможно, и потребуется
>свой компилятор и свою windows
Совсем не нужно для этой цели.
СМ>И даже если это сделать, то все равно не будет работать. Например либа открывает файл(ы) лог (или другой внешний ресурс с фикс именем). Или использует порт с номерм Х. А как обрабатывать коммунальные сегменты? их надо объеденять или замещать или отделять? так что все это какой то бред.
Какие-то бессвязные аргументы. Две разные библиотеки не могут открывать файлы каждая по отдельности ? Использовать порты ? И т.д. Могут, я полагаю. И без проблем. И если бы удалось представить (при линковке EXE) одну библиотеку как 2 разных, то все бы нормально получилось.
>Он родился от полного непонимания, что такое библиотека, и зачем то пытается обсуждать!!
Такие аргументы обычно используют, когда нет других, более серьезных.
СМ>плюс к этому решение не маштабируется.
Это верно.
Всего хорошего. Не думаю, что мне захочется еще с тобой дискутировать — в подобном стиле разговаривать неприятно.
W>условно говоря можно вообще не делать статик либы, а таскать набор объектников в папке и подключать их все. Будет менее удобно, но эффект будет тот же самый.
верно. но не совсем так, из либы может быть вообще ничего не взято, а объектник обязан быть включенным (правда потом может быть порезан при оптимизации, но проверку на дубликатность пройдет).
)
