Qualcomm звернулася до Intel із пропозицією про поглинання

Обсуждение статей и новостей сайта
Автор
Повідомлення
dext
Member
Звідки: Dnipro

Повідомлення

Scoffer: 22.09.2024 19:32 Окрім того що це сотні-тисячі тактів проблем немає :laugh:
- а безпосередньо (ре)компіляція JS-кода, яка йде до цього - напено десятки-одиниці тактів?
- а запис в кодовий сегмент на x86 хіба не призводить до примусового скидання кешу, автоматично, при кожному запису?
Питання риторичні B-)
Scoffer: 22.09.2024 19:32 А можна краще звернутись до затримок доступу до кеша і виявити що на айслейкі це 5 тактів, на зен4 це 4-5 тактів, і на м1 це 3-4 такти. Залежність строго частотна, чим більш частотний проц, тим більші затримки
- латентність позначена в тактах - це абсолютне значення з урахуванням конвеєризації, throughput для операцій запису на ARM також вищий - знову через простішу модель, на x86 такі швидкості принципово недосяжні
- латентність на ICL була збільшена саме через збільшення розміру і ПС заради "дуже потрібного" AVX512 - тобто в кого які приорітети :rotate:
Scoffer: 22.09.2024 19:32 це не є обмежуючим фактором
Це абсолютний лімит та обмеження архітектури: якщо вам, наприклад, потрібно виконати 2 послідовних store - на x86 будуть затримки саме через важкі протоколи синхронізації, навіть якщо ви пишете однопоточну програму, на ARM - ні
Scoffer: 22.09.2024 19:32 Тебе має хвилювати виключно пропускна спроможність. Це конвеєр, ти накидуєш команд в топку і вони паралельно виконуються
В конжної інструкції є абсолютні 1) latency 2) throughput, тож якщо ви накидаєте купу послідовних store - воно ніяк не буде виконуватись паралельно, то особисто вам як програмісту (компілятора/асемблера/програми) доведеться думати про рознесення цих store
Scoffer: 22.09.2024 19:32 Наведений код виглядає рівно як демонстратор різниці меморі модел
Наведений асемблерний код не є smp-безпечним на всіх weak-ordered архітеутурах, він також не є smp-безпечним навіть на x86, якщо потоки використовують ту ж саму movntq
Scoffer: 22.09.2024 19:32 будь-яку варіацію SMC на армах
- якщо супервізор (JIT-компілятор) знає, яку частину кода він оновив - з цим немає жодних проблем
- якщо сам код з дивної причини вирішив оновити сам себе (99.9% малварь?) - це скоріше вразливість x86, ніж перевага B-)
- гарним тоном для сегментів кода є саме -W +RX, для даних +RW+NX тож ми знову звужуємо цю проблему до саморобних VM

Відправлено через 15 хвилин 22 секунди:
NiTr0: 23.09.2024 14:42 то же и с х86 - 8086, i386 (32бит регистры и т.п.), x86-64. те самые legacy костыли из прошлого, да.
- x86_64 - похідна від i386, i386 - похідна від 80286, і т.д. (дуже умовно)
- thumb, arm32, aarch64 - це повністю несумісні між собою кодування
- кодування зазначених інструкцій на ARM значно простіше, ніж x86
тобто:
- на x86 декодер це мега-кобмайн, який тягне за собою абсолютно все
- на ARM це повністью відокремлені декодери
- для усіляких мікроконтролерів можна реалізувати лише thumb, або arm32 без thumb etc.
- на arm9 (сучасні високопродуктивні девайси), для прикладу, вирішили викинути все старе, тобто фактично замість трьох декодерів буде лише один (aarch64)
- на ARM через фіксований розмір інструкції - можна легко зробити N-wide decode (-накидати декодерів в паралель скількі завгодно), на x86 - це дуже велика проблема, тому без кешу мікрооперацій (L0 або uop-cache) - на x86 практично без альтернатив
Scoffer
Member
Аватар користувача

Повідомлення

