Повышения производительности и сопоставления производительности перекрестной загрузки ACE С++?

Ответ 1

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

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

Ответ 2

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

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

Ответ 3

Не беспокойтесь о накладных расходах уровня абстракции OS для объектов потоковой передачи и синхронизации. Накладные потоки буквально вообще не имеют значения (поскольку это относится только к созданию потоков, которое уже значительно медленнее по сравнению с накладными расходами на косвенную направленность указателя). Если вы обнаружите, что mutex ops замедляет вас, вам лучше смотреть на атомные операции или перестраивать шаблоны доступа к данным, чтобы избежать конкуренции.

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

Ответ 4

Я использовал ACE для многочисленных серверов с большими нагрузками. Это никогда не подводило меня. Он прочный камень и делает работу уже много лет. Попытался изучить сетевую структуру BOOST ASIO - не мог ее повесить. В то время как BOOST является более "современным" С++, его также труднее использовать для нетривиальных задач - и без "современного" опыта С++ и глубоких знаний STL это трудно использовать правильно.

Ответ 5

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

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

Ответ 6

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

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

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

Ответ 7

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

Ответ 8

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

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

Ответ 9

Используйте ACE и поддерживайте совместную работу. ACE имеет лучший коммуникационный API, основанный на шаблонах проектирования OO, тогда как boost имеет дизайн "современного С++" и хорошо работает с контейнерами, например.

Ответ 10

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

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

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

Ответ 11

Я использую ACE в течение многих лет (8), но я только начал исследовать использование boost снова для своего следующего проекта. Я рассматриваю boost, потому что у него есть большая сумка для инструментов (регулярное выражение и т.д.), А части ее впитываются в стандарт С++, поэтому долгосрочное обслуживание должно быть проще. Тем не менее, усиление потребует некоторой корректировки. Хотя Грег упоминает, что поддержка потоков менее инвазивна, поскольку она может запускать любую (C или статическую) функцию, если вы привыкли использовать классы потоков, которые более похожи на классы потоков Java и С#, которые предоставляет ACE_Task, у вас есть использовать немного утонченности, чтобы получить то же самое с boost.