Лечение «механического» Scrum. Часть 2. Команда

В первой части мы рассмотрели тревожные симптомы и возможные способы «лечения» Product Owner в «механическом» scrum. Продолжим разбор ролей и следующая на очереди – команда.

Все же знают мантру, что команда должна быть самоорганизованной и кросс-функциональной, это выглядит как самая простая часть scrum: берем людей с нужными компетенциями, говорим им: «вы команда», и полетели! Но на деле все несколько сложнее.

Самоорганизация

Симптом: Существует явная иерархия (директивное подчинение) снаружи, или что еще хуже внутри команды. Т.е. фактически разработчику продукта может прийти задача, непосредственно не связанная с деятельностью команды. Либо внутри команды люди не вольны в выборе работы для достижения цели спринта, а получают задания от «руководителя».

Чем плохо:

Любые границы — ограничивают @КЭП

Когда человек зажат должностной инструкцией, иерархией подчинения и т.п., это не дает ему раскрыться. Сила scrum команды в открывающихся перед людьми возможностях. Есть задача, бери на себя смелость и отвечай за её выполнение. Человек должен сам принимать решение о том, что он будет делать для достижения цели спринта. Если ему говорят что делать, то это не самоорганизация и не scrum.

Как лечим: Для людей в команде отменяются все должностные инструкции и иерархии, структура стремится к плоской. Все, кто в команде — это разработчики продукта (других ролей scrum guide не допускает). Есть только ситуационное лидерство, и люди сами решают, как им комфортно работать, чтобы быть эффективными. Конечно же, есть общие правила игры в компании, команда никоим образом их не нарушает (хотя может влиять на изменение на уровне компании), но за все внутренние вещи отвечает сама. Если есть серьезные препятствия на пути отмены ограничений для разработчиков, то стоит эскалировать вопрос до тех, кто принял решение о внедрении scrum и agile трансформации. Можно попробовать запустить плоскую структуру, как эксперимент на несколько спринтов, а затем провести обширную ретроспективу, где всеми заинтересованными лицами обсудить результаты эксперимента.

Симптом: Люди, помимо работы в команде, должны выполнять другие функциональные обязанности в компании. Например: 50% времени выполняет задачи команды, 50% — задачи отдела (разработка, тестирование и т.п.).

Чем плохо: Одна из ценностей в scrum — это сфокусированность. Команда фокусируется на цели спринта и движется к ней. Если помимо работы в команде человеку приходится заниматься еще чем-то, то фокус теряется. Как следствие, результат работы будет хуже. Сложно поддерживать командный дух в таких условиях.

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

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

Кросс-функциональность

Симптом: Люди внутри команды выполняют только определенную работу, есть четкая специализация. Хуже когда это еще покрыто должностными обязанностями, регламентами и прочей бюрократией. Отсутствие (отпуск, больничный и т.п.) одного члена команды, уменьшает функциональность команды. Привет, bus factor.

Чем плохо: Если команда зависит от компетенций одного из её членов, это неустойчивая к изменениям команда. Выстраивать с ней коммуникации сложно, т.к. нужно понимать текущую её функциональность и помнить о рисках, связанных с таким уровнем отказоустойчивости. Узкая специализация разработчиков сильно усложняет организационную работу для команды: при планировании нужно много думать о том, кто и чем будет заниматься; не каждая задача нуждается в заданных пропорциях компетенций команды, следовательно собрать сбалансированный спринт сложно; в такой схеме обязательно возникает «узкое горлышко», снижающая общую скорость команды.

Что делать: Нужно пропагандировать и поддерживать t-shaped навыки. Чтобы команда оставалась гибкой, важно чтобы конкретная функция или знание не были сосредоточены в одном человеке. Нужно стимулировать и поощрять постоянное развитие. Важно следить, чтобы команда совершенствовалась, искала способы улучшить процессы. Как варианты развития t-shaped: проведение внутренних семинаров, где члены команды делятся друг с другом знаниями; принять правило выполнения непрофильной задачи каждый спринт каждым членом команды; парная работа над задачами и т.д. Можно искусственно стимулировать команду, «выключая» её членов на некоторое время: отпуска, семинары, тренинги, командировки и т.п.

Симптом: В цепочке создания ценности команда отвечает (оказывает влияние) лишь за небольшую её часть, и как следствие, команда не может выпускать инкременты самостоятельно.

Чем плохо: Если команда слабо влияет на доставку инкремента (релиз продукта), то scrum тоже теряет свою суть: релизы происходят с задержкой, обратная связь происходит с еще большей задержкой. В общем, отсутствует ритм, а значит и скорость. Нет скорости — нет гибкости. Такая команда не чувствует свою сопричастность, она просто функциональный винтик в большой машине. Функциональности команды должно хватать на закрытие большей части цепочки создание ценности, иначе команда просто не будет доставлять ценность, а просто будет один вид «заготовки» перерабатывать в другой и передавать его дальше.

Проиллюстрируем это примером из web. Где упрощенно создание новой фичи включает в себя следующие этапы:

• разработка UI / UX прототипа
• разработка дизайна
• создание RESTful API
• создание SPA
• написание интеграционных автотестов
• сборка и выливка на боевое окружение

Для этих работ необходимы различные компетенции. Пример неудачного разделения на команды: выделить команду А из UI/UX, дизайнеров и frontend разработки, они готовят свой инкремент в виде SPA; но они зависят от того, когда backend подготовить API для работы нового функционала; ждут когда QA проверит все интеграционно и напишет тесты; а потом еще ожидают DevOps, чтобы те раскатали все на бой. Такой команде А трудно отвечать за релиз и доставку ценности, она просто пилит «заготовку» — SPA.

Как лечим: Определяем, каких компетенций не хватает команде, чтобы доставлять инкремент. Наделяем команду этими компетенциями благодаря обучению существующих членов команды, или добавлением новых игроков в команду. Т.к. найти / научить людей – задача не самая простая и быстрая, то можно налаживать коммуникации с соседними командами / отделами, объясняя им ценности scrum и договариваясь с ними об специальных регламентах / правилах взаимодействия, при которых они не будут ломать scrum вашей команде. Стоит подсветить процесс расширения функциональности команды: после первой ретроспективы и определения недостающих компетенций, можно их распечатать и разместить перед командой. Когда команда справляется с отсутствием компетенции (научились; новый член команды; настроили эффективную коммуникацию с другой командой и т.д.), то поверх ранее недостающей компетенции вешаем решение. Со временем команда должна стремиться расширять свою функциональность, чтобы полностью покрывать цепочку создания ценности.

Команда и продукт

Симптом: Команда есть, а продукта нет. Нет PO, нет backlog. Просто люди делают задачи, приходящие с разных сторон.

Чем плохо: Это не scum. Когда за командой не закреплен продукт, то команда вряд ли будет «гореть» работой. Когда есть глобальная цель (видение / стратегия / roadmap развития продукта), то хочется идти к ней. Ты делаешь работу, получаешь обратную связь, рефлексируешь и делаешь следующий шаг. Без чувства причастности ты рискуешь оказаться в рутине: обратная связь тебе особо не нужна, команда становится просто инструментом переработки ТЗ в функционал.

Как лечим: У команды должны быть свой продукт с backlog и PO, который сможет зажечь команду продуктом и увлечь её за собой — в этом суть. Нужно понять, зачем вам scrum? Понять, откуда у команды берутся задачи? Понять, есть ли среди этого потока «продукт»? Выбрать среди «заказчиков» команды одного и сделать его владельцем продукта, наделив его единоличным правом отвечать за backlog. Возможно, придется разделить команду на scrum команду работающую с одним PO (это может быть «пилотная» scrum команда) и вторую команду, ПОКА работающую по-старому с остальными «заказчиками». Обеспечивая максимальную прозрачность процессов и результатов, происходящих в новой scrum команде, можно заложить базис для дальнейшего распространения scrum и agile в организации.

Симптом: Команда не имеет влияния на продуктовую составляющую: она не решает, «как делать?», команде просто говорят «что делать?», т.е. на вход приходит ТЗ, а команда рассматривается как функциональная единица.

Чем плохо: Это очень опасный вариант, если в компании действительно провозглашаются ценности agile и scrum. Обычно это подразумевает, что все сотрудники — классные профессионалы, способные решать любые задачи, которые не боятся принимать решения и брать ответственность. Но если не дают принимать продуктовые решения, то вся свобода творчества у команды обычно с продукта перекидывается на технологии. Раз команде не дают решать, как сделать жизнь пользователя легче, мир лучше, а продукт полезнее; то команда начинает развивать кодовую базу, пробовать новые технологии / инструменты / фреймворки и т.д. Возникает конфликт интересов между PO и командой, команда начинает продавать «рефакторинги», «оптимизации», «серебряные пули» в виде нового стека и т.д. А страдают от этого в первую очередь пользователь и продукт. В процессе перехода от директивных моделей управления к agile есть опасность застрять в понимании команды как функциональной единицы (команда до этого не принимала решения). Это чревато тем, что либо убьем инициативу команды, либо придем к ситуации, когда команде интереснее технологии, чем продукт.

