Источник: Nature

Некоторое время назад на Хабре была опубликована заметка о возможностях 3D SEM-микроскопии применительно к исследованию структуры человеческого мозга в рамках европейского мегапроекта «The Human Brain Project». Под катом мы постарались максимально подробно – а это значит будет много текста – ответить на заданные вопросы, но начнём по традиции с некоторого введения.
Attention! Впереди очень много текста

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

В конце поста Вы сможете так же задать вопросы человеку, непосредственно работающему в команде The Blue Brain Project, ответы на которые выйдут отдельным постом.

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

Использованные термины

УСМ – ударно-спусковой механизм

Метрическое обозначение патрона — состоит из двух чисел, первое из которых означает калибр, второе – длину гильзы. Например, 9х19 говорит о том, что 9мм – калибр, а длина гильзы 19мм. Но это обозначение все равно во многом номинально.

Пистолетный патрон – небольшой патрон с короткой тупоконечной пулей и с зарядом быстрогорящего пороха менее 0.5г. Напр. 9х19, 7.62х25, 9х18 и т.д.



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

Напр. 7.62х54R, 7.62х51, 7.92х57.



Промежуточный, переходной патрон – патрон по мощности промежуточный между пистолетным и винтовочным. Создан для автоматов, но находит широкое применение и в ручных пулеметах. Гильза бутылочной формы, масса порохового заряда ок. 1.5 г пороха со средней скоростью горения.

Напр. 7.92х33, 7.62х39.



Малоимпульсный патрон – условный тип промежуточного патрона, появившийся впервые в винтовке М16. Представляет собой промежуточный патрон, однако с дальнейшим уменьшением размеров и калибром ок. 5.5мм. Свое название получил из-за уменьшенного импульса отдачи. Масса порохового заряда ок. 1.5 г, порох обычно того же типа что и в промежуточном патроне.

Напр. 5.56х45, 5.45х39, 5.8х42.



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

Это продолжение, началу тут.

Используемые термины:

Карабин – нечто укороченное (для стрельбы с двух рук). Изредка использовалась терминология, в которой карабин отличали от полноразмерной винтовки по числу калибров на длину ствола. С появлением малоимпульсных патронов с калибром ок. 5мм и автоматов с длинными стволами в схеме булл-пап, она потеряла смысл, т.к. в семействе получалось, что карабина нет вообще при том, что официально такой статус носило несколько образцов.

В прошлый раз мы остановились на последней четверти 19-го века, когда армии ведущих государств оказались вооружены казнозарядными винтовками под патрон с металлической гильзой. По большей части это были достаточно совершенные модели с продольно-скользящим затвором; значительная часть из них успеет даже застать Первую мировую, но лишь в руках у ополченцев и войск последней очереди. Отсюда, собственно, и штамп о стороже с берданкой (т.е. винтовкой Бердана №2) в русской культуре. Действительно, в межвоенный и послевоенный период это оружие могло быть табельным для охранников неважных складов. Впрочем, воображение чаще всего рисует берданку в виде двуствольного охотничьего ружья, а не винтовки. Рекорды службы для этого поколения оружия побила, вероятно, британская винтовка Генри-Мартини, которую периодически находят у различных террористов по сей день. Почему бы не включить воображение и не подумать, что же в винтовках можно усовершенствовать еще?

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

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

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

Вдохновением послужила эта статья: Разбираемся в С, изучая ассемблер. Продолжение так и не вышло, хотя тема интересная. Многие бы хотели писать код и понимать, как он работает. Поэтому я запущу цикл статей о том, как выглядит Си-код после декомпиляции, попутно разбирая основные структуры кода.

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

19 октября 2017 года команда Deepmind опубликовала в Nature статью, краткая суть которой сводится к тому, что их новая модель AlphaGo Zero не только разгромно обыгрывает прошлые версии сети, но ещё и не требует никакого человеческого участия в процессе тренировки. Естественно, это заявление произвело в AI-коммьюнити эффект разорвавшейся бомбы, и всем тут же стало интересно, за счёт чего удалось добиться такого успеха.

По мотивам материалов, находящихся в открытом доступе, Семён sim0nsays записал отличный стрим:


А для тех, кому проще два раза прочитать, чем один раз увидеть, я сейчас попробую объяснить всё это буквами.

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