dext: 24.09.2024 18:30- а безпосередньо (ре)компіляція JS-кода, яка йде до цього - напено десятки-одиниці тактів?
Поняття не маю, але операції з очисткою кешу це завжди дуже повільно і їх всіма силами намагаються уникати.
dext: 24.09.2024 18:30- а запис в кодовий сегмент на x86 хіба не призводить до примусового скидання кешу, автоматично, при кожному запису?
Ні, не треба тому що на х86 всі кеші когерентні. Щойноскомпілений код в л1д відправить теги в л1к, а потім засинхронить конкретні строки сам без участі програмера. На армі, до речі, можна скинути конкретні строки в декілька етапів вручну і це теж швидше ніж флашити все, але чомусь у мене стійке відчуття що не на плюсах.
dext: 24.09.2024 18:30латентність позначена в тактах
А я тобі ще раз кажу що латентність запису на ооо в силу особливостей ооо це якась бабалайка, а не реальна величина.
dext: 24.09.2024 18:30Це абсолютний лімит та обмеження архітектури: якщо вам, наприклад, потрібно виконати 2 послідовних store - на x86 будуть затримки саме через важкі протоколи синхронізації, навіть якщо ви пишете однопоточну програму, на ARM - ні
Маячня. На х86 ти можеш лупити по 4 скалярних стори за такт, на армі 2. І це не архітектурне обмеження, а мікроархітектурне. Якщо комусь колись знадобиться, то зроблять і 102, і 104.
dext: 24.09.2024 18:30 throughput, тож якщо ви накидаєте купу послідовних store - воно ніяк не буде виконуватись паралельно, то особисто вам як програмісту (компілятора/асемблера/програми) доведеться думати про рознесення цих store
Шо за бредятина, звідки ти це взагалі видрав. На то вона і пропускна спроможність щоб запускати все паралельно. А затримки тебе можуть зацікавити виключно в випадку коли треба прочитати щойно записане, але ти сам сказав що це ні разу не типовий код.
dext: 24.09.2024 18:30Наведений асемблерний код не є smp-безпечним
Ясен пень що не є, а як ще він має показати різницю між моделями пам'яті?
dext: 24.09.2024 18:30кщо супервізор (JIT-компілятор) знає, яку частину кода він оновив - з цим немає жодних проблем
- якщо сам код з дивної причини вирішив оновити сам себе (99.9% малварь?) - це скоріше вразливість x86, ніж перевага
- гарним тоном для сегментів кода є саме -W +RX, для даних +RW+NX тож ми знову звужуємо цю проблему до саморобних VM
Якщо пошукаєш як влаштовані JIT, то зненацька знайдеш що там намертво вирублені NX і варіації для цих сторінок пам'яті. Або як варіант на 32-бітних армах постійні виклики ядра ОС, все одно кеш через них чистити, і, відповідно, просто непристойно тормозна робота.
dext: 24.09.2024 18:45 на x86 - це дуже велика проблема,
Немає там ніяких проблем, переддекодери з'ясовують довжину команди, основні декодери тут же слідом розшифровують повністю. Технологія відпрацьована десятиліттями.
А на армі, до речі, є проблеми з нерегулярністю кодування тому що в 32 біти не виходить красиво запхнути все що треба, і дааалеко не всі команди декодер здатен розшифрувати за такт, так що вони один одного варті в цьому плані.
dext
Member
Звідки: Dnipro

Повідомлення