Как лечим: нужно выявить причину недоверия к команде или её нерешительности: почему команда не ищет решения, а работает только с детальным тех.заданием? Найдя причину, можно постепенно устранять её. Например:

• У команды не хватает компетенций или опыта.: Кто-то же прорабатывает решения и пишет ТЗ, можно либо добавить этого человека в команду, либо позволять ему работать над некоторыми задачами совместно с командой, тем самым передавая часть своих навыков и опыта команде. Так постепенно команда научится и привыкнет решать продуктовые задачи.
• У руководства есть страх, что команда ошибется.: Это краеугольный страх при переходе к agile, но, не преодолев его, не получится приобрести всю силу scrum команды. Команда обязательно ошибется, потому что ошибаются все. Но ошибка — это источник опыта и мастерства. Полезнее, когда команда ошибется, потому что она так решила, а не из-за неправильного внешнего ТЗ. Scrum — это ритм: быстро сделали решение для проверки гипотезы; получили обратную связь; осознали, что пошли не туда; выкинули решение. Стоимость ошибки резко сокращается (потратили спринт, а не квартал / год / ваш релизный срок), что позволяет переступить через страх ошибки.

Симптом: У членов команды нет свободного доступа к командным артефактам. Например, не все видят спринтовый или общий backlog, или есть сложности с возможностью актуализации его состояния.

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

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

Заключение

В следующей части продолжим рассматривать роли scrum, и доберемся, наконец, до scrum master-а. Кратко напомню, что вам делать с симптомами:

1. Отбираете симптомы, применимые к вашей ситуации.
2. Из них выбираете наиболее острые.
3. Осознаете эту боль.
4. Придумываете с командой решение (за отправную точку можно брать кейсы из статьи).
5. Реализуете ваше решение.
6. Переходите к пункту 1.

Спасибо, что читаете, хотелось бы увидеть известные вам «симптомы» в комментариях.

Спасибо Sai Kin за илюстрации.

Let's block ads! (Why?)

Biostar Racing P1: от простого к сложному

У миниатюрного компьютера типа Biostar Racing P1 каждый мегагерц на счету. Это диктуется компактностью и низким уровнем энергопотребления. Процессор Intel Atom x5-Z8350 здесь на своем месте. И ждать от него особых рекордов производительности не приходится. Особенно, с учетом провальных характеристик по записи кэш-памяти L1-уровня.

Тем не менее, этот «уже не стик, но еще и не ноутбук» своего потребителя всё же найдет. Залог тому – четыре ядра простенького, казалось бы, CPU. Стоит возлагать на них надежды?

В предыдущей статье мы анализировали результаты тестов кэш-памяти выполненные в одном потоке, что дает представление об «изолированной» производительность отдельно взятого ядра. Какой будет интегральная оценка многоядерного процессора? Итак, устанавливаем чекбокс Use parallel operations в утилите NCRB и выполняем аналогичную серию измерений.

Рис 1. Выбор сценария многопоточного тестирования платформы средствами утилиты NCRB

Многопоточный тест L1-кэш

В процессоре Intel Atom x5-Z8350 кэш-память первого уровня является приватным ресурсом каждого из четырех ядер. Это означает, что при обработке блока данных, размер которого меньше размера L1 (в нашем примере это 24 килобайта), каждое из ядер использует собственную кэш-память, конкуренция при доступе практически отсутствует, значит, мы вправе ожидать кратного прироста производительности в соответствии с количеством ядер. Расхожая фраза «а вот и не подеретесь» достаточно точно характеризует данный измерительный сценарий.

Рис 2. График зависимости скорости чтения блока данных от его размера для одновременно работающих 4 процессорных ядер; окрестность X = размер L1
Контраргументами могут стать такие факторы, как уменьшение верхнего лимита динамического оверклокинга при реализации заданного сценария энергопотребления и термального режима, а также ограничение процессорного времени, выделяемого операционной системой приложению в рамках многозадачной среды.

Напомним, пиковая производительность в однопоточном тесте (см. «Biostar Racing P1: холодный выхлоп») составляла чуть более 30 GBPS. Задействовав 4 ядра, получаем результат около 107 GBPS, который довольно близок к теоретическому значению 120 GBPS.

Рис 3. График зависимости скорости записи блока данных от его размера для одновременно работающих 4 процессорных ядер; окрестность X = размер L1
При исследовании L1 важен левый участок графика, соответствующий блоку размером до 24KB. Здесь мы видим две фракции производительности: быстрый участок на малоразмерных транзакциях (более 105 GBPS), и медленный участок для данных, размер которых превышает 6.4KB, но еще «влезающих» в игольное ушко L1-кэш. С первым все понятно: он, как и в случае с тестом чтения, близок к учетверенному для одного ядра значению 120 GBPS. Почему с записью данных в L1 снова «провал»? Об этом можно только догадываться.

Вероятно, инженеры Intel, проектируя эконом-вариант процессора, сместили акцент кэширования данных с L1 на L2. Кэширование инструкций на первом уровне по-прежнему остается эффективным, и с этим у Atom x5-Z8350 все в порядке. В условиях дефицита ресурсов процессор скупится бесшабашно расходовать статическую память для обслуживания потоков данных, более полагаясь на возможности второго кэш-уровня.

Здесь приходит на ум общепринятый подход по формированию профиля нагрузок для обработки транзакций в реальном времени. Общепринятым стандартом считается соотношение чтения к записи в пропорции 70% к 30%. Приблизительно так и соотносится объем, выделенный для «быстрой» записи, к оставшемуся месту в кэш-памяти L1. Можно ли на основании этого предполагать, что Intel нацеливает процессоры Atom в частности на обработку потоковой информации, например, медиаконтента?

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

Многопоточный тест L2-кэш

Кэш-память второго уровня, общим объемом 2 Мегабайта, разделена на две равные части по 1 MB, каждая из которых обслуживает группу из двух ядер. Это означает, что в многопоточном тесте на каждое ядро приходится 512 килобайт кэш-памяти L2 в отличие от 1 Мегабайта в однопоточном. Следовательно, на графике зависимости скорости обработки блока от его размера, точку перегиба следует ожидать в окрестности X=512 KB, а не X=1024 KB, как это имело место в однопоточном тесте (см. «Biostar Racing P1: холодный выхлоп»). Рассмотренные топологические особенности кэш-памяти L2 также оказывают влияние на масштабирование скорости доступа к ней.

Рис 4. График зависимости скорости чтения блока данных от его размера для одновременно работающих 4 процессорных ядер; окрестность X = размер L2
Производительность L2 характеризует участок графика, удовлетворяющий двойному неравенству 24 KB < X < 512 KB, что соответствует блоку данных, который уже не помещается в L1, но еще помещается в L2.

Рис 5. График зависимости скорости записи блока данных от его размера для одновременно работающих 4 процессорных ядер; окрестность X = размер L2
Напомним, скорость чтения L2 в однопоточном тесте составляет около 11.5 GBPS. Результат масштабирования — около 39 GBPS. Очень неплохо! Скорость записи L2 в однопоточном тесте составляет около 12 GBPS. Результат масштабирования — около 31 GBPS.

Вместо резюме

Можно констатировать неплохой уровень многопоточной производительности исследуемой платформы. Архитектура процессора Intel Atom x5-Z8350, определяющая приватную кэш-память L1 и частично-разделяемую L2, ожидаемо отразилась на результатах бенчмарок.

Рис 6. Мониторинг загрузки процессора средствами ОС Windows 10: момент увеличения загрузки ядер до 100 процентов соответствует моменту запуска теста
При запуске многопоточного теста, загрузка каждого из четырех ядер процессора возрастает до 100 процентов. А что при этом происходит с температурами и потребляемой мощностью?

Рис 7. Мониторинг температуры и потребляемой мощности средствами утилиты AIDA64
Результат получен с помощью популярной информационно-диагностической утилиты AIDA64 по прошествии примерно 20 минут после запуска многопоточного теста NCRB.

Важное предостережение

Пытаясь повторить выше описанные опыты на своем компьютере, необходимо выполнить резервное копирование данных, убедиться в эффективности системы охлаждения процессора, надежности блока питания и импульсного регулятора Vcore. Стресс-тест может повредить разогнанную или нестабильную систему. А лучше всего экспериментировать на казенном оборудовании.

Let's block ads! (Why?)

Почему VMware решили создать платформу для разработки корпоративных блокчейнов

В конце июня компания VMware опубликовала программы конференций VMworld 2018 US и VMworld 2018 EU, которые пройдут в августе и ноябре соответственно. Одной из ключевых тем конференций является создание корпоративных блокчейнов на платформе VMware.

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

/ фото Pxhere PD

Зачем разрабатывают

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

Далия Малхи (Dahlia Malkhi), исследователь из команды VMware Research, утверждает, что компания начала работать над платформой, поскольку среди клиентов VMware много финансовых и государственных организаций, которые планируют начать работать с блокчейнами. При этом компания обладает внушительным опытом разработки распределенных систем и содержит исследовательский отдел, на счету которого множество публикаций и реализованных проектов по теме.

