суббота, 24 августа 2013 г.

Развитие технических систем — Взрыв и стандартизация (с примером IBM)

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

При выходе в новую область наблюдается взрыв разнообразия различных форм. Так было с самолетами в 20-30-х гг., так было в войне Unix'ов, так было с кодировками до ASCII и до UTF-8.

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

После взрыва запускается процесс естественного отбора, когда разнообразие начинает уменьшаться, а видообразование приостанавливается. Отдельные наиболее приспособленные особи выживают и захватывают большие области, другим видам питаться нечем и они отмирают. Так, на сушу в свое время вышли 5-ти, 6-ти и 8-ми пальцевые существа, но выжили только потомки первых, потому мы такие и других больше не наблюдаем.

В технических системах происходит аналогичный процесс, когда остаются в основном 4-хколесные машины шириной в две крупы лошади, мейнстримовые языки программирования, типовые решения для аппаратных устройств (генераторы, трансформаторы), коробочные продукты (one-the-shelf), … Большие выжившие монстры решают большие классы задач, а в маленьких закоулках ютятся отдельные подвиды, зачастую мало кому известные и потенциально отмирающие.

Технические пути отбора

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

Первый — насильственный захват и выбивание конкурентов. Например как это делает Windows — разработчики Windows сами себе стандарт, не обращая внимания на других, и способ захвата — выживают те решения, которые выигрывают на рынке, даже если эти решения не являются сильными. Это и сама ОС, и Ctrl-C Ctrl-V (задолго до них был Ctrl+Insert и Shift+Insert), и Win-1251 и др.. С точки зрения разработки — это решения для себя, для полного контроля и для вписывания в внутрикорпоративные стандарты.

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

Технетика

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

Таким образом, любые технические системы развиваются, живут и умирают. И, как ни странно, есть целые труды и школы, которые описывают данный процесс. С одной из таких я познакомился где-то на рубеже 2000-х, это была Технетика Б.И.Кудрина — информация в ней зубодробительна и слишком философска для обычных людей, но базовые понятия развития техники удалось почерпнуть именно оттуда. В дальнейшем элементы технетики встречались и замечались в жизни много раз, иногда принося существенную пользу.

Стандартизация вычислений с плавающей точкой

Сейчас ещё один такой случай, который увиделся при чтении Fatal Defect (chapter Wrong Number), где подробно разобрана история становления стандарта по вычислительным арифметическим операциям на компьютерах/калькуляторах с плавающей точкой. Особенность в том, что в 60-х не было единого подхода и решения того, как хранить вещественные числа в компьютере, а также как проводить вычислительные операции. Каждая организация делала свое решение, а зачастую внутри организации разные аппаратные разработки имели разные реализации.

Особенностей разностей несколько. Для примера, первая в том, что для повышения точности можно хранить разное количество дополнительных разрядов (кроме отображаемых на дисплее калькулятора можно хранить 0, 1, 3, … разрядов за краем табло, чтобы потом результат вычисления был более точным; например если не хранить, то 1/3*3 получится 0.99999). Второй является то, что можно использовать разные способы округления, которые также могут отражаться на конечном результате. Третьей являются разные алгоритмы выполнения данных операций, каждый из которых может отличаться точностью, быстродействием и неравномерным распределением ошибок. Четвертой — возможно разные преобразования между отображением и вычислением (например сначала берется то что на дисплее в 10-й системе счисления, переводится в 2 с/c, считается, далее обратно в 10 с/c). Пятой — стоимость системы.

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

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

В конце 70-х IBM инициировала внутри себя процесс создания подобного стандарта, так как зоопарк был внутри данной организации и руководство уговорили это сделать. После запуска процесса был собран IEEE-комитет из ~70 представителей различных компаний и институтов (не только из IBM). После многочисленных штурмов и споров (потому что каждый эксперт считает свои заблуждения самыми правильными) был выпущен черновой вариант с сомнениями о том, что этому кто-то будет следовать. Однако IBM в 1980-м выпускает первые чипы 8087, которые соответствовали описанным требованиям, и после этого запустился лавинообразный процесс, который охватил всех мировых производителей, хотя официальный чистовой вариант был принят в 1984-м.

По-моему, отличный пример гибридного решения стандартизации после взрыва (гибридное в плане потому, что с одной стороны был комитет экспертов, а с другой силовое решение о реализации стандарта в железе).


среда, 21 августа 2013 г.

Радость от повторения

Дети любят, когда им несколько раз читают одни и те же сказки.

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

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

