arbtttrn6Для The Last Bullet: Updated.
1) https://i.postimg.cc/W3tMVyB9/1.jpg
2) https://i.ibb.co/zWF57mCZ/1.jpg
3) https://st.render.ru/artwork/869176
Модель инопланетной вражины для мода The Last Bullet на Half-Life.
Геометрия и развёртка сделаны в Blender'е, а раскрашено в Krita.
HabrВспомнить всё: как устроены ассоциативные памяти в СнК
Знаете ли вы, что у микропроцессоров существуют памяти, которые могут ответить на вопрос: «А нет ли внутри тебя информации, похожей на вот эту?» То есть они не просто запоминают, что им «скажут», и выдают ранее записанное, но еще и умеют сопоставлять свое содержимое с запросом извне. Как в каждой большой дружеской компании есть товарищ, у которого на любую тему найдется подходящий анекдот или мем.
https://habr.com/ru/companies/yadro/articles/958656/
#микроэлектроника #микропроцессоры #память #схемотехника #SoC #СнК #ассоциативная_память #tlb #компаратор #CAMпамять
аккаунт более неактивенПример типичной системно-прикладной разработки, реализация своей «очереди сообщений» (event loop).
Использованием #epoll, вместо «традиционных» select & poll, для асинхронной работы через polling’а (и мультиплексирования).
Отслеживание файловых дескрипторов через #epoll выглядит более современно, меньше копирования памяти между user space и kernel space. А при появлении ожидаемых данных можно напрямую переходить к объекту или структуре данных, что важно при наблюдении за несколькими файлами и\или соединениями. Устраняется поиск «сработавшего» файлового дескриптора в индексных массивах, полноценное О(1) во всех случаях. Можно сразу же работать с теми экземплярами объектов, которые оборачивают тот файл или udp-поток, tcp-, quic-соединение, где появились новые данные.
Есть несколько готовых к использованию «очередей сообщений» (event loop'ов) — #libev, #libuv, #libevent. Для некоторых агент-серверные решений и брокера #RabbitMQ это подходит. Однако, в некоторых случаях AMQP-библиотеки не скрещиваются с уже готовыми «очередями сообщений». Потому что агентская часть может активно использовать асинхронно-реактивное программирование с хорошей и проверенной «горизонтальной масштабируемостью». Т.е. на агентской части выполняется много работы и реализация сделана через sharing nothing многопоточность. Это такая парадигма, когда не просто достигается не только горизонтальная масштабируемость через lock-free\wait-free, а так же исключается много вредного, как тот же cache ping-pong или false sharing. Внутри агентов идёт своё управление потоками с выделениями памяти. Не только в плане «динамической памяти» (heap, аллокаторы а-ля #jemalloc от #Facebook), но и приколами вокруг pinning страниц, учёта #NUMA и даже huge pages(меньше промахов в #TLB).
Почему бы не использовать epoll?
Библиотека не обязана вычитывает данные целиком из потока (сокета), а может забирает данные лишь до тех пор, пока не насытится автомат состояний (finite-state machine). Например, выполняется парсинг сущностей AMQP-протокола, которые, по мере накопления, передаются в обработчики указанные клиентом библиотеки.
И это плохо соотносится с тем, что используя #epoll надо выбирать какой вариант оповещений использовать:
• «по уровню» (level-triggered),
• «по фронту» (edge-triggered).
Особенности поведения отдельно взятой библиотеки может не позволять использовать работу «по фронту» (edge-triggered), т.к. библиотека не вычитывает полностью все данные из файловых дескрипторов.
Можно быть хоть пять раз technical lead и всё это прекрасно знать, но следует помнить, что как только в коде появляется флаг EPOLLET, то необходимо проводить аудит работы с потоками данных. Это избавляет команду от многих заморочек вокруг тестирования и ковыряния с каким-то совершенно непонятным поведением кода.
Про «Edge Triggered Vs Level Triggered interrupts»
#programming #linux #softdev #трудовыебудни
Использованием #epoll, вместо «традиционных» select & poll, для асинхронной работы через polling’а (и мультиплексирования).
Отслеживание файловых дескрипторов через #epoll выглядит более современно, меньше копирования памяти между user space и kernel space. А при появлении ожидаемых данных можно напрямую переходить к объекту или структуре данных, что важно при наблюдении за несколькими файлами и\или соединениями. Устраняется поиск «сработавшего» файлового дескриптора в индексных массивах, полноценное О(1) во всех случаях. Можно сразу же работать с теми экземплярами объектов, которые оборачивают тот файл или udp-поток, tcp-, quic-соединение, где появились новые данные.
Есть несколько готовых к использованию «очередей сообщений» (event loop'ов) — #libev, #libuv, #libevent. Для некоторых агент-серверные решений и брокера #RabbitMQ это подходит. Однако, в некоторых случаях AMQP-библиотеки не скрещиваются с уже готовыми «очередями сообщений». Потому что агентская часть может активно использовать асинхронно-реактивное программирование с хорошей и проверенной «горизонтальной масштабируемостью». Т.е. на агентской части выполняется много работы и реализация сделана через sharing nothing многопоточность. Это такая парадигма, когда не просто достигается не только горизонтальная масштабируемость через lock-free\wait-free, а так же исключается много вредного, как тот же cache ping-pong или false sharing. Внутри агентов идёт своё управление потоками с выделениями памяти. Не только в плане «динамической памяти» (heap, аллокаторы а-ля #jemalloc от #Facebook), но и приколами вокруг pinning страниц, учёта #NUMA и даже huge pages(меньше промахов в #TLB).
Почему бы не использовать epoll?
Библиотека не обязана вычитывает данные целиком из потока (сокета), а может забирает данные лишь до тех пор, пока не насытится автомат состояний (finite-state machine). Например, выполняется парсинг сущностей AMQP-протокола, которые, по мере накопления, передаются в обработчики указанные клиентом библиотеки.
И это плохо соотносится с тем, что используя #epoll надо выбирать какой вариант оповещений использовать:
• «по уровню» (level-triggered),
• «по фронту» (edge-triggered).
Особенности поведения отдельно взятой библиотеки может не позволять использовать работу «по фронту» (edge-triggered), т.к. библиотека не вычитывает полностью все данные из файловых дескрипторов.
Можно быть хоть пять раз technical lead и всё это прекрасно знать, но следует помнить, что как только в коде появляется флаг EPOLLET, то необходимо проводить аудит работы с потоками данных. Это избавляет команду от многих заморочек вокруг тестирования и ковыряния с каким-то совершенно непонятным поведением кода.
Про «Edge Triggered Vs Level Triggered interrupts»
#programming #linux #softdev #трудовыебудни
grumbК вопросу использования #epoll вместо хорошо знакомых и «традиционных» select & poll. Т.е. асинхронной работы с чем-либо посредством polling’а и мультиплексирования.
Недавно пришлось заниматься реализацией очереди событий для AMQP-CPP. В одном из продуктов решено сделать связь агентских частей с основным «контроллером» через #AMQP, в качестве брокера #RabbitMQ (всё стандартно, обычный кластер и TLS-соединения).
Вот только агенты продукта активно используют асинхронно-реактивное программирование с хорошей «горизонтальной масштабируемостью». Когда достигнуто полноценное sharing nothing, не просто горизонтальная масштабируемость через lock-free или wait-free и закон Амдала. Исключается много всего и сразу, как старый-добрый cache ping-pong, так и печаль с false sharing.
Отсюда внутри агентов и своё управление потоками с выделениями памяти. Не только в плане heap (динамической памяти, со своими аллокаторами а-ля #jemalloc от #Facebook), но и приколы вокруг узлов #NUMA и даже huge pages (снижающих «давление» на #TLB, меньше промахов).
Первая же проблема выплыла почти сразу — не реально использовать библиотеку AMQP-CPP с уже предоставляющейся поддержкой #libev, #libuv, #libevent. Несовместимы эти очереди сообщений с имеющейся моделью управления потоками и организации задач на агентах.
Почему был взят epollПодход используемый в #epoll выглядит более современно, меньше копирований памяти между user space и kernel space. А при появлении данных в отслеживаемом файловом дескрипторе можно напрямую перейти по указателю на объект класса или структуру данных. Тем самым обходиться без поиска дескриптора по индексным массивам/контейнерам. Сразу же работать с экземплярами объектов оборачивающих нужное #tcp -соединение, того самого, в которое и пришли данные.
И тут обозначилась вторая проблема, что используема AMQP-библиотека не вычитывает данные целиком из потока сокета. Например, забирает данные лишь до тех пор, пока не насытится автомат состояний (finite-state machine), выполняющий парсинг сущностей AMQP-протокола.
Используя #epoll приходится выбирать на какой вариант обработки событий ориентироваться:
- срабатывание оповещений «по уровню» (level-triggered),
- выбрасывания событий «по фронту» (edge-triggered).
И беда с библиотекой в очередной раз показала, что нельзя использовать работу «по фронту» (edge-triggered) не изучив досконально работу подсистемы отвечающей за вычитывание данных из файловых дескрипторов. И появление флага EPOLLET в коде является маркером, о том, чтобы проводить аудит использовавшихся решений.
Про Edge Triggered Vs Level Triggered interrupts можно почитать в https://venkateshabbarapu.blogspot.com/2013/03/edge-triggered-vs-level-triggered.html)
[Перевод] Оптимизация кольцевого буфера для повышения пропускной способности
В этой статье мы рассмотрим классический конкурентный кольцевой буфер и обсудим, как его можно оптимизировать для повышения производительности. Я покажу вам, как существенно улучшить этот показатель от 5,5 миллионов элементов в секунду до 112 миллионов элементов в секунду — и эти показатели выше, чем в реализациях Boost и Folly . Если вам требуется готовая реализация со всеми этими оптимизациями, посмотрите мою библиотеку SPSCQueue.h . Кольцевой буфер также называется очередью «один производитель — один потребитель» (SPSC). В ней не бывает ожидания (и, соответственно, не бывает блокировок), это конкурентный примитив. Такая структура данных находит множество вариантов применения, и здесь я рассмотрю передачу сетевых пакетов между сетевым контроллером и драйверами операционной системы. Основная задача, решаемая при этом — выполнение событий ввода/вывода в относительно новом асинхронном API io_uring .
https://habr.com/ru/companies/timeweb/articles/870604/
#timeweb_статьи_перевод #SPSC #arm #цп #linux #ядро #amd #mesi #tlb #буфер
Some Bits: Nelson's LinkblogHuge Pages are a Good Idea: Linux boxes still use 4k memory pages even though 1GB of RAM for a process is now common. Bigger pages perform better but trigger bugs.
https://www.evanjones.ca/hugepages-are-a-good-idea.html
#via:hackernews #optimization #memory #linux #tlb #+
https://www.evanjones.ca/hugepages-are-a-good-idea.html
#via:hackernews #optimization #memory #linux #tlb #+
Alain Portay ⏚Donc je suis retourné sur Twitter et j'ai appris une triste nouvelle.
Pour me forcer à acheter son livre ou à garder mon compte ouvert, @SirYesSir29 ne viendra pas sur Mastodon et je trouve cela scandaleux.
#TLB #Scandale
Pour me forcer à acheter son livre ou à garder mon compte ouvert, @SirYesSir29 ne viendra pas sur Mastodon et je trouve cela scandaleux.
#TLB #Scandale
L1413_Bonjour les canetons de #TLB,
Plusieurs d’entre vous on migré vers mastodon depuis twitter. C’est cool, ça fait une base de replis libre de droits (contrairement à Discord) en cas de dérive de Twitter.
Je propose donc un truc.
Dans notre profil, on peut ajouter 4 métadonnées. Voici les miennes.
Ma proposition c’est ce champ « À #TLB » où chacun indique son rôle à TLB.
Qu’en dites-vous ?
motokiyoLa liste #BEC vous invite à une soirée !🤩
Ce mercredi 4 mars, à 19h au Tiers-Lieux en Bigorre, #TLB : Conférence participative "Transition, Effondrement et Résiliences". Valérie Garcia est sophrologue, écopsychologue. Marc Plessier, ingénieur génie mécanique, éco-constructeur.
🐦🔗: https://twitter.com/BecEcologie/status/1234824798137614336
Bagnères Ecologie Citoyenne - BEC on Twitter
“La liste #BEC vous invite à une soirée !🤩 Ce mercredi 4 mars, à 19h au Tiers-Lieux en Bigorre, #TLB : Conférence participative "Transition, Effondrement et Résiliences". Valérie Garcia est sophrologue, écopsychologue. Marc Plessier, ingénieur génie mécanique, éco-constructeur.”