Хорошая альтернатива общей памяти IPC для приложений Java/C++ на Linux
Я повторил ваш тест, используя Cygwin и g ++. Ваш код скомпилирован в 480k с -O2. Запуск полосы на исполняемом файле уменьшил его до 280k.
В целом, я подозреваю, что ваша проблема заключается в использовании заголовка < iostream>. Это приводит к подключению довольно большой библиотеки. Также обратите внимание, что cout << x делает гораздо больше, чем просто печатает. Здесь есть локали, ручьи и всякие вещи под капотом.
Если, однако, иметь маленький исполняемый размер - это реальная, критически важная задача, то избегайте ее и используйте printf или put. Если это не так, то я бы сказал, заплатите единовременную стоимость iostream и покончите с этим.
4 ответа
Это зависит от того, как вы планируете взаимодействовать между приложениями. В среде POSIX у вас есть каналы, разделяемая память, сокеты, семафоры и очереди сообщений. См. Этот вопрос: Сравнение unix linux IPC для получения дополнительной информации.
Какова модель взаимодействия для ваших процессов (т.е. клиент / сервер, производитель-потребитель и т. Д.)?
Из личного опыта, я Я бы предложил, что лучше всего будут каналы (поскольку это просто файлы для чтения и записи байтов) или сокеты (поскольку оба языка поддерживают их).
Хотя, вероятно, не самый эффективный, Java поддерживает только сокеты из коробки (лучшее, что я помню). Они очень гибкие, но, возможно, не такие быстрые, как другие варианты. Как упоминал Зифре, это оставляет вам возможность для прозрачности сети, а также прозрачности языка / привязки; так как в наши дни почти каждый язык поддерживает библиотеку сокетов из коробки.
Хотя я бросаю эффективность в окно, если вы хотите вывести ее на новый уровень, вы, вероятно, могли бы обернуть это в веб-службу какой-то.
Как сказал Микелонг, это во многом зависит от того, что вы делаете. AFAIK, ни один из методов IPC не имеет собственных привязок Java, поэтому вам, вероятно, придется использовать JNI и создавать привязки самостоятельно, поэтому все различные методы примерно одинаково сложны. Если вы выполняете передачу сообщений, я настоятельно рекомендую использовать очереди сообщений. Они очень просты в использовании (если у вас есть привязки) и имеют хорошую производительность. Если вам нужно «поделиться» каким-то ресурсом, то вы, вероятно, захотите использовать разделяемую память.
Похоже, что у вас есть какая-то вещь типа клиент / сервер, я бы сказал, используйте либо очереди сообщений, либо сокеты домена unix, либо именованные каналы. Все они включают копирование данных в ядро, поэтому они не так быстры, как разделяемая память, но все же очень быстры. Если у вас есть данные, похожие на сообщения (отдельные небольшие пакеты), используйте очереди сообщений. Это, наверное, самое чистое решение. Если у вас больше потока данных, используйте каналы или сокеты. У сокетов есть то преимущество, что вы можете легко сделать их прозрачными для сети (например, X11) позже, если захотите, но с ними немного сложнее работать, чем с каналами. Производительность, вероятно, очень похожа.
Самый простой способ связи между приложениями, написанными на разных языках, - это IMHO CORBA . Есть очень хорошие CORBA ORB с открытым исходным кодом . Мы используем TAO для C ++ и JacORB для Java. Существуют также такие компании, как OCI и Remedy , которые предоставляют техническую поддержку.