Конференция Radeon.ru
| Страница 14 из 14 [ Сообщений: 547 ] Версия для печати [+] | На страницу Пред. 1 ... 10, 11, 12, 13, 14 |
|
разрядность — 128. циферки измеренные throughput и latency где-то были ...
|
|
Хорошо, в 128 бит уже уверовал. Осталось данные по throughput и latency найти или же самому измерить, если экземпляр в руки попадёт...
|
|
Walter S. Farrell
Осталось данные по throughput и latency найти или же самому измерить А на Интеле мануала нет еще? |
|
Walter S. Farrell
Есть какой-либо достойный доверия источник по этому вопросу? http://www.intel.com/technology/magazin ... &#section8
+ в презентациях интел об этом неоднократно говориться. Осталось данные по throughput и latency найти или же самому измерить, если экземпляр в руки попадёт... С помощью Sciencemark 2.0 замерялось, данные ранее были. |
|
Walter S. Farrell
>Физических последовательностей исполнительных устройств (другими словами — конвейеров исполнительных устройств: ALU, FPU и т.д.) может быть сколько угодно. Их число необязательно должно совпасть с возможностью выдавать какое-то количество операций за такт. Их число самым непосредственным образом коррелирует с IPC, а толковый инженер постарается обеспечить выборку таким образом, чтоб они простаивали как можно меньше времени. Только вот как вы загрузите "сколько угодно" конвейеров командами? Декодеры CISC команд не особо хорошо параллелятся. Сколько угодно не значит чем больше тем лучше. Есть определенный предел, когда избыток исполнительных устройств уже не влияет на производительность. Но их всегда больше, чем количество [макроархитектурных] конвейеров. Для теоретического IPC их достаточно ровно столько, сколько I в этой аббревиатуре (сколько и конвейеров). А вот для практического "гладкого", высокого IPC нужен избыток (который Intel и IBM не без успеха смогли нагрузить вторым потоком). И при здесь декодеры? Мы вроде об испольнительных (вычислительных) стадиях. >Разрядность портов запуска и конвейеров исполнительных устройств (а процессоров Интел это касается особенно), может быть меньше чем разрядность входных/выходных данных. Может, только это непосредственно отразится на instruction throughput. Нет. Это может повлиять на латентность, но не на throughput интрукций, выполняемых в исполнительном конвейере за строго определенное количество тактов. Странная у вас логика. Стадия Write Back любого конвейера не является чем-то из ряда вон выходящим, и уж точно производительность процессора в неё не упирается. А вот в разрядность кокретно взятых расчётных стадий очень даже упирается. И произвести на протяжении одной стадии обработку 64-битных и 128-битных операндов -- это две большие разницы. Вы меня не поняли. Я не возражаю против того, что производительность процессора определяется кучей параметров. И именно под возможности процессора в конечном итоге подгоняются характеристики выходных портов. Но абсолютно неважно что там физически внутри исполнительных конвейеров: их количество, разрядность — 32 бита, 64 бита или на самом деле 128 (в чем лично я ОЧЕНЬ сильно сомневаюсь — есть много "против" такого подхода). Важно, что на выходе мы действительно имеем 3 128-битных команды, хоть и с некоторыми ограничениями по типу. |
|
McZag
>Сколько угодно не значит чем больше тем лучше. Есть определенный предел, когда избыток исполнительных устройств уже не влияет на производительность. Этот предел значительно варьируется между архитектурами. Дело не только в фиксированной длине команд. DSP часто обладают очень малым набором весьма примитивных или специализированных команд, которые легко декодировать и направлять в очереди на функциональные устройства. В обычных процессорах эту проблему пока пытаются решать при помощи внеочередного выполнения, предвыборки и SMT/TMT. Дальше будет видно. >А вот для практического "гладкого", высокого IPC нужен избыток (который Intel и IBM не без успеха смогли нагрузить вторым потоком). Между прочим, тот же SMT/TMT проявляет себя лучше всего в многозадачной серверной среде, а не на персональных компьютерах обычных людей. Ведь SMT/TMT предусматривает и накладные расходы, которые на PC не всегда оправданы. >Нет. Это может повлиять на латентность, но не на throughput интрукций, выполняемых в исполнительном конвейере за строго определенное количество тактов. Latency определяется количеством стадий конвейера, хотя и варьируется для разных типов команд. >Но абсолютно неважно что там физически внутри исполнительных конвейеров: их количество, разрядность — 32 бита, 64 бита или на самом деле 128 (в чем лично я ОЧЕНЬ сильно сомневаюсь — есть много "против" такого подхода). Важно, что на выходе мы действительно имеем 3 128-битных команды, хоть и с некоторыми ограничениями по типу. Всё в той или иной степени важно. Даже если Интел смогла добиться обработки 128-битных SIMD операндов в течение одного такта при помощи организации работы отдельных 64-битных стадий конвейеров на удвоенной частоте, то это уже имеет значение. Пока что я вижу то, что Core работает на тех же тактовых частотах, что и K8, хотя использует более передовой и неплохо отлаженный техпроцесс. Некоторый отрыв по производительности есть, но он не критичен. Мне интересны причины. Потому что когда в феврале следующего года IBM выкатит свой POWER6, он будет работать со тактовой частотой от 5ГГц и выше (прототипы уже есть) при использовании собственного гибридного 65нм / 90нм техпроцесса. Даже NetBurst не смог достичь подобного, хотя в POWER6 гиперконвейеризацию не обещают. |
|
Walter S. Farrell
Потому что когда в феврале следующего года IBM выкатит свой POWER6, он будет работать со тактовой частотой от 5ГГц и выше (прототипы уже есть) при использовании собственного гибридного 65нм / 90нм техпроцесса. Даже NetBurst не смог достичь подобного, хотя в POWER6 гиперконвейеризацию не обещают. Но реально, для рынка, ожидается частоты от 4 до 5 ггц. И это несмотря на то, что у них есть, IIRC, 6 ггц образцы. и глубокой конвейеризации при этом нет. |
|
Walter S. Farrell
Latency определяется количеством стадий конвейера, хотя и варьируется для разных типов команд. Интересная интертрепация. Но это, имхо, не совсем правильное объяснение. Латентность конвейеризованных команд настолько сильно варьируется, что объяснить ее "количеством стадий конвейера", тем более в единственном числе никак не получится  Исполнительных конвейеров несколько, они могут дублироваться или быть принципиально разными. Можно сказать так: максимальная латентность конвейеризованной команды равна длине конвейера, на которой она выполняется. Но и это не всегда так — к сожалению существует зависимость между определенными классами команд, которые блокируют запуск друг друга, влияя на throughput или даже увеличивают латентность, что говорит о том, что "конвейер" не является конвейером в чистом виде 
Даже если Интел смогла добиться обработки 128-битных SIMD операндов в течение одного такта при помощи организации работы отдельных 64-битных стадий конвейеров на удвоенной частоте Либо я вас не понимаю, либо вы продолжаете смешивать понятия латентности и темпа. Core 2 не обрабатывает 128-битный SIMD за такт (хотя и такое возможно для простейших операций — таблицы не видел). Core 2 выдает с каждого порта каждый такт 128-битный SIMD. А вот сколько физически он тратит тактов на обработку одной команды (надо смотреть мануал) и как он это делает (я бы предположил, что большинство операций расслаиваются на блоки по 32 бита, а затем сводятся воедино) — мне пока не известно. Вы обещались найти
Некоторый отрыв по производительности есть, но он не критичен. Мне интересны причины. Причины чего? Отрыва? Если ответ утвердительный, то основные слагаемые успеха насколько это возможно описаны самим производителем. Я бы только заострил внимание на выпадающих из ожидаемых 20-40% прироста приложениях в сравнении с равночастотным К8. Если приложение дает +70% или даже +200%, это не может быть чисто_числодробильный выигрыш. Достичь такого преимущества можно только улучшив работу с памятью. У Интела здесь целая обойма нововведений 1. Большой общий кэш 2. Улучшеный префетч, про который известно только, что он улучшеный 
3. Устранение ложных зависимостей на чтение/запись. Но даже все это вместе с трудом объясняет сумашедший результат в mcf, показанный на 2МВ кэше. Сдается мне, что Интел не договаривает Достичь такого результата, имхо, можно только
4. Интеллектуальным алгоримом вытеснения данных из кэша. Что-то между строк подобное звучит, но в явном виде ничего нет. |
|
U2, на ISSCC в этом году вроде показывали 5,6ГГц прототипы. Естественно, на рынок попадут и более медленные процессоры, не у всех ведь будет так замечательно с тактовым потенциалом, не в брак же их списывать...
McZag, "интертрепация", говорите? Латентность разных по характеру команд явно определяется многими факторами. Тот же IDIV конвейеризации почти не поддаётся, это объективная реальность. Стараются сделать так, чтобы его выполнение хотя бы не блокировало конвейер, хоть частично. Подобно и с "тяжёлыми" вещественными командами. >Либо я вас не понимаю, либо вы продолжаете смешивать понятия латентности и темпа. Core 2 не обрабатывает 128-битный SIMD за такт (хотя и такое возможно для простейших операций — таблицы не видел). Core 2 выдает с каждого порта каждый такт 128-битный SIMD. А вот сколько физически он тратит тактов на обработку одной команды (надо смотреть мануал) и как он это делает (я бы предположил, что большинство операций расслаиваются на блоки по 32 бита, а затем сводятся воедино) — мне пока не известно. Вы обещались найти Нашлось только это. 17 полных тактов на IDIV по сравнению с 40 у A64 -- это очень хорошо. 3 такта на PADD и 5 тактов на PMUL при заявленном throughput в 1 на порт -- тоже смотрятся прилично. По идее, задержки не сильно отличаются от таковых у А64, но вот благодаря throughput в 1 такт против 2 у А64 проявляется перевес Core. Возможно, некоторое внутреннее расслоение, удвоение частоты или что-то вроде этого имеет место, просто не вижу смысла делать throughput в 1 такт для хорошо конвейеризируемых векторных команд, чтобы затем затормозиться на последующих стадиях. >Я бы только заострил внимание на выпадающих из ожидаемых 20-40% прироста приложениях в сравнении с равночастотным К8. Если приложение дает +70% или даже +200%, это не может быть чисто_числодробильный выигрыш. Согласен. Мне кажется, что основная работа была проделана именно в декодерах и планировщиках. Механизм с instruction pool и reservation station микроархитектуры P6 был явно заменён чем-то более эффективным. Возможно, некоторый replay также был добавлен, но в форме без особых извращений. Что касается S-cache, то там не всё ясно и гладко. Но конвейеризированный доступ с 256-битной шиной данных и оптимизация по энергопотреблению (внутренняя сегментация, как это было сделано у Banias/Dothan, Madison и ранее у Cascades) неплохо перекрывают все недостатки. Возможно, у них просто не было времени, чтоб всё осилить. |
|
Walter S. Farrell
на ISSCC в этом году вроде показывали 5,6ГГц прототипы. Естественно, на рынок попадут и более медленные процессоры, не у всех ведь будет так замечательно с тактовым потенциалом, не в брак же их списывать... ИБМ имеет в лабе рабочие сэмплы, работающие на 6ггц, помимо того, что демонстрировалось на ISSCC. А вот собираются продвигать на рынок в 2007г камни в вилке 4-5ггц, несмотря на вышесказанное. P.S. Обновились опт. мануалы от Agner Fog. Там есть инфа по коре2. |
неплохо  |
|
chavv
неплохо Что конкретно? 3 инструкции или затыки в на стадиях выборки и декодирования? |
|
3 инструкции конечно...
predecode обрабатывает 16 байтов — да но вроде потом имеется 64-байт буфер? хотелось бы чтобы у К8/К8Л из-за предекоуд были "затыки" |
|
Список ошибок обновился для коре2, вкл. степпинг В2:
Будут фиксить в сл. степпинге. |
|
U2
AI39. Problem: When request for data from Core 1 results in a L1 cache miss, the request is sent to the L2 cache. If this request hits a modified line in the L1 data cache of Core 2, certain internal conditions may cause incorrect data to be returned to the Core 1. Implication: This erratum may cause unpredictable system behavior. Workaround: It is possible for the BIOS to contain a workaround for this erratum. |
|
lkj
This erratum may cause unpredictable system behavior. М-д-а-а-а..... |
|
Что-то я не понимаю как эти ошибки можно bios-ом исправить...
|
|
VLev
Что-то я не понимаю как эти ошибки можно bios-ом исправить... Я тоже. И баги достаточно жесткие. Странно, что еще новостные сайты не взорвались Или пофиг? Нет процессора, нет проблемы |
|
VLev
Что-то я не понимаю как эти ошибки можно bios-ом исправить... Зато сразу проблема переносится от производителя процессоров к производителям матплат |
|
chavv
хотелось бы или не хотелось бы?  У К8 predecode выполняетя на стадии загрузки в L1I. VLev
Может биосом исключаются "certain internal conditions" ? |
|
McZag
Или проблема не настолько серьезна |
По крайней мере ошибка с prefetch очень конкретно описана. Правда, кое-кто утвержал (и доказывал), что prefetch (причем аппаратный) можно отключить (правда, речь шла про Athlon). Последний раз редактировалось VLev 18:23 19.08.2006, всего редактировалось 1 раз. |
Сразу вспомнилась ошибка деления в Pentium. Вероятность ее появления была очень мала, но, скажем, в моем коде она встречалась, и я некоторое время на мог понять что происходит когда интегралы движения в консервативных схемах начинали "плыть" гораздо быстрее, чем это следовало из ошибок округления. Впрочем, про нее как раз раструбили в СМИ, да и Intel тогда мудро поступила --- заменяла по первому требованию все процессоры (в том числе и мой). |
|
lkj
AI39 Про это было в первой ревизии дока
VLev Что-то я не понимаю как эти ошибки можно bios-ом исправить... Интел явно и не говорит, что это можно 100% исправить через биос. Существует лишь возможность исправления (читай — не гарантируется), т.е. вероятность проявления бага видимо можно будет свести к некоему минимуму, как бы. McZag Я тоже. И баги достаточно жесткие. Странно, что еще новостные сайты не взорвались При определенных условиях, можно "взорвать" и интел  . Раскручивается инфа в сми, даются заключения экспертов от мировых ИТ-компаний. Финансовые аналитики делают заключения/рекомендации на основе всего этого, бросая укор в огород интел, последний вынужден выступить с заявлением, из которого возможно станет ясным насколь серьезна для интел сия проблема. Если речь будет идти о замене и в ожидании нового степпинга, то капитализация интел падает нехило. И на этом кто-то может ну очень много заработать.
BorisU Или проблема не настолько серьезна Ага Обычно в таких случаях пишут что-то типа "в коммерческих приложениях данная ошибка не обнаружена" и т.д. и т.п. Но здесь ничего подобного нет, а даются им "plan fix", а не "no fix".
VLev Впрочем, про нее как раз раструбили в СМИ, да и Intel тогда мудро поступила --- заменяла по первому требованию все процессоры (в том числе и мой). В то время интел был на коне, и мог легко позволить себе подобное. Нынче — ?. |
|
VLev
Что-то я не понимаю как эти ошибки можно bios-ом исправить... А запретить префетч
U2 При определенных условиях, можно "взорвать" и интел . Раскручивается инфа в сми, даются заключения экспертов от мировых ИТ-компаний. Финансовые аналитики делают заключения/рекомендации на основе всего этого, бросая укор в огород интел, последний вынужден выступить с заявлением, из которого возможно станет ясным насколь серьезна для интел сия проблема. Если речь будет идти о замене и в ожидании нового степпинга, то капитализация интел падает нехило. И на этом кто-то может ну очень много заработать. Хм. Готов взять на себя раскрутку Возьметесь за де-капитализацию? |
|
VLev
Взгляните на ошибки под номерами 81, 91, 94 в "Revision Guide for AMD AthlonTM 64 and AMD OpteronTM Processors". Там описаны способы решения через BIOS. Думаю Интел предоставляет похожие механизмы. Возможно так же, что имелось в виду обновление микрокода. Подмена оригинальной инструкции микрокодом может сказаться на производительности, но с другой стороны инструкции софтверного PREFETCH не так что бы часто встречаются.
Не верно. Вероятность появления ошибки деления в пентиуме, в специфических условиях, была равна 100% и эта ошибка легко поддавалась выявлению. Были написаны даже тестовые програмки для выявления ошибки в различных версиях процессоров (как потом оказалось Интел начал выпускать исправленные процессоры ещё до того, как ошибку обнаружили). Вы берётесь воспроизвести ошибку PREFETCH написав соответствующую тест-программу? |
|
|
| Новая тема Ответить | Страница 14 из 14 |
[ Сообщений: 547 ] | На страницу Пред. 1 ... 10, 11, 12, 13, 14 |
Кто сейчас на конференции |
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 20 |
| Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения |
