Radeon.ru :: Обсуждаем будущее Pentium M: возможная поддержка x86-64 и т.д.

Radeon.ru https://forum.radeon.ru/

Обсуждаем будущее Pentium M: возможная поддержка x86-64 и т.д. https://forum.radeon.ru/viewtopic.php?f=17&t=8794	Страница 1 из 1

Автор:	zurzic [ 10:48 14.05.2004 ]
Заголовок сообщения:	Обсуждаем будущее Pentium M: возможная поддержка x86-64 и т.
Предлагается всем присоединится к обсуждению возможностей будующих Pentium M и возможно К9. Для затравки привожу начало моего разговора с matik-ом Fury 13.05.20 12:50 Привет Как думаешь. если Прескотт будет последним NetBurst , а будущие десктопы будут на ядре PentiumM, означает ли это что в PentiumM будет (а возможно уже? ) внедрён x86-64? matador 13.05.20 12:53 думаю, да.... в П-М гораздо проще встроить х86-64 Fury 13.05.20 12:54 Ага как в К7. Ну что ж. Это хорошо, что мы опять вернёмся к баллансу микропроцессоров, без ярко выраженного преимущества того или другого в конкретном приложении matador 13.05.20 12:56 Согласен ) matador 13.05.20 12:56 Впрочем, все же П-М чуток слабоват с К8 сражаться... Думаю, его будут усиливать... Fury 13.05.20 12:57 Да, наверное 800 Мгц FSB дадут. matador 13.05.20 12:57 не только... matador 13.05.20 12:57 думаю, блоков доклеят... matador 13.05.20 12:57 например, SSE2... Fury 13.05.20 13:00 М.. А разве в Pentium M не было SSE2? Чес слово не знаю, как то до него руки не доходили matador 13.05.20 13:01 было Но, учитывая малую (по сравнению с П4 частоту), придется делать этот блок шире, чтобы перегнать НетБерст Логично? Fury 13.05.20 13:01 Второй FPU ? Согласен matador 13.05.20 13:02 думаю, сделают... И, возможно, улучшат ситуацию с АЛУ (хотя она вроде и так неплоха)... matador 13.05.20 13:02 Ассоциативность кэша второго уровня стоит поднять... Fury 13.05.20 13:03 Интересно, а в К9 второй FPU делать не собирались? matador 13.05.20 13:03 не знаю Честно Fury 13.05.20 13:05 Вот я смотрел как-то на Спеки. Итаниум 2 у Оптерона в плавучке выиигрывает в основном потому что у него 2 FPU. Думаю, что если Оптерону второй FPU дать, он на своей более высокой частоте Itanium забить должен matador 13.05.20 13:07 весь вопрос в том, сумеет ли он тогда достичь своей высокой частоты ) Согласен? Два ФПУ — это более сложный декодер, и так далее... Fury 13.05.20 13:07 Декодер, нет, планировщик — да. Вообще согласен конечно matador 13.05.20 13:08 Почему декодер нет? А кормить ты чем будешь два ФПУ? Тебе, значит, надо не 3МОПа за такт делать, а хотя бы 4... Fury 13.05.20 13:10 Я так не думаю. Чтобы кормить 2 FPU каждый такт, достаточно каждый такт декодировать 1 SSE[2] команду (сейчас же 2 половинки исполняются со сдигом в такт). А у нас полторы, так что запас matador 13.05.20 13:11 а весь остальной процессор пойдет рыбу удить? ) Адреса обрабатывать, условные переходы, данных дожидаться... ) matador 13.05.20 13:11 Не-е-е-е, был бы четкий стимул расширять до 4 МОПов... Конечно, и три тоже ничего — но, ИМХО, в данном случае есть прямой смысл уширять весь тракт... Fury 13.05.20 13:14 >а весь остальной процессор пойдет рыбу удить? ) :—) хорошо сказал. И да и нет. "Нет" потому что в плотных циклах, FPU команды преобладают. Но если расшить до 4-х без потери в тактовой частоте смогли, было бы великолепно matador 13.05.20 13:15 именно: 1. Было бы место для 2ССЕ за такт 2. Можно было бы обрабатывать достаточно продвинутую целочисленную логику... Не-е-е-е, если уж связываться с увеличением количества ФПУ, то попутно расширяя конвейер Тем паче, что именно ФПУ, думаю, один из самых греющихся блоков... Fury 13.05.20 13:16 Да, уж.

Автор:	ISA_user [ 11:26 14.05.2004 ]
Заголовок сообщения:
Не, им МС надо тоже интегрировать

Автор:	matik [ 11:28 14.05.2004 ]
Заголовок сообщения:
ISA_user Думаю, это они оставят на крайний случай... Потому что одна из сильных сторон Интеловских чипсетов — контроллер памяти. Если его интегрировать в процессор, сильно снизится привлекательность Интеловских чипсетов — они и дороже конкурентов, и, как правило, функционально беднее... Зачем себе бизнес подрезать?

Автор:	zurzic [ 11:36 14.05.2004 ]
Заголовок сообщения:
ISA_user К тому же котнролер памяти IMO не даст того преимущества, котое дал бы, например, второй FPU.

Автор:	ISA_user [ 11:37 14.05.2004 ]
Заголовок сообщения:
matik Потому что одна из сильных сторон Интеловских чипсетов — контроллер памяти. но шина! она в раз имеет большую латентность, т.к и сама она и буфера на стороне ЦПУ и МС работают на "малых" частотах. Зачем себе бизнес подрезать? ну только из-за этого? хотя они ведь могут и кривую построить чт выгоднее — уж свою маржу они знают Yury_Malich К тому же котнролер памяти IMO не даст того преимущества, котое дал бы, например, второй FPU. зато это можно сделать быстрее, т.к. это вопрос технологии а не разработки...

Автор:	zurzic [ 11:41 14.05.2004 ]
Заголовок сообщения:
<BLOCKQUOTE><SPAN class=hquote>цитата:</SPAN><HR size=22><SPAN class=quote>ISA_user: зато это можно сделать быстрее, т.к. это вопрос технологии а не разработки...</SPAN><HR size=22></SPAN></BLOCKQUOTE> Не думаю что интегрировать котроллер памяти намного проще чем второй FPU. Хотя утвержать или опровергать что-то здесь не рискну.

Автор:	KSP [ 11:54 14.05.2004 ]
Заголовок сообщения:
matik <I>сильно снизится привлекательность Интеловских чипсетов — они и дороже конкурентов, и, как правило, функционально беднее... Зачем себе бизнес подрезать?</I> Напротив, они весь бизнес контроллеров памяти себе забирают, попутно забирая эти деньги у конкурентов. Плюс если ставить вопрос "проигрывать по производительности и делать много денег на чипсетах" против "делать на чипсетах меньше, но иметь топовую производительность", то ответ очевиден.

Автор:	ISA_user [ 12:01 14.05.2004 ]
Заголовок сообщения:
Yury_Malich Не думаю что интегрировать котроллер памяти намного проще чем второй FPU. намного

Автор:	VLev [ 12:28 14.05.2004 ]
Заголовок сообщения:
Yury_Malich, matik: По поводу "второго" FPU в K8+ (да и P-M, видимо, тоже): речь идет в основном об ускорении векторных SSE2 операций (а не скалярных или x87), так что ни декодер, ни планировщик это существенно не затронет. То есть, конечно, видимо, надо некоторые новые mop-ы, будет ввести, но и только. Более того, собственно, речь не об "удвоении" блоков, а об уширении одного блока с 80бит до 128 (ну или для мантиссы с 64 до ~100), то есть сложность блока FPU возрастает "всего лишь" в ~1.5 раза. Много хуже (точнее, лучше, но сложнее) то, что это автоматически потребует расширения всех внутренних шин данных с 64 до 128битов. По поводу P-M надо у C@t спросить. Он вроде считает, что там "удвоение" просто сделать не получится. Я еще раз посмотрел OptManual на Pentium's. Вроде бы по простым FPU операциям K8 и P-M потактово-идентичны, по сложным K8 много лучше. Однако в низкоуровневых внутрикэшевых тестах P-M проигрывает даже на простых операциях. Вероятно, дело еще в доступе в L1 кэш. В общем, с FPU в P-M делать что-то в любом случае надо. А в K8+ (всвязи с отменой Tejas), может, и не обязательно --- он и так конкурентноспособный (а жаль).

Автор:	matik [ 12:36 14.05.2004 ]
Заголовок сообщения:
KSP Напротив, они весь бизнес контроллеров памяти себе забирают Сомневаюсь, что есть некий отдельный "бизнес контроллеров памяти"... Есть рынок чипсетов. Привлекательность чипсетов именно от Интел — в их производительности, поскольку функциональность у конкурентов шире. Соответственно, убрав производительность — подрежем привлекательность. Зачем? <I>Плюс если ставить вопрос "проигрывать по производительности и делать много денег на чипсетах" против "делать на чипсетах меньше, но иметь топовую производительность", то ответ очевиден. </I> А вот это действительно сложный выбор. Только я бы его чуток по-другому рассмотрел... 1. Если процессоры будут безусловно и сильно проигрывать по производительности, то это будет вынужденный шаг — тогда не до жиру. 2. Если будут примерно равны (или не сильно проигрывать), тогда можно и не делать. И, соответственно, не снижать свои прибыли... VLev он и так конкурентноспособный (а жаль). Я понял идею, но КАК это звучит!

Автор:	matik [ 13:06 14.05.2004 ]
Заголовок сообщения:
VLev речь идет в основном об ускорении векторных SSE2 операций Кстати, подумалось вот чего — а почему бы не сделать второй блок? Тогда вырастет скорость ВСЕХ операций, а не только векторных. Явно выгоднее. Правда, может оказаться заметно более сложным.

Автор:	KSP [ 13:08 14.05.2004 ]
Заголовок сообщения:
matik убрав производительность Убрав отличие/преимущество в производительности подрежем привлекательность. Зачем? Но при этом себестоимость/прибыль контроллера памяти они будут забирать себе с каждого проца, а не с каждого чипсета. Если будут примерно равны (или не сильно проигрывать), тогда можно и не делать. Согласен. Хотя тенденция к интеграции всего в проц налицо. VLev А в K8+ Вряд-ли все недавние новости столь фундаментально повлияют на разработку К8+. Кстати, когда он намечается к выходу?

Автор:	matik [ 13:19 14.05.2004 ]
Заголовок сообщения:
KSP Но при этом себестоимость/прибыль контроллера памяти они будут забирать себе с каждого проца, а не с каждого чипсета. Дык как бы и так процентов 80% рынка чипсетов у ИНтел... Так что принципиально разница невелика. И еще одно... Брать деньги за встроенный в процессор контроллер сложно. Как Вы себе это представляете? Вы же за ФПУ не доплачиваете, не так ли? Соответственно, напрямую денег не снять — разве что косвенно, за увеличенную скорость системы.

Автор:	KSP [ 14:16 14.05.2004 ]
Заголовок сообщения:
matik разве что косвенно, за увеличенную скорость системы. Примерно так. При этом снизив цену и себестоимость чипсета, на что будут вынуждены пойти и конкуренты. И сколько вообще составляет чипсетный бизнес против ЦПУшного в деньгах?

Автор:	VLev [ 14:29 14.05.2004 ]
Заголовок сообщения:
<BLOCKQUOTE><SPAN class=hquote>цитата:</SPAN><HR size=22><SPAN class=quote>matik: Явно выгоднее. Правда, может оказаться заметно более сложным.</SPAN><HR size=22></SPAN></BLOCKQUOTE> Сложнее --- несоизмеримо. Что выгоднее --- спорно, т.к. пропадет сбалансированность потоков кода, данных и "мощности" FPU. Кстати, не факт что будет даже просто быстрее. В смысле будет примерно одинаково на неоптимизированном коде и на оптимизированном векторном. Так что остается только оптимизированный чисто скалярный... IMHO, "убиваться" за это бессмысленно.

Автор:	VLev [ 14:32 14.05.2004 ]
Заголовок сообщения:
<BLOCKQUOTE><SPAN class=hquote>цитата:</SPAN><HR size=22><SPAN class=quote>KSP: Вряд-ли все недавние новости столь фундаментально повлияют на разработку К8+. Кстати, когда он намечается к выходу?</SPAN><HR size=22></SPAN></BLOCKQUOTE> Не знаю... Хотя лично я бы многие шины данных до 128бит расширил бы уже в 90nm K8. Ну и FPU за одно...

Автор:	U2 [ 15:11 14.05.2004 ]
Заголовок сообщения:
Yury_Malich а будущие десктопы будут на ядре PentiumM В ближайшие годы Прескотт будет в десктопах. Интел подтвердил это вчера. KSP И сколько вообще составляет чипсетный бизнес против ЦПУшного в деньгах? За 1 кв 2004: Microprocessor = $5,980 (In millions), Chipset + mb = $1,045 (In millions) Зачем ломать то, что приносит неслабый доход?

Автор:	VLev [ 15:41 14.05.2004 ]
Заголовок сообщения:
<BLOCKQUOTE><SPAN class=hquote>цитата:</SPAN><HR size=22><SPAN class=quote>U2: Зачем ломать то, что приносит неслабый доход? </SPAN><HR size=22></SPAN></BLOCKQUOTE> Да, я тоже думаю, что это и есть основной аргумент почему не будет встроенного MC у Intel в ближайшее время. Но еще есть и технический: Надо разрабатывать шину общения процессора с внешним миром. Так как она д.б. стандартизирована (я тут надеюсь, что совсем закрытых архитектур Intel делать не будет), то, насколько я понимаю, о ее параметрах сообщают задолго до выпуска. Но но о чем подобном Intel вроде бы пока не сообщала. Или же это будет HyperTransport ™ Technology

Автор:	0serg [ 16:05 14.05.2004 ]
Заголовок сообщения:
VLev Или PCI Express 16-32x. Why not? Её вполне достаточно для десктопов. Правда что делать в многопроцессорных архитектурах — неясно. На худой конец можно ту же QPB немного переделать.

Автор:	zurzic [ 16:26 14.05.2004 ]
Заголовок сообщения:
U2 <BLOCKQUOTE><SPAN class=hquote>цитата:</SPAN><HR size=22><SPAN class=quote> В ближайшие годы Прескотт будет в десктопах. Интел подтвердил это вчера. </SPAN><HR size=22></SPAN></BLOCKQUOTE> Я бы уточнил "в ближайшие год ". До второго квартала 2005 не намного больше года . Но это не мешает нам сейчас обсуждать. Не так ли?

