x86 он разный бывает. Например говнецо с C7 Cortext в некоторых случаях делает. Впрочем мы об этом дискутировали

Ключевое слово - массовый продукт

И как бы ведроид не кляли - он сейчас синоним этого массового продукта. Драйвера-то в ведре. Живой пример. Жили себе поживали стобаксовые недобуки на армах от VIA с winCE. Погоды не делали на рынке, крупных игроков эта ниша не влекла. Зато, когда на этом чипе появились устройства с ведроидом, народ быстро дебиан прикрутил к ведроидному ядру. Хотя раньше доолго бились над этим вопросом. Пущай будут с ведроидом, главное ядро. Уже и зомбоящики на армах с ведроидом от самса есть(с камерой, скайпом, домино и девчёнками).

>> И вот тут хотелось бы услышать, насколько это уменьшило бы сложность и увеличило бы производительность %)

Откуда ж я знаю.

Ну ты так уверенно говорил о том, что x86 говно...

судя по заявлениям о проделанных оптимизациях энергопотребления в Sandy Bridge (раздублицирование данных и избавление от копирования) игра стоит свеч

Игра стоит свеч при, например, 20% экономии. Но вот миграция на другую архитектуру этих процентов не стоит.

тот факт, что Intel решил сделать IA-64 чтобы максимально распараллелить исполнение инструкций говорит о том, что x86 для этого мало пригодна.

А то, что IA-64 провалился, намекает на то, что такое распараллеливание инструкций не нужно.

> А то, что IA-64 провалился, намекает на то, что такое распараллеливание инструкций не нужно.

VLIW вообще спорная штука.

Так такие армы и не нужны. Нужны нормальные.

нормальных нет и не будет

> Ну ты так уверенно говорил о том, что x86 говно...

Я говорил о том, что у нее есть недостатки. И говорил я исключительно о технической стороне самой архитектуры, не затрагивая вопросы доступности процессоров с этой архитектурой и их цены, софта под них, качества компиляторов, наличия инженеров и программистов и пр. вопросы, которые очень важны. По совокупности всех параметров этой архитектуре нет равных и она еще нас с вами переживет.

тот факт, что Intel решил сделать IA-64 чтобы максимально распараллелить исполнение инструкций говорит о том, что x86 для этого мало пригодна.

А то, что IA-64 провалился, намекает на то, что такое распараллеливание инструкций не нужно.

Коммерческий успех слабо соотносится с техническим совершенством. А именно о технических аспектах я и говорил.

нормальных нет и не будет

Вот это спорно. Будет спрос, появятся и предложения. Даже для роутеров требуются армы всё производительнее. А тот же нетгир вполне официально рекомендует dd-wrt в качестве альтернативы оф.прошивке. Выгода и производителю и покупателю. Рынок и конкурентоспособность девайса расширяется. Пусть опенсорс и работает на капиталиста. Но кто сказал, что это плохо. Плохо - это монополии и жри, что дают. Редкое явление, но надеюсь тенденция хорошая.

>Основная фишка CISC — малый размер кода (для современных десктопных архитектур это не важно).

Кэш-память с тобой ой как несогласна.

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

Рекомендую взять в руки fasm/nasm/asm(...) и посмотреть, насколько же, оказывается, быстро на самом деле эти переходы (в том числе и промахи) происходят. Скажем так: кеш-промах намного хуже, чем неверно предсказанный переход.

Нерегулярная структура инструкций (они могут иметь длину от 1 до 15 байт) вынуждает делать довольно сложный блок декодирования.

Что меня как конечного пользователя не интересует.

Обилие сложных инструкций вынуждает ввести такую штуку как микрокод.

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

Можно было бы выкинуть кучу блоков и тем самым

...прососать на чем-либо, отличном от целочисленной арифметики, как это делают всем любимыми армами.

упростить (удешевить) разработку новых моделей процессоров.

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

Роутеры вообще на мипсах работают :)

>Откуда ж я знаю.

