Привет, Хабр! Представляю вашему вниманию перевод статьи «Scheduling In Go: Part I — OS Scheduler» автора Билла Кеннеди, о том, как работает внутренний планировщик Go.

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

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

Полтора года назад, читая работы про уязвимости Meltdown и Spectre, я поймал себя на том, что не очень понимаю разницу между сокращениями i.e. и e.g. Т.е. по контексту вроде бы понятно, но потом вроде бы как-то и не совсем то. В результате я тогда сделал себе небольшую шпаргалку именно по этим сокращениям, чтобы не путаться. И тогда же появилась идея этой статьи.

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

Введение

В этой статье я расскажу, как профилировать и оптимизировать приложения на языке Go с использованием встроенных и общих инструментов, доступных в ОС Linux.

Что такое профайлинг и оптимизация? Если ваша программа работает недостаточно быстро, использует слишком много памяти, неоптимально использует процессор, вы хотите понять, в чем дело, и исправить — это и есть профайлинг и оптимизация.

Я привел такое определение, чтобы сразу отсечь вопросы некорректной работы приложения. В этой статье мы не будем говорить о проблемах мультитредового программирования, о дата-рейсах (англ. data race), о поиске ошибок (англ. debugging). Для всего этого в Go есть свои утилиты и подходы, но оставим эту тему на будущее.

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

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

Я долго искал инструмент, который помог бы справиться с такими проблемами (писал об этом на Хабре: 1, 2), но в итоге сделал собственное опенсорсное решение. В статье я рассказываю о преимуществах подхода service mesh и делюсь новым инструментом для его реализации.

В деле удалённого вызова процедур дела уже давно обстоят в точности как в известном комиксе «14 стандартов» — чего только тут ни напридумано: древние DCOM и Corba, странные SOAP и .NET Remoting, современные REST и AMQP (да, я знаю, что кое-что из этого формально не RPC, для того чтобы обсудить терминологию даже вот специальный топик недавно создали, тем ни менее всё это используется как RPC, а если что-то выглядит, как утка и плавает, как утка — ну, вы в курсе).

И конечно же, в полном соответствии со сценарием комикса, на рынок пришел Google и заявил что вот теперь наконец он создал ещё один, последний и самый правильный стандарт RPC. Google можно понять — продолжать в 21-ом веке гонять петабайты данных по старому и неэффективному HTTP+REST, теряя на каждом байте деньги — просто глупо. В то же время взять чужой стандарт и сказать «мы не смогли придумать ничего лучше» — совершенно не в их стиле.

Поэтому, встречайте, gRPC, что расшифровывается как «gRPC Remote Procedure Calls» — новый фреймворк для удалённого вызова процедур от Google. В этой статье мы поговорим о том, почему же он, в отличии от предыдущих «14 стандартов» всё-таки захватит мир (ну или хотя бы его часть), попробуем собрать билд gRPC под Windows + Visual Studio (и даже не говорите мне, что инструкция не нужна — в официальной документации упущено штук 5 важных шагов, без которых ничего не собирается), а также попробуем написать простенький сервис и клиент, обменивающиеся запросами и ответами.

Вчера компания Nvidia анонсировала Jetson Nano: одноплатный компьютер для вычислений в области ИИ. Маленький компьютер с поддержкой библиотек CUDA-X AI выдаёт 472 гигафлопса для запуска современных рабочих нагрузок ИИ, потребляя при этом всего лишь 5 Вт.

Рон Конвей (Ron Conway) однажды сказал: «Раньше компании стоимостью миллиард долларов создавались каждые 3 месяца, сейчас каждые 2». У меня появился шанс составить свой список «миллиардеров». Я попробовал ограничить этот список только хайтек-компаниями, производящими ПО. Также я добавил несколько компаний со стоимостью около миллиарда (~0,7 млрд. и больше).

Сдал сопромат — можно жениться!

Введение

Метод конечных элементов (МКЭ или FEM, у них за рубежом) прочно вошел в практику инженерных расчетов при проектировании сложных систем. В значительной степени это касается прочностных расчетов механики. Применения этого метода, реализуемого соответствующим программным обеспечением существенно сокращает цикл разработки конечного устройства, позволяя исключить массу экспериментальных проверок, необходимых при использования классических расчетов на основе методов сопромата и строительной механики. На текущий момент разработана масса прикладного ПО, реализующего МКЭ. Во главе угла стоит мощный ANSYS, по бокам от него и в почетном удалении — CAD-системы со встроенным FEM-модулем (SolidWorks, Siemens NX, Creo Parametric, Компас 3D).

CalculiX силен, но труден и непонятен. Исправим это?



Естественно, МКЭ проник и в сферу образования — чтобы использовать его в реальных задачах, нужна подготовка соответствующих специалистов. В столицах, в крупных технических вузах обстановка в этой области более-менее нормальная, да и у нас в регионе тот же ANSYS применяется, например, на кафедре теории упругости ЮФУ. Но по периферии, в узко специализированных и не богатых университетах ситуация плачевна. И всё просто — ANSYS стоит порядка 2 млн. рублей за одно рабочее место, а место требуется не одно. К сожалению не все вузы могут позволить себе выложить 30-40 миллионов на организацию компьютерного класса для обучения применению МКЭ.

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

В июне этого года в России был принят новый стандарт блочного шифрования — ГОСТ Р 34.12-2015. Этот стандарт помимо старого доброго ГОСТ 28147-89, который теперь называется «Магма» и имеет фиксированный набор подстановок, содержит описание блочного шифра «Кузнечик». О нем я и расскажу в этом посте.

Вступление

Давно хотел написать статью про образование в Computer Science, но руки не доходили. Решил все-таки это наконец сделать. Итак, о чем пойдет речь? Речь о том, что из себя представляет диплом MSc Computer Science топовых университетов США (во всех подробностях, включая основные курсы, книги и проекты) и как ему соответствовать.

Почему именно MSc? Это — некая развилка: с одной стороны после MSc — вы уже готовый к жизни инженер (да, речь идет о инженерной подготовке, как мне кажется это самое больное место в нашей системе образования), с другой — можно спокойно идти по пути PhD. Как известно, в PhD программу можно попасть и не особо умея программировать — особенно это касается теоретического Computer Science. С другой стороны найти работу программиста тоже дело не очень сложное, и часто не требует мощного образования. Но достигнув уровня MSc — вы получаете возможность разбираться как во всех новый идеях в Computer Science, так и возможность их воплотить в практику. То есть с одной стороны круто разобраться в каком-нибудь deep learning и сделать в нем что-то новое, а также взять и написать свою операционную систему (кто так сделал?). Причем вы не зажаты в рамки узкой специализации (если конечно продолжаете учиться). То есть вы теперь — универсальный солдат, готовый на все.

Надеюсь что эта статья будет полезна:
1. Студентам, которые хотят соответствовать высоким стандартам топ вузов США, или собирающиеся туда в аспирантуру по Computer Science
2. Профессионалам, которые хотят закрыть «дыры» и пробелы
3. Может кто-то из преподавателей возьмет на заметку для своих курсов.
4. Студентам, аспирантам американских вузов — хотелось бы тоже получить фидбэк, особенно касается последних трендов в образовании

Что же здесь будет написано? Минимум философии и общих мыслей: конкретная программа undergraduate и graduate курсов, конечно из дисциплин наиболее мне близких. Все курсы были лично прочувствованы на собственной шкуре, по этому и пишу. (Я пытался записаться на все интересные курсы, которые были, но мой основной упор — системное программирование, базы данных и искусственный интеллект. Отсюда конечно некий bias, но пытаюсь предложить более-менее универсальную программу).