x86 vs ARM: сложность инструкций

А как же P2P, крузис, БРАУЗЕР в конце-концов?

Лучше бы молчал, чем говорил, не выставил бы себя идиотом. FPGA отлично подходит для создания dataflow-архитектур. Все, что ложится на семантику dataflow, на FPGA делается лучше чем на последовательных архитектурах.

Вот только при более-менее сложных алгоритмах либо накладные расходы FPGA-CPU съедают всю выгоду, либо процом считать выгоднее из-за большей его частоты и производительности. А уж если поглядеть на цены всяких виртексов/стратиксов/спидстеров...

Быдло не способно мыслить параллельно

Не передергивай, ты же сам не понимаешь о чем говоришь - верно ?

придумать язык более простой, чем Verilog

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

FPGA никогда не станут массовой технологией

с этим скорей согласен, но время покажет

вы пьяны что ли. на кой хрен в переносном ПК, ноуту или планшете dataflow-архитектура? да еще дико греющаяся. да еще за такие бапки. и с корявыми dsp блоками которые точили под нужды конкретных массовых заказчиков.

Не передергивай, ты же сам не понимаешь о чем говоришь - верно ?

Прекрасно понимаю. Всякие там Сишечки, на которых любит кодерячить быдло, не годятся для разработки под FPGA. А учить что-то более непривычное быдлушко не желает ни при каких обстоятльствах. Менять способ мышления быдлушко не станет, даже если от этого будет зависеть быдлушкина жизнь.

дело не в языке, у Verilog С-подобный синтаксис, у VHDL - ада-вый, не так уж сложно привыкнуть

Синтаксис-то тут при чем? Семантика у HDL-ей параллельная, а мыслить параллельно быдлы не умеют. Понять концепции FSM и pipeline они не смогут.

Попадись задача сложней где потребовались бы более глубокие познания я бы сдулся.

Сдулся бы ты потому, что не умеешь мыслить категориями, отличными от уже привычных. Точно так же ты сдуешься, если потребуется программировать на Occam (который, кстати, как раз неплохо подходит для FPGA - его можно компилировать в простые NoC-системы).

И языки более высокого уровня, такие, как Bluespec, тоже не помогут - потому как требуют сдвига сознания. В общем, та же история, что с функциональщиной. Как функциональщина не будет массовой, так и параллельные архитектуры (транспьютеры, FPGA). Единственное, что быдло массово осилило, это SPMD всякие, вроде GPGPU.

Но я выскажу тебе мнение профессионального ЛОР-аналитика:

Ты некомпетентен.

Зато у меня есть здравое чувство самоиронии.

ARM давно обогнал Intel - в производительности на ватт, в площади на кристалле, в степени интеграции в SoC.

Спасибо, Капитан. Но речь о сырой производительности.

Именно эти характеристики и представляют интерес для потребителей продукции ARM.

Ну да, ARM прочно сидит в своей нише. Потеснить его будет дорого, но у Intel есть деньги.

Ты видел декодер x86? Такие накладные расходы в embedded недопустимы.

Может, ты приведешь его стоимость в процентах транзисторного бюджета.

Советую посмотреть на Hexagon, например.

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

Всякие там Сишечки, на которых любит кодерячить быдло, не годятся для разработки под FPGA

Тем не менее компиляторы VHDL -> C существуют и используются.

verilator как пример

Сдулся бы ты потому, что не умеешь мыслить категориями, отличными от уже привычных.

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

компиляторы VHDL -> C существуют и используются.

А зачем?

на них тестируют не накосячено ли в логике в принципе. там не нужна точная симуляция

компиляторы VHDL -> C существуют и используются.

А зачем?

Алгоритмы, реализуемые во всяких FPGA, обычно записываются (и отлаживаются) на императивных языках вроде Си.

вы пьяны что ли. на кой хрен в переносном ПК, ноуту или планшете dataflow-архитектура?

Вы некомпетентны, юноша.

Практически все вычислительные задачи на Dataflow ложатся эффективнее, чем на последовательное исполнение. Современные OoO, конечно же, тоже внутри Dataflow, но коротенькие.

да еще дико греющаяся.

Чушь.

да еще за такие бапки.

Нищебродец?

и с корявыми dsp блоками которые точили под нужды конкретных массовых заказчиков.

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

Тем не менее компиляторы VHDL -> C существуют и используются.

Ты, наверное, имел в виду C->VHDL, потому как иначе твой комментарий вообще не имеет смысла. Да, такие есть, и они порождают полнейшее говно. Для быстрого прототипирования небольших кусков логики они еще подходят, а вот для полноценной разработки они никогда и не предназначались.

Алгоритмы, реализуемые во всяких FPGA, обычно записываются (и отлаживаются) на императивных языках вроде Си.

