Ждём Ваших отзывов о материале.
Соблюдение Правил конференции строго обязательно!
Флуд, флейм и оффтоп преследуются по всей строгости закона!

а что корни выходят на рынок в 4 квартале 2007 года ?

в третьем квартале
К10 кстати тоже в третьем

MAS

А выйдет ли? Что-то уже не верится. Ноябрь-Декабрь уже пророчат....

MAS

А с чего вы решили что он сложный? Он большой (по площади), но большой - не значит сложный (то есть не значит, что микроархитектурно он сложнее Core).

И откуда люди берут такую траву? С чего это вы решили что SSE4 присутствуют в нынешник Корах в залоченном виде? Опять хрустальный шар нашептал?

вы не ответили на вопрос
1 нужно ли для добавления новых инструкций переделывать FPU, а не просто добавить
2 так ли сильно его надо переделывать
P.S. на IXBT лежит обзор VIA C3, да жутко старый и ни кому не интересный но там в в выводах есть любопытные рассуждения про SSE
http://www.ixbt.com/cpu/via-c3-nehemiah.shtml
Добавлено спустя 8 минут, 1 секунду

ни чего там не нужно, добавлять сейчас не будут позже вполне

Dogmatik

А что значит "просто добавить"? Что добавить и как добавить?

Ну давайте подсчитаем:
1. Декодер нужно переделать - должен опозновать новые команды и генерировать соответствующие микроинструкции.
2. Шедулер нужно переделать - должен уметь опозновать новые микроинструкции и направлять на соответсвующие порты.
3. Некоторые порты и исполнительные юниты нужно переделать - должны уметь принимать и исполнять новые микроинструкции.
4. В случае с инструкцией MOVNTDQA необходимо ещё серьёзно переделать MMU.
5 ... и т.д. и т.п.
Короче, как на это не посмотри, но переделка затронет как миннимум половину блоков процессора. Часть инструкций можно реализовать с помощью микрокода, только толк от этого будет нулевой (если не со знаком минус).
Небольшое отступление по поводу того, как всё это работает:
Я думаю, вам известно, что все CPU последнего поколения не исполняют x86 код "напрямую", а транслируют его во "внутренние" микроинструкции, которых намного меньше чем инструкций в х86 со всеми его расширениями. Например инструкция mov [Х], AX транслируется в три микроинструкции - загрузить содержимое адреса Х из памяти в регистер, прибавить к нему содержимое регистра AX, выгузить полученный результат обратно в адрес X.
Многие математические операции (например тригонометрические функции) слишком затратно реализовывать в железе, но поскольку, почти любое математическое действие можно представить как определённую последовательность простейших операций умножения и сложения, то в CPU есть специальный блок, microcode sequencer, который получая инструкцию, например, синуса, генерируют цепочку простых микроинструкций (сложений/вычитаний/умножений). Проблема в том, что такие цепочки исполняются слишком долго. Поэтому в Интеле и занимаются поиском таких распространённых математических операций, которые можно выполнить одной микроинструкцией (соответвенно спроектировав исполнительный блок). Например инструкцию DPPS из SSE4 (скалярное умножение векторов - расспространнёная операция в графикe) можно реализовать и с помощью микрокода, но и выполнятся такая инструкция будет не быстрее, чем обычная програмная реализация этой математической операции.

ну вообще-то полезно хоть изредка почитывать зарубежные форумы

надо переделывать FPU с нуля или нет? да/нет

че тут считать: "так ли сильно его надо переделывать" - вопрос относился конкретно к FPU.

Dogmatik
да, надо сильно переделывать

Согласен, надо доделать. Что Интелу, что АМД. Никакой разницы.
Кстати говоря, чтобы добавить десяток команд (на фоне нескольких сотен), никакой особой переделки не требуется. Чуток расширить список - не то же самое, что добавить с нуля все команды.


Это АМД вообще не касается, поскольку жесткой привязки к портам, как у Core 2, у К8/К10 нет (точнее, ее гораздо меньше). Так что шедулер пришлось переделывать Интел


В этом месте не соглашусь. Никаких "новых микроинструкций". Напротив, вся суть нынешней технологии преобразования х86 в микро-, макро-, и прочие инструкции в том, что не нужно переделывать внутренности - надо представить новую внешнюю систему команд в виде последовательности известных микроинструкций.
Можно добавлять микро- (или макро-) инструкции тогда, когда нам надо что-то оптимизировать, это да.

Но для простейшей поддержки (чтобы ПО могло корректно работать) не надо переделывать ничего, кроме декодера.

В определенной степени К10 от SSE4 выиграет в большей степени, чем Core 2, поскольку не имеет некоторых ограничений (например, register stall).

