Хм, ну автор здесь использует самописный ROM, в который можно записать работу с разнообразными интерфейсами. Вопрос только в источнике сигнала. Можно извернутся еще больше — использовать азбуку Морзе, например.
npm проверят версию окружения. Но выбрасывает error если установлена опция engine-strict. На уровне проекта эту опцию можно установить через .npmrc рядом с package.json.
У нас в schema registry хранятся схемы разных форматов. Специально обученный робот генерирует валидаторы, доки, API клиенты,…
Изначально тоже было OpenAPI, но с развитием обмена данными через очереди, обновили код на поддержку AsyncAPI.
Вообще CLS крутая штука, удобно автоматически пробрасывать контекст (а-ля tracking id / user). Но нужно быть весьма внимательным, да, чтоб не напороться на проблемы.
В модуле fs появились новые функции: fs.readSync, fs.readv, fs.readvSync.
fs.readSync был чуть ли не в первой ревизии ноды. Сейчас просто запилили версию функции с другой сигнатурой.
Много интересного можно найти в новом API для отслеживания ресурсов в асинхронном программировании: async_hooks
Нативные расширения могут контекст подпортить (да и не нативные тоже), поэтому нужно весьма аккуратно использовать async_hooks. В частности у нас с node-redis проблемы были.
На синтетическом с nop'ами более-менее очевидно как они странслируются в mop'ы и как будет нагружен кэш.
А вот практический пример не особо понятен. Ок, по метрикам видим, что кэш используется неэффективно. Исходя из предыдущих тезисов статьи — это потому что mop'ы раскиданы по разным кэш-линейкам? Тогда есть вопрос — как пришли к тому, что нужно развернуть цикл? Я так полагаю что нужно было бы смоделировать a) разбивку инструкцию по mop'ам b) формирование кэша с учётом внутренней логики распределения mop'ов по линейкам. И всё это сделать глядя на C'шный код? ;)
Или просто эмпирическая догадка — а-ля замерим-ка развернутый цикл и посмотрим вдруг микроинструкции легли более четко на кэш?
При этом на простых дизайнах прототип JIT-симулятора LLHD показывал производительность в 2.4 раза лучше, чем десятилетиями полируемый проприетарный симулятор, и только на масштабной симуляции ядра RISC-V проприетарный симулятор заметно вырвался вперед.
Ну по табличке это совсем не так. То же пересечение тактовых доменов симулируется почему-то в 1.5x раза медленнее. Хотя там нет особого простора для оптимизации, имхо.
Heroku вообще скорее жив чем мертв :)
Хорошо что часть инфраструктуры на aws eu-east.
Хм, ну автор здесь использует самописный ROM, в который можно записать работу с разнообразными интерфейсами. Вопрос только в источнике сигнала. Можно извернутся еще больше — использовать азбуку Морзе, например.
npm проверят версию окружения. Но выбрасывает
errorесли установлена опцияengine-strict. На уровне проекта эту опцию можно установить через.npmrcрядом сpackage.json.Была небольшая проблема, то что если есть lockfile, то проверка не проводилась, но в npm@7 уже пофиксили — https://github.com/npm/arborist/pull/143
У нас в schema registry хранятся схемы разных форматов. Специально обученный робот генерирует валидаторы, доки, API клиенты,…
Изначально тоже было OpenAPI, но с развитием обмена данными через очереди, обновили код на поддержку AsyncAPI.
Для каких целей используется schema registry? Почему OpenAPI, заточенный под HTTP-протокол, а не что-то типа Async API?
https://gitlab.com/tvoybro/multimatograf2020/-/blob/master/main.c#L564
ай-ай-ай ;)
10/11, последний вопрос подвёл — на внимательность ;)
У меня, кстати, лежит плата под iAPX 432. Может дойдут руки пощупать этот процессор в живую.
У Intel было много ISA, как минимум с десяток. Ни одна, кроме x86 не выстрелила, увы.
10% наклона это совсем не мало)
А зачем UART через USB пробрасывать, если можно поднять тот же CDC через уже подключенный USB? Благо в cubemx это делается очень просто.
Вроде это стандартный подход. Разве что я добавлял
retryNoв payload, а не использовал заголовок.Нет, не починили. По крайней мере, я пару месяцев назад проверял. Но конкретно в наших задачах блок идёт по io, а не по cpu.
Вообще CLS крутая штука, удобно автоматически пробрасывать контекст (а-ля tracking id / user). Но нужно быть весьма внимательным, да, чтоб не напороться на проблемы.
Концептуальные проблемы
async_hooksобсуждаются тут — https://github.com/nodejs/diagnostics/issues/300Конкретно, что у нас встречалось — https://github.com/nodejs/node/issues/16098
Пфф, вообще без проблем :) Я весьма далек от всех этих ваших аднроидов, поэтому даже не запускал приложение, а сразу начал со статического анализа :)
fs.readSyncбыл чуть ли не в первой ревизии ноды. Сейчас просто запилили версию функции с другой сигнатурой.Нативные расширения могут контекст подпортить (да и не нативные тоже), поэтому нужно весьма аккуратно использовать
async_hooks. В частности у нас сnode-redisпроблемы были.Ага, то есть глянули сгенерированные инструкции, прикинули сколько микроперации и заприметили что просадка идёт потому что их 7.
На синтетическом с nop'ами более-менее очевидно как они странслируются в mop'ы и как будет нагружен кэш.
А вот практический пример не особо понятен. Ок, по метрикам видим, что кэш используется неэффективно. Исходя из предыдущих тезисов статьи — это потому что mop'ы раскиданы по разным кэш-линейкам? Тогда есть вопрос — как пришли к тому, что нужно развернуть цикл? Я так полагаю что нужно было бы смоделировать a) разбивку инструкцию по mop'ам b) формирование кэша с учётом внутренней логики распределения mop'ов по линейкам. И всё это сделать глядя на C'шный код? ;)
Или просто эмпирическая догадка — а-ля замерим-ка развернутый цикл и посмотрим вдруг микроинструкции легли более четко на кэш?
Ну по табличке это совсем не так. То же пересечение тактовых доменов симулируется почему-то в 1.5x раза медленнее. Хотя там нет особого простора для оптимизации, имхо.