Нет, ничего подобного.

Попробуй «записать (и отладить)» банальный RS-232 на Сишечке. Если с этим справишься (а это даже возможно, если очень-очень постараться), то возьмись за VGA-контроллер. Облом будет очень болезненным и смешным.

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

Ты сливаешься, серое быдлушко. Обучение нужно всем, но настоящие люди его не боятся, для них научиться новому не проблема. Настоящий человек учится непрерывно, для него это естественный процесс. А вот серое быдло любой новой концепции боится до усрачки.

Из априорных знаний у тебя есть только инстинкты, ты - животное.

У тебя IQ явно ниже 80 единиц, или ты дислексик. Ну или и то, и другое разом.

Проблема в том что интересна run-time статистика.

Свободно доступна разве что древняя пдфка - Analysis of x86 Instruction Set Usage for DOS Windows Applications and Its Implication on Superscalar Design.pdf

Лидируют там - push mov и jz. Сохранение регистров (также при вызов функций), очевидный mov и циклы,

Ты, наверное, имел в виду C->VHDL

Да, конечно.

Да, такие есть, и они порождают полнейшее говно.

Если оно устраивает заказчика, всё нормально.

Спасибо, Капитан. Но речь о сырой производительности.

Кого колышет сырая производительность? ARM этим точно не занимается, и никогда заниматься не будет - не их ниша. За сырой производительностью дуй к голубым, они POWER на криогенном охлаждении гоняют.

Потеснить его будет дорого, но у Intel есть деньги.

У Intel нет опыта и есть огромное отставание. То, что ARM уже двадцать лет умеет, им надо изобретать заново.

Может, ты приведешь его стоимость в процентах транзисторного бюджета.

Исходи из того, что первые 5-8 этапов конвейера это декодер. Шаги конвейера занимают где-то равную площадь. Вот и думай теперь.

но взгляды твои, как бы это помягче, не мэйнстримные.

Что ты знаешь за мейнстрим?!? Видел бы ты, какие неконвенционные архитектурные решения сейчас в GPU применяют - там как раз всем на обратную совместимость насрать. Hexagon на этом фоне вполне мейнстримен.

Попробуй «записать (и отладить)» банальный RS-232 на Сишечке.

Попробуй записать и отладить небанальный алгоритм DSP сразу на VHDL.

Если оно устраивает заказчика, всё нормально.

Никто и никогда не получает готовых решений на C->HDL. Это всегда только прототипирование, причем очень узких участков. Интеграция всегда только HDL. Да что там, на C (даже в новомодном Vivado) даже распиновку не сделать.

Посмотри на http://www.c-to-verilog.com/online.html - примерно то же самое и на том же уровне делают и коммерческие тулзы.

Попробуй записать и отладить небанальный алгоритм DSP сразу на VHDL.

Я этим себе на жизнь зарабатываю (только не VHDL, а Verilog). Не вижу, чем бы мне сишечка помогла. Любой небанальный алгоритм - это FSM. А уж FSM записывается и отлаживается вообще на бумаге, карандашиком.

Но речь о сырой производительности.

Кого колышет сырая производительность?

Чуть менее, чем всех.

У Intel нет опыта и есть огромное отставание.

Ахиллес никогда не догонит черепаху.

Может, ты приведешь его стоимость в процентах транзисторного бюджета.

Исходи из того, что

Мне нужно искать данные в гугле, и не факт, что я найду правильные.

Что ты знаешь за мейнстрим?!?

Считай, что Анандтек.

Видел бы ты, какие неконвенционные архитектурные решения сейчас в GPU применяют - там как раз всем на обратную совместимость насрать.

Мде. Казалось бы, причем GPU к процессорам общего назначения...

Кого колышет сырая производительность?

Компании типа google, facebook, amazon итп. В качестве пути оптимизации расходов. Именно поэтому у этих контор (у первых двух по крайней мере) своё нестандартное оборудование (как минимум блоки питания, у гугла, судя по фоткам, нестандартные материнки).

Есть начальные расходы на приобретение оборудование, есть эксплуатационные расходы (электричество итп). ARM потенциально может скостить и то и другое.

Любой небанальный алгоритм - это FSM

Это профессиональная аберрация.

интересна run-time статистика

Пропатчи bochs и посмотри, если там этой фичи нет изначально.

У ARM есть огромное преимущество - ARM умеют в SoC

Вот и я про то же: как Интел в SoC въедет, так ARM потеряет кусок рынка.

и у ARM огромный опыт в снижении энергопотребления. Intel никогда ни тем, ни другим не заморачивался, и потому безнадежно отстал. «Intel SoC» сейчас звучит как оксюморон.

Ну, положим, про SoC они в роадмапах на ближайшие годы пишут... А отстал - от чего отстал? Сколько потребляет ARM, сравнимый по производительности с каким-нибудь средней паршивости Xeon'ом?

