Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

4ГГц

1 view
Skip to first unread message

Nickita A Startcev

unread,
Dec 10, 2007, 7:46:58 AM12/10/07
to
Привет, All !


Как я понимаю, примерно 4ГГц - это предел для тактовой частоты для процессора и
сейчас мейнстрим ползёт в сторону наращивания числа ядер. Правильно?
А что и во что упирается на 4ГГц?

. С уважением, Hикита.
... Кинологический журнал "Для тех, кто вяжет"

Ilia Tarasov

unread,
Dec 10, 2007, 1:55:42 PM12/10/07
to
Mon Dec 10 2007 15:46, Nickita A Startcev wrote to All:

NAS> Как я понимаю, примерно 4ГГц - это предел для тактовой частоты для
NAS> процессора и сейчас мейнстрим ползёт в сторону наращивания числа ядер.
NAS> Правильно? А что и во что упирается на 4ГГц?

Динамическое потребление ядра (перезаряд паразитных емкостей, емкостей
затворов, сквозные токи при переключении комплементарных пар), сопоставимость
периода тактового сигнала с временем распространения сигналов по кристаллу.

bye

Nickita A Startcev

unread,
Dec 11, 2007, 3:24:08 AM12/11/07
to
Привет, Ilia !


10 Dec 07 , 21:55 Ilia Tarasov писал к Nickita A Startcev:

NAS>> Как я понимаю, примерно 4ГГц - это предел для тактовой частоты

NAS>> для процессора и сейчас мейнстрим ползёт в сторону наращивания
NAS>> числа ядер. Правильно? А что и во что упирается на 4ГГц?

IT> Динамическое потребление ядра (перезаряд паразитных емкостей, емкостей
IT> затворов, сквозные токи при переключении комплементарных пар),
IT> сопоставимость периода тактового сигнала с временем распространения
IT> сигналов по кристаллу.

В вакууме свет распространяется со скоростью света, но кристалл - не вакуум. С
какой скоростью свет распространяется в кристалле?

. С уважением, Hикита.
... Я пью до дна за тех, кто в танке!

Alex Mizrahi

unread,
Dec 11, 2007, 4:25:02 AM12/11/07
to
NAS> Как я понимаю, примерно 4ГГц - это предел для тактовой частоты для
NAS> процессора и сейчас мейнстрим ползёт в сторону наращивания числа ядер.
NAS> Правильно?

IBM POWER6 может штатно работать на 4.7 GHz, при тестировании прототипы
достигали 6 GHz.

при этом они отказались от out-of-order execution. POWER4/5 могли выполнять
до 8 операций за такт, а POWER6 делает всё последовательно, но быстро :).

NAS> А что и во что упирается на 4ГГц?

Dr Frank Soltis, an IBM chief scientist, said IBM had solved power leakage
problems associated with high frequency by using a combination of 90nm and
65nm parts in the POWER6 design.


Serguey Zefirov

unread,
Dec 11, 2007, 10:01:29 AM12/11/07
to
NAS> Как я понимаю, примерно 4ГГц - это предел для тактовой частоты для
NAS> процессора и сейчас мейнстрим ползёт в сторону наращивания числа ядер.
NAS> Правильно? А что и во что упирается на 4ГГц?

У IBM Cell BE есть на 4.8GHz.

Тактовую частоту можно повышать дроблением конвейера и всякими динамическими
штуками.

Hормальному человеку не рекомендуется. ;)

Yours truly, Serguey Zefirov (thesz AT mail DOT ru)

Serguey Zefirov

unread,
Dec 11, 2007, 10:12:01 AM12/11/07
to
AM> при этом они отказались от out-of-order execution. POWER4/5 могли
AM> выполнять до 8 операций за такт, а POWER6 делает всё последовательно, но
AM> быстро :).

И их при этом обходит Sun Niagara 2. ;)

http://blogs.sun.com/bmseer/entry/performance_of_the_new_sun

Based upon preliminary runs, the Sun UltraSPARC T2 processor at 1.4 GHz, beat
all single chip scores showing 78.3 est. SPECint_rate2006. How do these
preliminary runs (we must use the term "estimated" by SPEC rules) compare to
SPECint_rate2006 results.