Автор:	matik [ 16:32 14.05.2004 ]
Заголовок сообщения:
VLev Что выгоднее --- спорно, т.к. пропадет сбалансированность потоков кода, данных и "мощности" FPU. Если делать второй FPU, то делать и 4МОПа за такт, это понятно... лично я бы многие шины данных до 128бит расширил бы уже в 90nm K8. Ну и FPU за одно... Очень может быть, что этим сейчас инженеры АМД и заняты — в конце концов, сдерживающая сила явно технологи, а не разработчики...

Автор:	VLev [ 17:47 14.05.2004 ]
Заголовок сообщения:
<BLOCKQUOTE><SPAN class=hquote>цитата:</SPAN><HR size=22><SPAN class=quote>matik: Если делать второй FPU, то делать и 4МОПа за такт, это понятно...</SPAN><HR size=22></SPAN></BLOCKQUOTE> Только 4х MOP-ов IMHO, не достаточно. Если мы за такт в FPU будем получать 2 независимых результата из 4х аргументов систематически (4 из 8 в пике), то существующее LSU (2load+1store за такт) просто не справится с такой нагрузкой. Короче, я просто не понимаю как с существующему ядру прикрутить второй FPU.

Автор:	BEKTOP [ 20:01 14.05.2004 ]
Заголовок сообщения:
Мои 2 копейки: 1. EM64T в P-M будет. Отеллини подтвердил (см, например, http://www.theinquirer.net/?article=15915 в конце заметки) 2. Насчет 2-го FPU. В раннем tape-out Willamette было 2 полноценных FP execution units. Потом для экономии площади, 2-й unit урезали (что сыграло одну из роковых ролей в судьбе P-4). Сейчас Intel, скорей всего, не повторит ту же ошибку. 3. НТ и memory controller будут — по слухам — в Conroe [Исправлено: BEKTOP : 15-05-2004 02:06]

Автор:	matik [ 03:04 15.05.2004 ]
Заголовок сообщения:
BEKTOP В раннем tape-out Willamette было 2 полноценных FP execution units Я тоже читал это в давней iXBT-шной статье про П4, но так и не понял, а откуда взялась эта идея? Очень как-то странно выглядит...

Автор:	Ivan Andreevich [ 04:05 15.05.2004 ]
Заголовок сообщения:
Давайте попробуем составить список фич Post-P6 (aka Pentium M c двумя ядрами) который позволит ему догнать и обогнать очень быстрый Оптерон? Причём чтобы это было с заделом на несколько лет вперёд

Автор:	BEKTOP [ 05:12 15.05.2004 ]
Заголовок сообщения:
<BLOCKQUOTE><SPAN class=hquote>цитата:</SPAN><HR size=22><SPAN class=quote>matik: BEKTOP В раннем tape-out Willamette было 2 полноценных FP execution units Я тоже читал это в давней iXBT-шной статье про П4, но так и не понял, а откуда взялась эта идея? Очень как-то странно выглядит...</SPAN><HR size=22></SPAN></BLOCKQUOTE> Идея добавить или убрать? Вообще-то 2 execution units там есть и сейчас. В первоначальном дизайне они оба были полноценными, но потом 2-й юнит урезали, оставив только функции move(load)/store.

Автор:

zurzic [ 12:54 15.05.2004 ]

Заголовок сообщения:

VLev
<BLOCKQUOTE>цитата:<HR size=22>По поводу "второго" FPU в K8+ (да и P-M, видимо, тоже):
речь идет в основном об ускорении векторных SSE2 операций (а не скалярных или x87), так что ни декодер, ни планировщик это существенно не затронет. То есть, конечно, видимо, надо некоторые новые mop-ы, будет ввести, но и только.
Более того, собственно, речь не об "удвоении" блоков, а об уширении одного блока с 80бит до 128 (ну или для мантиссы с 64 до ~100), то есть сложность блока FPU возрастает "всего лишь" в ~1.5 раза.<HR size=22></BLOCKQUOTE>
Не согласен. Я так полагаю, что как раз в случае уширения придёться переделывать и декодер и планирощик. Декодер:, потому что во всех случаях для каждой команды вместо двух мопов SSE[2] придётся делать новый один МОП, а для планировщика появятся новые типы данных (128 -разрядные), который тоже нужно учитывать. А в случае добавления второго FPU декодер переделывать в принципе не надо вообще: два SSE[2] МОПа будут уходить на два независимых FPU , может немного доделать декодер.

Цитата:
>Что выгоднее --- спорно, т.к. пропадет сбалансированность потоков кода, данных и "мощности" FPU. \

Ну внутренние шины данных естественно придётся расширить в любом случае: ущирения FPU или удвоения. Что мы будем иметь: декодеры выдают не менее трёх МОПов за такт, 2 FPU смогут за такт проглатывать 2 из трёх МОПов, данные для которых смогут поступать по шинам удвоенный ширины. Где же дизбалланс?

Цитата:
>Кстати, не факт что будет даже просто быстрее. В смысле будет примерно одинаково на неоптимизированном коде и на оптимизированном векторном.\

А какая нам в принципе разница скалярный или векторый? Нам шашечки или ехать? Главное чтобы с конвейеров могли сходить 2 FPU МОПа за такт а из каких x86 команд эти МОПы добывать скалярных x87, SSE или векторных SSE по-моему для планировщика и 2-х FPU не важно. У векторных преимущество: надо меньше x86 команд на то же количество МОПов.

Цитата:
>Так что остается только оптимизированный чисто скалярный... IMHO, "убиваться" за это бессмысленно.\

Не понял, что значит "остается ", почему он вдруг сам по себе?

BEKTOP

Цитата:
> EM64T в P-M будет. Отеллини подтвердил (см, например, http://www.theinquirer.net/?article=15915 в конце заметки)\

Имеется ввиду He said the EM64T technology will also be put into dual core systems. ?
Ой как не скоро это. Прескотт получается в ближайшее время единственный x86-64 процессор Интел.

Цитата:
> НТ и memory controller будут — по слухам — в Conroe\

Не верю я что в Pentium M будет HT. Не к селу он там IMO

Автор:	zurzic [ 13:08 15.05.2004 ]
Заголовок сообщения:
Ещё у меня есть одна мысль: интересно появится ли когда нибудь в системе команд SSE команда muladd (умножение с накоплением) которая есть в PowerPC и Itanium. Правда её придётся делать 3-х операндной, что для синтаксиса x86 может представить трудность, но не преодолимую , если отказатся от ссылок в память в синтаксисе команды.

Автор:	matik [ 13:56 15.05.2004 ]
Заголовок сообщения:
BEKTOP Вообще-то 2 execution units там есть и сейчас. В первоначальном дизайне они оба были полноценными, но потом 2-й юнит урезали, оставив только функции move(load)/store. Да, слышал. Только вот непонятно, откуда же все-таки растут ноги у этой идеи... Yury_Malich Не согласен Ты сумел оформить то, что я хотел промычать Ещё у меня есть одна мысль Когда-нибудь — может быть. Вот как раз в АМД64 ее бы ввести, все равно расширяли систему команд... А теперь разве что на SSE4 какое-нибудь придется надеяться...

Автор:	VLev [ 15:06 15.05.2004 ]
Заголовок сообщения:
Yury_Malich: ... во всех случаях для каждой команды вместо двух мопов SSE[2] придётся делать новый один МОП, С этим я согласен. Я и писал: > То есть, конечно, видимо, надо некоторые новые mop-ы, будет ввести, но и только. Но это IMHO будет даже некоторым упрощением настоящей ситуации при одновременном общем улучшении, так как несколько разгружает весь тракт от декодера до буферов команд FPU, позволяя другим mop-ам "двигаться" по нему свободнее. В общем, эти mop-ы становятся еще более макро-, что лежит в русле идеологии конвейера K7/8. а для планировщика появятся новые типы данных (128 -разрядные), который тоже нужно учитывать. Ну и слава Богу. Я тут вообще никакого усложнения не вижу (именно для планировщика). Шины данных и физ. регистры --- да, должны измениться. А в случае добавления второго FPU декодер переделывать в принципе не надо вообще: два SSE[2] МОПа будут уходить на два независимых FPU , "В принципе", действительно не надо. Но что тогда, со старым декодером, нам дает-то второй FPU? Максимальная скорость наполнения декодером очередей: 1.5 SSE2 инстр/такт, а скорость разгрузки у "существенной части" двойного FPU --- 2 (add+mul). Соотношение наполнение/разгрузка д.б. минимум обратное, т.к. на каждую FPU операцию приходится еще сколько-то вспомогательных (скажем, 1.1: одна операция загрузки и еще кусочек операций сохранения и изменения базового адреса. может немного доделать декодер. Тут даже 4 mop/такт мало. Так что IMHO, лучше изменить сами mop-ы Ну внутренние шины данных естественно придётся расширить в любом случае: ущирения FPU или удвоения. Но --- совершенно по-разному. В случае уширения просто увеличить разрядность с 64бит до 128, а в случае удвоения --- делать вторую независимую 64бит шину и как-то решать проблемы разделения ими доступа в L1 кэш и к регистрам. Что мы будем иметь: декодеры выдают не менее трёх МОПов за такт, 2 FPU смогут за такт проглатывать 2 из трёх МОПов, 4 (add+mul) не считая load/store (сейчас +2). Итого минимум 6 из 3 возможных. данные для которых смогут поступать по шинам удвоенный ширины. По удвоенному количесту шин той же ширины. А какая нам в принципе разница скалярный или векторый? Нам шашечки или ехать? Главное чтобы с конвейеров могли сходить 2 FPU МОПа за такт Они и так сходят, и даже 3 (1add+1mul+1ld/store). Лично я борюсь за [содержательных] 6 "rop"-ов, а не за 3 mop-а (как сейчас). Именно потому, что мне "ехать", а не шашечки. А так мне конечно все равно как это будет называться и из чего они будут набираться. Не понял, что значит "остается ", почему он вдруг сам по себе? Потому что, раз уж оптимизация под SSE2 делается, то можно и векторизовать заодно. Мне вообще кажется использование SSE2 в чисто скалярном режиме (как реально сейчас в оптимизации под AMD64) чем-то искусственным.

Автор:	VLev [ 15:15 15.05.2004 ]
Заголовок сообщения:
<BLOCKQUOTE><SPAN class=hquote>цитата:</SPAN><HR size=22><SPAN class=quote>Yury_Malich: Ещё у меня есть одна мысль: интересно появится ли когда нибудь в системе команд SSE команда muladd (умножение с накоплением) которая есть в PowerPC и Itanium.</SPAN><HR size=22></SPAN></BLOCKQUOTE> IMHO, не нужна.

Автор:	zurzic [ 16:17 15.05.2004 ]
Заголовок сообщения:
VLev Ок, мысль понятна, я ещё обдумаю. Интересно ещё C@t-а послушать Цитата: >IMHO, не нужна\ Почему? Зависимое сложение после умножение это 4+4=8 тактов. muladd Выпоняет эту же пару за 4 такта. Очень мощная команда.

Автор:	VLev [ 16:50 15.05.2004 ]
Заголовок сообщения:
<BLOCKQUOTE><SPAN class=hquote>цитата:</SPAN><HR size=22><SPAN class=quote>Yury_Malich: Почему? Зависимое сложение после умножение это 4+4=8 тактов. muladd Выпоняет эту же пару за 4 такта. Очень мощная команда.</SPAN><HR size=22></SPAN></BLOCKQUOTE> Ну, это как реализовать... Вообще, самым простым улучшением FPU я считаю добавку функции fadd умножителю. Тогда FPU сможет выполнять не только 1add+1mul, но и 2add за такт --- более универсально, и не требует никаких других изменений. Ну и соответственно, тогда можно подумать и о muladd. Но пока сумматор и умножитель отдельные блоки --- muladd IMHO не нужен.

Автор:	zurzic [ 20:22 15.05.2004 ]
Заголовок сообщения:
VLev Цитата: >Но пока сумматор и умножитель отдельные блоки --- muladd IMHO не нужен.\ О да, совершенно согласен, для muladd нужен Fmuladd. Я кстати и подразумевал, что так должно быть, когда писал о muladd. Кстати и два FPU , о которых я рассуждал представляются мне как два устройства Fmuladd и два Fload, a не как 6: Fmul, Fadd, Fload, Fmul, Fadd, Fload [Исправлено: Yury_Malich : 16-05-2004 00:57]

Автор:	Ivan Andreevich [ 20:25 15.05.2004 ]
Заголовок сообщения:
Tejas отменили — а что будет c TNI (SSE4)? Дебютирует с Post-P6 или на него забили вместе с NetBurst?

Автор:	zurzic [ 23:48 15.05.2004 ]
Заголовок сообщения:
Ivan Andreevich Скорее всего сделают когда-нибудь. Кстати насколько я понимаю в Dothan пока даже SSE3 нет.

Автор:	BEKTOP [ 04:41 16.05.2004 ]
Заголовок сообщения:
<BLOCKQUOTE><SPAN class=hquote>цитата:</SPAN><HR size=22><SPAN class=quote>matik: BEKTOP Вообще-то 2 execution units там есть и сейчас. В первоначальном дизайне они оба были полноценными, но потом 2-й юнит урезали, оставив только функции move(load)/store. Да, слышал. Только вот непонятно, откуда же все-таки растут ноги у этой идеи... </SPAN><HR size=22></SPAN></BLOCKQUOTE> Скорей всего, идеологи NetBurst предполагали скомпенсировать длинный конвейер. Отсюда и идея 2 ALU и 2 FPU. Согласен, что производительность П(2 FPU) <= П(FPU) + П(FPU). Но все же прирост был бы.

Автор:	Ivan Andreevich [ 20:51 16.05.2004 ]
Заголовок сообщения:
Yury_Malich Насколько я понимаю, из-за смены архитектуры набор SIMD комманд нужно перерабатывать. Всё же там многие комманды были ориентированы на NetBurst и её слабые места.

Автор:	zurzic [ 23:16 16.05.2004 ]
Заголовок сообщения:
Ivan Andreevich Цитата: >Насколько я понимаю, из-за смены архитектуры набор SIMD комманд нужно перерабатывать. Всё же там многие комманды были ориентированы на NetBurst и её слабые места.\ Да нет, с набором команд всё в порядке. Он логичен и строен и вполне универсален, если не считать команд для HT (это наверное единственные команды ориентированные на NetBurst). Под NetBurst ориентирована оптимизация потока команд. А вот что касается самой оптимизации, это да, доработать под Pentium M придётся.

Автор:

GReY [ 00:16 17.05.2004 ]

Заголовок сообщения:

matik

Цитата:
>Если делать второй FPU, то делать и 4МОПа за такт, это понятно...\

Почему, скажем, не 5? Или 6, как подсчитал VLev?

VLev

Цитата:
>В общем, эти mop-ы становятся еще более макро-, что лежит в русле идеологии конвейера K7/8.\

Микро WLIV?

BEKTOP

Цитата:
>В раннем tape-out Willamette было 2 полноценных FP execution units. Потом для экономии площади, 2-й unit урезали (что сыграло одну из роковых ролей в судьбе P-4). Сейчас Intel, скорей всего, не повторит ту же ошибку.\

1) откуда эти данные? меня тоже давно интересует их источник
2) даже если и хотели, то просто передумали, потому что ни в Норсвуде, ни в прескотте ничего не изменилось — а ведь могли запросто.

Yury_Malich

Цитата:
>Не верю я что в Pentium M будет HT. Не к селу он там IMO\

IMHO HT везде "к селу", если ядро способно переваривать много операций одновременно.

Цитата:
>Правда её придётся делать 3-х операндной, что для синтаксиса x86 может представить трудность\

Есть же уже трёхоперандные.

Автор:	matik [ 00:24 17.05.2004 ]
Заголовок сообщения:
GReY Почему, скажем, не 5? Или 6, как подсчитал VLev? Потому что есть еще такой важный принцип: "не создавать себе лишней работы" Вот 4МОПа за такт — минимальная величина, начиная с которой, ИМХО, имеет смысл делать два FPU...

Автор:	BEKTOP [ 00:47 17.05.2004 ]
Заголовок сообщения:
<BLOCKQUOTE><SPAN class=hquote>цитата:</SPAN><HR size=22><SPAN class=quote>Ivan Andreevich: Yury_Malich Насколько я понимаю, из-за смены архитектуры набор SIMD комманд нужно перерабатывать. Всё же там многие комманды были ориентированы на NetBurst и её слабые места.</SPAN><HR size=22></SPAN></BLOCKQUOTE> Отнюдь нет. SSE появился в Р-3 (Katmai). SIMD есть всего лишь векторная обработка. Подобные технологии есть и у АМД (3DNow!) и у Power (AltiVec)

Автор:	BEKTOP [ 00:56 17.05.2004 ]
Заголовок сообщения:
<BLOCKQUOTE><SPAN class=hquote>цитата:</SPAN><HR size=22><SPAN class=quote>GReY: <I>BEKTOP В раннем tape-out Willamette было 2 полноценных FP execution units. Потом для экономии площади, 2-й unit урезали (что сыграло одну из роковых ролей в судьбе P-4). Сейчас Intel, скорей всего, не повторит ту же ошибку.</I> 1) откуда эти данные? меня тоже давно интересует их источник 2) даже если и хотели, то просто передумали, потому что ни в Норсвуде, ни в прескотте ничего не изменилось — а ведь могли запросто.</SPAN><HR size=22></SPAN></BLOCKQUOTE> 1) Были внутренние доки... А из открытых источников — веб-сайты. Сделайте поиск по Willamette и наверняка на что-нибуд наткнетесь. 2) Наверняка не знаю. Видимо, предпочли не тратить деньги на улучшение х87, а сделать упор на SIMD. А исполнение SIMD инструкций и так в Р-4 очень хорошее.

