Хабраиндекс
344,54
24 сентября 2013 в 14:30

Почему не растет частота?

Clocking PCМногие, наверное, помнят, какими темпами увеличивалась тактовая частота микропроцессора в 90-х и начале 2000-х годов. Десятки мегагерц стремительно переросли в сотни, сотни мегагерц почти мгновенно сменились цельным гигагерцем, затем гигагерцем с долями, двумя гигагерцами и т.д.
Но последние несколько лет частота уже не растет так быстро. От десятка гигагерц мы сейчас почти так же далеки, как и 5 лет назад. Так куда же исчез прежний темп? Что препятствует, как и раньше, «задирать» частоту вверх?

Текст ниже ориентирован на людей, не знакомых или слабо знакомых с архитектурой микропроцессора. Для подкованных читателей рекомендуются соответствующие посты yurav


«Горячие» гигагерцы


Бытует мнение, что дальнейший рост тактовой частоты непременно связан с увеличением тепловыделения. То есть, вроде как, ничего не мешает просто повернуть в нужную сторону некоторый «рубильник», отвечающий за увеличение частоты, – и частота пойдет вверх. Но процессор при этом нагреется настолько, что расплавится.

Это мнение поддерживается множеством людей, имеющих какое-то отношение к компьютерной технике. К тому же подтверждается успехами оверклокеров, разгоняющих процессоры в два и более раз. Главное – поставить систему охлаждения помощнее.

Хотя упомянутый «рубильник» и связанная с ним проблема тепловыделения действительно существуют, — это только часть битвы за гигагерцы…

Главный тормоз


У различных микропроцессорных архитектур могут быть различные сложности с «разгоном». Для определенности, мы здесь будем говорить о суперскалярных архитектурах. К таковым относится, например, архитектура x86 – самая популярная среди разработок компании Интел.

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

Конвейер


Главный тормоз лежит на уровне конвейера. Конвейер – это сердце суперскалярной архитектуры. Его суть состоит в том, что исполнение каждой инструкции микропроцессора разбивается на стадии (см. рисунок).
Stages
Стадии следуют друг за другом во времени, причем каждая из них исполняется на отдельном вычислительном устройстве.

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

image

На рисунке показано, как в период времени t1 на первом вычислительном устройстве исполняется первая стадия первой инструкции. К началу периода t2 первая стадия уже выполнена, и поэтому можно переходить к исполнению второй стадии на втором устройстве. Первое устройство при этом освобождается, и его можно отдать под первую стадию уже другой инструкции. И так далее. В период времени t4 на конвейере одновременно будут исполняться различные стадии четырех инструкций.

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

image

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

Предположим, что самая длинная стадия требует для исполнения 500пс (пикосекунд) времени. Это длительность такта в машине с частотой 2ГГц. Допустим теперь, что мы хотим сделать такт в два раза короче – 250пс. Просто так… Ничего, кроме частоты, менять не собираемся. Такой ход приведет только к тому, что проблемная стадия будет исполняться два такта, но по времени это будут все те же 500пс. К тому же значительно возрастут сложности проектирования и увеличится тепловыделение процессора.

Можно было бы возразить, что благодаря более короткому такту, быстрее начнут «пролетать» короткие стадии, и значит, возрастет средняя скорость вычислений. Однако это не так (см. рисунок).

image

Поначалу вычисления действительно пойдут быстрее. Но уже с четвертого такта третья стадия и любые следующие за ней (в нашем примере – только четвертая) начнут задерживаться. Это произойдет из-за того, что третье вычислительное устройство будет освобождаться не каждый такт, а каждые два такта. Пока оно занято третьей стадией одной инструкции, аналогичная стадия другой инструкции не может быть исполнена. Таким образом, наш гипотетичский процессор с длиной такта в 250пс эффективно будет работать как процессор с тактом в 500пс, хотя формально его частота будет в два раза выше.

Чем мельче, тем лучше


Итак, с точки зрения конвейера, тактовая частота может быть повышена только одним способом – за счет уменьшения длительности самой долгой стадии. Если удается сократить самую долгую стадию, появляется возможность уменьшить такт до размера той стадии, которая станет самой длинной после проведенного сокращения. А чем короче такт, тем выше частота.

В рамках современных технологий, существует не так много способов, которыми можно воздействовать на размер стадии.

Один из таких способов – переход к более совершенному технологическому процессу. Грубо говоря, очередное уменьшение количества нанометров. Чем мельче составные части процессора, тем быстрее он работает. Происходит это за счет того, что сокращаются расстояния, которые необходимо преодолевать электрическим импульсам, сокращается время переключения транзисторов и пр. Упрощенно можно считать, что всё равномерно ускоряется. Примерно равномерно сокращаются длительности всех стадий, в том числе и самой долгой. Частоту после этого можно поднять.

Звучит довольно просто, однако продвижение вниз по шкале нанометров – процесс очень непростой. Он очень сильно зависит от современного уровня технологий, и дальше, чем позволяет этот уровень, шагнуть нельзя. Тем не менее, производители микропроцессоров постоянно совершенствуют технологический процесс, и частота за счет этого постепенно ползет вверх.

Порезать пациента


Другой способ поднять частоту – это «порезать» самую проблемную стадию на более мелкие. Ведь когда-то инструкции уже удавалось мельчить на стадии. И удавалось многократно. Почему бы не продолжить нарезку? Процессор после этого будет работать только быстрее!

Будет. Однако резать очень сложно.

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

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

А что со строительством? Допустим, мы хотим разбить строительство на возведение стен и укладывание перекрытий. Такое разделение можно сделать, но толку от него не будет. После того, как на одном этаже возведены стены, вы не можете отправить бригаду возводить их на следующем этаже, пока не будет перекрытий. Несмотря на то, что формально нам удалось разбить строительство на две стадии, нам не удалось полностью занять отдельные бригады, специализирующиеся на стенах и потолках. В любой момент времени будет работать только одна из них!

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

Повернуть рубильник


Вот мы и добрались до того, чем занимаются оверклокеры. Они поднимают напряжение, под которым работает процессор. За счет этого быстрее начинают переключаться транзисторы (основные элементы, из которых состоит процессор), и длины всех стадий более-менее равномерно сокращаются. Появляется возможность поднять частоту.

Очень просто! Но есть большие проблемы с тепловыделением. Упрощенно, выделяемая процессором мощность описывается следующим образом:
P ~ Cdyn*V2*f
Здесь Cdyn – динамическая емкость, V – напряжение, f – частота процессора.

Неважно, если вы не знаете, что такое динамическая емкость. Главное здесь – напряжение. Оно в квадрате! Выглядит ужасно…

На самом деле, все еще хуже. Как я уже сказал, напряжение нужно, чтобы заставить быстрее работать транзисторы. Транзистор – это своеобразный переключатель. Для того, чтобы переключиться, ему необходимо накопить достаточный заряд. Время такого накопления пропорционально току: чем он больше, тем быстрее на транзистор приходит заряд. Ток, в свою очередь, пропорционален напряжению. Таким образом, скорость срабатывания транзистора пропорциональна напряжению. Теперь обратим внимание на то, что частоту процессора мы можем увеличить лишь пропорционально увеличению скорости срабатывания транзисторов. Суммируя сказанное, имеем:
f ~ V и P ~ Cdyn*V3
С линейным ростом частоты тепловыделение будет увеличиваться по кубическому закону! При увеличении частоты в 2 раза, необходимо будет отвести от процессора в 8 раз больше тепла. Иначе он расплавится.

Очевидно, такой способ увеличения частоты не очень подходит для производителей процессоров из-за низкой энергоэффективности, хотя и используется разгонщиками-экстремалами.

И это все?


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

Такое тоже возможно, однако в очень ограниченных пределах. Процессоры рассчитаны производителем на то, чтобы эксплуатироваться в широком диапазоне внешних условий (которые влияют на длину стадии), поэтому производятся с некоторым запасом по частоте. Например, самая длинная стадия может занимать не целый такт работы процессора, а скажем, 95% такта. Отсюда и возможность незначительно повысить частоту.

Кстати, я ни в коем случае не призываю никого заниматься самостоятельным разгоном процессоров. Все, кто им занимается, делают это на свой страх и риск. Неправильно проводимый разгон опасен не только для ваших процессоров, но и для вас лично!

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

В общем и целом, получается, что за повышение частоты бороться очень тяжело… Тем не менее, эта битва постепенно ведется, и частота потихонечку ползет вверх. При этом грустить из-за того, что процесс замедлился, не приходится. Ведь появилась такая штука как многоядерность. И какая, в сущности, нам разница, стал наш компьютер работать быстрее из-за того, что поднялась его частота, или потому, что задачи стали исполняться в параллель? Тем более что во втором случае мы получаем дополнительные возможности и бОльшую гибкость…
+146
118297
298
TechThink 47,9

Комментарии (201)

+6
noonesshadow #
Все то же самое применимо к многоядерности. Да и софт в основном не готов использовать множество ядер, поэтому «быстрее» становится, к сожалению, для весьма малого класса задач
+10
dimzon541 #
ага. программистам приходится заниматься «прыжками в ширину»
–6
Evengard #
Современные ОС по определению исполняют все программы в параллели, им разнести софт по разным ядрам не проблема. Каждой программе по ядру! Почему бы и нет… :)
+12
amarao #
Это милое мнение с хабра. «Им разнести софт по разным ядрам не проблема».

А вот в linux'е так не думают, и процесс переноса процесса с ядра на ядро вызывает массу возражений из-за засирания кешей и снижения производительности.

А так да, никаких проблем нет. Welcome multicore.
+5
SlavikMIPT #
да тут вопрос более фундаментальный, чем технические сложности — в том, что не все алгоритмы можно распараллелелить — опять же аналогия со строителями — нельзя построить следующий этаж, не построив предыдущий — чтобы вычислить следующий член последовательности Фибоначчи — надо знать предыдущий, вот матрицы например перемножить в параллель — это запросто — поэтому видеокарты имеют дофигища ядер — перемножение матриц — одна из основных операций в видеообработке
–10
Zoberg #
Немного позанудствую, но для вычисления чисел Фибоначчи существует рекурсивный алгоритм, а он в принципе распараллеливается: даже для малого значения n рекурсивными вызовами порождается очень большое число параллельных процессов.
+5
SlavikMIPT #
чего — рекурсивный алгоритм распараллеливается? то есть я правильно понимаю, что
int fib(int n)
{
if (n <= 2) return 1;
else
{
return fib(n — 1) + fib(n — 2);
}
}
по вашему быстро отработает? это по сути дерево — то есть каждая функция должна ждать пока вычислятся вызванные ей функции — где тут параллельность? — сложность алгоритма ЭКСПОНЕНЦИАЛЬНАЯ. вот матрицы перемножить — взяли строку, умножили на столбец и сложили — никто никого ждать не должен
–8
Zoberg #
Про скорость никто не говорил, я говорил, что существует возможность распараллелить. Ведь этот алгоритм так и называется: параллельная рекурсия. Отправляете fib(n — 1) на одно ядро, fib(n — 2) на другое — вот и все. И на каждом шаге так. Да, ядра заканчиваются, но на теоретическую возможность распараллеливания это никак не влияет (use-case — тестирование возможностей систем параллельных вычислений). А если вы хотите скорости, то если использовать формулу Бине, то вообще не нужно знать ничего, кроме номера числа в последовательности.
+3
SlavikMIPT #
так все равно — ядра то простаивают, пока ждут числа от других ядер
–3
Zoberg #
Если не нравится рекурсивный пример, а нравятся матрицы, то тогда вычисление чисел Фибоначчи можно распараллелить, воспользовавшись следующим тождеством:

image
+3
SlavikMIPT #
хорошо конечно, что посмотрели таки википедию, но также посмотрите, что на основе этого свойства — операция сводится все равно к последовательному вычислению то есть каждое новое число получается на основе числа, вычисленного в предыдущем шаге:
//возвращает n-е число Фибоначчи
int fib(int n)
{
int a = 1, ta,
b = 1, tb,
c = 1, rc = 0, tc,
d = 0, rd = 1;

while (n)
{
if (n & 1) // Если степень нечетная
{
// Умножаем вектор R на матрицу A
tc = rc;
rc = rc*a + rd*c;
rd = tc*b + rd*d;
}

// Умножаем матрицу A на саму себя
ta = a; tb = b; tc = c;
a = a*a + b*c;
b = ta*b + b*d;
c = c*ta + d*c;
d = tc*tb+ d*d;

n >>= 1; // Уменьшаем степень вдвое

}
return rc;
}
0
nsinreal #
Хочу заметить, что мы можем сложить другую матрицу, с количеством строк и ячеек порядка N, которая за одно умножение себя будет давать переход из fib(a) -> fib(a+N). А после юзать какое-нибудь распараллеленное умножение матрицы на матрицу. Т.е. по сути нам нужно будет умножить не logN матриц, а log(N/c), но при этом потеряем на умножении матриц, что чисто теоретически мы можем покрыть большим количеством воркеров. Это вообще даже не примерные прикидки, там нужно считать, выгороит ли это или нет. Но это и вправду чисто гипотетические прикидки. Закон Амдала он суров, да.
0
mayorovp #
Если мы будем использовать матрицу размера K, то вычисление N-го числа Фибоначчи будет требовать O(logN/logK * K^3) операций. При этом максимальная степень параллелизма составит K^2, что даст время O(log N / log K * K). Как видно, асимптотика не улучшилась, а ровным счетом наоборот.

Но попытка интересная.
0
hombre #
не нашел) удалил комментарий)
+4
SlavikMIPT #
да вы нарисуйте картинку то — это не параллельность, это дерево
+4
noonesshadow #
На эту тему весьма обстоятельно:
trigonakis.com/blog/2011/02/27/parallelizing-simple-algorithms-fibonacci/
0
KvanTTT #
Рекурсивные алгоритмы тоже параллелятся, другое дело что менее эффективно и более сложно, чем итеративные. В шахматных движках например при поиске в глубину (а это даже сложнее, чем числа Фибоначчи, поскольку там дерево вызовов может быть сильно не симметричным) существуют алгоритмы для работы в несколько потоков.
+1
mayorovp #
В том-то и фокус, что шахматные движки параллелятся, а числа Фибоначчи — нет.
–2
Zoberg #
Сложность приведенного вами алгоритма экспоненциальная на одном ядре, а если бы у вас было бесконечное число ядер, то отправляя каждый вызов в новое ядро, вы бы получили выполнение задачи за линейное время. Про это я и говорил. Распараллелить можно, но смысла в этом мало, потому что именно для этой задачи существуют обходные пути. Но вот тот же самый quicksort имеет похожий вид и для него такое распараллеливание работает хорошо и быстро, хотя тоже ведь рекурсия.
–2
Zoberg #
Еще раз: я написал, что позанудствую и подчеркнул разницу между «нельзя распараллелить» и «можно, но выигрыша не принесет по сравнению с другими реализациями». Вот 1+1 нельзя распараллелить, а некоторые реализации вычисления чисел фибоначчи можно, но ускорения это не приносит.
+1
mayorovp #
Если занудствовать, то и i+1 можно распараллелить.
0
Manowar #
quicksort паралелится, т.к. там дерево и обработка обеих веток друг от друга не зависит. При вычислении чисел Фибоначи как F(n) = F(n-1)+F(n-2) обе ветки явно зависят друг от друга.

Кстати, справедливости ради стоит упомянуть что n-ное число Фибоначи можно итеративно вычислить за время O(log n). Описание мне попадалось в mitpress.mit.edu/sicp/full-text/book/book-Z-H-11.html, Exercise 1.19
–1
mtivkov #
Справедливости ради, для чисел Фиббоначи есть формула Бине (в Википедии есть) — никаких рекурсий, никаких матриц, никаких O(log n), все делается за O(1).
+2
iavael #
Делается-то за O(1), но 16-элемент ряда, например, получается равным 986.99999999999999995928

А сложность вычисление показательного выражения символьными методами, как мне кажется, совсем не O(1).
+1
nsinreal #
Справедливости ради, числа фибоначчи нельзя даже вывести ни за O(1), ни за O(logn). N-е число фибоначчи — это экспонента от N. Количество в цифре любого числа — это примерно логарифм этого числа. Т.е. N-е число фибоначчи имеет примерно N цифр домноженное на какую-то константу.
+3
mayorovp #
Я тоже немного позанудствую, но рекурсивное вычисление чисел Фибоначчи медленнее циклического при любом числе потоков.
–7
Zoberg #
Медленнее, да, но из-за того, что для параллельной рекурсии не хватает физических ядер, а потоки медленные сами по себе.
–2
stoune #
В языках поддерживающих хвостовую рекурсию, сложность цикла и рекурсивного вызова примерно одинаковы, более того чаще всего циклы реализируются через рекурсивный вызов функции.
0
mayorovp #
Что?

Во-первых, хвостовую рекурсию может поддерживать компилятор, но не язык.
Во-вторых, формула f(x+2) = f(x+1) + f(x) не дает хвостовой рекурсии ни при каких условиях.
0
stoune #
Но ведь можно вот так сделать?
tratt.net/laurie/blog/entries/tail_call_optimization
def fib(i, current = 0, next = 1): if i == 0: return current else: return fib(i - 1, next, current + next)

0
mayorovp #
Ваша правда, мне почему-то в голову приходили лишь более сложные решения.

Придется переформулировать фразу: «Я тоже немного позанудствую, но рекурсивное вычисление чисел Фибоначчи по приведенной формуле медленнее циклического при любом числе потоков.»
0
stoune #
Насчёт этого спорить не буду.
–1
amarao #
В контексте процессора всё просто — делать симметричную многопроцессорность не дорого, а очень дорого. Каждый write lock стопит все все ядра на всех операциях с памятью. Чем больше процессоров, тем больше ожидания синхронизации.

multicore до сих пор не выкатили не только по причине жадности интела, но и по объективным причинам.
0
mayorovp #
Простите, но что вы понимаете под терминами «multicore» и «не выкатили»? Такое ощущение, что мы обсуждаем разные проблемы на разных языках…
0
amarao #
Ага, я их опять попутал. Разумеется, речь про many-cores. Сейчас по мнению интела эпоха multicores, а потом будет many-cores, и там текущие подходы к ПО и процессорам перестанут работать из-за того, что ядер будет так много, что оверхед на SMP будет недопустимо высокий.

www.altera.com/technology/system-design/articles/2012/multicore-many-core.html
+6
mayorovp #
и процесс переноса процесса с ядра на ядро

Кто говорит о переносе процесса с ядра на ядро? Речь идет о том, что одна программа выполняется на первом ядре, другая — на втором и т. д. Результат получается в любом случае быстрее (ну, не медленнее) и отзывчивее, нежели одноядерный вариант.
–2
SlavikMIPT #
от этого игрушка меньше лагать не станет — прирост от того, что ресурсы ядра теперь только одной программой заняты — минимален — программа все равно выполняется на одном ядре, если хочется, чтоб реально работала в параллель — нужно специальным образом реализовывать алгоритмы, при том — не все пока поддаются распараллеливанию
+2
Renius #
Игрушка будет лагать меньше хотя бы от того, что есть возможность выделить ей гарантировано целое ядро в индивидуальное пользование. Видео для вашей игрушки спокойно обрабатывается тысячами ядер вашей видеокарты. Звук и сеть обрабатываются через DirectX и тоже выносятся на свободные ядра, без участия разработчика.
0
amarao #
В контексте «одноядерный» — да. Но вот что быстрее — 60 процессов по штуке на 60 ядер или 60 процессов на 30 ядрах, выполняющиеся по очереди — это вопрос открытый. На соответствующих кривых производительность начинает падать из-за оверхеда процессорной шины, общей памяти и т.д.
–1
iavael #
И в какой доле современных серверных систем runnable-процессов больше, чем количество ядер/потоков? Про домашние и так понятно, что 0.
+1
mayorovp #
Ну, я бы про 0 не говорил — на домашних компьютерах порой второе ядро бывает очень даже к месту.
0
Vest #
Жаль, что только в пределах ядра программа тоже бы хотела исполняться параллельно на таких вот процессорах (не беру в расчёт GPU), но к сожалению не все задачи можно распараллелить :(
+12
noonesshadow #
На одном ядре у меня любимая игрушечка (95% нагрузки), на втором фоновые процессы (20% нагрузки), третьим и четвертым ядром мы с пацанами меряемся по пятницам :)
0
mayorovp #
На третьем и четвертом ядре — виртуальные машины с еще двумя копиями этой игрушечки. Хожу втроем в группе сам с собою… То есть ходил, пока игрушку не прикрыли.
НЛО прилетело и опубликовало эту надпись здесь
+1
Badevlad #
вопрос: ускорит ли работу бухгалтера 3 или 4 или 6 ядерный процессор.

Ответ: нет, но руль и педали могли бы.
+4
TechThink #
Софт со временем созреет. Сейчас многое для этого делается: синтаксические расширения языков программирования, библиотеки хорошие, обучение студентов в ключе «параллельного мышления».

Основная проблема как раз в этом и есть: нынешние поколения программистов не привыкли мыслить параллельно. Как говорит один мой знакомый, параллельно умеют мыслить только домохозяйки. У них в одном углу ребенок растет, в другом кастрюля кипит, а в третьем белье гладится. И ведь все синхронизовано! :)