Часто можно наблюдать, как люди повторяют что-то банальное, что их греет и умиротворяет («во всем виновата мировая закулиса», «все плохо потому что у власти козлы», «а наши поезда все равно самые поездатые», …).

В разработке видео-игр, когда гейм-дизайнеры рассматривают игроков как подопытных кроликов, есть такое понятие как Core Gameplay Loop, заключающееся в том, чтобы формировать такие повторяющиеся радости, и чем чаще то делать, тем они сильнее закрепляются, и потом на них строить все остальное.

Если часто общаться с человеком, то можно заметить множество повторяющихся штук, в том числе и за собой.

По-моему, за всем этим стоит некий нейробиологический принцип, или общее психическое свойство. Но в популярных литературах ещё ничего такого не встречал.


понедельник, 19 августа 2013 г.

О правильном

В начале всяческой философии лежит удивление, ее развитием является исследование, ее концом — незнание.

М. Монтень

Не бывает правильных (тру-шных и т.п.) программ. Бывают программы с определенными свойствами. Мы не проверяем тестами корректность программы, и не доказываем правильность формальными методами — а определяем вполне её конкретные свойства.

Не бывает правильного способа решения проблемы. Бывают способы с определенными последствиями.

Не бывает правильного принципа или метода. Бывают принципы и методы с определенными достоинствами и недостатками, работающие в определенном окружении.

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

Одно дело когда известен контекст и все понимают, чем «правильный» вариант лучше, чем остальные. Другое дело, когда контекст теряется, и народ уже не понимает что стоит за словом «правильный». «Потому что так написано в книге Х», «Потому что так сказал Y», «Мы всегда делали Z, и в дальнейшем будем делать так же», …

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

После того, как схема принята, то изменить её сложно. Классическая цитата Лоренца:

Для существа, лишенного понимания причинных взаимосвязей, должно быть в высшей степени полезно придерживаться той линии поведения, которая уже — единожды или повторно — оказывалась безопасной и ведущей к цели. Если неизвестно, какие именно детали общей последовательности действий существенны для успеха и безопасности, то лучше всего с рабской точностью повторять ее целиком. Принцип «как бы чего не вышло» совершенно ясно выражается в уже упомянутых суевериях: забыв произнести заклинание, люди испытывают страх. (К. Лоренц, Агрессия)

Если существо работает «правильными методами», которые лишены понимания причинно-следственных взаимосвязей, то мы и получаем такую картину, когда делается потому, что так делалось всегда, а шаг в сторону — это страшно. И работает эта штука подсознательно.

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

Понимайте причинно-следственные взаимосвязи.


пятница, 16 августа 2013 г.

Поступательное развитие

В последнее время вокруг меня что-то много звезд выстроилось по этому понятию…

Примеры

Нельзя сразу собрать проект, который реализует полет на Луну. Или создаст термоядерную бомбу. Или реализует национальную ПРО.

Сразу слетать на Луну — это будет глупая и бессмысленная смерть. Сначала надо собрать ракету и запустить. Понять, что чтобы слетать, надо работать над надежными двигателями, иначе летать она будет низко. Придумать гироскоп, иначе летать будет не туда. Собрать конструкцию заданного масштаба (ракеты малой дальности и межконтинентальные — это две болшие разницы). Запустить железяку и проверить, чтобы она не столкнулась с небесным сводом. Запустить жывотное, потому что его не жалко. Запустить человека в корпусе. Запустить и отработать технологии выхода в открытый космос. Слетать на Луну и померять радиацию. Попробовать прилуниться, а то иначе можно утонуть. И только потом появляются какие-то шансы на слетать и вернуться обратно.

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

Для ПРО сначала необходимо создать что-то, что сможет зарегистрировать массы самолетов. Потому что-то, что сможет засечь одиночный самолет. Потом что-то, что сможет засечь и определить высоту полета. Потом что-то, что сможет засечь, определить x,y,z,t и сбить. И только потом можно думать о чем-то, что сможет отразить атаку в глобальном масштабе.

Два простых правила

Давно в данной теме знаю и использую два простых правила:

Законченные и дискретные решения
Необходимость поступательного развития — серия законченных проектов, каждый из которых имеет конкретную реализуемую цель, решая часть общей конечной задачи. На одних чертежах виртуально запустить в космос человека нельзя — должна быть конкретная задача и её воплощение, все этапы жизненного цикла.
Сложные системы строятся из простых
После Буча сейчас много где цитируют J.Gall'a *: «Любая работающая сложная система является результатом развития работавшей более простой системы... Сложная система, спроектированная "с нуля", никогда не заработает. Следует начинать с работающей простой системы».