Scoffer: 24.09.2024 18:46 Поняття не маю
Аналіз AST + генерація коду це тисячі, десятки тисяч тактів
Scoffer: 24.09.2024 18:46 Ні, не треба тому що на х86 всі кеші когерентні
При записі в сегмент коду на x86 відповідні лінії L1 інвалідуються автоматично, на ARM - це потрібно робити вручну, тобто втрати продуктивності +/- однакові
Scoffer: 24.09.2024 18:46 А я тобі ще раз кажу що латентність запису на ооо в силу особливостей ооо це якась бабалайка, а не реальна величина.
Латентність /та throughput зафіксовані навіть в офіційних документах "Intel® 64 and IA-32 Architectures Software Developer Manuals" - розробники ЦП в курсі, що "це якась балалайка"? :laugh:
Scoffer: 24.09.2024 18:46Шо за бредятина, звідки ти це взагалі видрав. На то вона і пропускна спроможність щоб запускати все паралельно
1) зверніться до офіційних мануалів: там чітко написано, скільки store інструкцій і з яким темпом ви можете запускати
2) для скалярів важливіша латентність, а не ПЗ
Scoffer: 24.09.2024 18:46 Ясен пень що не є, а як ще він має показати різницю між моделями пам'яті?
Навіщо наводити код, якого [практично] не існує в реальних програмах? Це висмоктування "проблеми" з пальця, як то кажуть
Scoffer: 24.09.2024 18:46 Якщо пошукаєш як влаштовані JIT, то зненацька знайдеш що там намертво вирублені NX і варіації для цих сторінок пам'яті. Або як варіант на 32-бітних армах постійні виклики ядра ОС, все одно кеш через них чистити, і, відповідно, просто непристойно тормозна робота.
Тож напевно усілякі браузери на 32-бітних армах працювали непристойно тормознуто у порівнянні з x86 - тож напевно саме в той час x86 намагався вирулити на моб. платформи і... програв? :gigi:
Scoffer: 24.09.2024 18:46 Немає там ніяких проблем, переддекодери з'ясовують довжину команди, основні декодери тут же слідом розшифровують повністю. Технологія відпрацьована десятиліттями.
преддекодери це +1..2 стадії конвейера, як мінімум, тобто плюс витрати енергії плюс додаткові затримки при скиданні конвеєра (branch misprediction penalty) - чого на ARM немає
Scoffer: 24.09.2024 18:46 А на армі, до речі, є проблеми з нерегулярністю кодування тому що в 32 біти не виходить красиво запхнути все що треба, і дааалеко не всі команди декодер здатен розшифрувати за такт, так що вони один одного варті в цьому плані.
За можливості легко масштабувати (нарощувати кількість декодерів) - це не проблема: вже давно є 10-wide (Cortex-X4), а на x86 стан речей такий, що AMD досі 4-wide, Інтел тільки-тільки реалізувала 6-wide, тож без L0i (uop-cache) на x86 нікуди https://x.com/divBy_zero/status/1788930699715608699
Scoffer
Member
Аватар користувача

Повідомлення

dext: 26.09.2024 10:15Латентність /та throughput зафіксовані навіть в офіційних документах "Intel® 64 and IA-32 Architectures Software Developer Manuals" - розробники ЦП в курсі, що "це якась балалайка"?
От зараз спеціально відкрив цей мануал щоб подивитись чи нічо там не змінилось, і вуаля, ні, не змінилось, ніде не вказана швидкість виконання команд ні по затримкам, ні по пропускній спроможності. Розробники ЦП не в курсі що можна сказати? Чи може навмисно це не роблять бо це мікроархітектурнозалежна величина, що гуляє від покоління до покоління і прив'язуватись до неї ССЗБ? :rotate:
dext: 26.09.2024 10:15там чітко написано, скільки store інструкцій і з яким темпом ви можете запускати
Не написано.
dext: 26.09.2024 10:15для скалярів важливіша латентність, а не ПЗ
Ні, ти не розумієш про що говориш. А я не розумію як може не доходити що латентність має значення виключно на операціях лоад-афте-стор. Люди, :censoured: , цілі тести для цьої конкретної операції вигадали. І наміряли в м1 аж 6 тактів. На що взагалі-то пофіг, але сам факт.
dext: 26.09.2024 10:15 чого на ARM немає
Є. Довжина конвеєра прямо пропорційна частоті процесора. Як тільки арм спробує працювати на 6ГГц, у нього буде так само або ще гірше через нелінійність процесу декодування. Порівнювати 3х-гігагерцний проц з 6 - смішно. Ти б ще згадав 4-стадійні міпси на 300МГц.
dext: 26.09.2024 10:15За можливості легко масштабувати (нарощувати кількість декодерів) - це не проблема: вже давно є 10-wide (Cortex-X4), а на x86 стан речей такий, що AMD досі 4-wide, Інтел тільки-тільки реалізувала 6-wide, тож без L0i (uop-cache) на x86 нікуди https://x.com/divBy_zero/status/1788930699715608699
Не зробили тому що нафіг не треба. Одна команда х86 робить те що декілька ріскових команд. Відповідно і декодувати їх треба менше в штуках. А чисто технічно першим 10-вайд що по декодеру, що по алу був сістем-зед 12 чи 13, старий коротше, з ще більш упоротою системою команд ніж х86, і їх це не зупинило.
dext: 26.09.2024 10:15При записі в сегмент коду на x86 відповідні лінії L1 інвалідуються автоматично, на ARM - це потрібно робити вручну, тобто втрати продуктивності +/- однакові
Ні не однакові, інакше б не було купа статтей зі скаргами на проблему.
dext: 26.09.2024 10:15Навіщо наводити код, якого [практично] не існує в реальних програмах? Це висмоктування "проблеми" з пальця, як то кажуть
Проблема існує в реальних програмах. Існують більш складні випадки ніж код на три асемблерні команди. Фіксація TSO це новітня історія, це середина-кінець 90х. До того на х86 модель пам'яті гуляла в різні сторони і ніякі гарантії не надавались, але зрештою, врахувавши аналіз реального коду, в інтелі вирішили що буде от так, а не не так. В сан/оракл спарк вирішили рівно так же само, хоча це взагалі-то ріск процесор. А в сістем-зед від ібм модель пам'яті ще сильніше. Я думаю ці контори трішечки таки шарять. А тим часом саму слабку модель пам'яті з альфи більше ніхто повторювати не хоче, бо вона проблемна. Як в анекдоті, друкую зі швидкістю 500 символів на хвилину, але така фігня виходить :laugh:
dext
Member
Звідки: Dnipro

