x86 уже больше 30-ти лет. Настало время считать его смешным.
адекватнойДумается мне, ты хотел какое-то другое слово использовать
человеку, как виду, уже больше 50000 лет. Это уже смешно. Когда наконец-то появится новый вид?
x86 уже больше 30-ти лет. Настало время считать его смешным.То есть, итаниумы прошли мимо тебя?
Когда уже мы увидим повсеместное распространение более адекватной архитектуры?
человеку, как виду, уже больше 50000 лет. Это уже смешно. Когда наконец-то появится новый вид?Скорость эволюции человека на порядки меньше скорости эволюции процессоров. К чему ты это сказал?
Адекватной чему?
То есть, итаниумы прошли мимо тебя?Вот это, в частности, и расстраивает.
Вообще говоря, мне нравится AMD, но, ИМХО, если бы они в своё время не выпустили AMD64, то за счёт большего упора на развитие Itanium мы могли бы сегодня иметь более быстрые процессоры.
за счёт большего упора на развитие Itanium мы могли бы сегодня иметь более быстрые процессоры"Лучше день потерять, потом за пять минут долететь"
Быстрые процессоры - не самоцель, если что.
"Лучше день потерять, потом за пять минут долететь"Что-то я не понял, что ты хочешь этим сказать.
Быстрые процессоры - не самоцель, если что.
Применение для быстрых процессоров найти не проблема.
Ты с итаниумами работал? Видимо нет. То еще чудо: на ассемблере писать руками практически невозможно, нужен очень хороший компилятор. А если компилятор налажает - то все его теоретическое быстродействие идет коту под хвост.
Сейчас все идет к тому, что гораздо нужнее маложрущие процессоры во всякие девайсы типа мобильников, КПКшек, нетбуков. А в этой области ARM опережает x86.
Сейчас все идет к тому, что гораздо нужнее маложрущие процессоры во всякие девайсы типа мобильников, КПКшек, нетбуков. А в этой области ARM опережает x86.
мы могли бы сегодня иметь более быстрые процессорыМы и так сегодня имеем более быстрые процессоры. x86 упёрся ещё во времена Pentium2. Но благодаря RISC-ядру, мы имеем более быстрые процессоры.
Кстати, начала это тогда вроде тоже AMD, ну почти — они купили NexGen, которая это разрабатывала.Ты с итаниумами работал? Видимо нет. То еще чудо: на ассемблере писать руками практически невозможно, нужен очень хороший компилятор. А если компилятор налажает - то все его теоретическое быстродействие идет коту под хвост.Ты теорию написания компиляторов ботал?
Так вот, написать хороший компилятор для Itanium - плёвое дело в сравнении с написанием хорошего компилятора для x86, так как набор инструкций в первом более грамотный.
На ассемблерах уже давно почти никто не пишет.
Во-первых, помимо архитектуры бывает ещё реализация.
Во-вторых, для x86 его писать не надо
Во-вторых, для x86 его писать не надо
Мы и так сегодня имеем более быстрые процессоры.Очень сильно раздражает, когда люди притворяются, что они не поняли смысл фразы.
Но благодаря RISC-ядру, мы имеем более быстрые процессоры.А благодаря существованию CISC->RISC на кристалле более медленные, чем могли бы быть.
Во-первых, помимо архитектуры бывает ещё реализация.1) Продолжи мысль.
Во-вторых, для x86 его писать не надо
2) Заяви это разработчикам gcc и llvm. Кроме того, для Itanium уже тоже не надо.
Когда уже мы увидим повсеместное распространение более адекватной архитектуры?Что ты имел ввиду? Уже сейчас мы имеем, например, x86, x64, ARM, Sparc, MIPS, PPC и другие архитектуры, каждая из которых (ну, кроме SPARC) повсеместно распространена.
Что ты имел ввиду? Уже сейчас мы имеем, например, x86, x64, ARM, Sparc, MIPS, PPC и другие архитектуры, каждая из которых (ну, кроме SPARC) повсеместно распространена.Распространённость в десктопах.
1) Продолжи мысль.всё может казаться стройным и хорошим издалека, пока не начнёшь непосредственно вникать в сабж. Тогда может выясниться, что не всё так удачно, как казалось с начала, есть куча странных деталей и тонкостей. Говорить об удобных инструкциях процессора, не написав на тамошнем асме парочку прог, всё равно что покупать обувь без примерки
Распространённость в десктопах.декстопы покупает быдло, у быдла дурной вкус. Толпа решает
Так вот, написать хороший компилятор для Itanium - плёвое дело в сравнении с написанием хорошего компилятора для x86, так как набор инструкций в первом более грамотный.Почему тогда в gcc вместо хорошего, годного компилятора для итаниума стоит затычка, лишь бы работало. Дело-то плёвое.
Распространённость в десктопах.Десктопу уже больше 30 лет. Настало время считать его смешным.
Что такое десктоп, кстати, в твоем определении?
Почему тогда в gcc вместо хорошего, годного компилятора для итаниума стоит затычка, лишь бы работало. Дело-то плёвое.Потому что архитектура не распространённая.
Десктопу уже больше 30 лет. Настало время считать его смешным.Да я даже не стану спорить с первой фразой. Тем более, что послдение годы соотношение между числом ноутбуков и десктопов неуклонно растёт скорее всего.
Что такое десктоп, кстати, в твоем определении?
Предлагаю не играть в определения. Всем здесь интуитивно понятно что я имел ввиду под этим словом.
Предлагаю не играть в определения. Всем здесь интуитивно понятно что я имел ввиду под этим словом.Мне непонятно (это не троллинг). Неттоп — это десктоп в твоем определении?
Ты теорию написания компиляторов ботал?Да, это моя специальность. И работаю я сейчас по ней.
Так вот, написать хороший компилятор для Itanium - плёвое дело в сравнении с написанием хорошего компилятора для x86, так как набор инструкций в первом более грамотный.Откуда инфа? Ты хоть один из них писал?
Инструкции в том же GCC матчатся автоматически по шаблонам, причем весьма неплохо. Так что нужно только шаблоны написать. Так что "более грамотный" набор не сильно упрощает написание компилятора.
В итаниуме другие проблемы. При том, что мы теоретически можем выдать 6 инструкций за такт, чтобы этого достичь нужно упорядочивать инструкции с учетом бандлинга. Само по себе это несложно (для компьютера но... Out of order execution отсутсвует, так что нужно очень точно отслеживать замисимости по данным. Не уследили, неправильно предсказали ветвление, промахнулись мимо кэша - вся параллельная группа инструкций (6 штук) стоит ждет несколько тактов. Вместе со всем конвейером в середине какого-нибудь горячего цикла.
(происхождение информации: когда тьюнили selective scheduler в GCC я довольно много смотрел на профили программ, которые получались)
На ассемблерах уже давно почти никто не пишет.На асме часто выписывают тело самых горячих циклов, если компилятор с ними плоховато справляется (или ему поленились скормить нужные опции). С итаниумом залатать лажу компилятора руками не получится.
Мне непонятно (это не троллинг). Неттоп — это десктоп в твоем определении?Имхо, особой роли это не играет, поэтому пусть будет десктоп.
Имхо, особой роли это не играет, поэтому пусть будет десктоп.Тогда радуйся, через полторы недели будет анонсирована NVIDIA Tegra 2 и, насколько я знаю, один или более неттопов на ней. А это честный ARM + видюха от nvidia на том же кристалле. Full HD-ready, быстрее атомных неттопов, энергопотребление ниже, цена — скорее всего ниже.
С итаниумом залатать лажу компилятора руками не получится.Поясни, почему не получится?
Да, это моя специальность. И работаю я сейчас по ней.Где и над чем, если не секрет?
Откуда инфа? Ты хоть один из них писал?Сделал выводы из описаний.
Инструкции в том же GCC матчатся автоматически по шаблонам, причем весьма неплохо. Так что нужно только шаблоны написать. Так что "более грамотный" набор не сильно упрощает написание компилятора.А как там с распределением неравнозначных регистров?
В итаниуме другие проблемы. При том, что мы теоретически можем выдать 6 инструкций за такт, чтобы этого достичь нужно упорядочивать инструкции с учетом бандлинга. Само по себе это несложно (для компьютера но... Out of order execution отсутсвует, так что нужно очень точно отслеживать замисимости по данным. Не уследили, неправильно предсказали ветвление, промахнулись мимо кэша - вся параллельная группа инструкций (6 штук) стоит ждет несколько тактов. Вместе со всем конвейером в середине какого-нибудь горячего цикла.Теоретически: в x86 переупорядочиванием занимается часть схемы процессора, скорее всего за линейное или (уже не так вероятно) квадратичное время. Компилятор для итаниума может применять более сложные алгоритмы, так как у него нет жёстких временных рамок.
(происхождение информации: когда тьюнили selective scheduler в GCC я довольно много смотрел на профили программ, которые получались)Выше вон писали, что в gcc компилятор для itanium - заглушка "чтобы работало".
На асме часто выписывают тело самых горячих циклов, если компилятор с ними плоховато справляется (или ему поленились скормить нужные опции). С итаниумом залатать лажу компилятора руками не получится.Это где так? Недавно, кстати, в девелопменте выкладывали бумагу, объясняющую, почему так делать не надо.
Тогда радуйся, через полторы недели будет анонсирована NVIDIA Tegra 2 и, насколько я знаю, один или более неттопов на ней. А это честный ARM + видюха от nvidia на том же кристалле. Full HD-ready, быстрее атомных неттопов, энергопотребление ниже, цена — скорее всего ниже.
Да я радуюсь. Что NVIDIA понимает и, возможно, пользователей убедит.Но до захвата рынка пока, к сожалению далеко.
Вот по новым ядрам AMD пока мало инфы. Может они тоже готовят что-то отличное от x86. Но это скорее мечты, чем догадки.
Выше вон писали, что в gcc компилятор для itanium - заглушка "чтобы работало".Это ж не значит,что там ничего нет. До действительно эффективных алгоритмов еще очень далеко, да и вряд ли они уже появятся, но что-то все таки реализовано.
Full HD-readyпоясни этот термин?
Держит 1080p в h264 при fps=25,30? А при fps 120?
Сейчас информация про tegra 2 на уровне слухов и утечек, поэтому я сам не знаю, что именно под этим понимать. Я бы ориентировался на то, что можно будет подключить его к монитору с 1920x1280 и смотреть фильмы 1080p. Но зуб дать не могу, ждем CES 2010.
Инструкции в том же GCC матчатся автоматически по шаблонам, причем весьма неплохо. Так что нужно только шаблоны написать. Так что "более грамотный" набор не сильно упрощает написание компилятора.Я вот подумал. Вообще же бредовый вывод написан.
Да, сопоставление образцов - это хорошо. Но шаблоны на разных наборах инструкций должны быть разные. Где-то их больше, где-то меньше, где-то они сложные, где-то простые. Если машина чисто стековая и все инструкции выполняются одинаковое время, например, вообще тривиальнейшие шаблоны будут и их будет мало.
А как там с распределением неравнозначных регистров?Распределением регистров вообще отдельный пас занимается. Там только ограничения пишутся, какие аргументы где могут стоять. Если интересно, как ограничения писать, то читай
http://gcc.gnu.org/onlinedocs/gccint/Machine-Desc.html
Теоретически: в x86 переупорядочиванием занимается часть схемы процессора, скорее всего за линейное или (уже не так вероятно) квадратичное время. Компилятор для итаниума может применять более сложные алгоритмы, так как у него нет жёстких временных рамок.Существенная разница: процессор переупорядочивает во время выполнения, когда уже известно, попали мы в кэш или нет, выполнился условный переход или нет, в отличае от компилятора, который должен это как-то угадывать.
Это где так? Недавно, кстати, в девелопменте выкладывали бумагу, объясняющую, почему так делать не надо.В коде, связанном с кодриование/декодированием/обработкой видею очень часто такое встречается. Например ffmpeg, x264. Мы тут обсуждаем не то, как надо, а что делать, если компилятор облажался.
Так где ты всё-таки работаешь и над чем?
Как вариант, и, кстати, весьма разумный, писать разработчикам компилятора.
Распределением регистров вообще отдельный пас занимается. Там только ограничения пишутся, какие аргументы где могут стоять. Если интересно, как ограничения писать, то читайЭтот пасс никто не писал? Может он половину генератора кода занимает.
http://gcc.gnu.org/onlinedocs/gccint/Machine-Desc.html
Существенная разница: процессор переупорядочивает во время выполнения, когда уже известно, попали мы в кэш или нет, выполнился условный переход или нет, в отличае от компилятора, который должен это как-то угадывать.Кому известно, блоку переупорядочивания? И он всю эту информацию использует? Ссылку для подтверждения в студию.
В коде, связанном с кодриование/декодированием/обработкой видею очень часто такое встречается. Например ffmpeg, x264. Мы тут обсуждаем не то, как надо, а что делать, если компилятор облажался.Собственно, на вопрос ты не ответил (почему для Itanium руками не сделать).
Как вариант, и, кстати, весьма разумный, писать разработчикам компилятора.
Поясни, почему не получится?Затрахаешься динамическое распределение ресурсов статически планировать, вероятно.
Поясни, почему не получится?В том же посте ответ был, хоть и в неявном виде.
1) Бандлинг. Мы не можем выписывать инструкции в произвольном порядке, а должны следовать шаблонам.
2) 6 инструкций за такт плюс отсутствие out of order execution. Floating point операции занимают 4-6 тактов. Вот и получается, что между двумя последовательными (с точки зрения логики программы) инструкциями надо вставить 24-36 других. А их еще найти надо, а у них тоже зависимости и т.д.
Слишком объемная получается задача для человека.
Да, сопоставление образцов - это хорошо. Но шаблоны на разных наборах инструкций должны быть разные. Где-то их больше, где-то меньше, где-то они сложные, где-то простые. Если машина чисто стековая и все инструкции выполняются одинаковое время, например, вообще тривиальнейшие шаблоны будут и их будет мало.Написание шаблонов инструкций - задача довольно объемная, но у нее известно решение. А вот как получить эффективный код за разумное время никто точно не знает. Все оптимизации - это те или иные эвристики. Обычно они работают, но что делать, если для какой-то архитектуры их недостаточно?
Вот и получается, что для x86 .md файлик взяли и написали, а для итаниума все по прежнему работает не очень хорошо. И дело тут не в малой распространенности: Intel и HP вкладывали деньги в разработку GCC под Itanium.
Ты сознательно игнорируешь половину поста?
Написание шаблонов инструкций - задача довольно объемная, но у нее известно решение. А вот как получить эффективный код за разумное время никто точно не знает. Все оптимизации - это те или иные эвристики. Обычно они работают, но что делать, если для какой-то архитектуры их недостаточно?Я вот не пойму. Тебе есть с чем сравнивать? Ну так и приведи сравнение.
Вот и получается, что для x86 .md файлик взяли и написали, а для итаниума все по прежнему работает не очень хорошо. И дело тут не в малой распространенности: Intel и HP вкладывали деньги в разработку GCC под Itanium.Зачем интелу, у которого есть собственный компилятор, вкладывать деньги в разработку GCC под итаниум? Ссылку в студию.
Клевая у тебя позиция, как я посмотрю: сам ни компилятора не писал, ни итаниум ни разу не видел, зато про собеседника пишешь, что "для адекватной оценки он ещё должен заниматься компиляторами для x86". Потом на каждое утверждение начинаешь требовать ссылку.
Хотя часть из них находится без проблем гуглом, как например про
"Кому известно, блоку переупорядочивания? И он всю эту информацию использует? Ссылку для подтверждения в студию."
http://en.wikipedia.org/wiki/Out-of-order_execution
или
"Этот пасс никто не писал? Может он половину генератора кода занимает."
http://gcc.gnu.org/gcc-4.4/changes.html
"Зачем интелу, у которого есть собственный компилятор, вкладывать деньги в разработку GCC под итаниум?"
Да потому что их процессор нафиг никому не нужен, если на нем нет хорошо работающего ПО. А GCC притащит за собой GNU/Linux.
А некоторые я вообще понять не могу:
"Тебе есть с чем сравнивать? Ну так и приведи сравнение."
Чего с чем сравнивать?
В данный момент разговор идет крайне односторонне: я оперирую конкретными фактами, а ты - общими рассуждениями. Так что если есть, что конкретное сказать, то говори. А если нет - так давай заканчивать этот разговор.
Хотя часть из них находится без проблем гуглом, как например про
"Кому известно, блоку переупорядочивания? И он всю эту информацию использует? Ссылку для подтверждения в студию."
http://en.wikipedia.org/wiki/Out-of-order_execution
или
"Этот пасс никто не писал? Может он половину генератора кода занимает."
http://gcc.gnu.org/gcc-4.4/changes.html
A new register allocator has replaced the old one. It is called integrated register allocator (IRA) because coalescing, register live range splitting, and hard register preferencing are done on-the-fly during coloring. It also has better integration with the reload pass. IRA is a regional register allocator which uses modern Chaitin-Briggs coloring instead of Chow's priority coloring used in the old register allocator. More info about IRA internals and options can be found in the GCC manuals.До ответов на часть впоросов можно догадаться самому:
"Зачем интелу, у которого есть собственный компилятор, вкладывать деньги в разработку GCC под итаниум?"
Да потому что их процессор нафиг никому не нужен, если на нем нет хорошо работающего ПО. А GCC притащит за собой GNU/Linux.
А некоторые я вообще понять не могу:
"Тебе есть с чем сравнивать? Ну так и приведи сравнение."
Чего с чем сравнивать?
В данный момент разговор идет крайне односторонне: я оперирую конкретными фактами, а ты - общими рассуждениями. Так что если есть, что конкретное сказать, то говори. А если нет - так давай заканчивать этот разговор.
Когда уже мы увидим повсеместное распространение более адекватной архитектуры?лисп-машины, например?
Клёвая позиция у тебя. Если ты писал только компилятор для Itanium, на основании чего ты полагаешь, что компилятор в x86 писать проще?
Да вот передо мной лежит AMD Althon 64 x2 4800+, я его вижу, это что-то меняет? Спеки я читал и для Itanium'a и для x86. C первым просто не приходилось работать.
Что ты делаешь из туманной фразы "работаю по специальности" не понятно.
Более того здесь: http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2748&... на схеме Intel Core видна Branch Prediction Table, что означает, что произойдёт переход или нет процессор не знает. Да, используется динамический алгоритм на основе истории прошлых переходов с этого адреса, но не более того.
Соответственно, твоё утверждение про переходы я опроверг. Подтверждения утверждения про кэш я не вижу. Более того, если я правильно понял картинку по ссылке, то наличие данных в кэше алгоритм переупорядочивания тоже не учитывает, а есть только блок переупорядочивания обращений в память, который работает уже после разбиения и упорядочивания инструкций.
Имхо, общие рассуждения лучше, чем "один работающий по специальности компиляторов сказал" в таком ключе.
Да вот передо мной лежит AMD Althon 64 x2 4800+, я его вижу, это что-то меняет? Спеки я читал и для Itanium'a и для x86. C первым просто не приходилось работать.
Что ты делаешь из туманной фразы "работаю по специальности" не понятно.
"Кому известно, блоку переупорядочивания? И он всю эту информацию использует? Ссылку для подтверждения в студию."По ссылке нигде не написано, что алгоритм переупорядочивания знает о том, попадём мы в кэш или нет и угадаем мы переход или нет.
http://en.wikipedia.org/wiki/Out-of-order_execution
Более того здесь: http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2748&... на схеме Intel Core видна Branch Prediction Table, что означает, что произойдёт переход или нет процессор не знает. Да, используется динамический алгоритм на основе истории прошлых переходов с этого адреса, но не более того.
Соответственно, твоё утверждение про переходы я опроверг. Подтверждения утверждения про кэш я не вижу. Более того, если я правильно понял картинку по ссылке, то наличие данных в кэше алгоритм переупорядочивания тоже не учитывает, а есть только блок переупорядочивания обращений в память, который работает уже после разбиения и упорядочивания инструкций.
A new register allocator has replaced the old one.OK, так понятно, что в аллокатор у них один на все архитектуры.
Да потому что их процессор нафиг никому не нужен, если на нем нет хорошо работающего ПО. А GCC притащит за собой GNU/Linux.Itanium вместе с HP делался и в составе серверов HP и Intel продвигался. Думаю, им было класть на Linux, ибо собственные ОС имели.
Чего с чем сравнивать?Разработку компиляторов для x86 и для Itanium.
В данный момент разговор идет крайне односторонне: я оперирую конкретными фактами, а ты - общими рассуждениями. Так что если есть, что конкретное сказать, то говори. А если нет - так давай заканчивать этот разговор.Ну да, как же. Что бы убедиться, что ты не оперируешь фактами достаточно посмотреть на твой промах про кэш и переходы. Кстати, вот тебе и пример конкретных рассуждений, если тебе не нравятся общие.
Имхо, общие рассуждения лучше, чем "один работающий по специальности компиляторов сказал" в таком ключе.
Ну да, как же. Что бы убедиться, что ты не оперируешь фактами достаточно посмотреть на твой промах про кэш и переходы. Кстати, вот тебе и пример конкретных рассуждений, если тебе не нравятся общие.Имхо, общие рассуждения лучше, чем "один работающий по специальности компиляторов сказал" в таком ключе.о да, ты мастерски опроверг его утверждения фактом отсутствия упоминания об этом в педивикии
о да, ты мастерски опроверг его утверждения фактом отсутствия упоминания об этом в педивикииВообще-то речь о ссылке на внутреннее строение Intel Core.
BTW. кто-то из админов/модераторов - мудак.
Что ты делаешь из туманной фразы "работаю по специальности" не понятно.Мне не понятно, какое это имеет отношение к вопросу. Раз это тебя так интересует, то работаю я в отделе компиляторных технологий ИСП РАН.
Спеки я читал и для Itanium'a и для x86.
Я писал не "попадём мы в кэш или нет" а "попали мы в кэш или нет". Прошедшее время, а не будущее.
Поясню подробнее.
Если в результате промаха по кэшу во время загрузки данных использование этих данных простаивает, то процессор это "видит" и переставляет использование этих данных с соседними инструкциями. Компилятор же работает раньше, когда загрузка еще не произошла, и знать, попадет она в кэш или нет не может.
То есть процессор на ходу разруливает ситуации простоя, когда они уже возникли, а компилятор должен генерировать код, в котором их возникать не будет.
Думаю, им было класть на Linux, ибо собственные ОС имели.Ну ты думай, а я зарплату из этих денег получал, когда занимался selective scheduler'ом.
Что бы убедиться, что ты не оперируешь фактами достаточно посмотреть на твой промах про кэш и переходы.Не было промаха, ты не внимательно прочитал или не правильно понял.
А GCC притащит за собой GNU/Linux.А
а им что-нить гнутое собирается?
А может ты не понял. Я сказал, что за счёт использования в ядре RISC-архитектуры мы имеем более быстрые процессоры. Причём совершенно не факт, что просто RISC-процессоры мы имели бы намного быстрее. Преобразование CISC-кода в микрокод, на сколько я представляю, в современных процессорах не в основных задачах находится, поэтому не стоит так много внимания уделять "внешней" архитектуре.Мы и так сегодня имеем более быстрые процессоры.Очень сильно раздражает, когда люди притворяются, что они не поняли смысл фразы.
Почему это?Но благодаря RISC-ядру, мы имеем более быстрые процессоры.А благодаря существованию CISC->RISC на кристалле более медленные, чем могли бы быть.
Мне не понятно, какое это имеет отношение к вопросу. Раз это тебя так интересует, то работаю я в отделе компиляторных технологий ИСП РАН.Эту тему поднял кто-то другой. Я просто стараюсь не закрывать поднятые вопросы без ответа.
Я писал не "попадём мы в кэш или нет" а "попали мы в кэш или нет". Прошедшее время, а не будущее.Спасибо, так гораздо понятнее. Я действительно неправильно тебя понял.
Поясню подробнее.
Если в результате промаха по кэшу во время загрузки данных использование этих данных простаивает, то процессор это "видит" и переставляет использование этих данных с соседними инструкциями. Компилятор же работает раньше, когда загрузка еще не произошла, и знать, попадет она в кэш или нет не может.
То есть процессор на ходу разруливает ситуации простоя, когда они уже возникли, а компилятор должен генерировать код, в котором их возникать не будет.
Но тогда откуда ты знаешь, что это применяется в современных x86?
Ну ты думай, а я зарплату из этих денег получал, когда занимался selective scheduler'ом.Так бы сразу и сказал.
Не было промаха, ты не внимательно прочитал или не правильно понял.ОК, я неправильно понял.
Всё же остаётся вопрос про переходы. Где используется информация о том, что был совершён переход? Ты имеешь ввиду предсказание перехода в зависимости от прошлой истории переходов в этом месте и/или по этому адресу?
Почему это?Вместо декодера можно было бы положить ещё один ALU, например, если бы поместился.
Вместо декодера можно было бы положить ещё один ALU, например, если бы поместился.А ты думаешь, что это декодер мешает положить ещё один ALU?
А ты думаешь, что это декодер мешает положить ещё один ALU?В частности. У тебя есть другие варианты?
возьми ГПУ — там АЛУ дохуя, но чтоб заставить всё это считать что-то поинтереснее перемножения матриц нужно очень постараться.
Мне всегда казалось, что гнутое стараются делать предельно портативным, ня?
портируй ка на МСВС MSVS что-нить гнутое =)
В частности. У тебя есть другие варианты?По-моему сам декодер место не очень много занимает. Там всякиее другие хрени большую часть кристалла покрывают. Кеш само собой дохера занимает, всякие регистровые буферы, ALU и прочие подсистемы. Думаю, что дело уж точно не в площади, а в том как это всё вместе уже заставить работать, причём вся "эта работа" уже не зависит от x86 почти.
В ответ на:и все они бывают в десктопах и игровых приставках, иногда в PLC контроллерах и прочей фигне
Что ты имел ввиду? Уже сейчас мы имеем, например, x86, x64, ARM, Sparc, MIPS, PPC и другие архитектуры, каждая из которых (ну, кроме SPARC) повсеместно распространена.
Распространённость в десктопах.
ICC не притащит за собой GNU/Linux?ICC не соберет ядро, в первую очередь.
у x86 есть еще одно преимущество - очень компактно закодированная последовательность инструкций, как => для тех же параметров надо меньше кэша, меньше пропускной способности памяти.
Intel пишет, что какбэ особых проблем там нет -
http://software.intel.com/en-us/articles/intel-c-compiler-fo...
http://cache-www.intel.com/cd/00/00/28/47/284736_284736.pdf
http://software.intel.com/en-us/articles/intel-c-compiler-fo...
http://cache-www.intel.com/cd/00/00/28/47/284736_284736.pdf
Но тогда откуда ты знаешь, что это применяется в современных x86?Я привел основные идеи out-of-order execution. Я ничего не говорил про конкретную реализацию в каком-либо процессоре.
Более того, я нигде не утверждал, что в x86 оно есть.
Более того, оно есть не во всех процессорах семейства x86.
Собственно, что я пытаюсь объяснить, так это то, почему твое предположение
в x86 переупорядочиванием занимается часть схемы процессора, скорее всего за линейное или (уже не так вероятно) квадратичное время. Компилятор для итаниума может применять более сложные алгоритмы, так как у него нет жёстких временных рамок.работает не так хорошо, как ты думаешь.
Всё же остаётся вопрос про переходы. Где используется информация о том, что был совершён переход? Ты имеешь ввиду предсказание перехода в зависимости от прошлой истории переходов в этом месте и/или по этому адресу?Тут ситуация такая же, как и с кэшем: от того, по какому пути пошло выполнение, зависит сколько тактов прошло между DEF'ом и USE'ом, то есть будет простой или нет. Процессор разбирается с простоем, когда он уже возник, а компилятор должен генерировать код так, чтобы простои не возникали.
у x86 есть еще одно преимущество - очень компактно закодированная последовательность инструкций, как => для тех же параметров надо меньше кэша, меньше пропускной способности памяти.по сравнению с чем? даже с иа64 спорно, а с армом вообще смешно сравнивать.
проблема больше в промахах а не в объёме или (лол) в пропускной способности.
с армом вообще смешно сравнивать.а все-таки, есть где-нибудь сравнения компактности кода x86 с ARM Thumb, например? Ну, или хотя бы с обычным ARM. Я чо-то ключевые слова найти не смог.
upd. Я нашел такие цифры (первые три компилятора из C в Thumb ARM, последний — C в x86)::
name C2tA C2tB C2tC C2x86
099.go 103,948 110,722 133,130 171,247
124.m88 52,642 52,684 57,228 79,188
126.gcc 502,142 502,806 542,302 823,237
130.li 20,536 21,232 21,454 38,039
132.ijpeg 64,450 56,246 83,100 112,028
147.vortex 232,872 266,972 239,520 364,618
176.gcc 611,924 581,716 626,746 1,250,740
186.crafty 92,478 84,664 99,468 173,753
197.parser 40,936 41,216 68,426 69,821
254.gap 218,464 217,654 250,736 270,740
255.vortex 238,090 266,972 239,520 369,010
300.twolf 114,522 108,744 117,156 168,065
Вроде, ARM после появления Thumb и Thumb-2 стал более компактный.
http://ramlamyammambam.livejournal.com/44265.html тут по числу команд, а по байтам thumb конечно порвёт
а вот, в каментах
http://ramlamyammambam.livejournal.com/44265.html?thread=268...
там дальше в каментах эльбрус рвёт всех, так что товарищу предлагаю дрочить на него
а вот, в каментах
http://ramlamyammambam.livejournal.com/44265.html?thread=268...
Компактность кода это отдельный вопрос. Вот, к примеру, размер кода embedded-реализации TCP/IP для трех архитектур. Компилятор GCC 4.1.2, оптимизация "-Os". В байтах:зы
Thumb - 14377
i386 - 20862
ARM - 21017
Нечетные значения - по причине размещения текстовых строк в том же сегменте, кто и код. Интел не сильно лучше чем ARM, а 16-битный Thumb заметно компактнее.
там дальше в каментах эльбрус рвёт всех, так что товарищу предлагаю дрочить на него
CSiBE
на их наборе thumb < i386 < x86_64 < arm
на их наборе thumb < i386 < x86_64 < arm
Ок, похоже техника откладывания инструкций с кэш-промахами реализована во всех или почти во всех x86 с out-of-order. В итаниумах с 2006-ого используется технология coaerse multithreading (http://en.wikipedia.org/wiki/Itanium#Architectural_changes что не решает проблему с однопоточными приложениями, но даёт возможность избавиться от неё для многопоточных, чего на мой взгляд достаточно для компенсации.
Про переходы не понял.
Про переходы не понял.
Интересно сохранился ли в рабочем состоянии хотя бы один комп этой архитектуры 30-летней давности. Я имею в виду непрерывное использование машинки 
Интересно сохранился ли в рабочем состоянии хотя бы один комп этой архитектуры 30-летней давности. Я имею в виду непрерывное использование машинкиНе знаю как 30, а 15 у меня есть. :-]
Не знаю как 30, а 15 у меня есть. :-]У нас на работе стоит 94-95 года 486-ой. Жив курилка!
Мне даже стало интересно, куда делись компы фирмы Sanyo с зелёными мониторами (сами компы были совмещены с клавиатурами, а мониторы умели показывать ровно три оттенка нежного зелёного цвета) и 286-ой (учительский, с цветным дисплеем и двумя флопиками 5,25”!) комп из нашего компьютерного класса. Они, наверное, из начала 90-х были…
Помнится, у меня в то время уже был 386SX с 1 МБ памяти. А потом ведь добавили ещё два! И там был потом Саундбластер 16, перекочевавший потом в два других компа. И Transport Tycoon, да!
Чо-то меня прорвало.
Помнится, у меня в то время уже был 386SX с 1 МБ памяти. А потом ведь добавили ещё два! И там был потом Саундбластер 16, перекочевавший потом в два других компа. И Transport Tycoon, да!
Чо-то меня прорвало.
Оставить комментарий
agaaaa
Когда уже мы увидим повсеместное распространение более адекватной архитектуры?