Кстати, над автоматическим распараллеливанием программ работы тоже ведутся. Но здесь все как-то запредельно сложно получается пока что…
+2
iavael #
Это уже десятки лет говорят. А параллелят код до сих пор в подавляющем большинстве случаев руками. И значительных подвижек на горизонте до сих пор как-то не видно.
0
SlavikMIPT #
еще бы стоило отметить, что львиную долю энергозатрат занимает поддержка устаревших архитектур, в архитектуру вносятся дополнительные элементы, что так же ограничивает максимальную скорость работы системы
+2
Juster #
какие дополнительные тормозящие элементы вы имеете в виду?
+1
SlavikMIPT #
которые отвечают за совместимость с более старой архитектурой — абстрактный пример — допустим (ДОПУСТИМ) сперва сделали 8 битные регистры и на этом построили архитектуру, то есть передача данных по 8 разрядным шинам идет, потом сделали 32 битную архитектуру и данные передаются по 32 разрядным шинам — соответственно для каждой архитектуры свой набор инструкций — одни инструкции могут работать с 32 битной шиной, другие-более старые — нет, соответственно — поскольку процессор должен поддерживать ВСЕ инструкции, которые были когда либо заложены в архитектуру — нужен какой то дешифратор, который определяет — с какой шиной и регистрами будет работать процессор — если надо — переключает — на это все доп время и энергия тратится
+1
KvanTTT #
Intel когда-нибудь собирается отказаться от поддержки старых архитектур для увеличения производительности?
0
SlavikMIPT #
спросить у интела надо), но вряд ли — вы представляете — сколько софта написано за годы существования процессоров? как от этого всего отказаться
+2
denonlink #
Была такая попытка чуть более 10-ти лет назад, и звали ее Itanium. Но боссы в AMD поняли, что если Itanium взлетит, то они обанкротятся, потому выпустили костыль под названием AMD64. А дальше как всегда.
0
gnomeby #
Itanium — принципиально другая архитектура. Тут речь скорее про отказ от 8-ми битных и 16-ти битных регистров и пары команд, нужных только в DOS.
+2
denonlink #
В том и дело, что она принципиаолно другая, а не порсто выкинуты пару старых команд.
+2
anarx #
Intel менее всего выгодно банкротство AMD. Их же антимонопольщики съедят. Посмотрите структуру владельцев, сильно удивитесь. Как только AMD испытывает серьёзные трудности – сразу же получает заметные инвестиции.
+1
denonlink #
Дело не в том, что Интелу выгодно делать с AMD, а то, что AMD пошла по легкому пути и нагородила костылей, зарубив на носу идею Интела выкинуть всю костыляндию и сделать современную архитектуру с нуля. Но это дороже — софт переписывать, совместимость там всякая… Или у AMD оказалась кишка тонка, или они специально каку сделали чтобы по быстрому бабла срубить и обломать главного конкурента.
+4
khim #
Если бы эта «современная архитектура» действительно работала-бы быстрее, но ничего с этим сделать бы AMD не смогла. Но она не работала быстрее: в большинстве задач она просто-напросто работала медленнее, а там, где она могла разогнаться (всякого рода математика) она оказалась гораздо медленнее видеокарт. И тогда зачем весь этот огород?
+1
Zelgadis #
Это вы про итаниум которые потреблял так, что AMD устали снимать смешную рекламу про них? У итаниума не было будущего за пределами серверов.
0
cawaleb #
Извините, вы работали с Itanium.
я пробывал сравнить сервер с 8 itanium на hpux 11.24, сервер на parisc тоже hpux на тот момент ему было около 10 лет, sun fire 240 sunos 5.8, и помоему 585 пролиант на 4 оптеронах RHEL.
Простым gzip видео > /dev/null
gzip не распаралеливается, то есть сравнивал производительность 1 ядра.
Отстающими оказались parisc и itanium.
+3
crea7or #
arm же шагает по планете и ничего, достаточно уверенно набирает обороты. большую часть этого старого софта можно было и 10 лет назад выкинуть.
0
Alexeyslav #
ARM-ы только немного выигрывают по энергопотреблению по сравнению с x86 процессорами но по производительности пока еще не конкуренты совершенно, да и в будущем тоже врядли ситуация изменится. Архитектура другая, заточенная под более узкие задачи — низкое потребление, воспроизведение HD-видео и т.д. а как процессоры общего назначения они не привлекательны в основном из-за низкой производительности.
0
crea7or #
А я совсем не про это, к арм хейтерам не отношусь. просто архитектура достаточно недавно и сильно шагнула вперёд по части софта. так что проблема не в нём. переписывание софта даже привнесёт некоторое оздоровление на рынок.
–1
Alexeyslav #
Нет, проблема именно в нем. На АРМ-ах удобно делать узкоспециализированные устройства, десктоп они заменить смогут разве что в тонких клиентах. Если сделать АРМ по вычислительной мощности равный x86 процессору то возникнет закономерный вопрос — а нафига нам еще одна сущность?
+2
leventov #
Какая еще львиная доля? Если вы видите какие-то существенные изъяны в x86, то это как бы не «поддержка», а и есть сама архитектура. От всяких старых команд вред разве что в том. что они занимают короткие коды. Но это мелочь.
+7
Fil #
Замечу, что за один такт 3ГГц процессора электромагнитная волна преодолевает 10 см, что сопоставимо с размером процессора.
+1
KvanTTT #
Ну это все-таки еще довольно много, так как в процессоре существует кэш.
В будущем наверное вся ОЗУ будет размещаться прямо в процессоре.

Интересно, какая максимальная теоретическая частота возможна (или хотя бы ее предел), если предположить, что вся память находится на процессоре, если исходить из ограничений по скорости света?
+7
SlavikMIPT #
это далеко не единственный фактор — есть еще емкости, индуктивности, согласование нагрузок, отражения, перекрестные помехи, туннельный эффект…
+3
FloppyFormator #
Это сопоставимо (хотя и в несколько раз больше) с размером корпуса процессора, который в свою очередь в несколько раз больше кремниевого ядра, а все процессы, происходящие с трёхгигагерцевой частотой, происходят именно в нём.
+2
m08pvv #
Только там далеко не прямолинейное распространение — надо же включать/выключать элементы.
+2
Alexeyslav #
Волна преодолевает, но основной ограничитель — время заряда паразитных емкостей.
0
zaitsevyan #
Что-то я не совсем понял аналогию со строительством стен и перекрытий, а что мешает рабочим, которые строят стены перейти в другой дом и начать строить стены там(после завершения постройки стен в первом доме)?
+6
SlavikMIPT #
ничто не мешает, но этаж в итоге быстрее не построится, то есть время исполнения одной инструкции от этого не уменьшится — следующий этап невозможно начать, пока не получен результат предыдущего
+9
mayorovp #
Ничего не мешает. Вы изобрели/описали hyper threading
+2
MasMaX #
Пока будешь идти от дома к дому у тебя как раз этаж построят.
+2
hedin_hiervard #
Неправильно проводимый разгон опасен не только для ваших процессоров, но и для вас лично!

Общество жаждет историй :D
0
amarao #
Недавно была история про хаккера, который нашёл метод разогнать свой кардиостимулятор.
+10
wegorich #
Даже фильм сняли, бегает мужик в себя током бьет и только здоровее становится.

+2
Deeman #
Ещё один вопрос, который напрашивался после прочтения статьи: получается, из-за почти полной обратной совместимости в x86-процессорах, невозможно сильно укоротить самые длинные стадии в инструкциях? И именно в это всё и упирается?
И именно из-за этого любители ARM так хотят «похоронить» x86?
Но похоронить его не получится, т.к. слишком много хорошего софта уже написано и переписывать его никто не будет?
–4
DeltaKilo #
Много проприетарного хорошего софта уже написано. С появлением ARM на серверах, а там везде Open Source, когда можно будет скомпилировать софт под любую архитектуру, а приложения уйдут в Web, Intel придется что-то делать со всем тем багажом костылей ее архитектуры. Кроме того, там все здорово параллелится и количество ядер добавляет производительность практически пропорционально.
+2
Maratyszcza #
А компилятор с хорошей оптимизацией под ARM64 сам материализуется? gcc и clang до сих не поддерживают интринзики под ARMv6, хотя архитектуре уже больше пяти лет. Пока их допилят генерировать качественный код под ARM64, может и мода на облака уйти.
0
DeltaKilo #
ARM64 появился две недели назад в конечных устройствах все-лишь. Кроме того, несмотря на отсутствие интринзиков, как-то ведь появляются игры на iPhone/Android. Что же касается серверного софта, там на FPU/SIMD нагрузки вообще очень мало.
+1
Maratyszcza #
Разработчики серверного софта (тем более опен сорсного) не готовы на такие жертвы ради производительности, на которые идут разработчики игр. Дело не в FPU/SIMD (ARMv6 интринзики это вообще про целочисленную арифметику), а про то, что компиляторы под ARM64 генерируют говнокод, и их ещё предстоит много лет вылизывать, прежде чем они сравняются по качеству кодогенерации с x86.
–4
DeltaKilo #
Вы хотите сказать Apple выпустила iPhone5S с совсем сырым компилятором? И кто такие эти разработчики серверного софта? Разработчики серверного софта это разработчики Java, Ruby, Python, PHP, а там все уже давно заточено и отшлифовано весьма. Вот в новом JBoss AS 8, который будет называться Wildfly и выйдет в этом году специально было проведено много работы с учетом особенностей других архитектур.
Представьте себе серверную стойку, и ещё представьте себе юнит. Обчный такой юнит, но размером с iPhone 4 и как в рекламе Эльрадо, 4 ядра 4 гига. $200-$300; цена(и это поначалу, потом подтянутся китайцы и спустят до сотки). Производительность на Ватт/Цену/Объем такая, что Интел впору бы было посыпать голову пеплом и скупать какой-нибудь Broadcom или TI уже сейчас. Кроме того там нечего администрировать, потому что устройства поставляются с чем-то типа готоваой прошивки => больше производительность труда админов => ещё меньше совокупная стоимость владения.
Такие дела. Будущее здесь.
+2
mayorovp #
Кроме того там нечего администрировать,
На сервере-то? рофл
–3
DeltaKilo #
Будет совсем другой workflow, написал же. Кто-то и Android любит поадминистрировать.
+3
DjOnline #
Любители разбрасываться производительностью на Ватт, покажите мне хоть один пруф в пользу любого Arm. Пока я вижу только маркетинговый обман, и все бенчмарки говорят обратное.
По бенчмаркам даже Intel Atom (Z2760) энергоэффективнее Tegra 3 либо на уровне Cortex A15 — www.anandtech.com/show/6536/arm-vs-x86-the-real-showdown/8. И при этом Intel в этом сравнении быстрее.
Ну чтобы по скорости догнать Haswell i7, ARM должен быть раз в 5-10 быстрее.

Ну и хотелось бы посмотреть на сервер с хотя бы минимально необходимым SSD 256Gb за $300, и главное зачем он нужен на ARM, если есть тот же hetzner на Haswell с SSD за 48 евро (без VAT), которые быстрее любого арма раз в 10.
+2
DeltaKilo #
Ок, хватит этого буллшита, где сравнивают Chrome на Android на ретине и WinRT на Эксплорере. Сейчас готовлю серию бенчей на серверных задачах. Внезапно. Cortex-A9 против Sandy Bridge. По первым данным по Ruby and Rails, там даже при таком раскладе у Intel есть серьезные затруднения в плане производительности/ватт и производительности на доллар. Но подождите, будет классная статья, обещаю. Если народу понравится, то потом будет Java, по которой я данные примерно представляю, может Python, обязательно NoSQL.
+2
Nubus #
Мечты, но такого не будет. Хотя бы потому что вы замучаетесь делать из под Web что то похожее на тяжелые редакторы (Photoshop, CorelDraw) или игрушки онлайн. Плюс не у каждого жителя планеты есть доступ хотя-бы к 512\64 КБит интернету. Поэтому в вебе будет очень ограниченное число приложений ближайшие лет 5.
–6
DeltaKilo #
Apple и Google с вами не согласны. iCloud и Google Docs тому пример. Я уже кстати полностью отказался от десктопных офисов. А интернет он быстрый, поверьте, у многих.
+2
mayorovp #
«у многих» != «у всех»
У нас в стране даже ADSL не во все деревни провели.
–5
DeltaKilo #
Это вопросы к премьеру и президенту, что там по программе преодоления цифрового неравенства, возможно она там же где и доступное и комфортное жилье. А интернет, он быстрый period
+1
TechThink #
Не стоит напрямую связывать обратную совместимость и возможность работать над длиной стадии. Однако действительно: отказ от совместимости позволяет работать над проблемой более эффективно.

