Так, а он не память, нет? А откуда берётся стоимость промаха?

Память, естественно. О каких промахах ты сейчас говоришь?

И как это сказывается на исполнении типичных задач процессором общего назначения?

Типичные задачи общего назначения требуют тоже до фига регистров.

Проведи такой эксперимент - возьми любое «типичное» приложение. Например, MySQL. Скомпиляй под x86_32, и посчитай среднее число спиллов на функцию. Потом сделай то же самое для ARM или IA64, и сравни. Разница будет в несколько раз, и не в пользу IA32.

И сколько времени займёт загрузка всех регистров данными для следующего «весьма сложного выражения»?

Идиот!

Итак, вот тебе, ничтожество, еще одна задача. Есть выражение, для определенности целочисленное: z = x*x + y*y + 2*x*y; Сколько регистров надо, чтобы его вычислить? А данных мы загружаем тут только x и y.

Да, и являются ли эти «весьма сложные выражения» типичной задачей для процессоров общего назначения?

Да, являются. Криптография, графика (даже десктопная), игры (чтоб им пусто было), СУБД всякие.

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

Т.е. получается, что большое количество регистров не только бессмыссленно, но ещё и вызывает дикое увеличение сложности кристалла?

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

В том же Intel, если ты еще не прочитал ссылку выше, внутренний регистровый файл состоит из 40 регистров. Это очень немало. Добавь к этому огромную и сложную таблицу register aliasing (наверняка с большим числом портов), и одного только этого хватит, чтобы весь Pentium 1 разместить, возможно еще и с кешем.

Кстати, прежде чем нести пургу дальше, ознакомься хотя бы вот с этим: http://en.wikipedia.org/wiki/Classic_RISC_pipeline

Просто чтобы понимать те слова, которые я использую. И чтобы не путать кеш-промах и pipeline flush.

Кем отмечено, мразь?

Gjkmpjdfntktv Dark_SavanT, мой любезный друг: Знание об архитектуре компьютера (комментарий)

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

Ну так не RISC же

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

Да-да, кривой, уродливый, но живой. А риск почему-то не очень.

Вот кстати, почему бы интелу не сделать чип только с RISC без x86 эмуляции в виде конкурента армам? Если уж X86 оно молотит шустро, то на родном коде будет гораздо интереснее.

Там не RISC-овские команды, да и объём инструкций в микрокодах каков по-твоему должен быть? Я думаю он большую часть времени будет проводить ожидая очередную микрокоманду, да и пользы от пайплайнов будет меньше.

Ну так не RISC же

VLIW. То есть, еще тупее, чем RISC. Это RISC с еще более тупым декодером и отрезанным начисто hazard prediction механизмом.

Да-да, кривой, уродливый, но живой.

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

А риск почему-то не очень.

RISC процессоров выпущено и используется в разы больше, чем x86. Так что гуляло бы ты мимо, тупое ничтожество.

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

Там не RISC-овские команды,

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

да и объём инструкций в микрокодах каков по-твоему должен быть

До 6 микроинструкций на одну инструкцию x86.

Я думаю он большую часть времени будет проводить ожидая очередную микрокоманду,

Нет. Меньше ветвлений, проще prefetch.

да и пользы от пайплайнов будет меньше.

Что?!? Бредишь? В x86 микроинструкции по пайплайнам разбрасывает железо. А оно тупое и у него мало времени что-либо умное сделать. Если же эту часть железа вообще устранить, и предоставить умному компилятору (у которого вагон времени) самому решать, в каком порядке инструкции расположить, то скорость существенно возрастет. Тут та же история, что и с VLIW/EPIC против RISC - компилятор всегда умнее железа и знает гораздо больше о коде.

До 6 микроинструкций на одну инструкцию x86.

и по машинному такту на выборку каждой из них.. Это во сколько раз оно должно быть медленнее?

и по машинному такту на выборку каждой из них.. Это во сколько раз оно должно быть медленнее?

Опять чушь. Единственная причина, почему тумб быстрее арма, например - больше в кеш помещается.

О каких промахах ты сейчас говоришь?

На ветвлении, ошибка branch prediction. Но, впрочем, ладно тут пожалуй ты прав и чем больше стадий в пайплайне - тем больше тактов будет утрачено на следующую команду.

Типичные задачи общего назначения требуют тоже до фига регистров.

Желательно несколько гигабайт..

Проведи такой эксперимент - возьми любое «типичное» приложение. Например, MySQL. Скомпиляй под x86_32, и посчитай среднее число спиллов на функцию.

Под x86_64 сойдёт? Как считать среднее число спиллов на функцию?

Потом сделай то же самое для ARM или IA64, и сравни. Разница будет в несколько раз, и не в пользу IA32.

Так, а что покажут тесты производительности?

Итак, вот тебе, ничтожество, еще одна задача. Есть выражение, для определенности целочисленное: z = x*x + y*y + 2*x*y; Сколько регистров надо, чтобы его вычислить? А данных мы загружаем тут только x и y.