Старший менеджер VMware Майк Дипетрилло (Mike DiPetrillo) рассказал, что компания стремится максимально упростить процесс внедрения блокчейн-технологий для своих клиентов — взять на себя организацию управления реестрами, обеспечение безопасности транзакций и вопросы масштабирования.

Еще на конференции в августе 2017 года исследователь из VMware Дэвид Тенненхауз (David Tennenhouse) заявил, что в компании уже работают над прототипом платформы для обмена цифровой валютой. Релиз пилотной версии платформы был намечен на 2018 год. Тенненхауз подчеркивает: «Блокчейн может стать принципиально новой сферой бизнеса, и мы считаем, что предприятиям нужны инновационные блокчейн-решения».

О платформе

По словам Далии Малхи, решение VMware нацелено на работу с закрытыми частными блокчейнами. Потому для обеспечения консенсуса они ищут альтернативные решения, которые необязательно используют принципы доказательства выполнения работы (proof-of-work), как в случае с биткоином.

По мнению представителей исследовательского отдела VMware, в мире 2 основные тенденции: увеличение числа кибератак и массовая цифровизация данных и бизнес-процессов. Чтобы решить эти две проблемы, в апреле 2018 года VMware в своем исследовании описали концепцию масштабируемой децентрализованной «инфраструктуры доверия» (scalable decentralized trust infrastructure) — технологию, за счет которой VMware реализуют платформу для создания корпоративных блокчейнов.

Она представляет собой распределенную систему, которая устойчива к проблеме византийских генералов (byzantine fault tolerant — BFT): система остается надежной, даже если содержит скомпрометированные или вышедшие из строя узлы сети. Когда группа, например, финансовых организаций, формирует единую инфраструктуру доверия, она получает возможность реализовывать смарт-контракты «поверх» BFT-системы. При этом среда выполнения смарт-контрактов (например, Ethereum Virtual Machine — EVM) обеспечивает тьюринг-полный уровень абстракции, который следит за соблюдением условий «договора» и предотвращает DoS-атаки.

Исследователи VMware протестировали такую инфраструктуру, проведя 1 млн транзакций на базе реальных рабочих Ethereum-нагрузок. Результаты показали, что система способна выполнять 50 транзакций в секунду.

Старший менеджер компании Майк Дипетрилло также добавил, что VMware уже внедрили платформу для создания блокчейнов внутри компании. Результаты тестирования этой системы показали, что сеть из 500 узлов способна проводить 30 тыс. транзакций в секунду.

/ фото Pxhere PD

Другие блокчейн-проекты VMware

Компания также работает с Hyperledger Fabric — проектом-хабом для разработки корпоративных блокчейнов, который создали в сообществе Linux Foundation с целью популяризировать блокчейн. В июле 2017 года Hyperledger выпустили свое первое решение — Hyperledger Fabric 1.0.

Для работы с ним VMware запустили вспомогательный проект — Blockchain on vSphere, который позволяет системным администраторам развернуть блокчейн-платформу для разработчиков на базе гипервизора ESXi. В нашем корпоративном блоге можно найти пошаговый алгоритм реализации блокчейн-проекта с помощью Hyperledger Fabric и vSphere.

Что дальше

Пока что (до августовской конференции в США) VMware не раскрывали точной даты релиза платформы для создания корпоративных блокчейнов. Однако Майк Дипетрилло отметил, что все желающие могут следить за прогрессом разработки на сайте исследовательского отдела VMware.

Дипетрилло также сказал, что блокчейны лишь начало развития «распределенных доверительных систем». Сейчас компания работает над вспомогательными решениями: системами распределенной аналитики, IoT-интерфейсами, протоколом доказательства с нулевым разглашением.

---

P.S. Несколько дополнительных статей из Первого блога о корпоративном IaaS:
P.P.S. Материалы по теме из нашего блога на Хабре:

Let's block ads! (Why?)

SpaceX отправила на МКС робота с искусственным интеллектом

Вот примерно так CIMON будет выглядеть на орбите. Это рендер, но весьма приближенный к реальности

В пятницу компания SpaceX отправила на МКС полезный груз массой 2,7 т. Доставлен на место он будет уже в понедельник, 2 июля. На этот раз, кроме привычных вещей — продуктов питания, оборудования и материалов для экспериментов астронавты получат робота с искусственным интеллектом. Это интерактивный мобильный ассистент, который предназначен для исследований в космосе. Называется устройство CIMON (Crew Interactive MObile сompanioN).

Разработали его специалисты Airbus и IBM. Внешне робот напоминает шар, который для обеспечения интерактивности оснащен дисплеем и звуковыми датчиками. CIMON станет личным помощником для астронавта Александера Герста во время проведения научных экспериментов. Кроме всего прочего, робот является объектом исследования психологов: ученые планируют выяснить, может ли ИИ помочь снять астронавтам стресс.
Робота можно сравнить с волейбольным мячом, если бы у мяча был экран. На дисплее показывается анимированное «лицо» самого цифрового помощника, который таким образом общается с обитателями станции. Система умеет перемещаться самостоятельно — для этого она оснащена 14 вентиляторами, которые выполняют роль двигателей в условиях отсутствия притяжения. Расположены они внутри системы, так что кроме всего прочего, робот с их помощью еще и охлаждается.

CIMON понимает, когда его зовут по имени. Поэтому как только астронавту из команды МКС потребуется помощь, он может позвать робота, и тот прилетит, причем довольно быстро. CIMON способен отвечать на вопросы.

Airbus и IBM создали робота по запросу космического агентства Германии. Работа его на орбите позволит понять, может ли электронный помощник стать своим для астронавтов. CIMON уже был опробован в работе, но на Земле, во время полета специального самолета НАСА, который на время позволяет достичь условий невесомости. Тренировал робота немецкий астронавт Александер Герст, который, как и говорилось выше, сейчас уже находится на орбите Земли.

Специалисты Airbus работали над электроникой и механикой, а IBM — над программным обеспечением, платформой ИИ. Как только робот окажется на станции, он станет участником научного эксперимента. В частности, он покажет своему наставнику основные моменты научных исследований, которые необходимо будет провести. Герст, в свою очередь, задаст несколько вопросов CIMON. Все это необходимо для выполнения миссии CIMON. Кстати, пребывание робота на МКС будет недолгим — всего три часа. Затем он вернется на Землю. Но информация, полученная им, позволит проектировать подобные системы для будущей работы.

Кроме робота, SpaceX отправила на МКС специальный инструмент, который будет прикреплен на внешней стороне станции для измерения температуры растений на Земле. Звучит немного странно, но это действительно необходимо — в частности, для того, чтобы исследовать состояние земных экосистем. Измеряя температуру растений, ученые планируют выяснить, насколько сильно экосистемы подвергаются стрессу в результате изменения климата и прямого воздействия человека.

Но и это еще не все. Полет примечателен тем, что SpaceX отправляет уже летавшую в космос первую ступень ракеты-носителя Falcon 9, плюс такой же «бывший в употреблении» Dragon. Этот запуск уже третий на счету SpaceX, когда в космос вторично отправилась не только ракета, но и Dragon. Что касается последнего, то он в последний раз летал к МКС в июле 2016 года. Falcon 9, первая ступень ракеты, менее «пожилая», она летала совсем недавно — в апреле этого года. Тогда при помощи Falcon 9 в космос был запущен научный спутник для НАСА, который называется TESS.

Кстати, ракета, которая полетела на этот раз, представляет собой модификацию Falcon 9 Block 4. Это последний полет ракеты, возвращать и снова использовать ее не планируют. После текущего пуска все ракеты SpaceX, которые отправятся в космос, относятся к модификации Block 5. Маск уже заявлял, что это почти совершенная конструкция, которая практически не будет изменяться.

Let's block ads! (Why?)

Tesla Inc открыла возможность заказа Tesla Model 3 для жителей Канады и США

Tesla Model 3 ожидают сотни тысяч клиентов компании Tesla. Ожидание несколько затянулось, и это понимают все

Два года назад компания Tesla представила свой новый электромобиль Tesla Model 3. Тогда Илон Маск заявил, что предзаказ на эту модель можно сделать, если внести $1000. Это считалось резервированием машины, и те, кто предоставил Tesla средства, получали место в очереди (которой на то время просто не было, поскольку и Tesla Model 3 существовала только в проекте).