Однако утверждаешь.

Однако судя по заявлениям о проделанных оптимизациях энергопотребления в Sandy Bridge (раздублицирование данных и избавление от копирования) игра стоит свеч.

Игра не стоит свеч, если при этом страдает производительность. Мы выпустили Core i9, который в два раза медленее, но кушает в 5 раз меньше энергии. Как думаешь, кому можно втюхать такой i9 Extreme Edition за $1k+? Думаю, подобных идиотов найдется немного.

А тот факт, что Intel решил сделать IA-64 чтобы максимально распараллелить исполнение инструкций говорит о том, что x86 для этого мало пригодна.

Я что-то запамятовал, почему IA64 получился таким мертворожденным? Кажется, потому что процессор — это не пистон, где можно клать мужской половой орган на обратную совместимость?

Роутеры вообще на мипсах работают

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

> Я говорил о том, что у нее есть недостатки. И говорил я исключительно о технической стороне самой архитектуры

Ты говорил про «снизить, упростить, улучшить». Вот и интересно стало, какой профит это принесет - ты не знаешь, а я думаю, что тупо никакого. Даже декодер внешнего x86 -> внутренний RISC на самом деле является полезным узлом, потому что позволяет менять внутренний RISC-формат по желанию.

Коммерческий успех слабо соотносится с техническим совершенством.

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

>> Основная фишка CISC — малый размер кода (для современных десктопных архитектур это не важно).

Кэш-память с тобой ой как несогласна.

У десктопных процессоров (включая PPC) L1I кэш очень маленький (16-64 КБ) и им этого достаточно. А ведь были времена когда 8 КБ системной памяти было о-го-го. :)

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

Рекомендую взять в руки fasm/nasm/asm(...) и посмотреть, насколько же, оказывается, быстро на самом деле эти переходы (в том числе и промахи) происходят. Скажем так: кеш-промах намного хуже, чем неверно предсказанный переход.

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

Нерегулярная структура инструкций (они могут иметь длину от 1 до 15 байт) вынуждает делать довольно сложный блок декодирования.

Что меня как конечного пользователя не интересует.

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

Обилие сложных инструкций вынуждает ввести такую штуку как микрокод.

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

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

Можно было бы выкинуть кучу блоков и тем самым

...прососать на чем-либо, отличном от целочисленной арифметики, как это делают всем любимыми армами.

Нутром чуешь? :)

упростить (удешевить) разработку новых моделей процессоров.

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

Кто сказал, что удешевление разработки приведет к удешевлению стоимости конечного продукта?

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

>> Я говорил о том, что у нее есть недостатки. И говорил я исключительно о технической стороне самой архитектуры

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

Почему ты так думаешь? Возможность вносить изменения в набор инструкций даёт больший простор для оптимизации процессоров. Сейчас приходится запихивать всё новую логику (которая жрет электричество) в процессор, а можно вместо этого просто внести необходимые изменения в код.

На IA-64 тупо не написали компиляторов, которыне выжали бы из него все возможности.

А что там не так с компиляторами?

>А ведь были времена когда 8 КБ системной памяти было о-го-го. :)

Напоминаю, что в те далекие времена компьютеры были: а) сверхмедленные по современным меркам; б) RAM была действительно RAM, а не устройством последовательного доступа, как сейчас

А ведь любая логика жрет электричество.

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

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

То-то я и смотрю, на каждом углу RISCи унижают и растаптывают корки... Стоп, все ведь с точностью до наборот! RISC тормозят, CISC летают!

Кто сказал, что удешевление разработки приведет к удешевлению стоимости конечного продукта?

Читай абзац целиком: никому не нужен в два раза более медленный процессор, даже если он стоит в 4 раз дешевле и потребляет в 5 раз меньше энергии.

>У десктопных процессоров (включая PPC)

Забыл добавить: нехорошо ссылаться на трупы.

> А что там не так с компиляторами?

На VLIW требуется очень большая оптимизация при помощи компилятора, иначе весь профит архитектуры летит в трубу