FPU переделывать вообще не нужно: задача декодера представить ему работу в понятном для него виде. Максимум, что может понадобиться в FPU - расширение узких мест (внутренних шин, etc). Но в К10 это и так проделали, расширив его вдвое.

Dogmatik

Переделывать - да. С нуля - нет. (С нуля процы уже давно никто не переделывает).

matik

Разве? И как вы определили, что особой передлки не потребуется. Я например, ещё кое что помню из курса "цифровых машин" - 56 новых "строчек" в таблице Карно - эта целая "куча" новой логики (и возможных багов из-за "неопределённых" состояний).


Ну как это нет? Конечно есть и практически тоже самое, что и у Core. Да и если бы не было - переделывать всё равно пришлось бы - шедулер хотябы должен знать о новых микроинструкция (и на какие порты их не стоит посылать ).


Вот в этом и состоит весь прикол - придумывать новые комманды чтобы реализовать их микрокодом - какой в этом смысл? Выигрыша в производительности от этого никакого не будет. Если и программа (не используящая SSE4) и микрокод будут генерить практически одинаковые цепочки micro-инструкций - так в чём разница?
Смысл именно в том, чтобы обьеденить несколько операций в одну (микроинструкцию) чтобы сэкономить на латентности исполнения, на throughput, на числе используемых портов и на количестве "мест" в Out-of-Order очереди.


Часть инструкций SSE4 можно реализовать микрокодом, но тогда не стоит ожидать 50% прироста в DivX .


Не понял, причём здесь register stall? Ни один "уважающий себя" транслятор не будет генерить код допускающий register stall. Кстати у К8 тоже есть register stall для 32-битных "четвертинок", а в К10 скорее всего будет и для 64-битных половинок (в резултате превращения XMM регистров в честные 128-битные). Да и не выиграет К10 ничего, если реализуют микрокодом.


Ну как же не нужно? Например если взять инструкцию DPPS (честную реализацию, а не с помощю микрокода), то для этого, как миннимум, надо добавить ещё один FP сумматор. И даже если суммарная латентность будет равна ADD+MUL, всё равно выигыш будет на throughput, на освобождении одного из портов и на плотности кода.

Потому что Вам нужно сделать не 56 новых строчек с нуля, а добавить 56 (на самом деле для АМД меньше, там уже были некоторые инструкции, которые у Интел только появились) строчек в таблицу из полутысячи значений. Есть разница? Логика усложнится, конечно - но не в разы, а на 10%.


А вот так, нет, и все. В К7\К8\К10 на исполнение отправляются не микроинструкции в порт (как и Р6 и ее наследниках), а целые Line, в которых сгруппированы по 3 макрооперации.
Это отличается от идеологии в процессорах Интел.

Нет необходимости проверять порты. Но появляется необходимость расставлять МОПы в линии.


Нет там шедулера. Нет. Понимаете?


Смысла целых три:
1. Сохранить совместимость и дать возможность программе работать с новым набором инструкций.
2. Использовать структуру SIMD, отдавая одну команду для действий над целой группой однотипных операций
3. Самый большой выигрыш мы получаем от совершенно, казалось бы, посторонней вещи: делая систему команд регулярной (то есть инструкции определенного вида заведомо известной длины), мы сильно (!) упрощаем работу декодера, который вынужден "вылавливать" инструкции из потока данных на ходу.
Благодаря этому операции, записанные на SSE2, часто исполняются в большем темпе, нежели такие же по смыслу операции, записанные при помощи старых х86 команд.

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


И в этом тоже (для Интел). У АМД несколько по другому, есть отдельные очереди у ФУ, там нет такой жесткой нехватки места.
Но регуляризация команд по полезному эффекту превышает выигрыш от экономии места.


Интересно, откуда Вы это взяли? Что не стоит ожидать? Я не готов делать такие утверждения. В частности, может оказаться, что в К10 эффект будет даже выше, чем 50% прироста.


Можно подумать, всегда есть выбор.
Кроме того, у Core 2 есть и другие ограничения: например, возможность читать одновременно не более 2 регистров общего назначения.
Таких ограничений нет в К8\К10. Более того, эти процессоры обладают двухпортовым кэшем, например.


"Честная реализация" - это любая, которая даст корректный результат. Я вполне согласен, что, добавив один сумматор, мы повысим производительность данной конкретной операции.
Спорить не о чем.
Кстати сказать, если добавить сумматор, то все равно понадобится микрокод

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

Кстати сказать, в К10 FPU расширен вдвое, это позволит исполнять подобные MADD команды вдвое быстрее, чем на К10.
А если учесть, что реализована невыровненная загрузка данных, реальная производительность FPU у K10 еще улучшится.

