[Apple][ARM]Скоро

> Я ошибаюсь, или оно без поддержки lossless? Если да, то не нужно. Во-вторых, я нигде не нашел сколько он работает от батареи. В третьих, габариты у него как для плеера великоваты.

Ищи. Lossless есть на многих девайсах, иногда правда официально не заявлен ибо 90% (включая меня) он нах не вперся, ибо не аудиофилы. Шум улицы тебе все равно кошерность звука подпортит.

Эппл в этом плане вперде планеты всей. Арм не годится из-за его производительности. И дело не в количестве тактов каких-то конкретных процессоров, а в отсутствии у арма множества наборов инструкций, широко применяемых для оптимизации.

Ну ну. Для оптимизации чего? Сто лет уже все кодеки есть в виде аппаратных блоков. Либо гоняются на специальных DSP копроцессоров. И как показывает практика это заруливает и по размеру на кристалле и по потреблению решения в x86.

>а в отсутствии у арма множества наборов инструкций, широко применяемых для оптимизации.
Как интересно!
А поподробнее нельзя?

> Ищи. Lossless есть на многих девайсах, иногда правда официально не заявлен ибо 90% (включая меня) он нах не вперся, ибо не аудиофилы. Шум улицы тебе все равно кошерность звука подпортит.

Возникает вполне логичный вопрос: а зачем тогда огромный HDD, если записывать на него только mp3? //Таки-да, я аудиофил, и слушаю плеер не только на шумных улицах.

Ну ну. Для оптимизации чего? Сто лет уже все кодеки есть в виде аппаратных блоков.

Ну конечно, для человека, у которого нагрузки на ЦП ассоциируются только с мультимедиа, Это аргумент.

Начнем хотя бы с FPU... продолжим SSE и строковыми операциями. (Неон частично заменяет SSE, но не везде есть).

Universalbinary только забыть успели

так до сих пор же есть возможность упаковать x86 и amd64 в один бинарь.

> Начнем хотя бы с FPU...

-mfpu=vfp (Либо vfp3 на более свежих армах)

продолжим SSE и строковыми операциями. (Неон частично заменяет SSE, но не везде есть).

Я юы сказал так: Уже есть неон который успешно заменяет многое из SSE, и на этом я думаю ближайшие годы не остановятся. Да и главный тут козырь время автономки, по которому х86 сливает, несмотря на все усилия. *cюда воткнуть время автономной работы телефона на базе интел атом и еще немного троллинга.*

> Возникает вполне логичный вопрос: а зачем тогда огромный HDD, если записывать на него только mp3? //Таки-да, я аудиофил, и слушаю плеер не только на шумных улицах.

Тоже логичный вопрос, ибо мне 8ми гигов SD хватает, а веник таки раздалбывается быстро в дороге да в кармане.

Ну конечно, для человека, у которого нагрузки на ЦП ассоциируются только с мультимедиа, Это аргумент.

Опять таки, смотря для чего делать чип. На арме чаще делают специализированные решения под задачу, нежели general purpose. А уж если сильно хочется SIMD - милости просим, берем интерфейс копроцессора арма и ваяем. насколько помню, арм может содержать до 16ти копроцессоров расширяющих инстракшн сет.

Хм, Apple использует видеокарты как раз AMD. В чем печаль?

печаль для AMD и кстати линукс (линукс сливает ещё одну нишу, и всё по той же причине что слиты нетбуки на x86). с нвидиевской графикой (платформой) ARM процессоры не требуют больших частот самого процессора. сначала Microsoft с Windows 8 для ARM, теперь Apple. а что предложит AMD? Intel вот может по заказу печатать ARM процессоры, а AMD то даже фабрики свои продала.

вот сейчас в журналы пихают видеорекламу с 4" экраном (там проц Ingenic JZ4725B 360Mhz который MIPS). вот там ось совершенно не линукс. вот ещё печаль, причина слива всё та-же.