Идеальная машина — это та, в которой единственные связи между инструкциями — это связи по данным (т.е. одни инструкции используют результаты работы других). Задача разработчиков архитектуры — постоянно приближаться к этому идеалу, устраняя все другие (кажущиеся искусственными) зависимости. Не думаю, что ARM сейчас ближе к этому идеалу, чем x86.

Зачем любители ARM хотят «похоронить» x86 (а они действительно хотят?), я не знаю. Я за разнообразие архитектур. Без конкуренции ничего хорошего не получается :)

И еще я бы не сказал, что единственная причина, по которой x86 жива, — это большое количество написанных программ. Все-таки, на сегодняшний день, это самая эффективная архитектура, которая все еще продолжает развиваться.
+2
khim #
Все эти ложные связи и прочее — это бантики. Разница между тем, что можно выжать из x86 когда и какого-нибудь «идельного кода» — где-то в 1.5-2 раза, не больше, дальше уже начинаются реальные зависимости между данными, которые никуда не спрятать.
+9
khim #
Какое имеет отношение x86 инструкции к «самым длинным стадиям»? Современные x86 процессоры (за редким исключением типа Quark) не исполняют x86 код, они исполняют μopsы. Вся совместимость влияет только на декодер, который не является узким местом ни разу.
+4
Deeman #
Большое спасибо за комментарий. Примерно ради такого ответа и писал вопрос.
+1
Alexeyslav #
нет не поэтому. старые инструкции не причем, в основном ограничителем является АЛУ — а именно время прохождения сигнала от его входа к выходу. Элементарная операция сложения двух чисел — сигнал логических состояний операндов на входе проходит несколько уровней логических вентилей прежде чем попадет на выход, из этого складывается минимальное время стадии. Впрочем, есть наверняка команды и потяжелее. Сами вентили из которых стоят логические блоки вполне способны работать на частотах до 20-30ГГц, но сложность самих логических блоков сильно увеличивает время прохождения сигнала от входа к выходу.
Единственный способ сократить это время — упрощение структуры логических блоков в ущерб универсальности — что-то подобное и делают в ARM-ах.
Проблема ARM-ов в том что они более узкоспециализированные вычислители чем процессоры широкого применения x86 за счет чего ARM-ы в планшетах и телефонах потребляют меньше энергии, но соотношение количества работы к затраченной энергии по сравнению с x86 или даже x64 на общих задачах отличается ненамного.
+2
denonlink #
Жаль Itanuim угробили…
–1
amarao #
Итаник не может утонуть. Итаник не может утонуть. Итаник не тонет. Итаник не тонет. Итаник не утонул. Итаник не утонул.

Представитель intel может это подтвердить.
+4
TechThink #
Тоже немного по нему ностальгирую. Технически он еще жив, т.к. все еще есть клиенты, которые его покупают. Но уже не развивается.

Itanium отлично показал себя на некоторых классах задач, но на некоторых оказался средненьким. В общем, не потянул на general purpose архитектуру.

Однако на нем были обкатаны некоторые интересные фишки (двоичная трансляция, например). Многие из этих фишек, подозреваю, получат новые воплощения, но уже с учетом полученных уроков.
+3
ximaera #
Не жаль. На HP-UX-ia64 11i-v3 образца 2009 года (уже вполне развитый и матёрый релиз) самая популярная машинная инструкция в /bin:/usr/bin всё ещё была nop. Itanium не угробили, он сам не взлетел.
–3
s0rr0w #
Странно слышать про микроархитектурные проблемы роста частоты. Особенно с учетом оверклокерских достижений.

Самая большая проблема — TDP и токи утечек. Чем меньше транзистор, тем тоньше прослойка диэлектрика, соответственно повышается шанс паразитных утечек, которые и повышают нагрев кристалла.

Длина конвейера у последних P4 была равна 31 стадиям, и максимальные частоты были в районе 3.8 GHz. Новая архитектура Haswell имеет 14-19 стадий конвейера, а тактовые частоты находятся все в том же районе, и легко подымаются выше. Длина конвейера архитектуры Piledriver составляет те же 14-17 стадий и тот же уровень частот, может чуть выше.
+1
forgotten #
–1
s0rr0w #
Вы о чем?
+2
mayorovp #
Он хотел сказать, что вы даже не прочитали статью, или прочитали ее невнимательно, но уже написали критический комментарий, полагая, что знаете эту проблему лучше, чем специалисты Intel.

В статье довольно понятно написано, почему оверклокерские достижения не могут стать массовыми. На всякий случай повторю: среднестатистический пользователь не может использовать те системы охлаждения, которые используются оверклокерами.
+6
s0rr0w #
Как человек, который наблюдает за развитием микропроцессоров и их архитектур на протяжении последних 15 лет, я повидал достаточно маркетинговых заманух (Pentium ускоряет интернет) и различных решений как на уровне архитектур, так и на уровне физических реализаций.

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

Давайте разберем главный тезис, что основной тормоз — конвейер. Да, выполнение некоторых инструкций требует занятости ФУ на разное количество тактов. Однако P4 имел 2ALU, которые работали на удвоенной частоте и могли обрабатывать инструкции за половину такта. Мало того, P4 имел избыточное количество ALU для его трехМОПного планировщика, т.е. 4, что позволяло освобождать дополнительный ресурс уже на следующий такт. О чем это говорит? О том, что вполне можно ускорять отдельные блоки по частоте, если вы хотите добиться какой-то цели.

Идем дальше. HyperThreading появился потому, что половина ресурсов ЦП не может быть эффективно утилизирована из-за проблем с доставкой данных из памяти, потому что латентность этих операций идет более 70 тактов (если данные не осели в кэше). Да, HT дает до 40% прироста производительности на двух параллельно выполняемых потоках, что снова же подтверждает факт простоя ФУ.

Смотрим на подход AMD с их модульной архитектурой, где модуль состоит из двух половинок с 2 ALU на борту (напомним, что в том же Core три ALU), утилизация ресурсов на оптимизированных алгоритмах весьма впечатляющая, и как минимум не уступает архитектуре Core второго поколения.

Суммируя хотя бы эти три факта мы получаем простой вывод, что рост частоты бесполезен ровно до тех пор, пока ФУ не будут загружаться постоянно и своевременно. Конвейер всегда можно расширить или применять тактику удвоения частоты работы ФУ, только бы патроны подавались вовремя.

Но, за увеличением количества ФУ стоит его величество ТДП. В спецификации по управлению питанием мы можем увидеть многофакторную систему удержания теплопакета в рамках допустимых значений. Там участвует и температура, и вольтаж, и частота отдельного ядра, и уровень загруженности…

Опять же, возьмем рендеринг 3D. Там применяются весьма впечатляющие оптимизации алгоритмов, поэтому они позволяют выжимать максимум из процессора и его архитектуры. Банально, не будем ходить далеко, сравним прирост частоты и прирост производительности i7-2600K при разгоне. Так вот, разгон с 3.4 до 4.45 (+30%) дает прирост производительности в районе 20%. Да, рост не линейный, но он есть. Погодите, в статье рассказывается, что конвейер не дает повышать частоту, но мы видим обратное, частота растет, и растет производительность. Да, не линейно, но рост есть. Упираемся в синхронизацию выполнения МОПов? А может все больше простаиваем по причине увеличения латентности доступа к памяти?

Но хабр такой хабр… Лучше ведь уличить кого-то в некомпетентности…
0
mayorovp #
Так вот, разгон с 3.4 до 4.45 (+30%) дает прирост производительности в районе 20%. Да, рост не линейный, но он есть.
Вот этот факт уже интереснее, над ним можно думать (если он подтвердится, конечно же). Надо было написать его сразу, вместо абстрактных «оверклокерских достижений».
0
s0rr0w #
В смысле если подтвердится?
Исследование производительности на реальном софте реальными людьми. Изучайте сколько влезет.

Идем дальше.
Смотрим на латентность инструкции MOVNTI
Nehalem: ~270 тактов
Sandy Bridge: ~350
Ivy Bridge: ~340
Haswell: ~400

Ха, латентность растет, частота находится на одном и том же уровне для всех этих архитектур. Это говорит про то, что латентность этой команды всем пофиг, она незначительна и не вносит серьезного влияния в общую производительность. Но нам усердно рассказывают, что проблема в этих самых «дорогих» операциях…

Давайте посмотрим на ту же фичу, которая появилась в архитектуре Core, такая как Macro Fusion. Она нам говорит, что некоторые операции могут соединяться в одну, чтобы выполняться в ФУ за 1 такт. Это значит, что есть операции, которые выполняются за доли такта. Так есть еще порох в пороховницах…

И, напоследок, почти все современные процессоры имеют блоки изменения очередности выполнения команд, которые позволяют равномерно распределять нагрузку по ФУ, достигая их более высокого уровня загруженности. Это снова же говорит в пользу простоя блоков и снижения влияния «толстых» комманд на общую производительность.

Еще раз повторю, можно просто увеличить количество ALU или FPU, или разрезать ALU на несколько частей, чтобы отделить одни операции от других. Но этим никто не будет заниматься, потому что бюджет транзисторов не бесконечный.
+1
mayorovp #
Нее, такое исследование я читать не буду. Это же надо было придумать верстку, чтобы основной контент занимал только 25% ширины монитора, вытянувшись в длинную «сосиску» по вертикали…
0
areht #
Почему вы считаете, что специалисты(мы же про маркетологов говорим?) Интел имеют цель продать вам самый быстрый процессор?

Им достаточно продать вам процессор быстрее процессора конкурента.

> На всякий случай повторю: среднестатистический пользователь не может использовать те системы охлаждения, которые используются оверклокерами.

Это софистика, и внедрить её в массы и есть цель написания статьи. Да, средний пользователь 7 ГГц не получит, а 4.5 — вполне.
0
mayorovp #
Два года назад я помог десяти людям понизить тактовую частоту процессора, благодаря чему их компьютеры перестали перезагружаться на «веселой ферме» при +37 на улице и +35 в комнате.

Сам я сейчас имею планы по понижению тактовой частоты моей видеокарты, надеясь хоть после этого суметь пройти Скайрим.

Я честно искал более мощные системы охлаждения, пригодные для эксплуатации неспециалистами. Я менял термопасту. Но не помогало ничего, кроме понижения частоты. А теперь вы мне рассказываете, что эту частоту можно, видите ли, поднять. В северных широтах — может и можно. Но не в моем городе.
+1
areht #
То есть вы утверждаете, что «специалисты» Intel не способны подобрать частоту и гонят брак в промышленных масштабах?

У меня средний аптайм месяц на всех компах, перезагружаюсь только если софт требует или электричество выключают. Попробуйте нормальный блок питания купить, например. И память.
0
mayorovp #
В таком случае я завидую климату дефолт-сити.
0
areht #
Эффект Даннинга — Крюгера?

