В AMD вважають, що в архітектури ARM немає переваг над x86

[talex]

Предлагаю обсудить В AMD вважають, що в архітектури ARM немає переваг над x86

ждем Юру со срывом покровов)

[avuremybe]

яблуни вже певно асфексію спіймали

[Геральт]

Усе це не означає кінець процесорів ARM у сегменті ноутбуків та десктопів.

Та воно ще навіть не почалося толком

[vsx]

Если произойдет переход на арм то изменится не только архитектура но и компановка. Продавать будут соки вместо цпу и конечный пользователь только проиграет. Так что нахрен такое надо.

[Scoffer]

В AMD вважають, що в архітектури ARM немає переваг над x86

Бо це правда. При розробці AArch64 ARM приділили увагу тому щоб архітектуру можна було реалізувати на будь-якому чайнику, а не тому щоб досягти переваг продуктивності над х86. Для переваг продуктивності треба зовсім іншу архітектуру.

[tornadox]

ждем Юру со срывом покровов)

Юра спить поки, вчора до 5 ранку вів бій у вітці про кулери Noctua з фанатами х86. Має набратися сил.

[denizen]

В AMD вважають, що в архітектури ARM немає переваг над x86

Бо це правда. При розробці AArch64 ARM приділили увагу тому щоб архітектуру можна було реалізувати на будь-якому чайнику, а не тому щоб досягти переваг продуктивності над х86. Для переваг продуктивності треба зовсім іншу архітектуру.

яку?

[Denvys5]

denizen
SPARC

[nazar-pc]

Насправді сучасні процесори не працюють з x86-64 чи aarch64 напряму, вони перетворюють ці інструкції на внутрішнє представлення.
Тому aarch64 чи x86-64 має не так багато різниці як внутрішня кухня, яку ми не бачимо.
Теоретично може бути процесор який підтримує кілька різних ISA, бо всередині він працює з зовсім іншим представленням де одні машинні інструкції об'єднуються, інші навпаки діляться, змінюється їх порядок і так далі.
Jim Keller про це неодноразово говорив в різних інтерв'ю.

[StTechnik]

АМД, ты потише. Сейчас придет Юра с реальными приложениями и расскажет за энергопотребление и божественные скорости в М4 на котором ему дают поработать через ssh.

[Scoffer]

SPARC

Ні, у спарка свої приколи. Треба зовсім нове. На вскидку:
1. 64-бітну команду щоб можна було більш-менш внятно орудувати 64-бітною адресацією же тому що на армах це зараз відбувається через global pointer і на банальний запуск функції вимагається мало не десяток команд замість 1-2;
2. Більше регістрів. Ще в далеких 90х компілятори могли серйозно оптимізувати код особливо в плані кількості лоад-сторів якщо мали щонайменше 64, а краще 128 регістрів загального призначення. Тому ітаніуми, павери в варіації з ящика і плойки, і спарки в варіації суперкомпів фуджитсу стільки і мали. Зараз треба закладати всі 256 бо навряд чи компілятор з 90х - пік розвитку технологій;
3. Регістри мають бути спільними для цілочисельних і операцій з плаваючою комою. В основному тому що одна негарна редиска, коли створювала жабоскрипт, котрий зараз трішки більше ніж всюди, зробила суперслабку типізацію, і цей жабоскрипт 100500 раз на кожен чих ганяє туди-сюди з інта в флоат і назад, а між банками регістрів це не швидко;
4. Повна предикація (ітаніум, avx512) зменшує навантаження на предиктор розгалуджень вдічі в порівнянні з архітектурами де її взагалі немає ні в якому вигляді (ріск-5) і на 25-30% де є лише cmov (арм, скалярний х86);
5. Щось треба зробити з ідентифікаціює процесів бо 12 біт це нікуди не годиться і ОС доводиться чистити кеші при перемиканні процесів там де цього можна було б уникнути
6. Також не завадить уникати злиття макрооперацій тому що це ускладнює uop cache, а значить архітектура має покривати всі ці дуже необхідні злиті команди одною не злитою
ймовірно це далеко не повний список

Відправлено через 7 хвилин 39 секунд:
7. LL/SC тільки в теоретичній теорії повноціна заміна CAS. В практичній практиці LL/SC настільки відрізняється в реалізації навіть в межах одної архітектури, що всі забили і просто за допомогою LL/SC програмно реалізують CAS, а це також не те щоб дуже швидко.
Коротше проблем вистачає. Як їх вирішити теж зрозуміло. Залишилось лише щоб хтось прийняв вольове рішення і зробив архітектуру конкретно для хай-перф обчислень, а не однією сракою на три-чотири стільці.

[erkins007]

АМД, ты потише. Сейчас придет Юра с реальными приложениями и расскажет за энергопотребление и божественные скорости в М4 на котором ему дают поработать через ssh.

И 6фпс в киберпанке в фуллшд)

[Олег Мандріаник]

Мммммм. А если придумать сразу 512 битную архитектуру? Сколько можно сидеть на этих несчастных 64 битах?

[Alexsandr]

Мммммм. А если придумать сразу 512 битную архитектуру? Сколько можно сидеть на этих несчастных 64 битах?

Можно. о сразу будет расти объем кода, расход памяти, транзисторный бюджет... Идут по пути выбора середины + дополнительные команды.

[Олег Мандріаник]

Мммммм. А если придумать сразу 512 битную архитектуру? Сколько можно сидеть на этих несчастных 64 битах?

Можно. о сразу будет расти объем кода, расход памяти, транзисторный бюджет... Идут по пути выбора середины + дополнительные команды.