Компиляция генты.

А зачам там такой процессор?
У меня 500mhz mips вполне с 1080р справляется и файлы при этов отдаёт ~12mb/s

>Смеха ради, назови хотя бы одну архитектуру, процессоры на которой превосходят x86 по двум паказателям: цена и производительность.
У меня в медиаплеере стоит процессор с цеой около $10 за штуку и при это он справляется с декодированием видео лучше чем двухядерный атом.

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

Они уже были процами общего назначения, мипсы-то.

никому не нужен в два раза более медленный процессор, даже если он стоит в 4 раз дешевле и потребляет в 5 раз меньше энергии

Штеуд атом. Только не дешёвый он нифига. И значительно медленнее, и с экономичностью не всё гуд.

>Также как и 64-битный софт поверх работающего в PIO харда.

Какой нафиг PIO на AHCI?

Они уже были процами общего назначения, мипсы-то.

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

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

> Возможность вносить изменения в набор инструкций даёт больший простор для оптимизации процессоров

Именно. Так вот, в x86 для этого вообще небывалый простор - там внутри стоит RISC-процессор (или несколько), систему команд которого можно менять как угодно. И эти изменения возможны как раз потому, что снаружи виден обычный, совместимый x86.

>> А ведь любая логика жрет электричество.

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

Это так, но это не повод не совершенствовать железо.

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

То-то я и смотрю, на каждом углу RISCи унижают и растаптывают корки... Стоп, все ведь с точностью до наборот! RISC тормозят, CISC летают!

Я думаю тебе известно, что CISC внутри давно имеют RISC-подобную организацию и работают с т.н. МОПами (микрооперациями). Внимание вопрос: что было бы если бы тому же CISC процессору на вход поступал поток МОПов вместо х86-инструкций? Подсказываю: процессор перестал бы называться CISC :) и декодер (вместе с микрокодом) стал бы не нужен. Производительность бы не изменилась, а вот энергопотребление снизилось бы за счет выкидывания ненужного блока.

>> А что там не так с компиляторами?

На VLIW требуется очень большая оптимизация при помощи компилятора, иначе весь профит архитектуры летит в трубу

Это да. Интересно услышать, почему он считает, что Интел с этим не справился.

Воркстейшны SGI были довольно-таки массовым продуктом

Это да, но кто мог прикупить такое для личных нужд (профессиональное решение было всё же). Сейчас массовый рынок - это фактически сектор доступной бытовой техники. И в этом заслуга интела и открытой архитектуры PC. Просто хочется альтернатив. Всё равно, специализированные решения для каждой группы задач функциональнее, чем прожорливый комбайн. Ну и пользовались бы массы гудящими 24/7 ящиками. Не хотят. Значит будет расти спрос на медиаплееры с сетевыми возможностями. x86 будет занимать нишу достаточно доступных высокопризводительных решений. А для массового потребителя операционная система значения иметь не будет, главное кнопочки чтобы подписаны были. И андроид тому доказательство. А нам профит будет несомненный. Я не спорю, все ваши доводы верны. Просто у меня нет задач, которые бы требовали таких вычислительных ресурсов в ущерб энергопотреблению и/или времени автономной работы(как, думаю, и у подавляющего большинства пользователей).

>И вот тут хотелось бы услышать, насколько это уменьшило бы сложность и увеличило бы производительность %)
Могу найти статью, где расписыватся это в процентном отношении.
Идея в том, что декодеры замимают место иедят энергию.
У топовых процессоров это мизер по сравнению с общим потреблением, а у ядер размера Атома или Селерона, это уже заметная часть как по площади так и по потреблению по сравнению с АРМ

>У меня в медиаплеере стоит процессор с цеой около $10 за штуку и при это он справляется с декодированием видео лучше чем двухядерный атом.

Запили туда WebM

Говорим АRМ, подразумеваем SoC, а значит компактность и экономичность. А ведь пытались не раз сделать экономичный и достаточно производительный x86 SoC. Фигвам. Геоде вроде последней попыткой были.