> Процессоры рассчитаны производителем на то, чтобы эксплуатироваться в широком диапазоне внешних условий (которые влияют на длину стадии), поэтому производятся с некоторым запасом по частоте.
+2
mayorovp #
Специально для вас посмотрел, что пишут специалисты: www.intel.ru/content/dam/www/public/us/en/documents/design-guides/4th-gen-core-family-desktop-tmsdg.pdf

3.1 Boundary Condition Definition

TEXTERNAL = 35 °C. This is typical of a maximum system operating environment or room temperature

То есть в описанной мною ситуации процессоры работали на пределе заложенных температурных возможностей. Добавим сюда любую мелкую помеху системе охлаждения — вот и перегрев. Напомню, компьютер эксплуатируется неспециалистами, которые всегда найдут способ чем-нибудь перекрыть поток воздуха. А не найдут люди — так кот поможет.
0
areht #
Специально для вас посмотрел, что пишут специалисты

The results may be excessive noise from fans having to operate at a speed higher than intended. In the worst case this can lead to performance loss with excessive activation of the Thermal Control Circuit (TCC).

Перезагрузка — это брак.

> А не найдут люди — так кот поможет.

вы до скольки занижаете частоту, чтоб от кота защититься? От пролитого чая?
0
mayorovp #
Перезагрузка — это брак.
Это — распространенная «фича» безымянных материнок. При стандартных настройках пороговая температура для аварийной перезагрузки зачастую ниже температуры активации TCC процессора.
0
areht #
Т.е. вы мне ссылку на дизайн-гайд интела даёте, чтобы доказать, что безымянные материнки покупать не стоит?
0
mayorovp #
Нет, чтобы объяснить, почему средний пользователь не сможет разогнать процессор до 4.5 ГГц.
–1
areht #
Тогда вам надо показать в каком месте материнка отличает проц на 3.5 от 4.5
+2
JDima #
Вы ищете системы охлаждения. А возможно, проблема кроется в плохом корпусе. Вот мой (картинка устарела — с тех пор добавилась вторая видеокарта, да и плашек памяти стало четыре). На процессоре заводская водянка, никаких сложностей, ставится даже проще суперкулеров. Напротив видеокарт 200мм вертушка поставляет свежий воздух, еще одна спереди, и несколько 120мм пропеллеров сверху и сзади. Паутина проводов не мешает воздушному потоку (типичная ошибка).

Видеокарты и процессор слегка (где-то на треть) разогнаны. Процессор, 3770к, до тех самых 4,5ггц (у меня неудачный чип, он для этого требует целых 1,3в).
В самую лютую жару никаких проблем с перегревом не испытываю. Я даже не про полный ахтунг вида «троттлинг, ребут в веселой ферме», а про «не более 80 градусов на процессоре под линпаком и 90 градусов на видеокартах под бубликом».

Мораль — не надо экономить на охлаждении, тогда не придется заниматься даунклокингом.
0
Valeratal #
А что за «заводская» водянка?
0
JDima #
H100. Выхлоп сразу наружу корпуса (но крепится радиатор внутри корпуса, лишнего места не занимая, на фотографии как раз под ним вплотную 2х120мм привинчены). Конечно, по эффективности это не Silver Arrow, но уступает мало, и есть масса своих преимуществ.
0
SlavikMIPT #
я на своем компе дело поправил, сделав притяжно-вытяжную систему внутри корпуса — что толку ставить суперкуллер, если горячий воздух никуда из корпуса не выходит — лучше поставить 2 куллера на маленьких оборотах — один вдувает, другой выдувает воздух из корпуса
0
mayorovp #
По поводу предмета спора: средний пользователь не будет ставить себе систему водяного охлаждения.

По поводу моих проблем и вашего корпуса: я рад, что в дефолт-сити достать нормальный корпус с заводской системой водяного охлаждения — не проблема, но в Челябинске систем водяного охлаждения нет вообще. По крайней мере, ни мои знакомые специалисты, ни папины знакомые специалисты, ни дедушкины знакомые специалисты, ни даже бабушкины знакомые специалисты не смогли подсказать мне нужного магазина.
0
JDima #
достать нормальный корпус с заводской системой водяного охлаждения

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

А почему бы и нет?
Есть и воздушные кулеры с хорошей эффективностью. Что угодно лучше боксового кулера.
в Челябинске систем водяного охлаждения нет вообще

Сходу, за 10 секунд поиска:
chel.utinet.ru/hardware/liquid_cooling/zalman/cnps20lq/
Внизу ссылки на множество заводских водянок других брендов.

Да и почему именно Челябинск, когда есть Ebay и Amazon? Я половину железа там беру.
0
mayorovp #
Обратите внимание: все, что находится сходу — интернет-магазины. То есть мне предстоит увлекательная игра «оплати заказ — подожди месяц — получи товар — убедись, что он не помог, ибо слабый — отправь обратно с заявлением почтой России — подожди 3 месяца возврата денег — перейди к пункту 1». Плюс ненулевая вероятность на очередной итерации потерять деньги из-за особенностей работы почты россии.

Конкретно по той ссылке, которую вы нашли — я так и не нашел, где указана хотя бы одна количественная характеристика эффективности охлаждения. Как вообще сравнивать эту систему охлаждения с аналогами?

–2
JDima #
все, что находится сходу — интернет-магазины. То есть мне предстоит увлекательная игра

Доставка до пункта выдачи — бесплатно и без предоплаты. Домой — 443 рубля. Прямо по моей ссылке, найденной сходу.
Как вообще сравнивать эту систему охлаждения с аналогами?

Очевидно, что надо смотреть независимые обзоры. Любые количественные характеристики по отдельности или вместе не говорят вообще ни о чем. Первый попавшийся пример.

Будто вы в XX-м веке застряли, причем в совковые времена :)
0
Alexeyslav #
Я вот когда что-то беру в интернет-магазине сначала гуглю предлагаемую модель и смотрю характеристики на сайте производителя, если таковой есть а если нет — то уже на свой страх и риск, естественно в итоге побеждает самый подходящий товар который максимально описан производителем. Там же, на сайте производителя можно посмотреть соседние модели, сравнить выбрать и найти в другом магазине. Это значительно снижает риски «кота в мешке» и пока ни разу подход не подвёл.
0
mayorovp #
Я тоже так делаю, но это имеет смысл только когда имеешь хотя бы минимальные представления о предметной области.
0
JDima #
Выше вы писали и про даунклокинг, и про:
Я честно искал более мощные системы охлаждения, пригодные для эксплуатации неспециалистами. Я менял термопасту. Но не помогало ничего, кроме понижения частоты.

Следовательно — вы имеете хотя бы минимальные представления о предметной области, и должны понимать, что описания площади радиаторов, силы воздушного потока, напряжений и оборотов вертушек, количества теплотрубок, массы, количестве хладагента, скорости его прокачки и так далее не позволяют судить об эффективности СО. Есть только одна цифра, которая важна: температура процессора с данной СО под нагрузкой, в сравнении с другими СО того же класса. Т.е. обзоры, которых полно.
–4
Veider #
возможность незначительно повысить частоту
Частоту можно повышать очень значительно, пока некоторые компании на «и» не начинают блокировать всеми силами эту возможность.
Core 2 и первое поколение i5/i7 — живой тому пример.
+8
forgotten #
Странно, чего же некоторые компании на букву «А» не пользуются ситуацией и не захватывают рынок.
0
areht #
Некоторые компании на букву «А» не могут захватить рынок потому, что лет 5 не могут, к сожалению, достойный конкурента процессор выпустить и конкурируют только ценой.

Это внутренние проблемы «А», чем и пользуется компания на «И».
0
forgotten #
Есть как минимум три компании на «A», которые могут захватить рынок — AMD, ARM и Apple.
+1
areht #
Вы сейчас про рынок чего?

Из них только одна имеет процессор сравнимый хотя бы Core i5, да и то при TDP зашкаливающим в 150 Вт. А что они могут противопоставить i7 4770?
0
Veider #
Собственно не все из них делают x86 процессоры, поэтому определенные доли рынка захватить не выйдет чисто технически.
–1
Veider #
Минусуют воинствующие фанаты интела?
+2
guessss_who #
Какая-то спорная статья. Первое, что бросилось в глаза — x86 называют суперскалярной архитектурой. i486 был суперскалярным? Или не был x86?..

Второе — как-то совершенно незаслуженно обойден вниманием тот факт, что раньше мы видели рост частоты процессоров при уменьшении техпроцессов. 3.8GHz когда появились? В 2004-2005 году, Pentium 4 Prescott, 65 нм. Сегодня, спустя 8 лет, техпроцесс уменьшен в 3 раза, а частоты возрасли… ой, а частоты не возрасли. Хотя автор пишет, цитирую:
Тем не менее, производители микропроцессоров постоянно совершенствуют технологический процесс, и частота за счет этого постепенно ползет вверх.


Автор, вы действительно являетесь экспертом в теме, о которой пишете?..
+2
khim #
Автор действительно является экспертов теме, о которой пишет, а вы демонстрируете яркий пример эффекта Даннинга — Крюгера. То есть да, с суперскалярностью вы человека подловили — скорее всего этот момент изначально в статье был, но потом выпал (суперскалярность, как бы, имеет прямое отношение к производительности и весьма косвенное — к частоте работы процессора) и остался обычный конвеер известный где-то с 70х (а может и раньше). Prescott же — идельный процессор для демонстрации тезисов, описанных в статье: в нём была сделана попытка «задрать частоту до небес», в конвеере создали аж 32 стадии (из-за чего многие вещи пришлось исполнять спекулятивно), в результате получили офигительную частоту и «прекрасное» тепловыделение при посредственной производительноти. Для справки: Nehalem имеет ровно вдвое меньше стадий и на той же частоте, что и Prescott исполняет программы чуть не вдвое быстрее (это без учёта многоядерности и прочего).
+1
guessss_who #
Признайтесь, про эффект Даннинга-Крюгера вы подсмотрели чуть выше, в комментарии forgotten? :)

И я не совсем понял, к чему вы вдались в разъяснения о низкой производительности Prescott-а (и о его производительности вообще). Я его упомянул только из-за того, что на нем была достигнута частота 3.8GHz. 8 лет назад. При техпроцессе 65 нм. И вот наступил 2014 год, техпроцесс уменьшен втрое, частоты не увеличились. И статья с названием «Почему не растет частота» не объясняет, почему. Хотя это один из самых интересных вопросов в данной предметной области, поверьте. Я однажды полез гуглить и залип часа на три. :)
0
khim #
Название эффекта я действительно взял из комментария выше, но про этот феномен все знают и так.

Статья «Почему не растет частота» прекрасно объясняет почем частоты не увеличились. Вернее так: она даёт всё необходимое для того, чтобы понять почему частоты не увеличились (они, кстати, чуток таки увеличились — Turbo Bust, не забываем, да). Но для этого нужно, о ужас, сопоставить несколько фактов. Похоже хабражители это делать разучились.
+1
s0rr0w #
Факты? Где факты? Что-то я не увидел в статье таблицы латентности операций и средней частоты их использования в софте (а такие факты однозначно есть в недрах компании Intel).
0
iavael #
Таблицы (а они довольно большие для статьи) латентности операций есть в документации по архитектуре. Среднюю частоту использования тех или иных опкодов, вы, извините, и сами посчитать можете, причем даже специфичную для вашего софта, тем более, что «средняя температура по больнице» вряд ли будет представлять практический интерес.
0
leventov #
Я думаю, Интел в состоянии сделать массовый проц с частотой 5ГГц, только зачем им это? Сейчас другие тренды — понижение энергопотребления, встроенные видеоядра.