:)
Вы можете обосновать необходимость «строковых операций» в RISKпроцессорах?

> Да и главный тут козырь время автономки, по которому х86 сливает, несмотря на все усилия.

Для десктопов и серверов время автономки не существует как понятие. При питании от сети плюс-минус 20 ватт не играют никакой роли. Еще во многих случаях ноутбук используют как десктоп, способный выдержать час-другой без внешнего питания. В этих случаях у арма преимуществ - ноль на массу.

Что касается винарности арма на мобильных девайсах - то тут факты говорят сами за себя. Но из нее не следует винарность на всем остальном. Еще раз повторяю, сейчас x86-рип означает серверо-десктопо-рип. Портативные рабочие станции идут туда же.

> На арме чаще делают специализированные решения под задачу

Ок, если ставить его в буки, под что предлагаете его специализировать?

арм может содержать до 16ти копроцессоров расширяющих инстракшн сет.

Ага, и жрать электроенергию как x86-решения. Или вы считаете, что штеуд безнадежно отстал технологически, и высокое энергопотребление его процессоров вызвано не только количеством интракшен сетов?

ДА ну, ты просто не Ъ маковод. У тех нет таких проблем

Вы можете обосновать необходимость и достаточность RISK-онли процессоров в коме?

> Ага, и жрать электроенергию как x86-решения. Или вы считаете, что штеуд безнадежно отстал технологически, и высокое энергопотребление его процессоров вызвано не только количеством интракшен сетов?

Нет, у штеуда с технологическим процессом все очень и очень хорошо, все это знают. Но вот атом как был тормозным кипятильником, так им пока и остается. Я повторюсь, я не говорю о том, что х86 закопать надо прямо сейчас. Но тенденция есть, и у арма все шансы в скором времени обрасти расширениями и таки закопать х86. Если конечно эппл окончательно не купит арм и не сделает его эксклюзивной архитектурой для своих поделок. (ходили вроде слухи).
В таком случае надежда на Microsoft Research которые к MIPS'у присобачивали динамически подгружаемые расширения.

> Вы можете обосновать необходимость и достаточность RISK-онли процессоров в коме?

К слову сказать, очень большое количество CISC'ов, это аппаратный транслятор в инструкции внутреннего RISC ядра. Это так, для галочки.

Тем не менее, работает он в разы быстрее программных «трансляторов».

> Но тенденция есть, и у арма все шансы в скором времени обрасти расширениями и таки закопать х86.

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

Да, сравнимо как если бы софт компилили под внутренний RISC, только ест больше.

o'rly? И почему-то я не совсем уверен в получении такого же кипятильника, при обрастании расширениями. Особенно учитывая, что половина из них в 90% случаях нафиг не вперлась.
Так или иначе, боюсь тут остается запасаться попкорном и ждать что будет. Ключей от машины времени у меня нет.

Кстати насколько больше легко посчитать. Транслятор работает с частотой ядра, значит надо только оценить количество вентилей, которые потребует транслятор, и посмотреть в справку по тех процессу. Кстати из-за того, что частота транслятора должна быть равна частоте ядра, цифиря довольно таки большая получается.

Почему же? Derbian armel, Ubuntu armel есть, Gentoo тоже.

> Особенно учитывая, что половина из них в 90% случаях нафиг не вперлась.

Я и не спорю, но в оставшихся 10% случаях их будет сильно не хватать. Для мобилки, планшета такое урезание оправдано, а вот уже для ноутбука - сомнительно.

Да и сами расширения, не входящие в основную спецификацию ПЦ - та еще морока. Производители софта плачут от осознания размеров зоопарка одного андроида, а если такое же разнообразие возникнет на уровне ЦП... то портирование вин-софта на линукс покажется вам малиной. Лично мне хватает всяких ifdef(ARM_NEON_AVAILIBLE) в коде.

>>> Почему же? Derbian armel, Ubuntu armel есть, Gentoo тоже.

Армовские поделки все подряд огороженые.