У Интела подвижки в области энергосбережения есть: Хасвелл дольше может ничего не делать.

Давно уже начал - Atom E6x5C.

Нет, этот на двух разных пластинах был.

У ARM аналогично - Xilinx Zynq. Толку-то - что то, что другое, совершенно нишевые продукты.

Понятно, что нишевые, но мы про них и разговариваем. Я, кстати, дофига продуктов на Zynq вижу.

Еще раньше были аналогичные решения на базе PowerPC, и тоже никакого массового применения не имели.

Тоже неправда, Виртексы с PPC много где использовались. В пределах ниши применения FPGA, но в ней были популярны.

С Интелом другая история: помимо полностью своей разработки и выпуска чипов, они делают оптимизированные компиляторы и библиотеки для разработчиков. Суть ведь использования FPGA в SoC в чём? Известный народу hard IP процессор с кучей программируемых гейтов вокруг для создания обвязки. Так вот, в какой-нибудь девайс с интенсивным использованием процессора лучше пойдёт Интел+FPGA, чем Интел + куча обвески от третьих контор + более сложное проектирование плат.

ARM/MIPS в такой девайс не пойдёт: слишком скромные вычислительные способности.

Виталик?

Чуть менее, чем всех.

Ну да ну да. Aerospace, automotive, CNC всех мастей - им очень-очень нужна производительность, да да, не надежность, не real time, не поддержка всяких там CAN, не низкое энергопотребление, а именно производительность. И это у меня «профессиональная аберрация»?!? По-моему тут кое-кто другой за пределами своих десктопишек с серверишками и прочими айпадиками ни черта не видит.

Ахиллес никогда не догонит черепаху.

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

Мде. Казалось бы, причем GPU к процессорам общего назначения...

GPU-ядра и есть процессоры общего назначения, если оттуда выкинуть всякие специализированные инструкции для текстурирования.

У Intel нет опыта и есть огромное отставание. То, что ARM уже двадцать лет умеет, им надо изобретать заново.

Ничего не надо изобретать. В современном бизнесе от момента покупки нишевых специалистов до начала серийного выпуска девайсов, предназначенных для этой ниши, проходит 3-5 лет. Специалисты по SoC в Интеле появились.

Вот и я про то же: как Интел в SoC въедет, так ARM потеряет кусок рынка.

До этого еще очень-очень далеко. У них даже шины нет подходящей.

Сколько потребляет ARM, сравнимый по производительности с каким-нибудь средней паршивости Xeon'ом?

Там, где нужна производительность Xeon-а, там все равно не до энергосбережения. А где нужно энергию беречь, там не нужна производительсноть. Потому они и не пересекаются нигде, ниши слишком разные.

У Интела подвижки в области энергосбережения есть: Хасвелл дольше может ничего не делать.

Им еще очень далеко до ARM.

Нет, этот на двух разных пластинах был.

Не знал. Ну ладно, останусь на Zynq - а то начинал уже к атомам присматриваться.

Понятно, что нишевые, но мы про них и разговариваем. Я, кстати, дофига продуктов на Zynq вижу.

Это я к тому, что в ноутбуки и планшеты оно никогда не попадет. А жаль.

Тоже неправда, Виртексы с PPC много где использовались. В пределах ниши применения FPGA, но в ней были популярны.

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

С Интелом другая история: помимо полностью своей разработки и выпуска чипов, они делают оптимизированные компиляторы и библиотеки для разработчиков.

ARM тоже компиляторы делает. И что?

Так вот, в какой-нибудь девайс с интенсивным использованием процессора лучше пойдёт Интел+FPGA

Честно говоря, не очень себе представляю область применимости таких девайсов. Если нужен тяжелый hard CPU с кучей жирной памяти, то его разумнее отдельно держать, нет смысла жирному монстру делить тормозную внутрисистемную шину с софтовой логикой на FPGA.

Aerospace, automotive, CNC всех мастей - им очень-очень нужна производительность

Не скажу за CNC и automotive, но в aerospace таки производительность нужна.

да да, не надежность, не real time, не поддержка всяких там CAN, не низкое энергопотребление, а именно производительность.

Ложная альтернатива.

И это у меня «профессиональная аберрация»?!?

Профессиональная аберрация у тебя - то, что любой сложный алгоритм является FSM. Есть сложные вычислительные алгоритмы, которые ни разу не FSM.

Не будем скатываться в танцпол, но все, кто считал, что для инноваций достаточно вбухать бабла побольше, очень жиденько обгадились

Ну блин, другая же ситуация. Речь не о том, чтобы с нуля после 20 лет разрухи, а о конкуренции между двумя действующими производителях процессоров.