Предзаказы оставили многие клиенты компании, фактически, она получила заявок гораздо больше, чем рассчитывала. И что немаловажно, больше, чем может удовлетворить в настоящий момент. Конечно, сейчас Маск старается сделать все возможное, чтобы наладить выпуск электромобилей в необходимом объеме. Но недовольных клиентов достаточно много — ведь кому хочется внести средства, а потом ждать несколько лет своего заказа? Теперь части клиентам можно расслабиться и получать удовольствие — Tesla открыла возможность полноценного заказа машины.
Правда, пока только для Канады и США. Жители этих стран, которые ранее сделали предзаказ, теперь могут внести $2500 и ждать несколько месяцев, пока приедет их новенькая Tesla Model 3. Выбрать можно из нескольких вариантов конфигураций, включая «полный фарш». Вот только ту самую базовую конфигурацию с ценой в $35 000 заказать пока не получится — компания отдает приоритет более дорогим заказам, а потом уже будет удовлетворять желания тех, кому не нужны продвинутые варианты.

Делается это для того, чтобы получить прибыль — насколько известно, базовая модель либо вообще не дает компании заработать, либо дает, но самый минимум. И если Tesla сейчас начнет продавать базовые электромобили, то ее производственные мощности будут заняты, а вот прибыли она не получит. При чем здесь клиенты, которые рассчитывали на получение недорогой Tesla? Риторический вопрос, в договоре, насколько можно понять, все это прописано, так что остается лишь ждать.

К слову, $1000 можно забрать в любой момент — с этим проблем нет. Тот же клиент, кто заплатил $2500, тоже сможет при желании забрать свой взнос, но лишь в течение трех дней. После этого залог блокируется (включая и ту самую тысячу) и компания начинает выполнять заказ.

Глава компании Tesla Илон Маск пообещал достичь объема производства в 5000 электромобилей в неделю к концу июня. По его словам, именно такое количество производимых машин позволяет удовлетворить спрос на электромобили со стороны клиентов. Тем не менее, выполнить обещание на все 100% не удалось, несмотря на все попытки Маска ускорить процесс производства. В компании постоянно что-то случалось, о чем писали многие СМИ. Последняя новость — это обвинение одного сотрудника в настоящем саботаже.

Возможно, компания сможет достичь требуемого объема производства во второй половине этого года. Но даже в этом случае в квартал Tesla будет производить 65 000 Tesla Model 3. А предзаказ составляет около 450 000 экземпляров электромобилей, так что клиентам придется ждать, и ожидание это продлится, если на фабрике Tesla случится какая-то неприятность.

Тем не менее, раз Tesla пока не открыла возможность заказа электромобилей для клиентов со всего мира, ограничившись лишь США и Канадой, то у жителей этих стран есть неплохой шанс получить свой заказ достаточно быстро. По оценкам экспертов, в лучшем случае все полмиллиона предзаказов будут удовлетворены в течение двух лет, не ранее.

Решение открыть возможность заказа машины было принято потому, что электромобили все же понемногу производятся, несмотря на все сложности, а также потому, что это поможет компании доказать, что она способна выполнять собственные обещания. Во второй половине 2018 года Tesla планирует выпустить около 100 000 Tesla Model 3. Есть и третья причина, о которой Tesla не говорит открыто — скорее всего, компании просто нужны дополнительные средства. И те самые $2 500, полученные от тысяч клиентов, помогут решить некоторые текущие финансовые проблемы.

Ранее сообщалось, что Tesla теряет сотни миллионов долларов США в квартал. Кроме того, компанию покидают топ-менеджеры, что может говорить о каких-то сложных внутренних проблемах, которые не видны всем нам.

Let's block ads! (Why?)

Компилятор Go: язык описания правил SSA оптимизаций

В компиляторе gc для описания Static Single Assignment (SSA) правил оптимизаций используется специальный Лисп-подобный предметно-ориентированный язык (DSL).

Предлагаю разобрать основные элементы этого языка, его особенности и ограничения.
В качестве упражнения, добавим в Go компилятор генерацию инструкции, которую он раньше не генерировал, оптимизируя выражение a*b+c.

Это первая статья из серии про внутренности Go SSA compiler backend, поэтому помимо обзора самого DSL описания правил мы рассмотрим связанные компоненты, чтобы создать необходимую базу для нашей следующей сессии.

Frontend Go компилятора заканчивается на моменте генерации SSA представления из аннотированного AST. Функции, ответственные за конвертацию можно найти в cmd/compile/internal/gc/ssa.go. Точкой входа в SSA backend является функция ssa.Compile, определённая в файле cmd/compile/internal/ssa/compile.go.

Терминология

EN	RU	Значение
Compiler frontend	Фронтенд компилятора	Парсинг и лексический анализ, иногда разрешение типов, промежуточное представление близко к исходному коду, обычно какое-нибудь аннотированное AST.
Compiler backend	Бэкенд компилятора	Более низкоуровневые оптимизации и промежуточное представление, кодогенерация.
Form	Форма	Практически синоним слову "выражение" (expression). Обычно в Лиспах form — довольно распространённый способ именовать элемент программы, будь то список или атом.
Optimization pass	Фаза оптимизации	Выполнение определённого алгоритма над программой. Слово "проход" несколько неоднозначно, потому что одна фаза может выполнять несколько проходов, и/или использовать общий с другими фазами код.

Если по мере прочтения статьи вы нашли совершенно непонятный для вас термин, стоит сообщить об этом, возможно он будет добавлен в эту таблицу.

SSA оптимизатор Go состоит из нескольких фаз, каждая из которых выполняет проходы по компилируемой функции. Некоторые фазы используют так называемые "rewrite rules", правила преобразования одних SSA последовательностей в другие, потенциально более оптимальные.

Правила преобразования описываются с помощью S-выражений. Элементы этих выражений — ssa.Value. В простейшем случае эти правила позволяют заменить один ssa.Value на другой.

Например, код ниже сворачивает умножение 8-битных констант:

(Mul8 (Const8 [c]) (Const8 [d])) -> (Const8 [int64(int8(c*d))])

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

Оптимизации описываются в терминах этих двух категорий. Сначала высокоуровневые и общие для всех архитектур, затем платформенно-ориентированные.

Весь код, связанный с правилами, лежит в cmd/compile/internal/ssa/gen. Мы будем рассматривать два набора:

1. genericOps.go — машино-независимые операции.
2. AMD64Ops.go — операции, специфичные для GOARCH=AMD64 (64-bit x86).

После нескольких первых фаз, которые работают над абстрактной машиной, выполняется так называемый lowering, в результате которого происходит переход из genericOps в набор конкретной архитектуры. В нашем примере это будет AMD64Ops. После этого момента, все последующие фазы оперируют над представлением из второй категории.

После оптимизатора в игру вступает кодогенератор. Для AMD64 реализацию кодогенерации можно найти в пакете cmd/compile/internal/amd64. Задача кодогенератора — заменить ssa.Block и ssa.Value в последовательность obj.Prog, передаваемые ассемблеру. Ассемблер соберёт машинный код, который будет готов к исполнению после линковки.

Если файлы с определениями операций имеют название вида "${ARCH}Ops.go", то правила оптимизаций размещаются в "${ARCH}.Rules".

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

Каждый файл с низкоуровневыми правилами состоит из двух частей:

1. Lowering — замена абстрактных операций на машинные эквиваленты.
2. Непосредственно сами оптимизации.

Пример сведения операции к машинной:

(Const32 [val]) -> (MOVLconst [val])
(Const64 [val]) -> (MOVQconst [val])
 |                  |
 generic op         |
                   AMD64 op

Именно в низкоуровневых оптимизациях выполняется основное количество важных оптимизаций, таких как снижение стоимости операций, частичное встраивание и утилизация возможностей доступных в процессоре режимов адресации памяти.

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

Базовая грамматика описана в rulegen.go:

// rule syntax:
//    sexpr [&& extra conditions] -> [@block] sexpr
//
// sexpr are s-expressions (lisp-like parenthesized groupings)
// sexpr ::= [variable:](opcode sexpr*)
//         | variable
//         | <type>
//         | [auxint]
//         | {aux}
//
// aux      ::= variable | {code}
// type     ::= variable | {code}
// variable ::= some token
// opcode   ::= one of the opcodes from the *Ops.go files

Перевод сниппета выше

// синтаксис правил:
//    sexpr [&& дополнительные условия] -> [@block] sexpr
//
// sexpr - это S-выражений (группирование в стиле Лиспа)
// sexpr ::= [variable:](opcode sexpr*)
//         | variable
//         | <type>
//         | [auxint]
//         | {aux}
//
// aux      ::= variable | {code}
// type     ::= variable | {code}
// variable ::= Go переменная (любой токен)
// opcode   ::= опкод из *Ops.go файла

Стоит также упомянуть, что внутри .Rules файлов разрешены "//" комментарии.

Разберём простой пример, который содержит все эти элементы:

   Opcode=ADDLconst - сложение аргумента с 32-битной константой
     :    AuxInt=c - константа, которая прибавляется к `x`
     :      :
(ADDLconst [c] x) && int32(c)==0 -> x
|              /  |           /     |
|             /   |          /      |
|            /    |         /       Форма для замены
|           /     Условие замены (через `&&` можно добавить ещё условий)
Форма, которую мы пытаемся заменить

Все эти пояснительные подписи не являются частью валидной записи правил.

