Здравствуйте, 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[5]: Линкование либы в несколько потоков одного процесса.
W>>А что конкретно глупого? X>зачем рекомендовать создавать процессы?
Например затем же для чего Goggle Chrome создает по процессу на вкладку.
X>а вообще, сдается мне, ТС совершенно не понимает сабжа...
По мне так совершенно адекватный ответ. Бывают ситуации когда совершенно адекватно завернуть библиотеку не поддерживющую многопоточность в отдельный процесс.
Иногда это единственная разумная опция. Понятно что процесс имеет penalty fee в виде overhead всего и вся.
Если написать свой линкер, свой компилятор и свою windows, то это будет совсем другой мир (это форум С++Appl). Если у вас есть время на фантазии — вперед.
И даже если это сделать, то все равно не будет работать. Например либа открывает файл(ы) лог (или другой внешний ресурс с фикс именем). Или использует порт с номерм Х. А как обрабатывать коммунальные сегменты? их надо объеденять или замещать или отделять? так что все это какой то бред. Он родился от полного непонимания, что такое библиотека, и зачем то пытается обсуждать!!
плюс к этому решение не маштабируется.
PD>Впрочем, если я тебя достал — можешь не отвечать.
---
С уважением,
Сергей Мухин
Re: Линкование либы в несколько потоков одного процесса.
Здравствуйте, squid_etc, Вы писали:
_>мне же нужно в каждом потоке создать экземпляр либы и отдавать каждому экземпляру работу из своего потока.
_>Спасибо!
либа (как Вы это называете) лежит в памяти и принадлежит процессу, а не потоку. Поэтому, если нигде в ее описании не объявлено, что она thread-safe, то использовать ее в разных thread нельзя.
Запускайте процессы, там в каждом будет свой экземпляр либы.
---
С уважением,
Сергей Мухин
Re[3]: Линкование либы в несколько потоков одного процесса.
Здравствуйте, Сергей Мухин, Вы писали:
СМ>либа (как Вы это называете) лежит в памяти и принадлежит процессу, а не потоку. Поэтому, если нигде в ее описании не объявлено, что она thread-safe, то использовать ее в разных thread нельзя.
На первый взгляд, единственное место, где библиотека не thread-safe — это в hashes/chc/chc.c, там есть две статические переменные.
И то, эти переменные устанавливаются при инициализации модуля.
Хотя, возможно, я плохо смотрел.
Так что я не стал бы априори грешить на небезопасность. Возможно, что баг на клиентской стороне.
Тем более, замораживание. Странно это всё. Может, программа собрана с однопоточным рантаймом? (Безумное предположение, и его стоит исключить с самого начала).
Перекуём баги на фичи!
Re[2]: Линкование либы в несколько потоков одного процесса.
СМ>либа (как Вы это называете) лежит в памяти и принадлежит процессу, а не потоку. Поэтому, если нигде в ее описании не объявлено, что она thread-safe, то использовать ее в разных thread нельзя.
C таким же успехом thread-safe может означать глобальный мютекс. И тогда все манипуляции с либой будут безопасными в многопоточном окружении, но идти строго последовательно.
Здравствуйте, 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 будет выбор исходжнй объектников из первой подключенной библиотеки. Т.е. у Вас будет одна копия и всё что полагается для одной копии.
---
С уважением,
Сергей Мухин
Линкование либы в несколько потоков одного процесса.
Проблема в том, что когда в пуле 2 и больше потоков и потоки пытаются вызвать метод шифрования — то один из потоков замерзает — мы не возвращаемся из метода по шифрованию — либа лочит наш поток.
либа собрана статически и статически линкуется к нашему приложению. Ставить лок на использование либы в конкретном месте — не вариант, т.к. шифрование будет ограничиваться линейным шифрованием в либе — которое так и будет проходить в один поток.
мне же нужно в каждом потоке создать экземпляр либы и отдавать каждому экземпляру работу из своего потока.
предложите идеи по реализации? примеры кода?
Спасибо!
07.12.13 20:48: Перенесено модератором из 'C/C++' — Кодт
Re: Линкование либы в несколько потоков одного процесса.
делите исходные данные на порции, чтоб каждому потоку отдавалась приблизительно равная порция — и не будет заморозок.
но тут важно, чтоб либа не имела общие изменяемые данные.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Re[2]: Линкование либы в несколько потоков одного процесса.
Здравствуйте, Сергей Мухин, Вы писали:
СМ>либа (как Вы это называете) лежит в памяти и принадлежит процессу, а не потоку. Поэтому, если нигде в ее описании не объявлено, что она thread-safe, то использовать ее в разных thread нельзя.
СМ>Запускайте процессы, там в каждом будет свой экземпляр либы.
Спасибо за конструктив.
я порылся немного в логировании пула потоков — и уже начал грешить на него. по 1000-5000 запросов проходит нормально. а застопоряется сам поток — толи ему нормально не отдаётся команда на работу, толи еще что.
перепишу пул по-человечески(сам) и дам знать что вышло.
Re[3]: Линкование либы в несколько потоков одного процесса.
Здравствуйте, squid_etc, Вы писали:
_>перепишу пул по-человечески(сам) и дам знать что вышло.
не нужно ничего переписывать. просто прочтите то, что я написал выше.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Re: Линкование либы в несколько потоков одного процесса.
Здравствуйте, squid_etc, Вы писали:
_>предложите идеи по реализации? примеры кода?
Я очень подозреваю, что бага не в либе, а у вас. LibTomCrypt — это набор криптопримитивов, т.е., вычислительных функций. Я вообще не понимаю, зачем ей внутри себя что-либо лочить.
Если есть уверенность, что программа помирает именно внутри LibTomCrypt'а, попробуйте OpenSSL. За ним вроде не замечены никакие придури, связанные с многопоточностью.
OpenSSL состоит из двух частей — библиотеки криптопримитивов и библиотеки, реализующей сетевой протокол SSL/TLS. Первая от второй не зависит, и, я уверен, содержит все, что вам надо.
Re: Линкование либы в несколько потоков одного процесса.
Здравствуйте, squid_etc, Вы писали:
_>предложите идеи по реализации? примеры кода?
И еще. Я бы подумал о том, чтобы поназапускать потоков руками, по числу доступный ядер, и привязать каждый к своему ядру — чтобы они не прыгали между ядрами, с потерей содержимогп кэша при каждом прыжке.
Re[3]: Линкование либы в несколько потоков одного процесса.
Здравствуйте, Pzz, Вы писали:
Pzz>Если есть уверенность, что программа помирает именно внутри LibTomCrypt'а, попробуйте OpenSSL. За ним вроде не замечены никакие придури, связанные с многопоточностью.
Спасибо за глубокое понимание проблемы. с OpenSSL уже работал, но в нем нет поддержки ЕСС шифрования(именно его я использую в томкрипте)
Re[3]: Линкование либы в несколько потоков одного процесса.
Здравствуйте, Pzz, Вы писали:
Pzz>И еще. Я бы подумал о том, чтобы поназапускать потоков руками, по числу доступный ядер, и привязать каждый к своему ядру — чтобы они не прыгали между ядрами, с потерей содержимогп кэша при каждом прыжке.
и еще раз спасибо за участие.
я запускаю как раз то количество потоков, для шифрования, сколько и коров на машине.
и я экспериментировал с привязкой потока к конкретному кору: при этом(при жёсткой привязке потока к кору) увеличивается загрузка проца. если потоки будут настроены по умолчанию(могут выполнятся на всех корах — реально работу делает тот кор, который свободен) — то загрузка проца меньше в разы, а скорость шифрации таже. так что лучше не привязываться — как и говорится во всех мануалах по привязке потоков к корам.
спс
Re[3]: Линкование либы в несколько потоков одного процесса.
Здравствуйте, squid_etc, Вы писали:
Pzz>>Если есть уверенность, что программа помирает именно внутри LibTomCrypt'а, попробуйте OpenSSL. За ним вроде не замечены никакие придури, связанные с многопоточностью.
_>Спасибо за глубокое понимание проблемы. с OpenSSL уже работал, но в нем нет поддержки ЕСС шифрования(именно его я использую в томкрипте)
Здравствуйте, squid_etc, Вы писали:
_>и я экспериментировал с привязкой потока к конкретному кору: при этом(при жёсткой привязке потока к кору) увеличивается загрузка проца. если потоки будут настроены по умолчанию(могут выполнятся на всех корах — реально работу делает тот кор, который свободен) — то загрузка проца меньше в разы, а скорость шифрации таже. так что лучше не привязываться — как и говорится во всех мануалах по привязке потоков к корам.
Непонятно, с чего бы. Казалось бы, если процессор загружен, то он что-то делает, и результаты этой деятельности должны быть как-то видны.
Может, если потоки не привязаны к ядру, то измерялка загрузки глючит?
Re[6]: Линкование либы в несколько потоков одного процесса.
Здравствуйте, c-smile, Вы писали:
CS>Например затем же для чего Goggle Chrome создает по процессу на вкладку.
оно это делает не столько для того чтоб увеличить увеличить озывчивость браузера, сколько ради надежности.
CS>По мне так совершенно адекватный ответ. Бывают ситуации когда совершенно адекватно завернуть библиотеку не поддерживющую многопоточность в отдельный процесс.
приведите пример такой ситуации, пожалуйста.
и еще, пожалуйста, приведите пример того, почему какая-то библиотека не поддерживает многопоточность, и что означает "не поддерживает многопоточность".
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Re[7]: Линкование либы в несколько потоков одного процесса.
Здравствуйте, niXman, Вы писали:
X>Здравствуйте, c-smile, Вы писали:
CS>>Например затем же для чего Goggle Chrome создает по процессу на вкладку. X>оно это делает не столько для того чтоб увеличить увеличить озывчивость браузера, сколько ради надежности.
так мне кажется мы тоже хотим что бы программа работала надежно и не повисала?
CS>>По мне так совершенно адекватный ответ. Бывают ситуации когда совершенно адекватно завернуть библиотеку не поддерживющую многопоточность в отдельный процесс. X>приведите пример такой ситуации, пожалуйста.
X>и что означает "не поддерживает многопоточность".
если Вы этого не знаете, зачем отвечаете в этой теме?
---
С уважением,
Сергей Мухин
Re[8]: Линкование либы в несколько потоков одного процесса.
Здравствуйте, Сергей Мухин, Вы писали:
СМ>так мне кажется мы тоже хотим что бы программа работала надежно и не повисала?
так вы считаете, что потоки только способствуют ненадежности и подвисанию?
да, действительно, для чего эти потоки придумали? — процессы рулят! </sarcastic>
СМ>если Вы этого не знаете, зачем отвечаете в этой теме?
глупый вброс.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Re[2]: Линкование либы в несколько потоков одного процесса.
Здравствуйте, Pzz, Вы писали:
Pzz>Если есть уверенность, что программа помирает именно внутри LibTomCrypt'а, попробуйте OpenSSL. За ним вроде не замечены никакие придури, связанные с многопоточностью.
Здравствуйте, niXman, Вы писали:
X>и еще, пожалуйста, приведите пример того, почему какая-то библиотека не поддерживает многопоточность, и что означает "не поддерживает многопоточность".
не сорьтесь!
пример могу привести я, хотя с таким в реале не сталкивался: либа может не поддерживать многопоточность, когда несколько потоков вызывают один и тот же метод либы — а внутри этого метода используются общие данные не защищенные критической секцией... вуаля — студенческий баг
Re[4]: Линкование либы в несколько потоков одного процесса.
Здравствуйте, Pzz, Вы писали: Pzz>Непонятно, с чего бы. Казалось бы, если процессор загружен, то он что-то делает, и результаты этой деятельности должны быть как-то видны.
Pzz>Может, если потоки не привязаны к ядру, то измерялка загрузки глючит?
"измерялка" == таск менеджер )))
если отвязать потоки от ядер загрузка 13-15%, если привязать 95-100% (это один процесс ест столько)
Re[3]: Линкование либы в несколько потоков одного процесса.
Здравствуйте, Кодт, Вы писали:
К>Тем более, замораживание. Странно это всё. Может, программа собрана с однопоточным рантаймом? (Безумное предположение, и его стоит исключить с самого начала).
если вы о "Multi-Threaded DLL" — то в эти настройки я не лез — и они не менялись.
я грешу на корявенький рукодельный(не мной) пул потоков. -руки еще не дошли поправить
Re[5]: Линкование либы в несколько потоков одного процесса.
Здравствуйте, squid_etc, Вы писали:
_>"измерялка" == таск менеджер ))) _>если отвязать потоки от ядер загрузка 13-15%, если привязать 95-100% (это один процесс ест столько)
Возможно, таск менеджер измеряет загрузку каждого из ядер, а потом берет максимум. Тогда если какой-то поток крутится в цикле на одном ядре, загрузка будет около 100%, а если прыгает по ядрам, то около 100%/N, где N — количество ядер. Разумеется, о реальной загрузке системы такая цифра мало чего говорит.
Re[9]: Линкование либы в несколько потоков одного процесса.
Здравствуйте, niXman, Вы писали:
X>Здравствуйте, Сергей Мухин, Вы писали:
СМ>>так мне кажется мы тоже хотим что бы программа работала надежно и не повисала? X>так вы считаете, что потоки только способствуют ненадежности и подвисанию?
А что, уже отменили гонки и дедлоки?
Как-то я пропустил видимо...
Re[6]: Линкование либы в несколько потоков одного процесса.
Здравствуйте, Pzz, Вы писали:
Pzz>Возможно, таск менеджер измеряет загрузку каждого из ядер, а потом берет максимум. Тогда если какой-то поток крутится в цикле на одном ядре, загрузка будет около 100%, а если прыгает по ядрам, то около 100%/N, где N — количество ядер.
Не думаю. Впрочем, проверить просто : Task manager — Perfomance и смотри на графики по ядрам.
Здравствуйте, Сергей Мухин, Вы писали:
СМ>либа (как Вы это называете) лежит в памяти и принадлежит процессу, а не потоку. Поэтому, если нигде в ее описании не объявлено, что она thread-safe, то использовать ее в разных thread нельзя.
Интересно, а если так ?
Делаем свою static library, экспонирующую те же функции, что и исходная, только с неким префиксом в имени. Функции просто вызывают соответствующие функции исходной library
Например, в исходной library
int sum(int x, int y)
А мы делаем
int my1sum(int z, int y)
{
return sum(x,y);
}
Делаем еще одну свою static library, экспонирующую те же функции, что и исходная, только с неким другим префиксом в имени. (в ней будет my2sum)
Итого имеем две статические library, а к ним статически прилинкованы 2 копии исходной library.
Теперь делаем EXE, к нему линкуем наши обе библиотеки. В своей программе вызываем в одном потоке my1sum, а в другом my2sum.
По идее вызов mysum1 пойдет в первую копию, а mysum2 — во вторую. А мешать они друг другу не должны, так как можно считать, что это две разные библиотеки. И thread-safe не должно быть существенным, так как это разные библиотеки.
Я нигде не ошибся ?
With best regards
Pavel Dvorkin
Re[7]: Линкование либы в несколько потоков одного процесса.
Здравствуйте, Pzz, Вы писали:
Pzz>Кому просто, а кому для этого венду придется ставить
Ну ТС-то несложно. У него там аж 24 ядра. Интересно было бы посмотреть на картинку Task Manager с 24 ядрами — как он там их нарисовал
Pzz>Я не могу придумать никакого другого объяснения, почему привязка вычислительного потока к ядру может так повлиять на загрузку.
Я тоже, но я сомневаюсь, в том, что это имеет место. Вообще-то игры с affinity mask обычно мало на что влияют при одном потоке. Когда-то проверял (в надежде получить именно ускорение за счет того, что сохраняется кеш при переключении) , получил 0).
With best regards
Pavel Dvorkin
Re[9]: Линкование либы в несколько потоков одного процесса.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Я тоже, но я сомневаюсь, в том, что это имеет место. Вообще-то игры с affinity mask обычно мало на что влияют при одном потоке. Когда-то проверял (в надежде получить именно ускорение за счет того, что сохраняется кеш при переключении) , получил 0).
Я думаю, при умеренной нагрузке системе хватает ума не дергать считающий поток по ядрам. По крайней мере, делать это не слишком часто. А вот при большой нагрузке у нее уже может не остаться выбора.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Сергей Мухин, Вы писали:
СМ>>либа (как Вы это называете) лежит в памяти и принадлежит процессу, а не потоку. Поэтому, если нигде в ее описании не объявлено, что она thread-safe, то использовать ее в разных thread нельзя.
PD>Интересно, а если так ?
PD>Делаем свою static library, экспонирующую те же функции, что и исходная, только с неким префиксом в имени. Функции просто вызывают соответствующие функции исходной library
PD>Например, в исходной library
PD>Делаем еще одну свою static library, экспонирующую те же функции, что и исходная, только с неким другим префиксом в имени. (в ней будет my2sum)
PD>Итого имеем две статические library, а к ним статически прилинкованы 2 копии исходной library.
PD>Теперь делаем EXE, к нему линкуем наши обе библиотеки. В своей программе вызываем в одном потоке my1sum, а в другом my2sum.
PD>По идее вызов mysum1 пойдет в первую копию, а mysum2 — во вторую. А мешать они друг другу не должны, так как можно считать, что это две разные библиотеки. И thread-safe не должно быть существенным, так как это разные библиотеки.
PD>Я нигде не ошибся ?
Если в будет вызываться старая либа внутри, то от проблемы не ушли. Если будет полная копия библиотеки, то у нас только два thread! и как вызывать? Все время проверять н омер thread?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Сергей Мухин, Вы писали:
СМ>>Если в будет вызываться старая либа внутри, то от проблемы не ушли.
PD>Нет, я же говорил, статически линковать старую либу. Ее больше нет в EXE-проекте, она скрыта внутри wrapper-либы.
что такое "EXE проект" в терминах выполнимых файлов? Есть Exe и DLL где библиотека? А где бы ни была, либо одна копия, либо несколько в разных выполнимых модулях.
Соответственно ничего не поменялось.
>>Если будет полная копия библиотеки, то у нас только два thread! и как вызывать? Все время проверять н омер thread?
PD>Не обязательно. Взять в самом начале указатели на функции и в tls их.
Ну и как? там мб 1000 ф-ий и их все придется описать заново и проинициализировать указатели в tls ? Но как мы будем инициализировать указатели? т.е. не то.
PD>Я не говорю, что решение идеально. Просто прочитал твое сообщение и подумал — нельзя ли что-то придумать. Задача показалась интересной. Думал минут 10
PD>>Нет, я же говорил, статически линковать старую либу. Ее больше нет в EXE-проекте, она скрыта внутри wrapper-либы.
СМ>что такое "EXE проект" в терминах выполнимых файлов?
EXE-проект — это проект VS, в котором собирается EXE.
>Есть Exe и DLL где библиотека?
Ни о каких DLL и речи тут не было. Речь идет о статической библиотеке.
>А где бы ни была, либо одна копия, либо несколько в разных выполнимых модулях.
И модуль тут один — EXE.
СМ>Соответственно ничего не поменялось.
Подумай еще раз.
>>>Если будет полная копия библиотеки, то у нас только два thread! и как вызывать? Все время проверять н омер thread?
PD>>Не обязательно. Взять в самом начале указатели на функции и в tls их.
СМ>Ну и как? там мб 1000 ф-ий и их все придется описать заново и проинициализировать указатели в tls ? Но как мы будем инициализировать указатели? т.е. не то.
Элементарно. Создадим потоки и в самом начале функции потока проинициализируем. Как и все tls-переменные.
PD>>Я не говорю, что решение идеально. Просто прочитал твое сообщение и подумал — нельзя ли что-то придумать. Задача показалась интересной. Думал минут 10
СМ>имхо это совсем не решение.
Твое право так считать, но хотелось бы серьезных аргументов.
СМ>>что такое "EXE проект" в терминах выполнимых файлов?
PD>EXE-проект — это проект VS, в котором собирается EXE.
т.е. никакого отношение к выполнению не имеет. имеет отношение к построению. И тогда нет там либы или есть — монопенициально.
PD>Подумай еще раз.
что тут думать — трясти надо
PD>Элементарно. Создадим потоки и в самом начале функции потока проинициализируем. Как и все tls-переменные.
PD>>>Я не говорю, что решение идеально. Просто прочитал твое сообщение и подумал — нельзя ли что-то придумать. Задача показалась интересной. Думал минут 10
СМ>>имхо это совсем не решение.
PD>Твое право так считать, но хотелось бы серьезных аргументов.
может я не понимаю что предлагается, но я вижу, что код функций из библиотеки содержится один раз во всем процессе. Это так?
Если да, то какие обертки не делай, код будет выполняться один.
Допустим, что в библиотеке одна ф-я ZZZ и её нельзя вызывать из разных потоков. Какие обертки над ней делай, её придётся вызвать! Соответственно или надо синхронихировать её вызов, и тогда о multithread забываем или приехали!
Если код дублируется, то непонятен механизм дублирования (если нет исходных текстов). И все равно могут быть проблемы, но уже из-за того, что библиотеки часто не приспособлены, иметь два кода в одном адресном пространстве.
Здравствуйте, Сергей Мухин, Вы писали:
СМ>может я не понимаю что предлагается, но я вижу, что код функций из библиотеки содержится один раз во всем процессе. Это так?
Нет, именно не так.
Еще раз.
Создаем свою 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 сидит его копия.
Здравствуйте, Сергей Мухин, Вы писали:
СМ>Дело в том, что 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: Линкование либы в несколько потоков одного процесса.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Не думаю. Впрочем, проверить просто : Task manager — Perfomance и смотри на графики по ядрам.
Pzz>Кому просто, а кому для этого венду придется ставить
Pzz>Я не могу придумать никакого другого объяснения, почему привязка вычислительного потока к ядру может так повлиять на загрузку.
Могу подкинуть идею: Когда мы биндим "тяжелый" поток на какое-то конкретное ядро, оно просто перегревается. И проц начинает его либо троллить либо спидстепить.
Best regards,
Oleg Bekhter
Software Developer
Re[9]: Линкование либы в несколько потоков одного процесса.
Здравствуйте, Oleg Bekhter, Вы писали:
Pzz>>Я не могу придумать никакого другого объяснения, почему привязка вычислительного потока к ядру может так повлиять на загрузку. OB>Могу подкинуть идею: Когда мы биндим "тяжелый" поток на какое-то конкретное ядро, оно просто перегревается. И проц начинает его либо троллить либо спидстепить.
Это вряд ли. Нагрузка определяется по соотношению между временем работы и временем простоя процессора, а не по тому, сколько инструкций он успел перемолотить.
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>условно говоря можно вообще не делать статик либы, а таскать набор объектников в папке и подключать их все. Будет менее удобно, но эффект будет тот же самый.
верно. но не совсем так, из либы может быть вообще ничего не взято, а объектник обязан быть включенным (правда потом может быть порезан при оптимизации, но проверку на дубликатность пройдет).
Перекуём баги на фичи!
