А можно, пожалуйста, ключевые слова? То есть названия антибиотиков. На самом деле я тоже подозреваю что мне что-то такое должно помочь. Но перед тем как идти к ЛОРу, нужно хорошо подготовиться теоретически.
Тут скорее как с экстремальными формами ожирения, когда без операций совсем никак. Я промывал пока это было возможно. Потом, для того чтобы промыть, нужно было уже пшикать сосудосуживающие, чтобы хоть какой-то просвет появился. После операции два года было отлично, совсем другое качество жизни. Сейчас всё чаще закладывает, от регулярного промывания пересушивается слизистая, нужно ещё масла пшикать. Если промывать (может не очень аккуратно) во время простуды, то можно занести инфекцию в ухо, два раза был отит - мало приятного. Проблема в том, что неизвестна причина этого явления. Если бы операция не была такая дорогая, то её можно было бы рассматривать как регулярную стрижку ногтей или волос ...
Для ноутбуков среднего и нижнего ценовых сегментов
А там это уже может иметь смысл, особенно если оперативной памяти действительно сильно не хватает. Ещё один класс применений это бездисковые станции, или виртуалки, у которых скорость, может быть ещё в порядке, а вот время доступа часто гораздо хуже - а его тоже надо учитывать.
Вот пример, программа выделяет себе кусок памяти с блокировкой страниц (не 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 приложение отправляло в аналитику каждое перемещение мышки с координатами. На вопрос зачем? Это же куча данных! Ответили что потом разберутся.
Для стерильных условий понятно, а как быть в реальных, когда потоков может быть очень много, на виртуализированных серверах, где программист не знает сколько ему достанется кеша в каждый конкретный тик.
так есть же уже answeroverflow, в котором бот kapa.ai несёт разную дичь и доводит юзеров до белого каления.
А можно, пожалуйста, ключевые слова? То есть названия антибиотиков.
На самом деле я тоже подозреваю что мне что-то такое должно помочь.
Но перед тем как идти к ЛОРу, нужно хорошо подготовиться теоретически.
Тут скорее как с экстремальными формами ожирения, когда без операций совсем никак.
Я промывал пока это было возможно. Потом, для того чтобы промыть, нужно было уже пшикать сосудосуживающие, чтобы хоть какой-то просвет появился.
После операции два года было отлично, совсем другое качество жизни.
Сейчас всё чаще закладывает, от регулярного промывания пересушивается слизистая, нужно ещё масла пшикать. Если промывать (может не очень аккуратно) во время простуды, то можно занести инфекцию в ухо, два раза был отит - мало приятного.
Проблема в том, что неизвестна причина этого явления.
Если бы операция не была такая дорогая, то её можно было бы рассматривать как регулярную стрижку ногтей или волос ...
В моём случае через два года после операции всё вернулось. У знакомого тоже.
Я бы ещё ClickHouse Keeper упомянул. Без Java, с простым и понятным конфигом.
Устанавливается, но не видит порты, т.е. пустой серый список.
Придумали, Rybelsus, например. Или Ozempic в виде инъекции. Только пока очень дорого.
Автор статьи специально оговаривает условия
А там это уже может иметь смысл, особенно если оперативной памяти действительно сильно не хватает.
Ещё один класс применений это бездисковые станции, или виртуалки, у которых скорость, может быть ещё в порядке, а вот время доступа часто гораздо хуже - а его тоже надо учитывать.
Вот пример, программа выделяет себе кусок памяти с блокировкой страниц (не 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, т.е. много чего можно из него слепить.
А тут непонятно, вход для камеры есть, а видео выхода нет. Какие сценарии использования?