Только что протестировал задержку от Java на моем Corei5 2,8 ГГц, только отправка / получение только одного байта,
2 процесса Java только что появились, без назначения определенных ядер ЦП с помощью набора задач:
TCP - 25 microseconds
Named pipes - 15 microseconds
Теперь явно указываются основные маски, например taskset 1 java Srv или taskset 2 java Cli :
TCP, same cores: 30 microseconds
TCP, explicit different cores: 22 microseconds
Named pipes, same core: 4-5 microseconds !!!!
Named pipes, taskset different cores: 7-8 microseconds !!!!
так
TCP overhead is visible
scheduling overhead (or core caches?) is also the culprit
В то же время Thread.sleep (0) (который, как показывает strace, приводит к выполнению одного вызова ядра sched_yield () ядра Linux), занимает 0,3 микросекунды - поэтому именованные каналы, запланированные для одного ядра, по-прежнему имеют большие издержки
Некоторые измерения общей памяти:
14 сентября 2009 г. - компания Solace Systems объявила сегодня, что ее API-интерфейс платформы единой системы обмена сообщениями может достичь средней задержки менее 700 наносекунд при использовании транспорта с общей памятью.
http://solacesystems.com/news/fastest-ipc-messaging/
P.S. - попробовал разделить память на следующий день в виде отображенных в память файлов,
если ожидание занято, мы можем уменьшить задержку до 0,3 мкс
для передачи одного байта с кодом, подобным этому:
MappedByteBuffer mem =
new RandomAccessFile("/tmp/mapped.txt", "rw").getChannel()
.map(FileChannel.MapMode.READ_WRITE, 0, 1);
while(true){
while(mem.get(0)!=5) Thread.sleep(0); // waiting for client request
mem.put(0, (byte)10); // sending the reply
}
Примечания: необходим Thread.sleep (0), чтобы 2 процесса могли видеть изменения друг друга
(Другого пути пока не знаю). Если 2 процесса принудительно подключены к одному ядру с набором задач,
задержка становится 1,5 микросекунды - это задержка переключения контекста
P.P.S - и 0,3 микросекунды - это хорошее число! Следующий код занимает ровно 0,1 микросекунды, выполняя только примитивную конкатенацию строк:
int j=123456789;
String ret = "my-record-key-" + j + "-in-db";
P.P.P.S - надеюсь, это не слишком неуместно, но в конце концов я попытался заменить Thread.sleep (0) на увеличение статической переменной volatile int (при этом JVM сбрасывает кэш процессора), и получил - запись! - 72 наносекунды латентное взаимодействие Java-процесса с Java !
Однако при принудительном использовании одного и того же ядра ЦП энергонезависимо увеличивающиеся JVM никогда не передают управление друг другу, создавая таким образом ровно 10 миллисекундную задержку - квант времени в Linux кажется равным 5 мс ... Так что это следует использовать только при наличии запасное ядро - иначе сон (0) безопаснее.