Microsoft подтвердила работу над 64-разрядной Windows 10 Mobile

Рискну предположить, что следующая версия будет несовместима вообще со всеми видами устройств.

Singularity писал:
Рискну предположить, что следующая версия будет несовместима вообще со всеми видами устройств.

Почему это? ARM-процессоры уже имеют поддержку разрядности х64. А уж про х86-х64 я молчу.

Uleaned, потому что винда никогда не обновлялась с x86 до x64.

Singularity писал:
Uleaned, потому что винда никогда не обновлялась с x86 до x64.

Значит, найдут способ обновить Приложения ведь могут работать в режиме совместимости

Wusa, uwp приложения и так успешно работают на любой платформе, единственное что нужно будет это переустановить (перекомпилировать в .Net Native) их из магазина, что и так происходит после обновления сборки. Но зачем, если ни одно устройство на WP не может похвастаться 4+ ГБ оперативы. 

Когда то и не каждый настольный компьютер мог похвастаться даже гигом оперативки. Видимо история пойдёт по кругу. Появится поколение мобильных аппаратов, для которых и 4 Гб будет самой заурядной нижней планкой.

a666s писал:
для которых и 4 Гб будет самой заурядной нижней планкой

А смысл? Абсолютное большинство телефонных/UWP приложений - тупая клиентская оболочка к API какого-нибудь веб-сервиса. Если бы их умели писать, то могли бы и в единицы-десятки килобайт запросто укладываться.

 На ПК рост памяти и переход на x64 в основном происходил из-за игровой 3D-графики. Крайне упрощенная арифметика: 1 кадр разрешением 1920х1080 занимает в видеопамяти ~6MB, умножаем на 30-60 fps = постоянный поток в 180-320MB/sec, которые надо сначала приготовить из нехилого кол-ва мега/гигабайт 3D-моделей, текстур и шейдеров, разбавленных скриптами и предварительно загруженных в быстрое ОЗУ с тормозного винта.
Но на смартфонных 5-7" качество картинки (и ресурсов из которых она готовится) легко снижается без всякого ущерба до такого видимого состояния, при котором на 19" мониторе в лучшем случае плеваться будут. Да и медленного винта в смартах нет и не будет, а быстрое чтение с SSD вполне возможно избавит от старой ПКашной нужды в огромном количестве буферной памяти.

wbnet, это задел на будущее, когда вообще не придется для смартфонов писать какие-то свои версии - перерисовал интерфейс под меньшее разрешение и все. Или как МС предлагает, подключать смартфон к монитору и использовать приложения с полным разрешением.

Собственно, архитектура x64 появилась как результат некоторой задержки в развитии технологий(не могли делать транзисторы еще меньше), что вынудило отойти от обычной архитектуры x86.

ceu160193, играть с телефона на мониторе в 3D - это только если маркетологи из МС поднатужатся и выпучат глаза еще сильнее, чем при выпуске 10. Для передачи 2D-картинки с телефона на монитор за глаза хватит и x32, мобильные видяхи даже близко не подошли к десктопным по возможностям, чтобы им не хватало системной памяти.
Про транзисторы совсем не понял. При чем они тут?
64 битная архитектура давным-давно появилась и стала более-менее известна с 1995 года, после выпуска относительно недорогих DEC Alpha. Все это время была востребована, в основном, у профи делавших 3D-контент (а-ля Pixar). Просто потому, что при фотореалистичном рендере одного статичного кадра разрешением 1024x768 не очень сложной 3D сцены, можно легко выползти за пределы 32 гигов (балуюсь порой "для себя").
Интел с АМД уже вторичны - появилась нужда в обработке BigData на серверах, ну и подсуетились они под клиентом. Попутно решив некоторые проблемы с отрисовкой псевдореалистичной 3D-графики на ширпотребных ПК. А MS тут и клиент, и исполнитель в одном лице. Если опустить серверную часть, то в два стандартных гигабайта, выделяемых х86 виндой юзеру, перестали помещаться текстуры и прочие игровые ресурсы. Правда в некоторых играх. Абсолютному большинству остальных десктопных игр (не говоря уже про мобильные) вполне хватает этих двух гигов.

