Хакери заволоділи секретною інформацією AMD: компанія підтверджує витік

[Nikolay Yeryomenko]

Интересно сколько в Ryzen-е уязвимостей, связанных с SMT?

[DuckRider]

Интересно сколько в Ryzen-е уязвимостей, связанных с SMT?

Узнаем как только у них закончатся идеи и они захотят скормить всем мусор на 8 потоков

[Nikolay Yeryomenko]

и они захотят скормить всем мусор на 8 потоков

Так игры плохо используют HT и SMT. То по какому поводу тогда переживания? Да SMT работает, так же как и HT, но вот сколько они несут за собой уязвимостей?

[DuckRider]

и они захотят скормить всем мусор на 8 потоков

Так игры плохо используют HT и SMT. То по какому поводу тогда переживания? Да SMT работает, так же как и HT, но вот сколько они несут за собой уязвимостей?

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

[Scoffer]

DuckRider
SMT/HT це калічна за визначенням технологія тому що планувальник завдань не може передбачити продуктивність другорядного потоку оскільки вона напряму залежить від навантаження на перший потік і нутрощів проца динамічно в реальному часі. Він тупо не знає чого від цього потоку очікувати. Якщо для завдань аля рендер на це загалом пофігу, там пакетні обробки і все одно з якою швидкістю кожен окремий шмат даних буде оброблений, черга вирівняє все, то для більшості завдань з керуючою логікою накшталт ігродвигла - не пофігу.

[DuckRider]

DuckRider
SMT/HT це калічна за визначенням технологія тому що планувальник завдань не може передбачити продуктивність другорядного потоку оскільки вона напряму залежить від навантаження на перший потік і нутрощів проца динамічно в реальному часі. Він тупо не знає чого від цього потоку очікувати. Якщо для завдань аля рендер на це загалом пофігу, там пакетні обробки і все одно з якою швидкістю кожен окремий шмат даних буде оброблений, черга вирівняє все, то для більшості завдань з керуючою логікою накшталт ігродвигла - не пофігу.

Опять проблема в клятом хт, а не в рукожопом софте
Нефанатство оно такое

[Scoffer]

DuckRider
Проблема в клятому хт/смт, на котрий принципово не лягають на завдання такого класу вже на рівні алгоритмів, а не в рукожопих реалізаціях.
Нефанацтво це триматись за хламотехнології наче тобі за них доплачують

[KimRomik]

Так игры плохо используют HT и SMT. То по какому поводу тогда переживания? Да SMT работает, так же как и HT, но вот сколько они несут за собой уязвимостей?

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

і тут ж я згадав Pentium G5600, який по продуктивності як древній i5 2500
люди, ви недооцінюєте HT

[vmsolver]

SMT/HT це калічна за визначенням технологія тому що планувальник завдань не може передбачити продуктивність другорядного потоку оскільки вона напряму залежить від навантаження на перший потік і нутрощів проца динамічно в реальному часі. Він тупо не знає чого від цього потоку очікувати. Якщо для завдань аля рендер на це загалом пофігу, там пакетні обробки і все одно з якою швидкістю кожен окремий шмат даних буде оброблений, черга вирівняє все, то для більшості завдань з керуючою логікою накшталт ігродвигла - не пофігу.

И действительно, как можно предсказать, что запуск второго потока на ядре приведёт к тому, что ядро будет исполнять два потока со средней скоростью каждого 115 / 2 = 57,5 % от исходной. Невозможно. Непредсказуемо! (с) Scoffer

Ты тупо хейтишь НТ не понимая всей картины.

[Scoffer]

vmsolver
Ага, а от і експерт виліз зі своїми відсотками. В х86 немає 100500 абсолютно однакових обчислювальних конвеєрів щоб можна було поділити продуктивність строго навпіл. ALU виконують лише частину команд. А планувальник тим часом нічо не знає ні про які нутрощі процесора. Як результат не є рідкістю ситуація коли ОС, що вінда що нікси, показує завантаження всіх потоків відсотків на 60, і при цьому завдання люто туплять і працюють повільніше ніж вимкнути нафіг SMT як таку.

Так як ти собі вигадав працює павер з його ідентичними екзекьюшн слайсами, але ціною того що у нього немає коротких цілочисельних конвеєрів, всі рівні, і однопоточна продуктивність значно падає і ніяк не доходить до рівня х86. Зато багатопоточна може бути і х2, і х3.

[vmsolver]

В х86 немає 100500 абсолютно однакових обчислювальних конвеєрів щоб можна було поділити продуктивність строго навпіл. ALU виконують лише частину команд.

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

Як результат не є рідкістю ситуація коли ОС, що вінда що нікси, показує завантаження всіх потоків відсотків на 60

Ты тупо несёшь ерунду интерпретируя без понимания того, что означает процент загрузки. Проц может почти всё время ждать данные, а диспетчер задач тебе будет показывать 100% загрузку.

Так як ти собі вигадав працює павер з його ідентичними екзекьюшн слайсами