+1
forgotten #
В этом тексте меня смущает один момент: а что, 5-10 лет назад, во время взрывного роста частот, эти проблемы были неактуальны? Да вроде как всё сказанное можно легко оттранслировать во времени назад, во времена микрометровых техпроцессов. Т.е. как раз основной вопрос — что же такого произошло на рубеже в 90 нм — так и не раскрыт.
+2
guessss_who #
Я как-то задавался этим вопросом и немного погуглил. Смысл (очень-очень грубо) в том, что на высоких частотах электрические цепи внутри процессора начинают сильно излучать в СВЧ-диапазоне, и энергия этого излучения превращается в тепло. Из-за этого, свыше определенного предела частоты, тепловыделение процессоров резко возрастает (до этогого предела оно расло более-менее линейно).

И да, странно, что при таком бодром начале (о том, что есть один фактор, в который всё упирается), в статье столько воды и нет даже намека на рассказ об этом самом факторе.
+2
khim #
Если бы всё было так, как вы описываете, то частоты процессоров в определённый момент просто упёрлись бы и перестали расти. Однако этого не происходит: частоты (при том же уровне тепловыделения) растут примерно с той же скоростью, с какой уменьшаются транзисторы (другое дело, что в последнее время с размерами транзисторов всё стало сложнее: они сейчас уменьшаются в размерах медленнее, чем это может показаться если просто сравнивать титулярные нанометры у разных техпроцессов). Статья же объясняет почему раньше частоты могли расти быстрее, чем уменьшались транзисторы.

Эффект, про который вы рассказываете тоже имеет место быть, но он скорее ограничивает частоту одного отдельно взятого процессора, а не рост частоты процессоров при изменении их конструкции.
–1
guessss_who #
Ну елки-палки. «Я не понимаю, как вы не понимаете».

Вот вам факты:
1) Частоты уже 8 лет не растут (со времен Prescott 3.8GHz);
2) За то время, пока частоты не растут, техпроцесс уменьшился втрое — c 65 до 22 нм (или сегодня уже мельче?..);
3) До предела в 3.8GHz частоты исправно расли с уменьшением техпроцесса.

Что, эти 8 лет отсутствия прогресса — вина проклятого длинного конвеера, о котором нам рассказывают в картинках три экрана?..
+1
khim #
Что, эти 8 лет отсутствия прогресса — вина проклятого длинного конвеера, о котором нам рассказывают в картинках три экрана?
Нет. Отсутствие прогресса в частоте — есть следствие отказа от сверхдлинного конвеера. А вот почему от него отказались — это уже другая история.

Частоты процессров с конвеерами одинаковой длины в последние 8 лет растут так же исправно как и раньше.
0
guessss_who #
Okay, значит длинный конвеер. Вы настаиваете. Теперь следите за руками. Опять голые факты:

1) В Prescott, 8 лет назад, у нас был плохой, нехороший, длинный ковеер. В Nehalem мы сократили его вдвое, при этом пришлось снизить частоту на 10%. Техпроцесс уменьшился на треть.
2) В Haswell длина конвеера такая же, как у Nehalem. Техпроцесс стал в 2 раза мельче. Частота — все те же ≈ 3.8GHz.

Почему уменьшение техпроцесса вдвое(!) позволило «отвоевать» частоту только до уровня 8-летнего Prescott? Разве это неинтересно? Я зря возмущаюсь, что об этом ничего не написано в статье под названием «Почему не растет частота», в блоге компании Intel?
+3
khim #
А эти вещи — они уже совсем из другой оперы. TDP топового Nehalem'а — 130 ватт, топового Haswell'а — пока что 84 ватта. Это притом, что топовый Nehalem не имел в себе GPU, а Haswell'а без GPU не бывает. С уменьшением техпроцесса «вдвое» тоже не всё так просто: в 45 nm Nehalem'а помещалось 774 миллиона транзисторов на 296mm² (то есть 2.6 миллиона на mm²), а в Haswell'е на 177mm² уместилось 1.4 миллиарда (то есть 7.9 миллиона на mm²), то есть транзисторы уменьшились на вчетверо, а втрое и, соответственно, время срабатывания также возросло не так сильно, как кажется из простого сравнения титульных названий техпроцессов.

Предельно высокая частота не обозначает предельно высокой производительности, а сделав предельно скоростной процессор вам нужно будет придумать кому его продать. Всё-таки Intel не на серверные рынки в основном работает, потому процессор работающий на 5GHz сделал не Intel, а IBM — причём ещё аж на 65 nm. А уже на 45 nm таких частот IBM не предлагал, а вместо этого предложил удвоить-учетверить количество ядер на сокет.

То есть ваши замечания о том, что в последнее время частота растёт гораздо медленнее уменьшения техпроцесса, в общем, справедливы, но они связаны во-многом не с техническими, а с маркетинговыми соображениями: продолжить тренд 90х и создать процессор на 10GHz сейчас, в принципе, не проблема — но он будет одноядерным и будет выделять хорошо за 1000 ватт (не забываем про то, что Pentium работал от 5V и выделял всего-то 16 ватт, что по тем временам было просто-таки «безумно горячо»), так что продать его будет проблематично.
0
TechThink #
По поводу x86 и суперскалярности. Все верно: x86 != суперскалярность. Но сейчас все представители семейства суперскалярны (даже Atom с недавних пор обрел это свойство), так что я не стал здесь вдаваться в детали.

Частота P4 не была «отвоевана». Она была завоевана. P4 из-за постоянного реплэя выделял мощность в соответствии со своей частотой, а IPC демонстрировал низкий. Эффективно он работал как процессор с более низкой частотой.
0
s0rr0w #
А при чем тут IPC? Ну более низкий, и что? Речь идет про частоту, а не про IPC…
0
TechThink #
Речь идет про полезную частоту. Вхолостую «тикать» неинтересно…
0
s0rr0w #
Почему это вхолостую? Работа выполнялась, но не вся принималась как правильная. Если бы P4 не гонял реплеи, он бы не грелся так. :)

Судя по устройству, P4 мог отправлять на исполнение 6 инструкций за такт. Сколько там у Core 3 поколения?
0
TechThink #
Мда… Вот что значит писать комменты во втором часу… Atom, конечно же, изначально суперскалярен. Я почему-то держал в голове OOO когда писал коммент. Прошу прощения.
+2
yurav #
скажу по секрету, «провода» на 32 нм перестали масштабироваться, можно сказать, совсем, а на 22-14 нм и транзисторы не слишком-то уменьшаются по сравнению с предыдущей технологией.
втрое оно только в цифрах нанометров.
+3
argos #
Сначала были кукурузные гигагерцы. Потом когда пользователи смекнули что гигагерцы != производительность, появились кукурузные нанометры. Что дальше?
+2
datacompboy #
кукурузные ядра.
стоп, они уже
0
khim #
Вам уже недостаточно в рот еду положить, ещё и разжевать надо? Исходные данные вам даны, запрос в любую поисковую систему даст вам вот эту статью где есть исходные данные:
1989й год: 486й — конвеер в 5 стадий
2004й год: Prescott — конвеер ажно в 31 стадию (32 если считать декодер)
Ну и? Когда там у нас частоты бурно росли? Сходится? Проблема в том, что при таком длинном конвеере весь пар «уходит в свисток»: в Pentium 4 очень много работы совершалось спекулятивно и её результат приходилось выкидывать, а мощности системы охлаждения небесконечны, потому у всех последующих процессоров конвеер находится между этими двумя крайностями (в Nehalem — 16 стадий).

P.S. Был ещё Tejas в котором планировалось не то 40, не то 50 стадий (как и следует из описанного в статье) и его даже вроде довели до матриц, но «выпекать» после фиско Prescott'а не стали ибо было ясно что при осмысленном уровне тепловыделения его производительность будет совсем никакая.
+4
forgotten #
> Вам уже недостаточно в рот еду положить, ещё и разжевать надо? Исходные данные вам даны,

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

> Ну и? Когда там у нас частоты бурно росли? Сходится?



Сделайте вывод из этого графика, пожалуйста.
–3
khim #
Сделайте вывод из этого графика, пожалуйста.
Недостаточно данных, однако. Подобные графики годятся для проверки теории, но никак не для построения теорий. Где ваша теория, которая свзяывает два наблюдаемых вами феномена? Желательно чтобы она появилась до появления соотвествующего графика, а не после.
+7
forgotten #
> Недостаточно данных, однако.

Ну вам же достаточно данных по количеству ступеней конвейера 486-го и Прескотта, чтобы объяснить феномен отсутствия роста частот процессоров в последние 10 лет.

> Где ваша теория, которая свзяывает два наблюдаемых вами феномена?

Вот: с падением доли IE уменьшилось общее количество агрессии, которую испытывали люди, созерцая глюки и тупняки этого браузера.
–1
darthslider #
А еще уменьшение количества пиратов ведёт к глобальному потеплению! ;)
+3
polym0rph #
Есть еще такой нюанс, как маркетинг и позиционирование. Некоторые процессоры может и могут работать на бОльших частотах не выбиваясь из теплового пакета, но им по лестнице не положено. Но мало просто нужную частоту задать, нужно сделать оверклокинг не самым простым занятием. Самый простой способ — ограничить множитель. Можно еще вместо пайки кристалла к крышке положить термопасту. Причем не совсем по уму положить. В итоге разгон без «скальпирования» будет упираться в пергрев ядра, хоть кулер и может спокойно справиться с теплоотводом, до него просто не успеет дойти. «Скальпированные» же модели после замены термоинтерфейса спокойно могут показать температуры градусов на 20 ниже, чем при тех же условиях до замены, что на частотном потенциале сказывается крайне благоприятно.
0
polym0rph #
В принципе не велика беда, об этих особенностях все равно знает только небольшая кучка энтузиастов, которые рискуя процессором иногда доводят его до ума. Среди них, кстати, такой подход организации теплоотвода получил довольно емкое название «навоз под крышкой».
НЛО прилетело и опубликовало эту надпись здесь
+1
Mario_Z #
Тема в комментах опять превратилась в срач x86 vs ARM, похоже людям важен спор ради спора, а не суть.
+1
valeriyk #
Рост частоты ограничен способностью корпуса микросхемы рассеивать тепло. До тех пор, пока это не проблема, как в случае с относительно маленькими кристаллами, частота действительно значительно растет при переходе на техпроцесс с меньшими нормами (при прочих равных условиях)!