Специалисты - да. А патенты? Очень непросто им будет родить эффективную шину, которая достаточно отличалась бы от всяких там AMBA, чтобы не попадать под действие существующих патентов.

Профессиональная аберрация у тебя - то, что любой сложный алгоритм является FSM. Есть сложные вычислительные алгоритмы, которые ни разу не FSM.

Я тебя удивлю, наверное, но абсолютно любой алгоритм - FSM. Потому как машина Тьюринга - FSM.

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

Для Intel это и будет практически с нуля. Они раньше никогда этим не занимались.

Я этим себе на жизнь зарабатываю (только не VHDL, а Verilog). Не вижу, чем бы мне сишечка помогла. Любой небанальный алгоритм - это FSM. А уж FSM записывается и отлаживается вообще на бумаге, карандашиком.

Парсер FIX - это голимый FSM. Он окружён пайплайнами со всех сторон. Людишки ручками сгенерировать безбажный парсер на HDL не могут, проверенно много раз, на людях разного уровня подготовки, от бывших студентов до (бывших) сотрудников Интела. Парсер FIX на DSL - это пропускание XML спецификации через лисповую функцию и расстановка триггеров, чего когда дёргать при матчинге. Никаких багов, неоптимальностей, всё параллельно и запайплайненно. О чём это я? О том, что язык для оперирования на сигнальном уровне для логики уровня dataflow не подходит.

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

Я не соглашусь с этим. Ноутбуки, планшеты, мобильники, микросервера. Везде присутствуют решения из двух лагерей.

И, в отличие от больших x86 процов, в этих сегментах эволюция идёт полным ходом.

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

Пардон муа, так наипервейший же смысл в FPGA вокруг CPU - это и есть организация интерфейсов. Вместо PCB с кучей чипов и дорожек теперь можно один чип иметь.

Я тебя удивлю, наверное

Не удивишь.

машина Тьюринга - FSM.

Ну началось... и вычислительные алгоритмы, конечно, именно для машины Тьюринга и пишутся.

Ой, да пожалуйста, DSL-ьте сколько угодно. Ничего не имею против. Только вот сишечка - ни разу не DSL.

До этого еще очень-очень далеко. У них даже шины нет подходящей.

Я точно не знаю, чего у них там нет, но вот заказы уже есть.

Честно говоря, не очень себе представляю область применимости таких девайсов. Если нужен тяжелый hard CPU с кучей жирной памяти, то его разумнее отдельно держать, нет смысла жирному монстру делить тормозную внутрисистемную шину с софтовой логикой на FPGA.

Сториджы, тяжёлые роутеры и т.п. Программируемая логика там была ещё 20 лет назад. Забавно в музее видеть, как две шкафа на рассыпухе были заменены одним, но с использованием ПЛМ.

Специалисты - да. А патенты? Очень непросто им будет родить эффективную шину, которая достаточно отличалась бы от всяких там AMBA, чтобы не попадать под действие существующих патентов.

Какая AMBA, зачем? У Интела есть QPI.

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

Ты невменяем. Так и запишем - скотина слилась с позором, не осилив цивилизованной дискуссии.

fpga очень удобная, не спорю. я даже как-то запилил сетевой адаптер, умеющий брать на себя tcp стек(c хаком-с нечестным юзерем мы нарушаем tcp протокол очень дерзко) с одного порта+базовое http и отправлять это прямо в RAM. Оно было бы очень удобно для датацентров и я это, между прочим отметил. i/o, всякая хрень летающая и военная и т.д. и т.п.

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

а, так эти ваши пляски у вас считаются «цивилизованной дискуссией»...как у вас, обезьянов, всё не как у людей

скомпиль какой нибудь пример под арм и х86 с ключем -S и сравнивай результаты. Если я конечно правильно тебя понимаю.

Если я конечно правильно тебя понимаю.

Я сам себя пока не понимаю. Просто пишу статью о перспективах армов на рынке серверов. Но мне хочется дать глубокийправдоподобный анализ. Сейчас модно сравнивать instructions per cycle (IPC) у x86 и у армов. Вот пытаюсь выяснить насколько это правомерно и какие выводы можно делать из цифр. Чем глубже копаешь тем менее понятно как это всё вообще работает.

модно сравнивать instructions per cycle (IPC) у x86 и у армов

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

полезная нагрузка на инструкцию то разная.

Угу. У меня есть ещё другие соображения. Кто сказал что если проц выдаёт по инструкции за такт то значит что эффективность 100%? Да у него там четыре пайплайна на ядро.

Плюс непонятно как считаются инструкции. Туда результаты некоторых μops учитывается как отдельные инструкции.

Короче, для производительности надо считать реальное время выполнения задачи. Но народ ещё хочет знать как эффективно расходуется кремний :). Если IPC большой то типа транзисторы потратили не зря :)