Ну так уже в обычном Лоусегменте можно 256Гб оперативы поставить. В Хедт терабайты, в Старших там хоть сотню, хоть тысячу ТБ. Вопрос только цены. Железо впринципе уже переросло 64 бит. А вот хотя бы 128 бит сделать это проблема. И проблема серьёзнее чем превысить порог транзистора в 1 Нм

[waryag]

Мммммм. А если придумать сразу 512 битную архитектуру? Сколько можно сидеть на этих несчастных 64 битах?

Цена конечного устрйоства вам не понравится. А отсутствие таких образцов намекает, что не нравится она и топам больших компаний.

[Gold_Star]

Олег Мандріаник
Та чого - одразу квантовий процесор для обчислення в кубітах

[1234waltz]

SPARC

Ні, у спарка свої приколи. Треба зовсім нове. На вскидку:
1. 64-бітну команду щоб можна було більш-менш внятно орудувати 64-бітною адресацією же тому що на армах це зараз відбувається через global pointer і на банальний запуск функції вимагається мало не десяток команд замість 1-2;
2. Більше регістрів. Ще в далеких 90х компілятори могли серйозно оптимізувати код особливо в плані кількості лоад-сторів якщо мали щонайменше 64, а краще 128 регістрів загального призначення. Тому ітаніуми, павери в варіації з ящика і плойки, і спарки в варіації суперкомпів фуджитсу стільки і мали. Зараз треба закладати всі 256 бо навряд чи компілятор з 90х - пік розвитку технологій;
3. Регістри мають бути спільними для цілочисельних і операцій з плаваючою комою. В основному тому що одна негарна редиска, коли створювала жабоскрипт, котрий зараз трішки більше ніж всюди, зробила суперслабку типізацію, і цей жабоскрипт 100500 раз на кожен чих ганяє туди-сюди з інта в флоат і назад, а між банками регістрів це не швидко;
4. Повна предикація (ітаніум, avx512) зменшує навантаження на предиктор розгалуджень вдічі в порівнянні з архітектурами де її взагалі немає ні в якому вигляді (ріск-5) і на 25-30% де є лише cmov (арм, скалярний х86);
5. Щось треба зробити з ідентифікаціює процесів бо 12 біт це нікуди не годиться і ОС доводиться чистити кеші при перемиканні процесів там де цього можна було б уникнути
6. Також не завадить уникати злиття макрооперацій тому що це ускладнює uop cache, а значить архітектура має покривати всі ці дуже необхідні злиті команди одною не злитою
ймовірно це далеко не повний список
Відправлено через 7 хвилин 39 секунд:
7. LL/SC тільки в теоретичній теорії повноціна заміна CAS. В практичній практиці LL/SC настільки відрізняється в реалізації навіть в межах одної архітектури, що всі забили і просто за допомогою LL/SC програмно реалізують CAS, а це також не те щоб дуже швидко.
Коротше проблем вистачає. Як їх вирішити теж зрозуміло. Залишилось лише щоб хтось прийняв вольове рішення і зробив архітектуру конкретно для хай-перф обчислень, а не однією сракою на три-чотири стільці.

Але половина описаного була в Ітаніках, спарках та є Power. Але ітанік вмер, SPARK64 доживає своє і не Фуджицу не випускала нового заліза з 2017-ого, почавши ліпити суперкомп'ют на кастомному АРМ, а Power в своїй пісочниці суворого корпоративного заліза.

Відправлено через 59 секунд:

Мммммм. А если придумать сразу 512 битную архитектуру? Сколько можно сидеть на этих несчастных 64 битах?

Вам AVX512 не вистачає?

[Scoffer]

Мммммм. А если придумать сразу 512 битную архитектуру? Сколько можно сидеть на этих несчастных 64 битах?

Немає практичної необхідності. А от необхідність в 128 бітах хоча б на FP назріла дуже давно. Ті ж FMA і інші рекомендовані комплексні операції з IEEE-754 - костиль щоб хоч якось відтермінувати накопичення помилок. 128 біт з запасом вистачить на будь-які хоч на скількись внятні обчислення без необхідності плодити зайвих команд.

Відправлено через 1 хвилину 45 секунд:

Але половина описаного була

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

[Олег Мандріаник]

Мммммм. А если придумать сразу 512 битную архитектуру? Сколько можно сидеть на этих несчастных 64 битах?

Цена конечного устрйоства вам не понравится. А отсутствие таких образцов намекает, что не нравится она и топам больших компаний.

Цена конечно будет космос. Но когда я покупал фотик Кенон 70д, первый в мире зеркальный с Дуал Пиксель и объектив 17-55 2,8 - то цена меня интересовала в последний момент. Точнее вообще не интересовала.

Відправлено через 8 хвилин 55 секунд:

Мммммм. А если придумать сразу 512 битную архитектуру? Сколько можно сидеть на этих несчастных 64 битах?

Немає практичної необхідності. А от необхідність в 128 бітах хоча б на FP назріла дуже давно. Ті ж FMA і інші рекомендовані комплексні операції з IEEE-754 - костиль щоб хоч якось відтермінувати накопичення помилок. 128 біт з запасом вистачить на будь-які хоч на скількись внятні обчислення без необхідності плодити зайвих команд.

Відправлено через 1 хвилину 45 секунд:

Але половина описаного була

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

Да чего-то вспомнился рывок с 32 на 64, когда несчастный Семпрон с 64 битами на 1,8Ггц разрывал вхлам Пень с 32 битами на 3,2 Ггц