Политехнический университет Виргинии предложил для обсуждения разработчиками ядра Linux набор патчей с реализацией системы распределённого выполнения потоков Popcorn (Distributed Thread Execution), позволяющей организовать выполнение приложений на нескольких компьютерах с распределением и прозрачной миграцией потоков. При помощи Popcorn приложения могут быть запущены на одном хосте, после чего без остановки работы перемещены на другой хост. В многопоточных программах допускается миграция на другие хосты отдельных потоков...Подробнее: https://www.opennet.me/opennews/art.shtml?num=52877
Больше ядер богу ядер
А что же плохого иметь много ядер? Вы бы отказались от 32 - 128-ядерной машинки?
У меня есть какая-то штука, называется вроде Xeon Phi 7210, только я не могу понять, зачем она мне. Что с ней можно сделать? Какая польза от неё, если поставить в обычный компьютер?
Ну если котиков с фконтактика смотреть, то, да, пользы будет немного. Попробуй на ней LFS что-ли пособирать.
Это что подарок такой от кого-то? Или покупаю не знаю зачем потому, что хочу вот это?
Пожалуй, это покруче ГРИДа будет. Знаю даже тех, кто захочет этим воспользоваться. Особенно когда расчёты неделями идут. Но писанина файлов с результатами - это тот ещё вопрос.
> Пожалуй, это покруче ГРИДа будет. Знаю даже тех, кто захочет этим воспользоваться.
> Особенно когда расчёты неделями идут. Но писанина файлов с результатами -
> это тот ещё вопрос.а кто захочет и для чего?
и чем это для них отличается от уже существующих методов запуска в кластере или в каком-нить GridGain ?не, технологически это реально круто, да и как бесшовная миграция с проблемных нод и балансировка - полезно
но вот само по себе применимость этого какая? всёж задачи для распределённых вычислений довольно специфические
Нормальный кластер единого системного образа обеспечивает миграцию процессов на другие узлы при обычном системном вызове fork (pthreads). Кочу прикладного ПО обычных пользователей: архиваторы, перекодировки видео, не говоря о научном ПО сразу, прозрачно, рапаралелятся по всем узлам кластера.
Насколько я понимаю для всех кластеров нужно переписывать программы под них.
Тут можно запустить теоретически любую программу в том числе неподдерживаемую разработчиком.
От перекодирования видео на домашнем компе со смартфона до рендера изображений на кластере.
> для всех кластеров нужно переписывать программы под них.Нет. SSI кластер для ПО это обычный комп с общим числом процов и оперативы. Для классического SSI который для миграции дочерных процессов использует системный вызов forck (pthreads) ничего переписывать ненадо.
> Тут можно запустить теоретически любую программу в том числе неподдерживаемую разработчиком.
Сабж это не классический SSI они для миграции процессов на другие узлы используют свой отдельный системный вызов. Для сабжа надо переписывать все ПО!!!
Чем сабж лучше MPI для которого тоже надо переписывать все ПО не понятно. MPI поддерживается сабжем но в той же мере MPI поддерживается и классическим SSI поскольку он прозрачен для ПО.
>>но вот само по себе применимость этого какая?- адмн: ааааааааабл?дь! у нас рэйд рушится, харды не можем купить! ваш софт надо переносить!
- бдлк: ааааааааабл?дь! у нас задача 20 из 50 дней считается, остановить её мы не можем!!
- элкт: ааааааааабл?дь! у нас вчера запланирован перенос на другую фазу, другой подвод, другую подстанцию! Может жахнуть, мы ничего не гарантируем.
- нчво: ааааааааабл?дь! у нас аренда кончается, переносите своё гуано в другой дотацентр! у вас джва дня!
- срвр: ааааааааабл?дь! алерт! алерт! алерт! префэйл кондишон! алерт! алерт! алерт!
и так далее )
Это как MPI?
не вспоминай это...
А что с ним не так было то? Ближайшие альтернативы выглядели куда хуже и страшнее.
Потребность программисту писать специализированное ПО используя только прраллельные алгоритмы.Обычное ПО MPI не паралелит.
Так и этот софт не параллелит то что не запаралеллили.
https://www.opennet.me/openforum/vsluhforumID3/120533.html#105
Это как Inferno
на миграцию запущеного фаерфокса со смартфона на десктоп и обратно я бы посмотрел....
ну или миграцию tox-а или rss-ридера...как можно применять этот "Distributed Thread Execution" ? какие идеи есть?
Мир немножко богаче, чем это видит анонимус с его локалхостом и телефоном.
> Мир немножко богаче, чем это видит анонимус с его локалхостом и телефоном.о, великий неанонимус! расширь мне сознание! покажи мне мир!
Воспользуйся гуглом и посмотри, для чего используют тот же CRIU.
И зачем это анонимусу если у него есть лишь локалхост и телефон? Вот анонимус и думает как ему можно применить новую, необычную для локалхоста, технологию. Но некоторые админы не могут опустить свой взляд на локалхост: надутые от гордости щёки мешают.
если такое ПО разлетится по всем ядрам линукс во будет праздник для взлома))) нашел одну уязвимость и все хосты одним махом у тебя в кармане)) отличная идея как я погляжу. такие системы придется держать строго в ограниченной локальной сети. для научных институтов вполне хорошая вещь.
B USB-шки залить эпоксидкой: это ж какой простор для взлома если софт можно копировать между машинами парой кнопок. Пусть с клавы программы набивают. Как в спектрумовские времена.
Только теплые ламповые перфокарты, только хардкор.
я смотрю вы все воспринимаете в штыки. ну не думая о всех возможностях так на эти штыки и напороться можно. все за развитие технологий, но и головой думать надо. искать возможности удержать технологию под полным контролем.
Абсолютно любая технология может (и будет) использована во вред. Поэтому напоминание о "на эти штыки и напороться можно. все за развитие технологий, но и головой думать надо. искать возможности удержать технологию под полным контролем" имеет смысла столько же, как и напоминание о необходимости дыхания и моргания.
никто и не отрицал, что человек разумным зовется только от слова разум, но действия часто продиктованы не им. что тут можно сказать за все время своего развития человек так и не изменился. только его оружие меняется от эпохе к эпохе.))
"Никогда не выеб*вайся в качалке. Ибо всегда найдется тот, кто твоим весом просто разминается." (с)
https://www.opennet.me/openforum/vsluhforumID3/120533.html#48https://www.opennet.me/openforum/vsluhforumID3/120533.html#42
telefork - где-то я уже слышал подобное ... а вспомнил, на хабре была недавно статья "Телепортируем процесс на другой компьютер!"
https://habr.com/ru/company/dcmiran/blog/499422/
Автор оригинала: Tristan Hume
он что с Политехнического университета Виргинии, или просто друг у друга потихоньку тыбзят идеи ?
Есть такое понятие "идея витает в воздухе". Это ж явный следующий логичный шаг от всяких микросервисов и подобного
> просто друг у друга потихоньку тыбзят идеи ?Все идеи тырят с моей работающей реализации: https://www.opennet.me/openforum/vsluhforumID3/120533.html#42
Если она такая хорошая надо было ее продавать задорого.
Единичные научные институты которые ее внедрение покупали в средине нулевых не имели денег. Разработка неокупалась.
я не понял. то есть я могу собрать 10 говнобуков в один кластер и что-нибудь компилировать?
> я не понял. то есть я могу собрать 10 говнобуков в один
> кластер и что-нибудь компилировать?да ты и раньше мог
https://en.wikipedia.org/wiki/Compile_farmне могу сейчас сразу нагуглить методичку по запуску своего кластера для компиляции, но раньше видел
Успешно используем: https://github.com/icecc/icecream
Как в сравнении с distcc?
//оффтопа на *BSD jail'ы мигрировать между нодами умеют?
Умеют на холодную. Но в новости не про это.
Вроде как в cbsd / BHYVE горячая миграция есть, а классические jail - надо останавливать процессы.
не взлетит. так и останется в виде патчей...
Про WireGuard тоже так говорили.
Кто про комментирует, для чего бы такое можно применить?
Есть у тебя софт, обрабатывающий данные в 100500 потоков, но при этом имеющий между ними общие данные и синхронизацию. Дальше ты его равномерно размазываешь по N систем без специальных ухищрений по обмену этими самыми данными.
А чем практически это отличается от кластеризации, в чем преимущество?
Так, наверное, это и есть одна из разновидностей кластеризации. Только здесь должно быть существено меньше танцев с настройками.
Там работа с памятью несколько смущает.
Есть смутные подозрения, что, если в ходе работы, активно шарятся данные, то производительность упрется в скорость синхронизации памяти по сети.
> Есть смутные подозрения, что, если в ходе работы, активно шарятся данные, то производительность упрется в скорость синхронизации памяти по сети.Оно во всех кластерах в скорость сети упирается.
Хороший выиграш на жирных, тяжолых процесах: распределить перекодировку видео на нескольких компах.
> Есть у тебя софт, обрабатывающий данные в 100500 потоков, но при этом
> имеющий между ними общие данные и синхронизацию. Дальше ты его равномерно
> размазываешь по N систем без специальных ухищрений по обмену этими самыми
> данными.а чего - распределённые/кластерные фс и просто базы данных раньше не существовали?
я не понимаю концептуальную новизну/профит (кроме distributed shared memory - не знаю были ли раньше распределённые in-memory map/bd, для java у GridGain было, у них ещё и жавамашина вместо LLVM создаёт мультиплатформенность)
Не, ну понятно что парни каких-то прорывов в синхронизации данных не совершили. Есть и распределенные базы данных и распределенные фс. Дело то не в синхронизации данных, а в конкретной реализации данных принципов применительно к процессу.Процесс не выполняется в ядре в вакууме. Он держит открытые хенлы на файлы, на сокеты, на расшаренную память. И это не считая того, что приложение может работать вообще с кастомными железками по pci или usb, которые тоже хранят свое состояние.
Все это нужно как-то синхронизировать, возможно уметь перемещать между компьютерами или пробрасывать прозрачно на один "основной" компьютер. Когда разрабатывали CRIU, с этим было куча проблем. И весь вопрос, насколько эта система работает быстро и сколько покрывает всех этих возможностей приложения. Потому что хочется брать абсолютно любое приложение и чтобы оно само начинало параллелиться, т.к. никто не будет переписывать приложение специально под Попкорн.
При чём тут FS? Речь о том, что у тебя треды _одного_ процесса потенциально могут летать между нодами, при этом прозрачно сохраняя общую область памяти + возможность синхронизации - и для этого не надо изголяться с кластерными FS, пилить свою собственную синхронизацию и т.п. Кластерная FS тут идёт только как дополнение - треды вполне могут захотеть что-то с общего "диска" почитать.
Потоки с чтением файлов не могут клонироваться в новости написано.
> Потоки с чтением файлов не могут клонироваться в новости написано.А я поэтому и говорю, что из этого супового набора имхо взлетит только DSM.
> При чём тут FS? Речь о том, что у тебя треды _одного_
> процесса потенциально могут летать между нодами, при этом прозрачно сохраняя общую
> область памяти + возможность синхронизацииа чем это от numa отличается?
Извини дружок, ты это в школе не проходил, да?
https://en.wikipedia.org/wiki/Non-uniform_memory_access
> Извини дружок, ты это в школе не проходил, да?
> https://en.wikipedia.org/wiki/Non-uniform_memory_accessи? так в чём разница? иль numa-over-ethernet диво дивное?
> и? так в чём разница? иль numa-over-ethernet диво дивное?Разница в том, что при NUMA одна микропроцессорная система осуществляет множественный доступ к разделяемой памяти, а в случае SDSM это синхронизация между несколькими системами.
>> и? так в чём разница? иль numa-over-ethernet диво дивное?
> Разница в том, что при NUMA одна микропроцессорная система осуществляет множественный доступ
> к разделяемой памяти, а в случае SDSM это синхронизация между несколькими
> системами.давайте лучше в терминах "когерентности кеша" для каждого проца
в чём отличие в обеспечении когерентности локальной памяти (кеша) каждого проца в numa и в "Distributed shared memory" соединённых через ethernet ("После стабилизации основных алгоритмов будет применён более эффективный вид транспорта.") ?
>Кто про комментирует, для чего бы такое можно применить?MAKEOPTS="-j 1000" emerge ....
Суперкомпьютеры станут ближе к людям.
Людям, как выясняется, обычные-то компы почти не нужны (постоянно сталкиваюсь с гейфон- дрочерами, причём чем крупнее город, тем больше этих юродивых), а что они будут делать с суперкомпом?
Между людьми и хомячками есть небольшая разница :)
"Ну я то уж точно не хомяк, идущий на поводу у конюктуры!"
Вот, один из носителей характерных детекторов этой разницы вылез.
Так залежь обратно, "не хомяк"
Самовнушением занимаешься прилюдно?
А еще как бесшовный переезд на более мощное жедезо без остановки процесса можно использовать наверное.
Distributed shared memory - это то, что из всего этого счастья реально может взлететь. Идея витает в воздухе уже очень долго.
Оно уже давно есть, называется NUMA. По очевидным причинам от этого больше гемора, как и от самой идеи SSI кластера, чем пользы.
Ты что-то путаешь. NUMA существует в пределах машины, а тут между несколькими машинами.На самом деле идея с DSM витала давно, и с ней экспериментировали. Всё упиралось в относительно медленную связность, но с появлением в массах серверных 40G и 100G интерфейсов идея DSM становится ближе к реальности - отсюда и новые эксперименты.
Воу, неужели спустя годы снова изобрели то, что уже было и прекрасно работало у дедов в OpenMosix, правда судя по тому что нужен особый компилятор, в каком-то урезанном игрушечном варианте.
Компилятор нужен для поддержки переезда процесса с железа на одной архитектуре (пускай x86) на железо на другой (пускай ARM)
В гомогенной среде особый компилятор не нужен.
https://www.opennet.me/openforum/vsluhforumID3/120533.html#42
Давно уже реализовано было - Amoeba OS Таненбаума и Ко.
Из новости не понятны ограничения технологии.
Явно ПО под эту вещь писать надо специальное.
Иначе не представляю как прозрачно для существующего ПО это может взлететь. Даже банальное обращение к файлам из разных потоков сломает это.
Именно в этом отличие от CRIU где миграция возможна для ПО которое не знает что его могут мигрировать.
Т.е. по факту это ядерная поддержка для всяких GRID.
Ну хорошо, это то чего не хватает Linux для реализации скайнета :)
> Из новости не понятны ограничения технологии.
> Явно ПО под эту вещь писать надо специальное.
> Иначе не представляю как прозрачно для существующего ПО это может взлететь.Да, это не прозрачный переход. Но если идея с DSM зайдёт даже в таком виде - в гипервизорах можно будет ждать уже прозрачной имплементации.
там, эта, эпл и гугл выпустили совместный интерфейс для остлеживания пользователей https://news.ycombinator.com/item?id=23073000
> Программный стек Popcorn образуют патчи к ядру Linux и библиотека с тестами, демонстрирующими как можно использовать системные вызовы Popcorn для миграции потоков в распределённо исполняемых приложениях.
> Applications, however, can rely on standard inter-process communication techniques, like shared memory, which works on multiple kernels operating on cache coherent kernels ,or message-passing on other hardware. For example, we used inter-kernel shared memory to provide a MPICH2 Nemesis channel for running MPI applications on Popcorn.http://popcornlinux.org/index.php/overview
1. Для миграции потоков необходимо переписывать прикладное ПО и линковать с их либой и это минус.
2. Сегодняшние ядра Linux, FreeBSD, OpenBSD непригодны для реализации виртуализации и кластера единого системного образа - используемая мат модель этого не предусматривает и не допускает.
3. Давным давно поддерживал сборник патчей для ядра Linux который мог:
* реализован прозрачний для всего ПО кластер единого системного образа. Узлы кластера могли подключатся/отключатся динамически. Миграция на узлы происходила когда ПО использовало fork (pthreds тоже можно добавить) причем учитывалась загрузка процессоров узлов и скорость сети. ПО пересобирать или переписывать не надо, стандартного вызова fork (pthreeds) необходимо и достаточно для миграции дочерного процесса на другой узел кластера.
* реализована защита от жестких збоев: содержимое оперативы, состояние всех процессов записывается в постоянную память, на диск, с возможностью восстановления работы ВСЕХ процессов к состоянию незадолго до момента збоя. Кластер легко проходил следующие испытание: выключалось и включалось питание отдельных узлов на которых исполнялся процесс мигрировавший с кластера, при загрузки ноды процесс продолжал исполнятся не замечая збоя в питании; отключалось питание всего кластера во время расчета, после включения расчет задачи продолжался не замечая збоя питания.
* все выше сказанное было сделано не в ущерб, а с максимальным усилением безопасности.
Не дам гарантии, что в этих версиях DYSTRYK все это реализовано идеальнл, но были версии которые успешно работали как SSI с защитой от сбоев и усиленной безопасностью. Грузите кластерное ядро om и подымите сервис mosix. https://mirror.yandex.ru/mirrors/ftp.linux.kiev.ua/Linux/CD/.../
>> Программный стек Popcorn образуют патчи к ядру Linux и библиотека с тестами, демонстрирующими как можно использовать системные вызовы Popcorn для миграции потоков в распределённо исполняемых приложениях.
> 1. Для миграции потоков необходимо переписывать прикладное ПО и линковать с их либойВнезапно. Естественно, такая фича не будет прозрачной.
> 2. Сегодняшние ядра Linux, FreeBSD, OpenBSD непригодны для реализации виртуализации и кластера
Если из этого списка удалить Linux, всё будет верно.
> 3. Давным давно поддерживал сборник патчей для ядра Linux который мог:Проблема моськи знаешь в чём? Это строго SSI. Никакой реальной кластеризацией софта там банально не пахнет, софт должен сам уметь в синхронизацию между своими процессами, обмен данными (через "классические" решения например) и т.п.
Это огромный плюс, что для миграции между нодами используются стандартные системные вызовы fork (pthreads). Именно это избавляет от потребности переписывать прикладное ПО. Все что умеет fork (pthreads) будет изкаробки, сразу, прозрачно работать в кластере SSI балансируя нагрузку между узлами!
> Это строго SSI. Никакой реальной кластеризацией софта там банально не пахнет, софт должен сам уметь в синхронизацию между своими процессами, обмен данными (через "классические" решения например) и т.п.Смотри DYSTRYK. В нем одновременно реализован SSI и MPI. Они друг другу совсем не мешают, а наоборот помогают. SSI дает один виртуальный компьютер с общим числом процов и оперативы в сети. MPI можно запускать не на физических компах, а сразу на виртуальных - кластерах SSI!
> Смотри DYSTRYK. В нем одновременно реализован SSI и MPI. Они друг другуИ много у тебя классического софта с MPI? Софт под это дело всё равно нужен специализированный. Понятно, что там грант хороший был, вот дистр на коленке и запилили, давай уж честно...
> И много у тебя классического софта с MPIequery h mpi
Понятно что только научные проги.
> Софт под это дело всё равно нужен специализированный.
Для нормального SSI не надо специализированного софта! Системных вызовов fork (pthreads) хватает. Дочирные процесс будут мигрировать на узлы кластера. Для обычного пользователя это архиваторы, кодировщик видео.
> Понятно, что там грант хороший был, вот дистр на коленке и запилили, давай уж честно...
Делал сам, для себя, в свободное время, без всяких президентских грандов.
Установку купили пару школ и один ВУЗ. Предприятия от кластерной реализации отказались, другую версию покупали.
> Понятно что только научные прогиНу ладно, здесь таки признал.
> Для нормального SSI не надо специализированного софта! Системных вызовов fork (pthreads) хватает.
Для этого вполне докера достаточно и микросервисов. Идея с миграцией бессмысленна без DSM, солнце закатывать (синхронизацию, обмен данными) иначе всё равно придётся костылить вручную.
> Ну ладно, здесь таки признал.MPI это довольно не тривиальный интерфейс параллельного программирования разработанный учеными для ученых. Понятно что нигде кроме науки не используется ибо для запуска MPI ПО надо MPI кластер, котрого дома нет.
Для домашних пользователей есть кучу других технологий: fork (pthreads), OpenMP, OpenCL,...
> Идея с миграцией бессмысленна.
Нет ты ошибаешься. Мигрировать может и вся задача. OpenMosix имел режим при котором на запускаемом узле вообще процесы не исполняются, все мигрирует на узлы, там исполняются и приходит только результат.
Ты путаешся в специализированном ПО для кластеров, где есть какая-то межпроцесная синхронизация.
SSI кластер это для жирных, тяжелых процессов которые целиком мигрируют на другой узел и возвращают результат. Примеры: архиватор, перекодировщик видео,... Они паралельно запускаются на нескольких узлах, а результат их работы собирается на одном. Более того в SSI кластере при загруженом проце, обычные процесы начинают мигрировать на другие узлы! И память у меня в SSI кластере синхронизируется идеально с максимальной защитой. Мой SSI кластер абсолютно прозрачен для ПО и пользователя, они видят общие число ядер в сети и общий объем оперативы, вся синхронизация скрыта от ПО под капотом OpenMosix.
> Нет ты ошибаешься. Мигрировать может и вся задача. OpenMosix имел режим при котором на запускаемом узле вообще процесы не исполняются, все мигрирует на узлы, там исполняютсяНу и зачем оно в таком виде?
Практика использования SSI показала, что быстрее всего задача считается когда запускаемый узел вообще не ведет расчет, а только занимается раскидыванием расчетов по другим узлам и сбором результатов.В те времена это вполне логично, компы однопроцессорные были, если ресурсы одного проца тратить на распределение работ, сбор результатов и еще при этом вести расчет то задача считалась заметно дольше!
> Делал сам, для себя, в свободное время, без всяких президентских грандов.
> Установку купили пару школ и один ВУЗ.Ну давай, признай уже, что были, может не президентские, но стимул эту бессмыслицу пилить должен быть :)
> Ну давай, признай уже, что были, может не президентские, но стимул эту бессмыслицу пилить должен быть :)SSI кластер это не бесмыслица, а пропущенный путь развития. Linux, FreeBSD, OpenBSD не в тот поворот свернули.
Разработка DYSTRYK никем, никогда не финансировать и велась мною в свободное время.
Хочу чтобы увидели один закон:
Если задачи ресурсоемки, а процессоры очень дорогие и маломощны - есть спрос на кластерные решения SSI.
Если ресурсоемких задач нет, а процессоры мощные и дешовые - спроса на кластера SSI не будет.
OS/2 тоже пропущенный путь развития. Нежизнеспособное отмирает.
Если вдруг станет вопрос необходимости SSI кластера, то отомрут Linux, FreeBSD, OpenBSD - которые свои ядра испоганили так, что добавить в них SSI кластер теперь очень сложно.
> Если вдруг станет вопрос необходимости SSI кластера, то отомрут Linux, FreeBSD, OpenBSDЕсли бы у бабушки был он, ну вы поняли...
Требование к вычислительным ресурсам будет расти до бесконечности, а вычислительная мощь проца когда-то упрется в потолок. Вот когда упрется, тогда и займутся ядром ОС с SSI кластером.
практически уже упёрлись - % выхода годных после eUV, а так же ситуация со всякими Spectre/Meltdown/RowHammer это наглядно демонстрируют.
По хорошему такое должно решаться на уровне гипервизиора. И да тот же z/VM в такое умеет.
> По хорошему такое должно решаться на уровне ...Нет детки, виртуализация и кластера единого системного образа решаются только в точке реализации ядром асинхронный работы на многопроцессорных системах.
Все зависит от выбранной матмодели ядра для асинхронной работы на много процессорных системах.
Сегодняшний Linux, FreeBSD, OpenBSD для виртуализации и кластера единого системного образа не подходят.
Только сферический дистрюк в вакууме )
Dragonfly BSD к этому идёт годами, практически в полтора рыла, и - если им здоровья хватит - таки придёт!
>збоясбоя
круто. Но openMOSIX, это было круче (такая болезненная потеря...)
https://www.opennet.me/openforum/vsluhforumID3/120533.html#42Надо было форкать ядро Linux! Мне сильно вредили, мешали и не хватило ресурсов...
Было бы не плохо если бы вы где-то рассказали поподробнее. Например на https://habr.ru/ если нет аккаунта то через песочницу. Плюсы, минусы, подводные камни, что помешало, что помогла, почему не взлетело.
> ПлюсыSSI, ..., там одни плюсы. К стати мою реализацию превзойти не смогли - она единственная прошла все тесты без ошибок и работала как надо.
У меня была идея:
* толстые бездисковые клиенты грузятся с сервака, отказоусойчевого кластера.
* толстые клиенты образуют SSI кластер
* толстые клиенты есть много местными (многоголовыми) системами.Железо для такой системы будет дешевле, а вычислительная мощь у конечных пользователей больше. Администрировать надо только сервак-кластер, а все рабочие станции как лампочки - включил и светит.
> минусы
Их нет. Трудозатраты на разработку SSI большие это за минус сойдет.
В РФ не захотели такой системы. Почему-то решили, что тонкие клиенты лучше и перспективнее чем толстые. И это не минус, а ошибка покупателя!
> подводные камни, что помешало
RedHat поменяли работу с памятью ядра, добавили cgroup, ... все это мешало openmosix. Можно сказать что плохому программисту всегда что-то мешает.. Просто я все видел по-другому. Не было ресурсов на разработку.
> что помогла,
Ускорение тяжелых задач! Для обычного пользователя это архивация, перекодировка видео. Для ученых много чего ускоряет...
> почему не взлетело.
Мы не думали что доживем до времени, когда в одном компе будет около сотни ядер и около сотни гиг оперативы.
Дешевле купить 1 проц IBM с 96 ядрами и сотню гиг оперативный ему, чем нанять того, кто напишет SSI кластер и купить 100 компов с 1 гигом оперативный + сеть.
Процессоры стали многоядерные и мощные, как следствие перспективнее оказалась противоположная задача, не объединение многих компов в один мощный, а разъединение одного на мелкие - виртуализация.
Очень напоминает общественное разделение труда в разных формациях,например: капитализм и социализм. Видимо это влияет.
Ахахах, как в том меме.
Так линукс теперь может работать с 4086 ядер!
Так а там реализовали нормальный просмотр видео в браузере?
Нет
Да что там видео, теперь даже джаваскрипт не тормозит.
> Так линукс теперь может работать с 4086 ядер!
> Так а там реализовали нормальный просмотр видео в браузере?Да, теперь декодировка видео в бровзере нормально параллелится аж на 4086 ядерах! ;)
А в windows юзается аппаратная деодировка. А если нету поддержки как допустим у меня с vp9, то как то юзают 3d шейдеры. Походу direct3d можно юзать как рендер
InfernoOS ?
она просто может быть распределенной, как план9, но разве может выполняться на разных хостах?
Надо такое же, только over web
вот есть у меня сервер который слушает порт 55555 и что они этот же порт на удаленной машине откроют и туда его перенесут?
Живую миграцию кто только не делает. Тут же они туда перенесут сначала процесс, а потом если надо вернут результат. По протоколу TCP.
"Политехнический университет Виргинии" ===> "Вирджиния Тех (Политехнический университет Виргинии)"
Его никто кроме как "Вирджиния Тех" не называет.
ТЕХ САМЫХ??
"Virginia Tech" - any prononciation are welcome.
>Для использования Popcorn в гетерогенных окружениях необходимо использовать специальный компилятор на основе LLVM.Без GCC не нужно!