Я смутно припоминаю что каждая полсыка в нетипизированном канале сопровождается сериализацией-десериализацией. Это как бы сделано для того чтобы при десериализации гарантировано не упала принимающая сторона. В типизированных каналах такого нет. Опять же, насколько я помню - давно смотрел.
Принимающий процесс после посылки слишком долго просыпался.
Выглядело примерно так: выполняем два старта (spawn), примерно одинаковой нагрузки, затем ждем сообщений от обоих процессов и обрабатываем. Время ожидания сообщений оказывалось заметно (на десятые доли секунды) больше, чем время работы любого из процессов.
Во всех существующих бекендах нету нормального разделения между локальной передачей данных и удаленной. Был такой-то проект позволяющий объединять различные network-transport, т.е. с ним можно было бы использовать stm для локальной передачи данных и tcp для удаленной, но проект вроде зашел вникуда и более менее живого кода не найти.
Так же все данные сериализуются-десериализуются даже локально, сделано это для того, чтобы не иметь констрейнт NFData, и при этом вычислять все данные на локальной ноде до отсылки (так решена проблема ленивости).
Для того, чтобы обойти замедления можно использовать семейство unsafe* (unsafeSend и т.п.) данные методы работают только для локальных соединений, не сериализуют и не форсят вычисления. Если быть честным, то network-transport вообще обходится стороной. Должно помочь для скорости. Что ты и наблюдал.
Кто готовит поверх RDMA? ParSci^W PS Labs сделали network-transport-cci, оно должно быть пошустрее. Правда похоже, что положить на hackage и дооткрывать так и не успели :/
Comments 3
Reply
Выглядело примерно так: выполняем два старта (spawn), примерно одинаковой нагрузки, затем ждем сообщений от обоих процессов и обрабатываем. Время ожидания сообщений оказывалось заметно (на десятые доли секунды) больше, чем время работы любого из процессов.
Это было странно.
Reply
Был такой-то проект позволяющий объединять различные network-transport, т.е. с ним можно было бы использовать stm
для локальной передачи данных и tcp для удаленной, но проект вроде зашел вникуда и более менее живого кода не
найти.
Так же все данные сериализуются-десериализуются даже локально, сделано это для того, чтобы не иметь
констрейнт NFData, и при этом вычислять все данные на локальной ноде до отсылки (так решена проблема
ленивости).
Для того, чтобы обойти замедления можно использовать семейство unsafe* (unsafeSend и т.п.) данные методы
работают только для локальных соединений, не сериализуют и не форсят вычисления. Если быть честным, то
network-transport вообще обходится стороной. Должно помочь для скорости. Что ты и наблюдал.
Кто готовит поверх RDMA? ParSci^W PS Labs сделали network-transport-cci, оно должно быть пошустрее.
Правда похоже, что положить на hackage и дооткрывать так и не успели :/
Reply
Leave a comment