- а безпосередньо (ре)компіляція JS-кода, яка йде до цього - напено десятки-одиниці тактів?Scoffer: ↑ 22.09.2024 19:32 Окрім того що це сотні-тисячі тактів проблем немає
- а запис в кодовий сегмент на x86 хіба не призводить до примусового скидання кешу, автоматично, при кожному запису?
Питання риторичні
- латентність позначена в тактах - це абсолютне значення з урахуванням конвеєризації, throughput для операцій запису на ARM також вищий - знову через простішу модель, на x86 такі швидкості принципово недосяжніScoffer: ↑ 22.09.2024 19:32 А можна краще звернутись до затримок доступу до кеша і виявити що на айслейкі це 5 тактів, на зен4 це 4-5 тактів, і на м1 це 3-4 такти. Залежність строго частотна, чим більш частотний проц, тим більші затримки
- латентність на ICL була збільшена саме через збільшення розміру і ПС заради "дуже потрібного" AVX512 - тобто в кого які приорітети
Це абсолютний лімит та обмеження архітектури: якщо вам, наприклад, потрібно виконати 2 послідовних store - на x86 будуть затримки саме через важкі протоколи синхронізації, навіть якщо ви пишете однопоточну програму, на ARM - ніScoffer: ↑ 22.09.2024 19:32 це не є обмежуючим фактором
В конжної інструкції є абсолютні 1) latency 2) throughput, тож якщо ви накидаєте купу послідовних store - воно ніяк не буде виконуватись паралельно, то особисто вам як програмісту (компілятора/асемблера/програми) доведеться думати про рознесення цих storeScoffer: ↑ 22.09.2024 19:32 Тебе має хвилювати виключно пропускна спроможність. Це конвеєр, ти накидуєш команд в топку і вони паралельно виконуються
Наведений асемблерний код не є smp-безпечним на всіх weak-ordered архітеутурах, він також не є smp-безпечним навіть на x86, якщо потоки використовують ту ж саму movntqScoffer: ↑ 22.09.2024 19:32 Наведений код виглядає рівно як демонстратор різниці меморі модел
- якщо супервізор (JIT-компілятор) знає, яку частину кода він оновив - з цим немає жодних проблемScoffer: ↑ 22.09.2024 19:32 будь-яку варіацію SMC на армах
- якщо сам код з дивної причини вирішив оновити сам себе (99.9% малварь?) - це скоріше вразливість x86, ніж перевага
- гарним тоном для сегментів кода є саме -W +RX, для даних +RW+NX тож ми знову звужуємо цю проблему до саморобних VM
Відправлено через 15 хвилин 22 секунди:
- x86_64 - похідна від i386, i386 - похідна від 80286, і т.д. (дуже умовно)NiTr0: ↑ 23.09.2024 14:42 то же и с х86 - 8086, i386 (32бит регистры и т.п.), x86-64. те самые legacy костыли из прошлого, да.
- thumb, arm32, aarch64 - це повністю несумісні між собою кодування
- кодування зазначених інструкцій на ARM значно простіше, ніж x86
тобто:
- на x86 декодер це мега-кобмайн, який тягне за собою абсолютно все
- на ARM це повністью відокремлені декодери
- для усіляких мікроконтролерів можна реалізувати лише thumb, або arm32 без thumb etc.
- на arm9 (сучасні високопродуктивні девайси), для прикладу, вирішили викинути все старе, тобто фактично замість трьох декодерів буде лише один (aarch64)
- на ARM через фіксований розмір інструкції - можна легко зробити N-wide decode (-накидати декодерів в паралель скількі завгодно), на x86 - це дуже велика проблема, тому без кешу мікрооперацій (L0 або uop-cache) - на x86 практично без альтернатив