В процессе вызова производительности производительности фреймворков, таких как Corba (например, TAO), Thrift, D-Bus, ICE
Мы пытаемся создать приложение, где его части могут распространяться, но не обязательно. Для этого мы хотели бы использовать существующую структуру для удаленных вызовов. Чтобы не реализовывать все дважды, мы хотели бы использовать одно и то же для вызовов на одной и той же машине, в одном и том же процессе.
Кто-нибудь знает штраф за производительность / задержку, который мы получим при использовании такой инфраструктуры вместо прямого вызова vtable? Доступны ли сравнения?
Система должна быть переносимой на Windows & Linux
С уважением
Тобиас
Решение
Что характерно для большинства коммуникационных сред, о которых я знаю, это то, что они всегда будут сериализовать, отправлять и десериализовать, что всегда будет падать в производительность при передаче ссылок на другие потоки и непосредственном доступе к данным (с мьютексом или без него). Это не всегда должно быть драматично, когда обязанности распределяются разумно, чтобы свести к минимуму общение.
Обратите внимание, что при таком архитектурном выборе производительность является лишь одним из аспектов, которые необходимо учитывать. Другие: безопасность, стабильность, гибкость, развертывание, ремонтопригодность, лицензии и т. Д.
Другие решения
OmniORB в течение долгого времени был совмещенный ярлык, который делал прямые вызовы, но начиная с версии 4 он имеет собственную политику POA, которая обходит даже больше требуемого поведения CORBA, чтобы сделать его почти таким же быстрым, как прямой виртуальный вызов. Увидеть omniORB Wiki и искать «Ярлык местных звонков». К сожалению, этого, похоже, нет в официальных документах, по крайней мере, я смог найти.
В 2011 году CERN (Европейская организация ядерных исследований) сравнила CORBA, Ice, Thrift, ZeroMQ, YAMI4, RTI и Qpid (AMQP). Прочитайте их анализ и выводы. (PDF)
Который может быть просто сравнение вы были после. (Найдено благодаря комментарию Матье Руж.)
Я бы также добавил, что, хотя некоторые ORB позволяют вам пропустить сортировку, вы все равно не можете избежать динамического выделения памяти, что действительно важно для производительности. (Сегодня процессоры безумно быстрые, доступ к памяти медленный, и запрос ОС на выделение страницы памяти действительно медленный.)
Итак, где C ++ вы можете просто вернуть const string &Связывание CORBA C ++ заставит вас динамически размещать и освобождать строку или структуру данных (по типу возвращаемого значения или параметру out). Это не имеет значения, если метод вызывает в любом случае процесс / сеть, но в процессе он становится довольно значительным по сравнению с простым C ++.
Другая «ошибка», которой мы были сожжены, заключается в том, что вы не можете определить взаимно рекурсивные структуры (то есть структура «A» включает в себя «B», который снова включает «A»). Это означало, что мы должны были преобразовать их в интерфейсы, которые распределяют CORBA Servant «на стороне сервера» (в процессе) для каждой структуры, что требует очень много памяти. Я считаю, что есть продвинутые уловки, чтобы избежать на самом деле создавая слуг, но в конечном итоге мы просто хотим полностью уйти от CORBA, а не копаться глубже.
Особенно в C ++, управление памятью очень хрупкое и его трудно программировать правильно. (Увидеть Взлет и падение или CORBA, раздел «сложность».) Я выбрал много человеко-лет дополнительных усилий из-за этого выбора технологии.
Мне было бы любопытно услышать, как вы & что ты принял.
Одной из нескольких причин создания IBM System Object Model была CORBA. IBM SOM — это «локальный CORBA», а IBM DSOM — это реализация CORBA.
Вы, вероятно, должны оценить somFree.
Другой вариант Организация Объединенных Наций (от OpenOffice.org). Не могу сказать, что мне нравится UNO. Это хуже, но оно более зрелое, чем давно забытое СДЛ. Локальная (внутрипроцессная) экосистема UNO разделена на разделы в зависимости от языка программирования. C ++ и Java являются наиболее распространенными разделами. Сериализации не существует, но предпочтительным механизмом взаимодействия между разделами является поздняя привязка (Java Proxy-> Java Dispatch-> C ++ Dispatch-> C ++ объект) (своего рода IDispatch в OLE), хотя прямые привязки также могут использоваться (Java Proxy-> Объект C ++).
ICE от ZeroC определенно поддерживает вызов коллокации, когда избегается сортировка данных. Вы можете найти подробную информацию о документации на их сайте: http://doc.zeroc.com/display/Ice/Location+Transparency
Хотя вызов коллокации имеет некоторые накладные расходы по сравнению с вызовом виртуального метода, к сожалению, у меня нет фактических номеров, но это также зависит от условий, т. Е. Сколько слуг зарегистрировано в конкретном адаптере и т. Д.