Комментарии 9
Ничего не понял, но... внушает! :-D
Можно более подробно тему раскрыть?
Но что самое занятное, всё это очень тесно связано с функциональным программированием и математикологическими предложениями Хорна.
Очень интересно - более подробно разверните мысль
А причем тут пролог и хаскел? :)
Пролог при том, что вылезают предложения Хорна, на которых он построен. А Хаскелл при том, что функции и редукция графов. Простейший пример. Пишем мы
gcc foo.c -o bar
На это можно посмотреть, как на
1. Логический вывод: существует утверждение gcc, утверждение foo.c из которых можно получить вывод - bar. Вобщем-то давно известно, что программы соответствуют выводам в интуиционистской логике. http://en.wikipedia.org/wiki/Curry%E2%80…
Это, конечно, не поиск наименьшего общего унификатора, но Пролог немного задевает. Хотя, наверное и не так сильно, чтобы выносить это в ключевые слова : ).
2. Вызов функции bar - получение этого значения при помощи применения функции gcc к функции-константе (хотя и не обязательно совсем) foo.c
3. Обычные операции с именованными данными: загрузить программу gcc, заставить её загрузить файл foo.c и выдать файл bar
Всё описывается одинаковой абстрактной схемой: gcc, foo.c -> bar. А подобные схемы исполнять параллельно очень удобно. Параллельные haskell'ы так делают. Или, например, make на это способен. Параллельная редукция lambda-графа, или графа зависимостей. Но это можно описывать не только в виде таких вот возвышенных материй, но и в виде операций с файлами:
for ((i = 0; i < 20; i = i + 1)); do gcc foo$i.c -o bar$i & pids[$i]=$!; done
for ((i = 0; i < 20; i = i + 1)); do wait pids[$i]; done
Граф потоков данных описывается на языке зависимости файлов (на самом деле достаточно говорить просто об именах файлов. имена могут содержать и некоторую версию) друг от друга. Ну, на shell для этого нужен wait для процессов, которые формируют файлы, или использовать какую-нибудь самопальную следилку, работающую через inotify.
В специально заточенной системе нужна файловая система, которая хранит эти файлы по возможности в памяти, позволяет отслеживать создание новых файлов, следит за уникальностью их имён (вобщем ничем особо экстраординарным по сравнению с обычной fs не занимается), чтобы потом можно было вычисления по мере готовности данных запускать. Программку запустили, выдали ей набор файлов для чтения, указали, куда результаты положить, результаты же потом можно использовать в других процессах - всё просто, привычно скриптуется и так далее. Остаётся только эффективности добится в доступе к самим данным, но тут ничего принципиально сложного, кажется, не возникает.
Сравнение с логикой: как только доказано, что a, b, c, d (сформированы соответствующие файлы) в утверждении a, b, c, d -> e, можно считать доказанным e (запросто формировать e). Поиск же доказательства или модели, удовлетворяющей аксиомам можно осуществлять параллельно. При этом очень даже совсем неплохо параллельно - тысячи математиков примерно этим заняты. Так почему бы эти конструкции вида a1, ..., an -> b1, ..., bn - предложения Хорна - из логики не использовать в описании алгоритмов, если ко всему прочему доказано, что они Тьюринг-полные?
Сравнение с функциональным программированием: речь идёт о банальном ленивом вычислении значения. Только не на уровне базовых конструкций функциональных языков, а на уровне файлов с произвольным содержимым. Haskell, как shell : ) Никто ещё не пробовал?
Вот. При этом всём файлы достаточно удобны при числодробительных вычислениях - это некие куски данных с произвольным доступом. Как раз то, что нужно чтобы матрицы умножать. Гораздо удобнее списков или небезопасных массивов из мира функциональных языков. Да и просто привычнее.
Ещё. Эти штуки сложно описать с использованием понятия 'переменная'. Но понятие 'переменная' достаточно просто выражается через понятие именованных данных (не областей памяти, привязанных к железяке, а именно просто данных) - как последовательность значений. Кроме того, 'переменная' вообще плохо параллелится, потому как это именованная ячейка и к ней нужно доступ синхронизировать, или копировать их, чтобы конфликты разруливать.
Вобщем примерно всё вот так. Подробнее, конечно, надо. Но времени нет : (
gcc foo.c -o bar
На это можно посмотреть, как на
1. Логический вывод: существует утверждение gcc, утверждение foo.c из которых можно получить вывод - bar. Вобщем-то давно известно, что программы соответствуют выводам в интуиционистской логике. http://en.wikipedia.org/wiki/Curry%E2%80…
Это, конечно, не поиск наименьшего общего унификатора, но Пролог немного задевает. Хотя, наверное и не так сильно, чтобы выносить это в ключевые слова : ).
2. Вызов функции bar - получение этого значения при помощи применения функции gcc к функции-константе (хотя и не обязательно совсем) foo.c
3. Обычные операции с именованными данными: загрузить программу gcc, заставить её загрузить файл foo.c и выдать файл bar
Всё описывается одинаковой абстрактной схемой: gcc, foo.c -> bar. А подобные схемы исполнять параллельно очень удобно. Параллельные haskell'ы так делают. Или, например, make на это способен. Параллельная редукция lambda-графа, или графа зависимостей. Но это можно описывать не только в виде таких вот возвышенных материй, но и в виде операций с файлами:
for ((i = 0; i < 20; i = i + 1)); do gcc foo$i.c -o bar$i & pids[$i]=$!; done
for ((i = 0; i < 20; i = i + 1)); do wait pids[$i]; done
Граф потоков данных описывается на языке зависимости файлов (на самом деле достаточно говорить просто об именах файлов. имена могут содержать и некоторую версию) друг от друга. Ну, на shell для этого нужен wait для процессов, которые формируют файлы, или использовать какую-нибудь самопальную следилку, работающую через inotify.
В специально заточенной системе нужна файловая система, которая хранит эти файлы по возможности в памяти, позволяет отслеживать создание новых файлов, следит за уникальностью их имён (вобщем ничем особо экстраординарным по сравнению с обычной fs не занимается), чтобы потом можно было вычисления по мере готовности данных запускать. Программку запустили, выдали ей набор файлов для чтения, указали, куда результаты положить, результаты же потом можно использовать в других процессах - всё просто, привычно скриптуется и так далее. Остаётся только эффективности добится в доступе к самим данным, но тут ничего принципиально сложного, кажется, не возникает.
Сравнение с логикой: как только доказано, что a, b, c, d (сформированы соответствующие файлы) в утверждении a, b, c, d -> e, можно считать доказанным e (запросто формировать e). Поиск же доказательства или модели, удовлетворяющей аксиомам можно осуществлять параллельно. При этом очень даже совсем неплохо параллельно - тысячи математиков примерно этим заняты. Так почему бы эти конструкции вида a1, ..., an -> b1, ..., bn - предложения Хорна - из логики не использовать в описании алгоритмов, если ко всему прочему доказано, что они Тьюринг-полные?
Сравнение с функциональным программированием: речь идёт о банальном ленивом вычислении значения. Только не на уровне базовых конструкций функциональных языков, а на уровне файлов с произвольным содержимым. Haskell, как shell : ) Никто ещё не пробовал?
Вот. При этом всём файлы достаточно удобны при числодробительных вычислениях - это некие куски данных с произвольным доступом. Как раз то, что нужно чтобы матрицы умножать. Гораздо удобнее списков или небезопасных массивов из мира функциональных языков. Да и просто привычнее.
Ещё. Эти штуки сложно описать с использованием понятия 'переменная'. Но понятие 'переменная' достаточно просто выражается через понятие именованных данных (не областей памяти, привязанных к железяке, а именно просто данных) - как последовательность значений. Кроме того, 'переменная' вообще плохо параллелится, потому как это именованная ячейка и к ней нужно доступ синхронизировать, или копировать их, чтобы конфликты разруливать.
Вобщем примерно всё вот так. Подробнее, конечно, надо. Но времени нет : (
Но, на самом деле, все эти слова про Пролог и Хаскелл - мелочи, чтобы присобачить текст статьи к именам великих, ибо так надо, а не потому что хочется. Главная же мысль в том, что нужна просто файловая система. И что файлы, как инструмент, гораздо удобнее, чем сообщения, например. И что это удобство привязано к некому фундаменту, который уходит в способ рационального мышления и решания задач.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
вот тебе бабушка и plan9, prolog и haskell.