Pull to refresh
39
0
Send message

Сделать частью кристалла сильно накладно выйдет. Память придётся делать по тому же техпроцессу что и проц. Ну и уровень брака вырастет сильно - битая память - кристалл на выброс. Чиплет - как в 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), то ситуация для планировщика стала уж совсем трудная, поэтому очень логичным выглядит шаг убрать это недоразумение совсем.

Из анекдота: "Как сделать хорошо? - Нужно сначала сделать плохо, а потом вернуть как было..." :)

Порядок операндов в 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 проектов.

Рекомендую следующий алгоритм использования:

if( data_volume < cpu_cache_size )
   	storeu
 else {
   	stream

Для стерильных условий понятно, а как быть в реальных, когда потоков может быть очень много, на виртуализированных серверах, где программист не знает сколько ему достанется кеша в каждый конкретный тик.

Класс! Я как-то заморачивался подобным для платы на i.MX6 процессоре.

Но там был и SATA и mini PCI-E, и HDMI, т.е. много чего можно из него слепить.

А тут непонятно, вход для камеры есть, а видео выхода нет. Какие сценарии использования?

В принципе не вижу причин селектелу не давать в облаке gentoo

Очень простая причина - это поддержка. Чем сложнее система, тем больше с ней будет проблем у пользователей, а значит больше времени (и денег) уйдёт на тех. поддержку. Убрав Gentoo из списка доступных образов, они просто повысили порог входа. У кого хватает опыта - тот и так поставит, настроит и не будет кошмарить суппорт.

И это происходит не только в Selectel, например, Hetzner и OVH сделали точно так же.

CPU_FLAGS .. Именно флаги компилятору и делают всю магию с быстродействием

Эти флаги сделают манию только для довольно узко-специализированных вычислительных приложений. А вот если включить LTO добавив "-flto" в COMMON_FLAGS, то магия уже будет практически в каждой более-менее серьёзной программе.

не понимаю чем тот же арч не угодил

Например, понадобилась мне поддержка ARC в Exim, просто кровь из носу надо.
И что, в арче с 2019 года висит открытый тикет с просьбой включить поддержку ARC.
А в Gentoo добавил в USE, и пользуйся на здоровье, радуй жмейл сервера...

На эту тему тут была хорошая статья
https://habr.com/ru/articles/337000/

Получается что для примитивных процессоров - такой "хинт" компилятору это плюс. Т.к. он разместит вероятный кода сразу за if и не будет никаких промахов и перезагрузки конвеера. С другой стороны, у этих самых примитивных процессоров конвеер или короткий или его нет вообще, поэтому и плата за промах минимальная.

Для современных процессоров, такой "хинт" подскажет процессору куда идти при первом срабатывании, а дальше он уже сам.

нет никакого предсказателя ветвлений.

Вот и я на это обратил внимание. Что для современного процессора это не будет играть большого значения, так как у них очень развитые алгоритмы предсказания переходов.

Разве что для старых Atom-ов.

iptables хорош, особенно в сочетании с ipset, который почему-то не был упомянут в статье.
Но тем не менее, iptables - это уже устаревшее решение, которое в современных дистрибутивах заменено на nftables.

Я бы рекомендовал установить Monterey, чтобы пользоваться современными версиями Xcode и других инструментов.

Для последнего Xcode нужна Ventura. И только с последнего Xcode можно отправлять приложения в стор.

Немного некорректное сравнение стоимости (или выгоды).

В случае Yandex/Gmail/другие - платится за готовую услугу: заплатил - и пользуй на здоровье.

Со своим сервером - там же ещё надо найти админа, который настроит и будет присматривать. Хорошо если в штате такой есть. А вдруг он захочет повышение за дополнительный объём работы? Ну или на стороне искать.

То есть если бы вы предоставляли не аренду голого сервера, а услугу аренды почтового сервиса, с функционалом сопоставимым с "облачной" почтой, то было бы честно сравнивать.

Кроме того, чаще всего пользователи голосуют за Yandex/Gmail из-за удобного интерфейса и очень хорошей фильтрации спама.

У меня довольно большой опыт работы со SpamAssassin - это совсем не то что есть в Gmail. Ну и RoundCube, тоже на любителя, кроме того были очень серьёзные инциденты с безопасностью.

Потом надёжность, вы говорите что не страшно, если сервер пару дней полежит, отдохнёт.

Да, почта не потеряется. Но если большой начальник ждёт важное письмо, и с той стороны говорят что они отправили, то объяснение что почта когда-нибудь дойдёт, скорее всего, большого начальника не устроит...

Но в целом, при наличии рук и головы, действительно можно здорово сэкономить.

больно споткнувшись о глюк данной ФС...

Было такое же, много лет назад, как только появилась в ванильном ядре.

Бэкапный рейд с BTRFS был забит под завязку. И потом что-то сломалось, и файловая система уже не монтировалась. Очень долго мучился, пока получилось расширить том ещё одним диском и потом система ожила. В те времена это была очень серьёзная проблема, когда заканчивается свободное место, особенно при наличии большого количества снимков и использования сжатия. Сейчас вроде починили. Ну то есть как - понять сколько у тебя фактически есть свободного места всё так же не просто, но хотя бы не падает.

Ну и важно понимать, что CoW подходит далеко не для всех задач. Если нужен swap файл - то есть специальная утилита чтобы создать его правильно, а для баз CoW вообще лучше отключать - есть множество бенчмарков.

А вот для бекапов эта ФС идеальная. Именно поэтому она всё чаще идёт как система по-умолчанию на NAS устройствах.

1
23 ...

Information

Rating
4,371-st
Registered
Activity