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

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

Что же не так с ДЭГ в Москве

Где лежат результаты и как их проверять

Издеваться мы будем над микросхемой GD32VF103CBT6, являющейся аналогом широко известной STM32F103, с небольшим, но важным отличием: вместо ядра ARM там используется ядро RISC-V. Чем это грозит нам, как программистам, попробуем разобраться.

Кратко перечислю характеристики контроллера:

• Напряжение питания: 2.6 — 3.6 В
  
  • Максимальная тактовая частота: 108 МГц
  • Объем ПЗУ (flash): 128 кБ
  • Объем ОЗУ (ram): 32 кБ
  • Объем Backup регистров (сохраняемых после сброса): 42 х 16 бит = 84 байта.
  • АЦП+ЦАП: 2 штуки АЦП по 10 каналов и 12 бит каждый плюс 2 ЦАП по 12 бит.
  • Разумеется, куча прочей периферии вроде таймеров, SPI, I2C, UART и т. д.

Этот документ поможет вам изучить контейнер для языка программирования Rust — futures, который обеспечивает реализацию futures и потоков с нулевой стоимостью. Futures доступны во многих других языках программирования, таких как C++, Java, и Scala, и контейнер futures черпает вдохновение из библиотек этих языков. Однако он отличается эргономичностью, а также придерживается философии абстракций с нулевой стоимостью, присущей Rust, а именно: для создания и композиции futures не требуется выделений памяти, а для Task, управляющего ими, нужна только одна аллокация. Futures должны стать основой асинхронного компонуемого высокопроизводительного ввода/вывода в Rust, и ранние замеры производительности показывают, что простой HTTP сервер, построенный на futures, действительно быстр.

Для написания эффективных и корректных многопоточных приложений очень важно знать какие существуют механизмы синхронизации памяти между потоками исполнения, какие гарантии предоставляют элементы многопоточного программирования, такие как мьютекс, join потока и другие. Особенно это касается модели памяти C++, которая была создана сложной таковой, чтобы обеспечивать оптимальный многопоточный код под множество архитектур процессоров. Кстати, язык программирования Rust, будучи построенным на LLVM, использует модель памяти такую же, как в C++. Поэтому материал в этой статье будет полезен программистам на обоих языках. Но все примеры будут на языке C++. Я буду рассказывать про std::atomic, std::memory_order и на каких трех слонах стоят атомики.

Все мы встречались со сложными ошибками на продакшне, которые сложно поймать обычными средствами мониторинга. BPF — это технология ядра Linux, которая позволяет делать быструю и безопасную динамическую отладку прямо на запущенной работающей системе, без необходимости готовиться к этому заранее. JVM сама по себе имеет множество точек мониторинга для отслеживания сборки мусора, выделения объектов, вызовов JNI, даже вызовов методов — и всё это без необходимости в дополнительном инструментировании. Когда этих точек мониторинга недостаточно, ядро Linux и всевозможные бибилиотеки позволяют отслеживать системные вызовы, сетевые пакеты, события планировщика, время потраченное на доступ к диску, и даже запросы к базам данных.

В этом хабрапосте мы сделали текстовую расшифровку доклада Sasha Goldshtein, посвященного тому, как инструменты BPF можно использовать для мониторинга JVM-приложений на GNU/Linux, и чеклисту проверки производительности с использованием классических инструментов, таких как fileslower, opensnoop, strace — но всё это с использованием неинвазивной, быстрой и безопасной технологии BPF.

После ката будет множество картинок со слайдами. Осторожно, трафик! Картинки ужаты насколько можно, но не более того. Все они действительно нужны.

Berkeley Packet Filters (BPF) — это технология ядра Linux, которая не сходит с первых полос англоязычных технических изданий вот уже несколько лет подряд. Конференции забиты докладами про использование и разработку BPF. David Miller, мантейнер сетевой подсистемы Linux, называет свой доклад на Linux Plumbers 2018 «This talk is not about XDP» (XDP – это один из вариантов использования BPF). Brendan Gregg читает доклады под названием Linux BPF Superpowers. Toke Høiland-Jørgensen смеется, что ядро это теперь microkernel. Thomas Graf рекламирует идею о том, что BPF — это javascript для ядра.

На Хабре до сих пор нет систематического описания BPF, и поэтому я в серии статей постараюсь рассказать про историю технологии, описать архитектуру и средства разработки, очертить области применения и практики использования BPF. В этой, нулевой, статье цикла рассказывается история и архитектура классического BPF, а также раскрываются тайны принципов работы tcpdump, seccomp, strace, и многое другое.

Разработка BPF контролируется сетевым сообществом Linux, основные существующие применения BPF связаны с сетями и поэтому, с позволения @eucariot, я назвал серию "BPF для самых маленьких", в честь великой серии "Сети для самых маленьких".

В начале была технология и называлась она BPF. Мы посмотрели на нее в предыдущей, ветхозаветной, статье этого цикла. В 2013 году усилиями Алексея Старовойтова (Alexei Starovoitov) и Даниэля Боркмана (Daniel Borkman) была разработана и включена в ядро Linux ее усовершенствованная версия, оптимизированная под современные 64-битные машины. Эта новая технология недолгое время носила название Internal BPF, затем была переименована в Extended BPF, а теперь, по прошествии нескольких лет, все ее называют просто BPF.

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

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

Предыстория

• Буферный кеш (эта статья);
• Журнал предзаписи — как устроен и как используется при восстановлении;
• Контрольная точка и фоновая запись — зачем нужны и как настраиваются;
• Настройка журнала — уровни и решаемые задачи, надежность и производительность.

Читайте и другие серии.

Индексы:

1. Механизм индексирования;
2. Интерфейс метода доступа, классы и семейства операторов;
3. Hash;
4. B-tree;
5. GiST;
6. SP-GiST;
7. GIN;
8. RUM;
9. BRIN;
10. Bloom.

Изоляция и многоверсионность:

1. Изоляция, как ее понимают стандарт и PostgreSQL;
2. Слои, файлы, страницы — что творится на физическом уровне;
3. Версии строк, виртуальные и вложенные транзакции;
4. Снимки данных и видимость версий строк, горизонт событий;
5. Внутристраничная очистка и HOT-обновления;
6. Обычная очистка (vacuum);
7. Автоматическая очистка (autovacuum);
8. Переполнение счетчика транзакций и заморозка.

Блокировки:

1. Блокировки отношений;
2. Блокировки строк;
3. Блокировки других объектов и предикатные блокировки;
4. Блокировки в оперативной памяти.

• настройка dev-окружения в docker-compose.
• создание бэкенда на Flask.
• создание фронтенда на Express.
• сборка JS с помощью Webpack.
• React, Redux и server side rendering.
• очереди задач с RQ.

• Don't communicate by sharing memory, share memory by communicating.
• Concurrency is not parallelism.
• Channels orchestrate; mutexes serialize.
• The bigger the interface, the weaker the abstraction.
• interface{} says nothing.
• Gofmt's style is no one's favorite, yet gofmt is everyone's favorite.
• A little copying is better than a little dependency.
• Cgo is not Go.
• Clear is better than clever.
• Reflection is never clear.
• Errors are values.