Pull to refresh

Comments 25

Думаю, в это направление хорошо вписывается Erlang
Возможно. Но из всего, что я знал об Erlang'е, мне запомнилось лишь то, что на нем писались прошивки для Ericsson'ов. И вроде бы ejabberd. Так что, ИМХО, этот язык — эндемик, тогда как вышеупомянутые весьма на слуху и в ходу.
UFO just landed and posted this here
Насколько я знаю, переписывают критические участки кода для оптимизации.
Так он эндемик именно потому, что ниша параллельных/распределённых вычислений весьма узка.
Просмотрите описание — в Эрланге уже по сути реализованы именно туманные вычисления.
Только на практике все капли находятся в пределах одного устройства.
Я же не зря помянул OpenMosix — там распараллеливание инфраструктурно. Т.е. параллелизм должен быть не в языке, а в инфраструктуре.

Шейдерная модель «ядро+поток» хорошо параллелится. Массив «капель» может выступать как vGPU (вспомним Larrabee), или многоядерник, если приложение тупо многопоточное. Так что не так уж и узка.
В erlang уже давно есть готовые модули для таких вещей, как самоорганизация одноранговых сетей, выбор лидера группы, подключение и удаление узлов сети и т.п. В саму основу языка заложены масштабируемость и стойкость к потерям узлов или данных.
Также есть европейский проект по созданию самоорганизующейся облачной ОС, основанной на linux и erlang.

А вот openMosix был довольно специфичной ОС, т.к. не поддерживал shared memory ни в каком виде.
По звучанию ещё Gosler неплохо так подходит…
А не является ли по сути тот же проект SETI@home по поиску сигналов от внеземных цивилизаций образцом «туманных вычислений»?
Есть большое кол-во компьютеров-узлов, не всегда доступных, выполняющих в моменты неактивности (запуска скринсэйвера) вычисления, и собирающих в одном месте в итоге.
Вроде как и похоже, поправьте если я понял неправильно.
SETI — это типичный грид. «Туманность» подразумевает наличие большого (около десятка) типовых узлов в локальном пространстве, и добавляет прозрачную миграцию нитей (threads) и хотплаг. ИМХО. Возможны даже некие «бродячие» программы-агенты, сходные с сетевыми червями по природе: в случае чего сериализуется и «переползает» и/или «реплицируется» на соседние узлы.
По-моему, это должно быть не «возможно», а основная штатная функция гипервизора, поскольку любая «капля» может отключится или выйти из зоны действия сети внезапно и без уведомлений. А на гостевые капли (про которые гипервизор или его распределенный аналог не может сказать, что они бесперебойно работают долгое время в его сети) процессы могут изначально дублироваться в надежде что хоть один до конца доработает и вернёт результат. Сериализация тут, по-моему, не очень уместна, скорее декомпозиция основной задачи на несколько элементарных подзадач, которые можно выполнять параллельно и асинхронно и довольно быстро (миллисекунды), чтобы необходимость пересчитать что-то заново из-за умершей капли не была заметна пользователю.

В общем видится как-то так: Узел, которому нужны внешние вычислительные ресурсы кричит (широковещательное сообщение) что-то вроде «нужен результат функции такой-то с такими параметрами, кто может посчитать?». Свободные узлы отвечают «Я, я, я, я...». Некоторые могут добавить «эта функция у меня уже в памяти», а какие-то вообще «Уже есть закешированный результат для этих параметров, вот он». Инициирующий узел выбирает те, что «поближе» (пинг) и понадежнее/побыстрее (из истории предыдущих обменов) и поручает им вычисление. Если за разумное время ответа не получено (или исполнительный узел не пингуется), то сеть опрашивается заново.
В чем-то соглашусь, а в чем-то и нет с автором. Я вижу начало fog computing в расшаривании через PAN и SR-RF сети лишних ресурсов от устройств, питающихся от сети общего пользования (220В). Сейчас для большинства беспроводных устройств проблема в питании. Есть неплохие аккумуляторы, но их нужно заряжать. Количество устройств, требующих регулярной подзарядки катострофически растет. Для экономии заряда батарей на вычисления можно «выгрузить» ресурсы с телефона на телевизор, утюг, холодильник, вытяжку, чайник. Все равно там есть какие-то полупроводники. Стоимость их изготовления не сильно вырастет, если добавить в них небольшой SoC, который будет шариться через какой-то ZigBee-подобную сеть.