Автор:	matik [ 01:11 17.05.2004 ]
Заголовок сообщения:
BEKTOP А из открытых источников — веб-сайты Не знаю насчет внутренних доков — ничего такого не попадалось... А вот новостные сайты все как один перепечатали эту "новость" с Инквайра.... А это весьма своеобразный "источник"...

Автор:	BEKTOP [ 01:44 17.05.2004 ]
Заголовок сообщения:
<BLOCKQUOTE><SPAN class=hquote>цитата:</SPAN><HR size=22><SPAN class=quote>matik: BEKTOP А из открытых источников — веб-сайты Не знаю насчет внутренних доков — ничего такого не попадалось... А вот новостные сайты все как один перепечатали эту "новость" с Инквайра.... А это весьма своеобразный "источник"...</SPAN><HR size=22></SPAN></BLOCKQUOTE> Да уж, Инквайр это ребята еще те... Только их в пору Willamette еще не было, ИМХО. А насчет доков — сам видел PowerPoint, с высокой степенью не поддельный.

Автор:	Ivan Andreevich [ 04:52 17.05.2004 ]
Заголовок сообщения:
BEKTOP Ёлки за кого вы меня принимаете Я говорю что SSE4 наверняка содержал в себе много комманд которые были рассчитаны на латание дыр в идеологии NetBurst... Теперь нужно перерабатывать.

Автор:	BEKTOP [ 07:27 17.05.2004 ]
Заголовок сообщения:
<BLOCKQUOTE><SPAN class=hquote>цитата:</SPAN><HR size=22><SPAN class=quote>Ivan Andreevich: BEKTOP Ёлки за кого вы меня принимаете Я говорю что SSE4 наверняка содержал в себе много комманд которые были рассчитаны на латание дыр в идеологии NetBurst... Теперь нужно перерабатывать. </SPAN><HR size=22></SPAN></BLOCKQUOTE> Виноват, не понял. Не хотел обидеть...

Автор:

zurzic [ 08:30 17.05.2004 ]

Заголовок сообщения:

GReY

Цитата:
>Есть же уже трёхоперандные.\

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

Цитата:
>IMHO HT везде "к селу", если ядро способно переваривать много операций одновременно.\

ДА, конечно, если узким местом не становится декодирование. Я не думаю что Pentium M с классическим I-кэшем и коротким конвейером сможет там сколько-нибудь существенный выигрышь получить. NetBurst с длинным ковейером, и другими архитектурными особенностями, вызывающими простои узлов и то умудрялся в ряде задач с включенным HT в минус уходить.

[Исправлено: Yury_Malich : 17-05-2004 10:31]

Автор:	zurzic [ 08:41 17.05.2004 ]
Заголовок сообщения:
<BLOCKQUOTE><SPAN class=hquote>цитата:</SPAN><HR size=22><SPAN class=quote>Ivan Andreevich: Yury_Malich Насколько я понимаю, из-за смены архитектуры набор SIMD комманд нужно перерабатывать. Всё же там многие комманды были ориентированы на NetBurst и её слабые места.</SPAN><HR size=22></SPAN></BLOCKQUOTE> Я кстати тоже не сообразил, что речь всё ещё шла о SSE4

Автор:	VLev [ 11:23 17.05.2004 ]
Заголовок сообщения:
По поводу "второго" FPU в Willi: 1. Вообще-то их там всегда и было 2: 1FPgeneral и 1FPmove, т.ч речь, видимо, идет о втором FPgeneral 2. iP4 может загружать только одно число из L1 кэша за такт (K7/8, кстати, 2). Соответственно, удваивать надо и LoadUnit, и FPmove. Но тогда, как и у K7/8, не хватит темпа uop-ов. 3. Плюс еще одно ограничение (по данным): очень маленький L1. Ну а предельный темп загрузки из L2 --- 1строка за 2 такта 4. Вообще, IMHO, у iP4 существовало очень простое решение знаменитой проблемы медленного x87: опять же , расширить FP MULunit с 64бит до 80 (мантисса с 52? до 64 --- всего ничего, 25%) --- тут все мое IMHO, т.к. этих данных нет в доках--- Однако! --- это должно было привести либо к увеличению латентности выполнения mul, либо к ограничению на тактовую частоту всего процессора. может, "зарезали" не второй блок, а второй порт (темп выполнения), иными словами, ширину [части] FPU, сделав ставку на более узкие, а следовательно, лучше подходящие для NetBurst данные SSE2?

Автор:

GReY [ 13:02 17.05.2004 ]

Заголовок сообщения:

BEKTOP

Цитата:
>Были внутренние доки... А из открытых источников — веб-сайты. Сделайте поиск по Willamette и наверняка на что-нибуд наткнетесь.\

В том-то и дело, что никаких даже полуофициальных подтверждений я так и не видел.

Цитата:
>Инквайр это ребята еще те... Только их в пору Willamette еще не было, ИМХО.\

Да вроде были.

Автор:	U2 [ 15:59 17.05.2004 ]
Заголовок сообщения:
Yury_Malich Предлагается всем присоединится к обсуждению возможностей будующих Pentium M и возможно К9. K9 спекуляции от pgerassi @SI <BLOCKQUOTE><SPAN class=hquote>цитата:</SPAN><HR size=22><SPAN class=quote>K9 Speculations: 1) AMD Patent on cross synchronizing dual register sets. With a dual set K8 3 wide decoders and 2 sets of K8 execution units, this makes for a 6 wide AMD64 CPU. Each set executes instructions and sees data from its own set of registers. Each cycle the register sets are made exactly the same as changes to one are duplicated to the other. Currently K8 has between 1.9 and 2.1 IPC. This would push K9 to do more than 3 IPC on a single execution thread. 2) Both paths of conditional branches are taken and when the actual path is known, the wrong path results are flushed. This will probably add 0.25 to 0.5 to the IPC. 3) Dual FPadd and FPmul units are targeted per register set. This allows 1 packed SSE2 add and 1 packed SSE2 multiply per cycle. Virtually doubles SSE2 performance per set. 4) Add memory area owner routing table for the local memory and a remote memory route table. The first holds all the local memory areas owned by a CPU cache in the form of the owning CPU's id. This would greatly reduce the needed HT traffic when local memory is accessed. The second helps route a request for a remote memory area by telling the remote memory controller's HT target id and the HT link with the shortest path. This also cuts the amount of HT traffic. Basically both of these improves the ultimate scalability of the glueless SMP and decreases the cache coherency overhead of the HT link net. With this, latency may be cut 10% and the HT link net's size to 32 to 64 way. 5) Doubling the HT target Id size from 8 bits to 16 bits. This may allow up to 15K dual core nodes in any HT link net. Of course the standard HT link speeds will double or more. 6) An additional support chip is a memory controller only with just the xbar HT switch and 3 HT links. In this die, the CPU cores are removed along with the L1 and L2 caches. This allows the memory channels to be used in a complete HT link net without the cost of the CPU. Thus a 4 way board can have only 1 true CPU and yet all the memory and I/O can be fully packed. Upgrades are the simple act of removing the placeholder packages and replacing it with a true CPU. This would also lower then power required for those larger memory and IO bound tasks. 7) In a similar vein, there would be CPUs with no memory controllers. These are for those MBs with no memory slots on those sockets. This may not be worth the small price differential unlike case 6 where the cost and power savings are substantial. All in all a 4 IPC K9 CPU that would trash all comers. Being usable in everything from small hand helds to massively parallel supercomputers is the great plus.</SPAN><HR size=22></SPAN></BLOCKQUOTE> matik Не знаю насчет внутренних доков — ничего такого не попадалось... Intel.com — The Microarchitecture of the Pentium® 4 Processor <BLOCKQUOTE><SPAN class=hquote>цитата:</SPAN><HR size=22><SPAN class=quote> Early in the development cycle of the Pentium 4 processor, we had two full FP/SSE execution units, but this cost a lot of hardware and did not buy very much performance for most FP/SSE applications. Instead, we optimized the cost/performance tradeoff with a simple second port that does FP/SSE moves and FP/SSE store data primitives. This tradeoff was shown to buy most of the performance of a second full-featured port with much less die size and power cost. </SPAN><HR size=22></SPAN></BLOCKQUOTE>

Автор:	matik [ 10:57 18.05.2004 ]
Заголовок сообщения:
U2 Intel.com — The Microarchitecture of the Pentium® 4 Processor Хм Смущен Уели!

Автор:	Ivan Andreevich [ 09:31 19.05.2004 ]
Заголовок сообщения:
Yury_Malich BEKTOP Так что мы по вашему увидим в Pentium M Dual Core @ Desktop —> SSE3? SSE4? Что-то другое? Ничего? 64 бита? Hyper Threading?

Автор:	zurzic [ 12:07 19.05.2004 ]
Заголовок сообщения:
Ivan Andreevich Я могу лишь высказать своё предположение, которое лежит где-то между желаемым и возможным: — SSE3 — x86-64 Ещё теоретически возможно уширение FPU до 128 бит (или удвоение существующих), как инженерам Интел проще будет. SSE4 я думаю пока не будет, в целесообразнность HT в Pentium M я не верю

Автор:	matik [ 12:40 19.05.2004 ]
Заголовок сообщения:
Yury_Malich в целесообразнность HT в Pentium M я не верю Боюсь, все равно придется сделать. Хотя бы из того соображения, что, раз технология объявлена, и в нее вложены средства, то поддерживать придется... Кстати, возможно, двухядерность в Pentium M в некотором роде компенсация НТ в П4...

Автор:	ISA_user [ 16:13 19.05.2004 ]
Заголовок сообщения:
Yury_Malich в целесообразнность HT в Pentium M я не верю а что Вы думаете в целесобразность что-то похожего (картинка даже была с отличими НТ и CМТ) в итаниках? matik раз технология объявлена, и в нее вложены средства, то поддерживать придется... так она далаже один явный плюс — застативила некоторые софтовые фирмы поддерживать двушки за теже деньги, что и однушки. А значит, можно будет ломать в том же направлении и по поводу двухядерных.

Автор:	Stranger_NN [ 16:53 19.05.2004 ]
Заголовок сообщения:
ISA_user, позволю себе вмешаться, но в отсутствие "сверхглубокого конвейера" и прочих прелестей NetBurst — не вижу смысла в HT. Точнее, как говорит matik, скорее всего сделают, но выигрыш от нее будет мизенрый, и несопоставимый с тем, к чему мы привыкли (не привычные +5-15% в зависимости от задачи, а +5%, если повезет). Ровно то же самое и для итаника, тем более, что там, в идеале, ситуаций, в которых можно применить HT-подобную технологию не должно возникать вообще.

