Комментарии 17
Извращение какое-то. Чем protobuf для RPC не устроил?
Мне нужна была совместимость формата с командной строкой и минимальный объем метаданных. Получился еще один убогий формат RPC-запросов, зато без излишеств. В данном случае бутылочное горлышко — скорость протокола. В то же время у protobuf больше оверхед.
Издержки сериализации в protobuf велики в сравнении с оверхедом чтения/записи в stdin/stdout? Вы, верно, шутите? Если что и оптимизировать, так именно канал передачи данных, тот же /dev/shm для этой цели куда лучше подходит.
Надо будет попробовать передавать через /dev/shm. ivlis советовал мне так поступить, но я наткнулся на обсуждение, где утверждали что общая память для 32-бит и 64-бит приложений содержит подводные камни. Я почитал еще статей, судя по всему там ошибались.
Так ведь stdin/stdout в нормальной работе этой программы будут перенаправлены, и будут представлять из себя анонимные пайпы. Какие там издержки то? Это ж просто передача буфера между процессами, с чего бы /dev/shm быстрее будет?
Пайп в общем случае медленнее чем преаллоцированная через /dev/shm область памяти.
И где именно он будет медленнее? Больше всего времени будет потрачено на read и write, в обоих случаях. А внутри пайпа просто небольшой буфер.
Я, кстати, проверил скорость работы пайпа простейшим способом.
$ dd if=/dev/zero bs=1M count=1024 | dd of=/dev/null
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied2097152+0 records in
2097152+0 records out
1073741824 bytes (1.1 GB) copied, 1.64809 s, 652 MB/s
, 1.64816 s, 651 MB/s
Медленно? Но это большими блоками. Если по 10 байт писать, то всё резко упирается в сами системные вызовы:
$ dd if=/dev/zero bs=10 count=102400 | dd of=/dev/null
102400+0 records in
102400+0 records out
390+63096 records in
2000+0 records out
1024000 bytes (1.0 MB) copied, 0.0913079 s, 11.2 MB/s
1024000 bytes (1.0 MB) copied, 0.0908237 s, 11.3 MB/s
Для /dev/shm:
$ dd if=/dev/zero bs=10 count=102400 of=/dev/shm/tmp
102400+0 records in
102400+0 records out
1024000 bytes (1.0 MB) copied, 0.0767044 s, 13.3 MB/s
Отличается даже не в разы. Но тут не совсем честно получается, в случае с пайпом 2 раза читается-пишется, а без пайпа только 1 раз.
Я, кстати, проверил скорость работы пайпа простейшим способом.
$ dd if=/dev/zero bs=1M count=1024 | dd of=/dev/null
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied2097152+0 records in
2097152+0 records out
1073741824 bytes (1.1 GB) copied, 1.64809 s, 652 MB/s
, 1.64816 s, 651 MB/s
Медленно? Но это большими блоками. Если по 10 байт писать, то всё резко упирается в сами системные вызовы:
$ dd if=/dev/zero bs=10 count=102400 | dd of=/dev/null
102400+0 records in
102400+0 records out
390+63096 records in
2000+0 records out
1024000 bytes (1.0 MB) copied, 0.0913079 s, 11.2 MB/s
1024000 bytes (1.0 MB) copied, 0.0908237 s, 11.3 MB/s
Для /dev/shm:
$ dd if=/dev/zero bs=10 count=102400 of=/dev/shm/tmp
102400+0 records in
102400+0 records out
1024000 bytes (1.0 MB) copied, 0.0767044 s, 13.3 MB/s
Отличается даже не в разы. Но тут не совсем честно получается, в случае с пайпом 2 раза читается-пишется, а без пайпа только 1 раз.
Есть маленький ньюанс. В shm никто не пишет через write, и никто не читает оттуда через read. Делают shm_open, а потом mmap и получают отображение одного участка физической памяти на адресное пространство двух процессов, через который потом и идёт обмен данными.
там не получится прямо один и тот же участок памяти, потому что адресное пространство у 32бит и 64ббит несколько разное
Вы тогда не путайте /dev/shm (который обычно является tmpfs) и шареную память. shm_open замечательнейше работает без наличия /dev/shm в системе.
В случае использования общей памяти придётся как-то реализовывать очередь команд и синхронизировать её, на это тоже требуется время. Если учесть обычный размер передаваемых аргументов (десятки байт) — именно синхронизация будет занимать всё время. С пайпом это делать намного проще.
В случае использования общей памяти придётся как-то реализовывать очередь команд и синхронизировать её, на это тоже требуется время. Если учесть обычный размер передаваемых аргументов (десятки байт) — именно синхронизация будет занимать всё время. С пайпом это делать намного проще.
Я сделал через shm,mmap — результат оказался посредственным. Для проверки я взял гипотетическую функцию, которая заполняет буфер размером 1кбайт. Получилось, что shm дает выигрыш всего в 1,5 (полтора) раза. Это тормозят синхронизирующие семафоры.
Вот еще бы rundll через wine :D
К сожалению rundll такое не умеет
Ну mingw, winelib, LoadLibrary и GetProcAddress в помощь.
Однако Rundll и Rundll32 позволяют вызывать только некоторые функции из некоторых библиотек DLL. Например, с помощью данных программ нельзя вызывать функции Win32 API (Application Programming Interface), экспортируемые системными библиотеками DLL. Эти программы позволяют вызывать функции только из тех библиотек DLL, при разработке которых была реализована подобная возможность.
support.microsoft.com/kb/164787
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Используем 32битные библиотеки в 64битных программах