Данное правило преобразует x+0 в x. Всё внутри секции условий — это обычный Go код,
разве что ограниченный до выражений, результатом которых должен быть bool.
Можно вызывать предикаты, определённые в rewrite.go.

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

(ADD(Q|L)const [off] x:(SP)) -> (LEA(Q|L) [off] x)
// Уберём alternation:
(ADDQconst [off] x:(SP)) -> (LEAQ [off] x)
(ADDLconst [off] x:(SP)) -> (LEAL [off] x)
// Уберём привязку к `x`:
(ADDQconst [off] (SP)) -> (LEAQ [off] (SP))
(ADDLconst [off] (SP)) -> (LEAL [off] (SP))

(SP) — это одна из операций в genericOps.go и выражает загрузку указателя на аппаратный стек. Для архитектур, где аппаратного SP нет, он эмулируется.

Особенности переменных в шаблонах (S-выражения слева от ->):

• Переменные, типа x, без выражения через :, захватывают что угодно.
• аналогично обычной переменной, _ захватывает любое значение, но результат можно игнорировать.

// Оба правила делают одно и то же: реализуют функцию идентичности ADDQconst,
// то есть они возвращают совпавшую с шаблоном форму без изменений:
(ADDQconst _) -> v
(ADDQconst x) -> (ADDQconst x)

Если AuxInt не указан (выражение в квадратных скобках), то правило будет срабатывать на любом значении AuxInt. Аналогично с {}-параметрами (о них ниже).

Имя v означает самую внешнюю захваченную форму.
Например, для выражения (ADDQconst (SUBQconst x)) внешней формой является ADDQconst.

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

(ADDQconst [v] (ADDQconst [v] x))
// Сработает, например, для "x+2+2" (x+v+v).

В некоторых случаях требуется явно указывать тип генерируемой и/или сопостовляемой формы.
Указывается тип в "треугольных скобках", как аргумент-тип в шаблонах C++:

// typ.UIint32 - тип операции BTSLconst.
// BSFL имеет фиксированный тип typ.UInt32, поэтому указывать для
// него тип не требуется.
(Ctz16 x) -> (BSFL (BTSLconst <typ.UInt32> [16] x))

Кроме типов, существуют "символы" (или, более универсально — Aux свойства).

(StaticCall [argsWidth] {target} mem) -> (CALLstatic [argsWidth] {target} mem)

• [argsWidth] — Value.AuxInt. Для StaticCall — суммарный размер передаваемых аргументов.
• {target} — Value.Aux. Для StaticCall — вызываемая функция.
• <typ.UInt32> — Value.Type. Тип значения.

Семантика Aux и AuxInt сильно варьируется от операции к операции. Лучшим источником документации в данном случае являются *Ops.go файлы. У каждого определения опкода opData есть поле aux, которое описывает как именно интерпретировать эти поля.

Для описания типов используется пакет cmd/compile/internal/types. Некоторые типы специфичны для SSA бэкенда, например types.TypeFlags, остальные общие между cmd/compile/internal/gc и cmd/compile/internal/ssa.

Существует особый тип types.TypeMem, который выполняет сразу несколько функций:

1. Позволяет сортировать и группировать ssa.Value по паттернам доступа к памяти. В частности, это гарантирует правильный порядок выполнения в рамках базовых блоков (о них ниже).
2. Определяет состояние потока памяти в программе. Если инструкция модифицирует память, новое SSA значение с типом types.TypeMem будет сгенерировано в результате этой операции.

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

Немного о Phi

Phi имеет роль, которая немного меняется от фазы к фазе.

В самом начале работы SSA части компилятора, Phi служит своей классической цели и выражает выбор значения в зависимости от пути исполнения, который привёл нас к этому значению.

Например, если в блок есть два прыжка, и оба модифицируют память, то блок-назначение получит память равную (Phi mem1 mem2). Циклы также протаскивают Phi значение.

Другим особым типом является упомянутый выше types.TypeFlags. Этот тип описывает генерацию инструкцией CPU флагов.

При этом инструкции, вроде ADDQ, хоть и генерируют флаги, не имеют тип types.Flags, но отмечены атрибутом clobberFlags.

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

Инструкции, вроде SETL позволяют "прочитать" флаги и вернуть их в виде ssa.Value, который может быть размещён в регистре.

 L-less than               G-greater than
 |                         |
(SETL (InvertFlags x)) -> (SETG x)
                   |
                   Форма, генерирующая флаги

Допустим, у нас есть такая программа (example.go):

package example

func fusedMulAdd(a, b, c float64) float64 {
    return a*c + b
}

Мы можем просмотреть SSA код, который сгенерирован для функции fusedMulAdd:

$ GOSSAFUNC=fusedMulAdd go tool compile example.go > ssa.txt

Теперь проверьте рабочую (текущую) директорию:

• ssa.txt содержит тектовой дамп.
• ssa.html, который генерируется автоматически, содержит ту же информацию, но в более интерактивном и удобночитабельном формате. Попробуйте открыть в браузере.

Машинный код для fusedMulAdd

Символ ~r3 переименован в ret для выразительности.

v7  (4) MOVSD a(SP), X0
v11 (4) MOVSD c+16(SP), X1
v12 (4) MULSD X1, X0
v6  (4) MOVSD b+8(SP), X1
v13 (4) ADDSD X1, X0
v15 (4) MOVSD X0, ret+24(SP)
b1  (4) RET

Вот так выглядит SSA программа для fusedMulAdd после фазы lower (ssa.html):

Текстовой формат SSA программы

Если вам почему-то захотелось это скопировать:

lower [77667 ns]
b1:
    v1 (?) = InitMem <mem>
    v2 (?) = SP <uintptr>
    v7 (?) = LEAQ <*float64> {~r3} v2
    v8 (3) = Arg <float64> {a}
    v9 (3) = Arg <float64> {b}
    v10 (3) = Arg <float64> {c}
    v12 (+4) = MULSD <float64> v8 v10
    v13 (4) = ADDSD <float64> v12 v9
    v14 (4) = VarDef <mem> {~r3} v1
    v15 (4) = MOVSDstore <mem> {~r3} v2 v13 v14
Ret v15 (line +4)

Переводя это в S-выражения:

(MOVQstore {~r3} 
           (SP)
           (ADDSD (MULSD (Arg {a})
                         (Arg {c}))
                  (Arg {b})))

SSA после фазы regalloc

Так выглядит вывод ssa.html для фазы regalloc.

regalloc [87237 ns]
b1:
    v1 (?) = InitMem <mem>
    v14 (4) = VarDef <mem> {~r3} v1
    v2 (?) = SP <uintptr> : SP
    v8 (3) = Arg <float64> {a} : a[float64]
    v9 (3) = Arg <float64> {b} : b[float64]
    v10 (3) = Arg <float64> {c} : c[float64]
    v7 (4) = LoadReg <float64> v8 : X0
    v11 (4) = LoadReg <float64> v10 : X1
    v12 (+4) = MULSD <float64> v7 v11 : X0
    v6 (4) = LoadReg <float64> v9 : X1
    v13 (4) = ADDSD <float64> v12 v6 : X0
    v15 (4) = MOVSDstore <mem> {~r3} v2 v13 v14
Ret v15 (line +4)

На процессорах с FMA мы можем вычислять a*c + b за одну инструкцию вместо двух.

Возьмём за основу CL117295 за авторством Ильи Токаря.

Для вашего удобства, я подготовил минимальный diff патч:
https://gist.github.com/Quasilyte/0d4dbb0f8311f38d00a7b2d25dcec704.

1. Добавление новой операции — FMASD

В файле compile/internal/ssa/gen/AMD64Ops.go найдите переменную-слайс AMD64ops и добавьте туда новый элемент (в любое место):

{ // fp64 fma
  name: "FMASD",      // Опкод для SSA
  argLength: 3,
  reg: fp31,          // Информация для regalloc, спецификатор регистров
  resultInArg0: true, // Первый аргумент является и source, и destination
  asm: "VFMADD231SD", // Ассемблерный опкод
},

Поскольку ранее (fp,fp,fp -> fp) операций не было, нужно определить новый спецификатор:

  fp01     = regInfo{inputs: nil, outputs: fponly}
  fp21     = regInfo{inputs: []regMask{fp, fp}, outputs: fponly}
+ fp31     = regInfo{inputs: []regMask{fp, fp, fp}, outputs: fponly}

2. Добавление правила оптимизации

(ADDSD (MULSD x y) z) -> (FMASD z x y)

Более правильная реализация не была бы безусловной и проверяла бы доступность FMA. Мы будем считать, что на нашей целевой машине FMA точно есть.

В компиляторе для подобных проверок используется config:

// Если config.useFMA=false, оптимизация выполняться не будет.
(ADDSD (MULSD x y) z) && config.useFMA-> (FMASD z x y)

Как проверить поддержку FMA?

Если в системе доступен lscpu, то, например так:

$ lscpu | grep fma

3. Реализация кодогенерации

Теперь в функцию ssaGenValue, определённую в файле compile/internal/amd64/ssa.go, нужно добавить кодогенерацию для FMASD:

