Сравнение производительности кроссплатформенной производительности с ACE C++?
Я участвую в проекте, который будет портировать некоторые функции связи, анализа и обработки данных с Win32 на Linux, и оба будут поддерживаться. Проблемная область очень чувствительна к пропускной способности и производительности.
У меня очень мало опыта работы с характеристиками наддува и ACE. В частности, мы хотим понять, какая библиотека обеспечивает лучшую производительность для многопоточности.
Может ли кто-нибудь предоставить некоторые данные - документированные или из уст в уста или, возможно, некоторые ссылки - об относительной эффективности между ними?
РЕДАКТИРОВАТЬ
Спасибо всем. Подтвердили наши первоначальные мысли - мы, скорее всего, выберем поддержку для кроссплатформенного уровня системы
11 ответов
Ни одна из библиотек не должна иметь никаких накладных расходов по сравнению с использованием встроенных средств потоковой обработки ОС Вы должны посмотреть, какой API чище. По моему мнению, API-интерфейс Boost Thread значительно проще в использовании.
ACE имеет тенденцию быть более "классическим OO", в то время как boost имеет тенденцию опираться на дизайн стандартной библиотеки C++. Например, для запуска потока в ACE требуется создать новый класс, производный от ACE_Task, и переопределить виртуальную функцию svc(), которая вызывается при запуске потока. В boost вы создаете поток и запускаете любую функцию, которую хотите, что значительно менее агрессивно.
Сделайте себе одолжение и держитесь подальше от ACE. Это ужасная, ужасная библиотека, которая никогда не должна была быть написана, если вы спросите меня. Я работал (или, скорее, ДОЛЖЕН работать с ним) в течение 3 лет, и я говорю вам, что это плохо спроектированный, плохо документированный, плохо реализованный кусок хлама, использующий архаичный C++ и построенный на совершенно безумных дизайнерских решениях... вызывающий ACE "C с классами" на самом деле делает это одолжение. Если вы посмотрите на внутренние реализации некоторых из его конструкций, вам часто будет трудно подавить рвотный рефлекс. Кроме того, я не могу подчеркнуть аспект "плохой документации" достаточно. Обычно понятие ACE о документировании функции заключается в простой печати подписи функции. Что касается значения его аргументов, его возвращаемого значения и его общего поведения, то, как правило, вам самим приходится это выяснять. Мне надоело гадать, какие исключения может выдавать функция, какое возвращаемое значение обозначает успех, какие аргументы я должен передать, чтобы функция делала то, что мне нужно, или функция / класс поточно-ориентирована или нет.
Boost, с другой стороны, прост в использовании, современный C++, чрезвычайно хорошо документирован, и он просто РАБОТАЕТ! Повышение это путь, вниз с ACE!
Не беспокойтесь о накладных расходах уровня абстракции ОС на объектах потоков и синхронизации. Накладные расходы на потоки буквально не имеют никакого значения (поскольку они применяются только к созданию потоков, которые уже чрезвычайно медленны по сравнению с издержками косвенной косвенной указки). Если вы обнаружите, что операции мьютекса замедляют работу, вам лучше смотреть на атомарные операции или перестраивать шаблоны доступа к данным, чтобы избежать конфликтов.
Что касается повышения по сравнению с ACE, то это вопрос "нового стиля" против "старого стиля" программирования. В Boost есть много шаблонов, основанных только на заголовках (с которыми приятно работать, если вы можете это оценить). Если, с другой стороны, вы привыкли к стилю C++ "C с классами", ACE будет казаться намного более естественным. Я считаю, что это в основном вопрос личного вкуса вашей команды.
Я использовал ACE для многочисленных мощных производственных серверов. Это никогда не подводило меня. Это твердое тело и делать работу в течение многих лет. Пытался изучить сетевую инфраструктуру BOOST ASIO - не смог освоить ее. Хотя BOOST является более "современным" C++, его также сложнее использовать для нетривиальных задач - и без "современного" C++ опыта и глубоких знаний STL его трудно использовать правильно
Даже если ACE является своего рода старой школой C++, он все еще имеет множество потоково-ориентированных функций, которые Boost пока не предоставляет.
На данный момент я не вижу причин не использовать оба (но для разных целей). После того, как boost предоставит простое средство для реализации очередей сообщений между задачами, я могу рассмотреть возможность отказа от ACE.
Когда дело доходит до простоты использования, boost намного лучше, чем ACE. boost-asio имеет более прозрачный API, его абстракции проще и могут легко предоставлять строительные блоки для вашего приложения. Полиморфизм времени компиляции разумно используется в boost для предупреждения / предотвращения нелегального кода. С другой стороны, использование шаблонов в ACE ограничено обобщением и вряд ли когда-либо будет ориентировано на пользователя, чтобы запретить незаконные операции. Вы более вероятно обнаружите проблемы во время выполнения с ACE.
Простой пример, который я могу вспомнить, это ACE_Reactor - довольно масштабируемый и отделенный интерфейс - но вы должны помнить, что нужно вызывать его "собственную" функцию, если вы запускаете цикл обработки событий в потоке, отличном от того, где он был создан. Я потратил часы, чтобы понять это впервые, и мог бы легко провести дни. Как ни странно, его объектная модель показывает больше деталей, чем скрывает - хорошо для обучения, но плохо для абстракции.
Я бы не назвал ACE "C с классами". ACE не интуитивно понятен, но если вы не торопитесь и используете платформу, как задумано, вы не пожалеете об этом.
Из того, что я могу сказать, после прочтения документации Boost, я бы хотел использовать каркас ACE и классы контейнеров Boost.
Потоки - это лишь малая часть того, что предоставляют boost и ACE, и в целом они не очень сопоставимы. Я согласен с тем, что boost проще в использовании, так как ACE - довольно тяжелая платформа.
Используйте ACE и повышайте совместно. ACE имеет лучший API связи, основанный на шаблонах проектирования ОО, тогда как boost имеет дизайн, подобный "современному C++", и хорошо работает, например, с контейнерами.
Мы начали использовать ACE, полагая, что он скроет различия платформы, существующие между windows и unix в сокетах TCP и вызовом select. Оказывается, это не так. Взятие Ace на выбор, шаблон реактора, не может смешивать сокеты и стандартный ввод в окнах, и семантические различия между платформами, касающиеся уведомлений о возможности записи в сокеты, все еще присутствуют на уровне ACE.
К тому времени, когда мы поняли это, мы уже использовали функции потоков и процессов ACE (последний из которых опять-таки не скрывает различия платформ в той степени, в которой мы хотели бы), так что наш код теперь привязан к огромной библиотеке, которая на самом деле предотвращает портирование нашего кода на 64-битную MinGW!
Я не могу дождаться того дня, когда последнее использование ACE в нашем коде будет наконец заменено чем-то другим.
Я использую ACE в течение многих лет (8), но я только начал снова исследовать использование наддува для моего следующего проекта. Я рассматриваю повышение, потому что у него есть большая сумка с инструментами (регулярные выражения и т. Д.), И ее части поглощаются стандартом C++, поэтому долгосрочное обслуживание должно быть проще. Тем не менее, повышение будет требовать некоторой корректировки. Хотя Грег упоминает, что поддержка потоков менее инвазивна, поскольку она может запускать любую (C или статическую) функцию, если вы привыкли использовать классы потоков, которые больше похожи на классы потоков Java и C#, что обеспечивает ACE_Task, у вас есть использовать немного ловкости, чтобы получить то же самое с наддувом.