Вот циферки для процессора Synopsys ARC EM6 из официального даташита (http://www.synopsys.com/dw/doc.php/ds/cc/arc_em6.pdf), конфигурация процессора идентичная:

65LP (Low Power): 350 МГц
40LP: 540 МГц
28HP: 900 МГц

Этот процессор на 65-нм процессе занимает 0,04 мм2 и рассеивает 5 мВт. Очевидно, что такое мизерное тепловыделение никак не ограничивает рост частоты.

В случае, когда кристалл значительно большего размера, именно тепловыделение играет решающую роль. Микросхема, изготовленная по техпроцессу 40LP с кристаллом площадью примерно 10 мм2, засунутым в пластиковый корпус размером 15х15мм, может работать без радиатора на 400 МГц. На 700 МГц ей нужен радиатор, и он уже весьма теплый.

Что происходит, когда у вас кристалл в районе 100 мм2, работающий на частоте за 2 ГГц, можете догадаться сами. Поэтому частоту повышают на столько, сколько может выдержать корпус.

Так что стадии конвейера тут не при чем. Мало того, имхо, именно проблемы с тепловыделением позволили вернуть длину конвейера к приличным значениям наперекор маркетологам.
+1
valeriyk #
Наверное, не совсем корректно сравнивать Low Power процессы c 28HP, поэтому вот данные по «быстрым» процессам из того же документа:
— 90GP: 420 МГц (90нм — это как раз времена позднего Pentium 4)
— 40GP: 770 МГц

То есть только за счет перехода с 40 нм на 28 нм увеличение частоты составляет 16%.

А вот данные по интеловским процам с одинаковой архитектурой (Nehalem/Westmere) и сопоставимыми техпроцессами (брал самую высокую частоту отсюда: en.wikipedia.org/wiki/List_of_Intel_Core_i7_microprocessors):
45 нм: 3,33 ГГц
32 нм: 3,47 ГГц (+4%)
+1
valeriyk #
Ну и напоследок, увеличение частоты при переходе с 65 нм на 40/45нм:

У Интела (Conroe/Wolfsdale: http://en.wikipedia.org/wiki/Core_(microarchitecture) ): 3 ГГц -> 3,33 ГГц (+11%)

У ARC EM6: 350 МГц -> 540 МГц (+54%)
+1
areht #
Я только одного не понял.
Если, не смотря на то, что Core i7-4770K промаркирован на 3.5 ГГц, после замены термоинтерфейса, на воздухе и без поднятия напряжения гонится до 4500 ГГц, то что мешает от 150-200$ продавать процессоры порядка 4 ГГц?

По-моему очевидно, что технология отработана и готова.

А тезис про маркировку процессоров в 95% от их максимума не имеет отношения к реальности и служит оправданием преднамеренного занижения возможностей процессоров.
+5
JDima #
что мешает от 150-200$ продавать процессоры порядка 4 ГГц?

Тот факт, что можно продавать за $300 камни на 3.5ггц, и уже даже тут конкурентов нет.
Кто хочет получить 4,5ггц и выше — не вопрос. Палки в колеса никто не сует (ну кроме термокаки под крышкой вместо православного припоя — это тоже объяснимо, так как старые камни в руках оверклокеров конкурируют с новыми, и потому оверклокер не так часто покупает новый камень).

Intel — коммерческая компания. Цель — не обеспечить каждого жителя планеты максимальным числом гигагерц, а заработать денег. А стоимость товара определяется в первую очередь не себестоимостью его производства, а тем, за сколько его готовы купить.
0
guessss_who #
Так, кажется я нашел тот нагугленный когда-то очень давно текст, который заставил меня усомниться в корректности выводов, сделанных в топике. Вот ссылка на полную версию:
www.rusdoc.ru/articles/15654/

А вот цитата с самым интересным (выделение мое):
… Не будем здесь вдаваться в конструкции применяемых транзисторов, для рассматриваемого явления это несущественно. Главное, что в любой конструкции со снижением размера транзисторов (длины канала) растет их быстродействие (снижается время переключения) и одновременно расширяется полоса частот, занимаемая помехами (Δf = 1 ⁄ τ) и повышается частота верхней границы спектра помех.

fгр = 1 ⁄ τ

Повышение быстродействия (снижение времени переключения) позволяют, вроде бы, так же повысить тактовую частоту процессоров, но ее рост остановился на частоте 3800 МГц еще на техпроцессе 0,9 мкм (обратите на это внимание).

Причем с ростом их частоты большая часть именно высокочастотных составляющих помех не выходит за пределы процессора и проявляется очень слабо, поскольку отсекаются паразитной индуктивностью соединительных линий — проводников. Для частот помех характерных для последних моделей процессоров даже их малая индуктивность имеет достаточно большое индуктивное сопротивление. Их оставшаяся в процессоре мощность теряется во внутренних соединениях, поглощается в виде потерь в диэлектрике изоляции проводников, поглощается в легированных областях полупроводника активных элементов. Они также через емкостные связи наводится на сигнальные цепи. Чем больше эта мощность, тем больше наводимое на сигнальные цепи напряжение и тепловыделение в процессоре. Потому для ее снижения приходится снижать тактовую частоту процессора.

Во всех публикациях пока рассматривается только влияние технологических факторов на рост тактовой частоты процессора и физические ограничения на параметры КМОП-транзистора.

Еще в 1999-2002 году я предсказывал ограничения тактовой частоты, накладываемые ВЧ помехами, генерируемыми процессорами в цепях питания. Начиная с техпроцесса 90 нм, их влияние начинает преобладать. А на тех. процессе 45 нм частоты помех таковы, что длина их волны меньше линейного размера кристалла. Это, несомненно, за счет резонансных явлений усилит поглощение их энергии в кристалле и снизит помехоустойчивость процессоров. …

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

Интересны комментарии по этому поводу от автора и от людей, которые хорошо знают физику рассматриваемых процессов.
0
TechThink #
Не совсем понимаю, о каких выводах, «сделанных в топике», вы говорите.

В статье предлагается определенная точка зрения на проблему: частоту можно поднять, только уменьшив длину стадии. Иначе никак. Стадия обязана влезать в такт.

Каким образом уменьшать длину стадии — вопрос сложный и многогранный. Вы хотите зайти со стороны техпроцесса, как я понимаю.

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

Теперь про вашу ссылку. Автор там делает то же самое, что и вы, — сравнивает несравнимое, т.е. ставит в один ряд принципиально разные микроархитектуры. Нельзя ставить в один ряд, например, процессоры семейства P4 и процессоры семейства Core, а затем сравнивать их исключительно с позиции техпроцесса.

По-хорошему, P4 с микронным процессом нужно сравнивать с P4 с нанометровым процессом (если бы такой был). При таком сравнении мы бы увидели приличный рост частоты (+ примерно линейный рост мощности + по-прежнему бестолковый IPC).

В скопированных вами сюда рассуждениях автор явно путает помехи (это то, что искажает фронт сигнала) с тепловыделением…
0
s0rr0w #
Почему латентность инструкции MOVNTI растет с каждой новой архитектурой, при этом частота процессоров не изменяется?

+3
khim #
Потому что на одну и ту же память вешается всё больше потребителей. Скорость работы movnti вообще никак с частотой процессора не связана.
0
s0rr0w #
Контроллер памяти в SB, IB, HW работает на частоте ядра. Точно не связана?
0
khim #
Абсолютно. Я даже не знаю как можно процессорные технологии обсуждать с человеком, который этого не понимает.

Как связана мощность двигателя локомотива со временем доставки почты на поезде ведомым оном локомотиве из Москвы во Владивосток? Да никак не связана: всё определяется длиной железной дороги и ограничением скорости на ней. Вот количество почты, которое вы можете доставить — да, связано, чем мощнее локомотив тем больше можно на него поцепить вагонов. А скорость — ну никак. Если заставите ваш поезд по дороге заехать в Одессу (==прогоните данные через дополнительный модуль) будет медленнее, спрямите дорогу — быстрее, но от замены локомотива скорость вообще никак не зависит.

То же самое и тут: основные задержки вносятся просто-напросто динамической памятью (скорость работы которой прекратила расти ещё в конце XX века), ещё что-то отбирают контроллеры между памятью и процессором, скорость же самого процессора влияет на этот параметр настолько слабо, что и говорить, в общем, не о чем.
0
s0rr0w #
А вот я и ошибся. Частота контроллера памяти не связана с частотой процессора, а тактуется отдельно. Итак, инструкция MOVNTI, попадая на 4й порт (store data), потом отправляется по кольцевой шине Агенту, который отправляет данные через IMC в память. Ядра, шина и контроллер памяти в последних процессорах Intel имеют свою частоту работы, поэтому на каждом из этапов могут возникать задержки синхронизации. Бенчмарки показывают, что пропускная способность памяти растет с увеличением частоты ядер. Это может говорить о том, что уменьшается лаг синхронизации сигналов между отдельными частями CPU, достигая тем самым более высокой производительности записи данных в память.

0
guessss_who #
Посмотрите на википедии статью о семействе Pentium 4. В некоторые моменты архитектура почти не менялась (или не менялась вовсе, как при переходе с Prescott-2M на Cedar Mill), а техпроцесс уменьшался. Тепловыделение заметно уменьшалось, но повысить частоты сверх 3.8GHz это не помогло. При чем, насколько я помню, разочарование ждало и тех, кто пытался этого добиться оверклокерскими методами.

В скопированных мной рассуждениях, насколько я понял, под «помехами» автор подразумевает радиоизлучение проводников (в данном случае СВЧ).
0
TechThink #
1) Под «помехами» автор понимает именно помехи. С ростом частоты, спектральный состав помех изменяется. Факт! На помехи расходуется мощность. Факт!

Дальше автор, видимо, пытается связать мощность помех с нагревом МП. Такая связь, очевидно, есть. В самых ужасных случаях до 10-20% полной мощности может уйти в помехи (т.е. 10-20% процентов нагрева происходит по вине помех).

Дальше я могу только задать вопрос: и что?

Самое страшное в помехах не то, что они греют процессор, а то, что из-за них деградирует сигнал.

И это проблема.

Но я все еще не понимаю, с чем именно вы спорите.

Нагрев МП — проблема. Деградирование фронта — проблема. Никто с этим не спорит. Куча других проблем еще есть.
Может, вы хотите сказать, что существует какое-то принципиальное ограничение на частоту МП, которое лежит в районе 3.8ГГц? Но ведь это не так. Даже оверклокеры гонят частоту до 8ГГц.

Поясните, пожалуйста, что вы хотите доказать.

2) Разгонять P4 дальше никакого смысла не было. Это был утюг с производительностью калькулятора. Успехи в области техпроцесса шли не на разгон, а на снижение мощности.
0
guessss_who #
Поясните, пожалуйста, что вы хотите доказать.

— Поясняю. Из текста, который процитирован в начале этого треда, я сделал выводы, что в районе 4GHz резко возрастает % энергии, который уходит сначала в СВЧ излучение, а потом в тепло. И именно этот эффект мешает сегодня делать процессоры с более высокой тактовой частотой. Как минимум — без серьёзного пересмотра подхода к проектированию топологии кристалла.

Это не так?
0
s0rr0w #
Еще вопрос, что именно вы называете стадией? Многие инструкции выполняются около 20 тактов (AAM, DIV, FDIV, FPREM, FSQRT и т.д), некоторые около 400 (MOVNTQ, MOVNTDQ, VMOVNTDQ), и однотактовых инструкций довольно таки мало (около четверти).

