Комментарии 45
Эх, автор-автор, я прямо спрошу:
— Что-нибудь кроме википедии читал по этой теме? У тебя в тексте полное отсутствие понимания плюсов и минусов RISC vs CISC, SoC vs CPU. Количество модулей в чипе совершенно не относится к тому, ARM это или не ARM. В тот же SoC для компактного девайса можно поставить i186 (что Phillips, например, и делает), и это будет и CPU, и периферия, и DMA в одном чипе.
— Сам пишешь на asm для ARM? Вот ты пишешь, что плюсы у ARM — простые команды. А ты не мерил, сколько получается простых команд, чтобы выполнить более-менее сложную операцию? Вот на примере аппаратно-реализованного деления — пока ARM будет считать результат и жрать батарею, CISC уже давно его выполнит и отключит питание блока. В тех же ULW-процессорах для портативных девайсов инструкции более длинные и супер-сложные, а кушает еще меньше, чем просто CISC.
Темасисек не раскрыта.
— Что-нибудь кроме википедии читал по этой теме? У тебя в тексте полное отсутствие понимания плюсов и минусов RISC vs CISC, SoC vs CPU. Количество модулей в чипе совершенно не относится к тому, ARM это или не ARM. В тот же SoC для компактного девайса можно поставить i186 (что Phillips, например, и делает), и это будет и CPU, и периферия, и DMA в одном чипе.
— Сам пишешь на asm для ARM? Вот ты пишешь, что плюсы у ARM — простые команды. А ты не мерил, сколько получается простых команд, чтобы выполнить более-менее сложную операцию? Вот на примере аппаратно-реализованного деления — пока ARM будет считать результат и жрать батарею, CISC уже давно его выполнит и отключит питание блока. В тех же ULW-процессорах для портативных девайсов инструкции более длинные и супер-сложные, а кушает еще меньше, чем просто CISC.
Тема
>Что-нибудь кроме википедии читал по этой теме?
Да, читал, но небуду спорить что я бы хотел прочесть ещё гораздо больше =).
>Сам пишешь на asm для ARM?
Нет, пока только под x86, да и то не очень много, хотя в планах на будующее и такое есть.
>А ты не мерил, сколько получается простых команд, чтобы выполнить более-менее сложную операцию?
Да, много, но не забывай что в RISC архитектурах они выполняются быстрее
Да, читал, но небуду спорить что я бы хотел прочесть ещё гораздо больше =).
>Сам пишешь на asm для ARM?
Нет, пока только под x86, да и то не очень много, хотя в планах на будующее и такое есть.
>А ты не мерил, сколько получается простых команд, чтобы выполнить более-менее сложную операцию?
Да, много, но не забывай что в RISC архитектурах они выполняются быстрее
тут были? если отделить зерна от плевел, будет много интересного.
x86 против arm, power, sparc, gpu, cell и других
Процессоры Atom. кому они нужны?
но мало что заменит собственный опыт разработки под конкретную архитектуру.
x86 против arm, power, sparc, gpu, cell и других
Процессоры Atom. кому они нужны?
но мало что заменит собственный опыт разработки под конкретную архитектуру.
Откуда такой странный факт про деление? Во-первых, деления бывают разные и компиляторы умеют их неплохо оптимизировать. Во-вторых, когда оптимизировать ничего не получается, то делить приходится просто столбиком, а это линейный и непараллелящийся алгоритм. Поэтому, особой разницы нет: проведёте вы 16 тактов внутри FU, инициировав процесс одной инструкцией, или это будет 16 выполнений однотактовых инструкций — скорость особо не изменится.
С длинной инструкций тоже странная у вас логика. У ARM инструкции длиннее, чем у x86, поэтому (по количеству) их и требуется, зачастую меньше для получения неких результатов, кроме того, они сложнее, чем инструкции x86, поэтому электронику их исполняющую, можно сделать проще (много информации уже содержится в коде). В статье же не написано, что команды проще, а написано, что набор этих команд меньше.
Другое дело, что в CISC есть простые команды, активирующие сложную электронику, вроде вычисления всяких sin/cos.
С длинной инструкций тоже странная у вас логика. У ARM инструкции длиннее, чем у x86, поэтому (по количеству) их и требуется, зачастую меньше для получения неких результатов, кроме того, они сложнее, чем инструкции x86, поэтому электронику их исполняющую, можно сделать проще (много информации уже содержится в коде). В статье же не написано, что команды проще, а написано, что набор этих команд меньше.
Другое дело, что в CISC есть простые команды, активирующие сложную электронику, вроде вычисления всяких sin/cos.
>>Откуда такой странный факт про деление
Из опыта работы, откуда же еще. Когда есть аппаратный делитель, деление работает гораздо быстрее. Как правило, у CISC на этот аппаратный делитель и выведена соответствующая инструкция. Поэтому разница есть — 6 тактов против минимум 57 на RISC-чипе MSP от TI-например.
>>У ARM инструкции длиннее, чем у x86,
O-la-la, длину инструкций в студию, может, я чо забыл.
У RISC (ARM) они практически все фиксированные по длине, и как правило 16/32 бит (ARM 32, ARM Thumb 16). У типичного x86 может быть и 6 и больше байт, а если все допустимые префиксы вписать в команду, то вообще длинная.
Из опыта работы, откуда же еще. Когда есть аппаратный делитель, деление работает гораздо быстрее. Как правило, у CISC на этот аппаратный делитель и выведена соответствующая инструкция. Поэтому разница есть — 6 тактов против минимум 57 на RISC-чипе MSP от TI-например.
>>У ARM инструкции длиннее, чем у x86,
O-la-la, длину инструкций в студию, может, я чо забыл.
У RISC (ARM) они практически все фиксированные по длине, и как правило 16/32 бит (ARM 32, ARM Thumb 16). У типичного x86 может быть и 6 и больше байт, а если все допустимые префиксы вписать в команду, то вообще длинная.
Бляха-муха, как же приятно вас слушать в этом топике!
Ну. Вы вспомните, какой длины инструкция сложения у x86 и у ARM. Ну. И понятно, что в x86-64 можно наворотить очень длинный код инструкции, только полезной информации в этом коде будет байта 4 (в большинстве случаев, загрузка констант — штука редкая) — остальное будет префиксами, необходимыми для совместимости. Так что… Я по-прежнему утверждаю, что у ARM инструкции длиннее (в них закодировано больше), чем у x86.
RISC-чип MSP от TI-например это не единственный RISC чип в мире. Кроме того, всё очень сильно зависит от качества компилятора (ну, или от криворукости программиста, если он на константы делит столбиком, то процессор тут ни при чём). Насчёт производительности в реальном мире — есть такой набор тестов Dhrystone, производительность ALU им меряют, деление в тесте есть. Так вот, ARM Cortex-A9 выдаёт в этом тесте 2.5 попугая, а Atom (в котором есть этот самый аппаратный div) всего 2.0333.
RISC-чип MSP от TI-например это не единственный RISC чип в мире. Кроме того, всё очень сильно зависит от качества компилятора (ну, или от криворукости программиста, если он на константы делит столбиком, то процессор тут ни при чём). Насчёт производительности в реальном мире — есть такой набор тестов Dhrystone, производительность ALU им меряют, деление в тесте есть. Так вот, ARM Cortex-A9 выдаёт в этом тесте 2.5 попугая, а Atom (в котором есть этот самый аппаратный div) всего 2.0333.
Вспомнил, да :) Вспомнил так же, что на команде сложения операции не заканчиваются. Да, у x86 переменная длина команд, а у RISC (ARM) — практически фиксированная.
Но тут вы сами себе противоречите с длиной команд. Смотрите, как именно.
Длина (разрядность) команды напрямую отвечает за степень многообразия опкодов. Вот тут вы говорите, что у RISC длина команды больше. А чуть выше — что (цитата) «набор этих команд меньше». Вопрос — как соотносится бОльшая длина команд с меньшим набором команд? Зачем нужно больше бит под представление команды, если разнообразие этих команд, по вашим словам, невелико, по сравнению с CISC? Ответ: низачем. Поэтому у RISC длина команд статистически меньше. Но фиксированная. Но меньше.
За пример про аппаратное деление сильно не цепляйтесь — это именно что пример, когда CISC оказывается намного выгоднее RISC. Вспомните, откуда пошли CISC и i8080 — из i8008, который вырос из i4004. А это был чип для калькулятора. Деление — раз, BCD — два, прочие прелести сложных команд — три, они предполагали реализацию сложных команд. Я взял как раз первую опцию.
По поводу качества компилятора вы абсолютно правы — скорость сильно зависит от них. Но только никакой компилятор не сможет софтовую реализацию деления из либы сделать быстрее и экономичнее, чем аппаратную — я имею в виду общий случай, без сдвигов.
По поводу синтетических тестов — вообше им не верю, извините. Ну вот AP7000 (AVR32) показывает на 133МГц скорость на 60% больше при том же потреблении, что и Marvell (XScale), и TI OMAP, и ARM7. Обалденный кристалл, хоть и слегка сложный, периферия — зашибись. Но почему-то в народ они не пошли, все на ARM7TDMI продолжают сидеть.
Но тут вы сами себе противоречите с длиной команд. Смотрите, как именно.
Длина (разрядность) команды напрямую отвечает за степень многообразия опкодов. Вот тут вы говорите, что у RISC длина команды больше. А чуть выше — что (цитата) «набор этих команд меньше». Вопрос — как соотносится бОльшая длина команд с меньшим набором команд? Зачем нужно больше бит под представление команды, если разнообразие этих команд, по вашим словам, невелико, по сравнению с CISC? Ответ: низачем. Поэтому у RISC длина команд статистически меньше. Но фиксированная. Но меньше.
За пример про аппаратное деление сильно не цепляйтесь — это именно что пример, когда CISC оказывается намного выгоднее RISC. Вспомните, откуда пошли CISC и i8080 — из i8008, который вырос из i4004. А это был чип для калькулятора. Деление — раз, BCD — два, прочие прелести сложных команд — три, они предполагали реализацию сложных команд. Я взял как раз первую опцию.
По поводу качества компилятора вы абсолютно правы — скорость сильно зависит от них. Но только никакой компилятор не сможет софтовую реализацию деления из либы сделать быстрее и экономичнее, чем аппаратную — я имею в виду общий случай, без сдвигов.
По поводу синтетических тестов — вообше им не верю, извините. Ну вот AP7000 (AVR32) показывает на 133МГц скорость на 60% больше при том же потреблении, что и Marvell (XScale), и TI OMAP, и ARM7. Обалденный кристалл, хоть и слегка сложный, периферия — зашибись. Но почему-то в народ они не пошли, все на ARM7TDMI продолжают сидеть.
> Но только никакой компилятор не сможет софтовую реализацию деления из либы сделать
> быстрее и экономичнее, чем аппаратную — я имею в виду общий случай, без сдвигов.
А что по-Вашему есть «аппаратная реализация» какой-либо сложной команды? Все команды в CISC точно так же на низком уровне выполняется микропрограмами. Зато в RISC (как правило) большее количество регистров общего назначения, более короткие опкоды, бОльшая тактовая частота, простая архитектура. В целом сложно сказать что именно эффективнее и быстрее получается.
> быстрее и экономичнее, чем аппаратную — я имею в виду общий случай, без сдвигов.
А что по-Вашему есть «аппаратная реализация» какой-либо сложной команды? Все команды в CISC точно так же на низком уровне выполняется микропрограмами. Зато в RISC (как правило) большее количество регистров общего назначения, более короткие опкоды, бОльшая тактовая частота, простая архитектура. В целом сложно сказать что именно эффективнее и быстрее получается.
Упс. Я не прав. В ARM Cortex есть аппаратный делитель.
А ты сам пишешь? Я пишу на асм под х86 и арм. Честно — под арм писать приятнее. Хотя бы тем, что не надо стопитсот команд на элементарные действия типа сдвигов.
А что вы имеете в виду под «стопицот» — большое их разнообразие или большое количество их в программе? Если про первое — ортогональность набор команд и CISC vs RISC — это все же разные вещи; иногда оно присутствует, иногда — не очень.
Что значительно приятнее у RISC при написании кода — это большое количество доступных регистров, что делает проще ручное написание.
Если же посмотреть на последние чипы от Intel, их там (скрытых регистров) около 700, т.е. внутри Intel — это та же RISC-машина.
Что значительно приятнее у RISC при написании кода — это большое количество доступных регистров, что делает проще ручное написание.
Если же посмотреть на последние чипы от Intel, их там (скрытых регистров) около 700, т.е. внутри Intel — это та же RISC-машина.
Имею в виду, что нет обособленных операций, выполняющих сами по себе ненужные действия — типа mov. Вместо этого они совмещены с логикой или арифметикой, что логичнее и приятнее при написании.
А про регистры — да, х86 в душЕ — риск, но до этого риска добраться программно могут наверно лишь сотрудники интела, посвященные в тайны микрокода. Нам, простым смертным, от этой радости ни горячо, ни холодно — пользоваться можно лишь навесными костылями для ублюдочной совместимости.
А про регистры — да, х86 в душЕ — риск, но до этого риска добраться программно могут наверно лишь сотрудники интела, посвященные в тайны микрокода. Нам, простым смертным, от этой радости ни горячо, ни холодно — пользоваться можно лишь навесными костылями для ублюдочной совместимости.
как-то малова-то и очевидно :)
>CISC микропроцессоров безусловно хороши для ресурсоемких приложений, таких как 3d max, Photoshop,
Photoshop у меня долго время летал на PowerPC G4. Да и спарки это тоже RISC. Cell (PS3) — чем не навороченные 3д игры?
p.s.
разве Apple A4 это ARM? я считал, что это «их» разработка на основе той которую они купили год или 2 назад. По поводу того, что приложения с iPhones OS идут без проблем — ну так и приложения PowerPC идут на Intel, и в обратную сторону тоже. Хотя сейчас все меньше и меньше универсальных продуктов.
>CISC микропроцессоров безусловно хороши для ресурсоемких приложений, таких как 3d max, Photoshop,
Photoshop у меня долго время летал на PowerPC G4. Да и спарки это тоже RISC. Cell (PS3) — чем не навороченные 3д игры?
p.s.
разве Apple A4 это ARM? я считал, что это «их» разработка на основе той которую они купили год или 2 назад. По поводу того, что приложения с iPhones OS идут без проблем — ну так и приложения PowerPC идут на Intel, и в обратную сторону тоже. Хотя сейчас все меньше и меньше универсальных продуктов.
Apple A4 все же модифицированный ARM
Ссылку забыл ru.wikipedia.org/wiki/Apple_A4
Сами читали?
Процессор, представляющий из себя систему на кристалле, разработан микропроцессорным подразделением Apple, __сформированным из приобретённой корпорацией фирмы P.A.Semi__ (англ.).
В сетевых СМИ __высказываются предположения,__ что процессор A4 изготавливается по 45-нанометровому технологическому процессу, имеет максимальную потребляемую мощность 0.3 Вт, кеш L2 объёмом 2 Мбайта, основное ядро с модифицированной архитектурой ARM Cortex A9[2]
Так, что ничего не известно пока еще.
Процессор, представляющий из себя систему на кристалле, разработан микропроцессорным подразделением Apple, __сформированным из приобретённой корпорацией фирмы P.A.Semi__ (англ.).
В сетевых СМИ __высказываются предположения,__ что процессор A4 изготавливается по 45-нанометровому технологическому процессу, имеет максимальную потребляемую мощность 0.3 Вт, кеш L2 объёмом 2 Мбайта, основное ядро с модифицированной архитектурой ARM Cortex A9[2]
Так, что ничего не известно пока еще.
Вполне логичное предположение, так как ОС iPad базируется на iPhone OS, а там стоят именно ARM
логично, но: у меня есть приложение VLC, если я его тупо скопирую на с вой старый мак(который PowerPC G4) то приложение будет работать точно так же. В тоже время как чистое PowerPC приложение MS Office(старый) работает на интел маках через транслятор Rosetta. так, что 50/50…
Apple юзает технологию fat binaries. Так что, если вы скопировали куда-то исполняемый файл и он там запустился, то это ещё не означает, что CPU там одинаковые, просто в бинарнике может быть код для разных архитектур.
А ещё есть возможность, что это бинарник с кодом LLVM, который уже на месте исполнения транслируется в необходимый машинный код.
Это ни о чём не говорит. Компиляторы умеют компилировать и для PPC, и для ARM, и для Itanium. Основная сложность при переносе ОС возникает не в связи с архитектурой процессора, а в связи с другим интерфейсом к перефирии.
Маловато и очевидно, потому что хабр читаю не только хорошие программеры. Согласитесь что небольшая статья хоть как-то раскрывающая тему лучше чем её полное отсутствие.
Насчёт фотошопов и игр, то как они летают на RISC архитектурах больше зависит от разработчика и компилятора, нежели от процессора.
>разве Apple A4 это ARM?
Да, на сайте эпл об этом конечно не написанно, но на большинстве новостных ресурсов — да.
Насчёт фотошопов и игр, то как они летают на RISC архитектурах больше зависит от разработчика и компилятора, нежели от процессора.
>разве Apple A4 это ARM?
Да, на сайте эпл об этом конечно не написанно, но на большинстве новостных ресурсов — да.
Если честно то статья на уровне сравнения первых параграфов из википедии.
>Насчёт фотошопов и игр, то как они летают на RISC архитектурах больше зависит от разработчика и компилятора, нежели от процессора.
тогла согласитесь, статья вообще в таком случае ничего не раскрывает?
>Да, на сайте эпл об этом конечно не написанно, но на большинстве новостных ресурсов — да.
слухи и не более. Известно только то, что Apple купила P.A.Semi. А про ARM догадки на основании того, что приложения от iPhones OS идут без проблем. Надо подождать выхода устройства все же.
>Насчёт фотошопов и игр, то как они летают на RISC архитектурах больше зависит от разработчика и компилятора, нежели от процессора.
тогла согласитесь, статья вообще в таком случае ничего не раскрывает?
>Да, на сайте эпл об этом конечно не написанно, но на большинстве новостных ресурсов — да.
слухи и не более. Известно только то, что Apple купила P.A.Semi. А про ARM догадки на основании того, что приложения от iPhones OS идут без проблем. Надо подождать выхода устройства все же.
Как раз наоборот: отсутствие статьи лучше, чем небольшая заметка под впечатлением от википедии. Потому что если человек просто не знаком с вопросом он хотя бы это про себя знает, осознает свою некомпетентности. Человек же принявший на веру ваш текст получит искаженное представление о предмете и ложное впечатление о своих знаниях.
А как слова о поддержке архитектур разными компаниями соотносятся с наличием XScale, которые имеют архитектуру ARM и изначально разрабатывались в Intel?
Начал за здравие, кончил за упокой.
В тред врывается MIPS!
НЛО прилетело и опубликовало эту надпись здесь
Тема, которую автор взял на себя, вообще не раскрыта. Почему действительно про длину команд ничего не сказано? Недостаток CISC не в «сложных» командах (у RISC'ов бывают такие, которые CISC'ам только на каких-нибудь VLIW снились — с кучей операндов, да еще когда, скажем, половина — в регистрах, половина — в памяти и так далее), а в их нефиксированной длине и, следовательно, в потребности намного более сложного декодера, что автоматически выливается в ограничения по количеству декодируемых одновременно команд, в сложности предсказаний, в лишний гемор с конвейером (вспоминаем, например, NetBurst и все его особенности и вообще причины его появления).
Почему автор ничего не сказал о том, что все CISC-процессоры ныне внутри — те же RISC со своим собственным набором инструкций, в которые они декодируют старый-добрый x86?
И вообще — почему речь идет исключительно про Arm? :-) Вот в комментах уже тоже упомянули MIPS. Во всех embedded-девайсах, с которыми я в последние разы сталкивался, был как раз MIPS, а не ARM. И, кстати, именно MIPS, а не ARM больше подходят под все определения из статьи — у них реально намного проще и понятнее система команд и так далее по тексту… Зато они изначально разрабатывались под длинный конвейер (читай — большие частоты) и там суперскалярность заложена в саму архитектуру. Поэтому, например, с непривычки очень прикольно воспринимается их код: там после каждого перехода зачастую есть еще какая-нибудь команда (обычно — «подчистка» регистров или типа того), которая с банальной точки зрения вообще не должна исполняться, но таки исполняется за счет суперскалярности. :-) Кстати, автор первого коммента тоже, очевидно, больше в виду как раз MIPS, а не ARM имеет. :-) Именно в MIPS изначально умножения/деления не было… :-)
Вообще же, что касается самой темы, то я всей душой надеюсь и жду, когда наконец хедлайнеры процессоростроения плюнут на этот пережиток в виде CISC (его ведь и вводили-то просто потому, что на первых процессорах так было проще — хотя тот же RISC уже кучу времени существовал на мейнфреймах и отлично себя зарекомендовал), откажутся от обратной совместимости и сделают шаг вперед. Это тут же развяжет всем руки…
Собственно, развитие технологий виртуализации вселяет надежду, что скоро так и будет. :-) Кстати, возможно, застрельщиком будет даже не Intel, а та же AMD: не найдя средств для адекватной конкуренции с i7, решит перейти на новые правила игры. :-) Хотя ХЗ. Посмотрим.
Почему автор ничего не сказал о том, что все CISC-процессоры ныне внутри — те же RISC со своим собственным набором инструкций, в которые они декодируют старый-добрый x86?
И вообще — почему речь идет исключительно про Arm? :-) Вот в комментах уже тоже упомянули MIPS. Во всех embedded-девайсах, с которыми я в последние разы сталкивался, был как раз MIPS, а не ARM. И, кстати, именно MIPS, а не ARM больше подходят под все определения из статьи — у них реально намного проще и понятнее система команд и так далее по тексту… Зато они изначально разрабатывались под длинный конвейер (читай — большие частоты) и там суперскалярность заложена в саму архитектуру. Поэтому, например, с непривычки очень прикольно воспринимается их код: там после каждого перехода зачастую есть еще какая-нибудь команда (обычно — «подчистка» регистров или типа того), которая с банальной точки зрения вообще не должна исполняться, но таки исполняется за счет суперскалярности. :-) Кстати, автор первого коммента тоже, очевидно, больше в виду как раз MIPS, а не ARM имеет. :-) Именно в MIPS изначально умножения/деления не было… :-)
Вообще же, что касается самой темы, то я всей душой надеюсь и жду, когда наконец хедлайнеры процессоростроения плюнут на этот пережиток в виде CISC (его ведь и вводили-то просто потому, что на первых процессорах так было проще — хотя тот же RISC уже кучу времени существовал на мейнфреймах и отлично себя зарекомендовал), откажутся от обратной совместимости и сделают шаг вперед. Это тут же развяжет всем руки…
Собственно, развитие технологий виртуализации вселяет надежду, что скоро так и будет. :-) Кстати, возможно, застрельщиком будет даже не Intel, а та же AMD: не найдя средств для адекватной конкуренции с i7, решит перейти на новые правила игры. :-) Хотя ХЗ. Посмотрим.
У ARM'ов есть большая плюшка — они не такие жручие и на батарее работают по 8-12 часов, в то время как x86 — по 2.
Не уж то все еще ни кто не написал что все современные процессоры от Intel или AMD внутри давно уже RISC?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
X86 и ARM: война за портативные устройства. Кто же выиграет?