Да, являются. Криптография, графика (даже десктопная), игры (чтоб им пусто было), СУБД всякие.

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

Так и конвейер вызывает дикое увеличение сложности кристалла.

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

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

К частоте-то какое отношение?

В том же Intel, если ты еще не прочитал ссылку выше, внутренний регистровый файл состоит из 40 регистров.

Ссылку на Classic RISC pipeline? Посмотрел. При чём тут Интел? Так у него больше или меньше регистров?

Это очень немало. Добавь к этому огромную и сложную таблицу register aliasing (наверняка с большим числом портов), и одного только этого хватит, чтобы весь Pentium 1 разместить, возможно еще и с кешем.

Единственная причина, почему тумб быстрее арма, например - больше в кеш помещается.

Что мешает делать ARM с нормальным кешем?

и по машинному такту на выборку каждой из них.. Это во сколько раз оно должно быть медленнее?

Опять чушь.

От чего же чушь? Выше ты приводил ссылку на то как работает рисков пайплайн: http://en.wikipedia.org/wiki/Classic_RISC_pipeline - там английским по белому написано, что на выборку каждой команды из SRAM затрачивается один машинный цикл.

То, что «нормальный» кеш греет как паяльник в жопе. У ARM-ов же другие применения.

Тогда я не понимаю, почему мы сравниваем интеловскую архитектуру с процессорами, у которых «другие применения».

На ветвлении, ошибка branch prediction. Но, впрочем, ладно тут пожалуй ты прав и чем больше стадий в пайплайне - тем больше тактов будет утрачено на следующую команду.

Ошибка branch prediction означает, что результаты исполнения всех команд, которые сейчас в пайплайне, должны быть выброшены на хер, а пайплайн надо очистить и начать заполнять заново. Чем он длиннее, тем это больнее.

Желательно несколько гигабайт..

Опять бредишь. Это выражение какой вложенности нужно?!?

Под x86_64 сойдёт? Как считать среднее число спиллов на функцию?

Не сойдет - это уже другая архитектура. Хотя, тоже должна слить ARM-у или итаниуму. Считать, например, с помощью llvm (для gcc это будет сложнее сделать), надо немного хакнуть его SelectionDag.

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

Идиот. Даже твой убогий вебик тормозить будет, там везде SSL.

То же самое и с графикой.

Отними у юзеришек графику, посмотрим, как они взвоют.

СУБД большую часть жизни проводит в ожидании данных с диска и сканировании огромных массивов данных в памяти - там тебя не выручают ни сорок ни восемьдесят ни сто восемьдесят регистров.

Идиот. Ты и про устройство СУБД, оказывается, ни черта не знаешь.

Зачем ты имеешь свое мнение, если ты вообще ни в чем не разбираешься?!?

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

«риски сливают» только в том жидком говне, которое наполняет твою гнилую черепушку.

К частоте-то какое отношение?

Сказочный идиот!!!

Зачем, по-твоему, нужен конвейер, а, придурок? Чем короче максимальный data path, тем выше частота.

сылку на Classic RISC pipeline? Посмотрел. При чём тут Интел? Так у него больше или меньше регистров?

Нет, на intel decoder. Там сказано, что у RISC-ядра Intel файл в сорок 64-битных (!!!) регистров. Больше чем у большинства RISC-ов, за исключением всяких там GPU (где вообще по 128 регистров на ядро).

Тогда я не понимаю, почему мы сравниваем интеловскую архитектуру с процессорами, у которых «другие применения».

Ну тогда ты дебил, а мамка твоя - шлюха-наркоманка. Других объяснений таких отклонений я не нахожу.

Ну тогда ты дебил

Почему же я? Ведь это не я, а ты сравниваешь тёплое с мягким.

Я утверждаю, что архитектура x86 уродливая и устаревшая, поскольку, во первых, не допускает эффективной компиляции в силу нехватки регистров общего назначения (как результат - ТОРМОЗА от спиллов в стек) и при реализации в железе выливается в уродливую и тяжеловесную надстройку над нормальной архитектурой (RISC, то есть), и как результат - ТОРМОЗА и расход энергии.

Мнэээ... а разве там не происходит ремапинга логических регистров на физические, аппаратные? этой самой надстройкой? хз насколько эффективно

Происходит. Неэффективно. Компилятор это делает умнее чем железо. Я уж не говорю про накладные расходы на сам этот мапинг.

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

В виденых мной случаях, соотношение MIPS/MHz в сравнении армов с интелами у интела было лучше.

А можно по-конкретней про такие случаи ? и желательно чтобы на arm код был собран не убогим gcc а хотя бы стареньким rvct.

Ошибка branch prediction означает, что результаты исполнения всех команд, которые сейчас в пайплайне, должны быть выброшены на хер, а пайплайн надо очистить и начать заполнять заново. Чем он длиннее, тем это больнее.

Ну да, я это и написал.

