Switch lang: Русский \ English

Понятное "ИТ-шникам" описание идеи.

    когда кажется, что все так складно и ладно. Ты спрашиваешь: “И почему же раньше никто не додумался до этого?” хм. - А на самом деле, чтобы так было, кто -то сильно постарался подумать. В любой простоте очень много труда. Павлом М.А. 20130611

    Здесь я описал суть и перспективы развития технологии в вопросах и ответах.

    Давайте сходу поговорим о транзакциях и раскроем весь их потенциал.

    Сегодня в SaaS web и Science мире почти любой софт использует большие и малые транзакции и объектный или функциональный подход.

    Что из себя представляет транзакция ? Что может получиться если подойти к этом вопросу серьёзно?

    Большая распределенная транзакция Работает с:

    1. оперативная информация; Временная информация;
    2. объектами и классами; изменения, которые сохранятся в системе; после применения транзакции.

    после завершения вычисления не нужна;

    Оперативная работа

    • создание и вычисление значений
    • создание и работа с временными объектами, которые после использования не нужны
    • поиск объектов и различные фильтры

    Работа с объектами и классами

    • найти объект по определенным критериям
    • прочитать версию объекта,
    • записать новую версию объекта
    • создать объект по образцу
    • и другое

    (здесь под объектом понимается ячейка данных или структура из этих ячеек - например ассоциативный массив)

    Параллельность - это было исходным требованием ко всей системе.

    Объекты ООП кроме данных имеют методы - это некие действия (функции), которые могут работать с другими объектами и прочими состояниями.

    Хочется уметь выполнять эти действия как можно быстрее, иметь большую степень параллелизма, использовать все ресурсы эффективно, если этого требует ситуация.

    Вопрос: как представить эти вычисления и действия, чтобы обеспечить максимальную масштабируемость ? на каком языке это сделать ? масса вопросов, как сделать так, чтобы люди готовы были за это заплатить ? как сделать так, чтобы это было доступно технологически ? итд...

    Ответ. Методы - суть функции, но вопреки традиционному понимаю функций мы не дадим им стэк. Стэк - суть цепочка контекстов. Нам же для параллельной работы цепочка сама по себе не нужна, нам нужно дерево контекстов.
    Это называют в некоторых параллельных языках “кактус-стэком”. Функция - суть “решальщик” (solver) простой задачи, и это решение не выходит за рамки контекста этой функции. Часто функции имеют массу промежуточных данных на стеке для того, чтобы найти/выразить результат. Итак, нам нужен способ составить нужное нам дерево из контекстов так, чтобы задачи в каждом из контекстов могли решить нашу общую проблему (выполнить метод, например). Важно понимать, что существование самого контекста - это предположение и абстракция мозга. Контекст состоит из отношений объектов - фактов, которые мозг группирует по областям видимости или ещё по каким - то критериям. Частями контекста являются, собственно, значения которые относятся к разным исполнителям и иногда имеют общий доступ - замыкания.

    Мы решили описывать все в виде маленьких “зависимых” действий. И как раз в поиске этих зависимостей и состоит вся сложность обычно.

    Если мы выразим все действие функции от начала до конца как массу задач, то получим ещё один вопрос:

    Ещё один вопрос: обычно программист сам контролирует последовательность действий. Если большая часть действий выполняется последовательно, то делать это относительно просто, однако и тут есть предел.

    Итак вопрос: если же все действия запустить одновременно, что мы получим ?

    третий вопрос: надо ли запускать все действия одновременно, или имеют право на жизнь варианты:

    • запустить все действия одновременно?;
    • запустить действия согласно зависимостям?;
    • запустить ли их, если они сами управляют процессом запуска?;
    • обмануть их, сказав, что запустил, а на самом деле «лениться» и выполнять только то, что требуется;
    • прямо выполнять операции, которые в них написаны так, как это подразумевается;
    • вместо выполнения самой операции создавать функцию, которая могла бы это делать, и возвращать эту функцию в качестве результата, тем самым строить ответ из систем функций, параметров, инвариантов и других данных;
    • ещё масса всего есть, например, строить не систему функций, а систему процессов, которые, общаясь, выдают (могут выдать) результат;
    • строить программу на неком языке для поиска ответа;
    • строить структуру данных для некой функции или их системы, чтобы потом, сделав свёртку этой структуры, получить результат... (морфизмы)

    Вариантов очень много. Они отличаются производительностью, потребностями в ресурсах, и выбор, очевидно, зависит от данных с которыми работает система.

    Ответы: Очевидно, что все это хочется. и хочется иметь возможность выбора. Обратите внимание, этот выбор относится скорее к системе исполнения нежели к самому проекту и тому, что мы хотим описать в нем.

    Как бы мы не желали исполнять общее решение (множество действий) и чтобы мы не выбрали - нужна некая система, которая позволит как-то из множества зависимых действий получить такую последовательность их запуска, такой способ, который бы не приводил к проблемам и ошибкам.

    Нужен способ развязать зависимости между зависимыми действиями, чтобы в итоге получить правильный результат. Нужен способ внешнего контроля, который исключит саму возможность ошибки.

    Требования: Этот способ должен иметь полный доступ к данным, с которыми работают действия. Знать их структуру и историю операций над ними. Этот способ должен уметь исправить ошибки, если они обнаружатся в процессе работы. Кроме того, этот способ напрямую связан со способом исполнения системы действий.

    Вопросы:

    • В каком месте системы должен находится этот способ контроля зависимостей ?
    • В каком месте должны хранится данные с которыми система работает ?
    • Как обеспечить исправление ошибок ?

    Ответы:

    Очевидно, что этот способ - часть рантайма исполнительной системы.

    Чаще всего сегодня языки исполняются в виртуальной машине.

    Значит, очевидно - это часть виртуальной машины. (не обязательно, но в виде VM это проще реализовать).

    Виртуальная машина работает с данными в своих внутренних структурах - значит данные, с которыми система работает, должны быть внутри виртуальной машины.

    Об ошибках: обеспечить контроль над ошибками можно. Типовой приём: откатить транзакцию, если ошибка или если транзакцию не удалось полностью применить. Замечание: мы говорим о системе действий, это множество маленьких действий, и в этом множестве существует их взаимо-подчинённость. Действия можно кластеризовать в иерархические группы.

    Важная мысль: откат всей транзакции целиком - это только лишь защита стабильной части системы от нестабильной. Это не даёт нам возможности исправить ошибку. Вот если бы мы откатили изменения, сделанные одним конкретным действием, которое выполнилось раньше положенного ему срока и поэтому привело к конфликту доступа - то мы бы могли учесть обнаруженную зависимость в дальнейшем между этими действиями и перезапустить откаченные действия в правильном порядке. (это обратная связь от транзакционного механизма, которая подразумевает управление им же)

    Допустим, нам известна часть зависимостей между действиями, т.к. мы проанализировали исходный код, но таким образом не найти всех зависимостей, для всех языков этого не сделать. Это неподъемная задача, её решают с начала времён, и до сих пор нет нормального решения.

    Если бы среда исполнения помогала находить их в процессе работы программы - это бы постепенно привело к отсутствию конфликтов доступа, и все зависимости стали бы известны. (более того : стали бы известны вероятности конфликта при параллельном запуске действий) - для этого система должна их копить и обучаться на них.

    Выводы:

    1. получается, что вся система исполнения (виртуальная машина) должна быть пронизана системой иерархических транзакций, которая бы искала зависимости при доступе к данным из разных действий, и при обнаружении могла бы переупорядочивать действия, перезапускать их. Мы это делаем при помощи TVM

    2. в данной виртуальной машине должна быть часть, ответственная за управление способом исполнения действий. Э то некая настраиваемая стратегия, управляющая специальным механизмом запуска действий.

    3. если мы говорим, что действие осуществляется в неком контексте определённой функцией, которую, кстати, можно перезапустить, например, из-за того, что прошлые её действия были откачены системой, то, вообще говоря, не важно, на чем эта функция написана,
      главное - она должна работать с контекстом и с системой и не должна иметь побочных эффектов (типа собственных файлов и состояний, кроме служебных, не влияющих на результат), либо таких, которые могут быть откачены без последствий.

    4. данная виртуальная машина не решает, как действие будет исполняться, она управляет зависимостями и мета-информацией о них для того, чтобы разбить большие задачи на более маленькие. Это автомат, управляющий процессом декомпозиции и устранением зависимостей между действиями в рантайме. Таким образом, нельзя сказать, что это виртуальная машина в привычном понимании.

    5. действия и функции, которые могут работать с данной системой, могут использовать любую традиционную VM, т.е. традиционная VM для системы - это более низкий слой, а система над ними всеми.

    6. ни одна привычная VM не работает с транзакциями так тесно. И уж тем более они не входят в список терминов обязательных для типовой VM. Но для нашей системы транзакция - обыкновенная необходимая вещь (кстати, с её помощью можно элегантно убрать из обихода исключения или элегантно ими воспользоваться - здесь возможен полезный симбиоз).

    7. то, что транзакция у нас встроена в VM, и то, что мы внутри VM работаем с данными, позволяет нам просто воспользоваться этим и легко превратить данную VM ещё и в хранилище данных.

    8. если мы превращаем VM ещё и в хранилище, почему бы не сделать его опционально распределенным?
      И VM можно сделать распределенной тоже.

    9. поскольку у нас будет внутри VM активная параллельная работа с множеством контекстов и значений в них (куда более параллельная работа, чем в VM обычно бывает), нам нужна очень конкурентная архитектура для работы с данными. Это значит, что нужен самый масштабируемый способ строить алгоритмы. Это CSP.

    10. если CSP - значит, нужен рантайм на быстрых легковесных процессах. TODO вставить линк на мытарства по выборы движка для CPVM

    11. если посмотреть из того, что сейчас есть, то вариантов немного: Haskell, Erlang, Go, Limbo, Stackless Python, LuaJit yield. Первый выигрывает все тесты производительности и выигрывает по памяти и другим параметрам.

      «Но после нескольких попыток мы отказались от Haskell»

    12. предоставление возможности использовать разные языки разработки для описания действий и подключения их к системе - это ожидаемо и пользователи будут к этому лояльны. Мы можем решить действие на любом языке и разрешить это. НО! как создавать большие системы из самих действий ? Многие действия могут быть построены из более примитивных кусочков только конфигурированием за счёт композиций. Многие так делают, вопрос лишь в транспорте.

    В результате конфигурирования мы действие не получим, мы получим некий solver для того, чтобы осуществлять действие. И он может быть занят в данный момент, либо свободен, либо уничтожен, но этот солвер лишь частично может соотносится с реальным потоком ОС. Можно создавать любые действия из более маленьких.
    Потребности в этих создаваемых solver-ах ограничены (pool).

    вопрос: существует ли базис? - небольшой набор таких базовых действий, из которых легко и удобно строить любое другое действие?. Лучше всего, чтобы это можно было делать автоматизированным способом в процессе анализа кода.

    Ответ: да

    1. любая VM работает как раз на таком множестве небольших операций;
    2. грамматика любого языка программирования состоит из конечного множества нетерминальных символов, каждый из которых может быть действием.

    вопрос: можем ли мы, добавляя новый язык в систему, добавлять в систему новые базисные действия специально для этого языка, чтобы не выражать одни языки в терминах и действиях других языков?

    ответ: да. Список базисных действий, из которых можно строить другие, определяется лишь только нашей фантазией. Почему бы не добавить для особого языка удобные именно для него базовые действия ? Это реально и логично.

    Важно: поскольку данная VM может исполнять в правильном порядке действия, описанные на любом языке, и действия, построенные из действий первого вида с помощью композиции, то это значит, что cистема будет параллелить код как проанализированный специально, так и не проанализированный, т.к. вопросом упорядочивания занимается ещё и рантайм данной VM.

    Что мы имели на входе - императивный ООП код. Что мы имеем на выходе ? Мы имеем на выходе систему, которая специально найденным упорядоченным образом вызывает действия(чистые функции без side эффектов? т. к. все эффекты найдены в процессе работы) и с помощью их композиции выстраивает внутри встроенной “БД” результат их работы с помощью некой определяемой стратегии. Так как данный процесс происходит в итоге без конфликтов, то можно сказать, что это некий похожий на dataflow способ исполнения. Хоть этот способ и работает над ООП структурами, но он работает над ними в чистом функциональном стиле с высокой степенью параллельности, потенциально максимальной для выбранной задачи.

    Таким образом технология позволяет преобразовывать код одной парадигмы в другую. И возможно, что не только императивной в функциональную, но других парадигм в другие. Поскольку выполнение происходит в виде SCP, а информация о зависимостях полностью извлечена, то система может(внимание!) генерировать параллельный код для, например, MPI, CUDA и прочих параллельных систем, dataflow систем и Grid систем, являясь по сути технологией разработки параллельного ПО для других параллельных сред, при этом имея на входе однопотопный императивный алгоритм. Данный подход таит в себе феноменальные возможности. Можно смело заявить, что в мире по масштабу и глубине вот этой данной ИТ идее аналогов не существует.

    «Нам известны лишь некие теоретические работы и модели новых языков не более.»

    Технология может стать основой для построения на ней глобальной VM для всех языков программирования, т.к. сама по себе её архитектура - это универсальная рантайм среда, которую остаётся лишь дополнить особенностями того или иного языка.

    Эта технология изменит мир и представление о вычислителях, о технологии программирования, алгоритмах и методах, о вычислительных сетях, она изменит/дополнит представление о способах построения трансляторов и прочих наиважнейших ИТ вопросах.

    мне бы так хотелось :)

    Comments

    Comments powered by Disqus
    Skip to main content