Комментарии 12
Обратите внимание. по ETHERNET. Ради устранения задержек, ребята весь IP стек выкинули к такой-то матери.
Никакого UDP, Кармак вас упаси. Только RDMA, только хардкор.
Теперь о проблемах. Если взять суровую монолитную вычислительную программу, которая написана под многопоточку (я брал традиционный LAPACK и считал GMRES) на одной машине и попытаться запустить ее вот на таком чуде (делал такие опыты с kerrighed), то задержки в канале связи (особенно, если это не InfiniBand или PCI-E) убьют, к сожалению все удовольствие.
В то же время, программа, написанная с учетом топологии кластера (OpenMP + OpenMPI) работала быстрее — просто потому, что разработчик знал, когда у него данные близко, а когда — на кудыкиных горах.
Иниересно, а попробовать завести это все на 10G Ethernet…
Вообще, учитывая что у нас есть сегодня — сомнительная штуковина. Есть уже и процы на кучи потоков, и памяти можно очень много — мы научились размазывать по контейнерам нагрузку…
Может быть интересно только как бюджетное решение на старом хламе которого с избытком завалялось, но нужно код приложения переписывать...
ЕМНИП, для подобных задач 10G это "фу, кака". В кластерах под вычисления используют инфинибенд ради сильно меньшего летенси.
Черт, это перевод… Я поначалу подумал что это автор пишет…
Я не мог понять, почему она такая глупая и простая, намного проще, чем любой API для удалённой работы, и почему компьютерные системы, кажется, не способны на такое.
Никто этого еще не придумал потому что задача по сложности эквивалентна синхронизации состояния в распределенных базах данных (а это просто огромная и сложная область да еще с кучей фундаментальных ограничений). Вот как вы собрались работать с шаред-состоянием в этих телепроцессах на разных машинах? У вас не то что там проблемы с многопоточностью как в обычных потоках — у вас появятся куда более серьезные проблемы консистентности из-за того что будет отсутствовать даже банальный атомарный бродкаст (который уже обеспечивается кеш-когерентностью самого процессора фундаментально упрощая проблемы многопоточного программирования). В итоге вам придется начинать все с нуля и алгоритмов вроде paxos-а или raft-а и погрузиться во все тяжкие распределенных систем и транзакционности.
Уважаю.
Самое интересное в этой теме — как CRIU что-то делает на стороне сохраняемого процесса. ptrace? Нет, медленно, неудобно. Они через ptrace подкладывают в процесс паразита (так в коде и называется), который слушает сокет и выполняет команды из него. А он уже что угодно делает.
Чем то напомнило )
Criu звучит круто, но по факту оно не работает. По крайней мере на чем-то более-менее серьезном.
Это очень крутой пример того, что могут (могли) ребята из Виртуоззо. Но точно не надо тащить в прод
Телепортируем процесс на другой компьютер!