Повідомлення

Scoffer: 26.09.2024 10:59 От зараз спеціально відкрив цей мануал щоб подивитись чи нічо там не змінилось, і вуаля, ні, не змінилось, ніде не вказана швидкість виконання команд ні по затримкам, ні по пропускній спроможності. Розробники ЦП не в курсі що можна сказати? Чи може навмисно це не роблять бо це мікроархітектурнозалежна величина, що гуляє від покоління до покоління і прив'язуватись до неї ССЗБ?
:rotate:
Так, не зафіксовані, але є Load Latency Facility + Store Latency Facility + купа методік + результатів для різних архітектур
Scoffer: 26.09.2024 10:59 Ні, ти не розумієш про що говориш. А я не розумію як може не доходити що латентність має значення виключно на операціях лоад-афте-стор. Люди, :censoured: , цілі тести для цьої конкретної операції вигадали. І наміряли в м1 аж 6 тактів. На що взагалі-то пофіг, але сам факт.
ще раз пояснюю:
- наведений store-load (до чого тут він взагалі?) має залежність між даними
- мова з самого початку виключано про store + store + store + ... тобто latency/throughput (які вказуються для інструкцій без залежностей), де weak memory model має значення - і дає суттєвий бусть на ARM там, де на x86 постійні затримки і вимагає написання sse/avx/axv2/axv512-комбайнів для стандартного memcpy
- для скалярів, ще раз повторюю, latency важливіша ніж throughput тому що виконати 1 команду за 1 такт гарантовано краще, ніш 2 команди за 2 такти - тому що в першому випадку вже через такт результат запису буде архітектурно видимий -> можна вивільнити ROB та задіяти більше резурсів для OoO, а на x86 в цей час буде блокування + витрати енергії + втрати продуктивності
Scoffer: 26.09.2024 10:59 Є. Довжина конвеєра прямо пропорційна частоті процесора.
Напевно саме тому більш високочастотний X925 має коротший конвеєр, ніж X4? :laugh:
Scoffer: 26.09.2024 10:59 Як тільки арм спробує працювати на 6ГГц, у нього буде так само або ще гірше через нелінійність процесу декодування. Порівнювати 3х-гігагерцний проц з 6 - смішно. Ти б ще згадав 4-стадійні міпси на 300МГц.
У Agner Fog э заміри для різних архітектур і щось я там не бачу жодної x86 з латентністью запису в 1 такт - як так?
Scoffer: 26.09.2024 10:59 Не зробили тому що нафіг не треба.
Звичайно, що "не треба": от як інтел викатить Royal Core з 8-wide - так одразу "треба" і настане :laugh:
Scoffer: 26.09.2024 10:59 Одна команда х86 робить те що декілька ріскових команд.
Сучасна ISA aarch64 також: ldp, cbnz, etc.
Scoffer: 26.09.2024 10:59 Ні не однакові, інакше б не було купа статтей зі скаргами на проблему.
Бачу лише одну статтю з саморобною VM - де решта скарг на проблему?
Scoffer: 26.09.2024 10:59 Я думаю ці контори трішечки таки шарять
А я не думаю, а можу з впевненістью сказати, що x86 розроблявся як дешева альтернатива "дорослих" MIPSів - тож і CISC (для економії RAM) і спрощена модель пам'яті (щоб програмістам легше жилося) та ін. - зроблено було виключно для зниження порогу входження і аж ніяк не є перевагами з технічної точки зору, тим паче зараз
Scoffer
Member
Аватар користувача