Ну, поехали.

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

string s = "";
for (int i = 0; i < 100000; i++) s += "a";

работает так медленно.

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

Краткое содержание: разработка модуля совместимости с ОС Колибри внутри модуля совместимости с ОС Юникс внутри ОС Фантом)

Внутри ОС Фантом есть маленький простенький Юникс. POSIX подсистема. В принципе необязательная для работы самого Фантома и довольно неполная — Unix Quake под ней собрать удалось, а, например, апач не соберётся почти наверняка. Тем не менее — она есть.

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

Почему же, тем не менее, любопытно реализовать слой совместимости с этой ОС? Тому несколько причин:

• Она очень компактна. Забегая вперёд — первую программу для Колибри в Фантоме удалось запустить через четыре часа работы.
• Этот мини-проект стал драйвером развития некоторых нативных подсистем Фантома,
  в частности — оконной.
• Главное — всё состояние процесса Колибри, известное ядру, укладывается в небольшую структуру. Многие (почти все!) вызовы — stateless, то есть не опираются о какое-либо знание,
  хранимое в ядре. Это идеальный кандидат на реализацию персистентных (переживающих перезапуск ОС) бинарных (не написанных на байткод-языке) процессов в Фантоме.

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

Для начала введём определение bus master: устройство, способное быть не только ведомым, но и ведущим на шине компьютера. То есть — не только отвечать на транзакции ввода-вывода, инициированные процессором, но и самостоятельно их инициировать — по собственной инициативе «ходить» в память.

История таких устройств уходит корнями в понятие DMA: ещё во времена прародителя микропроцессоров, микропроцессора 8080 (КР5080ИК80), появилось понимание, что процессор хорошо бы разгрузить от рутинной операции перетаскивания байтиков между устройствами в-в и памятью.

Сегодня выходной, так что напишу коротко про мелочи, до которых, как правило, руки не доходят.

TCP FS

Есть ещё одна вещь, которой нет в современном Юниксе и которую я хочу иметь в unix box фантома. Она проста как мычание, и почему её никто не сделал — непостижимо:

#cat /tcp/host/port > local_file

Правда, я хочу использовать иной синтаксис имени файла, URL style — tcp://host:port, но это уже детали. Естественно, наравне с TCP просится UDP, и там вообще проблем нет.



Для TCP есть очевидная проблема — нужен ли нам listen или connect, но её можно решить через указание в имени «файла» определённого суффикса.

Сказать на эту тему настолько больше нечего, что перейдём без остановки к следующей.

TRFS — тривиальная дистанционная файловая система.

Статья-гипотеза. Описанное нигде не было реализовано, хотя, в принципе, ничто не мешает запилить такое в Фантоме.

Эта идея пришла мне в голову очень давно и даже где-то была мной описана. Триггер к тому, чтобы её описать сегодня — обсуждение сетевых драйверов Линукса в комментариях к Анатомии драйвера.

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

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

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

Мне эта идея пришла когда я рассматривал совершенно фантастические модели для Фантом, включая акторную модель с запуском нити вообще на любой вызов функции/метода. Саму модель я отбросил, а вот идея lazy threads осталась и до сих пор кажется интересной.

Как это.

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

Я попробую выделить некоторые общие правила и каноны в этой области. Как всегда — на примере Фантома.

Драйвер — функциональная компонента ОС, ответственная за отношения с определённым подмножеством аппаратуры компьютера.

С лёгкой руки того же Юникса драйвера делятся на блочные и байт-ориентированные. В былые времена классическими примерами были драйвер диска (операции — записать и прочитать сектор диска) и драйвер дисплея (прочитать и записать символ).

В современной реальности, конечно, всё сложнее. Драйвер — типичный инстанс-объект класса, и классов этих до фига и больше. В принципе, интерфейс драйверов пытаются как-то ужать в прокрустово ложе модели read/write, но это самообман. У драйвера сетевой карты есть метод «прочитать MAC-адрес карты» (который, конечно, можно реализовать через properties), а у драйвера USB — целая пачка USB-специфичных операций. Ещё веселее у графических драйверов — какой-нибудь bitblt( startx, starty, destx, desty, xsize, ysize, operation ) — обычное дело.