func ssaGenValue(s *gc.SSAGenState, v *ssa.Value) {
  switch v.Op {
  case ssa.OpAMD64FMASD:
    p := s.Prog(v.Op.Asm())
    p.From.Type = obj.TYPE_REG
    p.From.Reg = v.Args[2].Reg()
    p.To.Type = obj.TYPE_REG
    p.To.Reg = v.Reg()
    p.SetFrom3(obj.Addr{
      Type: obj.TYPE_REG,
      Reg: v.Args[1].Reg(),
    })
    if v.Reg() != v.Args[0].Reg() {
      s := v.LongString()
      v.Fatalf("input[0] and output not in same register %s", s)
    }
  // Остальной код остаётся неизменным, мы только добавляем новый case.
  }
}

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

Первым шагом является генерация Go кода из обновлённых gen/AMD64Ops.Go и gen/AMD64.Rules.

cd $GOROOT/src/cmd/compile/internal/ssa/gen && go run *.go

Далее нужно собрать наш новый компилятор:

go install cmd/compile

Теперь при компиляции того же примера, мы получим иной машинный код:

- v7  (4) MOVSD a(SP), X0
- v11 (4) MOVSD c+16(SP), X1
- v12 (4) MULSD X1, X0
- v6  (4) MOVSD b+8(SP), X1
- v13 (4) ADDSD X1, X0
- v15 (4) MOVSD X0, ret+24(SP)
- b1  (4) RET
+ v12 (4) MOVSD b+8(SP), X0
+ v7  (4) MOVSD a(SP), X1
+ v11 (4) MOVSD c+16(SP), X2
+ v13 (4) VFMADD231SD X2, X1, X0
+ v15 (4) MOVSD  X0, ret+24(SP)
+ b1  (4) RET

Теперь, когда самая сложная работа сделана, поговорим о базовых блоках.

Значения, которые мы оптимизировали выше, находятся в блоках, а блоки находятся в функции.

Блоки, как и ssa.Value, бывают абстрактными и машино-зависимыми. Все блоки имеют ровно одну точку входа и от 0 до 2 точек выхода (зависит от типа блока).

Самыми простыми блоками являются If, Exit и Plain:

• Exit блок имеет 0 точек выхода. Это листовые блоки, которые совершают нелокальный прыжок, например, с помощью panic.
• Plain блок имеет 1 точку выхода. Можно рассматривать как безусловный переход после выполнения всех инструкций блока в другой блок.
• If блок имеет 2 точки выхода. Переход осуществляется в зависимости от условия (Block.Control).

Вот простые примеры переписывания абстрактных блоков в блоки AMD64:

                Тело "then" (является блоком)
                |   Тело "else" (является блоком)
                |   |
(If (SETL  cmp) yes no) -> (LT cmp yes no)
(If (SETLE cmp) yes no) -> (LE cmp yes no)

Тему блоков более подробно будем рассматривать в контексте других оптимизирующих фаз в SSA части компилятора.

У SSA бэкенда есть свои преимущества. Некоторые оптимизации выполнимы за O(1). Однако есть и недостатки, из-за которых одного лишь SSA оптимизатора будет маловато, по крайней мере пока не изменятся некоторые аспекты его реализации.

Предположим, вы хотите выполнять слияние вызовов append:

xs = append(xs, 'a')
xs = append(xs, 'b')
// =>
xs = append(xs, 'a', 'b')

На момент, когда SSA сгенерирован, высокоуровневая структура кода утрачена и append, будучи не обычной функцией, уже встроен в тело содержащего блока. Вам придётся писать громоздкое правило, которое захватывает всю сгенерированную для append последовательность операций.

Если говорить конкретно о .Rules, то в этом DSL довольно слабая работа с блоками (ssa.Block). Любая нетривиальная оптимизация, связанная с блоками, невозможна для выражения на этом языке. Частичное обновление блока невозможно. Выбрасывать блоки тоже невозможно (но есть хак в виде First блока, который используется для удаления мёртвого кода).

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

Если придумаете какие-то крутые правила оптимизации, смело высылайте на go-review.googlesource.com. Буду рад произвести ревью (добавляйте в CC iskander.sharipov@intel.com).

Счастливого хакинга компилятора!

Бонусный материал

Примеры хороших патчей в Go, которые добавляли или изменяли SSA rules:

Не так давно появился README документ для описания SSA части компилятора.
Рекомендуется к прочтению.

Let's block ads! (Why?)

[Перевод] Как сделать всё самому: открытые модульные системы

Возвращение традиционных ремёсел — один из способов саботировать современную индустрию одноразовых вещей. В данной статье рассматривается другой вариант: проектирование модульных потребительских товаров, детали и компоненты которых используются повторно в других объектах.

Инициативы OpenStructures, Grid Beam и Contraptor сочетают модульность систем в стиле LEGO, Meccano и Erector с силой коллективного сотрудничества, как в Википедии и Linux.

Экономика, основанная на концепции повторного использования, не только принесёт важные преимущества с точки зрения устойчивости, но и сэкономит деньги потребителей, ускорит инновации и выведет производство из-под контроля транснациональных корпораций.
Модульная система сочетает преимущества стандартизации (поскольку детали можно дёшево производить в большом количестве) с преимуществами кастомизации (большое разнообразие уникальных объектов делаются из относительно небольшого количества частей). Модульность в той или иной степени присутствует во многих продуктах (например, велосипеды и компьютеры) и системах (например, поезда и логистика), но лучшими примерами модульных систем являются игрушки: LEGO, Meccano и Erector (который теперь стал брендом Meccano в США).

LEGO, Meccano и Erector состоят из относительно небольшого количества простых блоков, из которых строятся различные объекты. После этого части демонтируются и повторно используются для чего-нибудь совершенно другого. Кроме элементарных блоков зданий, существует много более специфических строительных блоков, которые менее универсальны, но добавляют разнообразия.

Все строительные блоки в наборах LEGO, Meccano и Erector подходят друг к другу, потому что разработаны в соответствии с конкретным набором правил. У отверстий (Meccano и Erector) или шипов (LEGO) точный диаметр и они находятся на конкретном расстоянии. Кроме этого, размеры строительных блоков точно соответствуют друг другу. Продолжительный успех LEGO, Meccano и Erector (появившихся на рынке в 1947, 1902 и 1911 годах, соответственно) основан на том, что эти правила никогда не менялись. Все новые строительные блоки в течение многих лет совместимы с предыдущими. Сегодня малыши могут расширить свою коллекцию игрушек детальками, с которыми игрались родители, бабушки и дедушки, а на рынке эти детали стоят столько же, сколько новые.

Grid Beam, Bit Beam, Open Beam, Maker Beam и Contraptor

Тот же принцип применим к повседневным предметам: от кофеварки до мебели, гаджетов, автомобилей и систем возобновляемой энергии. Нужна только стандартизация на уровне дизайна. Правила проектирования могут быть очень простыми, как в случае с Grid Beam. Эта модульная система, разработанная в 1976 году, основана на брусах с простой геометрией и повторяющимся паттерном отверстий. Брусы можно делать из древесины, алюминия, стали или любого другого материала.

Несмотря на простоту, доступно большое разнообразие объектов. На базе Grid Beam делали все виды мебели, теплицы, конструкций для цехов и производственных процессов, ветряные мельницы, тачки, сельскохозяйственную технику, транспортные средства, сараи и здания (книга об этой модульной системе опубликована в 2009 году и её можно найти в онлайне). Grid Beam создана на основе идей Кена Айзекса и придуманной им в 50-е годы системы Living Structures, где использовались такие же балки, только с меньшим количеством отверстий.

В последние годы появилось несколько систем, которые используют очень похожий набор правил, основанный на повторяющейся системе отверстий. Bit Beam — это по сути масштабированная версия Grid Beam, только для конструкций меньшего размера из пробкового дерева типа подставки для ноутбука или прототипов. Contraptor использует аналогичный подход, но специализируется на структурных металлических рамках для DIY 3D-принтеров, фрезерных станков и робототехники. OpenBeam и MakerBeam — тоже модульные конструкции на очень простых правилах. Там структура основана не на паттерне отверстий, а на T-образных алюминиевых пазах. Makeblock совмещает оба подхода и включает электронные модули.

Большинство этих систем ограничены проектированием каркасов. Но есть одна система, которая предлагает гораздо больше возможностей, потому что основана на более сложном наборе правил: OpenStructures. Проект стартовал в Брюсселе в 2007 году. В отличие от всех вышеперечисленных, проект OpenStructures всё ещё находится в экспериментальной фазе. Однако интересно посмотреть на него более подробно, потому что он лучше всего демонстрирует потенциал модульных строительных конструкций.

OpenStructures

Первое основное правило OpenStructures совпадает с правилом Grid Beam и подобных систем: все части соединяются друг с другом так, чтобы их можно было легко демонтировать, используя болты и винты, а не гвозди или клей. Тем не менее, дизайнерский «язык» OpenStructures отличается: он основан на сетке OS Grid, которая базируется на квадратах 4×4 см и масштабируется. Квадраты тоже делятся на части или объединяются и формируют ещё бóльшие квадраты, не теряя совместимости друг с другом. На рисунке показаны девять полных квадратов по 4×4 см, совмещённых вместе.

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

