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

[dext]

Окрім того що це сотні-тисячі тактів проблем немає

- а безпосередньо (ре)компіляція JS-кода, яка йде до цього - напено десятки-одиниці тактів?
- а запис в кодовий сегмент на x86 хіба не призводить до примусового скидання кешу, автоматично, при кожному запису?
Питання риторичні

А можна краще звернутись до затримок доступу до кеша і виявити що на айслейкі це 5 тактів, на зен4 це 4-5 тактів, і на м1 це 3-4 такти. Залежність строго частотна, чим більш частотний проц, тим більші затримки

- латентність позначена в тактах - це абсолютне значення з урахуванням конвеєризації, throughput для операцій запису на ARM також вищий - знову через простішу модель, на x86 такі швидкості принципово недосяжні
- латентність на ICL була збільшена саме через збільшення розміру і ПС заради "дуже потрібного" AVX512 - тобто в кого які приорітети

це не є обмежуючим фактором

Це абсолютний лімит та обмеження архітектури: якщо вам, наприклад, потрібно виконати 2 послідовних store - на x86 будуть затримки саме через важкі протоколи синхронізації, навіть якщо ви пишете однопоточну програму, на ARM - ні

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

В конжної інструкції є абсолютні 1) latency 2) throughput, тож якщо ви накидаєте купу послідовних store - воно ніяк не буде виконуватись паралельно, то особисто вам як програмісту (компілятора/асемблера/програми) доведеться думати про рознесення цих store

Наведений код виглядає рівно як демонстратор різниці меморі модел

Наведений асемблерний код не є smp-безпечним на всіх weak-ordered архітеутурах, він також не є smp-безпечним навіть на x86, якщо потоки використовують ту ж саму movntq

будь-яку варіацію SMC на армах

- якщо супервізор (JIT-компілятор) знає, яку частину кода він оновив - з цим немає жодних проблем
- якщо сам код з дивної причини вирішив оновити сам себе (99.9% малварь?) - це скоріше вразливість x86, ніж перевага
- гарним тоном для сегментів кода є саме -W +RX, для даних +RW+NX тож ми знову звужуємо цю проблему до саморобних VM

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

то же и с х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]

- а безпосередньо (ре)компіляція JS-кода, яка йде до цього - напено десятки-одиниці тактів?

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

- а запис в кодовий сегмент на x86 хіба не призводить до примусового скидання кешу, автоматично, при кожному запису?

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

латентність позначена в тактах

А я тобі ще раз кажу що латентність запису на ооо в силу особливостей ооо це якась бабалайка, а не реальна величина.

Це абсолютний лімит та обмеження архітектури: якщо вам, наприклад, потрібно виконати 2 послідовних store - на x86 будуть затримки саме через важкі протоколи синхронізації, навіть якщо ви пишете однопоточну програму, на ARM - ні

Маячня. На х86 ти можеш лупити по 4 скалярних стори за такт, на армі 2. І це не архітектурне обмеження, а мікроархітектурне. Якщо комусь колись знадобиться, то зроблять і 102, і 104.

throughput, тож якщо ви накидаєте купу послідовних store - воно ніяк не буде виконуватись паралельно, то особисто вам як програмісту (компілятора/асемблера/програми) доведеться думати про рознесення цих store

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

Наведений асемблерний код не є smp-безпечним

Ясен пень що не є, а як ще він має показати різницю між моделями пам'яті?

кщо супервізор (JIT-компілятор) знає, яку частину кода він оновив - з цим немає жодних проблем
- якщо сам код з дивної причини вирішив оновити сам себе (99.9% малварь?) - це скоріше вразливість x86, ніж перевага
- гарним тоном для сегментів кода є саме -W +RX, для даних +RW+NX тож ми знову звужуємо цю проблему до саморобних VM

Якщо пошукаєш як влаштовані JIT, то зненацька знайдеш що там намертво вирублені NX і варіації для цих сторінок пам'яті. Або як варіант на 32-бітних армах постійні виклики ядра ОС, все одно кеш через них чистити, і, відповідно, просто непристойно тормозна робота.

на x86 - це дуже велика проблема,

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

[dext]

Поняття не маю

Аналіз AST + генерація коду це тисячі, десятки тисяч тактів

Ні, не треба тому що на х86 всі кеші когерентні

При записі в сегмент коду на x86 відповідні лінії L1 інвалідуються автоматично, на ARM - це потрібно робити вручну, тобто втрати продуктивності +/- однакові

А я тобі ще раз кажу що латентність запису на ооо в силу особливостей ооо це якась бабалайка, а не реальна величина.

Латентність /та throughput зафіксовані навіть в офіційних документах "Intel® 64 and IA-32 Architectures Software Developer Manuals" - розробники ЦП в курсі, що "це якась балалайка"?

Шо за бредятина, звідки ти це взагалі видрав. На то вона і пропускна спроможність щоб запускати все паралельно

1) зверніться до офіційних мануалів: там чітко написано, скільки store інструкцій і з яким темпом ви можете запускати
2) для скалярів важливіша латентність, а не ПЗ