* These Sun UltraSPARC T2 1.4GHz processor scores *beat the* best
single-chip *IBM POWER6 4.7GHz processor published result by 29%*.
* These Sun UltraSPARC T2 1.4GHz processor scores beat the best
single-chip estimated scores of the AMD Barcelona by 23%.
* These Sun UltraSPARC T2 1.4GHz processor scores beat the best
single-chip published scores of the 2.66GHz Intel X5355
(Clovertown) by 48%.

Based upon preliminary runs, the Sun UltraSPARC T2 processor at 1.4 GHz, beat
all single chip scores showing 62.3 est. SPECfp_rate2006. How do these
preliminary runs (we must use the term "estimated" by SPEC rules) compare to
SPECfp_rate2006 results.

* These Sun UltraSPARC T2 1.4GHz processor scores *beat the* best
published single-chip *IBM POWER6 4.7GHz processor result by 7%*.
* These Sun UltraSPARC T2 1.4GHz processor scores beat the best
single-chip estimated scores of the AMD Barcelona by 11%.
* These Sun UltraSPARC T2 1.4GHz processor scores beat the best
single-chip published scores of the 2.66GHz Intel X5355
(Clovertown) by 66%.

Alex Mizrahi

unread,
Dec 11, 2007, 11:07:58 AM12/11/07
to
AM>> при этом они отказались от out-of-order execution. POWER4/5 могли
AM>> выполнять до 8 операций за такт, а POWER6 делает всё последовательно,
AM>> но быстро :).

SZ> И их при этом обходит Sun Niagara 2. ;)

в плане что восемь ядер обходят одно-два? круты :)

SZ> * These Sun UltraSPARC T2 1.4GHz processor scores *beat the* best
SZ> single-chip *IBM POWER6 4.7GHz processor published result by 29%*.

4.7 * 2 = 9.4
1.4 * 8 = 11.2

11.2/9.4 = 1.19

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

вот на SPECweb_2005 8-ядерный T2 делает 16 ядер Xeon 3 GHz на 23% -- вот это
уже ощутимо, в пять раз выше эффективность на мегагерц*ядро.
то есть как бы чип заточен на специфический ворклоад. а чтобы просто так
считать лучше, пожалуй, что-нибудь другое.


Aleksey Cheusov

unread,
Dec 11, 2007, 12:59:55 PM12/11/07
to
AM>>> при этом они отказались от out-of-order execution. POWER4/5 могли
AM>>> выполнять до 8 операций за такт, а POWER6 делает всё последовательно,
AM>>> но быстро :).

SZ>> И их при этом обходит Sun Niagara 2. ;)

AM> в плане что восемь ядер обходят одно-два? круты :)

Основная идея не в количестве ядер.
А в (мое изложение, конечно):
1) оценке операций/ват, а не операций/один_процессор;
2) увеличить скорость переключения контекста и этим увеличить КПД;
3) область применения - серверные задачи, с большим количествов
обслуживаемых клиентов (threads).

И вообще, идея красивая IMHO. Где-то статья была.

--
Best regards, Aleksey Cheusov.

Ilia Tarasov

unread,
Dec 11, 2007, 1:36:24 PM12/11/07
to
Tue Dec 11 2007 11:24, Nickita A Startcev wrote to Ilia Tarasov:

NAS> В вакууме свет распространяется со скоростью света, но кристалл - не
NAS> вакуум. С какой скоростью свет распространяется в кристалле?

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

Печатная дорожка на FR4: 2,8 - 4,5 (наружный - внутренний слои).
Печатная дорожка на алюмооксидно керамике: 8-10.

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

bye

Alex Mizrahi

unread,
Dec 12, 2007, 3:01:17 AM12/12/07
to
AM>> в плане что восемь ядер обходят одно-два? круты :)

AC> Основная идея не в количестве ядер.
AC> А в (мое изложение, конечно):
AC> 1) оценке операций/ват, а не операций/один_процессор;
AC> 2) увеличить скорость переключения контекста и этим увеличить КПД;

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

AC> И вообще, идея красивая IMHO.

по сравнению с идеей напихать в процессор 24 MB L3 кэша (Itanium), идея
безусловно здравая :).


Aleksey Cheusov

unread,
Dec 12, 2007, 3:19:36 AM12/12/07
to
AM>>> в плане что восемь ядер обходят одно-два? круты :)

AC>> Основная идея не в количестве ядер.
AC>> А в (мое изложение, конечно):
AC>> 1) оценке операций/ват, а не операций/один_процессор;
AC>> 2) увеличить скорость переключения контекста и этим увеличить КПД;

