У меня нет здесь хорошего ответа. Мы лично наступали на ядерные баги, которые нам прям мешали, в минорных версях около .10. Это, в любом случае, компромис между стабильностью (из личного опыта) и фичами/производительностью/пр.
Я имел ввиду, что на какой-то конференции ваш DeмOps рассказывал, что вы (и Google тоже, как и другихе hyperscalers) патчите текущее ядро и так или иначе, оно попадает в про. Пусть не на условный YouTube.com/facebook.com, но тем не менее. Когда я его спросил собственно и как если сервер в проде в Oops свалится, он мне сказал, что инфраструктура строится так, что в любой момент любой сервер как угодно может выйти из строя. Так мало, кто может строить. Я занимаюсь балансировщиками и часто - это проста пара машин: пока одна ребутается, под хорошей нагрузкой и хорошим багом, и вторая может лечь. Вообще, люди очень настороженно относятся к ядерным багам.
Буду рад, если, что расскажешь про LTS ядра.
Сетевая community kernel handshakes приняла хорошо, а security - нет. У нас было прилично переписки. Сама по себе миграция патчей и унификация для общего use case для меня выглядит, как 1-2 человека года, может, и больше. У нас просто нет столько рук, чтобы это не повредило продукту.
Мы так и не заапстримили свои хендшейки - это очень большая работа. Ты, думаю, видел ссылки на нас на LWN и Netdev от Chuck Lever (Oracle) - мы пробовали запустить с ним портирование в мейнстрим для NFS, но поддержки от Oracle мы не получили и в результате они сделали проброс в user space. Портирование в mainstream мы отложили на неопрелеленное время.
Доклад был в декабре 2024 и коллеги, как и все нормальные/простые люди, у которых нет ресурсов Facebook для поддержки mainline ядер в продакшене, работают на longterm ядрах. Патч появился в июне 2024.
@AndrewSilin является ли открытой информация, сколько обучающихся на Практикуме нанимает сам Яндекс? Если это открытая информация, то было бы интересно еще узнать, как это происходит: прям во время обучения или в течение нескольких дней после.
Только увидел коментарий. Весь парсер у нас писался руками. Мы используем на макросах С некоторое подобие DSL, чтобы писать было проще. Есть HTTP парсеры, сгенерированные Ragel, но, во-первых, насколько помню, не вся грамматика HTTP может быть выражена таким генератором парсеров. Во-вторых, мы старались изолировать парсер от остального кода (аллокаторов памяти, сетевых структур и HTTP логики), но на практике это получается плохо.
Иными словами, если мы посмотрим не только на сервера, которые могут обрабатывать трафик из Internet типа Nginx, H2O, Varnish, HAproxy, но и "легкие" реализации, в основном предназначенные для микросервисных коммуникаций типа boost::beast, Pistache, libhttpserver или uWebSockets - у всех будут руками написанные парсеры.
Спасибо за статью — давно заняю ваш WAF, но не думал, что есть пробная бесплатная версия!
У меня есть несколько вопросов и буду рад, если ответите:
можете сделать какой-то ликбез относительно ModSecurity? Что ловится регекспами и используются ли они, а что ML?
если используются регекспы, то что внутри: PCRE JIT, Hyperscan, или вообще что-то свое?
можете ли дать какой-то ориентир сколько RPS ваш WAF может обработать на одно ядро CPU в каких-то конфигурациях (например, минимально, 100 регекспов, полная база)?
Причин несколько: отсутсвие копирований, оптимизированная работа с памятью, отсутствие контекст свитчей. Ну и конечно, более новые алгоритмы криптографии тоже дают свой эфект.
найти человека, который сможет задать и поддерживать высокий уровень профессионализма в применении языка Go
Совершенно адекватное интервью. Я бы сказал, что позиция, скорее, на tech lead, поскольку нужно "задать" высокий уровень, чем senior. Но я не совсем понял
средний балл по опроснику — 3.3 по шкале 0-9. 3.3, Карл! 3.3 — это, с моей точки зрения, уровень junior. Middle должен набирать, я считаю, 5+. Senior — 8+.
По всей видимости, плохо отработали HR или те, кто просматривал резюме — нужно было более серьезных людей пропускать на собеседование.
Возможно, и проблема с деньгами — люди, кто могут показать 8+ просто не особо шли. Впрочем, их и очевидно просто мало.
Считать среднее вообще не имеет смысла. Это нормальная статистика, что, чтобы нанять одного разработчика нужно провести около 10 собеседований. И это при хорошем фильтре резюме, как для mid, так и senior. Соответственно, да: 9 из 10 мидов попадают под <5, 9 из 10 сеньоров под <8.
Я имел ввиду, что из C++ программы я могу заинклюдить C хедер и в общем случае (не учитывая, напирмер, использование new идентификаторов в C) это "работает из коробки". Есть интеграция из C++ в C через extern "C". Так или иначе, но С++ наиболее совместим с C. Например, наткнулся на такой пост про использование C хедеров из D: https://atilaoncode.blog/2018/04/09/include-c-headers-in-d-code/ .
Вася на Rust не напишет в 2 раза быстрее, потому что "Вася" — это средний программист, который о Rust только слышал, в бою его не пробовал. Начиная новый проект, мы знаем, что на рынке много C/C++ разработчиков, много наработанных библиотек, инструментариев и просто ответов на StackOverflow.
Новый язык — это для энтузиастов, кто готов вечерами посидеть с багами в новом языке, поучить матчасть и пр. Вот, и выбирайте как скоротать долгий осенний вечер — выучить новый язык или лучше разобраться в архитектуре и компиляторе знакомго языка.
Давайте посмотрим на первый бенчмарк Rust и C. Во-первых, эту программу на Rust, как многие другие для этих бенчмарков, написала команда разработчиков Rust — коментарий из копирайта:
contributed by the Rust Project Developers
Я не могу оценить реализацию самого бенчмарка на Rust, но копирайт заставляет думать, что там сделано хорошо.
Я занимаюсь разработкой высокопроизводительного кода, часто нам нужен именно "чемпионский" код — показать самые высокие на рынке бенчмарки. Для меня очень важна скорость работы кода и иногда мне не хватает C.
В качестве практического примера приведу быстрые парсеры. В моем случае для разработки быстрого HTTP прасера понадобился не только GOTO, которого нет в Rust, но еще и computed labels — это уже compiler specific расширения для C.
Т.е. вот, есть реальная, не такая маленькая, задача, которую C решает лучше Rust. Но я не видел ни одной задачи, которую Rust решает лучше C. Удобство и быстрота разработки — возможно, но не скорость работы.
Если мучительно отлаживать указатели на C, то мы используем C++ с его smart pointers, RAII и пр. (Я могу вспомнить пару плохонаписанных, не наших, C проектов, которые мы переводили на C++ и в наиболее геморойных местах заменяли C указатели на smart pointers). В C++ можно всегда и просто встроить код на C, который будет работать очень быстро: совместимость с C — ключевое свойство C++ для системного программирования. C Rust, как и с D (тоже была такая 'лучшая' альтернатива C++), будут еще телодвижения на совместную компиляцию с C.
А еще видел неплохое, относительно нейтральное, сравнение C и Rust.
Перевод хороший, но оригинальная статья имеет очень странную "отсебятину" в сторону Rust.
Rust в качестве второго языка ядра
Прям очень громкое заявление. Речь идет о драйверах, которые и сейчас на C часто не удовлетворяют стилю кодирования, принятому в ядре. Очень сомнительно, что кто-то будет писать модули для основных подсистем Linux (аллокаторы памяти, СС алгоритмы в сети, LSM модули и пр.) на Rust.
На мой взгляд сканировать журнал событий и по нему собирать статистику — не очень оптимально. Если правильно понял описание ваших скриптов, то в Linux это делается с помощью fail2ban.
Про ветярнные мельницы я не понял. Мы бьемся за быстрый HTTPS. Для нас "нагруженной системой" может быть, как массивный bare metal, так и однопроцессорная VM, которая тоже должна работать быстро. Для нас, как и большинства людей, не очень приемлемо молотить все доступные CPU на 100% даже при простое.
C теорией NAPI и сетевых прерываний я знаком, но за ссылку спасибо :) Вопросов все равно много остается: проборс VF с VM и SR-IOV — это один только из кейсов, а что будет с трафиком между двумя VM на одном хосте? Будет куча VM-EXIT и в perf kvm stat будут EXTERNAL_INTERRUPT.
Поживем, увидим как будут развиваться серверные ARM, но пока у них use cases очень ограничены.
В среднем по больниц, понятно. Я мимоходом смотрел, например, на Marvell ThunderX2, которые до 256 потоков имеют, и как-то не понятно как там с APIC, а что с виртуализацией — тем более. Работал с ними или смотрел подробнее? У Xeon с vAPIC не очень — 4 машины (entry level) взяли и ни у одной не было vAPIC полного, чтобы KVM не воткнула на I/O.
С сетью у нас интересная история. С packet forwarding/filtering на уровнях L2-L4 все понятно — логики мало и она относительно легко скейлится на ядра, DPDK и пр. kernel bypass рулят. У нас же HTTPS прокси и в perf top, как правило, HTTP parser, криптография, различная прикладня логика, например генерация cookie или javascript челленджей, матчинг HTTP заголовков опять же. Т.е. сетевых функций Linux networking мы не видим. Но при, этом без vAPIC в KVM и мы и Nginx "втыкаем" по полной и разница по произволительности 2 раза в лучшем случае.
Кстати, я недавно писал про user-space TCP в приложении для HTTP. У Seastar реализация TCP фейковая (в смысле "fake it before you make it") — просто, чтобы поставить рекодные бенчмарки: очень мало кода и с кучей TODO. F-stack показывает хорошие результаты, но я проверил сделали ли они что-то с известной проблемой хеш таблицей TCP соединений (она же давно была описана CloudFlare), но и в ядре Linux, и FreeBSD, и F-stack реализация все та же и примерно с одним подходом.
Итого, несмотря на отличные бенчмарки и безумное число ядер ARM, если у них нет хорошего APIC — с сетью, и думаю, с дисковым I/O тоже, все будет плохо. Нет поддержики виртуализации (в т.ч. virtual page talbe) — все плохо будет в облаках. И что останется? Числодробилки для ML?.. Возможно, и это ложится в карту NVIDIA.
Но так было раньше. На ассемблере уже давно никто не пишет. Сейчас за программистов всё это делают компиляторы, поэтому никаких сложностей с написанием кода под RISC-процессоры нет.
Вообще-то, пишут. И иногда на CISC асемблере писать проще, чем на C. Посмотрите ядро Linux или более или менее быструю криптобиблитеку (OpenSSL, WolfSSL, Tempesta TLS). Простой пример: как сложить два 128-битных числа (каждое из которых по 2 long'а)? На C вам прийдется делать телодвижения с битом переноса, а на ассеблере у вас уже есть инструкция, которая в старшее 64-битное число добавит перенос со сложения прошлых 64-х битных чисел. Но, с другой стороны, те, кто упирается в бенчмарки, погемороятся с RISC ассемблером.
Я не очень хорошо знаком с ARM, но интересует что у этой архитектуры с virtual APIC? На x86 без vAPIC сеть в виртуалке очень тормозит.
Слышал от знакомых жалобу на другую проблему с APIC на каких-то ARM процессорах: на 8-и ядерном ARM (не знаю точно каком) нельзя было разбросать очереди прерываний с сетевой карты на разные ядра — все прерывания уходили на одно ядро. Как у современных ARM (которые по 128 потоков и выше умеют) дела с APIC?
У меня нет здесь хорошего ответа. Мы лично наступали на ядерные баги, которые нам прям мешали, в минорных версях около .10. Это, в любом случае, компромис между стабильностью (из личного опыта) и фичами/производительностью/пр.
Я имел ввиду, что на какой-то конференции ваш DeмOps рассказывал, что вы (и Google тоже, как и другихе hyperscalers) патчите текущее ядро и так или иначе, оно попадает в про. Пусть не на условный YouTube.com/facebook.com, но тем не менее. Когда я его спросил собственно и как если сервер в проде в Oops свалится, он мне сказал, что инфраструктура строится так, что в любой момент любой сервер как угодно может выйти из строя. Так мало, кто может строить. Я занимаюсь балансировщиками и часто - это проста пара машин: пока одна ребутается, под хорошей нагрузкой и хорошим багом, и вторая может лечь. Вообще, люди очень настороженно относятся к ядерным багам.
Буду рад, если, что расскажешь про LTS ядра.
Сетевая community kernel handshakes приняла хорошо, а security - нет. У нас было прилично переписки. Сама по себе миграция патчей и унификация для общего use case для меня выглядит, как 1-2 человека года, может, и больше. У нас просто нет столько рук, чтобы это не повредило продукту.
@vadimfedorenko , ты - безусловно, крут 8)
Мы так и не заапстримили свои хендшейки - это очень большая работа. Ты, думаю, видел ссылки на нас на LWN и Netdev от Chuck Lever (Oracle) - мы пробовали запустить с ним портирование в мейнстрим для NFS, но поддержки от Oracle мы не получили и в результате они сделали проброс в user space. Портирование в mainstream мы отложили на неопрелеленное время.
Если же нужна "метрика", то я всегда рад рассказать о нас. Есть https://archive.fosdem.org/2021/schedule/event/webperf_fast_tls/ - 40-80% быстрее WolfSSL и OpenSSL, попутно https://github.com/wolfSSL/wolfssl/issues/3184 . Мы первыми реализовали "Fast constant-time gcd computation and modular inversion" Bernstein and Yang, которая потом была реализована в OpenSSL 3.0.
Для kTLS интересен AES-GCM и CACHA20-POLY1305. Вторую не смотрел, но для GCM-AES патч -это https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e6e758fa64438082e48272db19ad74ed4fb98938 - да, реализует Karatsuba, которого очень долго не было в ядре https://netdevconf.info/0x14/session.html?talk-TLS-performance-characterization-on-modern-x86-CPUs , есть AVX-512 и AVX10, VAES, как и в OpenSSL. Реализации детально еще не сравнивал и не бенчмаркал. Патч уже есть в longterm 6.12 и имеет смысл пробовать kTLS на 6.12 с включенным AVX-512/AVX10.
Доклад был в декабре 2024 и коллеги, как и все нормальные/простые люди, у которых нет ресурсов Facebook для поддержки mainline ядер в продакшене, работают на longterm ядрах. Патч появился в июне 2024.
@AndrewSilin является ли открытой информация, сколько обучающихся на Практикуме нанимает сам Яндекс? Если это открытая информация, то было бы интересно еще узнать, как это происходит: прям во время обучения или в течение нескольких дней после.
Только увидел коментарий. Весь парсер у нас писался руками. Мы используем на макросах С некоторое подобие DSL, чтобы писать было проще. Есть HTTP парсеры, сгенерированные Ragel, но, во-первых, насколько помню, не вся грамматика HTTP может быть выражена таким генератором парсеров. Во-вторых, мы старались изолировать парсер от остального кода (аллокаторов памяти, сетевых структур и HTTP логики), но на практике это получается плохо.
Иными словами, если мы посмотрим не только на сервера, которые могут обрабатывать трафик из Internet типа Nginx, H2O, Varnish, HAproxy, но и "легкие" реализации, в основном предназначенные для микросервисных коммуникаций типа boost::beast, Pistache, libhttpserver или uWebSockets - у всех будут руками написанные парсеры.
Спасибо за развернутый ответ!
Спасибо за статью — давно заняю ваш WAF, но не думал, что есть пробная бесплатная версия!
У меня есть несколько вопросов и буду рад, если ответите:
можете сделать какой-то ликбез относительно ModSecurity? Что ловится регекспами и используются ли они, а что ML?
если используются регекспы, то что внутри: PCRE JIT, Hyperscan, или вообще что-то свое?
можете ли дать какой-то ориентир сколько RPS ваш WAF может обработать на одно ядро CPU в каких-то конфигурациях (например, минимально, 100 регекспов, полная база)?
Vultr, например, дает anycast, причем достаточно дешево.
Мы недавно сравнивали Rust с C/C++ в контексте производительности (обусждения на Hacker News https://news.ycombinator.com/item?id=24960108 и Reddit https://www.reddit.com/r/programming/comments/jjtobp/fast_programming_languages_c_c_rust_and_assembly/).
Rust позволяет писать более безопасный код, хотя C++ движется тоже в эту сторону. Интересный доклад на эту тему с CppCon'20 Closing the Gap between Rust and C++ Using Principles of Static Analysis.
Но Rust по своему дизайну делает разработку быстрого кода сложнее (примеры приводил в блоге).
Go для утилит типа ls — вполне, но для ядра ОС, например, очевидно — нет.
Пропустил я этот тред. Конкретно на вопрос
про TLS handshakes мы с JackMonterey отвечали в https://netdevconf.info/0x14/session.html?talk-performance-study-of-kernel-TLS-handshakes (видео https://www.youtube.com/watch?v=THJ6zC1V10c). При том, что мы еще не закончили оптимизацию математики, уже виден прирост производительности на 80% относительно OpenSSL/Nginx, latency может быть до 4 раз меньше. В моей демо на Security Weekly https://www.youtube.com/watch?v=IxLB3aUAECk хендшейки на виртаулке в несколько раз становились быстрее.
Причин несколько: отсутсвие копирований, оптимизированная работа с памятью, отсутствие контекст свитчей. Ну и конечно, более новые алгоритмы криптографии тоже дают свой эфект.
Более подробно будем еще рассказывать на следующем HighLoad++ https://www.highload.ru/moscow/2020/abstracts/7085 и Linux Conf Au'21 https://linux.conf.au/schedule/presentation/64/
Для позиции
Совершенно адекватное интервью. Я бы сказал, что позиция, скорее, на tech lead, поскольку нужно "задать" высокий уровень, чем senior. Но я не совсем понял
По всей видимости, плохо отработали HR или те, кто просматривал резюме — нужно было более серьезных людей пропускать на собеседование.
Возможно, и проблема с деньгами — люди, кто могут показать 8+ просто не особо шли. Впрочем, их и очевидно просто мало.
Считать среднее вообще не имеет смысла. Это нормальная статистика, что, чтобы нанять одного разработчика нужно провести около 10 собеседований. И это при хорошем фильтре резюме, как для mid, так и senior. Соответственно, да: 9 из 10 мидов попадают под <5, 9 из 10 сеньоров под <8.
Привет!
Это правда :) Зря я написал слово "треш".
Я имел ввиду, что из C++ программы я могу заинклюдить C хедер и в общем случае (не учитывая, напирмер, использование
newидентификаторов в C) это "работает из коробки". Есть интеграция из C++ в C черезextern "C". Так или иначе, но С++ наиболее совместим с C. Например, наткнулся на такой пост про использование C хедеров из D: https://atilaoncode.blog/2018/04/09/include-c-headers-in-d-code/ .Вася на Rust не напишет в 2 раза быстрее, потому что "Вася" — это средний программист, который о Rust только слышал, в бою его не пробовал. Начиная новый проект, мы знаем, что на рынке много C/C++ разработчиков, много наработанных библиотек, инструментариев и просто ответов на StackOverflow.
Новый язык — это для энтузиастов, кто готов вечерами посидеть с багами в новом языке, поучить матчасть и пр. Вот, и выбирайте как скоротать долгий осенний вечер — выучить новый язык или лучше разобраться в архитектуре и компиляторе знакомго языка.
Давайте посмотрим на первый бенчмарк Rust и C. Во-первых, эту программу на Rust, как многие другие для этих бенчмарков, написала команда разработчиков Rust — коментарий из копирайта:
Я не могу оценить реализацию самого бенчмарка на Rust, но копирайт заставляет думать, что там сделано хорошо.
Реализация на С https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/binarytrees-gcc-3.html — достаточно короткая реализация на OpenMP и APR, но явно не оптимизировалась вообще.
Я занимаюсь разработкой высокопроизводительного кода, часто нам нужен именно "чемпионский" код — показать самые высокие на рынке бенчмарки. Для меня очень важна скорость работы кода и иногда мне не хватает C.
В качестве практического примера приведу быстрые парсеры. В моем случае для разработки быстрого HTTP прасера понадобился не только
GOTO, которого нет в Rust, но еще и computed labels — это уже compiler specific расширения для C.Т.е. вот, есть реальная, не такая маленькая, задача, которую C решает лучше Rust. Но я не видел ни одной задачи, которую Rust решает лучше C. Удобство и быстрота разработки — возможно, но не скорость работы.
Если мучительно отлаживать указатели на C, то мы используем C++ с его smart pointers, RAII и пр. (Я могу вспомнить пару плохонаписанных, не наших, C проектов, которые мы переводили на C++ и в наиболее геморойных местах заменяли C указатели на smart pointers). В C++ можно всегда и просто встроить код на C, который будет работать очень быстро: совместимость с C — ключевое свойство C++ для системного программирования. C Rust, как и с D (тоже была такая 'лучшая' альтернатива C++), будут еще телодвижения на совместную компиляцию с C.
А еще видел неплохое, относительно нейтральное, сравнение C и Rust.
Перевод хороший, но оригинальная статья имеет очень странную "отсебятину" в сторону Rust.
Прям очень громкое заявление. Речь идет о драйверах, которые и сейчас на C часто не удовлетворяют стилю кодирования, принятому в ядре. Очень сомнительно, что кто-то будет писать модули для основных подсистем Linux (аллокаторы памяти, СС алгоритмы в сети, LSM модули и пр.) на Rust.
Чтобы было больше треша, на Netdev предлагали и Lua в ядре https://lwn.net/Articles/830154/
На мой взгляд сканировать журнал событий и по нему собирать статистику — не очень оптимально. Если правильно понял описание ваших скриптов, то в Linux это делается с помощью fail2ban.
В Tempesta FW есть специальное правило для блокировки переборщиков паролей. Например,
заблокирует IP клиента, если его запросы сгенерировали 10 ответов с кодами 401 или 403 за 3 секунды.
Так же, таки блокировки можно делать и на ModSecurity.
Про ветярнные мельницы я не понял. Мы бьемся за быстрый HTTPS. Для нас "нагруженной системой" может быть, как массивный bare metal, так и однопроцессорная VM, которая тоже должна работать быстро. Для нас, как и большинства людей, не очень приемлемо молотить все доступные CPU на 100% даже при простое.
C теорией NAPI и сетевых прерываний я знаком, но за ссылку спасибо :) Вопросов все равно много остается: проборс VF с VM и SR-IOV — это один только из кейсов, а что будет с трафиком между двумя VM на одном хосте? Будет куча VM-EXIT и в
perf kvm statбудутEXTERNAL_INTERRUPT.Поживем, увидим как будут развиваться серверные ARM, но пока у них use cases очень ограничены.
Привет!
В среднем по больниц, понятно. Я мимоходом смотрел, например, на Marvell ThunderX2, которые до 256 потоков имеют, и как-то не понятно как там с APIC, а что с виртуализацией — тем более. Работал с ними или смотрел подробнее? У Xeon с vAPIC не очень — 4 машины (entry level) взяли и ни у одной не было vAPIC полного, чтобы KVM не воткнула на I/O.
С сетью у нас интересная история. С packet forwarding/filtering на уровнях L2-L4 все понятно — логики мало и она относительно легко скейлится на ядра, DPDK и пр. kernel bypass рулят. У нас же HTTPS прокси и в perf top, как правило, HTTP parser, криптография, различная прикладня логика, например генерация cookie или javascript челленджей, матчинг HTTP заголовков опять же. Т.е. сетевых функций Linux networking мы не видим. Но при, этом без vAPIC в KVM и мы и Nginx "втыкаем" по полной и разница по произволительности 2 раза в лучшем случае.
Кстати, я недавно писал про user-space TCP в приложении для HTTP. У Seastar реализация TCP фейковая (в смысле "fake it before you make it") — просто, чтобы поставить рекодные бенчмарки: очень мало кода и с кучей TODO. F-stack показывает хорошие результаты, но я проверил сделали ли они что-то с известной проблемой хеш таблицей TCP соединений (она же давно была описана CloudFlare), но и в ядре Linux, и FreeBSD, и F-stack реализация все та же и примерно с одним подходом.
Итого, несмотря на отличные бенчмарки и безумное число ядер ARM, если у них нет хорошего APIC — с сетью, и думаю, с дисковым I/O тоже, все будет плохо. Нет поддержики виртуализации (в т.ч. virtual page talbe) — все плохо будет в облаках. И что останется? Числодробилки для ML?.. Возможно, и это ложится в карту NVIDIA.
Вообще-то, пишут. И иногда на CISC асемблере писать проще, чем на C. Посмотрите ядро Linux или более или менее быструю криптобиблитеку (OpenSSL, WolfSSL, Tempesta TLS). Простой пример: как сложить два 128-битных числа (каждое из которых по 2 long'а)? На C вам прийдется делать телодвижения с битом переноса, а на ассеблере у вас уже есть инструкция, которая в старшее 64-битное число добавит перенос со сложения прошлых 64-х битных чисел. Но, с другой стороны, те, кто упирается в бенчмарки, погемороятся с RISC ассемблером.
Я не очень хорошо знаком с ARM, но интересует что у этой архитектуры с virtual APIC? На x86 без vAPIC сеть в виртуалке очень тормозит.
Слышал от знакомых жалобу на другую проблему с APIC на каких-то ARM процессорах: на 8-и ядерном ARM (не знаю точно каком) нельзя было разбросать очереди прерываний с сетевой карты на разные ядра — все прерывания уходили на одно ядро. Как у современных ARM (которые по 128 потоков и выше умеют) дела с APIC?