0
stoune #
Интел схожего мнения с вашим автором. На Хабре уже есть статьи где достаточно качественно расписано:
Жизнь в эпоху «тёмного» кремния. Часть 1
Жизнь в эпоху «тёмного» кремния. Часть 2
Жизнь в эпоху «тёмного» кремния. Часть 2,
в моём коментарии ниже есть ссылки.
А статья автора, графоманство человека, который пропустил курс «Компьютерной архитектуры»
0
Dima4ka #
Автор, скажите, а Turbo Boost в mac — компьютерах работает именно увеличением напряжения и охлаждения?
0
stoune #
Рискно набрать минусов, но для любого кто хоть как-то слушал курсы микропроцессорной архитектуры и электроники начало статьи полный бред.
Длительность выполнения части/инструкции не меряется во времени, а меряется в тактах процессора. Ничего в процесоре синхронизированного с тактами генератора не происходит(за исключением советских асинхронных архитектур, которые канули в лету).
Дальше уже можно не читать, потому что ваши предположения построены на полностью ложных предпосылках. Читайте лучше Хеннеси и Патерсона, Computer Architecture, Fifth Edition: A Quantitative Approach John L. Hennessy (Author), David A. Patterson (Author). На компьютерной инженерии рассказывают примерно на третьем курсе.
Есть разные стадии конвейера, выборка, декодирование, исполнение и т. д. каждая в разных архитектурах занимает определенное количество тактов. И если вы откроете руководство разработчика про архитектуре х86 от Интел или АМД вы также не увидите времени исполнения инструкций, а увидите количество тактов.
Если говорить точнее почему не увеличивается частота, лучше чем Интел я не напишу наверное:
И на хабре было несколько статтей от Интела о «тёмном кремнии»
Жизнь в эпоху «тёмного» кремния. Часть 1
Жизнь в эпоху «тёмного» кремния. Часть 2
Жизнь в эпоху «тёмного» кремния. Часть 2
где упоминается закон Деннарда, а также любимый вопрос экзаменационных билетов закон Амдала.
А также нужно упомянуть о росте тока утечки при росте частоты и о том что размеры элементов настолько малые по сравнению с скоростью распространения сигнала кристалла и длиной шин что для нужно добавлять синхронизирующие элементы которые дополнительно усложняют схему(где то видел цыфры, что для интел уже более 10% кристала) и ограничивают рост частоты(разработчики на больших FPGA стыкаются достаточно часто на больших чатотах).
0
stoune #
Кстати IBM Power4 серийные образцы на 5 ГГц работают, вот только это несколько иное ядро и средняя вычислительная мощность иструкции архитектуры Power иная чем у x86.
0
khim #
POWER6 на 5Ghz продавался во вполне себе серийных машинках.
+2
noonesshadow #
x86 — виртуальный набор команд (в том смысле, что аппаратных цепей, реализующих эти команды, нет), который транслируется в микрокоманды, иногда несколько микрокоманд (отсюда число тактов), в редких случаях (пишу для зануд) несколько x86 команд транслируются в одну микрокоманду. в статье речь о микрокомандах
+1
stoune #
А какая разница? Разве я написал иначе? Микрокоманды prefecth, decoding, execution их распаралеливают на конвеере. Длина каждой микрокоманды измеряется в количестве тактов, а не времени, именно по тактам синхронизируют задержки от разных блоков. У современных чипов плавающая частота, соответственно каждая стадия может занять разное время, но в общем случае та же самая стадия для одной и той же команды занимает разное время на разной частоте но тоже количество тактов. Об это я говорил, привязка к времени это полная безграмотность. Закон что производительность системы ограничена самым медленным элементом, Закон Амдала, который учат третьекурсники компьютерной архитектуры.
Посмотрите статьи Интела что я привёл. Куча ссылок, список литературы.
А здесь куча противоречивых и ложных утверждений и мешанина фактов и выдумок, зато вроде бы написано по простецки.
0
noonesshadow #
Ага, кажется я понял о чем вы…
наверное в статье привязка ко времени идет в ключе «минимальное время, за которое эта микрокоманда может выполниться на текущей элементной базе»

вы же утверждаете, что физических ограничений подобного нет, и частота ограничена отводимым теплом

кстати это статья тоже из блога Интел, написана их же сотрудниками… может из-за этого вас негативно оценили
0
stoune #
Я не утверждаю что физических ограничений нет они есть но не они есть главной причиной отсутствия роста частоты. Для того чтобы не было проблем с задержкой сигналов ставят специальную логику, да она занимает площадь кристала, но это решабельно.
Чтобы не было проблем с самой длинной стадией один из подходов был дробить далее конвейер на более мелкие, что мы увидели в Пентиум-4, который имел наверное самый длинный конвейер, тогда можна было увеличивать частоту, но возникает много проблем, от проблемы заполнености конвеера, до самой главной, как отводить тепло. Радиатор Пентиум 4 был очень большим и притом всё одно сильно грелся.
То что статья написана интел разве что-то значит? Это не маркетинговая статья, причем с ссылками на научные работы, а у автора статья из разряда «они скрывают», а я вот умный закон Амдала сам вывел и нашел решение над которым бьются лучшие умы.
Мне не понравилось что в статье очень много неточностей и просто неграмотных выводов которым учат студентов 3-го курса.
0
Alexeyslav #
О, да прям? транзисторы теперь переключаются мгновенно? Логические вентили пропускают сигнал через себя мгновенно? Классический АЛУ — обычное сложение двух чисел — это логическая схема в которой сигнал на выходе появится через некоторое время после того как поданы на вход операнды. НЕ РАНЬШЕ. И если частота тактов будет больше, процессор будет просто простаивать все то время пока сигнал не пройдет все АЛУ от входа до выхода.
–1
stoune #
Читайте моё замечание от линиях задержки в конце. Но это не есть главным ограничителем частоты, по крайней мере пока. Если делать блоки локализироваными без длинных линий, то в пределах этого блока существенных проблем не возникает. Дальше нужно синхронизировать блоки. Для этого ставят схемы синхронизации, в самом простом случае регистр защёлка.
Если бы проблема была бы исключительно в линиях задержек то поднятие частоты не давало бы ничего, так что вы сами себе отрицаете, а ведь рост производительности есть. Но отчего-то оверлокерам нужен жидкий азот, чтобы получить большую частоту. Значит проблема с отводимой мощностью.
Ну и перечитайте статьи интел и прекратите нести чушь.
–1
stoune #
Опечатался «Ничего в процесоре не синхронизированного с тактами генератора не происходит(за исключением советских асинхронных архитектур, которые канули в лету).»
+2
TechThink #
Странно… Минусов вам так и не налепили…

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

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

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

Так первичны абслютные времянки, а не такты…
0
stoune #
Боюсь у нас приципиальное расхождение в понимании. Вся существующая серийная техника синхронная. Она тактируется частотой тактового генератора(если упрощённо, потому что ещё есть делители и множители). Ничего несинхронизированого с тактами не происходит, точнее происходят какие-то переходные процессы, но фиксируется конечное состояние именно в момент тактирования, чаще всего по фронту, иногда по спаду, или по тому и по тому.
Допустим что вы правы и транзистор вносит задержку в распространении сигнала на один такт.
Теперь допустив что для схемы есть два пути для прохождения сигнала, один через 5 транзисторов, другой через 3. Выход результата нужно как-то синхронизировать, что ж нет проблем мы тактируем регистр защелку чтобы он открыл запись условно для пути 1 не третьем такте, для другого на 5-ом и условно на 5-ом выпустил результат. Но вот чего вы не понимаете, так того что вся схема работает паралельно. Это конвейер который каждый такт даст что-то на выход, пусть выход и будет холостой. На пятом такте специальная сигнальна линия выдаст единицу как сигнал что результат готов. Это в самом примитивном и сильно упрощённом виде. Потому время иссполняют инструкции измеряют в тактах.
Дальше идём от теории к практике, частота переключения транзистора
en.wikipedia.org/wiki/Field-effect_transistor
A gate length of 1 µm limits the upper frequency to about 5 GHz, 0.2 µm to about 30 GHz.

Давайте вспомним что у интела техпроцес на 2011- был уже 22 нано метра, download.intel.com/newsroom/kits/22nm/pdfs/22nm-Details_Presentation.pdf При текущей частоте в 5 ГГЦ, можно переключить одновременно не менее 5 транзисторов, насколько помню курс электроники одна ячейка хранения данных статической памяти строится на 3-х транзисторах (а в реальности я уверен переключить можно даже больше транзисторов, так как рабочее напряжение у интел ниже, к сожалению Интел не привела значений маштаба графиков), а ведь сейчас тех процесс меньше, и рабочая частота ниже(3,4ГГц максимум обычно). Я мог бы приводить более детальные формулы, но честно говоря не вижу смысла тратить время, на повторение университетских учебников электроники и микропроцессорной техники. Чтобы устранить задержку сигнала интел встраивает также синхронизирующие схемы, это уже другая история.
Потому задержки времени на прохождение сигнала в пределах одного транзистора всё еще недостаточно существенны в пределах существующих частот(как минимум до 5ГГц).

Идём дальше. Университетский курс цифровой электроники en.wikipedia.org/wiki/CMOS
Скролим к секции Power: switching and leakage. Charging and discharging of load capacitances.
Берём формулу, подставляем пусть даже несколько сот миллионов активных транзисторов(а в современном чипе их милиарды) и думаем как отвести эти десятки ватов тепла с площади несколько десятков миллиметров квадратных. Видим что зависимость от частоты линейная. Как Интел с этим борется. Понижает частоту, понижает рабочее напряжение(очень важно, потому что зависимость от напряжения квадратичная), а также уменьшает альфа, коэффициент задействованы транзисторов через отключение работающих блоков(это в статьях интел о тёмном кремнии). Потолок который научились отводить в воздушном охлаждении примерно 150 Ват, при очень мощной турбине и радиаторе. А мы все ведь хоти очень тихий ПК, который умещается в ладони и чтобы работал от батарейки целый день? Какой здесь выход у производителей?
Повышение частоты даёт линейное повышение потребления энергии.
Та же статья от Интел о 22 нм техпроцесе:
While higher frequency is great for improving CPU performance, it is not always the best choice. For example, GPUs tend to rely on a huge number of more efficient transistors and run about 2-4X slower than a CPU. For scenarios where active power is most critical, the 22nm process can keep the same frequency but lower the operating voltage (e.g. from 1V to 0.8V). Active power falls even faster since P ~ F * V2 and Intel claims 50% less power, so the voltage reduction may be slightly larger in some circumstance. Similarly, transistors could use this headroom to significantly lower leakage power for always-on circuits, instead of changing frequency or active power. While Intel did not cite any specific numbers, it seems likely that an improvement of 1-2 orders of magnitude is realistic given the exponential relationship between leakage and drive currents.


Почему мне не понравилась ваша статья, как вопрос в разделе вопросы она могла бы существовать. Но она написана в стиле разоблачения с неграмотными утверждениями. Тут же нашлось много людей, любителей «теорий заговора» которые заплюсовали и пошла гулять «новая истина» что «кошки разносят чуму». Потом читают студенты и выдают за истину в последней инстанции. Хотя даже достаточно поверхностные статьи википедии о транзисторах могут развеять сомнения.
–3
Hoorsh #
Ни одного упоминания OpenMP, MPI…

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.