Хотя такой набор правил сложнее, чем система Grid Beam, он довольно простой. Тем не менее, он позволяет создавать гораздо большее разнообразие объектов, а не только квадратные или прямоугольные рамки. В течение пяти лет на основе OpenStructures создавались разнообразные объекты, начиная от бытовых устройств до грузовых велосипедов, чемоданов и мебели.

Открытые и закрытые модульные системы

Несмотря на сходства, между модульными системами OpenStructures, Grid Beam, Contraptor и модульными игрушками LEGO, Meccano и Erector есть одно принципиальное отличие. Первая группа состоит из «открытых» модульных систем, где каждый может свободно проектировать и производить детали, в то время как вторая состоит из «закрытых» модульных систем, где все детали проектируются и производятся одним производителем. Закрытые модульные системы производят единообразные части. Например, все блоки LEGO сделаны из пластика. Компания LEGO не производит блоки из дерева, алюминия, стекла или керамики. Существует ограниченный диапазон цветов. Всё потому что LEGO — это закрытая система. Никому не разрешено изготавливать её кубики.

Существуют модульные системы, которые работают по тем же закрытым принципам, как T-профили от компании 80/20 inc. Но в упомянутых выше модульных системах всем позволено конструировать и производить детали, совместимые с основным набором правил. Аналогичный подход действует в области открытого программного обеспечения, такого как как Linux (операционная система), OpenOffice (офисное программное обеспечение) или WordPress (платформа блогов). Компьютерный код для этих систем пишет много людей, каждый из которых строит часть чего-то большего. Поскольку все участники придерживаются базового набора правил, большое количество людей независимо друг от друга добавляют совместимые детали.

Потребительские товары на открытой модульной системе могут способствовать быстрым инновациям без потерь энергии и материалов

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

Долговременные потребительские товары

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

Потребительские товары на открытой модульной системе способствуют быстрым инновациям без потерь энергии и материалов. Детали устаревшего поколения продуктов можно использовать в следующем поколении или в совершенно ином продукте. Кроме того, модульные объекты ремонтопригодны по определению.

Открытые модульные системы значительно ускорят взаимопроникновение «низких технологий», как педальные машины, солнечные термоколлекторы, веломобили и грузовые велосипеды. Строительство ветряной мельницы или грузового велосипеда идёт гораздо быстрее с модульными деталями, чем со столярной работой или сваркой, и нет необходимости в дорогостоящих инструментах или специальных навыках. Ошибки легко исправляются — просто открутите болты и начните заново. Было бы интересно посмотреть на интеграцию модульных частей с другим проектом open hardware, таким как Global Village Construction Set, где создаётся много интересных дизайнов, но модульность ограничена.

Циркуляция деталей

«В то время как eBay обеспечивает циркуляцию товаров, а безотходные системы производства обеспечивают циркуляцию материалов, модульные системы обеспечивают циркуляцию деталей и компонентов, — говорит Томас Ломми, создатель OpenStructures. — Наша цель — создавать мозаику вместо статичных объектов. Система должна генерировать объекты, из которых не совсем понятно, кто их проектировал. Объект эволюционирует по мере того как проходит через руки большего количества дизайнеров».

Кухонные приборы OpenStructures

Хороший пример — кухонные приборы, разработанные в рамках проекта. Несколько частей изначально сделали для кофемолки, затем другой дизайнер использовал их вместе с новыми частями для кофеварки. Потом третий дизайнер доработал проект и создал устройство для очистки воды. Пластиковую бутылку, служившую в качестве ёмкости для воды, заменили прорезанной стеклянной бутылкой с глиняным фильтром. Томас Ломме говорит: «Добавляя или удаляя компоненты или используя их по-другому, вы получаете семейство объектов».

Грузовой велосипед

Ещё один прототип из этого проекта — грузовой велосипед. Задняя часть отпиливается от рамы обычного велосипеда, остальные детали совместимы с OS Grid. Это значит, что переднюю часть можно сделать модульной. Дизайнер Джо Ван Бостратен использовать эту возможность, чтобы спроектировать и грузовой велосипед, и грузовой трицикл (последний перевозит 3D-принтер), и это еще не всё. Вместе с Ломми они сконструировали модульный мотоблок. Он состоит из электрического двигателя и колёс, поверх которых размещается также модуль с батареей. Поскольку блоки совместимы с решеткой OS Grid, их можно установить впереди грузового велосипеда, получив полностью модульное моторизованное транспортное средство.

Последнее «семейство» этого проекта предназначено для детей. Примечательно, что оно выросло из одного компонента грузового велосипеда — из контейнера. Он состоит из модульных частей, скреплённых болтами, и эти части можно скрепить разными способами. Несколько дизайнеров поигрались с этими деталями, в результате чего (среди прочего) возникли сани, сиденье, игрушечный экскаватор и качели. Когда ребёнок подрастает, можно сделать чемодан или ящик для инструментов, или использовать в том же грузовом велосипеде — и зарабатывать карманные деньги.

Объекты с открытым исходным кодом

Система поддержки пользователей интереснее самих объектов. Grid Beam — очевидно, продукт доинтернетовской эпохи. Чтобы скопировать дизайн, рекомендуется посмотреть на его фотографию и «посчитать отверстия». С другой стороны, OpenStructures опирается на онлайн-поддержку пользователей. Для повторного использования деталей создана онлайновая база данных, которую можно использовать тремя способами.

Модульная база данных

Во-первых, можно вывести все объекты, разработанные на основе OS Grid. Страница каждого объекта показывает его детали и компоненты. Во-вторых, вы вывести все детали, созданные на основе OS Grid. Страница каждой детали показывает, в каких компонентах и объектах её можно применить. Наконец, можно посмотреть все компоненты со списком их деталей и объектов, для которых компоненты можно использовать.

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

Страница каждой детали, компонента и объекта также содержит дополнительную информацию: размеры, материалы, имя дизайнера, лицензию и информацию о заказе. Вдобавок, у деталей и компонентов есть серийные номера. Значит, после разборки модульного объекта серийный номер каждой части и компонента можно вписать в БД и посмотреть, что ещё с ним сделать. Недостающие части тоже добываются из базы данных: вы либо находите адрес магазина, где они продаются, и делаете заказ, либо загружаете цифровую модель и сами делаете деталь.

Не каждый может стать дизайнером

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

Модульные части бойлера

Второй вариант: компания покупает лицензию на дизайн (если она не бесплатна) и создаёт комплект для сборки по типу LEGO, Meccano или Erector. В этом случае потребителям не нужно самостоятельно искать запчасти, но человек всё равно сам собирает изделие, как мебель IKEA. Точно так же компания может предложить более универсальный комплект для сборки разнообразных вещей, как комплект основных кубиков конструктора. Bit Beam, Contraptor, Open Beam, Maker Beam и с недавних пор Grid Beam предлагают один или оба этих варианта.

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

Экономическая модель: кто производит детали?

Хотя проектирование OpenStructures и других открытых модульных систем идентично процессу проектирования цифровых продуктов, таких как Википедия, Linux или WordPress, существует и фундаментальное различие. Машинный код и цифровой текст накапливаются без материальных затрат. В материальном мире это не так. Поэтому создание модульных систем не так просто, зато открывает экономические возможности. На открытом ПО или онлайн-статьях трудно заработать деньги. Но в случае открытой модульной системы для объектов кто-то должен предоставить материалы.

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

Модульный тостер

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

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

Коллективная экономика

«Мы не собираемся строить гигантский завод, который производит все возможные детали, — пишет Ломми. — OpenStructures не должна стать модульной версией IKEA. Наша цель — создание коллективной экономической системы, в которой один производитель получает выгоду от продукции другого производителя. Потому что детали одного могут использовать другие. Мы хотели бы видеть много маленьких магазинчиков, где каждый немножко добавляет в коллективную экономику, а не одного гиганта, производящего всё. Социальное измерение очень важно».

Части Contraptor

«Если IKEA хочет продавать товар, совместимый с нашей системой, то это нормально. Но система может работать только в том случае, если остаётся открытой. Чем больше система, тем легче небольшой компании или ремесленнику стать её частью. Цель в том, чтобы запустить универсальный, коллективный конструктор, чтобы самый широкий круг людей — от мастеров до транснациональных корпораций — проектировал, строил и обменивался самым широким спектром модульных деталей и компонентов».

Организация повторного использования

Кроме языка проектирования (OS Grid) и онлайновой базы данных, компания OpenStructures создала ещё прототип склада в Брюсселе. Это место должно стать центром организации повторного использования деталей и компонентов. Представьте фаблаб или магазин, но с хранением модульных деталей. Если модульный товар больше не нужен и владелец не собирается использовать его детали в новых объектах, то приносит в одно из таких мест. Здесь предмет разбирается, а детали помещаются на хранение.