Автор:	matik [ 17:01 19.05.2004 ]
Заголовок сообщения:
ISA_user Согласен — тем более, что двухядерность выглядит в некотором смысле логичным продолжением НТ...

Автор:	zurzic [ 17:02 19.05.2004 ]
Заголовок сообщения:
ISA_user Цитата: >а что Вы думаете в целесобразность что-то похожего (картинка даже была с отличими НТ и CМТ) в итаниках\ CМТ — это SMT? Честно говоря не видел этой картинки. Но что могу сказать с ходу: я думаю будет не эффективно, если два потока в Итанике будут работать на одних и тех же вычислительных узлах. Поясню. Оптимизация под Итаник очёнь жёстко планируется на основании латентностьей команд, количества испонительных модулей и порядка портов, принимающи команды на исполнения. Вплоть до положения комад внутри одной группы. Если хоть одной команде из связки не хватит ресурсов, все следом идущие группы тупо упрутся в эту команду, и будут ждать, пока она уйдёт исполнятся. Это как раз тот случай когда семеро ждут одного. Если будет конкуренция за исполнительные ресурсы между двумя потоками, — это труба. Производительность уйдёт в минус.

Автор:	ISA_user [ 17:26 19.05.2004 ]
Заголовок сообщения:
Yury_Malich SMT ага если два потока в Итанике будут работать на одних и тех же вычислительных узлах. в том то и дело, что на картинке как раз что-то было. картинку ищу Но интел все равно утверждает, что делать это в итаниумах будет.

Автор:	matik [ 17:33 19.05.2004 ]
Заголовок сообщения:
Yury_Malich Кстати, если предположить, что, несмотря на тщательное планирование, довольно часто бывает ситуация, когда бандл ждет данных из памяти, то тогда идея НТ оказывается даже для Итаниума осмысленной... На фоне ожидания основной ветки вполне можно было бы исполнять побочную...

Автор:	ISA_user [ 17:37 19.05.2004 ]
Заголовок сообщения:
Stranger_NN но в отсутствие "сверхглубокого конвейера" и прочих прелестей NetBurst дык как правильно сказал matik: довольно часто бывает ситуация, когда бандл ждет данных из памяти, то тогда идея НТ оказывается даже для Итаниума осмысленной... Понятно, что сейчас с этим борються огроменными кэшами, но они тоже не резиновые...

Автор:	matik [ 17:44 19.05.2004 ]
Заголовок сообщения:
ISA_user Они мало того что не резиновые — иногда сама технология кэширования не в состоянии помочь в силу ограниченности стратегии... Например, когда есть несколько подряд условий выбора... Что ж кэшам, подтаскивать данные для всех веток? Никакой ПСП не хватит... Впервые попадаю в ситуацию, когда два оппонента спорят, при этом оба ссылаются на мои слова

Автор:	zurzic [ 21:16 19.05.2004 ]
Заголовок сообщения:
matik Цитата: >Кстати, если предположить, что, несмотря на тщательное планирование, довольно часто бывает ситуация, когда бандл ждет данных из памяти,\ Вообще-то для маскировки этого есть спекуляции данных и префетч. Я просто боюсь, что это не будет эффективно. Вариант 1. В одном из потоков не будет дырок-обращений к памяти достоточного количества, например я запущу на минуту чистый счётный цикл, умещающийся в кэше, таких задач много. Когда работать второму потоку. Что будет делать второй поток: тормозить и глючить? Вариант 2. Поток осуществяет последовательный доступ к памяти. ПСП максимальна. Если в дыках второй поток будет инициировать обращения к памяти , доступ к памяти от процессора не будет уже линейным, ПСП резко снизится, общая производительность 2-х потоков производительность может уйти в минус по сравнению с классической моделью переключений задач.

Автор:	Arie [ 21:28 19.05.2004 ]
Заголовок сообщения:
Yury_Malich Второй случай будет наблюдаться и при двуядерном варианте.

Автор:	matik [ 22:52 19.05.2004 ]
Заголовок сообщения:
Yury_Malich Вообще-то для маскировки этого есть спекуляции данных и префетч. Я просто боюсь, что это не будет эффективно. Ну и префетч какой ветки загружать в случае нескольких подряд условий? Или все 4? Вот это точно бестолковый вариант. Кроме того, есть вот какой нюанс: время "подтаскивания" данных из ОЗУ на самом деле может сильно отличаться раз от раза, в зависимости от того, открыт или закрыт нужный банк, проходит ли микросхема процедуру рефреша. Разница может составлять несколько десятков наносекунд (!), то есть больше сотни процессорных тактов. Причем мы заранее не знаем, будет наш префетч долгим, или коротким. Вот это время можно потратить с пользой. Естественно, если мы допускаем, что "пузырьки" в исполняемых бандлах есть. Вариант 1: вообще-то такая ситуация есть и на П4. И для второго потока отдается команда "Pause", а в SSE3 вроде и "MWait" (если не перепутал). То есть здесь ситуация не будет отличаться от ситуации на П4. Для плотных вычислительных задач НТ стоит использовать для загрузки данных в кэш. Вариант 2: В этом случае у нас вообще неважен КПД используемых блоков процессора, поскольку мы лимитированы ПСП памяти. Даже если у нас в бандле всего одна команда из трех, мы не сможем увеличить КПД процессора. НО! Вот как раз тогда стоит запускать твою задачу из варианта 1 Вместе результат будет лучше, чем поотдельности...

Автор:	zurzic [ 12:36 20.05.2004 ]
Заголовок сообщения:
matik Цитата: >Вариант 1: вообще-то такая ситуация есть и на П4. И для второго потока отдается команда "Pause", а в SSE3 вроде и "MWait" (если не перепутал). То есть здесь ситуация не будет отличаться от ситуации на П4. Для плотных вычислительных задач НТ стоит использовать для загрузки данных в кэш.\ Нет! Это совсем разные ситуации, я вообще не вижу ничего общего. Во-первых, в П4 аппаратный планировщик и там просто не будет случаев, когда из-за занятости какого-то ресурса все в следум идущие команды упрутся в одну единственную. Во-вторых, ресурсов Итаниум2 чётко достаточно для того чтобы исполнять 2 бандла за такт, лишнего практически нет. В-третьих, если использовать останов конвейера в результате ожиданиия доступа к памяти, то второй поток назначенный на второй виртуальный процессор операционной системой может в течении нескольких секунд не получить ни одного процессорного такта, если первы поток не полезет в память. А эти два потока вообще могут принадлежать разным процессам многозадачаной операционной системы. Ведь решает задачу переключения потоков операционная система, а она понятия не имеет: будет доступ к памяти или нет.

Автор:

zurzic [ 12:45 20.05.2004 ]

Заголовок сообщения:

matik

Цитата:
>Ну и префетч какой ветки загружать в случае нескольких подряд условий? Или все 4? Вот это точно бестолковый вариант.\

Конечно не все. Дырки конечно всё равно будут, но вот использовать их IMO вредно.

Цитата:
>Кроме того, есть вот какой нюанс: время "подтаскивания" данных из ОЗУ на самом деле может сильно отличаться раз от раза, в зависимости от того, открыт или закрыт нужный банк, проходит ли микросхема процедуру рефреша. Разница может составлять несколько десятков наносекунд (!), то есть больше сотни процессорных тактов. Причем мы заранее не знаем, будет наш префетч долгим, или коротким. Вот это время можно потратить с пользой.\

Всё верно. Для этого команда префетча или спекулятивной загрузки запускается на выполнение задолго до того (например итераций за 20 цикла), как будет востребованы данные. Всё время между командой спекулятивной загрузки и командой требующей данные процессор обрабатывает данные, уже подошедшие к процессору. Согласен, что простои всё равно не избежны, так как процессор обрабатыает данные быстрее, чем доставляет FSB. Но! Эти попытка использования этих простоев обернётся не выгодой, а как раз на оборот — создаcт пробки в потоке каманд, как на городском перекрёстке в час-пик.

[Исправлено: Yury_Malich : 20-05-2004 14:10]

Автор:	zurzic [ 12:48 20.05.2004 ]
Заголовок сообщения:
Arie Цитата: >Второй случай будет наблюдаться и при двуядерном варианте\ Конечно! Но в двухядерном варианте исполнительных ресусов в 2 раза больше и нет ряда общих частей, таких как конвейер и кэш L1. Поэтому там овчинка выделки стоит, а здесь нет

Автор:	matik [ 00:05 21.05.2004 ]
Заголовок сообщения:
Yury_Malich Во-первых, в П4 аппаратный планировщик и там просто не будет случаев, когда из-за занятости какого-то ресурса все в следум идущие команды упрутся в одну единственную. Сорри, аппаратный планировщик ЧЕГО? Собственно, команда "Pause" мною ведь не выдумана — это действительно рекомендация Интел для потока, ожидающего данных, например, из памяти. Если ее не применять — ожидающий поток притормаживает остальные. То есть, в текущем П4 эта проблема есть — и Интел специально обращает внимание на метод ее обхода. Во-вторых, ресурсов Итаниум2 чётко достаточно для того чтобы исполнять 2 бандла за такт, лишнего практически нет. Формально у П4 тоже нет лишних ФУ... Только вот те, что есть, иногда простаивают. И увеличить их КПД с помощью НТ оказалось более-менее эффективным. Безусловно, прямой перенос НТ на Итаниум скорее вреден — но такой глупости я вроде и не предлагал Думаю, доработают. Ниже есть идея, как именно. Ведь решает задачу переключения потоков операционная система, а она понятия не имеет: будет доступ к памяти или нет. Задача решается введением служебного счетчика. Например, если в течении (условно) 1000 тактов второй поток не получил доступа к ФУ, инициируется стандартный механизм вытесняющей многозадачности, и второму потоку передается управление средствами ОС. Согласен, что простои всё равно не избежны, так как процессор обрабатыает данные быстрее, чем доставляет FSB. Но! Эти попытка использования этих простоев обернётся не выгодой, а как раз на оборот — создаcт пробки в потоке каманд, как на городском перекрёстке в час-пик. А вот в этом случае проблема элементарно решается присванием второму потоку меньшего приоритета, чем у основного потока. Тогда, пока первый поток ждет данных, второй работает. Как только появились данные — исполнение второго приостанавливается.

Автор:

zurzic [ 08:57 21.05.2004 ]

Заголовок сообщения:

matik

Цитата:
>Cорри, аппаратный планировщик ЧЕГО?\

Команд, чегож ещё?

Цитата:
>Собственно, команда "Pause" мною ведь не выдумана — это действительно рекомендация Интел для потока, ожидающего данных, например, из памяти. Если ее не применять — ожидающий поток притормаживает остальные.\

Я знаю как и для чего применяется Pause. Я даже тест писал http://www.fcenter.ru/articles.shtml?processors/8473#16 который её использует

Цитата:
>То есть, в текущем П4 эта проблема есть — и Интел специально обращает внимание на метод ее обхода.\

Это не та проблема. Pause — это средство борьбы с короткими сигнальными циклами типа
while (signal!=0);
которые генерирую сплошной потоко каманд обращения к load юниту и кэш памяти и тем самым неоправданно жрут ресурсы.

Цитата:
>Формально у П4 тоже нет лишних ФУ... Только вот те, что есть, иногда простаивают. И увеличить их КПД с помощью НТ оказалось более-менее эффективным.\

М..м. Самый простой пример.
Во-первых, у Р4 конвейер 22 стадии у Nothwood и 30+ стадии у Пресса , каждый промах освобождает кучу исполнительных ресурсов. У Itanium 2 ковейер 8 стадий, да ещё + предикаты, которые позоляют избавится от большинства коротких ветвлений + специальная организация циклов, позволяющая процессору точно знать, когда произойдёт выход из него + специальные BR регистры, позволяющие точно указать процессору с какой точни начинать выбирать код для будующего ветвления.
В-вторых, планировщик П4 сам знает загруженность и латентности команд решает порядок отсылки команд того или иного потока на основании загруженности модулей. Itanium не имеет планировщика. Как эффективно исполнять код двух потоков?
Теперь о КПД. Не далее как вчера принимал участие в тестировании сжатия домашнего DV ролика с помощью Canopus Pro Coder в Mpeg2 на П4 3 Ггц. Результат 52 сек vs 54 с включенным и выключенным HT. И ведь в большинстве задач выигрыш HT редко превышает 10% на П4. Наверное ты не будешь со мной спорить, что на Itanium 2 даже если выигрыш теоретически возможет, то он всё будет ещё меньше. Стоит ли тратить деньги и городить огород ради копеечно выигрыша?

Цитата:
>Задача решается введением служебного счетчика. Например, если в течении (условно) 1000 тактов второй поток не получил доступа к ФУ, инициируется стандартный механизм вытесняющей многозадачности, и второму потоку передается управление средствами ОС.\

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

Цитата:
>А вот в этом случае проблема элементарно решается присванием второму потоку меньшего приоритета, чем у основного потока. Тогда, пока первый поток ждет данных, второй работает. Как только появились данные — исполнение второго приостанавливается.\

Ага, допускаю. А как ОС определит кому в процессоре выставить больше приоритет, а кому меньше, если оба потока изначально имеют одинаковый приоритет?

Теперь вернёмся к П4. Наверняка все ресуры П4 отдаются командам второго потока, если первый поток стоит в ожидании данных из памяти. Но почему-то, как я писал выше, эффект редко превышает 10%. Если у процессора на борту кэш 3-6 МБ. Не будет ли этот эффект ещё больше снижен, в добавление к тем чертам Itanium , о которых я написал выше?

Автор:	zurzic [ 09:06 21.05.2004 ]
Заголовок сообщения:
matik Кстати может есть смысл перебросить обсуждение в ветку про Итаниум?