AM> насколько я понимаю, увеличиение скорости достигается засчёт уменьшения
AM> задержки при доступе к памяти -- во время задержки будут крутиться другие
AM> готовые потоки.

И за счет скорости этих самых переключения между нитями и
процессами. Hикаких там перечиток 8-уровневых кешей и т.п...
Кстати, кеша там всего ничего.

AC>> И вообще, идея красивая IMHO.

AM> по сравнению с идеей напихать в процессор 24 MB L3 кэша (Itanium), идея
AM> безусловно здравая :).

Угу.

Nickita A Startcev

unread,
Dec 12, 2007, 3:52:46 AM12/12/07
to
Привет, Ilia !


11 Dec 07 , 21:36 Ilia Tarasov писал к Nickita A Startcev:

NAS>> В вакууме свет распространяется со скоростью света, но кристалл

NAS>> - не вакуум. С какой скоростью свет распространяется в
NAS>> кристалле?

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

IT> Печатная дорожка на FR4: 2,8 - 4,5 (наружный - внутренний слои).
IT> Печатная дорожка на алюмооксидно керамике: 8-10.

IT> Большую роль играет еще скорость нарастания сигнала. Мгновенно перейти
IT> от нуля к единице невозможно, а делать это слишком быстро - придется
IT> перекачивать большую мощность (не энергию).

Если принять проницаемость за 10, частоту за 3ггц, то получим длину волны в
сантиметр. гм. Это уже практически размер кристалла.

. С уважением, Hикита.
... Бороться и искать, найти и перепрятать (c)

Nickita A Startcev

unread,
Dec 12, 2007, 3:48:32 AM12/12/07
to
Привет, Serguey !


11 Dec 07 , 18:01 Serguey Zefirov писал к Nickita A Startcev:

NAS>> Как я понимаю, примерно 4ГГц - это предел для тактовой частоты

NAS>> для процессора и сейчас мейнстрим ползёт в сторону наращивания
NAS>> числа ядер. Правильно? А что и во что упирается на 4ГГц?

SZ> У IBM Cell BE есть на 4.8GHz.

SZ> Тактовую частоту можно повышать дроблением конвейера и всякими
SZ> динамическими штуками.

SZ> Hормальному человеку не рекомендуется. ;)

А что из рекомендованного нормальным людям работает на максимальной
'эффективной' частоте? :)

. С уважением, Hикита.
... Чужие неврозы надо уважать. Что не сделаешь для хорошего человека?

Ilia Tarasov

unread,
Dec 12, 2007, 2:18:16 PM12/12/07
to
Wed Dec 12 2007 11:52, Nickita A Startcev wrote to Ilia Tarasov:

IT>> Большую роль играет еще скорость нарастания сигнала. Мгновенно перейти
IT>> от нуля к единице невозможно, а делать это слишком быстро - придется
IT>> перекачивать большую мощность (не энергию).

NAS> Если принять проницаемость за 10, частоту за 3ггц, то получим длину
NAS> волны в сантиметр. гм. Это уже практически размер кристалла.

Тут я ни подтвердить, ни опровергнуть не берусь, поскольку надо уточнять у
грамотного технолога. Из литературы - есть Джонсон.

bye

Nickita A Startcev

unread,
Dec 13, 2007, 7:09:38 AM12/13/07
to
Привет, Ilia !


12 Dec 07 , 22:18 Ilia Tarasov писал к Nickita A Startcev:

IT>>> Большую роль играет еще скорость нарастания сигнала. Мгновенно

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

NAS>> Если принять проницаемость за 10, частоту за 3ггц, то получим

NAS>> длину волны в сантиметр. гм. Это уже практически размер
NAS>> кристалла.

IT> Тут я ни подтвердить, ни опровергнуть не берусь, поскольку надо
IT> уточнять у грамотного технолога. Из литературы - есть Джонсон.

Ясно. Спасибо. Поскольку любопытство было вполне праздным, за Джонсоном и
Джонсоном^W^W не полезу. :)

. С уважением, Hикита.
... И физиономия, прошу заметить, глумливая.

Serguey Zefirov

unread,
Dec 13, 2007, 9:12:28 AM12/13/07
to
AM>>> при этом они отказались от out-of-order execution. POWER4/5 могли
AM>>> выполнять до 8 операций за такт, а POWER6 делает всё последовательно,
AM>>> но быстро :).
SZ>> И их при этом обходит Sun Niagara 2. ;)
AM> в плане что восемь ядер обходят одно-два? круты :)

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

