Ждём Ваших отзывов о материале.

Соблюдение Правил конференции строго обязательно!
Флуд, флейм и оффтоп преследуются по всей строгости закона!
За статью можно проголосовать на странице материала.

Про мало софта не уловил.
repo sync
make && make install же! И весь софт вот он.

Ну да, а портироваться под особенности архитектуры оно будет по щучьему велению??? Поищите хотя бы, как переезжали с PowerPC на Intel маковские приложения, с учётом Universal Binary - формата.

Особенности архитектуры помещаются в нескольких библиотеках, которые линкуются после компиляции.

Тогда поясните мне, сущеглупому, чего ж адобе фотожоп перетаскивал такую уйму времени? AFAIK у них с той версии, которая была чисто под PPC, до UniBin, ещё 1 промежуточная появилась.

Некоторые умы видимо не знают, что переезд на новую архитектуру - это иногда достаточно тяжеловесное занятие.
Если не учитывать особенности архитектуры - то приложение будет работать по меньшей мере медленно. Основное достоинство ARMv8, я считаю, - это наличие 31-го незанятого регистра общего назначения. В предыдущих версиях регистров тоже было 31, но большая часть регистров были либо не доступны либо уже заняты под определенные нужды. В итоге коду функции оставалось около 6-ти регистров - ненамного больше, чем в x86 архитектуре. В ARMv8 на регистры общего назначения уже не накладываются эти ограничения.
Поэтому в ARMv8 станут за счет освободивших регистров станут доступны методы оптимизации, которые используются в DSP процессорах. И после правильной оптимизации программы написанные на этих зверьках будут рвать x86 как тузик грелку.

Вы когда последний раз книжку по асму х86 открывали, во времена dos-a и 8086? Ознакомьтесь с современными прцессорами, и их регистрами.

communyaka, Genry, то, что программа типа "Hello, World!" портируется в пару кликов, вовсе не означает, что так происходит со всеми приложениями. и чем приложение сложнее - тем больше времени и сил оно потребует для "переезда" и оптимизации.

И не забывайте, что речь идёт о серверном сегменте, и если горе-программист считает нормальным, что запрос к серверу обрабатывается на 0,1с дольше или занимает на 1Мб ОЗУ больше чем на старой платформе, то это означает лишь одно - работать этому программисту осталось недолго.

0xffffh
Речь идет о регистрах общего назначения, а не о векторной надстройке.

Если приложение использует CUDA а не OpenCL, то это грабли на которые попали программисты этого приложения. Тут возможности простого переезда на ARM нет. И таких проприетарных "чудиков" масса.

Скажите пожалуйста, почему сам концерн ARM не закажет, или хотя бы не проспонсирует, от части, написание самого необходимого софта ? Давно бесит ситуация со 100 летним SuperPi, на месте маркетологов AMD давно заказали бы супер оптимизированную версию под ATHLON-PHENOM архитектуру, однопоточную канэчно )

Имхо современная ИТ индустия уже совсем обленилась и потеряла совесть. Если они планируют захватывать рынок по сабжу - первое: пишется ПО по сабжу с учётом АРМ архитектуры. Второе: создаётся проц, исходя из потребностей ПО. Третье: ПО шлифуется на инжинерных семплах проца (оптимизация и дебаггинг). Если из этого списка выкинуть любой этап - будет дико нерациональный расход бюджета, электричества и процессорного времени.