Автор:	matik [ 10:48 21.05.2004 ]
Заголовок сообщения:
Yury_Malich <font class="off">Кстати может есть смысл перебросить обсуждение в ветку про Итаниум? Текущая версия UBB не позволяет перебрасывать отдельные постинги... </font> Itanium не имеет планировщика. Как эффективно исполнять код двух потоков? Естественно, НТ имеет смысл вводить тогда, когда Итаниум будет его иметь. Думаю, рано или поздно, но это произойдет. Ибо деваться все равно некуда — линейные методы повышения производительности применены уже в текущих ядрах. И ведь в большинстве задач выигрыш HT редко превышает 10% на П4 Оно-то так... Только иногда это существенный выигрыш. И почему-то в рассчетных задачах. Учитывая область применения Итаниума, это становится осмысленным. Стоит ли тратить деньги и городить огород ради копеечно выигрыша? Просто ради галочки — нет, не стоит. С другой стороны, работая с НТ, многие софтовые фирмы попутно провели оптимизацию под SMP... Вот ради этого — стоит, ибо многоядерные Итаниумы все равно будут делать. Согласен? Если рассматривать НТ как промежуточную точку к многоядерным процессорам (а, похоже, так оно и есть), то тогда смысл в этой технологии появляется. Впрочем, я не то чтобы сильно "за" НТ — но некий смысл в этом мероприятии найти можно. Да, прирост будет отнюдь не впечатляющим, но зато вполне в русле господствующей сейчас в Интел "идеологии" Если хотя бы пятая часть программ получит хоть сколько-нибудь заметное ускорение от НТ на Итаниуме, то, учитывая область применения этого процессора, это будет уже полезным нововведением. Хотя, конечно, лично мне было бы интереснее прочитать о каких-нибудь архитектурных нововведениях...

Автор:

GReY [ 10:59 21.05.2004 ]

Заголовок сообщения:

Stranger_NN

Цитата:
>в отсутствие "сверхглубокого конвейера" и прочих прелестей NetBurst — не вижу смысла в HT. Точнее, как говорит matik, скорее всего сделают, но выигрыш от нее будет мизенрый\

Хм, а какой прок гиперсредингу от длинного конвеера? Шина будет та же, кэша ещё больше — прок будет.

Yury_Malich

Цитата:
>Что будет делать второй поток: тормозить и глючить?\

Хороший вопрос

Нужен механизм вытеснения по приоритетам.

Цитата:
>доступ к памяти от процессора не будет уже линейным, ПСП резко снизится\

Не думаю. Префетч нам поможет — суммарная ПСП двух потоков останется максимальной.

Цитата:
>у Р4 конвейер 22 стадии у Nothwood и 30+ стадии у Пресса , каждый промах освобождает кучу исполнительных ресурсов. \

Про реплей уже забываем?

Автор:

zurzic [ 12:15 21.05.2004 ]

Заголовок сообщения:

matik
<BLOCKQUOTE>цитата:<HR size=22>Itanium не имеет планировщика. Как эффективно исполнять код двух потоков?
Естественно, НТ имеет смысл вводить тогда, когда Итаниум будет его иметь.<HR size=22></BLOCKQUOTE>
Будет ли? Это несколько противоречит концепции EPIC.

Цитата:
> И почему-то в рассчетных задачах. Учитывая область применения Итаниума, это становится осмысленным.\

Думаешь в такой реально будет найти столько простаивающих ресурсов, чтобы выиграть хотя бы 10%. Честно говоря, я так не думаю. Просто честно на мой взгляд: там столько проблем придётся решать, что проще сделать два простых ядра с обшим кэшем, чем делать планировщики и ещё кучу связанного с ними.

Цитата:
> С другой стороны, работая с НТ, многие софтовые фирмы попутно провели оптимизацию под SMP... Вот ради этого — стоит, ибо многоядерные Итаниумы все равно будут делать. Согласен? Если рассматривать НТ как промежуточную точку к многоядерным процессорам (а, похоже, так оно и есть), то тогда смысл в этой технологии появляется.\

Я как разработчик ПО поспорил. Просто оптимизации для 2-х ядер и для HT нужно подходить с несколько разных сторон. А на доводку софта под каждую новоую технологию нужна уйма времени и денег.

Цитата:
>Хотя, конечно, лично мне было бы интереснее прочитать о каких-нибудь архитектурных нововведениях...\

GReY

Цитата:
>Не думаю. Префетч нам поможет — суммарная ПСП двух потоков останется максимальной.\

Префетч в Итаниум и так всегда должен быть по концепции оптимизации.

Насчёт максимальной ПСП: как лучше — каждый такт выдавать запрос в смежный участок памяти, или чередовать с другим потоком?

. Мне кажется что первый вариант будет прокачивать больше МБ/с.

Цитата:
>Про реплей уже забываем?\

Не то чтобы забываем. Глючим.

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

Автор:	GReY [ 13:07 21.05.2004 ]
Заголовок сообщения:
Yury_Malich Цитата: >как лучше — каждый такт выдавать запрос в смежный участок памяти, или чередовать с другим потоком? \ Почти пофиг — в каждом банке памяти 4 страницы, чем больше страниц (больше модулей памяти), тем больше разных участков памяти можно держать открытыми.

Автор:	matik [ 14:54 21.05.2004 ]
Заголовок сообщения:
Yury_Malich Это несколько противоречит концепции EPIC. Ну, давай опять попробуем пофантазировать Безусловно, напрямую планировать порядок команд нельзя — это действительно противоречит концепции (хотя, если это будет приносить дивиденды в плане скорости, подозреваю, что "концепция пойдет лесом" ) Но вот порядок бандлов — вполне можно менять, если это дает выигрыш. Логично? Думаешь в такой реально будет найти столько простаивающих ресурсов, чтобы выиграть хотя бы 10% Теоретическая скорость — 6 команд за такт. Подозреваю, что средняя — в районе 2. Резерв огромный, логично? Безусловно, некоторая часть связана с недостатком ПСП. Но явно не все. ПСП памяти расширят, дело житейское. Но логику ядра тоже придется усилить... Просто честно на мой взгляд: там столько проблем придётся решать, что проще сделать два простых ядра с обшим кэшем, чем делать планировщики и ещё кучу связанного с ними. Проблемы, они везде будут. Думаешь, общий кэш — это сладко?! А арбитраж запросов? Учитывая, что каждый (!) такт на счету? Просто оптимизации для 2-х ядер и для HT нужно подходить с несколько разных сторон Ну, я их не приравниваю. Но согласись, что оптимизация под НТ и под SMP ближе друг к другу, чем оптимизация под один и под два процессора. Yury_Malich Насчёт максимальной ПСП: как лучше — каждый такт выдавать запрос в смежный участок памяти, или чередовать с другим потоком? Самый хороший вариант для нынешней памяти — давать 4 (8) смежных адреса, а затем к другому участку (банку) памяти Поэтому и с этой точки зрения есть смысл

Автор:	Stranger_NN [ 15:50 21.05.2004 ]
Заголовок сообщения:
GReY Цитата: >Хм, а какой прок гиперсредингу от длинного конвеера?\ Дык, там очень часто по нескольку десятков тактов "дыры" при ошибках предсказаний. Есть куда влезть, а если конвейер короткий — то только ситуевины ожидания памяти и остаются, что в хорошо оптимизированных программах бывает, полагаю, недостаточно часто.

Автор:	GReY [ 15:58 21.05.2004 ]
Заголовок сообщения:
Stranger_NN Цитата: >там очень часто по нескольку десятков тактов "дыры" при ошибках предсказаний\ Разве что при мисспредикте... IMHO HT везде толк даст, даже при коротком конвеере. Основная идея — перенести управление потоками с ядра винды на ядро проца. Тогда равномернее будут нагружаться все ФУ, не будет затрат на сохранение/восстановление контекста задачи.

Автор:	zurzic [ 16:19 21.05.2004 ]
Заголовок сообщения:
GReY Цитата: >Тогда равномернее будут нагружаться все ФУ, не будет затрат на сохранение/восстановление контекста задачи.\ Эти затраты ничтожны. Я как-то сделал оценку. Получалось что для 1 Ггц процессора 1500-2000 прерываний в секунду (при интенсивной работее с интегрированной сетевой картой) вызывают накладные расходы меннее 1%.

Автор:

zurzic [ 16:33 21.05.2004 ]

Заголовок сообщения:

GReY

Цитата:
>Разве что при мисспредикте...\

Можно подумать, что misspredict такое уж редкое событие.

10% неугаданных условных переходов — это IMO практически и есть те самые 10% выигранных от HT. Не забывай, что misspredict это не только условные переходы но и виртуальные функции.

Цитата:
>IMHO HT везде толк даст, даже при коротком конвеере. \

Не согласен. Я сам лично несколько раз сталкивался, когда включение HT оборачивалось снижением производительности. C коротким конвейером овчинка выделки не стоит. Ради 5% прироста в производительности в небольшом числе задач? Оно того не стоит. Лучше эти самые 5% получить новой ступенью тактовой частоты на том же самом конвейере, так как добавляя HT-логику ты усложняешь схему, а значит в принципе снижаешь потенциально допустимую тактовую частоту. Прирост частоты на 5% по крайней мере почувствуют больше задач, чем прирост от HT на 5%.

Цитата:
>Основная идея — перенести управление потоками с ядра винды на ядро проца. \

Оно того не стоит. Тем более, что ты не только в принципе не снимешь вопрос о переключении задач, так как их >2, но и усложнишь его, или поставишь ещё более сложный: нужно чтобы потоки с одинаковым приоритетом получали более-менее равные ресурсы, а с разным приоритетом- разные. В настоящей реализации HT AFAIK этого не наблюдается.

[Исправлено: Yury_Malich : 21-05-2004 18:07]

Автор:

zurzic [ 16:52 21.05.2004 ]

Заголовок сообщения:

matik

Цитата:
>Но вот порядок бандлов — вполне можно менять, если это дает выигрыш. Логично?\

Допускаю.

Цитата:
>Теоретическая скорость — 6 команд за такт. Подозреваю, что средняя — в районе 2. \

Я бы сказал, что не меньше 3-4 и цифра 6 вполне реально достижима на многих участках кода. Но без реальных цифр но руках это лишь моё IMO. IMO моё основано на том простом факте, что команды внутры бандла — типичные RISC. Поэтому много чего того, что CISC держит в одной команде, RISC держит в нескольких.

Цитата:
>Резерв огромный, логично? \

Логично, если 6 команд за такт действительно уходят< 50% случаев. К сожалению у меня нет точных данных и проверить сам без железа и софта не могу

Цитата:
>Безусловно, некоторая часть связана с недостатком ПСП. Но явно не все. ПСП памяти расширят, дело житейское. Но логику ядра тоже придется усилить...\

Если честно я думаю, что Итанику логики хватает, а вот тактовой частоты — нет.

Цитата:
>Проблемы, они везде будут. Думаешь, общий кэш — это сладко?! А арбитраж запросов? Учитывая, что каждый (!) такт на счету?\

HT от этой проблемы не спасёт

а если выбирать HT vs два простых ядра, я бы выбрал 2 ядра. Посмотрим что в конце концов выберет Интел

Цитата:
>Но согласись, что оптимизация под НТ и под SMP ближе друг к другу, чем оптимизация под один и под два процессора.\

Да, ближе. Но ресурсы у HT и двух ядер совсем разные.

Автор:	matik [ 17:27 21.05.2004 ]
Заголовок сообщения:
Yury_Malich IMO моё основано на том простом факте, что команды внутры бандла — типичные RISC. Поэтому много чего того, что CISC держит в одной команде, RISC держит в нескольких. М-м-м-м... Возможно. Тем не менее, даже если допустить 4 команды из 6 возможных, резерв — 50% (!) производительности. Много это, или мало? Особенно на фоне того, что по нынешним временам прирост 10% уже повод для радости... я думаю, что Итанику логики хватает, а вот тактовой частоты — нет. Погоди, а какая это в ядре Итаниума логика? Собственно, вся логика вынесена "за скобки", она в компиляторе... Если утрировать, то Итаниум — это блоки загрузки, кэш, и ФУ. И все. HT от этой проблемы не спасёт Как же не спасет? Если у нас НТ, у нас есть блок, который и ведает загрузкой данных. Есть единственная очередь, в которую кладут запросы. Управлять легко. Если же у нас два ядра с одним (!) кэшем, это означает, что надо вести две независимых очереди запросов, разрешать конфликты, и вообще вводить некий аналог MESI (MOESI) протокола для ядер... В случае с НТ этого всего не надо. Но ресурсы у HT и двух ядер совсем разные. Ну естественно, разные! Кто ж спорит... ИМХО, имеет смысл рассматривать НТ как остановку на пути к двухядерности — тогда и претензий к ней почти не остается...

Автор:

zurzic [ 06:58 22.05.2004 ]

Заголовок сообщения:

Цитата:
> Тем не менее, даже если допустить 4 команды из 6 возможных, резерв — 50% (!) производительности. Много это, или мало? Особенно на фоне того, что по нынешним временам прирост 10% уже повод для радости...\

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

Цитата:
>Погоди, а какая это в ядре Итаниума логика? Собственно, вся логика вынесена "за скобки", она в компиляторе... Если утрировать, то Итаниум — это блоки загрузки, кэш, и ФУ. И все.\

А вот не надо утрировать.

Если, как ты утрировать, то все x86 процессоры вплоть до Pentium Pro с его OutOfOrder исполнением,— это декодер, блоки загрузки, кэш, и ФУ. То есть как Pentium 1, но на самом деле в Itanium всё гораздо сложнее, чем в тех же Pentium 1.
<BLOCKQUOTE>цитата:<HR size=22>Как же не спасет? Если у нас НТ, у нас есть блок, который и ведает загрузкой данных. Есть единственная очередь, в которую кладут запросы. Управлять легко.
Если же у нас два ядра с одним (!) кэшем, это означает, что надо вести две независимых очереди запросов, разрешать конфликты, и вообще вводить некий аналог MESI (MOESI) протокола для ядер... В случае с НТ этого всего не надо.<HR size=22></BLOCKQUOTE>
Не понимаю, зачем ты усложняешь

. Достоточно контролеера кэша со своей очередью. Если быть точным то такой контроллер с очередью уже есть. Назвается L2 OzQ.

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

[Исправлено: Yury_Malich : 22-05-2004 22:36]

Автор:

GReY [ 12:09 22.05.2004 ]

Заголовок сообщения:

Yury_Malich

Цитата:
>для 1 Ггц процессора 1500-2000 прерываний в секунду (при интенсивной работее с интегрированной сетевой картой) вызывают накладные расходы меннее 1%\

Однако загрузка процессора почему-то составляет десятки процентов...

Цитата:
>так как добавляя HT-логику ты усложняешь схему\

IMHO очень незначительно.

Цитата:
>В настоящей реализации HT AFAIK этого не наблюдается.\

Именно!

Цитата:
>Назвается L2 OzQ.\

Чего чего?

Автор:

zurzic [ 21:33 22.05.2004 ]

