Здравствуйте, ELazin, Вы писали:
EL>biicode недавно умер, nuget — windows only, CPM не знаю что такое. IMO все это не нужно если есть нормальный пакетный менеджер и какое-нибудь общее место для заголовочных файлов и библиотек (как /usr/include в linux). Управление зависимостями и сборка это разные вещи, не стоит все смешивать.
А у тебя не бывает разных версий библиотеки на разных проектах? Пакетные менеджеры позволяют такое?
Здравствуйте, ELazin, Вы писали:
EL>Что не так с этими *make кроме названия?
Выше уже несколько раз об этом писали.
EL>IMO все это не нужно если есть нормальный пакетный менеджер
и если есть добрый дядя, подготовивший подходящий для конкретной системы пакет EL>какое-нибудь общее место для заголовочных файлов и библиотек (как /usr/include в linux)
*тут шутка про размазывание ровным слоем*
EL>Управление зависимостями и сборка это разные вещи, не стоит все смешивать.
Вообще-то второе не имеет смысла без первого.
Более того, в этом плане у c/c++ имеется фундаментальная проблема:
В самом языке средств для полного описания прямых и косвенные зависимостей нет, а жесткая привязка к файловой системе есть. Информация о зависимостях (как минимум об их части) и о привязке в файловой системе необходима для осуществления сборки и поэтому присутствует в том или ином виде в сборочных скриптах, но извлечение ее из феерического винегрета этих скриптов обычно крайне затруднено. А перед тем, как приступать к сборке, эту информацию приходится собирать и готовить нужные зависимости. Причем практически всегда вручную. То есть у нас втройне убогая ситуация: одновременно и частичное дублирование информации, и неполнота информации, и необходимость ручных манипуляций.
По факту сборочные скрипты в их нынешнем виде(ах) — это "неуправление" зависимостями.
При наличии явного управления зависимостями роль сборочных скриптов заметно упрощается, вызвать исполняемый файл с несколькими аргументами — это дело техники.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
EL>>Что не так с этими *make кроме названия? VTT>Выше уже несколько раз об этом писали.
Ничего дельного там не написано об этом, ты просто уходишь от ответа на прямой вопрос. Вот что конкретно не так с CMake?
EL>>IMO все это не нужно если есть нормальный пакетный менеджер VTT>и если есть добрый дядя, подготовивший подходящий для конкретной системы пакет
Это же можно сказать про репозитории вроде maven-а. Если дядя подготовил то оно там есть, если не подготовил, то нет.
EL>>Управление зависимостями и сборка это разные вещи, не стоит все смешивать. VTT>Вообще-то второе не имеет смысла без первого. VTT>Более того, в этом плане у c/c++ имеется фундаментальная проблема:
Вообще, система управления зависимостями может быть одна для всех (system wide package manager), а не для каждого языка свой отдельный, как сейчас. Вот представь что у тебя есть питоновский пакет, который зависит от конкретной версии какого-нибудь модуля и еще один пакет, который зависит от другой версии того же модуля. Ты не сможешь установить две версии модуля сразу через pip, только используя virtualenv и два разных окружения, что не вариант, если пакеты должны использоваться совместно. Современный пакетный менеджер pip, лол.
В С++ я могу собрать что-угодно как угодно, немножко попрелюбодействовав с билд-скриптами.
VTT>В самом языке средств для полного описания прямых и косвенные зависимостей нет, а жесткая привязка к файловой системе есть. Информация о зависимостях (как минимум об их части) и о привязке в файловой системе необходима для осуществления сборки и поэтому присутствует в том или ином виде в сборочных скриптах, но извлечение ее из феерического винегрета этих скриптов обычно крайне затруднено. А перед тем, как приступать к сборке, эту информацию приходится собирать и готовить нужные зависимости. Причем практически всегда вручную. То есть у нас втройне убогая ситуация: одновременно и частичное дублирование информации, и неполнота информации, и необходимость ручных манипуляций.
Если библиотека установлена как положено, то никакой привязки к файловой системе как-бы и нет, оно все всегда сразу находится. CMake тоже не заставляет тебя напрямую работать с именами файлов, находишь зависимость через FIND_PACKAGE и потом просто используешь соответствующие переменные. Я ни разу не делал то, о чем ты тут пишешь "практически всегда вручную" вручную. Оно как-то само получалось
VTT>По факту сборочные скрипты в их нынешнем виде(ах) — это "неуправление" зависимостями.
Вот наверное поэтому они и называются "сборочными скриптами".
VTT>При наличии явного управления зависимостями роль сборочных скриптов заметно упрощается, вызвать исполняемый файл с несколькими аргументами — это дело техники.
Вот о чем я и говорю. Вот как это в винде делается — не знаю, может там все это имеет место быть.
Здравствуйте, ELazin, Вы писали:
EL>Вообще, система управления зависимостями может быть одна для всех (system wide package manager), а не для каждого языка свой отдельный, как сейчас. Вот представь что у тебя есть питоновский пакет, который зависит от конкретной версии какого-нибудь модуля и еще один пакет, который зависит от другой версии того же модуля. Ты не сможешь установить две версии модуля сразу через pip, только используя virtualenv и два разных окружения, что не вариант, если пакеты должны использоваться совместно. Современный пакетный менеджер pip, лол.
Это ж ограничение самого питона. Как ты в одном месте будешь использовать одну версию модуля, в другом (в пределах одной программы) — другую? Разве что дать им разные названия, но пользователи на такое могут быть не рассчитаны.
EL>В С++ я могу собрать что-угодно как угодно, немножко попрелюбодействовав с билд-скриптами.
Здравствуйте, StanislavK, Вы писали:
SK>Интригующий заголовок, но вопросто не в измерении длинны сами знаете чего Прошу на касаться вопросов производительности.
SK>Вопрос в следующем, если бы вам пришлось начать разрабатывать большую серверную, многопоточную, многокомпонентную, распределенную систему, то какой язык бы вы выбрали?
...
для C++ со сложной структурой проекта и множеством подпроектов нужна быстрая распределенная система сборки на каждого разработчика. Если послушать местных "берем cmake, а там дальше разберемся", то лучше сразу не брать С++. Это как лакмусовая бумажка, если даже сборку проекта не могут сделать "многопоточную, многокомпонентную, распределенную ...", то проект посложнее и подавно.
Вообще с С++ главный риск это люди и опыт людей. По скольку никакой специфики проекта не известно, то можно предположить что железки и вендоры вас не ограничивают и на более простом инструменте напишете функционал быстрее, отладите быстрее, потюните быстрее. В общем оставьте с++ в покое =) разве что для чегото ресурсоемкого/низкоуровневого сделаете/возьмете (полу-)готовое, отдельный модуль.
Здравствуйте, Nuzhny, Вы писали:
N>Например неплохой прирост в производительности давал следующий трюк: получаемые от ip-камер кадры для декодирования лучше записывать не просто в буфер, а делать в начале буфера небольшой случайного размера poadding, чтобы предсказатель переходов в процессоре вовремя сбрасывал кэш.
Стесняюсь спросить, а зачем для производительности "вовремя сбрасывать кэш" и какое к этому отношение имеет предсказатель переходов?
EL>В С++ я могу собрать что-угодно как угодно, немножко попрелюбодействовав с билд-скриптами. EL>Если библиотека установлена как положено, то никакой привязки к файловой системе как-бы и нет, оно все всегда сразу находится. CMake тоже не заставляет тебя напрямую работать с именами файлов, находишь зависимость через FIND_PACKAGE и потом просто используешь соответствующие переменные. Я ни разу не делал то, о чем ты тут пишешь "практически всегда вручную" вручную. Оно как-то само получалось
Ну-ну, вот так в каждой библиотеке у разработчиков свое представление о том, как положено (и далеко не все удосуживаются поделиться этим представлением с другими). Когда скачущий в агонии по диску билд-скрипт отдает концы непонятно где и почему, то начинается многочасовое веселье с разгадыванием ребусов. Но даже когда он отрабатывает, то все равно стоит проверить, а то ли он намутил. Другими словами, нужно владеть ситуацией, знать что для чего задействуется и откуда именно должно браться. А выуживать эту информацию практически всегда приходится вручную (так или иначе).
EL>>>IMO все это не нужно если есть нормальный пакетный менеджер EL>Вообще, система управления зависимостями может быть одна для всех (system wide package manager), а не для каждого языка свой отдельный, как сейчас.
Для одно-то языка никак не могут нормально сделать, а вы хотите сразу для всех. Да еще system wide.
EL>Вот как это в винде делается — не знаю, может там все это имеет место быть.
У вас какая-то нездоровая неприязнь к ОС Windows. Так и до столменизма можно докатиться.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Здравствуйте, Patalog, Вы писали:
P>Стесняюсь спросить, а зачем для производительности "вовремя сбрасывать кэш" и какое к этому отношение имеет предсказатель переходов?
Во времена Пентиумов 4 так работало: предсказатель видит, что адрес начала буфера "какой-то не такой" и вовремя реагировал на приход буфера с новым кадром. Профайлер показывал уменьшение "cache miss rate" или чего-то похожего. Скорость работы увеличивалась. Данный трюк был описан где-то у Агнера Фога.
CMake генерирует проекты autotools под Линуксом и, вообще-то, он ужас-ужас-ужас, но обычно это совсем незаметно!
Первое предложение, а уже булшит, CMake не умеет генерировать "проекты autotools" и никогда не умел, лол.
VTT>Ну-ну, вот так в каждой библиотеке у разработчиков свое представление о том, как положено (и далеко не все удосуживаются поделиться этим представлением с другими). Когда скачущий в агонии по диску билд-скрипт отдает концы непонятно где и почему, то начинается многочасовое веселье с разгадыванием ребусов. Но даже когда он отрабатывает, то все равно стоит проверить, а то ли он намутил. Другими словами, нужно владеть ситуацией, знать что для чего задействуется и откуда именно должно браться. А выуживать эту информацию практически всегда приходится вручную (так или иначе).
Ты излишне драматизируешь КМК, я такое ни разу не видел. Даже гребаный boost собирается как раз плюнуть.
EL>>>>IMO все это не нужно если есть нормальный пакетный менеджер EL>>Вообще, система управления зависимостями может быть одна для всех (system wide package manager), а не для каждого языка свой отдельный, как сейчас. VTT>Для одно-то языка никак не могут нормально сделать, а вы хотите сразу для всех. Да еще system wide.
Я имел ввиду пакетные менеджеры (что очевидно из более ранних комментариев). Вот скажем питоновский пакет я могу установить с помощью pip, а могу с помощью apt, а могу вообще через easy_install. Для питона наличие встроенных средств управления зависимостями оправдано тем, что он может использоваться там, где нет вообще никакого пакетного менеджера (windows) и все эти инструменты входят в дистрибутив питона и есть централизованный репозиторий, но вот для С и С++, лично я всегда предпочту apt всяким там biicode-ам, просто потому что многие зависимости нужно устанавливать и на клиентской машине, а это проще всего делать средствами системы (в отличии от питона, где иногда проще ставить средствами самого питона), packaging проще становится и все такое. Если же у меня есть зависимость от какой-нибудь библиотеки, которую я беру в сторонней системе управления зависимостями, то мне нужно будет вручную нарулить для нее пакет и поставлять его клиенту, может даже поднять свой репозиторий пакетов. Это лишний геморрой, так никто не делает (AFAIK).
EL>>Вот как это в винде делается — не знаю, может там все это имеет место быть. VTT>У вас какая-то нездоровая неприязнь к ОС Windows. Так и до столменизма можно докатиться.
Wishful thinking. Я ничего подобного не говорил, просто последний раз собирал что-то под windows больше пяти лет назад.
Здравствуйте, ELazin, Вы писали:
EL>CMake не умеет генерировать "проекты autotools" и никогда не умел, лол.
Возможно, пусть тогда делает make проекты, это не столь важно.
EL>Даже гребаный boost собирается как раз плюнуть.
Почему гребанный?
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Здравствуйте, VTT, Вы писали:
EL>>CMake не умеет генерировать "проекты autotools" и никогда не умел, лол. VTT>Возможно, пусть тогда делает make проекты, это не столь важно.
В действительности важно, т.к. эта генерация может быть скрыта под капотом и плюсовая IDE будер работать как бы с проектом на CMake безо всякой промежуточной генерации.
Да и вообще, CMake можно достаточно просто использовать для кросскомпиляции проектов подо всякие embedded платформы. Скажем, под sparc.
VTT>Возможно, пусть тогда делает make проекты, это не столь важно.
Ну а что в этом плохого? Я знаю как минимум 3 разные плюсовые IDE, которые используют CMake для сборки, генерируя make-файлы. И знаешь, очень удобно. Работать можно в CLion и потом тот же самый CMake проект, без модификаций, собирать на CI сервере через скрипт, тесты прогонять и даже пакеты собирать.
VTT>Почему гребанный?
Там своя система сборки и нужно сначала собрать bjam, а потом с его помощью уже собрать буст. Не самый приятный опыт.
Здравствуйте, ELazin, Вы писали:
VTT>>Почему гребанный? EL>Там своя система сборки и нужно сначала собрать bjam, а потом с его помощью уже собрать буст. Не самый приятный опыт.
Справедливости ради, в последних версиях (примерно как пару лет) появился скрипт bootstrap с которым все гораздо проще:
cd boost_some_version && ./bootstrap.sh && ./b2 <some_options> install
что впрочем не очень сильно отличается от старых версий, где надо было делать
Учитывая что ОС, базы, компиляторы, все самые высоконагруженные распределенные системы так или иначе написаны на C++ говорить о том java лучше как минимум смешно.
---SK>1. Развитая система билда (maven, gradle)
пару раз в неделю у нас падает билд от нарушений зависмостей (большая международная компаний с java ентерпрайс сервером).
Очень редко было в предидушей компании (большая международная компаний с C++ ентерпрайс сервером).
--SK>2. Реально много библиотек и фреймворков.
В С++ тоже вагон и тележка
В конце концов C++ живет на куда большем числе устройств чем Java.
SK>3. Хорошая совместимость с БД, мессаджингом и т.д. Драйвера есть для всех известных мне продуктов.
И как правило в одном количестве. Больше года ждали JDBC драйвер для MSSQL с поддержкой мирроринга.
А у C++: АДО, ODBC, OLEDB, .NET, ................
--можно в пол-тычка сделать rest-сервис
пункт 4 вообше мало понятен. что с чем интегрируется. Особенно с CUDA.
---SK>5.
Есть еше более замечательная система Visual Studio, где проекты в сотни тышь файлов прекрасно живут.
И каждый раз матерюсь перегружая Eclipse который течет и виснет на больших проектах и с которого уже не слезть.
---SK>6. У меня лично есть опыт как это все делается на Java.
У меня и там и там.
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, Patalog, Вы писали:
P>>Стесняюсь спросить, а зачем для производительности "вовремя сбрасывать кэш" и какое к этому отношение имеет предсказатель переходов?
N>Во времена Пентиумов 4 так работало: предсказатель видит, что адрес начала буфера "какой-то не такой" и вовремя реагировал на приход буфера с новым кадром. Профайлер показывал уменьшение "cache miss rate" или чего-то похожего. Скорость работы увеличивалась. Данный трюк был описан где-то у Агнера Фога.
А какой "предсказатель" имеется в виду? Branch predictor? Но при чем здесь тогда cache miss?
Здравствуйте, andyag, Вы писали:
A>.so, написанно на C++ по-моему можно использовать из абсолютно любого ЯП — начиная со всяких Java и .NET, заканчивая Python, Ruby, Node и наверное какими-то ещё. A>REST сервис — нет, это уже будет подвиг. Там где у Java программиста в резюме мелкими буквами написано "а ещё CXF", у C++ программиста будет на полстраницы "жирным таймз нью роман четырнадцатым" название библиотеки, с которой он про-бался месяц, но таки собрал её и заставил отдавать JSON. Без кеширования, без аутентификации, без сессий, но хоть как-то. Потому что это неподъёмная задача.
Враки. Делал такое лет 6-8 назад. Без кэширования ответов (ибо не надо было), с сессиями, аутентификацией и имперсонацией. Не сказал бы, что это было сильно сложно или объемно.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Прошу на касаться вопросов производительности.