Открытая модульная система предлагает экономические возможности для каждого

Люди могут прийти, купить запчасти или прямо на месте собрать что-то новое. Как говорит Ломме: «Не каждый должен собирать собственные изделия, но после истечения срока службы модульный продукт всегда попадёт в руки людей, которые любят мастерить».

Совместимость между открытыми модульными системами

OpenStructures пока находится в экспериментальной фазе, но это самая честолюбивая и самая цельная открытая модульная система на сегодняшний день. Будучи европейским проектом, она следует международной метрической системе, в то время как гораздо более старый проект Grid Beam использует имперскую систему. Эти системы несовместимы между собой. С появлением всё более открытых модульных систем разве не важно обеспечить совместимость между ними?

Makeblock

Ломми так не считает: «Большинство этих систем предназначены для различных приложений. Например, Contraptor нацелен на точность, потому что детали используются для создания роботов и других сложных машин. Эстетика вообще не важна. Я дизайнер, поэтому меня особенно интересует, можно ли делать на основе модульной системы красивые объекты — вещи, которые вы хотелось бы поставить дома. Есть ещё Wikispeed, например, где создаётся модульный автомобиль. Проект Arduino нацелен на электронику. Я не думаю, что все эти модульные системы должны быть совместимы друг с другом, поскольку приложения очень разные».

Open Beam

Далее он объясняет, почему выбрал метрическую систему. «Я много сомневался. Но в итоге решил, что с метрической системой легче работать. И думаю, что в мире есть место для обеих систем: просто посмотрите на разнообразие энергетических стандартов. Кто-то уже разработал европейскую версию Contraptor, основанную на метрической системе и совместимую с OS Grid. И всегда есть способ соединить эти системы и использовать совместно. С другой стороны, мы живём в сетевом мире со сплошными связями и копиями. Часто это означает, что при конкуренции стандартов выживает только один. И необязательно лучший. Так что скрестим пальцы».

Статья написана в декабре 2012 года

Let's block ads! (Why?)

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

Если бы человеку предоставили доступ к неограниченному количеству благ — например, если он может выбирать идеальные уровни продолжительности жизни, интеллекта, свободы, самооценки, здоровья, удовольствия и счастья — что он выберет, какие уровни? В психологии существует принцип максимизации, когда для идеального случая человек выбирает максимально возможную сумму параметров, которые считает позитивными. В соответствии с этим принципом, человек выберет максимально возможные уровни по каждому параметру.

В работе Говарда «Адаптация человеческого образа жизни к 21 веку» (2000) максимизация описана как «самое основное неисследованное предположение о человеческой природе». Психологи предполагали, что это нечто само собой разумеющееся: каждый выбирает максимально выгодные условия. Например, у человека есть фундаментальное желание сохранить себе жизнь (см. теорию управления страхом смерти, работа Соломона и др., 1991), чувствовать самостоятельность (Райан и Дечи, 2017), быть счастливым (Кесибир и Динер, 2008), чувствовать безопасность (Маслоу, 1943), иметь самоуважение (Лири и др., 1995) и так далее. Принцип максимизации оказывает важное влияние на экономику как предиктор поведения потребителей.

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

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

Исследование показало, что принцип максимизации вовсе не так распространён, как принято считать. «Наше исследование показало, что чувство совершенства у людей удивительно скромное, — говорит психолог Мэтью Дж. Хорнси (Matthew J. Hornsey) из университета Квинсленда, ведущий исследования. — Люди хотят иметь положительные качества, такие как здоровье и счастье, но не исключают плохих переживаний: они хотят примерно 75% хороших».

Желаемая продолжительность жизни составила в среднем 90 лет, что лишь немного превышает нынешнюю среднюю продолжительность жизни. Даже когда участники представляли себе, что они могут принять волшебную пилюлю, гарантирующую вечную молодость, то идеальная продолжительность жизни увеличилась всего на несколько десятилетий, до 120 лет по медиане (с вечной молодостью, см. таблицу ниже). А когда людям предлагали выбрать идеальный IQ, средний балл оказался около 130. Это умный человек, но не гений.

В первом исследовании приняли участие 2392 участника из Австралии, Чили, Китая, Гонконга, Индии, Японии, Перу, России и США. Исследователи классифицировали Китай, Гонконг, Индию и Японию как целостные культуры, преимущественно под влиянием религий или философий, которые акцентируют целостное мировоззрение. Соответственно, Австралия, Чили, Перу, Россия и США классифицированы как нехолистические культуры.

Используя шкалу от 0 (нет) до 100 (максимум), участники указали в опроснике свой идеальный уровень здоровья, индивидуальной свободы, счастья, удовольствия и самооценки. Они использовали ту же шкалу для оценки идеальных уровней социальных характеристик, таких как мораль, равенство возможностей, технический прогресс и национальная безопасность.

В целом участники, как правило, оценивали свои идеальные уровни индивидуальных характеристик примерно на 70−80%, хотя были некоторые различия. Например, гораздо больше участников предпочли максимизировать здоровье, чем максимизировать счастье. Идеалы участников оказались относительно скромными как для интеллекта, так и для долголетия, даже когда не было никаких ограничений по уровням.

В таблице показаны результаты опроса. Последняя колонка соответствует желаемому долголетию при сохранении молодости (среднее по медиане), предпоследняя — без сохранения молодости.

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

Второе исследование с 5650 участниками в 27 странах показало схожие результаты.

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

Научная статья опубликована 11 июня 2018 года в журнале Psychological Science (doi:10.1177/0956797618768058).

Let's block ads! (Why?)

Аппаратное кодирование видео потока на камере Logitech C920 и отправка его в ROS по wifi с задержкой менее 0.2 секунды

В этой инструкции мы отправим аппаратно закодированный h264 видео поток камеры Logitech C920 переданный c BeagleBone Blue по wifi сети на ноутбук, а затем примем его в узел ROS gscam и произведем поиск и распознавание изображений карт таро и бутылки кетчупа по пути движения робота EduMIP.
Это продолжение серии моих статей, в последней мы остановились на том что через gstreamer отправили видео на ноутбук.

В ROS есть пакет который умеет принимать видео от gstreamer, который называется gscam, вот документация по нему и исходный код.

Нам нужна последняя версия gscam c поддержкой gstreamer-1.0, поэтому будем устанавливать из последней версии исходного кода.

cd catkin_ws/src
git clone https://github.com/ros-drivers/gscam
cd ..
catkin_make -DGSTREAMER_VERSION_1_x=On

Теперь нам нужно создать launch файл и вписать туда команду gstreamer которая отправит видео в ffmpegcolorspace.

-v udpsrc port=6666 ! application/x-rtp, encoding-name=H264 ! rtph264depay ! h264parse ! avdec_h264 ! videoconvert ! ffmpegcolorspace

Итоговый файл ~/catkin_ws/src/gscam/examples/streamc920.launch будет выглядеть так:

<launch>
  <!-- Set this to your camera's name -->
  <arg name="cam_name" value="creative_cam" />

  <!-- Start the GSCAM node -->
  <env name="GSCAM_CONFIG" value="-v udpsrc port=6666 ! application/x-rtp, encoding-name=H264 ! rtph264depay ! h264parse ! avdec_h264 ! videoconvert ! ffmpegcolorspace" />
  <node pkg="gscam" type="gscam" name="$(arg cam_name)">
    <param name="camera_name" value="$(arg cam_name)" />
    <param name="camera_info_url" value="package://localcam/calibrations/${NAME}.yaml" />
    <remap from="camera/image_raw" to="$(arg cam_name)/image_raw" />
  </node>

  <!-- Provide rectification -->
  <node pkg="image_proc" type="image_proc" name="creative_image_proc"
        ns="$(arg cam_name)" />

  <!-- View the raw and rectified output -->
  <node pkg="image_view" type="image_view" name="creative_view" >
    <remap from="image" to="/$(arg cam_name)/image_raw" />
  </node>
</launch>

Теперь если мы его запустим:

roslaunch gscam streamc920.launch

Появится оно видео потока с камеры, теперь мы в ROS имеем это видео как topic creative_cam/image_raw.

Из одного из прошлых уроков запустим поиск и распознавание изображений карт изменив топик:

rosrun find_object_2d find_object_2d image:=/creative_cam/image_raw

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

Также я соединил ноутбук с wifi роутером витой парой и понизил битрейт до 1 Мбит/с с ключевыми кадрами раз в секунду, что уменьшило задержку передачи видео до 0.2 секунды.

gst-launch-1.0 uvch264src initial-bitrate=1000000 average-bitrate=1000000 iframe-period=1000 name=src auto-start=true src.vidsrc ! video/x-h264,width=160,height=120,framerate=30/1 ! h264parse ! rtph264pay ! udpsink host=192.168.1.196 port=6666

Для тех кто хочет в живую посмотреть на робота буду 7 июля выступать с проектом EduMIP на DIYorDIE Meetup в Москве.

Let's block ads! (Why?)