Для ноутбуков среднего и нижнего ценовых сегментов
А там это уже может иметь смысл, особенно если оперативной памяти действительно сильно не хватает. Ещё один класс применений это бездисковые станции, или виртуалки, у которых скорость, может быть ещё в порядке, а вот время доступа часто гораздо хуже - а его тоже надо учитывать.
Вот пример, программа выделяет себе кусок памяти с блокировкой страниц (не lazy).
Для какого-нибудь буфера, кэша или вообще просто так (деградация и ожирение софта никуда не делись). И вот системе стало не хватать памяти, и она хочет выгрузить в подкачку эти "пустые" страницы. Допустим 100 мегабайт:) Без ZSWAP она физически запишет все данные на диск, а если когда понадобятся - то все 100 будет вычитывать. В случае ZSWAP нолики прекрасно и быстро сожмутся, и в виде десятков байт останутся в памяти, а когда понадобятся - то мгновенно распакуются.
ZRAM — модуль ядра Linux, ранее известный как compcache. До версии ядра 3.14 находился в экспериментальной ветке, с 3.14 перемещён в основную. Суть его в том, что в оперативной памяти создаётся сжатый раздел подкачки (swap). ... Можно считать ZSWAP продвинутым вариантом ZRAM
Какая-то ересь написана. ZRAM - это блочное устройство, диск в памяти, со сжатием данных. ZSWAP - это действительно сжатый кэш для файла подкачки. Ну, то есть, это совершенно разные вещи.
Сделать частью кристалла сильно накладно выйдет. Память придётся делать по тому же техпроцессу что и проц. Ну и уровень брака вырастет сильно - битая память - кристалл на выброс. Чиплет - как в AMD 3D V-Cache - тоже дорого. А с отдельными модулями памяти появляется дополнительная гибкость - больше/меньше памяти - "новый" проц - маркетологи потирают ручки.
Так память быстрее не стала, время доступа (в тактах CPU) только растёт.
Не спорю, скорее так и есть. Если есть какие-то циферки, будет интересно изучить.
Если брать не только время доступа, но и пропускную способность, то она точно выросла, и очень серьёзно. DDR4 быстрее DDR2 примерно в 4 раза. Тактовая частота процессора со времён P4/HT (3.6-3.8GHz) ещё настолько не поднялась.
В результате сегодня ситуации, в которых отключение smt имеет смысл, стали встречаться совсем редко.
Ну да, потому что такой софт получил "оптимизацию" для работы с HT, которая заключается в том, чтобы найти физические ядра, и с помощью affinity mask запретить планировщику ОС запускать там потоки, ну и не запускать больше считающих потоков, чем есть физических ядер. Но в общем и целом согласен, что сейчас от HT больше плюсов, чем минусов - т.е. обещанные +30% до сих пор можно легко получить во многих задачах.
Как мне кажется, если в Intel от HT таки откажутся, то не везде, а только там где будут E-ядра. Так как это сильно упростил логику работы планировщика. Не нужны будут разные "костыли" в виде Intel APO и разработчикам игр не нужно будет реализовывать свой планировщик (но это не точно :)
Кроме того, возможно, транзисторный бюджет на реализацию E-ядер не намного больше, чем на реализацию HT. А "честное" ядро всяко лучше логического.
Ну, HyperThreading это очень даже аппаратная, а не программная функция. Имела какой-то смысл в специализированных задачах, где узким местом был (медленный) доступ к памяти. В целом классе задач HT только мешал. Ну а как появились разные ядра (performance и energy efficient), то ситуация для планировщика стала уж совсем трудная, поэтому очень логичным выглядит шаг убрать это недоразумение совсем.
Из анекдота: "Как сделать хорошо? - Нужно сначала сделать плохо, а потом вернуть как было..." :)
Я думаю что это продолжение проблемы с "ожирением программного обеспечения". Почему никого не пугает, что установщик драйверов для видеокарты занимает гигабайт, а распакованные на диске 3.9G ? - это же больше, чем установленная Windows XP со всеми драйверами и некоторыми программами! Так и тут, всё больше "умных" гаджетов, IoT и всё такое. И всё меньше программистов, которые понимают размерность данных - килобайт, мегабайт, гигабайт - много это или мало. С ужасом для себя узнал, что есть, оказывается, Python для микроконтроллеров ...
Недавно проводил переучёт, кто больше всего в доме потребляет. Оказалось что инвертор для солнечных панелей. Причём когда солнца нет, т.е. панели не генерируют ничего, то трафик ещё приемлемый, хотя не представляю что там может быть в той телеметрии, в приложении только пара параметров отображается. Может они конечно каждую секунду шлют. Но вот когда есть солнце, появляется множество других подключений! По GeoIP адреса из моей округи. И трафик может быть до 40кб/с на выход и 300кб/с на вход. Не знаю что это, предполагаю что инверторы обмениваются инфой и договариваются о том, кто будет лить в какую фазу и сколько. Такой себе mesh.
Или вот ещё пример, клиент захотел чтобы web приложение отправляло в аналитику каждое перемещение мышки с координатами. На вопрос зачем? Это же куча данных! Ответили что потом разберутся.
Для стерильных условий понятно, а как быть в реальных, когда потоков может быть очень много, на виртуализированных серверах, где программист не знает сколько ему достанется кеша в каждый конкретный тик.
В принципе не вижу причин селектелу не давать в облаке gentoo
Очень простая причина - это поддержка. Чем сложнее система, тем больше с ней будет проблем у пользователей, а значит больше времени (и денег) уйдёт на тех. поддержку. Убрав Gentoo из списка доступных образов, они просто повысили порог входа. У кого хватает опыта - тот и так поставит, настроит и не будет кошмарить суппорт.
И это происходит не только в Selectel, например, Hetzner и OVH сделали точно так же.
CPU_FLAGS .. Именно флаги компилятору и делают всю магию с быстродействием
Эти флаги сделают манию только для довольно узко-специализированных вычислительных приложений. А вот если включить LTO добавив "-flto" в COMMON_FLAGS, то магия уже будет практически в каждой более-менее серьёзной программе.
Например, понадобилась мне поддержка ARC в Exim, просто кровь из носу надо. И что, в арче с 2019 года висит открытый тикет с просьбой включить поддержку ARC. А в Gentoo добавил в USE, и пользуйся на здоровье, радуй жмейл сервера...
Получается что для примитивных процессоров - такой "хинт" компилятору это плюс. Т.к. он разместит вероятный кода сразу за if и не будет никаких промахов и перезагрузки конвеера. С другой стороны, у этих самых примитивных процессоров конвеер или короткий или его нет вообще, поэтому и плата за промах минимальная.
Для современных процессоров, такой "хинт" подскажет процессору куда идти при первом срабатывании, а дальше он уже сам.
Вот и я на это обратил внимание. Что для современного процессора это не будет играть большого значения, так как у них очень развитые алгоритмы предсказания переходов.
iptables хорош, особенно в сочетании с ipset, который почему-то не был упомянут в статье. Но тем не менее, iptables - это уже устаревшее решение, которое в современных дистрибутивах заменено на nftables.
Автор статьи специально оговаривает условия
А там это уже может иметь смысл, особенно если оперативной памяти действительно сильно не хватает.
Ещё один класс применений это бездисковые станции, или виртуалки, у которых скорость, может быть ещё в порядке, а вот время доступа часто гораздо хуже - а его тоже надо учитывать.
Вот пример, программа выделяет себе кусок памяти с блокировкой страниц (не lazy).
Для какого-нибудь буфера, кэша или вообще просто так (деградация и ожирение софта никуда не делись).
И вот системе стало не хватать памяти, и она хочет выгрузить в подкачку эти "пустые" страницы. Допустим 100 мегабайт:) Без ZSWAP она физически запишет все данные на диск, а если когда понадобятся - то все 100 будет вычитывать.
В случае ZSWAP нолики прекрасно и быстро сожмутся, и в виде десятков байт останутся в памяти, а когда понадобятся - то мгновенно распакуются.
Какая-то ересь написана. ZRAM - это блочное устройство, диск в памяти, со сжатием данных.
ZSWAP - это действительно сжатый кэш для файла подкачки.
Ну, то есть, это совершенно разные вещи.
Сделать частью кристалла сильно накладно выйдет. Память придётся делать по тому же техпроцессу что и проц. Ну и уровень брака вырастет сильно - битая память - кристалл на выброс. Чиплет - как в AMD 3D V-Cache - тоже дорого.
А с отдельными модулями памяти появляется дополнительная гибкость - больше/меньше памяти - "новый" проц - маркетологи потирают ручки.
Не спорю, скорее так и есть. Если есть какие-то циферки, будет интересно изучить.
Если брать не только время доступа, но и пропускную способность, то она точно выросла, и очень серьёзно. DDR4 быстрее DDR2 примерно в 4 раза. Тактовая частота процессора со времён P4/HT (3.6-3.8GHz) ещё настолько не поднялась.
Ну да, потому что такой софт получил "оптимизацию" для работы с HT, которая заключается в том, чтобы найти физические ядра, и с помощью affinity mask запретить планировщику ОС запускать там потоки, ну и не запускать больше считающих потоков, чем есть физических ядер. Но в общем и целом согласен, что сейчас от HT больше плюсов, чем минусов - т.е. обещанные +30% до сих пор можно легко получить во многих задачах.
Как мне кажется, если в Intel от HT таки откажутся, то не везде, а только там где будут E-ядра. Так как это сильно упростил логику работы планировщика. Не нужны будут разные "костыли" в виде Intel APO и разработчикам игр не нужно будет реализовывать свой планировщик (но это не точно :)
Кроме того, возможно, транзисторный бюджет на реализацию E-ядер не намного больше, чем на реализацию HT. А "честное" ядро всяко лучше логического.
Ну, HyperThreading это очень даже аппаратная, а не программная функция. Имела какой-то смысл в специализированных задачах, где узким местом был (медленный) доступ к памяти. В целом классе задач HT только мешал. Ну а как появились разные ядра (performance и energy efficient), то ситуация для планировщика стала уж совсем трудная, поэтому очень логичным выглядит шаг убрать это недоразумение совсем.
Из анекдота: "Как сделать хорошо? - Нужно сначала сделать плохо, а потом вернуть как было..." :)
Порядок операндов в gas для инструкции MOV на x86 выглядит как-то очень непривычно после "классического" ассемблера.
А почему вы выбрали 1.3.1 кодек за 19-ый год, а не 1.4 за 23-ий?
Или он "разжирел" ?
Теоретически, D+/D- c SUB разъёма идут сразу на ноги CH340, т.е. можно пробовать подпаяться туда.
Утюгов и шуруповёртов с Wi-Fi ещё не встречал, а всё остальное перечисленное вами уже есть :)
Я думаю что это продолжение проблемы с "ожирением программного обеспечения".
Почему никого не пугает, что установщик драйверов для видеокарты занимает гигабайт, а распакованные на диске 3.9G ? - это же больше, чем установленная Windows XP со всеми драйверами и некоторыми программами!
Так и тут, всё больше "умных" гаджетов, IoT и всё такое. И всё меньше программистов, которые понимают размерность данных - килобайт, мегабайт, гигабайт - много это или мало. С ужасом для себя узнал, что есть, оказывается, Python для микроконтроллеров ...
Недавно проводил переучёт, кто больше всего в доме потребляет. Оказалось что инвертор для солнечных панелей. Причём когда солнца нет, т.е. панели не генерируют ничего, то трафик ещё приемлемый, хотя не представляю что там может быть в той телеметрии, в приложении только пара параметров отображается. Может они конечно каждую секунду шлют. Но вот когда есть солнце, появляется множество других подключений! По GeoIP адреса из моей округи. И трафик может быть до 40кб/с на выход и 300кб/с на вход. Не знаю что это, предполагаю что инверторы обмениваются инфой и договариваются о том, кто будет лить в какую фазу и сколько. Такой себе mesh.
Или вот ещё пример, клиент захотел чтобы web приложение отправляло в аналитику каждое перемещение мышки с координатами. На вопрос зачем? Это же куча данных! Ответили что потом разберутся.
Очень странно, что обошли вниманием игру Alyx от Valve - это же шедевр, шаблон и планка качества для остальных VR проектов.
Для стерильных условий понятно, а как быть в реальных, когда потоков может быть очень много, на виртуализированных серверах, где программист не знает сколько ему достанется кеша в каждый конкретный тик.
Класс! Я как-то заморачивался подобным для платы на i.MX6 процессоре.
Но там был и SATA и mini PCI-E, и HDMI, т.е. много чего можно из него слепить.
А тут непонятно, вход для камеры есть, а видео выхода нет. Какие сценарии использования?
Очень простая причина - это поддержка. Чем сложнее система, тем больше с ней будет проблем у пользователей, а значит больше времени (и денег) уйдёт на тех. поддержку. Убрав Gentoo из списка доступных образов, они просто повысили порог входа. У кого хватает опыта - тот и так поставит, настроит и не будет кошмарить суппорт.
И это происходит не только в Selectel, например, Hetzner и OVH сделали точно так же.
Эти флаги сделают манию только для довольно узко-специализированных вычислительных приложений. А вот если включить LTO добавив "-flto" в COMMON_FLAGS, то магия уже будет практически в каждой более-менее серьёзной программе.
Например, понадобилась мне поддержка ARC в Exim, просто кровь из носу надо.
И что, в арче с 2019 года висит открытый тикет с просьбой включить поддержку ARC.
А в Gentoo добавил в USE, и пользуйся на здоровье, радуй жмейл сервера...
На эту тему тут была хорошая статья
https://habr.com/ru/articles/337000/
Получается что для примитивных процессоров - такой "хинт" компилятору это плюс. Т.к. он разместит вероятный кода сразу за if и не будет никаких промахов и перезагрузки конвеера. С другой стороны, у этих самых примитивных процессоров конвеер или короткий или его нет вообще, поэтому и плата за промах минимальная.
Для современных процессоров, такой "хинт" подскажет процессору куда идти при первом срабатывании, а дальше он уже сам.
Вот и я на это обратил внимание. Что для современного процессора это не будет играть большого значения, так как у них очень развитые алгоритмы предсказания переходов.
Разве что для старых Atom-ов.
iptables хорош, особенно в сочетании с ipset, который почему-то не был упомянут в статье.
Но тем не менее, iptables - это уже устаревшее решение, которое в современных дистрибутивах заменено на nftables.
Для последнего Xcode нужна Ventura. И только с последнего Xcode можно отправлять приложения в стор.