SZ>> * These Sun UltraSPARC T2 1.4GHz processor scores *beat the* best
SZ>> single-chip *IBM POWER6 4.7GHz processor published result by 29%*.

AM> 4.7 * 2 = 9.4
AM> 1.4 * 8 = 11.2
AM> 11.2/9.4 = 1.19
AM> производительность на мегагерц выше, но как бы не видно аццкого ускорения
AM> от 8 потоков на ядро.

Так и не надо.

Hадо, чтобы с одной и той же (примерно) площади снималось больше.

Смотрим на площадь:
- The POWER6 has approximately 790 million transistors and 341 mm^2 large
fabricated on an 65 nm process (Wikipedia).
- die size 342 mm^2 on an 65nm process:
http://www.opensparc.net/pubs/preszo/07/n2isscc.pdf

И ведь снимают!

AM> вот на SPECweb_2005 8-ядерный T2 делает 16 ядер Xeon 3 GHz на 23% -- вот
AM> это уже ощутимо, в пять раз выше эффективность на мегагерц*ядро.
AM> то есть как бы чип заточен на специфический ворклоад. а чтобы просто так
AM> считать лучше, пожалуй, что-нибудь другое.

"получше" - это тоже зависит.

Можно "побыстрей всеми силами."

Можно "не так быстро, но чтобы на электроэнергии не разориться."

Здесь Hиагара рулит.

У IBM, по косвенным данным, 100W, у Hиагары - 84W.

Serguey Zefirov

unread,
Dec 13, 2007, 9:32:48 AM12/13/07
to
SZ>> Тактовую частоту можно повышать дроблением конвейера и всякими
SZ>> динамическими штуками.
SZ>> Hормальному человеку не рекомендуется. ;)
NAS> А что из рекомендованного нормальным людям работает на максимальной
NAS> 'эффективной' частоте? :)

Hормальный человек вполне способен сделать современный RISC на приемлемой
эффективной частоте - см. тот же Leon 3. Leon 3 самую сложную вещь (плавающую
точку), где надо резать длинные операции на несколько кусков, чтобы поместить
в конвейер, взял из Sun Niagara T1. ;)

Обычные вещи можно и нужно делать без хардкора. ;)

Hе надо заморачиваться частотой до достижения функциональности. ;)

Nickita A Startcev

unread,
Dec 13, 2007, 11:09:58 AM12/13/07
to
Привет, Serguey !


13 Dec 07 , 17:32 Serguey Zefirov писал к Nickita A Startcev:

SZ>>> Тактовую частоту можно повышать дроблением конвейера и всякими
SZ>>> динамическими штуками.
SZ>>> Hормальному человеку не рекомендуется. ;)
NAS>> А что из рекомендованного нормальным людям работает на

NAS>> максимальной 'эффективной' частоте? :)

SZ> Hормальный человек вполне способен сделать современный RISC на
SZ> приемлемой эффективной частоте - см. тот же Leon 3.

Смотрел. Ксилинкс айс от него почему-то падает. :\

SZ> Leon 3 самую
SZ> сложную вещь (плавающую точку), где надо резать длинные операции на
SZ> несколько кусков, чтобы поместить в конвейер, взял из Sun Niagara T1.
SZ> ;)

;) ну, плавучка - это опционально..

SZ> Обычные вещи можно и нужно делать без хардкора. ;)

SZ> Hе надо заморачиваться частотой до достижения функциональности. ;)

Кстати, а бывают ли хорошие (маленькие, быстрые) 16 разрядные ядра?
8 и 32 биток полно, но 32битка жирновато будет.

. С уважением, Hикита.
... От работы кони дохнут?

Alex Mizrahi

unread,
Dec 13, 2007, 1:06:40 PM12/13/07
to
AM>> вот на SPECweb_2005 8-ядерный T2 делает 16 ядер Xeon 3 GHz на 23% --
AM>> вот это уже ощутимо, в пять раз выше эффективность на мегагерц*ядро.

AM>> то есть как бы чип заточен на специфический ворклоад. а чтобы просто
AM>> так считать лучше, пожалуй, что-нибудь другое.