Повідомлення

dext: 26.09.2024 13:17ще раз пояснюю:
- наведений store-load (до чого тут він взагалі?) має залежність між даними
- мова з самого початку виключано про store + store + store + ... тобто latency/throughput (які вказуються для інструкцій без залежностей), де weak memory model має значення - і дає суттєвий бусть на ARM там, де на x86 постійні затримки і вимагає написання sse/avx/axv2/axv512-комбайнів для стандартного memcpy
- для скалярів, ще раз повторюю, latency важливіша ніж throughput тому що виконати 1 команду за 1 такт гарантовано краще, ніш 2 команди за 2 такти - тому що в першому випадку вже через такт результат запису буде архітектурно видимий -> можна вивільнити ROB та задіяти більше резурсів для OoO, а на x86 в цей час буде блокування + витрати енергії + втрати продуктивності
А я тобі в сотий раз повторю що в випадку store + store + store + латенсі значення НЕ МАЄ тому що немає залежності. Не має і все тут. Має значення виключно throughput. Throughput пересічного інтеля на стор операціях це 4 скалярні команди за такт. Ферштейн, нє? Якщо не ферштейн, то відкривай свого Agner Fog і читай скільки він заміряв сторів за такт на інтелях поки не дійде.
dext: 26.09.2024 13:17У Agner Fog э заміри для різних архітектур і щось я там не бачу жодної x86 з латентністью запису в 1 такт - як так?
Ні в кого немає ніякого запису за один такт по латенсі. Це повна маячня тому що в дуже бородаті роки просто дійти до кешу було ДВА такти, настільки два що міпс це ввів аж в архітектуру, а не в мікроархітектуру, а зараз ні, зараз це 3-4-5 тактів. І до меморі модел це не має жодного стосунку від слова зовсім. Якщо у інтела і є на якийсь там такт довше, не 4 а 5 наприклад реальних, то тільки тому що адресація інтела це base+index*scale+offset, тобто додаткові обчислення, а у арма лише base+index*4 або base+offset, і можливості обходу по даним однією командою сильно обмежені, доведеться робити більше інструкцій, 2 чи 3. Залежних інструкцій, між іншим.
dext: 26.09.2024 13:17спрощена модель пам'яті
Стронг модел не спрощена, а ускладнена. Це додатковий буфер, котрого немає в міпсах. Інтел починав з відсутності когерентності, тобто слабкої моделі, слабше нікуди. До TSO дійшли сильно пізніше, зафіксували десь аж на 2му пні. Дійшли не просто так. І втопили всіх твоїх міпсів на робочих станціях теж не просто так.

Відправлено через 7 хвилин 18 секунд:
dext: 26.09.2024 13:17Бачу лише одну статтю з саморобною VM - де решта скарг на проблему?
Гугл в допомогу.
dext
Member
Звідки: Dnipro

Повідомлення

