Заметил при обновлении ПО, что на некоторых сайтах появились ARM версии известных программ. Да и ноутбуки на производительных процессорах потихоньку выходят https://www.youtube.com/watch?v=8oDztgOq_fU
Непонятно, что там с эмуляцией X86, но на МакБук Эйр M1 в виртуалке UTM x86 проги практически невозможно использовать, в Parallels чуть получше, но тормоза есть.
Блогер Rozetked утверждает, что без виртуалки тормозов нет, как и при эмуляции Intel на ARM маках.
Понятно, что версия АРМ это только 64-бит. Все ли перевели свои проги на 64 бит, ведь Вин11 существуют только в 64-битном варианте? Я еще нет.
Интересно, миграция с Intel64 на ARM64 ограничится перекомпиляцией, как под Мак, или чем-то сложнее? Кто пробовал уже?
Здравствуйте, Morgan, Вы писали:
M>на некоторых сайтах появились ARM версии известных программ.
На "некоторых" они стали появляться год-два назад. Сейчас это уже принимает массовый характер.
M>Понятно, что версия АРМ это только 64-бит.
Есть версии винды и для 32-разрядных ARM, но они уже раритет.
M>Все ли перевели свои проги на 64 бит
Все, кто этого хоть немного хотел, сделали это еще 15-20 лет назад. Чего там "переводить"-то?
M>миграция с Intel64 на ARM64 ограничится перекомпиляцией
На C/C++, если нет заточки именно под Intel — да. На других языках — зависит от совместимости реализаций.
Здравствуйте, Morgan, Вы писали: M>Интересно, миграция с Intel64 на ARM64 ограничится перекомпиляцией, как под Мак, или чем-то сложнее? Кто пробовал уже?
Паскалистов обидели, увы. В Free Pascal поддержка win64-aarch64 есть, но пока нормально не работает. В Delphi нет, и вроде пока даже не планируется.
Ну а так да, если ассемблера нету, то просто перекомпиляция своего кода и сторонних библиотек, если используются.
Здравствуйте, Morgan, Вы писали:
M>Непонятно, что там с эмуляцией X86, но на МакБук Эйр M1 в виртуалке UTM x86 проги практически невозможно использовать, в Parallels чуть получше, но тормоза есть. M>Блогер Rozetked утверждает, что без виртуалки тормозов нет, как и при эмуляции Intel на ARM маках.
Все так, в случае с Интелом там туева хуча эмуляции слоев абстракций, да и UTM это обертка вокруг qemu, известного своей неповоротливостью.
На уровне ОС же для трансляции комманд x86_64 -> aarch64, Apple сделала Rosetta 2, а Microsoft свой безымянный эмулятор. Они эмулируют по сути только CPU, потому их скорость близка к скорости машины. На приложениях мало использующих процессор вы вообще разницы не увидете, если запустите x86_64 EXE на Винде которая aarch64.
Здравствуйте, Morgan, Вы писали:
M>Понятно, что версия АРМ это только 64-бит. Все ли перевели свои проги на 64 бит, ведь Вин11 существуют только в 64-битном варианте? Я еще нет.
В смысле, x86 приложухи вообще не запускаются под Win11?
Здравствуйте, пффф, Вы писали:
П>Здравствуйте, Morgan, Вы писали:
M>>Понятно, что версия АРМ это только 64-бит. Все ли перевели свои проги на 64 бит, ведь Вин11 существуют только в 64-битном варианте? Я еще нет.
П>В смысле, x86 приложухи вообще не запускаются под Win11?
запускаются, просто они устарели для win11. как в 90-е годы устаревшие 16-битные программы для win95.
Здравствуйте, Morgan, Вы писали:
M>>>Понятно, что версия АРМ это только 64-бит. Все ли перевели свои проги на 64 бит, ведь Вин11 существуют только в 64-битном варианте? Я еще нет.
П>>В смысле, x86 приложухи вообще не запускаются под Win11?
M>запускаются, просто они устарели для win11. как в 90-е годы устаревшие 16-битные программы для win95.
Ну, запускать-то это их не мешало, и работали.
А какая сейчас проблема с x86 на Win11? Она ругается каждый раз, что "вы запускаете устаревшее ПО, поддержка которого в следующих версиях Windows будет отключена", или что-то подобное?
Здравствуйте, Черный □□ Властелин, Вы писали:
ЧВ> На уровне ОС же для трансляции комманд x86_64 -> aarch64, Apple сделала Rosetta 2, а Microsoft свой безымянный эмулятор.
Здравствуйте, пффф, Вы писали:
П>Здравствуйте, Morgan, Вы писали:
M>>>>Понятно, что версия АРМ это только 64-бит. Все ли перевели свои проги на 64 бит, ведь Вин11 существуют только в 64-битном варианте? Я еще нет.
П>>>В смысле, x86 приложухи вообще не запускаются под Win11?
M>>запускаются, просто они устарели для win11. как в 90-е годы устаревшие 16-битные программы для win95.
П>Ну, запускать-то это их не мешало, и работали.
П>А какая сейчас проблема с x86 на Win11? Она ругается каждый раз, что "вы запускаете устаревшее ПО, поддержка которого в следующих версиях Windows будет отключена", или что-то подобное?
Apple с 2019 года запретила 32-битные приложения, возможно в windows 12 будет то же самое. Visual Studio лишь в версии 2022 стал 64 бит, Майкрософт отстаёт.. и хорошо!
Здравствуйте, Morgan, Вы писали:
M>Apple с 2019 года запретила 32-битные приложения, возможно в windows 12 будет то же самое. Visual Studio лишь в версии 2022 стал 64 бит, Майкрософт отстаёт.. и хорошо!
Жаль. Я не шароварщик, но свой софт обычно собираю в x86 — разницы нет, а в размере раза в два меньше. Мелочь, но приятно
Здравствуйте, Черный 😈 Властелин, Вы писали:
ЧВ>если ассемблера нету, то просто перекомпиляция своего кода и сторонних библиотек
Не только ассемблер, любая зависимость от платформы будет мешать. Например, в C/C++ есть встроенные (intrinsic) функции, которые напрямую отображаются на процессорные операции. Одни, вроде _InterlockedXxx, есть для всех платформ, а другие, вроде __emul — только для подходящих.
Но в основном такие функции используют для ускорения, так что для других процессоров можно попробовать определить свои варианты.
Здравствуйте, rudzuk, Вы писали:
R>Здравствуйте, Черный □□ Властелин, Вы писали:
ЧВ>> На уровне ОС же для трансляции комманд x86_64 -> aarch64, Apple сделала Rosetta 2, а Microsoft свой безымянный эмулятор.
R>Технология трансляции у МС называется: Prism.
Пишут,
Обратите внимание, что эмуляция поддерживает только код пользовательского режима и не поддерживает драйверы; все компоненты режима ядра должны быть скомпилированы как Arm64.
Наверное драйверов под арм не так и много.. и вообще непонятно, зачем они это делают, Интел не сильно хуже, на моем Хуавей с core i7 13700h всё мгновенно запускается и не греется ничего.
Здравствуйте, Morgan, Вы писали:
П>>x86 приложухи
M>они устарели для win11. как в 90-е годы устаревшие 16-битные программы для win95.
Не путайте, это радикально разные ситуации.
16-разрядные программы работали в подсистеме Win16, а 32-разрядные (x86) — в подсистеме Win32. Это очень разные по архитектуре подсистемы, у них совпадают только имена основных функций API.
С переходом с Win16 на Win32 в винде качественно поменялись и архитектура, и функциональность. Подсистема Win16 даже для Win9x была практически чуждой — там под нею работали только драйверы принтеров и звуковых устройств, которые не успели вовремя переписать под Win32. А в любой NT под Win16 ничего своего уже не было, ее держали исключительно для поддержки старых приложений.
Win32 же является родной подсистемой для всех NT-систем, включая Win11. В 64-разрядных версиях винды не добавилось качественно новой функциональности — основной подсистемой так и осталась Win32, которая в этих версиях просто стала 64-разрядной (изменилась чисто количественно), а добавилась как раз WOW64, которая попросту транслирует одни и те же вызовы между 64- и 32-разрядным кодом и изолирует определенные каталоги и ветви реестра.
Поддержку Win16 выкинули потому, что она вообще никому не была нужна — в старой парадигме давно никто ничего не делал, ибо она убога и примитивна, и изжила себя еще в 80-е на 386. А 32-разрадные приложения до сих пор делают все, кому не лень, и поддержку x86 сейчас выкидывают сугубо из прагматических соображений — считается, что экономия на размере кода компенсируется затратами времени/памяти на содержание подсистемы WOW64 (там только на диске больше гигабайта), на эмуляторы между разными платформами и т.п.
Здравствуйте, пффф, Вы писали:
П>свой софт обычно собираю в x86 — разницы нет, а в размере раза в два меньше.
Чтобы в два, нужно очень постараться — например, использовать огромные таблицы указателей (или других значений, которые по умолчанию имеют разрядность платформы). У меня разница не больше 10-15 процентов, как и должно быть в среднем.
Здравствуйте, Евгений Музыченко, Вы писали:
ЧВ>>если ассемблера нету, то просто перекомпиляция своего кода и сторонних библиотек
ЕМ>Не только ассемблер, любая зависимость от платформы будет мешать. Например, в C/C++ есть встроенные (intrinsic) функции, которые напрямую отображаются на процессорные операции. Одни, вроде _InterlockedXxx, есть для всех платформ, а другие, вроде __emul — только для подходящих.
ЕМ>Но в основном такие функции используют для ускорения, так что для других процессоров можно попробовать определить свои варианты.
Я не настоящий сварщик, но слыхал, что в ARM другая модель консистентности памяти. И что многопоточный код, который под x86 работает через общую памяти, под ARM вполне может сломаться. Понятно, что этот код изначально является глючным и работает, можно сказать, только по счастливому совпадению, но неприятности при поиске такого бага это не уменьшает.
Здравствуйте, Morgan, Вы писали:
M> и вообще непонятно, зачем они это делают, Интел не сильно хуже, на моем Хуавей с core i7 13700h всё мгновенно запускается и не греется ничего.
Когда вышел M1 мой коллега пищал от восторга, сравнивая свой эйр с ноутом на интеловской ультре тех же времен. Производительность выше, от батареи живет дольше, и охлаждение пассивное. Еще говорил, что ноут на ультре только от розетки нормальную производительность показывает, работая от батареи проседает сильно.
Здравствуйте, Евгений Музыченко, Вы писали:
П>>свой софт обычно собираю в x86 — разницы нет, а в размере раза в два меньше.
ЕМ>Чтобы в два, нужно очень постараться — например, использовать огромные таблицы указателей (или других значений, которые по умолчанию имеют разрядность платформы). У меня разница не больше 10-15 процентов, как и должно быть в среднем.
Экстремальный случай — это раза в три, когда я llvm использовал. Но в полтора раза стабильно меньше
Здравствуйте, vsb, Вы писали:
vsb>слыхал, что в ARM другая модель консистентности памяти.
Не памяти, а состояния кэшей разных ядер/процессоров. x86/x64 обеспечивает соответствие аппаратно, в ARM это нужно делать явно.
vsb>И что многопоточный код, который под x86 работает через общую памяти
Если речь о примитивах синхронизации, то они везде работают через общую память.
vsb>под ARM вполне может сломаться.
Только если там что-то совсем самопальное/ручное. Реализация встроенных (intrinsic) InterlockedXxx обеспечивает пометку нужных ячеек памяти, а все остальное реализовано в системе, которая обеспечивает то же самое сама.
Если используется самопальная синхронизация, то нужно добавлять семантику acquire/release или барьеры. У меня такое кое-где используется, расставил там барьеры — пользователи не жаловались.
Еще у компилятора MSVC есть ключ /volatile для управления генерацией кода при операциях с volatile-переменными. С параметром "ms" он для ARM выдает соответствующие команды сам.
vsb>Понятно, что этот код изначально является глючным и работает, можно сказать, только по счастливому совпадению
Почему "понятно"? В x86/x64 это штатное, документированное поведение, они не умеют работать иначе.
Чего там "переводить"-то?
