Сравнение производительности кроссплатформенной производительности в сравнении с ACE C ++? - PullRequest
20 голосов
/ 24 января 2009

Я участвую в предприятии, которое перенесет некоторые функции связи, анализа и обработки данных с Win32 на Linux, и оба будут поддерживаться. Проблемная область очень чувствительна к пропускной способности и производительности.

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

Может ли кто-нибудь предоставить некоторые данные - документированные или из уст в уста или, возможно, некоторые ссылки - об относительной эффективности между этими двумя?

EDIT

Спасибо всем. Подтвердили наши первоначальные мысли - мы, скорее всего, выберем поддержку для кроссплатформенных вещей системного уровня.

Ответы [ 11 ]

27 голосов
/ 24 января 2009

Ни одна из библиотек не должна иметь каких-либо накладных расходов по сравнению с использованием встроенных средств потоковой обработки ОС. Вы должны посмотреть, какой API чище. По моему мнению, API-интерфейс Boost Thread значительно проще в использовании.

ACE имеет тенденцию быть более "классическим OO", в то время как boost имеет тенденцию извлекать пользу из дизайна стандартной библиотеки C ++. Например, для запуска потока в ACE требуется создать новый класс, производный от ACE_Task, и переопределить виртуальную функцию svc (), которая вызывается при запуске потока. В boost вы создаете поток и запускаете любую функцию, которая вам нужна, которая значительно менее инвазивна.

20 голосов
/ 08 мая 2009

Сделайте себе одолжение и держитесь подальше от ACE. Это ужасная, ужасная библиотека, которая никогда не должна была быть написана, если вы спросите меня. Я работал (или, скорее, ДОЛЖЕН работать с ним) в течение 3 лет, и я говорю вам, что это плохо спроектированный, плохо документированный, плохо реализованный кусок хлама, использующий архаичный C ++ и построенный на совершенно безумных дизайнерских решениях ... вызывающий ACE «C с классами» на самом деле делает это одолжение. Если вы посмотрите на внутренние реализации некоторых из его конструкций, вам часто будет трудно подавить рвотный рефлекс. Кроме того, я не могу не подчеркнуть аспект «плохой документации». Обычно понятие ACE о документировании функции заключается в простой печати подписи функции. Что касается значения его аргументов, его возвращаемого значения и его общего поведения, то, как правило, вам остается это выяснить самостоятельно. Мне надоело гадать, какие исключения может выдавать функция, какое возвращаемое значение означает успех, какие аргументы я должен передать, чтобы функция делала то, что мне нужно, или функция / класс поточно-ориентирована или нет.

Boost, с другой стороны, прост в использовании, современный C ++, чрезвычайно хорошо документирован, и он просто РАБОТАЕТ! Ускорение - путь к успеху, с ACE!

8 голосов
/ 24 января 2009

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

Что касается повышения по сравнению с ACE, то это вопрос «нового стиля» против «старого стиля» программирования. В Boost есть много шаблонов, основанных только на заголовках (с которыми приятно работать, если вы можете это оценить). Если, с другой стороны, вы привыкли к стилю C ++ "C с классами", ACE будет казаться намного более естественным. Я считаю, что это в основном вопрос личного вкуса вашей команды.

7 голосов
/ 16 октября 2009

Я использовал ACE для многочисленных мощных производственных серверов. Это никогда не подводило меня. Это твердое тело и делать работу в течение многих лет. Пытался изучить сетевую инфраструктуру BOOST ASIO - не смог освоить его. Хотя BOOST является более «современным» C ++, его также сложнее использовать для нетривиальных задач - и без «современного» C ++ опыта и глубоких знаний STL его трудно использовать правильно

6 голосов
/ 08 мая 2009

Даже если ACE и является старым классом C ++, он все еще имеет множество потоково-ориентированных функций, которые Boost пока не предоставляет.

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

3 голосов
/ 22 сентября 2012

Когда дело доходит до простоты использования, boost намного лучше, чем ACE. boost-asio имеет более прозрачный API, его абстракции проще и могут легко обеспечить строительные блоки для вашего приложения. Полиморфизм времени компиляции разумно используется в boost для предупреждения / предотвращения нелегального кода. С другой стороны, использование шаблонов в ACE ограничено обобщением и вряд ли когда-либо будет ориентировано на пользователя, чтобы запретить незаконные операции. У вас больше шансов обнаружить проблемы во время выполнения с ACE.

Простой пример, который я могу вспомнить, это ACE_Reactor - довольно масштабируемый и отделенный интерфейс - но вы должны помнить, что нужно вызывать его «собственную» функцию, если вы запускаете цикл обработки событий в потоке, отличном от того, где он был создан. Я потратил часы, чтобы понять это впервые, и мог бы легко провести дни. Как ни странно, его объектная модель показывает больше деталей, чем скрывает - хорошо для обучения, но плохо для абстракции.

https://groups.google.com/forum/?fromgroups=#!topic/comp.soft-sys.ace/QvXE7391XKA

2 голосов
/ 05 февраля 2009

Я бы не назвал ACE "C с классами". ACE не интуитивно понятен, но если вы потратите время и будете использовать фреймворк, как задумано, вы не пожалеете об этом.

Из того, что я могу сказать, после прочтения документации Boost я бы хотел использовать каркас ACE и классы контейнеров Boost.

2 голосов
/ 24 января 2009

Потоки - это лишь малая часть того, что обеспечивают boost и ACE, и в целом они не очень сопоставимы. Я согласен, что boost проще в использовании, так как ACE - довольно тяжелый фреймворк.

1 голос
/ 26 февраля 2012

Мы начали использовать ACE, полагая, что он будет скрывать различия платформы, присутствующие между окнами и unix в сокетах TCP и вызовом select. Оказывается, это не так. Взятие Ace на выбор, модель реактора, не может смешивать сокеты и стандартный ввод в окнах, и семантические различия между платформами, касающиеся уведомлений о возможности записи сокетов, все еще присутствуют на уровне ACE.

К тому времени, когда мы это осознали, мы уже использовали функции потоков и процессов ACE (последний из которых опять-таки не скрывает различия платформ в той степени, в которой нам хотелось бы), так что наш код теперь привязан к огромному библиотека, которая фактически предотвращает портирование нашего кода на 64-битную MinGW!

Я не могу дождаться того дня, когда последнее использование ACE в нашем коде будет окончательно заменено чем-то другим.

1 голос
/ 30 марта 2010

Используйте ACE и повышайте совместно. ACE имеет лучший API связи, основанный на шаблонах проектирования ОО, тогда как boost имеет дизайн, подобный «современному C ++», и хорошо работает, например, с контейнерами.

...