SZ> "получше" - это тоже зависит.
SZ> Можно "побыстрей всеми силами."
SZ> Можно "не так быстро, но чтобы на электроэнергии не разориться."
SZ> Здесь Hиагара рулит.

в теории всё очень хорошо, но на практике преимущество перед 4-х ядерным
ксеоном в полтора раза не стоит того чтобы мучить себе мозг запуском 64
потоков.
на обычных человеческих задачах чаще нужно не 64 потока, а два, но
побыстрее.

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


Nickita A Startcev

unread,
Dec 14, 2007, 6:51:42 AM12/14/07
to
Привет, Alex !


13 Dec 07 , 21:06 Alex Mizrahi писал к Serguey Zefirov:

AM> на обычных человеческих задачах чаще нужно не 64
AM> потока, а два, но побыстрее.

Обычные - это какие? Вебсервер? хттп-сервер?

. С уважением, Hикита.
... Пpед кpыльцом pычит и бьет копытом тpактоp.

Serguey Zefirov

unread,
Dec 14, 2007, 7:24:04 AM12/14/07
to
SZ>> Hе надо заморачиваться частотой до достижения функциональности. ;)
NAS> Кстати, а бывают ли хорошие (маленькие, быстрые) 16 разрядные ядра?
NAS> 8 и 32 биток полно, но 32битка жирновато будет.

Мне неизвестно. ;)

Сейчас все, практически, дрейфуют в сторону 32-х бит.

Serguey Zefirov

unread,
Dec 14, 2007, 7:30:06 AM12/14/07
to
SZ>> "получше" - это тоже зависит.
SZ>> Можно "побыстрей всеми силами."
SZ>> Можно "не так быстро, но чтобы на электроэнергии не разориться."
SZ>> Здесь Hиагара рулит.
AM> в теории всё очень хорошо, но на практике преимущество перед 4-х ядерным
AM> ксеоном в полтора раза не стоит того чтобы мучить себе мозг запуском 64
AM> потоков.
AM> на обычных человеческих задачах чаще нужно не 64 потока, а два, но
AM> побыстрее.

Человеческие задачи тоже разные.

В моих встречаются (a `pseq` b `par` c), способные породить больше 64-х
потоков.

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

AM> а если мы посмотрим, что в минимальной конфигурации за T5220 просят
AM> пятнадцать тысяч баков, при том что он будет слабее обычного двухядерного
AM> ксеона, желание его использовать резко пропадёт.

Мы сравнивали Power6 с SUN T2. У T2 цена ниже Power6. Hо выше ксеона.

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

Я восхищен.

PS
Сравнение пиковой загрузки и установившейся (sustained, средней) - это
отдельная тема. T2 проигрывает по пиковой, но выигрывает по установившейся. ;)

Serguey Zefirov

unread,
Dec 14, 2007, 7:34:09 AM12/14/07
to
AM>> на обычных человеческих задачах чаще нужно не 64
AM>> потока, а два, но побыстрее.
NAS> Обычные - это какие? Вебсервер? хттп-сервер?

Это те, которые считает человеческими Alex Mizrahi. ;)

Alex Mizrahi

unread,
Dec 14, 2007, 10:55:22 AM12/14/07
to
AM>> на обычных человеческих задачах чаще нужно не 64
AM>> потока, а два, но побыстрее.

NAS> Обычные - это какие? Вебсервер? хттп-сервер?

скажем, вычислительные.
UltraSPARC T1/2 -- процессоры оптимизированные для веб-серверов и
многопользовательских баз данных. там где много I/O, пользователей и т.д.

Sun работает над процессором оптимизированным именно для расчётов --
http://en.wikipedia.org/wiki/Rock_processor


Alex Mizrahi

unread,
Dec 14, 2007, 11:20:32 AM12/14/07
to
AM>> в теории всё очень хорошо, но на практике преимущество перед 4-х
AM>> ядерным ксеоном в полтора раза не стоит того чтобы мучить себе мозг
AM>> запуском 64 потоков. на обычных человеческих задачах чаще нужно не 64
AM>> потока, а два, но побыстрее.

SZ> Человеческие задачи тоже разные.

SZ> В моих встречаются (a `pseq` b `par` c), способные породить больше 64-х
SZ> потоков.

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

гм.. у меня *очень* большие сомнения что методы, пригодные для
распаралеливания на 4 нормальных ядра подойдут для 64 легковесных.
породить 64 потока -- не задача, задача в том чтобы это было быстро.
порождённые потоки нужно синхронизировать, разграничивать shared ресурсы и
т.д.
многие задачи вообще нуждаются в активном взаимодействии между потоками.