В процессоре есть планировщик, который в реальном времени знает какой порт занят, а какой простаивает, знает с каким темпом какая инструкция на каком порту исполняется, и исходя из этого ищет готовые для исполнения инструкции у себя в буфере. Так придумал не я, а интел, но я бы придумал бы также

[Scoffer]

Никто не собирается и никогда не собирался делить вычислительные ресурсы поровну

Окрім павера, а раніше альфи, та і на спарках в більшості точно така ж тема бо тільки так нарощується продуктивність потоків не на якісь жалюгідні 15-20%, а на 100-200-300+% і тільки так можна гарантувати потоку як мінімум один конвеєр, а отже процес на ньому ніколи не заткнеться в нуль

спойлер

что означает процент загрузки

Відсоток завантаження це головна і єдина величина, по котрій ОС має змогу розкидати завдання по ядрам/потокам. Якщо у ОС в силу калічності технології не виходить оцінити справжнє завантаження, починаються проблеми. Якби ти сервера хоча б одним оком бачив, то знав би про ці проблеми і подібної маячні не писав би.

В процессоре есть планировщик

Котрий не відслідковує історію потоків і йому начхати якщо у нього виходить так шо в один поток влітає більше команд ніж в інший просто тому що так склалась ситуація з кодом.
Інтел як вигадав, так і розвигадав назад, прямо заявивши що лавочка закрита, технологія застаріла і відправляється в утиль.

[DuckRider]

DuckRider
Проблема в клятому хт/смт, на котрий принципово не лягають на завдання такого класу вже на рівні алгоритмів, а не в рукожопих реалізаціях.
Нефанацтво це триматись за хламотехнології наче тобі за них доплачують

Тот же хвинфо отличает ядро от потока, в чём ваша проблема? Заполняешь сначала ядра, затем потоки задачей, а не пуксренькаешь фанатам про плохой гипертрейдинг и о том как его нужно выбросить со своей ядерной печи, у которой потребление уже выше чем фпс в играх

[vmsolver]

Окрім павера, а раніше альфи, та і на спарках

Закончил перепись трупов? Может вспомнишь, что мы говорим о х86 и перестанешь нести пургу, прыгая с темы на тему?

Відсоток завантаження це головна і єдина величина, по котрій ОС має змогу

ОС вообще не нужен этот параметр

Котрий не відслідковує історію потоків і йому начхати

Это планировщик инструкций, а не потоков (который вообще-то в ОС, а не в cpu), ему плевать на потоки, он занимается инструкциями, каждый делает свою задачу, а не лезет без понимания сути во всё подряд, как это делаешь ты.

Чел без матчасти хейтит НТ, занавес

[VovaII]

KYDRAM

ІМХО:
у синіх видно зовсім погано припущення

— Чому припущення? Декілька років тому манагери Інтела зоптимізували витрати на зарплати провідних інженерів, потім довго-довго переповзали на новий техпроцес, поки не придумали його перейменувати, а тепер, коли потрібно нові архітектури процесорів — знайшли хакерів!

Хоча, версія про передачу інформації родичам в Китаї, — більш правдоподібна.

Відправлено через 6 хвилин 13 секунд:
KYDRAM

квалком наступає!!!

— Сумніваюсь щоб Квалком якось використав х86? Хоча, я не експерт.

[zmax]

а чому хакери не пограбували Nvidia? мене цікавлять технічні дані та матеріал шкірянки

Хто сказав? Може й пограбували, може й відкупилися. А можливо це були не зелені, а сині. Якщо цього немає в новинах, це не означає, що такого не було.

[Scoffer]

Закончил перепись трупов?

Це ти тут починаєш втирати що SMT в х86 працює так само як в ти висловився трупах, а не я. Так от, в х86 SMT працює не так. Те що ти не роздуплився - виключно твої особисті проблеми.

ОС вообще не нужен этот параметр

Ага, зовсім. І нашо тільки в планувальник завдань того ж лінукса включений лоад балансер окремою підсистемою, котрий відслідковує завантаження ядер. Лошари мабуть якісь робили

Это планировщик инструкций, а не потоков

Саме так, це планувальник інструкцій, а не потоків, тому він в загальному випадку не здатен гарантувати потоку його 50% як ти втирав вище. Він взагалі нічого не здатен гарантувати. Тому на практиці і зустрічаються випадки коли одному потоку 100%, а іншому нуль, тому в паверах і зроблено все не так щоб такого не траплялось, і за оце "не так" було заплачено однопоточною продуктивністю.

Короче як завжли херомантію якусь розповідаєш, навіть приблизно не віддупляючи що відбувається в залізі насправді.

[Earanak]

Хоспаде, снова Scoffer душит технической душниной Это может занять 30+ сообщений пока все не устанут ))

[Scoffer]

Earanak
Ну так, це ж не технічний форум, а форум домогосподарок, вічно забуваю

[Earanak]

Scoffer
Кстати это похоже на правду. Лишь пару воинов за техническую грамотность осталось на форуме и то которые порой в дрёме