Ясен пень що не є, а як ще він має показати різницю між моделями пам'яті?

Навіщо наводити код, якого [практично] не існує в реальних програмах? Це висмоктування "проблеми" з пальця, як то кажуть

Якщо пошукаєш як влаштовані JIT, то зненацька знайдеш що там намертво вирублені NX і варіації для цих сторінок пам'яті. Або як варіант на 32-бітних армах постійні виклики ядра ОС, все одно кеш через них чистити, і, відповідно, просто непристойно тормозна робота.

Тож напевно усілякі браузери на 32-бітних армах працювали непристойно тормознуто у порівнянні з x86 - тож напевно саме в той час x86 намагався вирулити на моб. платформи і... програв?

Немає там ніяких проблем, переддекодери з'ясовують довжину команди, основні декодери тут же слідом розшифровують повністю. Технологія відпрацьована десятиліттями.

преддекодери це +1..2 стадії конвейера, як мінімум, тобто плюс витрати енергії плюс додаткові затримки при скиданні конвеєра (branch misprediction penalty) - чого на ARM немає

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

За можливості легко масштабувати (нарощувати кількість декодерів) - це не проблема: вже давно є 10-wide (Cortex-X4), а на x86 стан речей такий, що AMD досі 4-wide, Інтел тільки-тільки реалізувала 6-wide, тож без L0i (uop-cache) на x86 нікуди https://x.com/divBy_zero/status/1788930699715608699

[Scoffer]

Латентність /та throughput зафіксовані навіть в офіційних документах "Intel® 64 and IA-32 Architectures Software Developer Manuals" - розробники ЦП в курсі, що "це якась балалайка"?

От зараз спеціально відкрив цей мануал щоб подивитись чи нічо там не змінилось, і вуаля, ні, не змінилось, ніде не вказана швидкість виконання команд ні по затримкам, ні по пропускній спроможності. Розробники ЦП не в курсі що можна сказати? Чи може навмисно це не роблять бо це мікроархітектурнозалежна величина, що гуляє від покоління до покоління і прив'язуватись до неї ССЗБ?

там чітко написано, скільки store інструкцій і з яким темпом ви можете запускати

Не написано.

для скалярів важливіша латентність, а не ПЗ

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

чого на ARM немає

Є. Довжина конвеєра прямо пропорційна частоті процесора. Як тільки арм спробує працювати на 6ГГц, у нього буде так само або ще гірше через нелінійність процесу декодування. Порівнювати 3х-гігагерцний проц з 6 - смішно. Ти б ще згадав 4-стадійні міпси на 300МГц.

За можливості легко масштабувати (нарощувати кількість декодерів) - це не проблема: вже давно є 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, і їх це не зупинило.

При записі в сегмент коду на x86 відповідні лінії L1 інвалідуються автоматично, на ARM - це потрібно робити вручну, тобто втрати продуктивності +/- однакові

Ні не однакові, інакше б не було купа статтей зі скаргами на проблему.

Навіщо наводити код, якого [практично] не існує в реальних програмах? Це висмоктування "проблеми" з пальця, як то кажуть

Проблема існує в реальних програмах. Існують більш складні випадки ніж код на три асемблерні команди. Фіксація TSO це новітня історія, це середина-кінець 90х. До того на х86 модель пам'яті гуляла в різні сторони і ніякі гарантії не надавались, але зрештою, врахувавши аналіз реального коду, в інтелі вирішили що буде от так, а не не так. В сан/оракл спарк вирішили рівно так же само, хоча це взагалі-то ріск процесор. А в сістем-зед від ібм модель пам'яті ще сильніше. Я думаю ці контори трішечки таки шарять. А тим часом саму слабку модель пам'яті з альфи більше ніхто повторювати не хоче, бо вона проблемна. Як в анекдоті, друкую зі швидкістю 500 символів на хвилину, але така фігня виходить

[dext]

От зараз спеціально відкрив цей мануал щоб подивитись чи нічо там не змінилось, і вуаля, ні, не змінилось, ніде не вказана швидкість виконання команд ні по затримкам, ні по пропускній спроможності. Розробники ЦП не в курсі що можна сказати? Чи може навмисно це не роблять бо це мікроархітектурнозалежна величина, що гуляє від покоління до покоління і прив'язуватись до неї ССЗБ?

Так, не зафіксовані, але є Load Latency Facility + Store Latency Facility + купа методік + результатів для різних архітектур

Ні, ти не розумієш про що говориш. А я не розумію як може не доходити що латентність має значення виключно на операціях лоад-афте-стор. Люди, , цілі тести для цьої конкретної операції вигадали. І наміряли в м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 в цей час буде блокування + витрати енергії + втрати продуктивності

Є. Довжина конвеєра прямо пропорційна частоті процесора.

Напевно саме тому більш високочастотний X925 має коротший конвеєр, ніж X4?

Як тільки арм спробує працювати на 6ГГц, у нього буде так само або ще гірше через нелінійність процесу декодування. Порівнювати 3х-гігагерцний проц з 6 - смішно. Ти б ще згадав 4-стадійні міпси на 300МГц.