Заголовок сообщения:

GReY

Цитата:
>Однако загрузка процессора почему-то составляет десятки процентов...\

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

.
Не правда, я серьёзно. Проверь сам. Количество прерываний в секунду легко посмотреть в счётчиках производительности в Win2000, XP. Задачи реально переключаются даже реже, чем непосредственно происходят прерывания, AFAIK число переключений задач < 500 в секунду, реально около 100, но возьмём грубо 1000. Порядок накладных расходов на сохранения контекста одной задачи и восстановление другой можно оценить, они вряд ли превышают 10000 тактов. Возьмём и прикинем грубо с большим запасом: 1000 переключений в секунду * 10000 тактов = 10 000 000 потерянных на переключения тактов в секунду. Для процессора с частотой 1 000 000 000 Гц это 1%. Реально это цифра ниже, раз в 10, так как я брал с запасом

Цитата:
> L2 OzQ Чего чего?\

25111002 — Intel Itanium 2 Processor Reference Manual For Software Development and Optimization.pdf
"The L2 cache is non-blocking and out of order. All memory operations that access the L2 (L1D misses and all stores) check the L2 tags and allocate into a 32 entry queuing structure called the L2 OzQ...
6.7.2 L2 OzQ
The non-blocking nature of the L2 is made possible by the L2 OzQ. This structure holds up to 32 operations that cannot be satisfied by the L1D. These include all stores, semaphores, uncacheable accesses, L1D load misses, and L1D unresolved conflict cases. The L2 cache design requires fewer than 32 L2 OzQ entries to hold the maximum number of L1D requests in conflict-free cases. However, there are many conflict cases within the L2. These cases may increase request lifetimes in the L2 OzQ. Thus, the additional entries allow the L1D pipeline to continue to service hits and make additional requests of the L2 while the L2 resolves the conflicts. The conflicts increase the L2 latency and make L2 latency prediction impossible.
"

Автор:	matik [ 22:21 22.05.2004 ]
Заголовок сообщения:
Yury_Malich Ага, но только, если резерв этот будет на уровне бандлов (вернее даже групп), а не отдельных команд, потому, как если бандлы (даже группы) не будут уходить целиком, то семеро одного ждут. Если не будет свободных ресурсов отправлять бандлы (группы) целиком, то ни о каком более эффективном использовании ресурсов при двухпоточном исполнении речи идти просто не может. Кстати, мелькнула у меня еще одна сумасшедшая идея... Как ты знаешь, в случае, если бандл нечем дополнить, то в него добавляют NOP. А теперь представь себе логику, которая отслеживает NOP-ы в бандлах, и меняет их на команды из второй нити программы. Вот тебе и "появившиеся ниоткуда" ресурсы Иэх, почему я не разработчик? Если, как ты утрировать, то все x86 процессоры вплоть до Pentium Pro с его OutOfOrder исполнением,— это декодер, блоки загрузки, кэш, и ФУ. То есть как Pentium 1, но на самом деле в Itanium всё гораздо сложнее, чем в тех же Pentium 1. "Я, конешно, дико извиняюсь" © Гоблин, но что ж там "гораздо сложнее"? Фактически, разве что логика "вращения регистрового файла" может претендовать на некоторую сложность. Какие еще сложные элементы (сравнимые с декодером команд или планировщиком в х86-процессорах) ты можешь назвать? Не понимаю, зачем ты усложняешь Вас, Егоровых, не поймешь! © анекдот Так я усложняю, или упрощаю? Кстати, насчет L2 OzQ... Название, конечно, красивое... Но почему-то вдруг припомнилось, что еще Пентиум Про мог создавать очередь до 8-ми отложенных запросов. Я не готов спорить, тот же это механизм, или нет — но логично было бы предположить, что в Итаниуме его потомок. Я же говорю несколько о другом. Пусть у тебя два ядра с общим кэшем L2. Пока идет только чтение из одной и той же ячейки, все в порядке. Если же одно из ядер в процессе работы модернизировало содержимое ячейки кэша, то появляется проблема: второе ядро должно узнать, что ячейка изменена, и перечитать ее. Собственно, проблема кэш-когеррентности. Да, кэш у нас один, и пересылать данные куда-то не понадобится. Но вот все остальные этапы (выставление Owned для ячейки, сохранение в памяти, и так далее) — все это понадобится. И то, что очередь у Итаниума умная, и может сохранять 32 запроса — никак в данной ситуации не помогает. Потому что в тот момент, когда она формировалась, ячейка еще не была изменена. GReY Честно говоря, в вопросе загрузки процессора переключением задач согласен с Юрой — занимает это явно немного. Другой вопрос, что одна некорректно написанная задача способна сильно испортить ситуацию (вовремя не отдав управление), это да. Возможно, имеет смысл механизм смены тредов сделать аппаратным — ровно для того, чтобы никогда не возникло ситуации "система не отзывается на действие пользователя".... Правда, это потребует корреной смены принципа управления приоритетами процессов, как мне кажется...

Автор:

zurzic [ 07:59 23.05.2004 ]

Заголовок сообщения:

matik

Цитата:
> Если же одно из ядер в процессе работы модернизировало содержимое ячейки кэша, то появляется проблема: второе ядро должно узнать, что ячейка изменена, и перечитать ее. Собственно, проблема кэш-когеррентности. Да, кэш у нас один, и пересылать данные куда-то не понадобится. Но вот все остальные этапы (выставление Owned для ячейки, сохранение в памяти, и так далее) — все это понадобится.\

Понял, извини сразе не ссообразил о чём ты.

Ну так Itanium 2 в настоящее время поддерживает многопроцессорное взаимодействи? Поддерживает. Флаги M, E, и S в кэшах есть? Есть. Snoop-запросы есть. И какая в принципе разница теперь: будут отправлятся запросы двух процессорнрого взаимодествия на системную шину или во второе ядро? А L1D в Itanium write-throught. Это значит в кэше L2 всегда можно найти последние данные.

Цитата:
> Какие еще сложные элементы (сравнимые с декодером команд или планировщиком в х86-процессорах) ты можешь назвать?\

Подумаю, если надумаю, чуть позже отвечу. Но вообще это для меня не принципиально. Это может быть принципиально для Intel

.

[Исправлено: Yury_Malich : 24-05-2004 09:12]

Автор:	ISA_user [ 08:42 23.05.2004 ]
Заголовок сообщения:
matik А теперь представь себе логику, которая отслеживает NOP-ы в бандлах, и меняет их на команды из второй нити программы. Вот тебе и "появившиеся ниоткуда" ресурсы Как раз это на картинке то и было вот блин тему начал, а картинку все найти не могу Собственно, проблема кэш-когеррентности. поддерживаю Юру, сей механизм и так есть, он просто в двухядерном, но с одним кэшем, даже быстрее отрабатывать будет, т.к. не нужно будет "чужой" кэш обновлять.

Автор:	VLev [ 10:27 23.05.2004 ]
Заголовок сообщения:
<BLOCKQUOTE><SPAN class=hquote>цитата:</SPAN><HR size=22><SPAN class=quote>Yury_Malich: Ага, но только, если резерв этот будет на уровне бандлов (вернее даже групп), а не отдельных команд, потому, как если бандлы (даже группы) не будут уходить целиком, то семеро одного ждут. Если не будет свободных ресурсов отправлять бандлы (группы) целиком, то ни о каком более эффективном использовании ресурсов при двухпоточном исполнении речи идти просто не может.</SPAN><HR size=22></SPAN></BLOCKQUOTE> Ну да. Именно потому IMHO, HT на Itanium будет весьма полезен, но только не в том виде, что он есть в NetBurst (где uop-ы разных потоков перемешаны). Лично я представляю себе этот процесс так: 1. Есть 2 типа принципиально плохопредсказуемых событий --- условный переход и загрузка из иерархии памяти. За ошибку первого штраф ~10-100тактов (IMH, в среднем ближе к 10), второго ~10-1000 тактов (в случае RAM ближе к 1000), причем в это время процессор просто простаивает. Интегральные потери от этих неприятностей зависят конечно от задачи, но есть типы приложений, где они существенно > 50%. 2. Как заполнять простои от непредсказанных условных переходов я не знаю, а вот при непрефетченном доступе в память образуется дыра в несколько сот тактов, куда вполне естественно засунуть выполнение пторой нити. 3. Даже если все доступы в память предсказаны (что вообще говоря, пока --- недостижимый идеал), причем достаточно рано [для компенсации латентности], то и тогда совершенно не факт, что процессор не будет простаивать. Если приложению не хватает ПСП, то простои все равно будут. И вполне естественно туда попытаться засунуть выполнение нити, нетребовательной к ПСП.

Автор:	zurzic [ 08:22 24.05.2004 ]
Заголовок сообщения:
matik Цитата: >Кстати, мелькнула у меня еще одна сумасшедшая идея... Как ты знаешь, в случае, если бандл нечем дополнить, то в него добавляют NOP. А теперь представь себе логику, которая отслеживает NOP-ы в бандлах, и меняет их на команды из второй нити программы. Вот тебе и "появившиеся ниоткуда" ресурсы\ Ну не то что это теоретически принципиально не выполнимо, но применительно к существующей системе команд это не даст выигрыша. Первая проблема в вся в том что шаблоны бандлов строго определены, как и порты привязанные к слотам, и команды например из слота 0 одного бандла в слот 1 другого бандла в подавляющем большинстве случаев перекинуть просто невозможно. Проблема 2: nop-ы распередлены в слотах крайне не равномерно. AFAIK наиболее часто пустует слот 2, за тем 0 и наиболее используемый слот 1. Проблема 3: если не удастся раскидать все команды связки, то совершенно не какого эффекта от такого перераспределения не произойдёт (потому как всё равно сколько в связке останется команд 1 или 3, исполнятся будет одинаково.). Вывод простой: кремния на реализацию подобного планировщика потратится много, а эффект вряд ли будет превышать даже 1%. Не эффективно.

Автор:	zurzic [ 08:47 24.05.2004 ]
Заголовок сообщения:
<BLOCKQUOTE><SPAN class=hquote>цитата:</SPAN><HR size=22><SPAN class=quote>Yury_Malich: 2. Как заполнять простои от непредсказанных условных переходов я не знаю, а вот при непрефетченном доступе в память образуется дыра в несколько сот тактов, куда вполне естественно засунуть выполнение пторой нити. </SPAN><HR size=22></SPAN></BLOCKQUOTE> Как я уже говорил, если на это рассчитывать, то второй поток может в течении нескольких секунд вообще не будут получать не одного такта (ну или скажем менее 1% ресурсов), потому как можно запустить чисто счётную, умещающуюся в кэш L2.

Автор:	matik [ 10:31 24.05.2004 ]
Заголовок сообщения:
Yury_Malich Первая проблема в вся в том что шаблоны бандлов строго определены, как и порты привязанные к слотам, и команды например из слота 0 одного бандла в слот 1 другого бандла в подавляющем большинстве случаев перекинуть просто невозможно Ну, в текущей реализации Итаниума вроде никто НТ и не предлагает, правда? Речь идет о будущих вариантах. А там у нас не так много вариантов.... Скажем, просто увеличивать количество одновременно исполняемых бандлов не очень эффективно. И еще одно: если жестко привязывать количество FPU и ALU к распределению команд в бандлах, то окажется, что у нас всегда должно быть соотношение FPU/ALU, например, равное 2 (цифра совершенно условна). Другими словами, мы заранее связали себя жестким соотношением исполнительных устройств. Отсюда и выходит, что мы вынуждены вставлять NOP-ы: не потому, что нечего исполнять, а потому, что заняты ФУ нужного нам типа. Если же допустить, что в следующих реализациях мы можем менять соотношение команд в бандлах, то и такие жесткие связи нам не нужны. Безусловно, это потребует и более сложной схемотехники, и нового компилятора. Но мне почему-то кажется, что эффект будет заведомо превышать "твой" 1% Кстати, предлагаю обсудить идеи по развитию Итаниума в соседней ветке (вместе с продолжением этого обсуждения) — а то мы "несколько" удалились от темы топика...

Автор:	VLev [ 10:38 24.05.2004 ]
Заголовок сообщения:
<BLOCKQUOTE><SPAN class=hquote>цитата:</SPAN><HR size=22><SPAN class=quote>Yury_Malich: Как я уже говорил, если на это рассчитывать, то второй поток может в течении нескольких секунд вообще не будут получать не одного такта (ну или скажем менее 1% ресурсов), потому как можно запустить чисто счётную, умещающуюся в кэш L2. </SPAN><HR size=22></SPAN></BLOCKQUOTE> Не, ну обычный механизм прерываний я не отменяю... Второй поток [если конечно он активен] получит управление сразу же, как только истечет квант времени, выделенный первому. Это где-то миллисекунды... Вероятно, необходим механизм приоритетов, учитывающий многопоточную природу процессора. Тогда, в твоем примере, сначала один квант времени основным является первый поток (второй простаивает), потом, второй квант времени, основным является второй поток, а первый лишь заполняет паузы от него (допустим, 50%). Итого, по сравнению с однонитиевым процессором: первый поток ускоряется в 1.5 раза, а скорость второго остается без изменений. По-моему, неплохо.

Автор:	zurzic [ 11:17 24.05.2004 ]
Заголовок сообщения:
VLev matik http://www.radeon2.ru/ubb/Forum17/HTML/000166-6.html