Scoffer: 26.09.2024 15:08 що в випадку store + store + store + латенсі значення НЕ МАЄ тому що немає залежності. Не має і все тут
Саме тому реалізація memcpy() на x86 така "проста" і така "коротка", чи не так? :laugh:
Scoffer: 26.09.2024 15:08 відкривай свого Agner Fog і читай скільки він заміряв сторів за такт на інтелях поки не дійде.
по-перше, не "свого", а загальновідомого та авторитетного на відміну від... кого? по-друге: знову повертаємось до memcpy B-)
dext: 26.09.2024 13:17 Ні в кого немає ніякого запису за один такт по латенсі
Arm_Cortex_X4_Core_Software_Optimization_Guide.pdf
STR - Exec Latency: 1
як так? :laugh:
Scoffer: 26.09.2024 15:08 Якщо у інтела і є на якийсь там такт довше, не 4 а 5 наприклад реальних, то тільки тому що адресація інтела це base+index*scale+offset, тобто додаткові обчислення, а у арма лише base+index*4 або base+offset
Мова виключно про store (де weak model має значення), a не load
Scoffer: 26.09.2024 15:08Стронг модел не спрощена, а ускладнена
Я мав на увазі - спрощена для програмістів (ціною ускладнення/уповільнення заліза) бо береш собі і ліпиш якісь volatile на колінках, але працювати воно буде лише на x86
Scoffer: 26.09.2024 15:08 Гугл в допомогу.
Надавати докази "проблем" - логічне зобов'язання того, хто про такі "проблеми" стверджує, тож якщо ви стверджуєте про "купа статтей зі скаргами на проблему" - надайте, будь ласка, докази, їх же купа, це повинно бути легко :rotate:
Scoffer
Member
Аватар користувача

Повідомлення

Exec latency != store latency взагалі ні разу і близько. Тому от так от.
dext: 26.09.2024 15:57Саме тому реалізація memcpy() на x86 така "проста" і така "коротка", чи не так?
https://chromium.googlesource.com/nativ ... 4/memcpy.S
Супер проста і коротка. Копіюють по 128 байт одним махом через стек бо а чом би і ні, проц сам розбереться. З запасом на виріст шоб не переписувати на кожен чих. Та шо там з memcpy? Неправильна якась? :lol:

Відправлено через 3 хвилини 44 секунди:
https://gist.github.com/Const-me/329026 ... d39b28007c
ще якась інша реалізація, через регістри теж фігарить по 16*64, ті ж 128 байт за раз. І нічо не знає ні про які твої затримки.

Відправлено через 1 хвилину 11 секунд:
Коротше мені набридло, все. Якщо ти хочеш розібратись в залізі, то розбирайся, а не неси бредні. А якщо не хочеш, то не розбирайся і не лізь до нього. Пересічному програмеру знати все це не обов'язково. А на непересічного ти явно недотягуєш.
dext
Member
Звідки: Dnipro

Повідомлення

Scoffer: 26.09.2024 16:22 Exec latency != store latency взагалі ні разу і близько. Тому от так от.
Exec latency там для кожної інструкції, тож і load latency, і store latency, і будь-яка latency:
A series of tables summarize the effective execution latency and throughput (instruction bandwidth per
cycle)
Тому от так от B-)
Scoffer: 26.09.2024 16:22 Супер проста і коротка
- чому ж вони не використали системну https://github.com/bminor/glibc/blob/ma ... ned-erms.S?
- яка продуктивність такох реалізації у порівнянні з системною на векторах? підозрюю, що відчутно нижча :rotate:
От на ARM реалізація всюди проста і коротка, використовує виключно скаляри з базової ISA, без жодних розширень:
https://github.com/bminor/glibc/blob/ma ... 4/memcpy.S
І така реалізація на M1 дозволяе вичавити 60GB/s з одного потока, на M1 Max 100GB/s, теж з одного потока - тобто майже всю доступну ПЗ, без усіляких векторних комбайнів і non-temporal stores B-)
Пересічному програмеру знати все це не обов'язково
пересічному x86-програмеру, без перспектив - без сумніву, а от якщо є перспективи (на крос-платформеність) - обов'язково, як мінімум для того щоб позбутить хибних стереотипів і не вигадувати проблеми
Відповісти