У Agner Fog э заміри для різних архітектур і щось я там не бачу жодної x86 з латентністью запису в 1 такт - як так?

Не зробили тому що нафіг не треба.

Звичайно, що "не треба": от як інтел викатить Royal Core з 8-wide - так одразу "треба" і настане

Одна команда х86 робить те що декілька ріскових команд.

Сучасна ISA aarch64 також: ldp, cbnz, etc.

Ні не однакові, інакше б не було купа статтей зі скаргами на проблему.

Бачу лише одну статтю з саморобною VM - де решта скарг на проблему?

Я думаю ці контори трішечки таки шарять

А я не думаю, а можу з впевненістью сказати, що x86 розроблявся як дешева альтернатива "дорослих" MIPSів - тож і CISC (для економії RAM) і спрощена модель пам'яті (щоб програмістам легше жилося) та ін. - зроблено було виключно для зниження порогу входження і аж ніяк не є перевагами з технічної точки зору, тим паче зараз

[Scoffer]

ще раз пояснюю:
- наведений 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 і читай скільки він заміряв сторів за такт на інтелях поки не дійде.

У Agner Fog э заміри для різних архітектур і щось я там не бачу жодної x86 з латентністью запису в 1 такт - як так?

Ні в кого немає ніякого запису за один такт по латенсі. Це повна маячня тому що в дуже бородаті роки просто дійти до кешу було ДВА такти, настільки два що міпс це ввів аж в архітектуру, а не в мікроархітектуру, а зараз ні, зараз це 3-4-5 тактів. І до меморі модел це не має жодного стосунку від слова зовсім. Якщо у інтела і є на якийсь там такт довше, не 4 а 5 наприклад реальних, то тільки тому що адресація інтела це base+index*scale+offset, тобто додаткові обчислення, а у арма лише base+index*4 або base+offset, і можливості обходу по даним однією командою сильно обмежені, доведеться робити більше інструкцій, 2 чи 3. Залежних інструкцій, між іншим.

спрощена модель пам'яті

Стронг модел не спрощена, а ускладнена. Це додатковий буфер, котрого немає в міпсах. Інтел починав з відсутності когерентності, тобто слабкої моделі, слабше нікуди. До TSO дійшли сильно пізніше, зафіксували десь аж на 2му пні. Дійшли не просто так. І втопили всіх твоїх міпсів на робочих станціях теж не просто так.

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

Бачу лише одну статтю з саморобною VM - де решта скарг на проблему?

Гугл в допомогу.

[dext]

що в випадку store + store + store + латенсі значення НЕ МАЄ тому що немає залежності. Не має і все тут

Саме тому реалізація memcpy() на x86 така "проста" і така "коротка", чи не так?

відкривай свого Agner Fog і читай скільки він заміряв сторів за такт на інтелях поки не дійде.

по-перше, не "свого", а загальновідомого та авторитетного на відміну від... кого? по-друге: знову повертаємось до memcpy

Ні в кого немає ніякого запису за один такт по латенсі

Arm_Cortex_X4_Core_Software_Optimization_Guide.pdf

STR - Exec Latency: 1

як так?

Якщо у інтела і є на якийсь там такт довше, не 4 а 5 наприклад реальних, то тільки тому що адресація інтела це base+index*scale+offset, тобто додаткові обчислення, а у арма лише base+index*4 або base+offset

Мова виключно про store (де weak model має значення), a не load

Стронг модел не спрощена, а ускладнена

Я мав на увазі - спрощена для програмістів (ціною ускладнення/уповільнення заліза) бо береш собі і ліпиш якісь volatile на колінках, але працювати воно буде лише на x86

Гугл в допомогу.

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

[Scoffer]

як так?

Exec latency != store latency взагалі ні разу і близько. Тому от так от.

Саме тому реалізація memcpy() на x86 така "проста" і така "коротка", чи не так?

https://chromium.googlesource.com/nativ ... 4/memcpy.S
Супер проста і коротка. Копіюють по 128 байт одним махом через стек бо а чом би і ні, проц сам розбереться. З запасом на виріст шоб не переписувати на кожен чих. Та шо там з memcpy? Неправильна якась?

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

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

[dext]

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)

Тому от так от

Супер проста і коротка

- чому ж вони не використали системну https://github.com/bminor/glibc/blob/ma ... ned-erms.S?
- яка продуктивність такох реалізації у порівнянні з системною на векторах? підозрюю, що відчутно нижча
От на ARM реалізація всюди проста і коротка, використовує виключно скаляри з базової ISA, без жодних розширень:
https://github.com/bminor/glibc/blob/ma ... 4/memcpy.S
І така реалізація на M1 дозволяе вичавити 60GB/s з одного потока, на M1 Max 100GB/s, теж з одного потока - тобто майже всю доступну ПЗ, без усіляких векторних комбайнів і non-temporal stores

Пересічному програмеру знати все це не обов'язково

пересічному x86-програмеру, без перспектив - без сумніву, а от якщо є перспективи (на крос-платформеність) - обов'язково, як мінімум для того щоб позбутить хибних стереотипів і не вигадувати проблеми