Процесс роста

Совсем недавно встретил через Стратоплан картинку роста в любой области (источник — недра психологии потока):

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

На графике по вертикали сложность постановки задачи, они же требования к её исполнению (масштабность проекта, процент отказов, производительность системы, … — все это может быть большим уровнем по требованиям). По горизонтали наши умения (+ знания и навыки). Т.е. способность что-либо делать.

В самом начале мало чего умеем. И лучше, если не предъявляем к себе каких-либо сверх-требований. Тогда это нижний левый угол.

Делая что-то, мы учимся это делать лучше. Если делать это долго, то мы научимся это самое делать, но нам становится скучно. A1→A2. Если мы предъявляем к себе более высокие требования, то появляется чувство тревоги — получится ли? сложно! много всего.. и все такое. A1→A3.

В состояниях A2 и A3 зоны дискомфорта — человек может бросить этим заниматься, а может получить большой стимул к развитию.

Оптимальное развитие — как по красной линии, можно немного иногда заходить в сторону тревоги. Если делаем переход вида A1→A4, то растем и можем осуществить большее.

Следствия:

  • Сначала мы все ничего не умеем. Если мы предъявляем к себе большие требования, то станет страшно, ничего не будет получаться и все будет заброшено. Поэтому начинать надо с простых вещей.
  • Если долго делать одни и те же простые вещи, то станет скучно и уныло. Что делать? Повышать требования.
  • Что делать чтобы быстро расти вверх? Идти согласно коридору потока. Если проект большой и масштабный, то идти придется долго, зачастую окольными путями.

Под другим ракурсом

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

Слишком сложная цель

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

Здесь вижу два больших разных пути решения: «составление программы» и «работа в стол». Первый вариант предпочтителен — есть ресурсы, понятно приблизительно что делать, вехи отмечены. Второй вариант — за неимением первого, когда цель недостижима, не хватает ресурсов, практическая область не понятна.

Работа в стол: переход на самообразование в случае плохого образования; постепенная выработка мастерства; методический и системный сбор информации.

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

Отсутствие цели

Проект выполнен, а дальнейших целей нет.

Активный поиск качественно более широкой и дальней цели и отсутствие ожидания. Без этого — останов процесса роста и потеря поступательного развития.

Отсутвие возможности работы над следующим этапом (не важно по каким причинам) — способствует потере команды и задела.

Цель забирают

По разным причинам — недопущение до информации, высмеивание, потеря контроля, куча соавторов.

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


* — данная мысль только в программной инженерии лет на 20 старше; у Брукса в статье о серебрьяной пуле есть ссылка на научную публикацию 1971 года и цитата коллеги 1958-го года.


воскресенье, 11 августа 2013 г.

Art of Failure

Теперь прибавился к известным мне квази-научным фотоконкурсам конкурс Art of Failure.

Конкурс проводится в рамках международного симпозиума IEEE по физическому анализу и анализу отказов интегральных полупроводниковых схем (IEEE International Symposium on the Physical and Failure Analysis of Integrated Circuits). На этом конкурсе представляются имеющие художественную ценность фотографии необычных объектов и явлений, которые возникают на кристаллах микросхем и других полупроводниковых приборов, возникшие в результате неисправности или выхода из строя этих кристаллов.

  • Именно эту картину увидел на изображении, снятом электронным развертывающим микроскопом, Лим Сав Синг (Lim Saw Sing), сотрудник компании Infineon Technologies, рассматривая поверхность полимидного кристалла, подвергнутого процессу ионного травления. Этот снимок занял первое место в конкурсе Art of Failure 2012.

  • Мембрана из специального материала "прилипла" к коротким частям из углеродной ленты, формируя подобие странного и необычного "леса" на этом изображении с микроскопа. Данный снимок сделал Лим Чен Вэй (Lim Chan Way) из компании Infineon Technologies.

  • Аналитики компании Advanced Micro Devices посчитали, что данная структура на поверхности кремниевой подложки очень смахивает на слона в головном уборе. Фотография так же принадлежит Жаклин Ква (Jacqueline Kwa) из компании AMD.

  • Проводя свои исследования, инженеры компании WinTech Nano-Technology создали эти 20-микронные структуры из меди, используя технологию нанопроизводства с использованием сфокусированного ионного луча. Фотогорафия Ху Бинг Шен из компании WinTech Nano-Technology.