Слух: процессоры AMD EPYC (Milan) смогут обрабатывать четыре потока на ядро

[NiTr0]

Взагалі SMT на скільки дає приросту продуктивності, на стільки ж дає і приросту жору, іноді навіть більше.

в обычных числодробильнях - пожалуй.
а вот в виртуализации - чем больше потоков, тем реже переключение контекста. а выгрузка всех регистров, чистка TLB, кешей ядра (да-да, иначе привет спектр) и т.п. - очень затратная по времени операция...
никогда не запускали 2 конкурирующих за ресурсы виртуалки на одном ядре, к примеру, с компиляцией? попробуйте... просадка производительности в каждой будет не в 2 раза (как ожидалось бы), а раза в 4-5.

[Alexsandr]

а ведь оно потом и в десктопах появится.
Атлон 400GE 2 ядра 8 потоков

Появится. По площади кристалла экономия. Но каждый дополнительный поток на ядро снижает эффективность. Интересно как будут с этим бороться.

[Scoffer]

NiTr0
Я десь в районі третього коменту на першій сторінкі написав, що в завданнях, де потоків ПЗ більше ніж потоків проца, х86 - хлам. І SMT тут не сильно допоможе. Треба змінювати систему команд на більш прогнозовану за розміром команди, і з меншим трешем в регістрах, інакше конвеєри так і будуть безбожно просідати.

[Hotspur]

так это и есть HT. только 4 потока вместо 2. что переписывать-то?...

все

[Ouroboros]

сие в вакууме. а есть еще парковка и перекресток. в общем писать ОС если не с 0 то где то на 70%

Малопоточные игры запускаю через affinity с жёсткой привязкой к одному-двум физядрам... И никаких проблем...

[NiTr0]

NiTr0
Я десь в районі третього коменту на першій сторінкі написав, що в завданнях, де потоків ПЗ більше ніж потоків проца, х86 - хлам. І SMT тут не сильно допоможе. Треба змінювати систему команд на більш прогнозовану за розміром команди, і з меншим трешем в регістрах, інакше конвеєри так і будуть безбожно просідати.

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

Отправлено спустя 2 минуты 31 секунду:

так это и есть HT. только 4 потока вместо 2. что переписывать-то?...

все

очень веское и обоснованное мнение, да. вот прям непременно надо будет переписать весь юзер интерфейс, все драйвера (включая драйвера файловых систем), криптографию и сжатие дисков, управление памятью... да?
у вас вообще сколько опыта-то в системном программировании?

[Hotspur]

у вас вообще сколько опыта-то в системном программировании?

опиши своими словами проблему парковки и перекрестка

[Lucas55]

Шах и мат, Интел

[avuremybe]

Шах и мат, Интел

Вы о чем?

[Lucas55]

Шах и мат, Интел

Вы о чем?

от том, что там только 2 потока

[avuremybe]

от том, что там только 2 потока

Речь таки про сервера и интел там много чего может предложить. Включая уже упомянутые зион фай.

[Kotya]

Бедный интол это же им приедаться на 4 ядерные скайлейки теперь клеить надпись Celeron

Intel® Celeron® Diamond
иначе не зайдет, голда и платина уже не впечатляет.

Селерон ТЕФЛОН!
И у вас, не пригорает

[nikolaiii]

Kotya
Отличная идея, что-бы кулер к крышке пастой не приклеивался.

[Alexsandr]

NiTr0
Я десь в районі третього коменту на першій сторінкі написав, що в завданнях, де потоків ПЗ більше ніж потоків проца, х86 - хлам. І SMT тут не сильно допоможе. Треба змінювати систему команд на більш прогнозовану за розміром команди, і з меншим трешем в регістрах, інакше конвеєри так і будуть безбожно просідати.

Итаниумы показали что не все так гладко. ARM идут на встречу с х86 постепенно таки добавляя команд, но по скорости пока так и не сравнились даже в бюджетном секторе.

[Scoffer]

Alexsandr
Справа не в кількості команд, а в вирювнюванні.
На х86 команда може мати довжину від одного байта до п'ятнадцяти, через що сильно ускладнюється робота конвеєрів, кешей і взаємодія з оперативою в цілому. Ті ж перемикання контексту проца проходять половину вічності в порівнянні з іншими архітектурами.
В рісках типу ARM або паверів - 2/4/8 байт, в ітаніумах взагалі було строго 16 байт і ніяк інакше, що ще більше спрощує взаємодію з пам'ятю, з котрою зараз і є основна проблема.
Тупим переформатуванням х86 команд, от просто в лоб, без заміни, в більш пряме кодування можна нефігово так підняти продуктивність процесорів.
Ще більше підняти продуктивність можна вирішивши проблему з регістрами, бо там зараз треш угар і содомія:

спойлер

[Marc Crass]

ОС под такое переписывать надо, а майки не будут. вспоминаем Бульдозер

Бульдозер работал реально по другому от НТ.
И таки да, идея потонула.
А вот как на четыре параллелятся потоки сейчас - неизвестно.
Может проблемы явной и нет.

Будем посмотреть.

Да и не коснётся это нас.
Серверная тема же.

Слух про 4 потока в "Милане" видел еще этой весной. А про десктопную версию тогда же был слух о 3 потоках. Так что это уже не чисто серверная тема. Число потоков будет расти все возрастающими темпами, т. к. потолок частот давно уже достигнут.

[nikolaiii]

Marc Crass
Нет потолка частот, частоты будут расти, просто не так быстро как мы привыкли, лет через 5, 5.5Ггц - 5.7Ггц будет рядовым бустом для топовых процов.

[Hotspur]

5.5Ггц - 5.7Ггц будет рядовым бустом для топовых процов

не уверен. 5 ггц АМД выкатила очень давно, с тех пор прогресса нет

[nikolaiii]

Hotspur
Выкатила на слабой архитектуре, у Интела тоже была своя кукурузная архитектура NetBurst, и если на Интел смотреть, там одна по сути мощная архитектура Core дошла до 5Ггц, как только Интел решит свои проблемы с освоением более тонких техпроцессов 5Ггц будет преодолен без особых проблем.

[NiTr0]

у вас вообще сколько опыта-то в системном программировании?

опиши своими словами проблему парковки и перекрестка

да нет никакой проблемы с парковкой ядер. вообще нет. есть проблема с кривым менеджером процессов в винде - это да, но менеджер процессов - это не 70% системы, это маленький кусок кода, от силы на несколько сот кб.