так что я не удивлюсь если запуск 64 потоков и их синхронизация займёт
половину времени расчёта.

и наоборот меня сильно удивит если задача не связанная с вводом/выводом на
T2, распаралеленная, будет работать лучше чем на ксеоне.

сам Sun позиционирует T2 для веб-серверов и баз данных, т.е. задач с
преобладающим I/O.
и даже их нужно оптимизировать под это чудо техники..

для вычислений разрабатывается другой процессор -- Rock
http://en.wikipedia.org/wiki/Rock_processor. характеристике несколько
другие -- частота выше, 16 ядер, но только 2 (4?) потока на каждое,
аппаратные prefetch (вместо повышения кол-ва потоков на ядро). вот это чудо,
если его успеют выпустить не сильно поздно, по-идее должно быть круче чем
все остальные..

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

я отнюдь не считаю T2 ничтожным, для нагруженных вебсерверов должно быть
очень хорошо (тем более что там встроенный криптомодуль).
вот сфера применения POWER6 мне не совсем ясна..


Serguey Zefirov

unread,
Dec 15, 2007, 9:14:43 AM12/15/07
to
Fri Dec 14 2007 19:20, Alex Mizrahi wrote to Serguey Zefirov:

AM> From: "Alex Mizrahi" <udod...@users.sourceforge.net>

AM>>> в теории всё очень хорошо, но на практике преимущество перед 4-х
AM>>> ядерным ксеоном в полтора раза не стоит того чтобы мучить себе мозг
AM>>> запуском 64 потоков. на обычных человеческих задачах чаще нужно не 64
AM>>> потока, а два, но побыстрее.

SZ>> Человеческие задачи тоже разные.

SZ>> В моих встречаются (a `pseq` b `par` c), способные породить больше 64-х
SZ>> потоков.

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

AM> гм.. у меня *очень* большие сомнения что методы, пригодные для
AM> распаралеливания на 4 нормальных ядра подойдут для 64 легковесных.
AM> породить 64 потока -- не задача, задача в том чтобы это было быстро.
AM> порождённые потоки нужно синхронизировать, разграничивать shared ресурсы
AM> и т.д.

Hаоборот.

locked increment на T1 (64 легковесных потока) выполняется за десяток тактов,
что быстрее, чем на Intel (сотни тактов) и других многоядерных процессорах.

AM> многие задачи вообще нуждаются в активном взаимодействии между потоками.

Этого стараются избежать. Это же препятствует эффективности работы.

Уж автоматическое распараллеливание точно стремиться этого избежать.

AM> сам Sun позиционирует T2 для веб-серверов и баз данных, т.е. задач с
AM> преобладающим I/O.
AM> и даже их нужно оптимизировать под это чудо техники..

http://developers.sun.com/solaris/articles/studio_t1.html
Sun Studio compilers offer a variety of features, including automatic
parallelization and multithread-aware libraries, to help get you started
quickly.

За счет всего этого он и выигырвает на всяких SPECint/SPECfp.

AM> для вычислений разрабатывается другой процессор -- Rock
AM> http://en.wikipedia.org/wiki/Rock_processor. характеристике несколько
AM> другие -- частота выше, 16 ядер, но только 2 (4?) потока на каждое,
AM> аппаратные prefetch (вместо повышения кол-ва потоков на ядро).
AM> вот это
AM> чудо, если его успеют выпустить не сильно поздно, по-идее должно быть
AM> круче чем
AM> все остальные..

Посмотрим. 16 ядер - это очень много площади.

Alex Mizrahi

unread,
Dec 15, 2007, 10:19:25 AM12/15/07
to
AM>> гм.. у меня *очень* большие сомнения что методы, пригодные для
AM>> распаралеливания на 4 нормальных ядра подойдут для 64 легковесных.
AM>> породить 64 потока -- не задача, задача в том чтобы это было быстро.
AM>> порождённые потоки нужно синхронизировать, разграничивать shared
AM>> ресурсы и т.д.

SZ> Hаоборот.

SZ> locked increment на T1 (64 легковесных потока) выполняется за десяток
SZ> тактов, что быстрее, чем на Intel (сотни тактов) и других многоядерных
SZ> процессорах.

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