Опять бредишь. Это выражение какой вложенности нужно?!?

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

Не сойдет - это уже другая архитектура.

Но это же интеловская архитектура! А ты говорил, что она кривая.

Хотя, тоже должна слить ARM-у или итаниуму. Считать, например, с помощью llvm (для gcc это будет сложнее сделать), надо немного хакнуть его SelectionDag.

Казалось бы такой важный параметр, а нет готовых средств для анализа?

Идиот. Даже твой убогий вебик тормозить будет, там везде SSL.

Какая часть загрузки «вебика» приходится на SSL по-твоему?

Отними у юзеришек графику, посмотрим, как они взвоют.

Ну так Гуй и не съедает львиную долю ресурсов машины. Иначе кому он был нужен.

Идиот. Ты и про устройство СУБД, оказывается, ни черта не знаешь.

Конечно. Расскажи мне про устройство СУБД. мне очень интересно твоё представление.

«риски сливают» только в том жидком говне, которое наполняет твою гнилую черепушку.

Не распарсил. РИСКИ сливают В МОЗГАХ? Следует ли понмать твоё высказывание так, что если бы разработчикам РИСКОВ господь даровал мозги, то они бы сделали процессор с архитектурой, похожей на интеловскую?

Зачем, по-твоему, нужен конвейер, а, придурок? Чем короче максимальный data path, тем выше частота.

Какая частота? Тактовая?

Нет, на intel decoder. Там сказано, что у RISC-ядра Intel файл в сорок 64-битных (!!!) регистров. Больше чем у большинства RISC-ов, за исключением всяких там GPU (где вообще по 128 регистров на ядро).

Значит он лучше RISC'a?

Вообще, бредовый спор. POWER уделывает Intel в хвост и в гриву.

Эндрю Таненбаум. Архитектура компьютера. 5-е изд. (+CD)

Советую начать со старого доброго Эндрю Таненбаума Архитектура компьютера. 5-е изд. (+CD)

на ozon.ru

на books.ru

или на rutracker.org

Значит он лучше RISC'a?

Он и есть RISC, только обгаженный декодером для устаревшей и нелепой ISA.

Какая частота? Тактовая?

Естественно.

В общем, школота, надоел ты мне. Ты слишком тупой, чтобы продолжать над тобой издеваться. Фанбои интела все такие, что ли?

Ага. И марсоходы сделаны на Power, а не на убогом x86

Практического применения асму нет

А какже реверс и крекинг?

Школьникам всё равно не хватит мозгов на реверс серьёзных обфусцированных проприетарных поделок.

Но это не значит что асм не нужен. Напротив.

Он и есть RISC, только обгаженный декодером для устаревшей и нелепой ISA.

Ога. И с более ёмкими командами, позволяющими лучше утилизовать кеш.

> Какая частота? Тактовая?

Естественно.

С дуба рухнул? Как тактовая частота зависит от длины data path? Ты вообще понимаешь о чём ты разговариваешь? А то знай только сыплешь ссылками, которые тебя же самого опровергают.

В общем, школота, надоел ты мне. Ты слишком тупой, чтобы продолжать над тобой издеваться. Фанбои интела все такие, что ли?

Так и скажи что был не прав. Что уж тут юлить и валить на собеседника собственные грешки.

Да ты, по ходу, совсем ничтожнон и жалкое быдло, которое в принципе не способно понимать электронику. Объясняю для грязной школоты: чем длиннее data path, тем больше времени надо на стабилизацию сигнала на его выходе.

Упражнение для грязной школоты: попробуй реализовать 32-битное умножение за один такт без таблиц, на ПЛИС Virtex-6 доя определенности. И скажи после этого, говно, какая максимальная тактовая частота у тебя получилась. Сравни с конвейером в пять шагов, признай себя мразью и умри от стыда.

В тумбе инструкции намного более емкие.

Объясняю для грязной школоты: чем длиннее data path, тем больше времени надо на стабилизацию сигнала на его выходе.

Нук раскрой-ка поподробнее:

1. Что конкретно ты называешь data path

2. О каком именно выходе речь

3. С чего ты взял, что время стабилизации сигнала на выходе зависит от data path, а не от электрических свойств собственно выхода?

И скажи после этого, говно, какая максимальная тактовая частота у тебя получилась.

Дай угадаю. Тактовая частота ПЛИС?

P.S.

Можно только удивляться как тебя с твоими представлениями о работе компьютеров до сих пор не погнали из слесарного цеха.

Я просто фалломорфирую от такого зашкалмвающего агрессивного невежества. Решай задачу, мразь! Не понимаешь плис - делай сразу на asic, техпроцесс и библиотека компонент на твой выбор.

И почитай учебники, ничтожество.

Кстати, посмеши еще раз почтенное собрание, школятина. Попробуй рассказать, что такое «частота ПЛИС».

Подскажите эмулятор микропроцессора/микроконтроллера и что-то типа proteus под ubuntu.