>>И вот тут хотелось бы услышать, насколько это уменьшило бы сложность и увеличило бы производительность %)

Могу найти статью, где расписыватся это в процентном отношении.

Да, было бы интересно.

>Читай абзац целиком: никому не нужен в два раза более медленный процессор, даже если он стоит в 4 раз дешевле и потребляет в 5 раз меньше энергии.
LOL
Расскажите это пользователям нотбуков, и прочего мобильного железа.
А так-же интелу, выпустившему Атом.

Интел CE ЕМНИП 5 ватт был. Только после появления i3 и pentium u на базе i3 оно никому не нужно стало.

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

>> Возможность вносить изменения в набор инструкций даёт больший простор для оптимизации процессоров

Именно. Так вот, в x86 для этого вообще небывалый простор - там внутри стоит RISC-процессор (или несколько), систему команд которого можно менять как угодно. И эти изменения возможны как раз потому, что снаружи виден обычный, совместимый x86.

Выше головы не прыгнешь. Поясню на примере. Знаешь почему компиляторы не используют инструкцию inc (в режиме оптимизации по скорости)? Они вставляют вместо нее инструкцию add $1, %xxx (которая между прочим длиннее). Делается это потому, что add модифицирует флаги OF, SF, ZF, AF, CF и PF, а inc только OF, SF, ZF, AF и PF. Флаг CF инструкция inc не меняет. Это создает зависимость по данным от предыдущих записей в EFLAGS и тем самым уменьшает количество кода, который можно было бы исполнять параллельно. Ведь если есть несколько инструкций, не зависящих друг от друга по данным, то можно их выполнить параллельно. А если одна инструкция зависит от результата вычисления другой, то выполнять их приходится последовательно. Всё, приехали. Процессор с этим не может ничего поделать из-за того, что архитектура х86 такая.

> Это да. Интересно услышать, почему он считает, что Интел с этим не справился.

Собственно, если бы Интел справился, нынешние топовые процы имели бы архитектуру IA64.

> А ведь пытались не раз сделать экономичный и достаточно производительный x86 SoC. Фигвам. Геоде вроде последней попыткой были.

http://www.intel.com/pressroom/archive/releases/2010/20100413comp.htm

> Выше головы не прыгнешь.

Выше своей - нет, но выше голов всех остальных - вполне.

Процессор с этим не может ничего поделать из-за того, что архитектура х86 такая.

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

>> Процессор с этим не может ничего поделать из-за того, что архитектура х86 такая.

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

Это был всего лишь пример, демонстрирующий очевидный факт, что особенности архитектуры влияют на производительность. С inc хорошо, его можно без проблем заменить на add. А что делать в случае когда адекватной замены нет?

> С inc хорошо, его можно без проблем заменить на add. А что делать в случае когда адекватной замены нет?

RISC доказал, что незаменимых команд нет %)

Спасибо за ссылку

Но атом в коммуникаторы? Посмотрим, что получится. Я думаю очень ограниченная ниша. Всё равно, потребление энергии даже в soc варианте будет не меньше 4 ватт. SoC combines an Intel Atom processor core, the memory controller hub, graphics engine and video engine into one chip. Вроде всё в это в Nxxx есть. Добавили контроллер памяти и назвали soc. Так вот почему интел миго пилит.

Я не очень понимаю кому оно надо. Наверное это все-таки скорее предназначено в кофеварки и стиральные машины, чем в телефоны.

в кофеварки и стиральные машины

graphics engine and video engine - интересное кино получается. Ну в китайские автомобили миго, я ещё понимаю. Не хрюшу же с кашперовским на бортовой компьютер ставить.

> Не хрюшу же с кашперовским на бортовой компьютер ставить.

Это infotainment. Если он зависнет, это не критично.

Это infotainment. Если он зависнет, это не критично.

Если он зависает - это бесит. А это критично на скорости 100+ км/ч.