ЗЫ. Рад, что моя тема получила развитие :)
А я рад, что благодаря ей смог попасть на Хабр. Это моя четвертая попытка :)

Вот, имхо, SoC должен быть достаточно мощным, чтобы и выполнять штатные функции, и иметь мощности для офф-лоада
И почему все забывают о таком штуке как алгоритмы? Сколько процентов софта сейчас поддерживает 2хядерные процессоры? и это в 2012году то… а запускать что-то на каплях будет еще веселее…
Вот-вот. Замечательный есть вопрос: что такого полезного можно запускать на каплях?
А что, мало многопоточных и ресурсоемких приложений? Фотошоп вон, запустите, или агенты рендеринга 3DS MAX. Базу данных — причем в таком окружении будет хороша DHT. Три килограмма серверов — это серьезно.
Таким образом ваша «капля» должна быть достаточно мощным устройством. И еще: если вы считаете что в таком микро-исполнении (сотни в банке) удастся создать достаточно мощные устройства, то что может мешать сосредоточить эту мощь в одном традиционном устройстве (сотни ядер процессора например)? Мощность та же, исполнение на порядок проще на мой взгляд.

Если же под облачными вычислениями вы понимаете использование незадействованных ресурсов любых устройств, то здесь во весь рост встает проблема скорости взаимодействия и получения результата вычичсления. Такой подход может подойти для долгоиграющих, не интерактивных, задач по типу SETI или брутфорс или свертка белков. Но здесь возникает другая проблема — как мотивировать владельца устройства?
На последний вопрос пока есть только такая идея: Снизить стоимость устройства или ОС на стоимость вычислений за достаточно длительный период. Т.е. грубо говоря смартфон стоит на 10 баксов дешевле, подразумевая что в нем запущен неотключаемый агент выполняющий по заказу вендора определенные вычисления.
Давайте я попробую ответить?
Да, «капля» — достаточно мощное и автономное устройство, фактически миниатюрный сетевой компьютер. Сейчас сложно сказать — вытеснят ли «туманные» решения классические десктопы, смартфоны, или будут сосуществовать.
Простота в виде многоядерника-десктопа на самом деле тоже спорна — то же самое практически, но в макромасштабе, сложнее масштабировать и обновлять: то ли засыпать в баночку новые «капли», то ли менять материнскую плату, процессор и память.

При туманных вычислениях именно что вопрос скорости не встает — это локализованная PAN по большей части, а удаленные сегменты есть смысл задействовать как в SETI. С консолидирующим ПО и некоторыми программными ухищрениями, такая сеть может на лету перестраиваться: часть капель работают как CPU, часть как GPU, часть как криптоускоритель — а поверх этого функционирует вполне стандартная ОС, загрузка которой инициируется с единственной пользовательской капли.

В принципе мотивация предусмотрена уже ценой и заложенной в решение масштабируемостью — вставил кубик «капли» — нарастил мощность. Апгрейд в любое время. Уверенность в совместимости.
Хром с его концепцией «одна вкладка — один процесс» :)
Локализаторы Кенг Хо из «Глубины в небе» — вот 100% ваша идея :)
Вернор Виндж? Надо будет осилить раз так…
В вашем будущем слишком много проводов и лишних интерфейсов. Скорее будет один универсальный Wireless USB, нежели то, что Вы описали.
WUSB не панацея, от проводников для питания, и внутри кристалла никуда не деться, а в ряде случаев провод проще и дешевле. Так что какие-то провода безусловно будут, но их будет меньше, чем сейчас.
Sign up to leave a comment.

Articles