Комментарии 25
Григорий, волнуюсь за вас, что-то случилось?
Григорий, волнуюсь за вас, что-то случилось?
Пока писал третью часть опуса выше, обнаружил что hyper-v местами - пропаганда разных веществ. Очень расстроился.
"Не ожидал я, что получу в итоге +230 - 232 в карму, всего 462 голоса. "
Дополню вопрос, а что случилось с вашим аккаунтом? Админы хабра обнулили всю карму и голоса за неё, но оставили все статьи? Сейчас 25 человек голосовало за карму, т.е. куда-то пропали старые 462 голоса.
Если бы старых статей не было, то я бы подумал, что это просто новый аккаунт создан.
- Кроме того, оказывается что на Хабре осталось меньше 300-500 живых людей с правом голоса за карму.
Что-то вспомнилось теория мертвого интернета
У мне ещё кажется что Hyperthreading зло. Первые 50 процентов по CPU условно честные. А вот дальше... Вторые 50 процентов это максимум 25. Но при приближении к 100 процентам страдает cache hits для L3 cache и cross numa каналы
Кстати, MSSQL с его огромным плоским buffer cache это очень неудобная аппликация как для L3 cache, так и для NUMA - нет привязки тредов к месту памяти, они могут рандомно читать отовсюду.
К сожалению что cache hits L3, что загрузку Numa можно снять только специальным оборудованием, метрик таких нет
У мне ещё кажется что Hyperthreading зло. Первые 50 процентов по CPU условно честные. А вот дальше... Вторые 50 процентов это максимум 25. Но при приближении к 100 процентам страдает cache hits для L3 cache и cross numa каналы
Так и должно быть. HT это не отдельное ядро, а попытка хоть как-то задействовать простаивающие ALU ядра. Если на ядре выполняются два разношёрстных потока, это худо-бедно выигрышно. А если одинаковые, то лучше вовсе запретить шедулить такие потоки на HT "ядро".
У мне ещё кажется что Hyperthreading зло. Первые 50 процентов по CPU условно честные. А вот дальше... Вторые 50 процентов это максимум 25. Но при приближении к 100 процентам страдает cache hits для L3 cache и cross numa каналы
10-15% пользы после забивания задачами реальных ядер.
Это вы ещё на архитектуру ARM не перешли. Где зачастую у разных ядер разная производительность, как в Apple Silicon. Как следствие – симметрично мультипроцессорная программа на 4 ядрах работает быстрее, чем на 8.
Ну хоть в серверном исполнении это не так? Было бы странно. Я понимаю ноут...
К примеру, Mac Pro в девятнадцатидюймовом исполнении – вроде бы как сервер по внешним признакам. Имеет 24-core CPU with 16 performance cores and 8 efficiency cores.
Ну все таки это не настоящий сервер. Настоящий сервер это несколько вентиляторов, дублирующиеся блоки питания, iDrac/iLo, скорее всего отсутствие диска, ну и 64/192Gb как то смешно для сервера
Ну так можно и до того договориться, что настоящий сервер занимает несколько шкафов, и опять придём к несимметричной производительности.
А фишка Silicon в том, что оперативная память встроена в процессор для ускорения доступа. Можно считать, что это кеш по интеловским меркам.
И формат у него не стоечный.
скорее всего отсутствие диска,
С чего бы? Наоборот, в современной инфраструктуре у сервера будут не только загрузочные м.2 , но и 20-24 SSD и штуки 4 nvme
дублирующиеся блоки питания,
300W auxiliary power available:
Two 6-pin connectors delivering 75W of power each
Я тоже так думал, что больше ресурсов тратится на переключение контекстов потока, чем выигрыш от использования этих виртуальных потоков. НО, как то раз мне надо было посчитать много хэшей файлов, и производительность упиралась в процессор, не в чтение с диска. Решил попробовать отключить HT из соображений приведенных выше, и получил ещё меньшую скорость расчета, как раз раза в полтора. Так что может оно и с толку сбивает, но скорости явно добавляет.
Кстати, MSSQL с его огромным плоским buffer cache это очень неудобная аппликация как для L3 cache, так и для NUMA - нет привязки тредов к месту памяти, они могут рандомно читать отовсюду.
Погодите, в документации пишут, что "The buffer manager is non-uniform memory access (NUMA) aware. Buffer cache pages are distributed across hardware NUMA nodes, which allows a thread to access a buffer page that is allocated on the local NUMA node rather than from foreign memory."
Нужен ли на Хабре такой плохо написанный текст
Григорий, я на Хабре зарегистрирован 13 лет, и вы первый человек, на которого я подписан (хотя и не из-за этой статьи).
Замечательный текст, но параллельной темой "проскакивает" - 1С и как жить и что с этим делать при стандартных подходах в некоторых видах систем виртуализаций. Уже не поднимается вопрос - "а фундаментально платформа 1С намерена модернизироваться с учетом использования виртуализации" или " покрутите там у себя в системах и должно стать лучше" ? Существует уже целый пласт тех кто ушел в 20ый век bare-metal для использования 1С и мало того под эти вещи допускают использование высокогерцовых несерверных ЦПУ - "заказчик доволен" подытоживает пласт ушедших, а то что гибкость и надежность страдают , это никого не волнует, до первого хорошего инцидента.
А я как раз из-за этой статьи сделал рег и подписался. Всё многогранно, неожиданно и предсказуемо.
Публикации
Тормозящая виртуализация на x86. Небольшая попытка разобраться. Часть 1: Общий обзор