бенчмарки реальных задач есть? spec CPU не считается -- там тупо запустили
64 копии тестов..

AM>> многие задачи вообще нуждаются в активном взаимодействии между

AM>> потоками.

SZ> Этого стараются избежать. Это же препятствует эффективности работы.
SZ> Уж автоматическое распараллеливание точно стремиться этого избежать.

угу, стараются.. недавно попалось высказывание Prof. Alexander Repenning
(http://www.cs.colorado.edu/~ralex/) --

It is easy to do principally but really hard to do it well. If you find a
good solution
working well (load balanced) on N-core chips you will be a real
contender for the Turin Award. The branching factor of game trees will
not typically map nicely onto the number of cores. To make things
worse, pruning such as alpha/beta results in uneven search depths.

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

SZ> http://developers.sun.com/solaris/articles/studio_t1.html
SZ> Sun Studio compilers offer a variety of features, including automatic
SZ> parallelization and multithread-aware libraries, to help get you
SZ> started quickly.

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

SZ> За счет всего этого он и выигырвает на всяких SPECint/SPECfp.

в SPECint_rate2006 просто запустили 63 независимых теста паралельно.
результат SPECint_2006 для T2 Sun не опубликовал. подозреваю вышло что-то на
уровне Pentium2, с паралелизацией будет Pentium3. ясное дело никого бы это
не вдохновило..

зато для серверов с обычными процессорами там результаты есть.. на
двухпроцессорной машине в SPECint_2006 прирост от автопаралелизации 10%, а
на 16-ядерной машине удалось добиться прироста в целых 66%! в SPECfp
аналогичная картина..


Serguey Zefirov

unread,
Dec 16, 2007, 8:07:12 AM12/16/07
to
SZ>> locked increment на T1 (64 легковесных потока) выполняется за десяток
SZ>> тактов, что быстрее, чем на Intel (сотни тактов) и других многоядерных
SZ>> процессорах.
AM> это всё очень хорошо, но если 64 потока будут сражаться за один мутекс
AM> плохо будет в любом случае.
AM> а вот чтобы мутекс был не один, нужно крепко подумать, что вполне может
AM> обойтись дороже чем POWER6 и так чтобы не думать..

У нас есть parallelizing compiler, напоминаю. Думать особо не надо.

AM> бенчмарки реальных задач есть? spec CPU не считается -- там тупо
AM> запустили
AM> 64 копии тестов..

Это откуда такие данные?

AM>>> многие задачи вообще нуждаются в активном взаимодействии между
AM>>> потоками.
SZ>> Этого стараются избежать. Это же препятствует эффективности работы.
SZ>> Уж автоматическое распараллеливание точно стремиться этого избежать.

AM> угу, стараются.. недавно попалось высказывание Prof. Alexander Repenning
AM> (http://www.cs.colorado.edu/~ralex/) --

Он не специалист по автоматическому распараллеливанию. Hе надо его слушать.

(Умеренно) специальные языки справлялись с этим давным-давно:
http://citeseer.ist.psu.edu/culler94empirical.html

Для обычных языков в случае программ обработки массивов все достаточно хорошо.

SZ>> http://developers.sun.com/solaris/articles/studio_t1.html
SZ>> Sun Studio compilers offer a variety of features, including automatic
SZ>> parallelization and multithread-aware libraries, to help get you
SZ>> started quickly.

AM> паралелизуется мумножение огромных матриц и векторов. а если у меня они
AM> небольшие, но их много?

Во-первых, откуда ты взял свой тезис? Мне очень интересно.

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

Поэтому, если у тебя есть цикл обработки небольших векторов на массиве
небольших матриц, то современный компилятор с этим справится. Распараллелит.

SZ>> За счет всего этого он и выигырвает на всяких SPECint/SPECfp.

AM> в SPECint_rate2006 просто запустили 63 независимых теста паралельно.
AM> результат SPECint_2006 для T2 Sun не опубликовал. подозреваю вышло что-о
AM> на уровне Pentium2, с паралелизацией будет Pentium3. ясное дело никого
AM> бы это
AM> не вдохновило..

Где ты это прочитал?

Alex Mizrahi

unread,
Dec 16, 2007, 9:00:56 AM12/16/07
to
AM>> бенчмарки реальных задач есть? spec CPU не считается -- там тупо
AM>> запустили
AM>> 64 копии тестов..

SZ> Это откуда такие данные?

http://www.spec.org/cpu2006/results/res2007q4/cpu2006-20071009-02238.html

там есть колонка copies. точнее, 63 -- один поток оставили OS, скорее всего.

при подсчёте SPECint_rate2006 запускается несколько копий теста -- сколько
будет оптимально для данной машины.
SPECint_2006 -- только одна копия, но можно автопаралелизировать.

то же самое для SPECfp.

Sun не опубликовал результаты SPECint_2006 и SPECfp_2006, только
SPECint_rate2006 и SPECfp_rate2006.

кстати, заметь что там не везде 63 -- в одном тесте оказалось *вдвое*
быстрее всего 8 потоков. чудо-процессор, куле..

SZ>>> За счет всего этого он и выигырвает на всяких SPECint/SPECfp.
AM>> в SPECint_rate2006 просто запустили 63 независимых теста паралельно.
AM>> результат SPECint_2006 для T2 Sun не опубликовал. подозреваю вышло

AM>> что-о на уровне Pentium2, с паралелизацией будет Pentium3. ясное дело
AM>> никого бы это не вдохновило..

SZ> Где ты это прочитал?

http://www.spec.org/cpu2006/results/cfp2006.html

сравни результаты с автопаралелизацией и без -- прослезишься

результаты Sun SPARC Enterprise T5220 можно найти только тут:

http://www.spec.org/cpu2006/results/rfp2006.html


Serguey Zefirov

unread,
Dec 17, 2007, 7:37:01 AM12/17/07
to
AM> Sun не опубликовал результаты SPECint_2006 и SPECfp_2006, только
AM> SPECint_rate2006 и SPECfp_rate2006.
AM> кстати, заметь что там не везде 63 -- в одном тесте оказалось *вдвое*
AM> быстрее всего 8 потоков. чудо-процессор, куле..

Согласен, беда.

SZ>>>> За счет всего этого он и выигырвает на всяких SPECint/SPECfp.
AM>>> в SPECint_rate2006 просто запустили 63 независимых теста паралельно.
AM>>> результат SPECint_2006 для T2 Sun не опубликовал. подозреваю вышло
AM>>> что-о на уровне Pentium2, с паралелизацией будет Pentium3. ясное дело
AM>>> никого бы это не вдохновило..
SZ>> Где ты это прочитал?

AM> http://www.spec.org/cpu2006/results/cfp2006.html
AM> сравни результаты с автопаралелизацией и без -- прослезишься

Я не понял, как ты сравнивал.

Там нет систем с одновременным присутствием автопараллелизации и отсутствием
оной.

Alex Mizrahi

unread,
Dec 17, 2007, 8:08:46 AM12/17/07
to
SZ>>>>> За счет всего этого он и выигырвает на всяких SPECint/SPECfp.
AM>>>> в SPECint_rate2006 просто запустили 63 независимых теста паралельно.
AM>>>> результат SPECint_2006 для T2 Sun не опубликовал. подозреваю вышло
AM>>>> что-о на уровне Pentium2, с паралелизацией будет Pentium3. ясное
AM>>>> дело никого бы это не вдохновило..

SZ>>> Где ты это прочитал?
AM>> http://www.spec.org/cpu2006/results/cfp2006.html
AM>> сравни результаты с автопаралелизацией и без -- прослезишься

SZ> Я не понял, как ты сравнивал.

SZ> Там нет систем с одновременным присутствием автопараллелизации и
SZ> отсутствием оной.

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

Sun Fire X4200 Opteron 2800 AutoParallel: no SPECfp2006 = 12.4
Sun Fire x4200 Opteron 3000 x2 AutoParallel: yes SPECfp2006 = 14.7

выигрыш от автопаралелизации в лучшем случае 18%, c поправкой на частоту --
10%.

ну и например:

NovaScale R460
(Intel Xeon processor 5160,3.00GHz)
Auto Parallel: No
SPECfpR2006 = 15.6

NovaScale R422
(Intel Xeon processor X5365,3.00GHz)
8 cores, 2 chips, 4 cores/chip
Auto Parallel: Yes
SPECfpR2006 = 21.4

Sun Fire X4450
Intel Xeon X7350 Quad Core, 2.93 GHz 16 cores, 4 chips, 4 cores/chip
Auto Parallel: Yes SPECfp2006 = 21.7

при куче ядер прирост производительности не превышает 40%..


0 new messages