Могу с полной уверенностью сказать, что ни один коммерческий NGFW сейчас не то, что не готов, даже близко в планах не сможет в такие блокировки, зная их внутрянку.
ТСПУ делает одна единственная контора, и делает уже очень давно. Бум российских NGFW вообще никак не связан с задачами блокировки интернета)
Все равно при вызове push_back будет проверка: не переполнился ли вектор, не надо ли снова аллоцировать. Поэтому тут мы остановились на варианте с std::vector<std::unique_ptr> без резервации.
Но почему push_back?) C emplace_back было бы компактнее))
Уже лучше, но все еще храним целых три указателя. Если таких property в классе много, а самих объектов тысячи (напр. акторы в игровом движке), может быть критично по памяти.
Возьём 100 свойств на объект и 10000 акторов. Указатель на self - 8 байт + два указателя на функции-члены (16+16 = 32 байта). 40 х 100 х 10000 = 35 MiB памяти. Сомнительная экономия.
> Не забывайте, вы имеете права кастомизировать поведение консоли и ее внешний вид
> Но я часто вижу, что бОльшую часть своего времени разработчики загораживают 10-40% своего экрана этим окном, с учетом того, что используют его 1-5% своего времени
Поясню зачем я это делаю. Любой лишний клик - раздражает и выбивает из потока куда сильнее, чем недостаток места на мониторе.
Любая кастомизация хоткеев и окон - превращает тебя в овоща, при необходимости сесть за новый ПК или при необходимости 5 минут посидеть за клавиатурой коллеги. Я стал чувствовать себя значительно комфортнее, когда перестал заниматься кастомизацией и просто приучил мозг к стандартным вещам. Некоторая кастомизация у меня есть, но она минимальна и автоматизируется. Развернуть рабочее окружение в новом месте для меня - это работа на 10 минут.
Спасибо большое за столь подробный ответ и проведенные замеры. Разница, как можно заметить, не существенная. vDSO конечно медленнее в целых два раза, но это наносекунды. В масштабах всего пайплайна - это капля в море. К тому же, замеры времени в VPP требуют синхронизации, что лишает временные метки свойства монотонности. Впрочем, это уже всё совсем другая история)
Я лишь хотел подсветить момент с тем, что получение времени - это не системный вызов. Я часто встречаю этот пример в разных учебниках и статьях, поэтому просто хотел уточнить этот момент для юных умов, что будут читать вашу статью .
Ещё раз спасибо за такой подробный ответ, редко встретишь людей, готовых заморочиться с бенчмарками для комментария на хабре.
Пример с временем: классические способы получения времени (std::chrono::steady_clock::now(), time(), gettimeofday()) — это syscall-ы. Каждый такой вызов — это дорогостоящее переключение контекста в ядро и обратно
Уже лет тысячу в Linux существует механизм VDSO решающий конкретно эту проблему. Понятное дело, что не все системные вызовы он закрывает , но именно получение времени не приводит к переключению контекста и почти бесплатно.
Всё бы хорошо, но сколько таких наборов инструкций у intel? Они появлялись в версиях архитектур сразу пачками, и дай боже наберётся 4 "поколения". Плюс, RISC-V позволяет иметь (и они существуют) проприоретарные расширения + некоторые наборы инструкций были реализованы до стандартизации и выглядят "почти также, но не так".
И там десятки расширений. Не, в целом-то понятно, что условный cpuid в помощь, пишите софт, диспетчеризуйте вызовы и вот это все, но это усложняет разработку - раз. Ибо комбинаторный взрыв имеет место быть и отладка всех сценариев будет дико дорогой.
Делает невозможным предсказать запустится ли такой софт у потребителя, а если запустится, то с какой производительностью.
В общем и целом, пока RISC-V не перестанут играть в лего, эта архитектура так и останется нишевой, ориентированной на разработку под заказ. CPU общего назначения на ней не изобрести
Они не борются за соотношение "цена-качество". Они борятся за соотношение "цена-объемы продаж". Качество тут просто побочный эффект. Если бы они продавать дикое дерьмище в бесконечных объемах по высокой цене, они бы его продавали)
Вообще, скорее всего будут) Но количество электроэнергии необходимого для конвертации всего и вся в 8 битную кодировку скорее всего сопоставимо с выигрышем, если не вообще есть.
Могу с полной уверенностью сказать, что ни один коммерческий NGFW сейчас не то, что не готов, даже близко в планах не сможет в такие блокировки, зная их внутрянку.
ТСПУ делает одна единственная контора, и делает уже очень давно. Бум российских NGFW вообще никак не связан с задачами блокировки интернета)
Я в жизни для собеседования столько не заморачивался))
Но почему push_back?) C emplace_back было бы компактнее))
https://godbolt.org/z/bEdx6hn4G
Гспди. Просто используйте Linux Mint с cinnamon окружением (форк gnome2) и получите то же самое, только не в noname в дистрибутиве
Такие телефоны в жизни не потянут 10000 акторов на сцене) Там дай бог 1000-то уместится)
Возьём 100 свойств на объект и 10000 акторов. Указатель на self - 8 байт + два указателя на функции-члены (16+16 = 32 байта). 40 х 100 х 10000 = 35 MiB памяти. Сомнительная экономия.
Но это даже близко не C#-like свойства. Смысл был бы, если бы финальный синтаксис получится бы каким-то таким
Ну, понятное дело, что ещё надо будет где-то прикопать this и всё такое и возможно для этого можно было бы немного макросов добавить.
А финальный результат из статьи - это просто очередная монструозная конструкция из макросов, такого придумали уже все подряд)
P.S.
Уже 26-й год скоро) Можно вместое enable_if использовать концепты
Поясню зачем я это делаю. Любой лишний клик - раздражает и выбивает из потока куда сильнее, чем недостаток места на мониторе.
Любая кастомизация хоткеев и окон - превращает тебя в овоща, при необходимости сесть за новый ПК или при необходимости 5 минут посидеть за клавиатурой коллеги. Я стал чувствовать себя значительно комфортнее, когда перестал заниматься кастомизацией и просто приучил мозг к стандартным вещам. Некоторая кастомизация у меня есть, но она минимальна и автоматизируется. Развернуть рабочее окружение в новом месте для меня - это работа на 10 минут.
Если хочется совсем cutting edge потрогать, посмотрите ещё и в сторону grout.
Спасибо большое за столь подробный ответ и проведенные замеры. Разница, как можно заметить, не существенная. vDSO конечно медленнее в целых два раза, но это наносекунды. В масштабах всего пайплайна - это капля в море. К тому же, замеры времени в VPP требуют синхронизации, что лишает временные метки свойства монотонности. Впрочем, это уже всё совсем другая история)
Я лишь хотел подсветить момент с тем, что получение времени - это не системный вызов. Я часто встречаю этот пример в разных учебниках и статьях, поэтому просто хотел уточнить этот момент для юных умов, что будут читать вашу статью .
Ещё раз спасибо за такой подробный ответ, редко встретишь людей, готовых заморочиться с бенчмарками для комментария на хабре.
Уже лет тысячу в Linux существует механизм VDSO решающий конкретно эту проблему. Понятное дело, что не все системные вызовы он закрывает , но именно получение времени не приводит к переключению контекста и почти бесплатно.
Возможно даже 44 000 раз)
Всё бы хорошо, но сколько таких наборов инструкций у intel? Они появлялись в версиях архитектур сразу пачками, и дай боже наберётся 4 "поколения". Плюс, RISC-V позволяет иметь (и они существуют) проприоретарные расширения + некоторые наборы инструкций были реализованы до стандартизации и выглядят "почти также, но не так".
И там десятки расширений. Не, в целом-то понятно, что условный cpuid в помощь, пишите софт, диспетчеризуйте вызовы и вот это все, но это усложняет разработку - раз. Ибо комбинаторный взрыв имеет место быть и отладка всех сценариев будет дико дорогой.
Делает невозможным предсказать запустится ли такой софт у потребителя, а если запустится, то с какой производительностью.
В общем и целом, пока RISC-V не перестанут играть в лего, эта архитектура так и останется нишевой, ориентированной на разработку под заказ. CPU общего назначения на ней не изобрести
Основная проблема подхода RISC-V - невозможно писать сколько-нибудь предсказуемый по производительности и переносимый софт.
К каждому бинарню под RISC-V должна где-то идти инструкция, на каких процессорах оно может запуститься. Это просто дикий ужас.
Eclipse, Borlands - даже не смешно)
MacAfee, Norton - не припомню я, чтобы там был опенсорс какой-то, чтобы его можно было "слизать"
Теперь будет два уровня перегруженности)
explorer.exe и так по сути основной процесс, без которого UI бесполезен) Он и так давно захватил систему)
А можно мне рассказать? Я вот что-то не наблюдаю)
Они не борются за соотношение "цена-качество". Они борятся за соотношение "цена-объемы продаж". Качество тут просто побочный эффект. Если бы они продавать дикое дерьмище в бесконечных объемах по высокой цене, они бы его продавали)
Вообще, скорее всего будут) Но количество электроэнергии необходимого для конвертации всего и вся в 8 битную кодировку скорее всего сопоставимо с выигрышем, если не вообще есть.