S>Вроде Xcode — это гигант, даже судя по размеру бинарников. Как так быстро смогли перевести под ARM? S>Ну и главное — сможет ли MS сделать так же со своей VS или там все намного хуже?
ВС уже год так точно доступна для АРМ. правда они писали что планируют закрыть это направление, потому что ненужно.
Нет времени на раскачку!
Re[2]: Как Apple так быстро сделали Xcode для ARM? Сможет ли MS?
Здравствуйте, СвободуАнжелеДевис, Вы писали:
САД>ВС уже год так точно доступна для АРМ. правда они писали что планируют закрыть это направление, потому что ненужно.
Вроде писали, что для макос закроют. А теперь, когда МС сама планирует устройства на арм клепать и винду на них ставить, кто-то должен будет и приложения под нее писать. А на чем и где? Не в макос же.
Re[3]: Как Apple так быстро сделали Xcode для ARM? Сможет ли MS?
Здравствуйте, rFLY, Вы писали:
FLY>Вроде писали, что для макос закроют. А теперь, когда МС сама планирует устройства на арм клепать и винду на них ставить, кто-то должен будет и приложения под нее писать. А на чем и где? Не в макос же.
Ну, идея писать приложения ровно на той же платформе, что и исполнять их, устарела уже лет двадцать как.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: Как Apple так быстро сделали Xcode для ARM? Сможет ли
FLY>Вроде писали, что для макос закроют. А теперь, когда МС сама планирует устройства на арм клепать и винду на них ставить, кто-то должен будет и приложения под нее писать. А на чем и где? Не в макос же.
Эмуляторы были еще со времен ЦЕ. Прекрасно обходились и без девайсов на VS 2008
А Xamarin (MAUI)тоже прекрасно использует гугловские эмуляторы
Да и для нормальных девайсов все прекрасно через USB (TCP/IP) устанавливается, отлаживается итд
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>Да и для нормальных девайсов все прекрасно через USB (TCP/IP) устанавливается, отлаживается итд
Потребовалось мне странички для хрома версии 60+ поотлаживать. Так эмуляторы андроида из состава VS2022, как говорится — "то потухнут, то погаснут". Это что ли прекрасно?
Re[5]: Как Apple так быстро сделали Xcode для ARM? Сможет ли
Здравствуйте, rFLY, Вы писали:
S>>Да и для нормальных девайсов все прекрасно через USB (TCP/IP) устанавливается, отлаживается итд FLY>Потребовалось мне странички для хрома версии 60+ поотлаживать. Так эмуляторы андроида из состава VS2022, как говорится — "то потухнут, то погаснут". Это что ли прекрасно?
Вообще то там Гугловские эмуляторы. У меня все нормально тестируется. Сочувствую.
Но можешь и на девайсе отлаживать. В чем проблема? Или у тебя только айфоны?
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Sinclair, Вы писали:
S>Ну, идея писать приложения ровно на той же платформе, что и исполнять их, устарела уже лет двадцать как.
Для всяких дохлых и малодоступных девайсов — да. Но в чём проблема писать на вполне себе современных и мощных платформах? К которым АРМ уже вполне относятся. Мне даже на Nvidia Jetson Nano было проще разрабатывать, а современные Джетсоны — практически суперкомпьютеры по сравнению с ним.
Re[6]: Как Apple так быстро сделали Xcode для ARM? Сможет ли
Здравствуйте, Serginio1, Вы писали:
S>Вообще то там Гугловские эмуляторы. У меня все нормально тестируется. Сочувствую.
Да какая разница кто этот эмуль писал. Не знаю как раньше, но в vs2022 на современном железе эмуляторы старых версий андроида работают ужасно.
S> Но можешь и на девайсе отлаживать. В чем проблема? Или у тебя только айфоны?
У меня андроид, но разве суть твоего сообщения не в том, что при наличии эмулятора девайс не нужен?
Re[7]: Как Apple так быстро сделали Xcode для ARM? Сможет ли
Здравствуйте, rFLY, Вы писали:
S>>Вообще то там Гугловские эмуляторы. У меня все нормально тестируется. Сочувствую. FLY>Да какая разница кто этот эмуль писал. Не знаю как раньше, но в vs2022 на современном железе эмуляторы старых версий андроида работают ужасно.
S>> Но можешь и на девайсе отлаживать. В чем проблема? Или у тебя только айфоны? FLY>У меня андроид, но разве суть твоего сообщения не в том, что при наличии эмулятора девайс не нужен?
Вроде писали, что для макос закроют. А теперь, когда МС сама планирует устройства на арм клепать и винду на них ставить, кто-то должен будет и приложения под нее писать. А на чем и где? Не в макос же.
Писать на VS под виндой. Хочешь используй эмуль, хочешь девайс через USB или TСP/IP.
Зачем нужна VS под макос или андроид?
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Shmj, Вы писали:
S>Вроде Xcode — это гигант, даже судя по размеру бинарников. Как так быстро смогли перевести под ARM?
Всё кроме мака очень давно было на ARM. Так что ARM там везде давно уже маячил.
Ну и "быстро" это сколько по твоему?
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Re[8]: Как Apple так быстро сделали Xcode для ARM? Сможет ли
Здравствуйте, Serginio1, Вы писали:
S> Писать на VS под виндой. Хочешь используй эмуль, хочешь девайс через USB или TСP/IP. S>Зачем нужна VS под макос или андроид?
Эээ. Вообще речь об вс под винду на арме. А если ты спрашиваешь про мои мытарства с эмулятором, то писалась страничка, которая должна была корректно работать на древнющем говне.
Re[9]: Как Apple так быстро сделали Xcode для ARM? Сможет ли
Здравствуйте, rFLY, Вы писали:
S>> Писать на VS под виндой. Хочешь используй эмуль, хочешь девайс через USB или TСP/IP. S>>Зачем нужна VS под макос или андроид? FLY>Эээ. Вообще речь об вс под винду на арме. А если ты спрашиваешь про мои мытарства с эмулятором, то писалась страничка, которая должна была корректно работать на древнющем говне.
Зачем винда на арме, если прекрасно все работает и по х86?
Ты и сейчас можешь подключаться и отлаживать программы на другом компьютере.
Ну а например .Net Core можешь прекрасно отлаживать и на x86 https://learn.microsoft.com/ru-ru/windows/arm/overview#find-tools-for-arm-development
.NET 6 уже поддерживает Arm как для машинного выполнения Arm, так и для эмуляции x64. Для разработки приложений .NET, работающих на устройствах Arm64, рекомендуется установить новый собственный пакет Visual Studio 2022 17.4 и пакет SDK для .NET 7 Arm64. Дополнительные сведения о поддержке .NET 7 для Arm и улучшения производительности Arm64 см. в блоге .NET.
Пакет SDK для .NET 6 Arm64: по умолчанию, если приложение dotnet run .NET 6 с пакетом SDK Arm64 будет работать как Arm64. Это dotnet-runtimeinfo средство можно использовать для обнаружения среды, в которой работает .NET. Дополнительные сведения см. в блоге .NET 6 в службе поддержки Arm64.
и солнце б утром не вставало, когда бы не было меня
Re: Как Apple так быстро сделали Xcode для ARM? Сможет ли MS?
Здравствуйте, Serginio1, Вы писали:
S> Зачем винда на арме, если прекрасно все работает и по х86?
Затем, что это тренд нынешнего и последующих лет. АРМы холодные (бесшумные), производительные (мы же верим квалкому), легкие, с модемчиками и ваще модные. Интельчик все. Лежит с температурой.
Здравствуйте, rudzuk, Вы писали:
R>Здравствуйте, Serginio1, Вы писали:
S>> Зачем винда на арме, если прекрасно все работает и по х86?
R>Затем, что это тренд нынешнего и последующих лет. АРМы холодные (бесшумные), производительные (мы же верим квалкому), легкие, с модемчиками и ваще модные. Интельчик все. Лежит с температурой.
Здравствуйте, Nuzhny, Вы писали:
N>Для всяких дохлых и малодоступных девайсов — да.
Ну почему для дохлых и малодоступных? Вот, к примеру, если я хочу написать приложение для iOS — мне что теперь, студию на iPhone запускать? Зачем?
N>Но в чём проблема писать на вполне себе современных и мощных платформах? К которым АРМ уже вполне относятся. Мне даже на Nvidia Jetson Nano было проще разрабатывать, а современные Джетсоны — практически суперкомпьютеры по сравнению с ним.
Всё наоборот — зачем создавать себе проблему?
Вот у меня лаптоп с Core i7. Если мне вдруг захочется таргетить в своём приложении ARM — мне зачем переезжать на него со всем своим окружением? С какой целью?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: Как Apple так быстро сделали Xcode для ARM? Сможет ли MS?
в каком смысле быстро?
если кто помнит, яблочники в 2015 году выкатили свой bitcode с той же идеей, как у дотнета и, видимо, жабы (не в курсе про неё): приложение компилируется не прямо в инструкции для конечного процессора, а в команды некоего абстрактного ассемблера и в дальнейшем может быть автоматически (самим апстором) перекомпилировано под любой требуемый процессор.
на тот момент bitcode никому нафиг был не нужен, да и его включение необязательно. Но конечная цель была понятна уже тогда, 8 лет назад: возможно, эпл готовится к каким-то изменениям, связанным со сменой процессора. Возможно, с унификацией процессора между компами, телефонами и планшетами. Ну и кто бы мог подумать: выходят маки на М* и айпады на нём же. Ждем айфоны.
А начали-то они, видимо, ещё раньше, т.е. условно десяток лет у них был.
Re[6]: Как Apple так быстро сделали Xcode для ARM? Сможет ли MS?
Здравствуйте, Sinclair, Вы писали:
S>Всё наоборот — зачем создавать себе проблему? S>Вот у меня лаптоп с Core i7. Если мне вдруг захочется таргетить в своём приложении ARM — мне зачем переезжать на него со всем своим окружением? С какой целью?
Ну, у меня окружение на i7 x86 и на ARM Linux ну очень разные, практически никак не пересекаются. Пусть АРМ послабее, но работать прямо на нём мне комфортнее.
Re[13]: Как Apple так быстро сделали Xcode для ARM? Сможет л
Здравствуйте, Nuzhny, Вы писали:
N>Ну, у меня окружение на i7 x86 и на ARM Linux ну очень разные, практически никак не пересекаются.
Вот и я о том же — зачем мне разные окружения? Все эти ключики от гита, настройки VPN, предпочтения в студии, кэш посещённых страниц, етк. N>Пусть АРМ послабее, но работать прямо на нём мне комфортнее.
Это совершенно ортогональный фактор.
Если вдруг какое-то конкретное ARM устройство удобнее, то можно переехать на него, и девелопить на нём всё — и для винтел, и для iOS с его чипами, и для всего остальное.
Но вот идея что "раз мы хотим компилировать программы для ARM, то и разрабатывать их мы должны на ARM" — она порочна сама по себе.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[4]: Как Apple так быстро сделали Xcode для ARM? Сможет ли MS?
Здравствуйте, Sinclair, Вы писали:
S>Вот у меня лаптоп с Core i7. Если мне вдруг захочется таргетить в своём приложении ARM — мне зачем переезжать на него со всем своим окружением? С какой целью?
Кросс-компиляция всегда считалась сложной дрянью. Особенно на с++ со всяким там autotools с bash-скриптами и прочими марсианскими манускриптами, под разные линуксы, особенно под коммерческие юниксы, особенно с последующим пакетированием (ведь сложить файлики в архив — это очень сложное занятие, его за 40 лет не осилили, а теперь и тем более не осилят, поскольку кодинг закончился с появлением ChatGPT).
Людей от этого так тошнило, что появился Докер.
Re[4]: Как Apple так быстро сделали Xcode для ARM? Сможет ли MS?
Здравствуйте, Sinclair, Вы писали:
FLY>>Вроде писали, что для макос закроют. А теперь, когда МС сама планирует устройства на арм клепать и винду на них ставить, кто-то должен будет и приложения под нее писать. А на чем и где? Не в макос же. S>Ну, идея писать приложения ровно на той же платформе, что и исполнять их, устарела уже лет двадцать как.
С этим есть проблема в тестировании нативных приложений. Если вы пишете на другой платформе, то тестируете сильно опосредовано, через эмуляторы, точечными тестами итд.
А если вы сидите с ушами на той самой платформе, то тестирование само собой получается более плотным в силу естественных причин.
Например, с виндой вечно проблема с путями — ктото да всунет виндовый путь, а потом на линуксе это отвалится.
Re[8]: Как Apple так быстро сделали Xcode для ARM? Сможет ли MS?
Здравствуйте, Sinclair, Вы писали:
S>Вот и я о том же — зачем мне разные окружения? Все эти ключики от гита, настройки VPN, предпочтения в студии, кэш посещённых страниц, етк.
Я не могу понять, в чём проблема разных окружений. К устройству есть доступ по ssh, оно достаточно мощное для компиляции. Ядро я на нём же не собираю. Ну и всё нативное, без лишних лагов.
N>>Пусть АРМ послабее, но работать прямо на нём мне комфортнее. S>Это совершенно ортогональный фактор.
Нет, как раз основной. Кросскомпиляция для эмбеддет — это естественно и нормально. Но для многих устройств нет проблем работать на них самих именно потому, что скорость разработки не падает.
S>Если вдруг какое-то конкретное ARM устройство удобнее, то можно переехать на него, и девелопить на нём всё — и для винтел, и для iOS с его чипами, и для всего остальное.
Не надо на каком-то одном устройстве девелопить всё — вот это уже порочная практика. Надо быть гибче.
S>Но вот идея что "раз мы хотим компилировать программы для ARM, то и разрабатывать их мы должны на ARM" — она порочна сама по себе.
Никто это и не продвигает.
Re[5]: Как Apple так быстро сделали Xcode для ARM? Сможет ли
Здравствуйте, Pauel, Вы писали: P>С этим есть проблема в тестировании нативных приложений. Если вы пишете на другой платформе, то тестируете сильно опосредовано, через эмуляторы, точечными тестами итд. P>А если вы сидите с ушами на той самой платформе, то тестирование само собой получается более плотным в силу естественных причин. P>Например, с виндой вечно проблема с путями — ктото да всунет виндовый путь, а потом на линуксе это отвалится.
Здравствуйте, Serginio1, Вы писали:
P>>С этим есть проблема в тестировании нативных приложений. Если вы пишете на другой платформе, то тестируете сильно опосредовано, через эмуляторы, точечными тестами итд. P>>А если вы сидите с ушами на той самой платформе, то тестирование само собой получается более плотным в силу естественных причин. P>>Например, с виндой вечно проблема с путями — ктото да всунет виндовый путь, а потом на линуксе это отвалится.
S> Кто тебе мешает тестировать на устройстве через USB или TCP/IP ?
Цитирую себя "сильно опосредовано, через эмуляторы, точечными тестами"
S>Для линукса есть WSL 2
Забавная вещь с этим wsl 2 — это ненастоящий линукс. Для примера — год назад или около того, переводил билды мавена с виндовых путей на линуксовые, по двум причинам
1. для себя, т.к. я сам перешел на линукс
2. билдагент должен был перейти на кубер с лялихом
P>Забавная вещь с этим wsl 2 — это ненастоящий линукс. Для примера — год назад или около того, переводил билды мавена с виндовых путей на линуксовые, по двум причинам P>1. для себя, т.к. я сам перешел на линукс P>2. билдагент должен был перейти на кубер с лялихом
P>И вот в процессе выяснилось, что дотнетчик безо всяких фиксов спокойно пускал билды под wsl, и это работало. У меня же под линуксом дотнетая часть ну никак не собиралась, от слова совсем. Заработала только после того, как я вычистил вообще все пути
Собираешь докер под виндой? https://learn.microsoft.com/ru-RU/visualstudio/containers/container-build?view=vs-2022
>> или подключиться к удаленному процессу https://learn.microsoft.com/ru-ru/visualstudio/debugger/attach-to-process-running-in-docker-container?view=vs-2022
P>Цитирую себя "сильно опосредовано, через эмуляторы, точечными тестами"
Вот у тебя случилась проблема на wsl. Какая проблема у тебя была с удаленным отладчиком?
Для запуска есть логи. По ним бОльшая часть загрузки и ловится, так как не всегда дебажный вариант, соответствует релизу.
Для ЦЕ и андроидов как ты пишешь точечные тесты используются и никто не жалуется. Нет проблем.
Устанавливать WS на ЦЕ?
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Pauel, Вы писали:
P>И вот в процессе выяснилось, что дотнетчик безо всяких фиксов спокойно пускал билды под wsl, и это работало. У меня же под линуксом дотнетая часть ну никак не собиралась, от слова совсем. Заработала только после того, как я вычистил вообще все пути
Мда, и опять выходит что винда лучше линух чем сам линух
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Re[5]: Как Apple так быстро сделали Xcode для ARM? Сможет ли MS?
Здравствуйте, Pauel, Вы писали:
P>С этим есть проблема в тестировании нативных приложений. Если вы пишете на другой платформе, то тестируете сильно опосредовано, через эмуляторы, точечными тестами итд.
Почему? Я (условно) пишу банк-клиент для айфона. И тестирую его непосредственно на айфоне, через TestFlight. Ежедневно перевожу деньги, смотрю балансы, оплачиваю счета, и т.д.
Конечно же это лучше любого эмулятора. Но по-прежнему непонятно, зачем мне запускать студию на этом же устройстве.
Понимаете, вся эта наркомания про то "где будем исполнять — там и разрабатываем" была придумана во времена, когда все программисты писали программы для программистов.
Если я разрабатываю студию для ARM, то разрабатывать её в студии на ARM — хорошая, годная идея.
Но блин это 0.0001% реальных сценариев — большинство людей пишут не студию под ARM, а какой-то другой софт. Например, фотошоп. И работать с этим фотошопом надо, конечно, на ARM.
А запуск на этом АРМестудии никак не увеличит плотность тестового покрытия фотошопа.
P>А если вы сидите с ушами на той самой платформе, то тестирование само собой получается более плотным в силу естественных причин. P>Например, с виндой вечно проблема с путями — ктото да всунет виндовый путь, а потом на линуксе это отвалится.
Это иллюзия. Плотность тестирования достигается не тем, что "я компилирую программу том же устройство", а
а) целенаправленной QA деятельностью — с внятной политикой, целями, метриками и контролем. Вы, кстати, по соседству писали очень, очень толковые замечания про юнит-тесты.
б) догфудингом настолько, насколько возможно. Который вовсе не сводится к запуску на таргет платформе компилятора.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[9]: Как Apple так быстро сделали Xcode для ARM? Сможет ли MS?
Здравствуйте, Nuzhny, Вы писали: N>Я не могу понять, в чём проблема разных окружений. К устройству есть доступ по ssh, оно достаточно мощное для компиляции. Ядро я на нём же не собираю. Ну и всё нативное, без лишних лагов.
Проблема разных окружений в том, что они разные. Обновил ключ на одном — надо не забыть обновить его на другом. Перенастроил VPN на одном — надо не забыть перенастроить VPN на другом.
Решение с удалённым запуском компиляции на устройстве мне понятно. Но оно не требует наличия на устройстве студии и всего девеломпент стека.
N>Нет, как раз основной. Кросскомпиляция для эмбеддет — это естественно и нормально. Но для многих устройств нет проблем работать на них самих именно потому, что скорость разработки не падает.
Я не вижу логики в ваших рассуждениях. Из того, что что-то не создаёт проблем, не означает, что нужно этим чем-то обязательно пользоваться.
Вот, скажем, мне не составляет никакой проблемы покупать молоко в разных магазинах. Но это не означает, что я искусственно буду заставлять себя чередовать эти магазины.
S>>Если вдруг какое-то конкретное ARM устройство удобнее, то можно переехать на него, и девелопить на нём всё — и для винтел, и для iOS с его чипами, и для всего остальное. N>Не надо на каком-то одном устройстве девелопить всё — вот это уже порочная практика. Надо быть гибче.
Вот это хотелось бы как-то обосновать. Если одно устройство компилирует быстрее, чем другое — надо всё компилировать на нём. Если можно распределить компиляцию на оба устройства — надо параллелить.
Если одно устройство обладает более отзывчивым/просторным/хорошим гуём, то редактировать код надо на нём.
Потому что скорость разработки = скорости цикла "протестировал — исправил — скомпилировал". Соответственно, выбираем то, на котором эти шаги быстрее.
S>>Но вот идея что "раз мы хотим компилировать программы для ARM, то и разрабатывать их мы должны на ARM" — она порочна сама по себе.
N>Никто это и не продвигает.
Я отвечал вот на это:
А теперь, когда МС сама планирует устройства на арм клепать и винду на них ставить, кто-то должен будет и приложения под нее писать. А на чем и где?
Здесь явно подразумевается, что приложения под ARM нужно и разрабатывать, сидя под ARM. И вы продолжаете агитировать в ту же сторону, хотя утверждаете, что вроде как нет.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[7]: Как Apple так быстро сделали Xcode для ARM? Сможет ли
Здравствуйте, Pauel, Вы писали:
P>Забавная вещь с этим wsl 2 — это ненастоящий линукс. Для примера — год назад или около того, переводил билды мавена с виндовых путей на линуксовые, по двум причинам P>1. для себя, т.к. я сам перешел на линукс P>2. билдагент должен был перейти на кубер с лялихом
Он ещё сырой как хрен знает что. Я вот как раз сейчас его осваиваю — выясняются забавные вещи. Уже не первый релиз у WSL2, и пацаны до сих пор не допилили базовые вещи: маунт виндовой ФС до сих пор кривой, как турецкая сабля. Начиная от того, что часть файлов случайно начинает принадлежать неизвестно кому (и никакие chown не помогают), что лечится установкой настройки в секции experimental, и заканчивая тем, что параллельное чтение несколькими процессами одного файла регулярно отпадает с IO Error, что не лечится пока ничем. Плюс сетевой стек, который теряет пакеты при работе через виндовый VPN. Что, увы, не лечится никакими настройками, даже в секции experimental.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[8]: Как Apple так быстро сделали Xcode для ARM? Сможет ли
Здравствуйте, Serginio1, Вы писали:
P>>И вот в процессе выяснилось, что дотнетчик безо всяких фиксов спокойно пускал билды под wsl, и это работало. У меня же под линуксом дотнетая часть ну никак не собиралась, от слова совсем. Заработала только после того, как я вычистил вообще все пути S> Собираешь докер под виндой? https://learn.microsoft.com/ru-RU/visualstudio/containers/container-build?view=vs-2022
Цитирую себя "сильно опосредовано, через эмуляторы, точечными тестами"
P>>Цитирую себя "сильно опосредовано, через эмуляторы, точечными тестами" S> Вот у тебя случилась проблема на wsl. Какая проблема у тебя была с удаленным отладчиком?
В удалённом отладчике никто не сидит 100% времени, а потому большинство проблем проходит мимо него
S>Для запуска есть логи. По ним бОльшая часть загрузки и ловится, так как не всегда дебажный вариант, соответствует релизу.
Цитирую себя "сильно опосредовано, через эмуляторы, точечными тестами"
S>Для ЦЕ и андроидов как ты пишешь точечные тесты используются и никто не жалуется. Нет проблем.
Жалуются, только альтернативы нет.
Re[8]: Как Apple так быстро сделали Xcode для ARM? Сможет ли
Здравствуйте, CreatorCray, Вы писали:
P>>И вот в процессе выяснилось, что дотнетчик безо всяких фиксов спокойно пускал билды под wsl, и это работало. У меня же под линуксом дотнетая часть ну никак не собиралась, от слова совсем. Заработала только после того, как я вычистил вообще все пути
CC>Мда, и опять выходит что винда лучше линух чем сам линух
Это wsl больше про винду, чем про линукс. У Микрософта это традиция — приобщиться к конкурентам, и переделывать под себя.
Re[6]: Как Apple так быстро сделали Xcode для ARM? Сможет ли MS?
Здравствуйте, Sinclair, Вы писали:
P>>С этим есть проблема в тестировании нативных приложений. Если вы пишете на другой платформе, то тестируете сильно опосредовано, через эмуляторы, точечными тестами итд. S>Почему? Я (условно) пишу банк-клиент для айфона. И тестирую его непосредственно на айфоне, через TestFlight. Ежедневно перевожу деньги, смотрю балансы, оплачиваю счета, и т.д.
Если вы пользуетесь для своих целей, то это очень круто. Но вобщем большинство разработчиков так не делают — надеются на QA
S>Конечно же это лучше любого эмулятора. Но по-прежнему непонятно, зачем мне запускать студию на этом же устройстве.
Я больше про десктоп приложения писал. На телефоне студию конечно же нет смысла запускать. А с десктопом есть много всего — то одни настройки, то другие.
Пример — шрифты дрожат при drag&drop, и юзеры жалуются. А девелоперы сидят на другой платформе и с этим вообще не сталкиваются — у них графический стек работает иначе.
S>Понимаете, вся эта наркомания про то "где будем исполнять — там и разрабатываем" была придумана во времена, когда все программисты писали программы для программистов. S>Если я разрабатываю студию для ARM, то разрабатывать её в студии на ARM — хорошая, годная идея.
Не только студию, а большие десктопные приложения или приложения требовательные к ресурсам.
S>Но блин это 0.0001% реальных сценариев — большинство людей пишут не студию под ARM, а какой-то другой софт. Например, фотошоп. И работать с этим фотошопом надо, конечно, на ARM. S>А запуск на этом АРМестудии никак не увеличит плотность тестового покрытия фотошопа.
Дело не в том, где вы студию запускаете, а где разработчик проводит бОльшую часть времени.
S>Это иллюзия. Плотность тестирования достигается не тем, что "я компилирую программу том же устройство", а S>а) целенаправленной QA деятельностью — с внятной политикой, целями, метриками и контролем. Вы, кстати, по соседству писали очень, очень толковые замечания про юнит-тесты. S>б) догфудингом настолько, насколько возможно. Который вовсе не сводится к запуску на таргет платформе компилятора.
Я собственно про догфудинг если правильно этот термин понимаю, а не самого компилятора.
Про догфудинг — проверял тушенку для кота на себе, жена не успевала покупать
Re[9]: Как Apple так быстро сделали Xcode для ARM? Сможет ли
Здравствуйте, Pauel, Вы писали:
P>>>И вот в процессе выяснилось, что дотнетчик безо всяких фиксов спокойно пускал билды под wsl, и это работало. У меня же под линуксом дотнетая часть ну никак не собиралась, от слова совсем. Заработала только после того, как я вычистил вообще все пути S>> Собираешь докер под виндой? https://learn.microsoft.com/ru-RU/visualstudio/containers/container-build?view=vs-2022
P>Цитирую себя "сильно опосредовано, через эмуляторы, точечными тестами"
P>>>Цитирую себя "сильно опосредовано, через эмуляторы, точечными тестами" S>> Вот у тебя случилась проблема на wsl. Какая проблема у тебя была с удаленным отладчиком?
P>В удалённом отладчике никто не сидит 100% времени, а потому большинство проблем проходит мимо него
Это как? Ты отлаживаешь ровно так же как на своем компе. Какие проблемы? S>>Для запуска есть логи. По ним бОльшая часть загрузки и ловится, так как не всегда дебажный вариант, соответствует релизу.
P>Цитирую себя "сильно опосредовано, через эмуляторы, точечными тестами"
S>>Для ЦЕ и андроидов как ты пишешь точечные тесты используются и никто не жалуется. Нет проблем.
P>Жалуются, только альтернативы нет.
Я не жалуюсь и проблем нет. Опиши проблемы. А то мы не в курсе!
Чем удаленная отладка по Tcp/IP сильно отличается от отладки на компе.
Применяется постоянно для удаленной отладки. https://learn.microsoft.com/ru-ru/visualstudio/debugger/remote-debugging?view=vs-2022 https://learn.microsoft.com/ru-ru/visualstudio/debugger/remote-debugging-csharp?view=vs-2022 https://learn.microsoft.com/ru-ru/visualstudio/debugger/remote-debugging-dotnet-core-linux-with-ssh?view=vs-2022
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Sinclair, Вы писали: S>Ну, идея писать приложения ровно на той же платформе, что и исполнять их, устарела уже лет двадцать как.
Кросс-компиляция в первую очередь необходима для встраивальщины (т.е. либо очень слабые вычислительные мощности целевой платформы, либо нет периферии, удобной для разраба).
Эппловский M1/2 — это не тот случай, и ЕМНИП даже уделывал тогдашних топов мобильных интелов, ну а с т.з. периферии ноут он и есть ноут.
Re[10]: Как Apple так быстро сделали Xcode для ARM? Сможет ли MS?
Здравствуйте, Sinclair, Вы писали:
S>Решение с удалённым запуском компиляции на устройстве мне понятно. Но оно не требует наличия на устройстве студии и всего девеломпент стека.
Студия — это у тебя профессиональная деформация. По факту, она не всегда и нужна. Но при необходимости, VS Code умеет быть установленным у разработчика и по ssh работать с удалённым устройством. То есть там нужен просто тулчейн.
S>Вот, скажем, мне не составляет никакой проблемы покупать молоко в разных магазинах. Но это не означает, что я искусственно буду заставлять себя чередовать эти магазины.
Вот, я смотрю на твой путь примерно также: зачем тебе на одном компе агрегировать сразу всё? Я могу получить устройство от одного разработчика (физически или по сети), к нему логин/пароль и там уже будет установлен весь необходимый тулчейн и окружение. Сделаю свою часть, отлажусь, напишу тесты, проверю и отдам дальше.
S>Вот это хотелось бы как-то обосновать. Если одно устройство компилирует быстрее, чем другое — надо всё компилировать на нём. Если можно распределить компиляцию на оба устройства — надо параллелить.
Компиляция + деплой + отладка + запуск + логи посмотреть и т.д. Чем мощнее устройство, тем меньше смысла работать не на нём. Ну ещё зависит от того, насколько оно доступно, конечно. Если оно одно на большую команду (такое тоже бывает), то все работают у себя.
S>Если одно устройство обладает более отзывчивым/просторным/хорошим гуём, то редактировать код надо на нём. S>Потому что скорость разработки = скорости цикла "протестировал — исправил — скомпилировал". Соответственно, выбираем то, на котором эти шаги быстрее.
Можно по разному:
1. можно всё делать на нём;
2. можно редактировать по сети, но исходники и тулчен на устройстве;
3. можно всю сборку делать у себя, деплоить бинарники на девайс и там запускать тесты;
4. можно работать с эмулятором и совсем без устройства.
S>Здесь явно подразумевается, что приложения под ARM нужно и разрабатывать, сидя под ARM. И вы продолжаете агитировать в ту же сторону, хотя утверждаете, что вроде как нет.
И да, и нет. Если есть шанс разрабатывать на АРМ — прекрасно и великолепно, это самый простой путь и его лучше сделать.
Re[8]: Как Apple так быстро сделали Xcode для ARM? Сможет ли
Здравствуйте, CreatorCray, Вы писали:
P>>И вот в процессе выяснилось, что дотнетчик безо всяких фиксов спокойно пускал билды под wsl, и это работало. У меня же под линуксом дотнетая часть ну никак не собиралась, от слова совсем. Заработала только после того, как я вычистил вообще все пути CC>Мда, и опять выходит что винда лучше линух чем сам линух https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[5]: Как Apple так быстро сделали Xcode для ARM? Сможет ли MS?
Здравствуйте, Pauel, Вы писали:
P>С этим есть проблема в тестировании нативных приложений. Если вы пишете на другой платформе, то тестируете сильно опосредовано, через эмуляторы, точечными тестами итд.
Ес-но.
Еще удалённым дебаггером на девайсе, потребляющим минимум ресурсов.
Re[2]: Как Apple так быстро сделали Xcode для ARM? Сможет ли MS?
Здравствуйте, Serginio1, Вы писали:
P>>В удалённом отладчике никто не сидит 100% времени, а потому большинство проблем проходит мимо него S> Это как? Ты отлаживаешь ровно так же как на своем компе. Какие проблемы?
Проблема в том, что на удаленный комп вы заходите ничтожную часть времени, вы там не сидите 100% времени, не инсталируете всякий хлам.
У меня, например, сколько ни работал, удаленный комп работает как часы — там все чистенько, стерильно, быстро и аккуратно.
У типичного пользователя никогда не бывает чистой и стерильной ОС — она всегда забита разного рода дрянью, которая дает разные эффекты.
Хотите быть ближе к типичному пользователю — избегайте отладки в чистой и стерильной ОС.
S>Чем удаленная отладка по Tcp/IP сильно отличается от отладки на компе.
Вы вообще читаете? Я пишу про то, где должен работать разработчик основную часть времени, а не про протокол, отладчик или компилятор.
Re[11]: Как Apple так быстро сделали Xcode для ARM? Сможет л
Здравствуйте, Pauel, Вы писали:
P>Здравствуйте, Serginio1, Вы писали:
P>>>В удалённом отладчике никто не сидит 100% времени, а потому большинство проблем проходит мимо него S>> Это как? Ты отлаживаешь ровно так же как на своем компе. Какие проблемы?
P>Проблема в том, что на удаленный комп вы заходите ничтожную часть времени, вы там не сидите 100% времени, не инсталируете всякий хлам. P>У меня, например, сколько ни работал, удаленный комп работает как часы — там все чистенько, стерильно, быстро и аккуратно. P>У типичного пользователя никогда не бывает чистой и стерильной ОС — она всегда забита разного рода дрянью, которая дает разные эффекты. P>Хотите быть ближе к типичному пользователю — избегайте отладки в чистой и стерильной ОС.
Так используй рабочий комп. Обычно удаленная отладка используется для обнаружения проблем на удаленном компе.
Те же девайсы тоже рабочие, на которых возникают проблемы. S>>Чем удаленная отладка по Tcp/IP сильно отличается от отладки на компе.
P>Вы вообще читаете? Я пишу про то, где должен работать разработчик основную часть времени, а не про протокол, отладчик или компилятор.
У меня как раз удаленная отладка там где есть проблемы. Обычно и эмуляторов хватает.
И комп разработчика ооочень сильно отличается от рабочего варианта!
Опять же куча версий того же андроида, оборудования. Как и линукса.
На всех на них студию устанавливать?
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Shmj, Вы писали:
S>Вопрос такой.
S>Вроде Xcode — это гигант, даже судя по размеру бинарников. Как так быстро смогли перевести под ARM?
А ты уверен, что быстро? слухи о переходе появились в 2011 году. То бишь это заняло около 10 лет. А может и больше. Не очень-то быстро.
S>Ну и главное — сможет ли MS сделать так же со своей VS или там все намного хуже?
Всё упирается в деньги. Захотят инвестировать — смогут. Может уже и делают. Хотя у меня складывается впечатление, что MS инвестирует в VS Code, а старую студию выкинут в какой-то момент. Странно тянуть две IDE.
Здравствуйте, Shmj, Вы писали:
D>>А в чём проблема код на C собрать под другую платформу? S>Ну дьявол, как обычно, в деталях. Наверняка без ассемблерных вставок и пр. низкоуровневого не обошлось.
Ну, CreatorCray не расскажет потому что NDA, но даже если они там есть, то в чём проблема их переписать? Это всего лишь какое-то потраченное время на разработку.
Re[7]: Как Apple так быстро сделали Xcode для ARM? Сможет ли MS?
Здравствуйте, Pauel, Вы писали:
P>Если вы пользуетесь для своих целей, то это очень круто. Но вобщем большинство разработчиков так не делают — надеются на QA
Когда работал в компании с мобильным продуктом — делал. Мне до сих пор нотификации про новые сборки приходят
P>Пример — шрифты дрожат при drag&drop, и юзеры жалуются. А девелоперы сидят на другой платформе и с этим вообще не сталкиваются — у них графический стек работает иначе.
Повторю очевидное: девелоперы могут хоть обсидеться на "той платформе". Вопрос не в том, в чём они девелопят. Если это фотошоп — то шрифты в нём так и продолжат дрожать, т.к. в студии у них всё отлично.
P>Не только студию, а большие десктопные приложения или приложения требовательные к ресурсам.
Я по-прежнему не понимаю, чем фотошопу под АРМ поможет написание исходников фотошопа под АРМом. Или, скажем, CAD-системе. Оба — большие, ресурсоёмкие приложения. Ну и что?
P>Дело не в том, где вы студию запускаете, а где разработчик проводит бОльшую часть времени.
Ну да, в студии он его и проводит. А где ещё? Он же разработчик.
P>Я собственно про догфудинг если правильно этот термин понимаю, а не самого компилятора.
Ну так вот догфудинг строго ортогонален тому месту, где бегает студия. Догфудинг означает "самостоятельное использование продукта авторами этого продукта".
Например, парням из Microsoft было запрещено пользоваться Вебексом. Были обязаны проводить конференции только через Lync.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[11]: Как Apple так быстро сделали Xcode для ARM? Сможет ли MS?
Здравствуйте, Nuzhny, Вы писали: N>Студия — это у тебя профессиональная деформация. По факту, она не всегда и нужна. Но при необходимости, VS Code умеет быть установленным у разработчика и по ssh работать с удалённым устройством. То есть там нужен просто тулчейн.
Ну, и я примерно о том же.
N>Вот, я смотрю на твой путь примерно также: зачем тебе на одном компе агрегировать сразу всё? Я могу получить устройство от одного разработчика (физически или по сети), к нему логин/пароль и там уже будет установлен весь необходимый тулчейн и окружение. Сделаю свою часть, отлажусь, напишу тесты, проверю и отдам дальше.
Может у вас оно так и работает. Но это вы наверное просто заранее готовы прогнуться под любой тулчейн и окружение. А в моём мирке у разработчиков разные предпочтения. Один пользуется VS Code, другой VS Professional, третий всё пишет в vi, четвёртому жизнь не мила без Notepad++. И тут мы приносим устройство, на котором стоит что-то не то, к чему разработчик привык.
Вы, судя по всему, говорите об удалённой отладке — когда весь шелл стоит локально на машине, и, скажем, на stackoverflow пользователь ходит по привычным закладкам.
А то, с чем я спорил — это именно работа внутри студии на целевой машине. Которая, к примеру, может вообще наружу выхода не иметь, ибо зачем? И там даже на гитхаб сходить — уже проблема. Зато воспроизводится проблема, которую нужно проанализировать. Ну, вот как раз ssh и вперёд. Для него никакая студия на той стороне не нужна.
N>Компиляция + деплой + отладка + запуск + логи посмотреть и т.д. Чем мощнее устройство, тем меньше смысла работать не на нём. Ну ещё зависит от того, насколько оно доступно, конечно. Если оно одно на большую команду (такое тоже бывает), то все работают у себя.
N>Можно по разному: N>1. можно всё делать на нём; N>2. можно редактировать по сети, но исходники и тулчен на устройстве; N>3. можно всю сборку делать у себя, деплоить бинарники на девайс и там запускать тесты; N>4. можно работать с эмулятором и совсем без устройства.
S>>Здесь явно подразумевается, что приложения под ARM нужно и разрабатывать, сидя под ARM. И вы продолжаете агитировать в ту же сторону, хотя утверждаете, что вроде как нет.
N>И да, и нет. Если есть шанс разрабатывать на АРМ — прекрасно и великолепно, это самый простой путь и его лучше сделать.
Наверное, у меня мозг искажён мультиплатформенностью, в которой "приложений для ARM" не существует, а существуют продукты, которые должны работать на нескольких аппаратных платформах и под разными ОС.
Тогда прыгать между виндой/линуксом/ARM/Intel просто заради фана кажется неэффективным.
Если предстоит длинный проект, который ARM-only — то да, временно переехать на другую платформу будет оправдано, согласен.
Но это опять же при условии, что там есть всё, что нужно. А при отсутствии там, скажем, Visual Studio, можно продолжать работать по ssh.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re: Как Apple так быстро сделали Xcode для ARM? Сможет ли MS?
Подозреваю что, так как Apple изначально все было на powerpc и лишь потом они с большим успехом перешли на intel, то они спецы в процессах перехода с одной платформы на другую. Может архитектуру многоплатформенную еще тогда во все свои продукты заложили, может тупо записали все ходы. Поэтому переход на ARM по накатанной. А в микрософте intel поди гвоздями прибит в миллионах разных местах им известных и нет и поэтому никуда они не перейдут. Уже было пытались пару раз но что-то все заканчивалось провалами.
Re[2]: Как Apple так быстро сделали Xcode для ARM? Сможет ли
Здравствуйте, qqqqq, Вы писали:
Q>А в микрософте intel поди гвоздями прибит в миллионах разных местах им известных и нет и поэтому никуда они не перейдут.
?
какой-то бред, arm64 версия винды уже давно доступна. Да и вообще — HAL придумали именно в МС, когда у них была powerPc версия NT4 а это на секунду 1996й год
Q> Может архитектуру многоплатформенную еще тогда во все свои продукты заложили, может тупо записали все ходы
Да нет в юзермоде никакой архитектуры многоплатформенной. Вся архитектура — не писать на асме, а если уж захотелось пописать оптимизации ради местами — оставлять дефолтовые реализации на сишке. Но я очень сомневаюсь что в Xcode есть чтото, написанное на асме.
В остальном, в случае одинаковой endianess и битности платформ (а тут ниче не менялось), все просто компилируется в другой проц, после чего фиксятся сколлапсировавшие гейзенбаги и вуаля.
Q> А в микрософте intel поди гвоздями прибит в миллионах разных местах им известных и нет
Винда по многоплатформенности всегда была впереди планеты всей.
Как много веселых ребят, и все делают велосипед...
не договариваешь _>arm64 версия винды уже давно доступна
...и нахрен никому не нужна. Ты много устройств таких видал? В том то и дело что когда самый главный начальник в микрософте вызывает на ковер и говорит что за хрень? почему у компании Х есть такая вот вещь а у нас нет, то в дело бросются мульены, засучиваются рукава по локоть, таки выдают на гора аналог и отчитываются. Но оказывается что вещь не такая уж и вещь и все так и продолжают пользоваться Х.
Re[11]: Как Apple так быстро сделали Xcode для ARM? Сможет ли MS?
Здравствуйте, Nuzhny, Вы писали:
N>Студия — это у тебя профессиональная деформация. По факту, она не всегда и нужна.
После того как попользуешься профессиональным гайковёртом с регулируемым усилием как то совсем не хочется возвращаться к простому гаечному ключу без крайней на то нужды.
N>VS Code
ужасен
N>Я могу получить устройство от одного разработчика (физически или по сети), к нему логин/пароль и там уже будет установлен весь необходимый тулчейн и окружение.
Интересные у тебя устройства, на которых сразу и toolchain и окружение, и поди весь нужный SDK на гигабайты сразу тоже там лежит?
N>Компиляция + деплой + отладка + запуск + логи посмотреть и т.д. Чем мощнее устройство, тем меньше смысла работать не на нём.
Как правило у девелопера не то чтобы сильно более дохлая машина чтоб это имело совсем настолько существенную разницу.
Больше смысла работать на уже настроенном окружении, где всё что надо уже гарантированно есть.
Поэтому у меня нет разницы что я дебажу — новую beefy mac studio или старые часы с одним гигом памяти. Просто дебаг probe перетыкаешь в другой девайс и всё.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Re[9]: Как Apple так быстро сделали Xcode для ARM? Сможет ли
Здравствуйте, Pauel, Вы писали:
P>У Микрософта это традиция — приобщиться к конкурентам, и переделывать под себя.
И совершенно правильно делают между прочим
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Re[7]: Как Apple так быстро сделали Xcode для ARM? Сможет ли MS?
Здравствуйте, Pauel, Вы писали:
P>Пример — шрифты дрожат при drag&drop, и юзеры жалуются. А девелоперы сидят на другой платформе и с этим вообще не сталкиваются — у них графический стек работает иначе.
И как тебе тут поможет запуск студии на именно этой же машине?
P>Про догфудинг — проверял тушенку для кота на себе, жена не успевала покупать Ты зачем котэ объедаешь?
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Re[8]: Как Apple так быстро сделали Xcode для ARM? Сможет ли MS?
Здравствуйте, Sinclair, Вы писали:
S>Например, парням из Microsoft было запрещено пользоваться Вебексом. Были обязаны проводить конференции только через Lync.
Ох, соболезную им! Лютое говно этот Lync
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Re[9]: Как Apple так быстро сделали Xcode для ARM? Сможет ли MS?
Здравствуйте, CreatorCray, Вы писали:
CC>Ох, соболезную им! Лютое говно этот Lync
Подозреваю это старые сведения, Lync скорее всего уже похоронен и сейчас лютое говно это teams.
Re[4]: Как Apple так быстро сделали Xcode для ARM? Сможет ли
Здравствуйте, qqqqq, Вы писали:
Q>не договариваешь _>>arm64 версия винды уже давно доступна Q>...и нахрен никому не нужна. Ты много устройств таких видал? В том то и дело что когда самый главный начальник в микрософте вызывает на ковер и говорит что за хрень? почему у компании Х есть такая вот вещь а у нас нет, то в дело бросются мульены, засучиваются рукава по локоть, таки выдают на гора аналог и отчитываются. Но оказывается что вещь не такая уж и вещь и все так и продолжают пользоваться Х.
Если будут запускаться x86 приложения и будут выполняться с такой же скоростью как и на ч86, то мини-компы, ноутбуки и планшеты вполне могут и использоваться.
и солнце б утром не вставало, когда бы не было меня
Re[4]: Как Apple так быстро сделали Xcode для ARM? Сможет ли
Здравствуйте, qqqqq, Вы писали:
q> _>arm64 версия винды уже давно доступна
q> ...и нахрен никому не нужна. Ты много устройств таких видал?
Устройства появятся в середине этого года:
Первые устройства на Snapdragon X Elite появятся в середине 2024 года. Среди партнёров — Asus, Dell, HP, Honor, Lenovo, Microsoft Surface, Samsung и Xiaomi.
Здравствуйте, CreatorCray, Вы писали:
P>>У Микрософта это традиция — приобщиться к конкурентам, и переделывать под себя. CC>И совершенно правильно делают между прочим
Утопили браузер дважды, мобайл ось — трижды.
Re[5]: Как Apple так быстро сделали Xcode для ARM? Сможет ли
Здравствуйте, Serginio1, Вы писали:
S>Если будут запускаться x86 приложения и будут выполняться с такой же скоростью как и на x86
Вот только это "если" реализовать в железе и софте довольно нетривиально, особенно пункт про скорость.
Apple M в отличие от обычных ARM умеет избирательно включать memory ordering model как в x86, так что все гарантии остаются теми же, и потому достаточно отAOT/JITить код в другую архитектуру.
Так что без поддержки железом не обойтись.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Re[10]: Как Apple так быстро сделали Xcode для ARM? Сможет ли MS?
Здравствуйте, qqqqq, Вы писали:
CC>>Ох, соболезную им! Лютое говно этот Lync Q>Подозреваю это старые сведения, Lync скорее всего уже похоронен
Жил как говно и помер как говно (С)
Q> и сейчас лютое говно это teams.
+100500
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Re[4]: Как Apple так быстро сделали Xcode для ARM? Сможет ли
Здравствуйте, Dair, Вы писали:
D>Ну, CreatorCray не расскажет потому что NDA, но даже если они там есть, то в чём проблема их переписать? Это всего лишь какое-то потраченное время на разработку.
Вот даже проект на изначально задуманном как кросс-платформенный — на C# для .Net Framework — переписать на .Net Core — это уже куча работы. А тут голый C да еще и такого объема — неужели все прямо так легко?
Здравствуйте, CreatorCray, Вы писали:
S>>Если будут запускаться x86 приложения и будут выполняться с такой же скоростью как и на x86 CC>Вот только это "если" реализовать в железе и софте довольно нетривиально, особенно пункт про скорость. CC>Apple M в отличие от обычных ARM умеет избирательно включать memory ordering model как в x86, так что все гарантии остаются теми же, и потому достаточно отAOT/JITить код в другую архитектуру. CC>Так что без поддержки железом не обойтись.
Так для этого и делается Snapdragon X Elite Qualcomm с новым 64-битным процессором Snapdragon X Elite под ОС Windows легко обошла Intel и AMD
Приложение x86 (или x64) даже не знает, что оно работает на компьютере Windows на компьютере Arm, если он не вызывает определенные API (IsWoW64Process2).
Уровень WOW64 Windows позволяет выполнять код x86 в версии Arm64 Windows. Эмуляция x86 работает путем компиляции блоков инструкций x86 в инструкции Arm64 с оптимизацией для повышения производительности. Служба кэширует эти переведенные блоки кода, чтобы сократить затраты на перевод инструкций и разрешить оптимизацию при повторном запуске кода. Кэши создаются для каждого модуля, чтобы другие приложения могли использовать их при первом запуске.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, qqqqq, Вы писали:
Q>...и нахрен никому не нужна. Ты много устройств таких видал? В том то и дело что когда самый главный начальник в микрософте вызывает на ковер и говорит что за хрень? почему у компании Х есть такая вот вещь а у нас нет, то в дело бросются мульены, засучиваются рукава по локоть, таки выдают на гора аналог и отчитываются. Но оказывается что вещь не такая уж и вещь и все так и продолжают пользоваться Х.
феерический бред школьника
Re[3]: Как Apple так быстро сделали Xcode для ARM? Сможет ли MS?
Здравствуйте, Shmj, Вы писали:
D>>А в чём проблема код на C собрать под другую платформу?
S>Ну дьявол, как обычно, в деталях. Наверняка без ассемблерных вставок и пр. низкоуровневого не обошлось.
Ну да, операционку портировать на новый проц не проблема, а иде — ужос-ужос?
Re[8]: Как Apple так быстро сделали Xcode для ARM? Сможет ли MS?
Здравствуйте, CreatorCray, Вы писали:
P>>Пример — шрифты дрожат при drag&drop, и юзеры жалуются. А девелоперы сидят на другой платформе и с этим вообще не сталкиваются — у них графический стек работает иначе. CC>И как тебе тут поможет запуск студии на именно этой же машине?
Помогает не запуск студии, а повседневное использование конкретной платформы самим разработчиком. Чем больше вы используете платформу, тем лучше знаете её болячки.
Re[8]: Как Apple так быстро сделали Xcode для ARM? Сможет ли MS?
Здравствуйте, Sinclair, Вы писали:
P>>Пример — шрифты дрожат при drag&drop, и юзеры жалуются. А девелоперы сидят на другой платформе и с этим вообще не сталкиваются — у них графический стек работает иначе. S>Повторю очевидное: девелоперы могут хоть обсидеться на "той платформе". Вопрос не в том, в чём они девелопят. Если это фотошоп — то шрифты в нём так и продолжат дрожать, т.к. в студии у них всё отлично.
Если запускают приложение только под отладчиком, то конечно.
P>>Не только студию, а большие десктопные приложения или приложения требовательные к ресурсам. S>Я по-прежнему не понимаю, чем фотошопу под АРМ поможет написание исходников фотошопа под АРМом. Или, скажем, CAD-системе. Оба — большие, ресурсоёмкие приложения. Ну и что?
Девелоперы обычно хорошо знают болячки конкретной платформы, когда проводят в ней время не только отладку.
P>>Дело не в том, где вы студию запускаете, а где разработчик проводит бОльшую часть времени. S>Ну да, в студии он его и проводит. А где ещё? Он же разработчик.
Кроме студии есть еще куча софта. И домашнее использование тоже добавляет опыта.
S>Ну так вот догфудинг строго ортогонален тому месту, где бегает студия. Догфудинг означает "самостоятельное использование продукта авторами этого продукта". S>Например, парням из Microsoft было запрещено пользоваться Вебексом. Были обязаны проводить конференции только через Lync.
Хорошее правило.
Re[9]: Как Apple так быстро сделали Xcode для ARM? Сможет ли MS?
Здравствуйте, Pauel, Вы писали: P>Помогает не запуск студии, а повседневное использование конкретной платформы самим разработчиком. Чем больше вы используете платформу, тем лучше знаете её болячки.
Болячки платформы — это болячки платформы. На качество приложения влияют болячки приложения.
Грубо говоря, если у вас приложение — это HFT, то косяки растеризации шрифтов вам по барабану. А если приложение — это какой-нибудь "расчёт воздуховодов", то вам наплевать на косяки с порядком вызова IO Completion.
Тем более, что сейчас мы говорим не про ОС, где прямо окружение совсем-совсем разное; а про хардвару. Дрожание шрифтов там может возникнуть только по вине кривого драйвера, и в приложении его не починишь. Весь user level же будет одинаковым.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[5]: Как Apple так быстро сделали Xcode для ARM? Сможет ли
Здравствуйте, Shmj, Вы писали:
D>>Ну, CreatorCray не расскажет потому что NDA, но даже если они там есть, то в чём проблема их переписать? Это всего лишь какое-то потраченное время на разработку.
S>Вот даже проект на изначально задуманном как кросс-платформенный — на C# для .Net Framework — переписать на .Net Core — это уже куча работы. А тут голый C да еще и такого объема — неужели все прямо так легко?
Я не писал на C# столько чтобы чувствовать различия между исходным .NET и .NET Core, сказать не могу.
Но я привык что под какую-то процессорную архитектуру или сделали компилятор С (gcc, clang или ещё какой), или пока ещё не сделали. Если сделали — им компилируется компилятор C++ (g++, clang++, ещё какой) и дальше компилируется вообще всё.
Да, выше шага 1, т.е., компилятора С, существуют платформеннозависимые ассемблерные части, которые оптимизируют ту или иную работу под конкретной платформой. Иногда (не всегда) её можно переписать на С с потерей производительности, но и ладно на первых-то порах.
Я наблюдал процесс, следя за тем что происходит вокруг Эльбруса (RIP) — сначала собрали gcc (долго делали, но это вопрос денег), потом собрали g++ (примерно полгода), дальше всё взлетело само.
Re[6]: Как Apple так быстро сделали Xcode для ARM? Сможет ли
Microsoft выбрала Qualcomm в качестве партнёра и производителя Arm-процессоров для устройств с Windows в 2016 году. С тех пор Qualcomm является единственной компанией, выпускающей процессоры на базе архитектуры Arm для устройств с Windows. Информация о подписании эксклюзивного соглашения никогда не озвучивалась официальными лицами, но с течением времени этот факт стал очевидным, поскольку Qualcomm оставалась единственной компанией, выпускающей Arm-чипы для ноутбуков, все восемь лет с момента объявления о партнёрстве с Microsoft.
Ходили разные слухи касательно того, на какой период было подписано эксклюзивное соглашение между Microsoft и Qualcomm. Теперь же Рене Хаас стал первым официальным лицом, фактически подтвердившим, что срок действия договора истечёт в этом году «Я думаю, хорошо задокументировано, что эксклюзивность, которую Qualcomm имеет с Windows, заканчивается, я думаю, в этом году», — сказал Хаас в недавнем интервью для Stratecherry.
Хотя Хаас не стал открыто заявлять о завершении действия партнёрского соглашения в этом году, вероятно, он не стал бы упоминать это, не имея достоверной информации. Поскольку он является гендиректором Arm, его заявление следует воспринимать как достоверное. Точная дата прекращения действия договора между Microsoft и Qualcomm продолжает оставаться неизвестной, но, вероятно, соглашение потеряет силу к началу 2025 года.
Потеря эксклюзивности чипов Qualcomm означает, что другие компании смогут производить Arm-процессоры для ноутбуков с Windows. Ранее агентство Reuters писало, что выпускать Arm-чипы планируют AMD и NVIDIA.
и солнце б утром не вставало, когда бы не было меня
Re[7]: Как Apple так быстро сделали Xcode для ARM? Сможет ли
S>Приложение x86 (или x64) даже не знает, что оно работает на компьютере Windows на компьютере Arm, если он не вызывает определенные API (IsWoW64Process2).
S>Уровень WOW64 Windows позволяет выполнять код x86 в версии Arm64 Windows. Эмуляция x86 работает путем компиляции блоков инструкций x86 в инструкции Arm64 с оптимизацией для повышения производительности. Служба кэширует эти переведенные блоки кода, чтобы сократить затраты на перевод инструкций и разрешить оптимизацию при повторном запуске кода. Кэши создаются для каждого модуля, чтобы другие приложения могли использовать их при первом запуске.
Содрали с Rosetta
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Re[9]: Как Apple так быстро сделали Xcode для ARM? Сможет ли MS?
Здравствуйте, Pauel, Вы писали:
P>Помогает не запуск студии, а повседневное использование конкретной платформы самим разработчиком. P> Чем больше вы используете платформу, тем лучше знаете её болячки.
Не обязательно жрать кактус каждый день чтоб знать что он колется. Достаточно знать область в которой работает отлаживаемый софт, а тратить время на героическое преодоление всего остального геморроя совершенно контрпродуктивно.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Re[8]: Как Apple так быстро сделали Xcode для ARM? Сможет ли
Здравствуйте, CreatorCray, Вы писали:
CC> S>Уровень WOW64 Windows позволяет выполнять код x86 в версии Arm64 Windows. Эмуляция x86 работает путем компиляции блоков инструкций x86 в инструкции Arm64 с оптимизацией для повышения производительности. Служба кэширует эти переведенные блоки кода, чтобы сократить затраты на перевод инструкций и разрешить оптимизацию при повторном запуске кода. Кэши создаются для каждого модуля, чтобы другие приложения могли использовать их при первом запуске. CC> S>
CC> Содрали с Rosetta
Да прям... Будто у них своего нгена для этих их дотнетов небыло.
Здравствуйте, CreatorCray, Вы писали:
P>>Помогает не запуск студии, а повседневное использование конкретной платформы самим разработчиком. P>> Чем больше вы используете платформу, тем лучше знаете её болячки. CC>Не обязательно жрать кактус каждый день чтоб знать что он колется. Достаточно знать область в которой работает отлаживаемый софт, а тратить время на героическое преодоление всего остального геморроя совершенно контрпродуктивно.
Недостаточно. Всё взаимодействие вашего софта с системой определяется в основном системой. И тут чем лучше вы знаете эту систему с разных сторон, тем легче будет находить, воспроизводить и фиксить проблемы.
Скажем, для большинства разработчиков профессионального софта догфудинг как его описывает Синклер неприменим. Сильно вряд ли разработчики будут использовать сапр для оптических или беспроводных сетей для своих целей.
А раз так, то остаётся та самая платформа.
Re: x86 Emulation on Arm CPUs - Better on Windows or macOS?
yadda yadda, tested with my own software который я есессна не покажу чтоб вы сами не попытались эти результаты повторить.
На чужом (а потому доступном другим людям для самостоятельно проверки) коде результат получился наоборот.
Garbage in — garbage out.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Re[2]: x86 Emulation on Arm CPUs - Better on Windows or macOS?
Здравствуйте, CreatorCray, Вы писали: S>>https://www.youtube.com/watch?v=uY-tMBk9Vx4
CC>yadda yadda, tested with my own software который я есессна не покажу чтоб вы сами не попытались эти результаты повторить. CC>На чужом (а потому доступном другим людям для самостоятельно проверки) коде результат получился наоборот. CC>Garbage in — garbage out.
Проверишь через пол года. Пока есть такие данные. Это все лучше, чем ничего. А за полгода многое может измениться как плохую, так и в хорошую сторону.
и солнце б утром не вставало, когда бы не было меня
Re: Как Apple так быстро сделали Xcode для ARM? Сможет ли MS
Для установки на Windows 11 доступен полностью встроенный в Arm набор средств разработчика, в том числе:
Visual Studio 2022 17.4 для Arm64Это первая собственная версия Visual Studio для Arm64, доступная с рабочими нагрузками, включенными для разработки классических приложений на C++ (для проектов на основе MSBuild), разработки классических приложений .NET, веб-разработки, разработки игр и разработки Node.js, а также включает поддержку windows SDK и компонентов Win App SDK (Win UI).
Пакет SDK arm64 для .NET 7Встроенная поддержка Arm64 доступна начиная с .NET 6, а также среды выполнения платформа .NET Framework 4.8.1 и пакета SDK, и эта поддержка была расширена в .NET 7. Узнайте больше об улучшениях производительности Arm64 в .NET 7.
Visual Studio Code для ArmVS Code поддерживает архитектуру Arm64 с выпуска 1.50 за сентябрь 2020 г., включая расширения для удаленной разработки.
Также доступна поддержка создания приложений на основе Arm и переноса существующих приложений x64, в том числе:
Arm64ECArm64EC («Совместим с эмуляцией») — это новый двоичный интерфейс приложения (ABI), позволяющий создавать новые собственные приложения или постепенно переходить к существующим приложениям x64, чтобы воспользоваться преимуществами собственной скорости и производительности, которые можно использовать на устройствах с питанием Arm, включая более высокую энергопотребление, время работы батареи и ускоренные рабочие нагрузки машинного обучения ИИ & .
Arm64XArm64X — это новый тип двоичного кода, который может содержать как классический код Arm64, так и код Arm64EC, что делает его особенно подходящим для ПО промежуточного слоя или подключаемых модулей, которые могут использоваться обоими API.
К дополнительным средствам разработчика, поддерживаемым Windows 11 в Arm, относятся:
Подсистема Windows для LinuxВключение установки дистрибутивов Linux в Windows без дополнительных затрат на традиционную виртуальную машину или установку с двойной загрузкой.
Терминал WindowsСовременный способ параллельного выполнения нескольких командных строк на вкладках или панелях, полностью настраиваемый с помощью обработчика отрисовки текста с ускорением GPU и палитры команд.
Диспетчер пакетов WindowsКомплексное решение диспетчера пакетов, состоящее из программы командной строки (winget) и набора служб для установки приложений, которые будут выбирать оптимальный доступный пакет в зависимости от архитектуры оборудования.
Microsoft PowerToysНабор служебных программ для опытных пользователей для настройки и оптимизации работы с Windows для повышения производительности, включая диспетчер окон FancyZones, диспетчер клавиатуры, служебные программы мыши, PowerRename и многое другое.
Подсистема Windows для AndroidВключение Windows 11 для запуска приложений Android, доступных в Amazon Appstore.
Также на этой странице можно посмотреть видео от Microsoft, в котором рассматриваются различные сценарии использования Dev Kit 2023 для разработки приложений.
Наконец, если говорить про использование Project Volterra в быту, то в принципе это возможно. В отличие от предыдущих устройств с Windows на ARM, Dev Kit легко справляется с огромным количество вкладок браузера, перемещениями файлов, подключением дисков и так далее.
Еще стоит отметить, что Microsoft качественно улучшил работу WOW64 — слоя-переводчика приложений с х86-64 на ARM, так что в целом неоптимизированные приложения будут запускаться на Project Volterra. Но не всегда хорошо и далеко не все. Проверить, в каком формате работает та или иная программа, можно через диспетчер задач.
и солнце б утром не вставало, когда бы не было меня
Ты зачем котэ объедаешь?
