ASUS вивела на український ринок лептоп Zenbook A14 із процесором Snapdragon X

[SergiusTheBest]

1. Сумісність дуже обмежена, багато програм або запускаються з багами та вилітами, або взагалі не працюють.
2. Транслятор має лютий оверхед, через що просдака продуктивності перетворює цей чип в якусь подобу i3 в режимі транслятора. В одних задачах просадка прийнятна і може складати 10%, а в деяких тестах (гугліть на ютьюбі) може бути навтіь більше 40%.

1. Програми, які встановлюють свій драйвер - не будуть працювати. Наприклад, VPN встановлює драйвер віртуальної мережевої карти, Google Drive встановлює драйвер мережевої файлової системи, антивірус також має свій драйвер. Adobe дивно чому не працює, але у їхніх програмістів дуже криві руки. Проте софта під ARM буде все більше і більше.
2. Так, на макбуках те саме: 20-30% просадки.

[Scoffer]

SergiusTheBest
Питання не тільки в драйверах. Проблеми можуть і виникнуть в багатопоточних завданнях. Простий приклад: сильна модель пам'яті х86 не дозволяє в більшості випадків читати кеш л2 в сусідньому ядрі поки не пройде синхронізація даних, а в армі дозволяє і вимагає від прогера додаткового коду з розстановками бар'єрів пам'яті, котрого тупо не існує в оригінальній прозі на х86 за відсутністю необхідності. Як транслятор на льоту його вигадає? Та ніяк. Аплє плюнула і завезла сильну модель в якості одного з додаткових режимів, а в квалкомі я щось нічого подібного не бачу.

Відправлено через 3 хвилини 53 секунди:
Це arm -> x86 можна "в лоб" транслювати і принципових проблем не виникне, а навпаки - не дуже.

[SergiusTheBest]

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

З коректно написаною програмою такої проблеми не буде, бо потоки синхронізуються між собою за допомогою примітивів синхронізації, що надає ОС, і вони виступають неявними бар'єрами пам'яті. А от якщо запускати віртуальну машину з x64 ОС на ARM64 залізі, тоді буде проблема, бо x64 ОС розраховує на одну модель пам'яті, а отримує іншу.

[Scoffer]

SergiusTheBest
Ти не зрозумів. В х86 деяких бар'єрів не потрібно бай дизайн. Відповідно їх немає і в прозі тому що а нафіга. Питання не як реалізовано, через ОС чи не через ОС, а чи реалізовано на х86 взагалі, що якраз і не факт, а на армі їх треба бо синхр може і розвалитись.

[SergiusTheBest]

Ти не зрозумів. В х86 деяких бар'єрів не потрібно бай дизайн. Відповідно їх немає і в прозі тому що а нафіга. Питання не як реалізовано, через ОС чи не через ОС, а чи реалізовано на х86 взагалі, що якраз і не факт, а на армі їх треба бо синхр може і розвалитись.

Якщо один поток - то бар'єрі не потрібні на x86 та ARM. Якщо багато потоків - то потрібні примітиви синхронізації, які надає ОС. Якщо користуватися ними - то все буде ок. Якщо намагатися писати свої примітиві синхронізації не на основі примітивів ОС - то буде халепа.

[Scoffer]

SergiusTheBest
Прогеру на х86 в загальному випадку начхати на стан кешу, йому не треба ставити бар'єр шоб другий потік отримав актуальні дані. Відповідно і примітиви синхронізації юзати не треба в дуже багатьох випадках, котрих треба в рісках, а конкретно арм ще й когерентність л1-л2 не тримає, окрім всього іншого, там ще й кеш чистити на кожен чих. Повторю, питання не в реалізації бар'єра а в його принциповій наявності. Якби все було так просто як ти думаєш, епл не завозила б собі в проц сильно більш складну реалізацію пам'яті.

[SergiusTheBest]

Прогеру на х86 в загальному випадку начхати на стан кешу, йому не треба ставити бар'єр шоб другий потік отримав актуальні дані. Відповідно і примітиви синхронізації юзати не треба в дуже багатьох випадках, котрих треба в рісках, а конкретно арм ще й когерентність л1-л2 не тримає, окрім всього іншого. Повторю, питання не в реалізації бар'єра а в його принциповій наявності. Якби все було так просто як ти думаєш, епл не завозила б собі в проц сильно більш складну реалізацію пам'яті.

А як по вашому один потік дізнається, що другий потік згенерував дані? За допомогою синхронізації! Якщо якийсь lock-free, то він побудований на атоміках. Я думаю, що Apple додала в M процесори іншу модель пам'яті для запуску x86 віртуальних машин (той же докер). І можливо, таке саме є в Snapgragon X (але відкритої інформації по цьому немає).

До речі, ось що пише Microsoft: Prism is optimized and tuned specifically for Qualcomm Snapdragon processors. Some performance features within Prism require hardware features only available in the Snapdragon X series. Тобто щось апаратне для прискорення x86 є.

[Scoffer]

SergiusTheBest
А атоміки це ще одна тема для розмови. В х86 строки блокуються по 64 байти, в армах - по 128. Зійшлись зорі і привіт дедлок там де його бути не мало б. В епл також цю проблему вирішили апаратно завізши 64-байтні строки.

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

Відправлено через 16 хвилин 58 секунд:
Тут треба пам'ятати що транслятору скормлюються саме машинні коди, а не джерело на умовних плюсах. Було б це джерело на плюсах, або хоча б байт-код llvm - більшість проблем самозникло б при перекомпіляції. А так ні, бачить транслятор команду CMPXCHG16B і йому на льоту треба вирішити як її перетворити на те шо зжере і бажано не подавиться арм. Це не завжди просто.

[SergiusTheBest]

А атоміки це ще одна тема для розмови. В х86 строки блокуються по 64 байти, в армах - по 128. Зійшлись зорі і привіт дедлок там де його бути не мало б. В епл також цю проблему вирішили апаратно завізши 64-байтні строки.

Не розумію, звідки там візьметься дедлок. В інтернетах пишуть, що 64 байта епл використовує суто для більшої ефективності, хоч і строка кешу у них 128 байт.

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

Тут треба пам'ятати що транслятору скормлюються саме машинні коди, а не джерело на умовних плюсах. Було б це джерело на плюсах, або хоча б байт-код llvm - більшість проблем самозникло б при перекомпіляції. А так ні, бачить транслятор команду CMPXCHG16B і йому на льоту треба вирішити як її перетворити на те шо зжере і бажано не подавиться арм. Це не завжди просто.

Це зрозуміло, але виклик до примітиву синхронізації, що надає ОС, так і залишається викликом до ОС. Тобто цілком зрозумілим бар'єром і з реалізацією під конкретну архітектуру.

[Scoffer]

SergiusTheBest
Прога очікує гранулярності атомарного доступу в 64 байти, на арм гранулярність 128 байт. В той же час LL/SC це пара команд, перша тегує строку кешу, а друга перевіряє і зберігає зміни якщо зі строки не зняли тег, а між ними ще щось виконується корисного. Що буде якщо два потоки довбитимуться атомарними операціями в сусідні 64-байтні простори (що допустимо для х86)? Правильно, скидуватимуть теги один одного до посиніння і нічо не зберігатимуть. Ну хоча так, це більше схоже на лайвлок, але результат той же самий.

PS: В еплі строка фізично 64 байти, логічно може бути організована в 64 і 128, як того вимагають відповідні режими.