Автор:	C@t [ 15:35 24.05.2004 ]
Заголовок сообщения:
matik Yury_Malich VLev * По поводу "второго" FPU в K8+ Введение параллельных парных блоков FMUL/FADD — вещь нужная, важная и т.п. С одной стороны, по большому счёту это определённо _упрощает_ логику как декодера, так и планировщика. С другой — добавляет проблемы в плане передачи результата. Плюс, само собою, надо учитывать, что блоки эти довольно "массивные". В целом, если проецировать имеюшиеся возможности на будущее, вариант простого уширения блоков 64->128 кажется слишком простым и не очень интересным. ИМО, намного разумнее оставить 64р блокам самостоятельность, и увеличить их количество — благо система распределения команд это сделать позволяет. Имеет смысл "векторные" команды пускать в виде одной CISC-операции, "распадающейся" на ФУ, подобно тому, как это делается на П4 (что даёт существенную экономию позиций RS). Основная проблема — конечно же, обеспечение дополнительных блоков данными для достижения потребной загрузки. Очевидно, что перевод 2х64р. load'ов на 2х128р — не то, что бы хотелось. А 4х64(128) — слишком сложно. * По поводу P-M Сугубо временная конструкция, призванная закрыть сложившуюся брешь, и не поддающаяся перспективному улучшению в плане достижения рекордных показателей производительности *** По поводу HT Немного "прощупав" ситуацию, я прихожу к довольно забавному выводу, что основная польза от HT для П4 — компенсация коротких очередей. Естественно, при включенном HT глубина очереди уменьшается ещё в два раза, и реордеринг становится уже совсем ограниченным, но — теперь мы имеем две независимые цепочки, которые можно исполнять параллельно. [Независимые цепочки — дело обычное, например каждая итерация цикла "load — execute — store" почти независима от другой. Важно, однако, чтобы в очередь поместились команды, относящиеся как к этой итерации, так и к следующей. Раскрытие цикла не всегда здесь поможет, например, в случае, когда группа первых команд активно задействует один ФУ, а последних — другой.]

Автор:	matik [ 16:25 24.05.2004 ]
Заголовок сообщения:
C@t Сугубо временная конструкция, призванная закрыть сложившуюся брешь, и не поддающаяся перспективному улучшению в плане достижения рекордных показателей производительности Эко припечатал! Ну все, теперь в Интеле будут рыдать! А что насчет двухядерности? Тоже бесперспективно? С таким утверждением не согласен категорически — хотя бы потому, что двухпроцессорная система под нагрузкой работает намного плавнее, и быстро отзывается на действия пользователя. То есть, субъективно она быстрее — даже если некий расчет выполнится на такой системе медленнее. Да и, ИМХО, это достаточно перспективное направление.

Автор:	C@t [ 17:06 24.05.2004 ]
Заголовок сообщения:
matik А что насчет двухядерности? Тоже бесперспективно? Тут есть очень простой момент. <BLOCKQUOTE><SPAN class=hquote>цитата:</SPAN><HR size=22><SPAN class=quote>Andy Glew: Now, I'm not opposed to multithreading or multiprocessing. But, we continue to need faster CPU cores, if we need more performance at all: if you can integrate 4 Banias on a die this year, it will soon need to be 8, or 16, and soon you will exceed the number of CPUs that a single PC can use. (No prize for doing a Google processor, unless you are Afara and can get Sun to buy you out.) So, even if 2 and 4 CPU cores/chip are the future, you still need to improve single CPU performance.</SPAN><HR size=22></SPAN></BLOCKQUOTE>

Автор:	VLev [ 18:02 24.05.2004 ]
Заголовок сообщения:
Цитата: >C@t: Очевидно, что перевод 2х64р. load'ов на 2х128р — не то, что бы хотелось.\ А вот мне, как реальному потребителю FP производительности, это совершенно не очевидно. Кстати говоря, выбирая между 2х128р и даже 4x64р, я бы сначала очень внимательно посмотрел бы на реализацию обменов, и совершенно не факт, что выбрал бы 4x64р. Я уж не говорю о том, что существует реальная потребность в скалярных 128бит FP операциях.

Автор:	matik [ 20:42 24.05.2004 ]
Заголовок сообщения:
C@t Возможно, я мало думал, но так и не могу понять, чем же плохо иметь 128 бит FPU вместо 2х64? Это, как минимум, возможность запускать на исполнение 2 команды за такт. Разве это плохо?!

Автор:	zurzic [ 11:31 25.05.2004 ]
Заголовок сообщения:
У меня тут интересная мысль возникла. С выпуском двухядерных процессоров процент брака резко уменьшается. Теперь если брак попал на ядро, второе ядро всё равно работает и процессор можно продавать как одноядерный, а если на кэш L2, то как и раньше с уполовиненным кэшем. При этом под браком я понимаю выкинутый процессор, а не урезанный. Урезанных в процентном отношении конечно станет больше, а вот выкинутых однозначно меньше.

Автор:	C@t [ 17:14 26.05.2004 ]
Заголовок сообщения:
matik так и не могу понять, чем же плохо иметь 128 бит FPU вместо 2х64? Это, как минимум, возможность запускать на исполнение 2 команды за такт. Разве это плохо?! Возможно, я нечетко выразился. Суть такая: N штук 128-р. FPU — хорошо, но 2хN штук 64 р. — лучше, т.к. при одинаковом "объёме" "вычислительной" логики второй вариант является намного более гибким. VLev Кстати говоря, выбирая между 2х128р и даже 4x64р, я бы сначала очень внимательно посмотрел бы на реализацию обменов, и совершенно не факт, что выбрал бы 4x64р. непонятно

Автор:	matik [ 18:27 26.05.2004 ]
Заголовок сообщения:
C@t Суть такая: N штук 128-р. FPU — хорошо, но 2хN штук 64 р. — лучше, т.к. при одинаковом "объёме" "вычислительной" логики второй вариант является намного более гибким. Идею понял... Ну, ее в общем случае оспорить трудно. Второй вопрос, что действительно ли организация N штук по 128 бит, и 2xN по 64 бит одинакова? ИМХО, в случае сравнительно небольшой частоты первый вариант проще... Ибо дополнительная гибкость — это отдельные порты запуска, более сложная логика загрузки... Не так ли?

Автор:	C@t [ 18:47 26.05.2004 ]
Заголовок сообщения:
matik Второй вопрос, что действительно ли организация N штук по 128 бит, и 2xN по 64 бит одинакова? Т.к. FP-ФУ сами по себе довольно большие, то львиная доля "новой" площади на кристалле придется как раз на них. Что касается "портов запуска" то для некоторых разумных и современных микроархитектур это не проблема. А вот хорошее обеспечение данными (мощное LSU) — это уже крайне желательно, иначе многие приятности будут незаметны (про что и речь). Здесь возможны разные "гибридные" варианты.

Автор:	matik [ 18:52 26.05.2004 ]
Заголовок сообщения:
C@t Что касается "портов запуска" то для некоторыхразумных и современныхмикроархитектур это не проблема А вот хорошее обеспечение данными (мощное LSU) — это уже крайне желательно, иначе многие приятности будут незаметны (про что и речь). Здесь возможны разные "гибридные" варианты. Гибридные — это какие? Часть FPU 128 битная, часть 64 битная? Собственно, подтаскивать данные придется также поактивнее, это да. Вроде мы выигрываем только в ситуации, когда обрабатываем пары (а не четверки) 64 битных данных, правильно? Но при этом намного сложнее должен быть модуль OoO, поскольку ФУ заметно больше... У каждого своя очередь... ИМХО, ты чуток "упростил" задачу

Автор:	C@t [ 20:07 26.05.2004 ]
Заголовок сообщения:
matik Гибридные — это какие? Часть FPU 128 битная, часть 64 битная? Последовательная передача: одна команда — два примитивных действия. Вообще, этот вопрос очень интересный. Кажется, что _разумный_ переход к внутреннему CISC'у — вещь занимательная Вроде мы выигрываем только в ситуации, когда обрабатываем пары (а не четверки) 64 битных данных, правильно? Но при этом намного сложнее должен быть модуль OoO, поскольку ФУ заметно больше... У каждого своя очередь... ИМХО, ты чуток "упростил" задачу Скажем так: речь идет не столько о выигрыше, сколько о том, чтобы не допускать по возможности проигрышных ситуаций в случае "спаренных" блоков. То есть: У нас имеются данные определенного размера, допустим 64 бит. Имеются блоки, которые эти данные обрабатывают — строго говоря, поштучно. И имеется система, по которой "плывут" команды. Естественно, мы хотим минимизировать внутренний трафик, но таким образом, чтобы не подъедать производительность. В простейшем случае, мы можем _всегда_ объединять в пары как ФУ, так и данные — но в таком случае мы накладываем дополнительные ограничения. Во-первых, на расположение данных в памяти — если обрабатываемые данные не являются соседними, то нам потребуется дополнительное искусственное действие на их объединение. Во-вторых, не всегда нужно обрабатывать именно пары _одной_ операцией — часто приходится производить действие только над одним значением (что не исключает неявный параллелизм). С другой стороны, что даёт объединение — в первую очередь, это — уменьшение внутреннего потока операций и более компактное использование очередей. Что важно. Затея состоит в том, чтобы (u)архитектура позволяла довольно гибко объединять в "пары" как данные, так и значения. В плане операций — одна макрокоманда для "спаренных" действий (возможно, последовательное исполнение на _одном_ ФУ). Для данных — также одна команда LSU (возможно, одно внутреннее действие по поиску, два последовательных — по передаче). Но при этом намного сложнее должен быть модуль OoO, поскольку ФУ заметно больше... У каждого своя очередь... ИМХО, ты чуток "упростил" задачу Сложнее, но не намного. К примеру, три FP очереди на K7 как-бы задействованы очень неравномерно. На самом же деле это не так, поскольку там используется довольно сложная и хитрая система уплотнения и переброски команд. От неё можно будет отказаться. Идеальная схема — компартментализация очереди по типу ALU К7: каждая очередь обслуживает свою связку FMUL/FADD/FMISC.

Автор:	matik [ 20:28 26.05.2004 ]
Заголовок сообщения:
C@t Последовательная передача: одна команда — два примитивных действия. Примерно понял... Кажется, что _разумный_ переход к внутреннему CISC'у — вещь занимательная Ммм Не понял, что ты хочешь сказать <I>К примеру, три FP очереди на K7 как-бы задействованы очень неравномерно. На самом же деле это не так, поскольку там используется довольно сложная и хитрая система уплотнения и переброски команд. От неё можно будет отказаться. Идеальная схема — компартментализация очереди по типу ALU К7: каждая очередь обслуживает свою связку FMUL/FADD/FMISC.</I> Этого абзаца не понял Чуток попроще, если можно... Если я правильно воспринял, у К7 очередь для его "строенного" FPU общая (видимо, есть метки, какая команда кому). Что такое "компартментализация"?

Автор:

VLev [ 20:56 26.05.2004 ]

Заголовок сообщения:

Цитата:
>C@t: при одинаковом "объёме" "вычислительной" логики второй вариант является намного более гибким.\

Во-первых, в данный момент x87 никто пока не отменял, потому выбор фактически между 2x80бит и 128бит. Соответственно, объем логики разный.
Во-вторых, эта самая гибкость [в части комбинаций внешних команд] вряд ли будет востребована (пока только в скалярном SSE2). А в востребованной части [x87 или векторный SSE2] гибкость примерно одинаковая.
В третьих, с точки зрения внутреннего устройства, 128бит FPU более гибок нежели 2x64бит. Например, там можно выполнять операции 128бит точности. Вероятно, и сложные FP операции типа DIV/SQRT можно реализовать быстрее.

Цитата:
>непонятно \

Простая вещь: Высокая производительность связана с хорошей организацией данных. Если данные организованы плохо, высокого ipc все равно не достичь. Последовательные данные --- самый простой пример хорошо организованных данных. Обычно. И именно на это ориентируется организация кэшей, префетча, ну и SIMD тоже.
Не очень простая вещь: В K7/8 (да и везде) существует понятие конфликта банков L1. Так что даже при 2 загрузках за такт не все их комбинации хороши. Правда, последовательные данные обрабатываются без конфликта. Что будет при 4хLoad --- не понятно.

Автор:	C@t [ 20:58 26.05.2004 ]
Заголовок сообщения:
matik <I>>>Кажется, что _разумный_ переход к внутреннему CISC'у — вещь занимательная >Ммм Не понял, что ты хочешь сказать </I> вот это: одна команда — два примитивных действия искусственное объединение двух (нескольких) часто встречающихся команд в одну макрокоманду. Макрокоманда перемещается по конвейеру как одна единица; распадается на составляющие на ФУ. Если я правильно воспринял, у К7 очередь для его "строенного" FPU общая (видимо, есть метки, какая команда кому). Практически это выглядит так: очередей — три штуки, каждая из которых имеет выход на все три "связки" ФУ. Что такое "компартментализация"? разделение пространства в очереди на (две) части, куда попадают составляющие одной макрооперации. Например, каждую из трех очередей IEU K7 можно рассматривать как объединение двух очередей — одной ALU и одной AGU. В плане же светлого будущего я намекаю на "макрооперацию" FMADD (1 умножение + 1 сложение).

Автор:	C@t [ 21:24 26.05.2004 ]
Заголовок сообщения:
Во-первых, в данный момент x87 никто пока не отменял, потому выбор фактически между 2x80бит и 128бит. Соответственно, объем логики разный. Однако сейчас x87 и DP SSE2 исполняется на одних и тех же ФУ. В конечном счете, при "уширении" можно ввести отдельные "широкие" блоки для более экзотических операций. Во-вторых, эта самая гибкость [в части комбинаций внешних команд] вряд ли будет востребована (пока только в скалярном SSE2). А в востребованной части [x87 или векторный SSE2] гибкость примерно одинаковая. нет. Речь идет о том, чтобы иметь возможность занимать ФУ ровно настолько, насколько нужно (напр., не выполнять лишних действий для неиспользуемой части packed SSE и не терять темп на scalar). В третьих, с точки зрения внутреннего устройства, 128бит FPU более гибок нежели 2x64бит. Например, там можно выполнять операции 128бит точности. Вероятно, и сложные FP операции типа DIV/SQRT можно реализовать быстрее. "Чистый" 128 р. блок, выполняющий действия над 128р значениями — вещь особая. Я говорю про обычное простое решение, когда 2 одинаковых 64р блока комбинируется в один -как-бы- 128р (где будет достигаться темп 1 packed SSE2-op в такт). На мой взгляд, лучше 2 блока по 64р. (темп 1 packed SSE2-op в 2 такта) Не очень простая вещь: В K7/8 (да и везде) существует понятие конфликта банков L1. Так что даже при 2 загрузках за такт не все их комбинации хороши. Правда, последовательные данные обрабатываются без конфликта. Что будет при 4хLoad --- не понятно. Да, конечно. Самое забавное, что конфликт банков реально оказывается заметным только в случае очень эффективного цикла, где все расписано по тактам и все ресурсы задействованы. Однако, как ты и сказал, во всех случаях где можно применить 1х128 реализация-"2х64" дает заведомо не худшие результаты.

