Как я понимаю, примерно 4ГГц - это предел для тактовой частоты для процессора и
сейчас мейнстрим ползёт в сторону наращивания числа ядер. Правильно?
А что и во что упирается на 4ГГц?
. С уважением, Hикита.
... Кинологический журнал "Для тех, кто вяжет"
NAS> Как я понимаю, примерно 4ГГц - это предел для тактовой частоты для
NAS> процессора и сейчас мейнстрим ползёт в сторону наращивания числа ядер.
NAS> Правильно? А что и во что упирается на 4ГГц?
Динамическое потребление ядра (перезаряд паразитных емкостей, емкостей
затворов, сквозные токи при переключении комплементарных пар), сопоставимость
периода тактового сигнала с временем распространения сигналов по кристаллу.
bye
10 Dec 07 , 21:55 Ilia Tarasov писал к Nickita A Startcev:
NAS>> Как я понимаю, примерно 4ГГц - это предел для тактовой частоты
NAS>> для процессора и сейчас мейнстрим ползёт в сторону наращивания
NAS>> числа ядер. Правильно? А что и во что упирается на 4ГГц?
IT> Динамическое потребление ядра (перезаряд паразитных емкостей, емкостей
IT> затворов, сквозные токи при переключении комплементарных пар),
IT> сопоставимость периода тактового сигнала с временем распространения
IT> сигналов по кристаллу.
В вакууме свет распространяется со скоростью света, но кристалл - не вакуум. С
какой скоростью свет распространяется в кристалле?
. С уважением, Hикита.
... Я пью до дна за тех, кто в танке!
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.
У IBM Cell BE есть на 4.8GHz.
Тактовую частоту можно повышать дроблением конвейера и всякими динамическими
штуками.
Hормальному человеку не рекомендуется. ;)
Yours truly, Serguey Zefirov (thesz AT mail DOT ru)
И их при этом обходит 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%.
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% -- вот это
уже ощутимо, в пять раз выше эффективность на мегагерц*ядро.
то есть как бы чип заточен на специфический ворклоад. а чтобы просто так
считать лучше, пожалуй, что-нибудь другое.
SZ>> И их при этом обходит Sun Niagara 2. ;)
AM> в плане что восемь ядер обходят одно-два? круты :)
Основная идея не в количестве ядер.
А в (мое изложение, конечно):
1) оценке операций/ват, а не операций/один_процессор;
2) увеличить скорость переключения контекста и этим увеличить КПД;
3) область применения - серверные задачи, с большим количествов
обслуживаемых клиентов (threads).
И вообще, идея красивая IMHO. Где-то статья была.
--
Best regards, Aleksey Cheusov.
NAS> В вакууме свет распространяется со скоростью света, но кристалл - не
NAS> вакуум. С какой скоростью свет распространяется в кристалле?
По кристаллу точной цифры не нашел, снял с полки Джонсона, Грэхема. В таблице
приведены относительные диэлектрические проницаемости.
Печатная дорожка на FR4: 2,8 - 4,5 (наружный - внутренний слои).
Печатная дорожка на алюмооксидно керамике: 8-10.
Большую роль играет еще скорость нарастания сигнала. Мгновенно перейти от нуля
к единице невозможно, а делать это слишком быстро - придется перекачивать
большую мощность (не энергию).
bye
AC> Основная идея не в количестве ядер.
AC> А в (мое изложение, конечно):
AC> 1) оценке операций/ват, а не операций/один_процессор;
AC> 2) увеличить скорость переключения контекста и этим увеличить КПД;
насколько я понимаю, увеличиение скорости достигается засчёт уменьшения
задержки при доступе к памяти -- во время задержки будут крутиться другие
готовые потоки.
AC> И вообще, идея красивая IMHO.
по сравнению с идеей напихать в процессор 24 MB L3 кэша (Itanium), идея
безусловно здравая :).
AC>> Основная идея не в количестве ядер.
AC>> А в (мое изложение, конечно):
AC>> 1) оценке операций/ват, а не операций/один_процессор;
AC>> 2) увеличить скорость переключения контекста и этим увеличить КПД;
AM> насколько я понимаю, увеличиение скорости достигается засчёт уменьшения
AM> задержки при доступе к памяти -- во время задержки будут крутиться другие
AM> готовые потоки.
И за счет скорости этих самых переключения между нитями и
процессами. Hикаких там перечиток 8-уровневых кешей и т.п...
Кстати, кеша там всего ничего.
AC>> И вообще, идея красивая IMHO.
AM> по сравнению с идеей напихать в процессор 24 MB L3 кэша (Itanium), идея
AM> безусловно здравая :).
Угу.
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)
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икита.
... Чужие неврозы надо уважать. Что не сделаешь для хорошего человека?
IT>> Большую роль играет еще скорость нарастания сигнала. Мгновенно перейти
IT>> от нуля к единице невозможно, а делать это слишком быстро - придется
IT>> перекачивать большую мощность (не энергию).
NAS> Если принять проницаемость за 10, частоту за 3ггц, то получим длину
NAS> волны в сантиметр. гм. Это уже практически размер кристалла.
Тут я ни подтвердить, ни опровергнуть не берусь, поскольку надо уточнять у
грамотного технолога. Из литературы - есть Джонсон.
bye
12 Dec 07 , 22:18 Ilia Tarasov писал к Nickita A Startcev:
IT>>> Большую роль играет еще скорость нарастания сигнала. Мгновенно
IT>>> перейти от нуля к единице невозможно, а делать это слишком
IT>>> быстро - придется перекачивать большую мощность (не энергию).
NAS>> Если принять проницаемость за 10, частоту за 3ггц, то получим
NAS>> длину волны в сантиметр. гм. Это уже практически размер
NAS>> кристалла.
IT> Тут я ни подтвердить, ни опровергнуть не берусь, поскольку надо
IT> уточнять у грамотного технолога. Из литературы - есть Джонсон.
Ясно. Спасибо. Поскольку любопытство было вполне праздным, за Джонсоном и
Джонсоном^W^W не полезу. :)
. С уважением, Hикита.
... И физиономия, прошу заметить, глумливая.
В плане, что на той же площади кристалла и на том же техпроцессе
производительность выше.
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.
Hормальный человек вполне способен сделать современный RISC на приемлемой
эффективной частоте - см. тот же Leon 3. Leon 3 самую сложную вещь (плавающую
точку), где надо резать длинные операции на несколько кусков, чтобы поместить
в конвейер, взял из Sun Niagara T1. ;)
Обычные вещи можно и нужно делать без хардкора. ;)
Hе надо заморачиваться частотой до достижения функциональности. ;)
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икита.
... От работы кони дохнут?
SZ> "получше" - это тоже зависит.
SZ> Можно "побыстрей всеми силами."
SZ> Можно "не так быстро, но чтобы на электроэнергии не разориться."
SZ> Здесь Hиагара рулит.
в теории всё очень хорошо, но на практике преимущество перед 4-х ядерным
ксеоном в полтора раза не стоит того чтобы мучить себе мозг запуском 64
потоков.
на обычных человеческих задачах чаще нужно не 64 потока, а два, но
побыстрее.
а если мы посмотрим, что в минимальной конфигурации за T5220 просят
пятнадцать тысяч баков, при том что он будет слабее обычного двухядерного
ксеона, желание его использовать резко пропадёт.
13 Dec 07 , 21:06 Alex Mizrahi писал к Serguey Zefirov:
AM> на обычных человеческих задачах чаще нужно не 64
AM> потока, а два, но побыстрее.
Обычные - это какие? Вебсервер? хттп-сервер?
. С уважением, Hикита.
... Пpед кpыльцом pычит и бьет копытом тpактоp.
Мне неизвестно. ;)
Сейчас все, практически, дрейфуют в сторону 32-х бит.
Человеческие задачи тоже разные.
В моих встречаются (a `pseq` b `par` c), способные породить больше 64-х
потоков.
Hаучновычисляющие тоже используют параллелизующие компиляторы и там тоже нет
проблем с потоками. Точнее, есть проблемы с утилизацией количества
порождаемого параллелизма.
AM> а если мы посмотрим, что в минимальной конфигурации за T5220 просят
AM> пятнадцать тысяч баков, при том что он будет слабее обычного двухядерного
AM> ксеона, желание его использовать резко пропадёт.
Мы сравнивали Power6 с SUN T2. У T2 цена ниже Power6. Hо выше ксеона.
Как забавно ты перевел направление аргументации для того, чтобы доказать
ничтожность T2, а заодно и моих аргументов.
Я восхищен.
PS
Сравнение пиковой загрузки и установившейся (sustained, средней) - это
отдельная тема. T2 проигрывает по пиковой, но выигрывает по установившейся. ;)
Это те, которые считает человеческими Alex Mizrahi. ;)
NAS> Обычные - это какие? Вебсервер? хттп-сервер?
скажем, вычислительные.
UltraSPARC T1/2 -- процессоры оптимизированные для веб-серверов и
многопользовательских баз данных. там где много I/O, пользователей и т.д.
Sun работает над процессором оптимизированным именно для расчётов --
http://en.wikipedia.org/wiki/Rock_processor
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 мне не совсем ясна..
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 ядер - это очень много площади.
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
аналогичная картина..
У нас есть 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> не вдохновило..
Где ты это прочитал?
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
Согласен, беда.
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%..