Здравствуйте, Cyberax, Вы писали:
G>>Посмотрел подробно. 3 канала там всего — два сумматора да один умножитель. Слабее там одно ядро, чем Core 2 — три операции в пике. Пика, впрочем, они должны достигать часто, потому что замешивают в reorder buffer два независимых по регистрам потока. Если, конечно, умножений попадется достаточно. Если, конечно, не будет промахов в кэш . C>Мне всё же кажется, что не замешивают. А на один поток 3 ALU — самое то, как раз.
Узнаем, когда они детальные спеки опубликуют. Сейчас тупо информации не хватает, только гадать остается. Там, я чувствую, что-то нетривиальное у них. Кстати, я бы заключил пари на 1000 руб, что у них там замес двух потоков в общий reorder buffer, а не переключение потоков. Ты готов?
Здравствуйте, Gaperton, Вы писали:
C>>Мне всё же кажется, что не замешивают. А на один поток 3 ALU — самое то, как раз.
G>Узнаем, когда они детальные спеки опубликуют. Сейчас тупо информации не хватает, только гадать остается. Там, я чувствую, что-то нетривиальное у них. Кстати, я бы заключил пари на 1000 руб, что у них там замес двух потоков в общий reorder buffer, а не переключение потоков. Ты готов?
Секундантом предлагаю thesz — он, во-первых, человек строгих моральных правил, и подойдет к вопросу беспристрастно, во-вторых — круто шарит в теме (в архитектурах процов — он писал нашу модель 4-way суперскалярного MIPS, и вообще много как отличился), и установит победителя. В третьих — он просто очень крупный специалист — весит он больше 100 кг и жим штанги у него 120 .
Здравствуйте, Gaperton, Вы писали:
G>Узнаем, когда они детальные спеки опубликуют. Сейчас тупо информации не хватает, только гадать остается. Там, я чувствую, что-то нетривиальное у них. Кстати, я бы заключил пари на 1000 руб, что у них там замес двух потоков в общий reorder buffer, а не переключение потоков. Ты готов?
Да без проблем, давай.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Gaperton, Вы писали:
G>>Чудес не бывает. Nehalem выдает всего три арифметических инструкции за такт в пике
AVK>Я бы не был так уверен. Никакой достоверной информации о том, что реально будет продаваться, пока нет.
Если не изменяет память, то в Pentium4 целочисленное АЛУ для простых операций работало на удвоенной частоте. Соотв. Кол-во целочисленных операций за такт было не равно кол-ву целочисленных АЛУ.
G>Секундантом предлагаю thesz — он, во-первых, человек строгих моральных правил, и подойдет к вопросу беспристрастно, во-вторых — круто шарит в теме (в архитектурах процов — он писал нашу модель 4-way суперскалярного MIPS...
4-way в смысле 4-ёх процессорный SMP?
Это оно: http://mskhug.ru/wiki/MskHUG1_1
?
Было бы интересно посмотреть на моделирование SMP, но там вроде нет упоминаний...
Здравствуйте, remark, Вы писали:
R>Если не изменяет память, то в Pentium4 целочисленное АЛУ для простых операций работало на удвоенной частоте. Соотв. Кол-во целочисленных операций за такт было не равно кол-ву целочисленных АЛУ.
Ну это дичь.
Операция на одном устройстве может занимать разное количество тактов — это запросто. Я конечно не специалист по арифметике, но уверен, целочисленное АЛУ не может работать на удвоенной частоте для простых операций. Современные процессоры имеют т.н. синхронный дизайн — на выходе блока стоят "защелки" из триггеров, которые срабатывают по сигналам clock tree, и времена работы блоков рассчитаны статически. Удваивать частоту в зависимости от операции геморройно и лишено смысла — все равно остальная часть системы не сможет воспользоваться этим результатом раньше, чем начнется ее такт. Впрочем, приведи ссылку, посмотрим.
R>А кстати, на текущих Core сколько АЛУ?
Посмотрел. Арифметики у него столько же и такой же, сколько и у Нехалема. То есть три "полезных" юнита SSE-128 бит. Но выполнять они могут за такт больше — до 5-6 операций x86. Они клеят пары операций вместе — macro-fusion, не пропадать же 128-битным АЛУ без SSE-команд. При этом, конвейр там способен выдавать 4 инструкции за такт. Короче, все ни разу не просто, но главное — на самом деле они с Нехалем во многом одинаковы, по крайней мере в части арифметики. Что подтверждается и тестами. Это не укоцанные ядра. Удивительное рядом, блин.
Здравствуйте, Cyberax, Вы писали:
G>>Узнаем, когда они детальные спеки опубликуют. Сейчас тупо информации не хватает, только гадать остается. Там, я чувствую, что-то нетривиальное у них. Кстати, я бы заключил пари на 1000 руб, что у них там замес двух потоков в общий reorder buffer, а не переключение потоков. Ты готов? C>Да без проблем, давай.
Здравствуйте, AndrewVK, Вы писали:
G>>Чудес не бывает. Nehalem выдает всего три арифметических инструкции за такт в пике
AVK>Я бы не был так уверен. Никакой достоверной информации о том, что реально будет продаваться, пока нет.
Ну да, чудеса бывают . Я посмотрел, как устроен Core. Они в части арифметики оказывается очень похожи с Nehalem, и умеют клеить операции в пары. Что подтверждает твой тест. Так что на самом деле там до 6 обычных инструкций за такт, и до 3-х SSE инструкций.
Здравствуйте, iZEN, Вы писали:
VD>>Ага. Но надо ограничивать себя обсуждаемой темой. Эта тема была про процессор.
ZEN>Согласен.
Ну, и замечательно. Продолжай обсуждать процессор, а не ОС.
ZEN>И как же Windows решает проблемы диспетчерезиции процессов на Nehalem?
Открою тебе один небольшой сикрет. ОС фактически плевать на то сколько процессоров в системе. Две абсолютно независимых задачи будут работать так как будто они живут на двух разны машинах, а 8 как на восьми (если есть 8 ядер). Но все это будет только при одном условии. У этих задач не должно быть точек соприкоснования в которых они обращаются к одним и тем же ресурсам. А вот это как раз очень сложно. В системе общая память, общий винт, общие шины. Вот это и тормозит работу. А Виндовс тут мало чем отличается от любой другой многозадачной ОС.
В большинстве случаев производительность зависит не от ОС, а от программ.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, remark, Вы писали:
R>>Если не изменяет память, то в Pentium4 целочисленное АЛУ для простых операций работало на удвоенной частоте. Соотв. Кол-во целочисленных операций за такт было не равно кол-ву целочисленных АЛУ.
G>Ну это дичь.
G>Операция на одном устройстве может занимать разное количество тактов — это запросто. Я конечно не специалист по арифметике, но уверен, целочисленное АЛУ не может работать на удвоенной частоте для простых операций. Современные процессоры имеют т.н. синхронный дизайн — на выходе блока стоят "защелки" из триггеров, которые срабатывают по сигналам clock tree, и времена работы блоков рассчитаны статически. Удваивать частоту в зависимости от операции геморройно и лишено смысла — все равно остальная часть системы не сможет воспользоваться этим результатом раньше, чем начнется ее такт. Впрочем, приведи ссылку, посмотрим.
Сейчас попробовать погуглить...
Насколько помню там было не удвоение частоты блока, а просто отдельное алу, которое способно выполнять подмножество команд, *всегда* работает на удвоенной частоте.
R>>А кстати, на текущих Core сколько АЛУ?
G>Посмотрел. Арифметики у него столько же и такой же, сколько и у Нехалема. То есть три "полезных" юнита SSE-128 бит. Но выполнять они могут за такт больше — до 5-6 операций x86. Они клеят пары операций вместе — macro-fusion, не пропадать же 128-битным АЛУ без SSE-команд. При этом, конвейр там способен выдавать 4 инструкции за такт. Короче, все ни разу не просто, но главное — на самом деле они с Нехалем во многом одинаковы, по крайней мере в части арифметики. Что подтверждается и тестами. Это не укоцанные ядра. Удивительное рядом, блин.
Насколько помню доки, micro-fusion и macro-fusion работают только для достаточно ограниченных случаев, поэтому считать их в общем случае не очень честно. Да и в Нахелеме они остались.
Здравствуйте, remark, Вы писали:
R>Здравствуйте, Gaperton, Вы писали:
G>>Секундантом предлагаю thesz — он, во-первых, человек строгих моральных правил, и подойдет к вопросу беспристрастно, во-вторых — круто шарит в теме (в архитектурах процов — он писал нашу модель 4-way суперскалярного MIPS...
R>4-way в смысле 4-ёх процессорный SMP?
Нет, речь об однопоточном процес, который умеет выполнять до 4-х инструкций за такт.
R>Это оно: R>http://mskhug.ru/wiki/MskHUG1_1
VD>Открою тебе один небольшой сикрет. ОС фактически плевать на то сколько процессоров в системе. Две абсолютно независимых задачи будут работать так как будто они живут на двух разны машинах...
Я думаю, что две абсолютно независимых будут очень сильно конкурировать внутри ядра ОС, если будут, например, создавать объекты ядра. Объекты исключительно "программные", ну например семафоры.
Здравствуйте, Gaperton, Вы писали:
G>Ну это дичь.
G>Операция на одном устройстве может занимать разное количество тактов — это запросто. Я конечно не специалист по арифметике, но уверен, целочисленное АЛУ не может работать на удвоенной частоте для простых операций. Современные процессоры имеют т.н. синхронный дизайн — на выходе блока стоят "защелки" из триггеров, которые срабатывают по сигналам clock tree, и времена работы блоков рассчитаны статически. Удваивать частоту в зависимости от операции геморройно и лишено смысла — все равно остальная часть системы не сможет воспользоваться этим результатом раньше, чем начнется ее такт. Впрочем, приведи ссылку, посмотрим.
ABSTRACT
To meet the demands of low-latency integer operations,
the Intel Pentium® 4 processor architecture implements
fast integer operations using a 2x frequency core clock.
The frequency advances enabled by Intel’s new 90nm
technology when paired with a 2x frequency multiplier
require novel circuit topologies if latency is to be
optimized. The discussed solution uses unprecedented
levels of small signal random logic to implement a double
frequency X86 integer core. This circuit technology,
termed “Low-Voltage Swing” (LVS) enables the Pentium
4 processor [1] to take full advantage of Intel’s new 90nm
technology [2].
Здравствуйте, VladD2, Вы писали:
VD>Открою тебе один небольшой сикрет. ОС фактически плевать на то сколько процессоров в системе. Две абсолютно независимых задачи будут работать так как будто они живут на двух разны машинах, а 8 как на восьми (если есть 8 ядер). Но все это будет только при одном условии. У этих задач не должно быть точек соприкоснования в которых они обращаются к одним и тем же ресурсам. А вот это как раз очень сложно. В системе общая память, общий винт, общие шины. Вот это и тормозит работу. А Виндовс тут мало чем отличается от любой другой многозадачной ОС.
Вообще говоря, от ОС как раз очень многое зависит при большом количестве процессоров. Так как проявляются очень многие bottleneck'и, незаметные на малом числе CPU.
Например, безобидная блокировка в ядерном менеджере памяти на 64 процессорах вызвать жуткие тормоза. Или глюки в планировщике могут вызывать большую латентность и т.п.
Здравствуйте, remark, Вы писали:
R>Здравствуйте, Gaperton, Вы писали:
G>>Ну это дичь.
G>>Операция на одном устройстве может занимать разное количество тактов — это запросто. Я конечно не специалист по арифметике, но уверен, целочисленное АЛУ не может работать на удвоенной частоте для простых операций. Современные процессоры имеют т.н. синхронный дизайн — на выходе блока стоят "защелки" из триггеров, которые срабатывают по сигналам clock tree, и времена работы блоков рассчитаны статически. Удваивать частоту в зависимости от операции геморройно и лишено смысла — все равно остальная часть системы не сможет воспользоваться этим результатом раньше, чем начнется ее такт. Впрочем, приведи ссылку, посмотрим.
Дык это не дичь. Эта статья о жостких аналоговых оптимизациях LVS, применяемых в Интеле, с целью сократить латентность выполнения целочесленных операций. То, что там _внутри_ блоков частота удваивается — это частность и особенности технологии LVS, темп выдачи информации _наружу_ из АЛУ все равно соответствует общесистемной частоте. Что они эти достигают — они сокращают _латентность_ арифметических операций. Но не _темп_ выдачи результатов. Поэтому на _пиковую_ производительность это никак не влияет. Об этом, кстати, в самом начале и говорится.
Здравствуйте, Gaperton, Вы писали:
G>Дык это не дичь. Эта статья о жостких аналоговых оптимизациях LVS, применяемых в Интеле, с целью сократить латентность выполнения целочесленных операций. То, что там _внутри_ блоков частота удваивается — это частность и особенности технологии LVS, темп выдачи информации _наружу_ из АЛУ все равно соответствует общесистемной частоте. Что они эти достигают — они сокращают _латентность_ арифметических операций. Но не _темп_ выдачи результатов. Поэтому на _пиковую_ производительность это никак не влияет. Об этом, кстати, в самом начале и говорится.
Значит я не так понял...
А какая тогда конечная цель этого удвоения частоты?
Здравствуйте, remark, Вы писали:
R>Значит я не так понял... R>А какая тогда конечная цель этого удвоения частоты?
Конвейер короче становится на арифметике. Работает быстрее — требуется меньше стадий.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Gaperton, Вы писали:
G>>Узнаем, когда они детальные спеки опубликуют. Сейчас тупо информации не хватает, только гадать остается. Там, я чувствую, что-то нетривиальное у них. Кстати, я бы заключил пари на 1000 руб, что у них там замес двух потоков в общий reorder buffer, а не переключение потоков. Ты готов?
C>Да без проблем, давай.
Я спорить не буду, но мне тоже кажется, что будет замес двух потоков в одном конвеере.
Во-первых, если промах мимо L2$ или L3$ не вызывает проблем, то промах мимо L1$ с одной стороны слишком короткий, что бы затевать что-то грандиозное, а с другой всё-таки не хочется терять его время.
Во-вторых, промах мимо любого кэша не вызывает сброс конвеера, что бы можно было делать заполнение конвеера другим потоком. Команды зависимые от загружаемых данных надо просто приостановить.
В-третьих, если конвеер мы всё равно сбрасываем из-за неправильно предсказанного перехода, то в принципе всё равно каким потоком заполнять конвеер по-новой — новым потоком или текущим. Я не вижу тут ничего, откуда может взяться какой-то выигрыш.
В-четвёртых, при замесе двух потоков эффективная длина конвеера получается меньше, т.к. сбрасывать из него надо только часть команд, которые относятся к потоку, который вызвал сброс. Что в общем-то хорошо.
.