Автор:	matik [ 23:39 26.05.2004 ]
Заголовок сообщения:
C@t искусственное объединение двух (нескольких) часто встречающихся команд в одну макрокоманду. Макрокоманда перемещается по конвейеру как одна единица; распадается на составляющие на ФУ. Gracie, senior! Практически это выглядит так: очередей — три штуки, каждая из которых имеет выход на все три "связки" ФУ. Понял. разделение пространства в очереди на (две) части, куда попадают составляющие одной макрооперации. Например, каждую из трех очередей IEU K7 можно рассматривать как объединение двух очередей — одной ALU и одной AGU. Теперь понял мыслю... То есть, было бы здорово, если бы было несколько составляющих одной макрооперации... Например, 1 FADD, 1FMULL, 1FSTORE? Или неудачный пример? я намекаю на "макрооперацию" FMADD (1 умножение + 1 сложение). ОК <I>"Чистый" 128 р. блок, выполняющий действия над 128р значениями — вещь особая. Я говорю про обычное простое решение, когда 2 одинаковых 64р блока комбинируется в один -как-бы- 128р (где будет достигаться темп 1 packed SSE2-op в такт). На мой взгляд, лучше 2 блока по 64р. (темп 1 packed SSE2-op в 2 такта)</I> ИМХО, совсем идеальное решение — два 64 битных блока, которые могут И комбинироваться в "128 битное", и работать раздельно.... Или это требует слишком небанальной логики работы?

Автор:	ISA_user [ 08:44 27.05.2004 ]
Заголовок сообщения:
matik совсем идеальное решение — два 64 битных блока, которые могут И комбинироваться в "128 битное", и работать раздельно.... даже так n*(два 64 битных блока, которые могут комбинироваться в "128 битное"), вот только кажется, что при n скажем больше 2, 3 мы разницы в реальных приложениях и не увидим

Автор:	matik [ 11:20 27.05.2004 ]
Заголовок сообщения:
ISA_user Ну, не знаю... Может, и не увидим... А может, и увидим... Думаю, что некая разница все же будет.

Автор:	ISA_user [ 13:05 27.05.2004 ]
Заголовок сообщения:
matik Думаю, что некая разница все же будет. ага, увеличив в 3 раза а получим 5% на выхоже как показала практика, некоторым проще было интегрировать МС в кристалл, чем заморачиваться с новым выч. ядром

Автор:	matik [ 13:31 27.05.2004 ]
Заголовок сообщения:
ISA_user как показала практика, некоторым проще было интегрировать МС в кристалл, чем заморачиваться с новым выч. ядром Почему? Заморочка идет себе вполне... Да и не только МС там из нового, сам же знаешь.. Декодер сильно переработан, шина другая — все вместе вполне тянет на новое поколение... К тому же можно ведь привести и встречные примеры, правда? Например, гигантский шаг вперед при смене П2 на П3

Автор:	ISA_user [ 14:11 27.05.2004 ]
Заголовок сообщения:
matik шина другая вау, так это и было сделано в р3 вс р2 И все-таки основная прибавка в реальном быстродействии — МС. все остальное дало до 5%, сам же знаешь можно ведь привести и встречные примеры, правда? ага, прескотт <font class="off">гигантский шаг вперед при смене П2 на П3 но при этом они оба были Р6, а тут к7, к8, вот приделают еще одну ногу НТ или еще лучше еще одно ядро и к9 можно запустить в серию PS ты опять заикаться начал</font>

Автор:	matik [ 14:25 27.05.2004 ]
Заголовок сообщения:
ISA_user <font class="off">вау, так это и было сделано в р3 вс р2 Ой вэй! Это чем это отличалась шина у PII-450 и PIII-450?! </font> все остальное дало до 5%, сам же знаешь Уверен? В плотных циклах именно МС, не декодер? Посмотри на плотность МОПов из приложения 2 статьи про Хаммер — там местами сильная разница... А кое-где (в Фотошопе, например, или в офисных бенчах) и 1МВ кэша добавляет неплохо... <font class="off">ты опять заикаться начал Старею Теряю нить </font>

Автор:	ISA_user [ 16:24 27.05.2004 ]
Заголовок сообщения:
matik Ой вэй! шириной — я вообще-то про кэш купермайна тк это хоть не косметика А в этом случае — появился НОВЫЙ набор инструкций Уверен? да В плотных циклах именно МС, не декодер? вау и часто ты с ними в жизни встречаешься? если конечно не дуришь меня, что именно в плотных циклах именно новый декодер дает больше 5% прибавки. там местами сильная разница... сикока? А кое-где и 1МВ кэша добавляет неплохо... эх жаль мустанг не вышел

Автор:	matik [ 16:34 27.05.2004 ]
Заголовок сообщения:
ISA_user сикока? Да как-бы у К7 порядка 2.3 МОП/такт, а у К8 — 3.00... И таких инструкций довольно большая группа.... эх жаль мустанг не вышел Думаю, они посчитали стоимость, прослезились, и отменили...

Автор:	C@t [ 18:49 27.05.2004 ]
Заголовок сообщения:
matik ИМХО, совсем идеальное решение — два 64 битных блока, которые могут И комбинироваться в "128 битное", и работать раздельно.... Именно, как раз про это я и говорю Или это требует слишком небанальной логики работы? что-то требует, но не слишком. Фокус в другом — что бы это хозяйство загрузить данными, требуется очень продвинутый L/S блок, а он и так уже довольно большой (не меньше FPU). Т.е. основная имхо загвоздка — не столько сам FPU, сколько LSU. ISA_user даже так n*(два 64 битных блока, которые могут комбинироваться в "128 битное"), вот только кажется, что при n скажем больше 2, 3 мы разницы в реальных приложениях и не увидим неправильно кажется

Автор:	matik [ 18:57 27.05.2004 ]
Заголовок сообщения:
C@t Фокус в другом — что бы это хозяйство загрузить данными, требуется очень продвинутый L/S блок, а он и так уже довольно большой (не меньше FPU). Т.е. основная имхо загвоздка — не столько сам FPU, сколько LSU. Кстати, насколько я понимаю, этот блок содержит буфера довольно значительного размера? И, кстати, что нас ждет в этом месте тогда? В чем главные трудности?

Автор:	C@t [ 19:56 27.05.2004 ]
Заголовок сообщения:
matik этот блок содержит буфера довольно значительного размера? именно, их разруливать надо, причем быстро. За такт (часть такта) — пока идет поиск в L1 — надо просмотреть их содержимое, и, главное, учесть новые изменения, вносимые "соседними" командами. Вот тут как раз при уширении будут некоторые неприятности.

Автор:	matik [ 20:31 27.05.2004 ]
Заголовок сообщения:
C@t Таким образом, можно высказать осторожное предположение, что именно LSU является одним из тормозов наращивания частот? Его работу можно конвейеризовать? За такт (часть такта) — пока идет поиск в L1 — надо просмотреть их содержимое, и, главное, учесть новые изменения, вносимые "соседними" командами. Судя по всему, НУЖНО... Или она уже?

Автор:	C@t [ 20:39 27.05.2004 ]
Заголовок сообщения:
matik Таким образом, можно высказать осторожное предположение, что именно LSU является одним из тормозов наращивания частот? я бы так не сказал, хотя бы потому что имеются разные облегчающие возможности — конечно, за счет некоторых жертв и "отступок" от идеальной производительности. Просто объём логики там очень большой, и технические решения, надо полагать, довольно нестандартные. Судя по всему, НУЖНО... Или она уже ?

Автор:	matik [ 20:41 27.05.2004 ]
Заголовок сообщения:
Ну, я имел ввиду, что НУЖНО конвейеризовать, или же этот модуль уже предельно конвейеризован?

Автор:	matik [ 20:42 27.05.2004 ]
Заголовок сообщения:
C@t я бы так не сказал, хотя бы потому что имеются разные облегчающие возможности ОК. Тогда кто главный "тормоз" на пути наращивания частоты? Имя, сестра! Назови мне его имя! (с)

Автор:	C@t [ 21:17 27.05.2004 ]
Заголовок сообщения:
matik Ну, я имел ввиду, что НУЖНО конвейеризовать, или же этот модуль уже предельно конвейеризован? конечно и уже ОК. Тогда кто главный "тормоз" на пути наращивания частоты? мммэ имхо, "зависит От", но, как правило, тормозит самое нужное и самое-хорошо-работающее

Автор:	matik [ 21:22 27.05.2004 ]
Заголовок сообщения:
C@t как правило, тормозит самое нужное и самое-хорошо-работающее ФУ?

Автор:	C@t [ 21:31 27.05.2004 ]
Заголовок сообщения:
matik наверное, однозначно сказать нельзя — т.к. после принудительного ухудшения тормозить будет уже что-то другое. Раньше были проблемы с декодером, кот. удалось решить малой кровью, реально с улучшением. ФУ тормозят, но их можно неплохо "ухудшать". Всегда есть проблемы с быстрой передачей результата.

Автор:	matik [ 21:44 27.05.2004 ]
Заголовок сообщения:
C@t Всегда есть проблемы с быстрой передачей результата. Нам помогут: 1. X-iniative 2. 3D-architecture

Автор:	ISA_user [ 08:55 28.05.2004 ]
Заголовок сообщения:
matik И таких инструкций довольно большая группа.... сикока? C@t неправильно кажется все может быть, только пока на живых примерах все-таки кажеться, что правильно — матик уже приводил как к7 выглядет в жизни против р6. Вот появиться в кристалле, а не в теориях что-то более конкретное, то изменю свою точку зрения. К тому же сейчас более менее сблансированная архитектура, а если вырастить мускулы, а вслед за ними и мозги придеться наращивать — тут-то овражки и появяться. будут некоторые* неприятности.* как Вы их ласково-то matik <I>Нам помогут: 1. X-iniative 2. 3D-architecture</I> не, не помогут. они из другой оперы это как сравнивать схему быстрого переноса в сумматоре и выделение еще одного слоя под разводку сигнальных линий

Автор:	matik [ 10:36 28.05.2004 ]
Заголовок сообщения:
ISA_user не, не помогут. они из другой оперы Именно что помогут. Ибо: 1. Здесь применение диагональных соединений, что уменьшает длину проводников между блоками, и улучшает топологию. Наверное, не надо объяснять важность топологии для быстрой передачи результатов между блоками? Члены альянса X-initiative говорят о примерно 30% приросте частоты... 2. Трехмерные схемы позволят близко располагать те блоки, которые более других нужнаются в быстром взаимодействии. Естественно, есть лимитирующие факторы, вроде нагрева... Потенциально технология сильная. сикока? 23!

Автор:	ISA_user [ 11:02 28.05.2004 ]
Заголовок сообщения:
matik Наверное, не надо объяснять важность топологии для быстрой передачи результатов между блоками? причем тут между? нам бы внутри бы разобраться Естественно, есть лимитирующие факторы, вроде нагрева... вот вот, причем заметь. ты хочешь друг под другом расположить самые быстродействующие части системы. Члены альянса X-initiative говорят о примерно 30% приросте частоты... Виктор, ты действительно понял о чем я? И ты действительно им веришь про 30%? 23! %? А в общем коде это сколько дало?

Автор:	matik [ 12:33 28.05.2004 ]
Заголовок сообщения:
ISA_user нам бы внутри бы разобраться Насколько я понял Яна, проблема в том, чтобы быстро найти результат, и быстро же его передать. Если уменьшаем длину проводников — уменьшаем время передачи... Да и блок явно можно пооптимальнее развести... вот вот, причем заметь. ты хочешь друг под другом расположить самые быстродействующие части системы Боюсь, что здесь особого выбора нет — либо быстро, либо мало греемся... Виктор, ты действительно понял о чем я? И ты действительно им веришь про 30%? Я вообще никому не верю Но других оценок у меня пока нет, поэтому _пока_ поверю.

Автор:	U2 [ 11:10 04.06.2004 ]
Заголовок сообщения:
Цитата: >Krewell [editor of the Microprocessor Report] estimates that Intel's dual-core chips will offer at least 40 percent greater performance than their single-core cousins, at roughly the same speeds. The company's first dual-core chips are likely to be based on Prescott, the current version of the Pentium 4, and run at 2.5GHz to 3GHz per core. A dual-core chip based on the Pentium M processor will probably follow during 2006. \

Автор:	ISA_user [ 11:32 04.06.2004 ]
Заголовок сообщения:
U2 мне недавно один человек сказал, что в интеле тихо смеялись над новостями, что двухпроцессорный чип от интела будет на основе дотана. The company's first dual-core chips are likely to be based on Prescott, the current version of the Pentium 4, and run at 2.5GHz to 3GHz per core. это уже проверил НР на примере итаника, где два более слабых ядра но с большим общим кэшем дает в сапе и сиквелах также как один топовый, но это же не счетные задачи, а как в них совсем не все однозначно будет.

Автор:	Arie [ 17:11 04.06.2004 ]
Заголовок сообщения:
ISA_user Цитата: >The company's first dual-core chips are likely to be based on Prescott, the current version of the Pentium 4, and run at 2.5GHz to 3GHz per core.\ Я представляю себе размеры кристалла

Автор:	TeoAX [ 17:30 04.06.2004 ]
Заголовок сообщения:
Arie Сравнимо с Willamette-ом. Меня больше волнует тепловыделение (по идее ~150W и более, если частоты действительно в диапазоне 2,5-3ГГц).

Автор:	ISA_user [ 18:10 04.06.2004 ]
Заголовок сообщения:
Arie Я представляю себе размеры кристалла что то мне говорит, что это не 0,09, с соответсвующим уменьшением и размеров и возможно тепловыделения, все-таки даже у прескотта на степинге д уменьшили на 15% тепловыделение.

Автор:	U2 [ 22:55 04.06.2004 ]
Заголовок сообщения:
ISA_user это уже проверил НР на примере итаника Это про mx2? что то мне говорит, что это не 0,09 65nm?

Автор:	ISA_user [ 09:49 05.06.2004 ]
Заголовок сообщения:
U2 да, причем по моему мнению такой проц именно в серверный сегмент сперва поступит, хотя в тех задачах, про которые я говорил, можно просто кэш наращивать. интересно, что по EMEA существенно больше продается как по дензнакам так и по штукам именно 2cpu- 1 032 397, вот может быть взять проц именно для задач на данном сегменте смоделировать, а не скажем на спеке да

Страница 1 из 1	Часовой пояс: UTC + 3 часа
Copyright © 2001 - 2012, Radeon.ru Team Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/