Кстати сказать, невыровненная загрузка (то есть наиболее общий и частый случай расположения данных!) будет на К10 вдвое быстрее, чем на Core 2 той же частоты.
Лично меня это вполне впечатляет.

На ананде...
http://www.anandtech.com/tradeshows/showdoc.aspx?i=3006

Неужели у AMD всё так плохо?

matik

На самом деле - больше, учитывая до сих пор не реализованное SSSE3.

Так дело ведь не только в процентах усложнения логики. Даже 10% - это уже серьёзное изменение. Написание модели на Verilog это только часть работы (имхо, самая маленькая часть) - после этого надо ещё рассчитать схему и переделать физразводку в соответствии с запланированными таймингами. После этого проц. должен пройти полный цикл тестинга и дебагинга. Помнится, АМД SSE3 почти год добавляла - а там всего 8 инструкций.

Мы вроде бы говорим про SSE4, который исполняется на FP pipeline который реализован как и интеловский - единый шедулер со специализированными портами. Причём здесь целочисленный конвейер?

Есть .

С этим согласен, но это не даст прирост производительности (кое где возможен небольшой рост, но кое где может быть и падение).

Не понял что вы имели в виду. В принципе и сейчас практически любую инструкцию в SSE4 можно реализовать с помощью SSE2 (то есть в любом случае можно используется SIMD). В этом ведь и состоит задача - использовать для некоторых мат. операций, вместо группы инструкций из SSE/SSE2, одну инструкцию из SSE4. Но в этом не будет смысла если быстрота исполнения этой инструкции из SSE4 буде ниже или равна быстроте исполнения вышеупомянутой группе инструкций из SSE/SSE2.


Не понял, какая здесь выгода. Будет это одна SSE4 или же группа SSE/SSE2 ("програмно" реализующая эту SSE4 инструкцию) - цепочка микроопераций на выходе из декодера/генератора микрокода будет практически одинаковой. Разве что, это поможет незначительно сократить размер кода.

Опять вы почему-то переходите на целочисленный конвейер .

Это как?

Я уже написал выше. В микрокодовой реализации SSE4 и её програмная эмуляция с помощью SSE/SSE2 сгенерируют одинаковую цепочку микроопераций. Естественно, я имею в виду "правильную" програмную эмуляцию. В некоторых случаях быстрота програмной эмуляции может быть выше при "правильной" реализации (как например в случае с тригонометрическими функциями).

Как раз таки в случае с partial register stall - выбор есть всегда. Нет ни одного технического оправдания использования подобного кода.

Почему?

Dot product - довольно распростарнёная операция в 2D/3D графике. Да и в физике можно найти кучу применений.

(Вы наверно имели в виду "чем на К8"?)
Я с этим согласен, но это же можно сказать о любой векторной SSE/SSE2 инструкции. Кроме того, микрокодовая реализация не увеличит пиковую FP производительность. Эта инструкция будет занимать по прежнему два порта (как и в програмной эмуляции), тогда как при "правильной" реализации эта инструкция должна занимать один порт, оставляя второй свободным для других инструкций (это должно увеличить FP troughput в 1.5 раза).

Не понял, какое это имеет отношение к SSE4?

Вообще-то это не совсем соответствует действительности. Судя по последнему optimization manual для К10, скорость для невыровненных загрузок не изменилась относительно К8. Другое дело, что невыровненные загрузки теперь разрешили для тех инструкций, которые раньше не могли этого делать. В принципе, здесь может быть некоторый выигрышь за счёт чуть большей плотности кода, но только такой код надо ещё написать, (а я сомневаюсь, что кто-то это будет делать, так как такой код не будет совместим не только с процессорами Интел, но и с поколением К8). Да и всё равно надо стараться использовать выровненные загрузки - они по любому лучше невыровненных в К10 Впрочем, по прежнему не понимаю, как это относится к возможности реализации SSE4 в ближайших степингах К10.

гы )

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

:lol: Даже материнскую плату не нашли, чтобы Барсу воткнуть нормальную. Более того, я на 95% уверен, что тестили Сокет F Барсу на Сокет F материнке - если было бы на АМ2 - тогда берётся Epox 570 SLI и на нем всё должно великолепно работать.

Inqizitor Я так понял, что нынешние степпинги Барселоны содержат ошибки в архитектуре. Поэтому она и зависает до конца 3-го квартала...

Dogmatik
http://forums.overclockers.ru/viewtopic ... 32#3962032

вот тут тебе ответили на твое гы =)

ты за себя отвечай