Цикл жизни драйвера, в целом, может быть описан так:

• Инициализация: драйвер получает ресурсы (но не доступ к своей аппаратуре)
• Поиск аппаратуры: драйвер получает от ядра или находит сам свои аппаратные ресурсы
• Активация — драйвер начинает работу
• Появление/пропадание устройств, если это уместно. См. тот же USB.
• Засыпание/просыпание аппаратуры, если это уместно. В контроллерах часто неиспользуемая аппаратура выключается для экономии.
• Деактивация драйвера — обслуживание запросов прекращается
• Выгрузка драйвера — освобождаются все ресурсы ядра, драйвер не существует.

(Вообще я написал в прошлом году черновик открытой спецификации интерфейса драйвера — см. репозиторий и документ.)

Мне известны три модели построения драйвера:

• Поллинг
• Прерывания
• Нити (threads)

Это — статья-вопрос. У меня нет идеального ответа на то, что здесь будет описано. Какой-то есть, но насколько он удачен — неочевидно.

Статья касается одной из концептуальных проблем ОС Фантом, ну или любой другой системы, в которой есть персистентная и «волатильная» составляющие.

Для понимания сути проблемы стоит прочесть одну из предыдущих статей — про персистентную оперативную память.

Краткая постановка проблемы: В силу того, что прикладная программа в ОС Фантом персистентна (не перезапускается при перезагрузке), а ядро — нет (перезапускается при перезагрузке и может быть изменено между запусками), в такой системе нельзя делать блокирующие системные вызовы. Обычным способом.

В процессе работы над ОС Фантом, которая вообще не Юникс никаким местом, мне, тем не менее, захотелось сделать в нём Unix-compatible подсистему. Не то, чтобы прямо POSIX, но что-то достаточно близкое. Отчасти из любопытства, отчасти для удобства, отчасти как ещё один migration path. (Ну и вообще было интересно, насколько трудно написать простенький Юникс «из головы».) В качестве цели номер 1 была поставлена задача запустить quake 1 for Unix, которая и была достигнута.

В процессе, естественно, появились open/close/r/w/ioctl, и появилось ощущение, что последний неприлично, постыдно устарел. В качестве упражнения для размятия мозга я реализовал (в дополнение к обычному ioctl) некоторый альтернативный API, который бы позволил управлять свойствами устройств более гибким и удобным с точки зрения пользователя способом. Этот API, конечно, имеет свои очевидны минусы, и, в целом, эта статья — RFC, aka request For Comments.

Итак, API на уровне пользователя:

// returns name of property with sequential number nProperty, or error
errno_t listproperties( int fd, int nProperty, char *buf, int buflen );

errno_t getproperty( int fd, const char *pName, char *buf, int buflen );
errno_t setproperty( int fd, const char *pName, const char *pValue );

Правила:

1. Никаких дефайнов с номерами, только имена.
2. Никаких бинарных данных, только строки

См. две другие статьи этой группы — Делаем многозадачность и Преемптивность: как отнять процессор.

Сразу просьба к строгим читателям. Если вы не поняли какой-либо термин из применённых — спросите, я подскажу, что я имел в виду. А если вам нравится другое написание или перевод этого термина — укажите его в комментарии. Я применяю те, которые нравятся мне.

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

Как я уже говорил, шедулер — это просто функция, которая отвечает на вопрос: какую нить и на сколько времени поставить на процессор.

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

Говоря о шедулере нельзя не сказать о приоритетах.

Приоритет — свойство нити (или процесса) влияющее на конкуренцию этой нити с другими нитями за процессор.

Приоритет обычно описывается парой <класс приоритета, значение приоритета внутри класса>.

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

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

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

Но, как обычно, есть нюансы. См. код для интела.

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

^{Источник: Spacefacts.de}

Эта история произошла в 1985 году, но в последствии постепенно забылась. Шли годы — многие подробности были искажены, кое-что было выдумано. Даже те, кто первыми рассказал об этих событиях, допускали явные ошибки. Операция «Союза-13» по спасению орбитальной станции «Салют-7» была впечатляющей попыткой проведения ремонта в открытом космосе. Писатель Николай Белаковский собрал все факты воедино и готов впервые за все время предоставить нам полноценный рассказ о тех событиях.