Комментарии 37
Кr'айне интеr'есно! Ждём-с пr'одолжения с самым интеr'есным :)
Очень хотелось бы послушать про реализацию (в том числе и про распараллеливание) циклов в потоковых системах…
Я получил инвайт 2 года назад за похожий пост. У вас намного развернутее.
Было бы интересно узнать про сравнительную производительность Dataflow и Controlflow систем.
Их очень сложно сравнивать, поскольку одни задачи хорошо идут на dataflow и плохо на controlflow, а другие — наоборот. В своих статьях разработчики стремятся выбрать тесты, которые по максимуму используют преимущества их системы. Получаются вот такие красивые, но малообъективные картинки:
(Взято отсюда)
(Взято отсюда)
случаем Дикарев Н.И. Вам не знаком?
НЛО прилетело и опубликовало эту надпись здесь
Что то мне подсказывает, что dataflow лучше подходит для создания систем ИИ. А есть ли какие-то эмуляторы этой системы на ПК или специализированные языки программирования, чтобы вот прям взять сейчас и попробовать? Было бы интересно посмотреть на конкретные примеры программ. В общем жду следующую статью.
Разным людям на протяжении полувека что-то подсказывало, что для создания систем ИИ подходит то одно, то другое, то Lisp, то Prolog, то ещё что-то. Но вот ИИ за это время так и не родился. Может, дело не в инструментах? А в алгоритмах? Или даже в осознании того, чем является собой «интеллект».
Лично мне подсказывает то соображение, что стандартная модель выполнения программ может не очень для этого подходить. Данные в такой системе нужно организовывать как то по другому. На уровне каких-то образов, где данные перемешаны с методами. И вот описание dataflow сильно напоминает что-то такое.
Данные перемешаны с методами — это очень напоминает язык MUMPS используется в СУБД Cache (к примеру). По правде сказать — принципиальных отличий в организации самих данных там нет. Поэтому для ИИ — сам факт микса данных и методов, может не многое дать.
Ничего себе, MUMPS вспомнили! Я между прочим как раз занимаюсь поддержкой одного сервера на базе Cache. Но там на самом деле данные четко отделены от методов, так что я не совсем понимаю, что вы имеете ввиду. Текстовые строки можно интерпретировать как команды на лету, да. Но эта фича является скорее опасной, чем полезной.
Мампс я не вспомнил — а седьмой год на нём программирую. Если данные в каше чётко отделены от методов — то это означает что скорее всего данные хранятся в SQL или (тяжёлый случай) в объектах. Однако отделение их от методов только логическое — физически и SQL-таблицы и объякты и программы — хранятся в глобалах (полезное свойство кстати, если удалите какую-то программу или измените её а в гите или другой системе контроля версий ничего не сохраните — всегда есть возможность посмотреть несколько старых версий программы в глобале). Я не говорю уже о более интересной реализации когда правила, которые являются либо методами, либо вызовом подпрограмм, записываются в глобалы как правила, и выполняются в зависимости от контекста. Естественно и здесь, присутствует разделение на данные и методы, но это разделение уже определяется именно вами, как разработчиком, и границы становятся очень размытыми. Да безопасность необходимо обеспечивать самому. Что бы увидеть где хранятся программы кликните в портале управления -> глобалы (радиобаттон базы данных) выберите вашу БД, и поставьте чек бокс «Система» — неоткомпилированные программы хранятся в глобале ^rMAC к этому глобалу вы можете сами обратится — то есть по сути писать код для каше можно и без студии (но это для любителей экзотики)… вообщем много интересного обнаружите — нулевая версия — это текущаяя — 1я версия самая старая и т.д.
Просто я не ожидал встретить человека, который связан с этой СУБД. О каше так редко говорят, что кажется, будто ее вообще не существует.
Я изучал язык давно, еще когда у нас стояла не Cache а MSM под дос (там программы вообще редко когда компилировались как это делается сейчас в студии), и я не разработчик, хотя в коде немного разбираюсь и пограммы писать приходилось. А сейчас даже не знаю куда развивается эта технология. Наша система собирает аэронавигационную информацию и работает на достаточно старом дистрибутиве, но данные хранятся в глобалях с их нереляционной организацией.
А можете подробнее рассказать про правила (или ссылку дать)? А то я не совсем понимаю, что имеется ввиду.
То, что вы посоветовали посмотреть, я гляну когда буду на работе — не знал, что версии хранятся.
Я изучал язык давно, еще когда у нас стояла не Cache а MSM под дос (там программы вообще редко когда компилировались как это делается сейчас в студии), и я не разработчик, хотя в коде немного разбираюсь и пограммы писать приходилось. А сейчас даже не знаю куда развивается эта технология. Наша система собирает аэронавигационную информацию и работает на достаточно старом дистрибутиве, но данные хранятся в глобалях с их нереляционной организацией.
А можете подробнее рассказать про правила (или ссылку дать)? А то я не совсем понимаю, что имеется ввиду.
То, что вы посоветовали посмотреть, я гляну когда буду на работе — не знал, что версии хранятся.
Хранение версий регулируется настройками самой системы, которые кстати тоже хранятся в глобалах, а если у вас старый дистрибутив, то там вполне эти настройки могут либо отсутствовать либо хранится только свежая, нулевая версия (но она должна быть в любом случае). Рассказать про правила, в комментарии вряд ли получится, планировал по этому поводу статью написать, но процесс этот длительный. Два года назад запостил habrahabr.ru/blogs/personal/59380/ однако сейчас она сильно устарела, хотя код описанный в ней всё ещё используется. В двух словах рабочий кусок кода обрабатывающий задачу:
processingTask(priority,task)private s $zt=«errTask» new t s t(«i»)="" f { s t(«i»)=$o($$$iRule(«Task»,ontology,type,action,t(«i»))) q:t(«i»)=""
s t(«cmd»)=$g($$$iRule(«Task»,ontology,type,action,t(«i»)),"") x:t(«cmd»)'="" t(«cmd») } g endTask
где в глобале $$$iRule описан определённый набор действий, для конкретного типа заданной онтологии указанного action — этот набор действий может быть простым вызовм программы «d program^program» а может быть просто куском кода, в котором реализуется определённый функционал, однако в самом глобале правил $$$iRule — можно хранить очень многое — от количества процессов обрабатывающих задачи определённого приоритета — до перечня полей структур бизнес-данных… Но основная идея заимствуется у разработчиков каше — все хранить в данных, где нельзя использовать глобал — используется файл.
s t(«cmd»)=$g($$$iRule(«Task»,ontology,type,action,t(«i»)),"") x:t(«cmd»)'="" t(«cmd») } g endTask
где в глобале $$$iRule описан определённый набор действий, для конкретного типа заданной онтологии указанного action — этот набор действий может быть простым вызовм программы «d program^program» а может быть просто куском кода, в котором реализуется определённый функционал, однако в самом глобале правил $$$iRule — можно хранить очень многое — от количества процессов обрабатывающих задачи определённого приоритета — до перечня полей структур бизнес-данных… Но основная идея заимствуется у разработчиков каше — все хранить в данных, где нельзя использовать глобал — используется файл.
да ещё посмотрите в глобал ^rMACSAVE может быть интересно…
А если не секретно — то было бы очень интересно взглянуть на реализацию структуры данных вашей системы, пусть и старой — потому что честно сказать, кроме как на своей работе — вживую никогда не видел человеку разрабатывающего под каше. Да и здесь таких немного.
А если не секретно — то было бы очень интересно взглянуть на реализацию структуры данных вашей системы, пусть и старой — потому что честно сказать, кроме как на своей работе — вживую никогда не видел человеку разрабатывающего под каше. Да и здесь таких немного.
ИИ не родился, но зато мы получили Lisp и Prolog.
«Зачастую средства оправдывают цель: цель продвигает технологию, а технология выживает даже если цели не достигаются». (Алан Дж. Перлис)
«Зачастую средства оправдывают цель: цель продвигает технологию, а технология выживает даже если цели не достигаются». (Алан Дж. Перлис)
Лет 7 назад в университете делал что-то очень похожее на Delphi (программную реализацию, конечно, не в железе). Хотел реализовать визуальную сборку схемы вычислений в программе из функциональных модулей. Слыхом не слыхивал про тему этого топика, но программу назвал Dataflow :)
Тогда, увы, толком не доделал (переоценил свои силы), но после текущего проекта собирался реализовать еще раз, на этот раз применительно к вебу. И как раз распараллеливание считаю очень полезным качеством этой схемы, потому что можно реализовать в облаке с отличной масштабируемостью. Было не очень понятно как реализовать параллельную обработку запросов, теперь ясно, почему, надо бы поковырять преимущества и недостатки, пока свои шишки не набил )
Тогда, увы, толком не доделал (переоценил свои силы), но после текущего проекта собирался реализовать еще раз, на этот раз применительно к вебу. И как раз распараллеливание считаю очень полезным качеством этой схемы, потому что можно реализовать в облаке с отличной масштабируемостью. Было не очень понятно как реализовать параллельную обработку запросов, теперь ясно, почему, надо бы поковырять преимущества и недостатки, пока свои шишки не набил )
Мне кажется в коммутаторе собака зарыта.
А ещё мне кажется что это чем-то похоже на систолические матричные структуры, но пока не пойму чем?
(Что-то мне сильно много кажется.)
(Что-то мне сильно много кажется.)
На схеме 1 с графом вычислений ошибка в 3-ем слое. Операция вычитания не ассоциативная, нужно указать порядок операндов. Так возникает неверное представление о ходе вычислений
Исправлено. Для некоммутативных узлов первый операнд слева, а второй — справа.
Спасибо. Однако будет понятней, если операцию вычитания заменить на отрицание + сложение. Тогда неопределенность будет устранена полностью
Рисунок еще раз переделывать уже не буду, т.к. это всего лишь иллюстрация принципа. А вообще вы правы, и дело тут даже не в понятности. В dataflow системах стремятся избегать узлов с некоммутативными входами, так как появляется задача научить систему отличать «левый» операнд от «правого»: добавляются лишние поля в контекст, усложняется устройство сопоставления… Зачем нам лишние проблемы, проще заменить вычитание умножением на (-1) и сложением.
Меня умиляет, когда материал из университетских лекций постят на хабре.
На картинке ката изображен коммутатор? Я угадал?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Dataflow-архитектуры. Часть 1