Wusa писал:
Значит, найдут способ обновить Приложения ведь могут работать в режиме совместимости

Я один раз видел, как работает x64 винда на 1 Гб ОЗУ. Этот единственный гиг занимает загруженная в память операционка, остальное свопится и тормозит безбожно.
Я рекомендую включить режим разработчика на WP10 и подключиться удаленно, через http к телефону. Ты увидишь, как прожорлива десятка, когда одно открытие приложения грузит проц на 100%.

wbnet, насколько я знаю, до 64-битной архитектуры были костыли, позволявшие использовать память больше 4 гигабайт, вроде использования 36-разрядной адресации. В серверных версиях Windows эти костыли работали исправно, а на клиентских системах, из-за большего разнообразия драйверов, решили подстраховаться и отключить их. Предел для таких костылей - примерно 64 гигабайта.

По поводу того, при чем тут транзисторы - закон Мура начал давать сбои, и стали искать иные пути. 64 бита дают прирост производительности? Дают, хоть и не всегда сильно заметный. Частоту нужно повышать? Нет. Просто мечта - лишняя производительность без кардинальных перемен конструкции процессора. А если еще и совместимо с старыми программами, то вообще красота. Впоследствии многоядерность появилась по подобной же причине - уперлись на тот момент в ограничение по частоте одного ядра.

На всякий случай уточню - 64-битной архитектура становится, когда все команды имеет такой или больший размер. Иначе сейчас у нас уже давно 128-битная архитектура используется. 

ceu160193, между прочим, 64 бита в абсолютном большинстве случаев замедляют работу ПО, а вовсе не ускоряют. При этом увеличивают его объем. Основной профит с разработки получался в изменении адресации памяти и ускорении работы сверхбольших БД, без применения AWE или PAE, которые сильно ограничивали производительность. Ну и  графические станции попутно получили то, что для них очень сильно хотели. Неудивительно что первое ПО, которое сразу же начали переводить на 64 бита - Oracle, MS SQL, различные CAD/3D/видео-фото редакторы - в общем все, кто постоянно работал с пакетами данных, не вмещавшимися в 4 гигабайта ОЗУ. В тогдашних играх эти плюшки с памятью не нужны были от слова "совсем", так как игровые видеокарты просто не смогли бы переваривать подобные объемы. Да и сейчас игр, которым кровь из носу надо x64 и более 4 гигов памяти, единицы. ОК, пускай даже десятки, но уж точно не сотни. А ведь уже почти 15 лет прошло.

К 2003му, когда начали выпускать "х86-64" (внезапно, первым был серверный Оптерон), вопрос о ограничениях закона Мура вообще не отсвечивал,  наоборот были весьма радужные настроения и насчет распараллеливания потоков по куче ядер, и насчет повышения частот до цифр в десятки гигагерц. Это уж потом по ходу дела выяснилось и про плохое распараллеливание, и про "а как эти реакторы охлаждать будем?" В общем х64 на ПК - внебрачный ребенок серверов и баз данных, дешевле было эту развивающуюся архитектуру (а у её основных заказчиков - большие кучи бабла) использовать также и на ПК, чем продолжать пилить отдельную х32 ветку для  маленьких домохозяйств.

И вот смысл это на мобилы притаскивать? Oracle Database Mobile будем там запускать? Или расчет на нынешних г-девелоперов мобильных приложений, которые легко засрут всю доступную память и обязательно начнут кого-то другого в этом винить?

wbnet, скорее второе - расчет на нынешних разработчиков и нынешние языки программирования, где утечки памяти часто замаскированы.

Первая попытка распараллеливания была предпринята с появлением Itanium, но из-за сложностей в компиляции и фиговой обратной совместимости (программная эмуляция x86, мягко говоря, тормозит в сравнении с аппаратной у x86-64) не взлетело.

Про замедление - если переносить алгоритм с x86, замедление неизбежно, так как теперь у программы другие узкие места. Чтобы действительно производительность повышалась, надо сразу начинать с x64, только вот кто решится переписывать с нуля готовый продукт?