URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 73156
[ Назад ]

Исходное сообщение
"Oracle переходит к сокращению числу ядер в следующем поколен..."

Отправлено opennews , 08-Дек-10 13:00 
Компания Oracle изменила (http://www.pcworld.idg.com.au/article/370535/oracle_halve_co.../) стратегию усовершенствования процессоров SPARC, вместо практикуемого другими производителями наращивания числа процессорных ядер, в следующем поколении процессоров Sparc (T4) число ядер будет сокращено в два раза. Все усилия инженеров будут сосредоточены на оптимизации производительности отдельных потоков, так как по результатам исследования именно данная область является слабым звеном присутствующих на рынке CPU Sparc.


Несмотря на то, что число ядер благотворно влияет на производительность систем, задачи в которых разбиваются на множество мелких частей (например, обслуживание web-запросов или online-транзакций), для выпускаемых Oracle программных продуктов, таких как большие СУБД и ERP-приложения, гораздо важнее производительность отдельных потоков. По словам Ларри Эллисона, руководителя Oracle, выпуск Sparc T4 является критичной для компании задачей, в первую оче...

URL: http://www.pcworld.idg.com.au/article/370535/oracle_halve_co.../
Новость: http://www.opennet.me/opennews/art.shtml?num=28919


Содержание

Сообщения в этом обсуждении
"Oracle переходит к сокращению числу ядер в следующем поколен..."
Отправлено Max , 08-Дек-10 13:00 
Надоело Футжикам деньги за SPARC64 отстегивать?

"Oracle переходит к сокращению числу ядер в следующем поколен..."
Отправлено northbear , 08-Дек-10 13:13 
При всем моем неуважении к Oracle, данное решение выглядит более чем разумным. Гнаться за майнстримом (наращиванием количества ядер) заведомо проигрышный вариант. SPARC'у игра на поле х86 ничем не светит. Никаких, даже теоретических шансов на успех в этой игре у SPARC'а нет.

А эффективность в обработке данных будет востребована всегда.  


"Oracle переходит к сокращению числу ядер в следующем поколен..."
Отправлено Толстый , 08-Дек-10 13:23 
Да все правильно, а то надоела эта гонка по количеству ядер. От наращивания ядер выйграют только оптимизированные под многопоточность приложения, в то время как от наращивания производительности отдельных ядер выйгрыш будет во *всех* приложениях.

"Oracle переходит к сокращению числу ядер в следующем поколен..."
Отправлено tipa_admin , 08-Дек-10 14:16 
> Да все правильно, а то надоела эта гонка по количеству ядер.

Да-да, гонка по количеству сокетов гораздо прикольнее.



"Oracle переходит к сокращению числу ядер в следующем поколен..."
Отправлено Denisiuk , 08-Дек-10 14:23 
Может, кто-то помнить рекламу бритв.. там обыгрывался стеб над бритвами с большим количеством лезвий, тогда джилет, кажется 3 лезвия вставили в бритву.. где-то в 90х было дело
так вот, там стебанулись, мол: а теперь мы представляем бритву с 16ю лезвиями! ...а сейчас бритва с 5ю лезвиями - обычное дело О_о
Так вот... сначала 2 ядра - было диковиной, а теперь 16ю никого не удивишь..

"Oracle переходит к сокращению числу ядер в следующем поколен..."
Отправлено user455 , 13-Дек-10 15:44 
немного оффтоп, но самый прикол во всех этих наращивания лезвий - это то, что каждый раз говорят, что их бритвы бреют идеально гладко. но с увеличеним количества лезвий оказывается, что 2-3-4 и т.д. уже не бреют :(

"Oracle переходит к сокращению числу ядер в следующем поколен..."
Отправлено pavlinux , 08-Дек-10 14:59 
> От наращивания ядер выиграют только оптимизированные под многопоточность приложения

Например ядро Linux.

Написали бы, что НИАСИЛИЛИ многоядерность, а то давай отмазки придумывать.


"Oracle переходит к сокращению числу ядер в следующем поколен..."
Отправлено Аноним , 08-Дек-10 15:19 
не тупи. вместе с уменьшением количества ядер - увеличивается объем кэша принадлежаший каждому ядру и потоку. А ты сразу "ниасилили .. ниасилили"..
Это как с включением и выключением HT у интеля - есть задачи на которых HT будет медленее обычного, за счет того что без HT данные и код будут влезать в кэш и не потребуется доп загрузка из памяти (что не дешево - в случае NUMA,  а спарки это NUMA)

"Oracle переходит к сокращению числу ядер в следующем поколен..."
Отправлено filosofem , 08-Дек-10 15:25 
Меняю свой двухъядерный проц на ваш шестиядерный. Конечно с вашей доплатой.

"Oracle переходит к сокращению числу ядер в следующем поколен..."
Отправлено Толстый , 08-Дек-10 16:55 
Типичный вброс. Если у тебя каждое ядро будет как минимум в три раза моего шестиядерника, то я с удовольствием поменяюсь и тебе доплачу.

"Oracle переходит к сокращению числу ядер в следующем поколен..."
Отправлено Толстый , 08-Дек-10 16:56 
в три раза быстрее*

"Oracle переходит к сокращению числу ядер в следующем поколен..."
Отправлено filosofem , 09-Дек-10 08:55 
Нет не вброс.
Вброс это про кэш и HT. Во-первых HT не многоядерность, а многопоточность, здесь же говорят про многоядерность. Во-вторых кэш может быть общим и использоваться весь хоть одним потоком при необходимости. В-третьих никому кроме Оракула религия не запрещает одновременно оптимизировать производительность отдельного потока и увеличивать количество ядер.

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


"Oracle переходит к сокращению числу ядер в следующем поколен..."
Отправлено nagual , 09-Дек-10 11:12 
>[оверквотинг удален]
> религия не запрещает одновременно оптимизировать производительность отдельного потока
> и увеличивать количество ядер.
> Единственное объяснение - это ERP приложения, которые пишут орды студентов и индусов
> в сжатые сроки и до оптимизации дело конечно не доходит. У
> этих программ совершенно безумная логика и оверхед и конечно они однопоточны.
> Видел случаи, когда одно обращение из джава-приложения к оракловой базе, возвращающее
> одну запись, длилось до нескольких минут на двух процессорах Зион 5580
> и конечно же работал один поток.
> А так же лохматое проприетарное  ПО, которое давно не обновляется и
> не обслуживается производителем.

Кто вам сказал что проприентарное по оптимизируется? Дописали продали - забыли. Делают новое. Оптимизируется то за что заплочено. Половина проприентарного по (проекты писанные под конкретные заказы и неполучившие массового распостранения) это уг.


"Oracle переходит к сокращению числу ядер в следующем поколен..."
Отправлено pavlinux , 08-Дек-10 15:28 
> не тупи. вместе с уменьшением количества ядер - увеличивается объем кэша принадлежаший
> каждому ядру и потоку. А ты сразу "ниасилили .. ниасилили"..
> Это как с включением и выключением HT у интеля - есть задачи
> на которых HT будет медленее обычного, за счет того что без
> HT данные и код будут влезать в кэш и не потребуется
> доп загрузка из памяти (что не дешево - в случае NUMA,
>  а спарки это NUMA)

NUMA в проце??? Зачем?!



"Oracle переходит к сокращению числу ядер в следующем поколен..."
Отправлено Square , 08-Дек-10 19:18 
>> не тупи. вместе с уменьшением количества ядер - увеличивается объем кэша принадлежаший
>> каждому ядру и потоку. А ты сразу "ниасилили .. ниасилили"..
>> Это как с включением и выключением HT у интеля - есть задачи
>> на которых HT будет медленее обычного, за счет того что без
>> HT данные и код будут влезать в кэш и не потребуется
>> доп загрузка из памяти (что не дешево - в случае NUMA,
>>  а спарки это NUMA)
> NUMA в проце??? Зачем?!

Opteron тоже построен на архитектуре NUMA

А нужна она там наверное затем, что в Оптероне например - контроллер памяти находится в самом проце...а NUMA - это архитектура доступа к памяти...


"Oracle переходит к сокращению числу ядер в следующем поколен..."
Отправлено pavlinux , 08-Дек-10 22:50 
>>> не тупи. вместе с уменьшением количества ядер - увеличивается объем кэша принадлежаший
>>> каждому ядру и потоку. А ты сразу "ниасилили .. ниасилили"..
>>> Это как с включением и выключением HT у интеля - есть задачи
>>> на которых HT будет медленее обычного, за счет того что без
>>> HT данные и код будут влезать в кэш и не потребуется
>>> доп загрузка из памяти (что не дешево - в случае NUMA,
>>>  а спарки это NUMA)
>> NUMA в проце??? Зачем?!
> Opteron тоже построен на архитектуре NUMA

Еще скажи что он один, меж своми ядрами сможет замутить НУМУ

-----
pavel@suse64:~> numastat
                           node0           node1
numa_hit                43910069        50573757
numa_miss                  62495          204582
numa_foreign              204582           62495
interleave_hit             23920           23443
local_node              43899628        50560454
other_node                 72936          217885


Обломс .... две ноды тока.

----
В общем NUMA  это комплекс из контроллера памяти + памяти + OSи
------

Я то думал, что когда написали что Спарки стали NUMA,
то решил что там сделали NUMA между ядер или между тредов
в одном кристалле. Если порубить 128 тредов на 32 мега L3-кэша,
то каждой нити досталось бы под 256 кило. Вот это было бы клёво!


"Oracle переходит к сокращению числу ядер в следующем поколен..."
Отправлено nagual , 09-Дек-10 11:16 
>[оверквотинг удален]
>>> Это как с включением и выключением HT у интеля - есть задачи
>>> на которых HT будет медленее обычного, за счет того что без
>>> HT данные и код будут влезать в кэш и не потребуется
>>> доп загрузка из памяти (что не дешево - в случае NUMA,
>>>  а спарки это NUMA)
>> NUMA в проце??? Зачем?!
> Opteron тоже построен на архитектуре NUMA
> А нужна она там наверное затем, что в Оптероне например - контроллер
> памяти находится в самом проце...а NUMA - это архитектура доступа к
> памяти...

Лол какие удивительные подробности ... ;-) а ведь феномы когда проходят тесты хомячками перемаркируются в оптероны ... а двуядерные атлоны это теже феномы но из отбраковки ... ;-)


"Oracle переходит к сокращению числу ядер в следующем поколен..."
Отправлено Vkni , 09-Дек-10 20:28 
Дорогой Павлинукс, возьми практический любой алгоритм вычмата по нахождению корня уравнения - не параллелизуется. Если брать алгоритмы решенения систем алгебраических уравнений, то, что на современных компах тоже относительно долго считается, то алгоритм Гаусса-Зейделя тоже не параллелизуется.

Т.е. можно его частично превратить в алгоритм Гаусса, который можно распараллелить, но он будет едва ли не медленнее считать.

И тут можно хоть 5000 000 000 штук PDP-11 поставить, всё равно они будут считать со скоростью одной машины.


"Oracle переходит к сокращению числу ядер в следующем поколен..."
Отправлено pavlinux , 09-Дек-10 21:41 
> - не параллелизуется. Если брать алгоритмы решенения систем алгебраических уравнений,
> то, что на современных компах тоже относительно долго считается, то алгоритм
> Гаусса-Зейделя тоже не параллелизуется.
> Т.е. можно его частично превратить в алгоритм Гаусса, который можно распараллелить, но
> он будет едва ли не медленнее считать.
> И тут можно хоть 5000 000 000 штук PDP-11 поставить, всё равно
> они будут считать со скоростью одной машины.

Распердолить матрицу на части равным количеству ядров/процов,
и методом,... как его там.., Крамера.
Вот и будет чем занять 5000000000 штук PDP-11 :)

Ах да, через алг. дополнения можно параллелить


"Oracle переходит к сокращению числу ядер в следующем поколен..."
Отправлено Аноним , 10-Дек-10 03:51 
Крамер подходит, afaik, для ручного счета небольших систем, но уж никак не для машинного решения уравнений 1000+-порядка

"Oracle переходит к сокращению числу ядер в следующем поколен..."
Отправлено pavlinux , 10-Дек-10 04:10 
> Крамер подходит, afaik, для ручного счета небольших систем, но уж никак не
> для машинного решения уравнений 1000+-порядка

Вы такую матрицу три года составлять будете. А уж посчитать за недельку можно.


"Oracle переходит к сокращению числу ядер в следующем поколен..."
Отправлено User294 , 08-Дек-10 18:41 
КО намекает: наращивание производительности одного ядра упирается в его сложность и максимальную частоту при которой схема еще нормально работает. Интель и амд уже уперлись в пределы ограниченные тепловыделением и гоняются за количеством ядер ... просто потому что в случае существующих нынче кремниевых CMOS технологий задирать частоту выше 3 с небольшим ГГц - не выходит, а добавление новых ядер дает по простому достаточно большой эффект в ряде программ. Оракл хочет порубаться с ними в general purpose? Удачи ораклу - им она понадобится.

"Oracle переходит к сокращению числа ядер в следующем поколен..."
Отправлено Аноним , 08-Дек-10 13:23 
Ага, значит теперь Лари решил и железо санок под откос пустить.

"Oracle переходит к сокращению числа ядер в следующем поколен..."
Отправлено Аноним , 08-Дек-10 13:38 
Только мне кажется что они хотят увеличить количество ЦПУ чтто бы снимать бабло за лицензии на камень для ОracleDB? Такое не прикрытое надувательство )

"Oracle переходит к сокращению числа ядер в следующем поколен..."
Отправлено Аноним , 08-Дек-10 14:16 
А смысл? То есть, конечно, понятно, что Оракл любит рубить бабло (хотя какая не любит? разве что сан был компаней с более "человеческим" лицом, но это плохо для него кончилось), но ведь в условиях жёсткой конкуренции со стороны других производителей процессоров и кроссплатформенности самой бд, это приведёт лишь к уходу клиентов с архитектуры спарк и её окончательному вымиранию. А ведь при правильном подходе она может быть вполне профитной (для сана железо вообще было основным доходом до кризиса, из-за которого им и пришлось продаться), чего и хочет добиться Оракл, переводя её из разряда специализированных в общие. На месте Оракла я бы, наоборот, пользуясь популярностью самой бд, предоставлял бы льготные условия её (и не только, но и прочего ынтерпрайза) использования для клиентов со спарк-серверами/рабочими станциями, чтобы потихоньку выправить не слишком хорошее положение архитектуры. А там уже и доить можно будет, привязав клиентуру к своей архитектуре :)
А если тупо ради увеличения состригаемого бабла - это сюминутная выгода, которая не долго продлится, а потенциально профитный портфель технологий, за которые были уплачены приличные деньги, будет выброшен на помойку, тем более, что в отличие от опенсорса, выгода от разработки которого не всегда очевидна и достаточна для поддержания интереса компании, тут профит лежит на поверхности. Не думаю, что такая серьёзная компания как Оракл будет действовать так примитивно.

"Oracle переходит к сокращению числа ядер в следующем поколен..."
Отправлено Max , 08-Дек-10 14:24 
Enterprise edition лицензируется по числу ядер, а не сокетов.
Поэтому на Т-серии множитель лицензий ниже, чем на М.

"Oracle переходит к сокращению числа ядер в следующем поколен..."
Отправлено balex , 11-Дек-10 06:52 
> Только мне кажется что они хотят увеличить количество ЦПУ чтто бы снимать
> бабло за лицензии на камень для ОracleDB? Такое не прикрытое надувательство
> )

Дык вроде ядра тоже считаются в случае лицензирования. Или я напутал? В этом случае желание оракла уменьшить кол-во ядер понятны - уменьшить стоимость конечной лицензии СУБД. А далее народу проще впаривать - ходите дешевле - берите с малым кол-вом сокетов...


"Oracle переходит к сокращению числа ядер в следующем поколен..."
Отправлено анонимус , 08-Дек-10 14:16 
>Oracle переходит к сокращению числа ядер в следующем поколении процессоров SPARC

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


"Oracle переходит к сокращению числа ядер в следующем поколен..."
Отправлено pavlinux , 08-Дек-10 15:11 
x86 - держит рынок ядрами.
power - держит гигагерцами.
итаниум - ошень длинными инструкциями.
ARM - малыми ваттами.

спарк - ни в пиз...у ни вж...у  :)


"Oracle переходит к сокращению числа ядер в следующем поколен..."
Отправлено Аноним , 08-Дек-10 15:21 
> x86 - держит рынок ядрами.
> power - держит гигагерцами.

сдох.
> итаниум - ошень длинными инструкциями.

сдох.

> ARM - малыми ваттами.
> спарк - ни в пиз...у ни вж...у  :)

Да да.. мозги стоит включать прежде чем пишешь.


"Oracle переходит к сокращению числа ядер в следующем поколен..."
Отправлено pavlinux , 08-Дек-10 15:35 
>> x86 - держит рынок ядрами.
>> power - держит гигагерцами.
> сдох.
>> итаниум - ошень длинными инструкциями.
> сдох.
>> ARM - малыми ваттами.
>> спарк - ни в пиз...у ни вж...у  :)
> Да да.. мозги стоит включать прежде чем пишешь.

У тя его ваще нет.

IBM на Power7 строит кластер для ДАРПы, обещают 7 Петафлоп.
Ну и глянь в тор500 - Opteron, Xeon и Power


"Oracle переходит к сокращению числа ядер в следующем поколен..."
Отправлено jSnake , 08-Дек-10 15:51 
Поздравляю.
Ну и зачем дарпе гигагерцы взамен многоядерности? И причём здесь кластер? Речь идёт о непростом выборе - ориентироваться на одну большую задачу или на миллиард мелких. В Оракле решили начать с первого и попросили у фуджитсу именно такой спарк. Оправдается это или нет - время покажет. Ктому же есть T3, он отлично масштабируется, лет на пять вполне хватит.

"Oracle переходит к сокращению числа ядер в следующем поколен..."
Отправлено Square , 08-Дек-10 15:56 
>[оверквотинг удален]
>>> power - держит гигагерцами.
>> сдох.
>>> итаниум - ошень длинными инструкциями.
>> сдох.
>>> ARM - малыми ваттами.
>>> спарк - ни в пиз...у ни вж...у  :)
>> Да да.. мозги стоит включать прежде чем пишешь.
> У тя его ваще нет.
> IBM на Power7 строит кластер для ДАРПы, обещают 7 Петафлоп.
> Ну и глянь в тор500 - Opteron, Xeon и Power

Xeon это не Itanium.

top500 -

Power      8.00 %  
Sparc     0.40 %     
Intel IA-64 1.00 %     
Intel EM64T 78.40 %     
AMD x86_64 11.40 %     

IA-64 - это и есть итаниум.
AMD x86_64 - это оптерон.


"Oracle переходит к сокращению числа ядер в следующем поколен..."
Отправлено Avator , 08-Дек-10 19:42 
ошибаетесь... Power уж точно не сдох, замечательно себя чувствует, правда рынок он конечно не гигагерцами держит =))

"Oracle переходит к сокращению числа ядер в следующем поколен..."
Отправлено Square , 08-Дек-10 15:49 
> x86 - держит рынок ядрами.
> power - держит гигагерцами.
> итаниум - ошень длинными инструкциями.
> ARM - малыми ваттами.

Все это разные рынки.

на рынке персональных компьютеров, бюджетных бизнес систем - x86 держится из-за цены и популярности. power для этого рынка умер. итаниум - даже не рождался. ARM - присутствует но слабо.

На рынке корпоратива - x86 держится из-за цены и популярности. power,спарк - из-за поддержки.  итаниум - умер. ARM - отсутствует.

На рынке встраиваемых устройств - x86 держится из-за цены и популярности.
power,спарк,итаниум - отсутствуют. ARM - присутствует.


"Oracle переходит к сокращению числа ядер в следующем поколен..."
Отправлено pavlinux , 08-Дек-10 16:02 
Я вот даже не знаю, но почему-то исследованиям сотрудников РАН и МГУ больше верю,
о том что Итаниум2 на данный момент лучший проц в галакитке.

"Oracle переходит к сокращению числа ядер в следующем поколен..."
Отправлено Square , 08-Дек-10 16:03 
> Я вот даже не знаю, но почему-то исследованиям сотрудников РАН и МГУ
> больше верю,
> о том что Итаниум2 на данный момент лучший проц в галакитке.

Смотря для чего лучший...
К тому же от сотрудников РАН и МГУ хотелось бы услышать о перспективах Эльбруса а не Итаниума2


"Oracle переходит к сокращению числа ядер в следующем поколен..."
Отправлено pavlinux , 08-Дек-10 16:44 
>> Я вот даже не знаю, но почему-то исследованиям сотрудников РАН и МГУ
>> больше верю,
>> о том что Итаниум2 на данный момент лучший проц в галакитке.
> Смотря для чего лучший...
> К тому же от сотрудников РАН и МГУ хотелось бы услышать о
> перспективах Эльбруса а не Итаниума2

Эльбрусовцы это другие, я иха не знаю. :)

А про Итаники речь шла о платформе для SQL.
Диагноз был такой что, Оптероны и у тем более Зеоны
генерят кучу ошибок, и масса времени проца уходит на
повторы и исправления. Про Powerы_ы - то что они сцуки,
хороши только на AIX, под который надо переписывать/дописывать софт.
Так как портабельный софт не использует всех возможностей ни AIX ни Power. :(

По секрету: Бабло на Итаники не дали, купили Оптеронов :)


"Oracle переходит к сокращению числа ядер в следующем поколен..."
Отправлено vle , 09-Дек-10 01:48 
>>> Я вот даже не знаю, но почему-то исследованиям сотрудников РАН и МГУ
>>> больше верю,
>>> о том что Итаниум2 на данный момент лучший проц в галакитке.
>> Смотря для чего лучший...
>> К тому же от сотрудников РАН и МГУ хотелось бы услышать о
>> перспективах Эльбруса а не Итаниума2
> Эльбрусовцы это другие, я иха не знаю. :)

"Тот самый Эльбрус" - это Бабаян, а Бабаян -- это еще и "новый Эльбрус",
который вроде почти умер с тех пор, как Бабаяна купил Intel.
А "новый Эльбрус" -- этот тот самый, который рвал как Тузик грелку
Mersed-а IIRC в конце 90-х, а Mersed -- это тот самый Итаник, который
вот те самые люди из РАН и МГУ хвалят за VLIW, а VLIW -- это ...

> Про Powerы_ы - то что они сцуки,
> хороши только на AIX, под который надо переписывать/дописывать софт.

Ну что за бред. Игровые приставки работают
практически полностью на семействе Power.


"Oracle переходит к сокращению числа ядер в следующем поколен..."
Отправлено psiho , 08-Дек-10 18:10 
так старые эльбрусовцы по моему и попали в комаду итаниума

"Oracle переходит к сокращению числа ядер в следующем поколен..."
Отправлено nagual , 09-Дек-10 04:10 
> Я вот даже не знаю, но почему-то исследованиям сотрудников РАН и МГУ
> больше верю,
> о том что Итаниум2 на данный момент лучший проц в галакитке.

Первый вопрос про какую галактику речь ?
И второй где они берут такую траву ?

ЗЫ РАН это дармоеды ... история с фильтрами для воды весьма показательна.


"Oracle переходит к сокращению числа ядер в следующем поколен..."
Отправлено User294 , 08-Дек-10 19:16 
> x86 - держит рынок ядрами.

Потому что уткнулись в пределы улучшения 1 ядра - есть существенные барьеры в продолжении эволюции в ту же сторону. Частоту бесконечно задирать не получается, остальными методами можно добиться успеха только частично и с переменной эффективностью, в основном эволюционируют по части параллельного исполнения микрокоманд - тоже параллелизация, и тоже не любой алгоритм от этого выиграет.  Вообще, большое ядро на афигенной частоте по определению дохрена жрет. А это главная проблема - слишком сложная и быстрая схема элементарно поджаривает сама себя. Вот и заглохло направление развития "одно ядро, зато крутое". Проще сделать два, работающих в нормальном режиме, чем одно которое само себя изжарит в результате.

> power - держит гигагерцами.

Павлин, на кремнии выше 3-4 ГГц крайне проблематично выходит, и Power тут не исключение (извраты типа охлаждения жидким азотом - экономически неэффективны, проще поставить 2 проца на 3 ГГц чем один на 6ГГц + азот). Кстати не ты ли там про GaAs с его дикими ГГц втирал? Обломись: из него оказыается не удается CMOS структуры делать, поэтому его и не используют. Я думаю ты понимаешь что это означает, ага? Да, он и дальше будет использоваться только для совсем примитивных, но быстрых чипов. Где потребление одного элемента - не критично в силу малой интеграции. Мало-мальски сложные чипы на GaAs - зажарят сами себя, т.к. будут жрать как трамвай (вспомни сколько жрали чипы до внедрежа комплементарных структур, в пересчете на элемент, ага) :).Может быть, поэтому то Power и стал маловато использоваться? Гонка гигагерцев налетела на физические ограничения технологий.

> итаниум - ошень длинными инструкциями.

Итаниум? Итаник! Задуман мощно, система команд внушает. Но ... но где он?! АМД с своим амд64 + интел с своим жлобством практически на пару его закопали, живьем. Потому что АМД64 - дешево, сердито, работает. А больше покупателей ничего особо и не волнует. Вот и вышел у интеля итаник.

> ARM - малыми ваттами.

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

> спарк - ни в пиз...у ни вж...у  :)

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


"Oracle переходит к сокращению числа ядер в следующем поколен..."
Отправлено nagual , 09-Дек-10 04:19 
> Гонка гигагерцев налетела на
> физические ограничения технологий.

Единственно что мешает далнейшему развитию это патентные войны.

> Итаниум? Итаник! Задуман мощно, система команд внушает. Но ... но где он?!
> АМД с своим амд64 + интел с своим жлобством практически на
> пару его закопали, живьем. Потому что АМД64 - дешево, сердито, работает.
> А больше покупателей ничего особо и не волнует. Вот и вышел
> у интеля итаник.

Даже несмотря на навязчивую рекламу интела, везде гне надо, ненадо и даже совсем ненадо :-) амд покупают. Недавно смотрел обзор на украинском оверклокере - еще один тест процессора. В начале статьи более менее а на последней странице скрины какие то совсем левые вместо ддр3 в тесте вдруг появилась ддр2 ... автор непроводил тесты а просто написал статью. Реь идет о амд процессоре ...

>> спарк - ни в пиз...у ни вж...у  :)

Спарки это готовые решения как маки в десктопном сегменте так спарки в серверном. В частности R3 ...


"Oracle переходит к сокращению числа ядер в следующем поколен..."
Отправлено fidaj , 09-Дек-10 13:17 
>> Гонка гигагерцев налетела на
>> физические ограничения технологий.
> Единственно что мешает далнейшему развитию это патентные войны.

Войны - это единственный быстрый и надежный способ регулировки численности популяции homoerectus на планете...


"Oracle переходит к сокращению числа ядер в следующем поколен..."
Отправлено www2 , 09-Дек-10 09:07 
По-моему Power нифига не умер, а очень даже здравствует на серверах IBM. x86 и x86_64 не годятся ему в подмётки по одной причине - они работают с памятью по одной шине, а Power в компьютерах IBM - по NUMA. То есть процессорные ядра и блоки памяти связаны между собой через коммутационную матрицу. В своём классе задач эти системы просто незаменимы, так что скорее всего Power не только не сдох, но будет жив ещё очень долго.

"Oracle переходит к сокращению числа ядер в следующем поколен..."
Отправлено johnjoy , 08-Дек-10 15:32 
Имхо, логично вполне.
Было 2 разработки - Rock и CoolThreads (T1/2/3), нацеленные на разные задачи - первый для СУБД, ERP и пр OLAP-подобные задачи, второй на многопоточные (более) легкие приложения.
CoolThreads вполне успешно выпустили, довели до ума ко второму релизу, знатная молотилка получилась.
А вот Rock умер так и не родившись - и Oracle оказалась в ситуации, когда они имеют отработанные и перспективные железные технологии - но, увы, совсем не для их флагманского продукта.

Даже хорошо, что вместо того, чтобы забыть спарк и дать ему потихоньку умирать - стали допиливать и адаптировать то, что имеют.
К тому же CoolThreads довольно специфичны: нужно еще постараться (и админством и программированием), чтобы разогнать их до потенциала.


"Oracle переходит к сокращению числа ядер в следующем поколен..."
Отправлено Square , 08-Дек-10 15:36 
Правильная мысль.
Что производительнее, MPP из сотни 386 или один пентиум?
Один пентиум.
Как говаривал классик - вся ваша конница не заменит одного подростка с фаустпатроном...

"Oracle переходит к сокращению числа ядер в следующем поколен..."
Отправлено User294 , 08-Дек-10 20:04 
> Что производительнее, MPP из сотни 386 или один пентиум?
> Один пентиум.

А что проще, дешевле и технологичнее - воткнуть 2 проца на 3ГГц или один но на 6? Может быть, нынче немного иные технологические проблемы чем в девяностые? Чтобы проц на 6ГГц не зажарился - потребуется жидкий азот в системе охлаждения... всего-то так, ага ;)

А что до производительности - от задач зависит. На ряде задач пень упрется в свою тормозную память, которая не сильно лучше чем у 386. А у 386 она у каждого своя. Так что у сотни процов в 100 раз больше бандвиза памяти чем у одного. Профит, ага. Да и просто отгрузка вебпаг кластером из 100 386-х будет пожалуй лучше чем одним несчастным пеньком, за счет того что винт и сетевуха у пня ну никак не в 100 раз лучше, пардон :)


"Oracle переходит к сокращению числа ядер в следующем поколен..."
Отправлено nagual , 09-Дек-10 04:24 
>[оверквотинг удален]
> проблемы чем в девяностые? Чтобы проц на 6ГГц не зажарился -
> потребуется жидкий азот в системе охлаждения... всего-то так, ага ;)
> А что до производительности - от задач зависит. На ряде задач пень
> упрется в свою тормозную память, которая не сильно лучше чем у
> 386. А у 386 она у каждого своя. Так что у
> сотни процов в 100 раз больше бандвиза памяти чем у одного.
> Профит, ага. Да и просто отгрузка вебпаг кластером из 100 386-х
> будет пожалуй лучше чем одним несчастным пеньком, за счет того что
> винт и сетевуха у пня ну никак не в 100 раз
> лучше, пардон :)

Вообще у процессора кеш сильно греетца, а сама молотилка не очень.


"Oracle переходит к сокращению числа ядер в следующем поколен..."
Отправлено Square , 09-Дек-10 06:08 
>[оверквотинг удален]
>> потребуется жидкий азот в системе охлаждения... всего-то так, ага ;)
>> А что до производительности - от задач зависит. На ряде задач пень
>> упрется в свою тормозную память, которая не сильно лучше чем у
>> 386. А у 386 она у каждого своя. Так что у
>> сотни процов в 100 раз больше бандвиза памяти чем у одного.
>> Профит, ага. Да и просто отгрузка вебпаг кластером из 100 386-х
>> будет пожалуй лучше чем одним несчастным пеньком, за счет того что
>> винт и сетевуха у пня ну никак не в 100 раз
>> лучше, пардон :)
> Вообще у процессора кеш сильно греетца, а сама молотилка не очень.

Согласно top 500 за 1993 год, система из 512 процессоров Power  работавших на частоте 30 Мгц (0.002 GFlops), выдавала 0.485 Gflops и находилась на 411 месте в топ 500.

Конечно Power  не i386, я ориентировался по частоте только, но суть то от этого не меняется- один подросток с фаустпатроном лучше конницы :)

Из того же топ-500 1993 года - система на ОДНОМ процессоре Fujitsu 312 MHz (1.25 GFlops) выдавала .... ну вы поняли сколько :)

Система из 64 процессоров Intel 80860 40 MHz (0.04 GFlops) выдавала 1.4 GFlops.
если умножить частоту 64*40=2560 - то суммарная частота получится в ВОСЕМЬ раз больше чем у предыдущего кандидата примерно такой же производительности.

Определенно, один фаустпатрон - лучше конницы :))


"Oracle переходит к сокращению числа ядер в следующем поколен..."
Отправлено svv , 09-Дек-10 12:39 
Это кто же тебя учил умножать частоту на число ядер?

"Oracle переходит к сокращению числа ядер в следующем поколен..."
Отправлено Square , 09-Дек-10 13:56 
> Это кто же тебя учил умножать частоту на число ядер?

А в чем проблема? Смысл многоядерности как раз в том, чтобы решать задачу параллельно...
Решается задача при этом на каждом из узлов с некой скорость зависящей от частоты...
Суммарная производительность реальных систем состоящих из множества процессоров работающих на некой частоте - никогда не достигает производительность процессора работавшего бы на этой эквивалентной частоте. Что хорошо видно в списке top500. Весь ВОЗМОЖНЫЙ прирост производительности "съедают" накладные расходы.
Именно по этому, на практике - такую операцию как сделал я- умножил частоты на количество процессоров- люди не делают, потому что заранее известно что производительность в мультипроцессорных системах не растет линейно.
Если вас смущает умножение частоты на ядра -  можете перевести частоту во время исполнения одного такта и этот показатель умножить на число ядер. Число которое получится- будет показывать за какое время мультиядерная система совершит тот же (эквивалентный) объем вычислений.


"Oracle переходит к сокращению числа ядер в следующем поколен..."
Отправлено filosofem , 09-Дек-10 09:12 
> Правильная мысль.
> Что производительнее, MPP из сотни 386 или один пентиум?
> Один пентиум.
> Как говаривал классик - вся ваша конница не заменит одного подростка с
> фаустпатроном...

Вы "правильную мысль" до конца не дочитали. Вот дублирую для писателей не читателей:
"Компенсировать снижение числа ядер внутри одного CPU, сможет увеличение числа CPU-сокетов в серверных платформах будущего от компании Oracle. Например, к 2013 году прогнозируется использование до 8 сокетов, а в 2014 году число сокетов в одном сервере достигнет 64."


"Oracle переходит к сокращению числа ядер в следующем поколен..."
Отправлено Square , 09-Дек-10 15:31 
>[оверквотинг удален]
>> Что производительнее, MPP из сотни 386 или один пентиум?
>> Один пентиум.
>> Как говаривал классик - вся ваша конница не заменит одного подростка с
>> фаустпатроном...
> Вы "правильную мысль" до конца не дочитали. Вот дублирую для писателей не
> читателей:
> "Компенсировать снижение числа ядер внутри одного CPU, сможет увеличение числа CPU-сокетов
> в серверных платформах будущего от компании Oracle. Например, к 2013 году
> прогнозируется использование до 8 сокетов, а в 2014 году число сокетов
> в одном сервере достигнет 64."

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

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

Есть два пути развития технологии- интенсивный и экстенсивный.

Экстенсивный - это развитие "вширь", связанный с количественным, а не качественным изменением, увеличением числа ядер в кристалле.

Интенсивный - создание новых алгоритмов, создание новых схем, изменение логики работы устройства.

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


"Oracle переходит к сокращению числа ядер в следующем поколен..."
Отправлено filosofem , 09-Дек-10 15:50 
>Экстенсивный - это развитие "вширь", связанный с количественным, а не качественным изменением, увеличением числа ядер в кристалле.

А увеличение числа сокетов до 64 это стало быть интенсивный путь?


"Oracle переходит к сокращению числа ядер в следующем поколен..."
Отправлено Square , 09-Дек-10 15:56 
>>Экстенсивный - это развитие "вширь", связанный с количественным, а не качественным изменением, увеличением числа ядер в кристалле.
> А увеличение числа сокетов до 64 это стало быть интенсивный путь?

Вы как-то избирательно читаете новость.. Они оптимизировать потоки собираются.
Вы оригинал новости то, а не перевод читали? :)
Цитирую:

The next Sparc chip on Oracle's road map, the T4, will have eight cores on each chip, down from 16 in the current Sparc T3, according to a slide shown at Oracle's systems launch last week. Both will run the same eight compute threads per core.

далее:

But chips with high core counts tend to be better at some workloads than others. They are good at jobs that can be broken into many smaller parts, such as processing high volumes of Web requests and online transactions, but fare worse at big databases and ERP applications, where single-thread performance is important .


Обратите внимание: "single-thread performance".

Они хотят добиться высокой производительности на нераспараллеливаемых задачах. И возможно вообще перейти к одноядерным процессорам:

"I think the handwriting is on the wall that, ultimately, Oracle will want to have one core that they can deploy in both these highly parallel throughput type environments and also in the higher-end environments," he said.

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

Это по мнению переводчика новости- увеличение числа сокетов делается для того чтобы "компенсировать". А в оригинале - масштабирование своих систем Оракл и раньше делал таким же способом. Увеличивая число CPU-сокетов... Фраза про CPU-сокеты - в оригинальной новости приведена как ремарка "А вы в курсе что они еще и количество сокетов собираются увеличить?" Нормальное масштабирование, к СУТИ новости- не относящееся, но перевернутое переводчиком так, что аж жутко становится...

Извините, но обсуждать воображение переводчика я не буду.

В оригинале фраза про увеличение CPU-сокетов звучит так:

Indeed, the roadmap shown at OpenWorld had Sparc-based systems scaling from four sockets per server today, to eight sockets in 2013 and up to 64 sockets in 2014 -- in line with the Sparc64 -- suggesting the Sparc T chips will power some very large, scale-up systems.

Найдите в этой фразе слова "компенсировать ради увеличения производительности".


"Oracle переходит к сокращению числа ядер в следующем поколен..."
Отправлено filosofem , 09-Дек-10 16:30 
Цитата опять же для нечитателей из оригинала:
"Indeed, the roadmap shown at OpenWorld had Sparc-based systems scaling from four sockets per server today, to eight sockets in 2013 and up to 64 sockets in 2014"

>Они хотят добиться высокой производительности на нераспараллеливаемых задачах

А кто не хочет. Интел (к примеру) тоже оптимизирует производительность одного потока. Каждый год эта производительность(одного потока) увеличивается в 1.5 - 2 раза, смотрите бенчмарки однопоточный приложений.

Теперь задумаемся, ок?
Один производитель оптимизирует архитектуру и увеличивает количество ядер.
Другой производитель собирается оптимизировать архитектуру и уменьшает число ядер, зато зверски увеличивает количество сокетов.
Ну и кто здесь конница, а кто с фаустпатроном?
И главный вопрос: кто в каске? =)


"Oracle переходит к сокращению числа ядер в следующем поколен..."
Отправлено Square , 09-Дек-10 16:37 
> И главный вопрос: кто в каске? =)

Может быть тот, кто путает серверную платформу и отдельный процессор?

И если вам любопытно -то вот ваше "зверски увеличивает числа сокетов" шо называется в железе:
http://www.ibm.com/systems/ru/p/hardware/highend/595/

То что Оракл ТОЛЬКО ПЛАНИРУЕТ (увеличить число сокетов в платформе до 64) - давно можно купить. Сервера System p5 590 поддерживают 64-х процессорные конфигурации...
Из характеристики платформы System p5 590:

"От 16 до 64 64-разрядных процессоров POWER5 с тактовой частотой 1,65 или 1,9 ГГц или процессоров POWER5+ с тактовой частотой 2,1 или 2,3 ГГц в многокристальных модулях MCM (восемь процессоров на MCM)"

А Оракл ТОЛЬКО ПЛАНИРУЕТ увеличить число сокетов в системе до 64 к 2014 году...
То есть на рынке такие системы есть, они востребованы, и Оракл в этом плане не собирается отставать...Вот об этом говорит эта ремарка.. А не о "компенсации".


"Oracle переходит к сокращению числа ядер в следующем поколен..."
Отправлено filosofem , 09-Дек-10 19:09 
>А Оракл ТОЛЬКО ПЛАНИРУЕТ увеличить число сокетов в системе до 64 к 2014 году...
>То есть на рынке такие системы есть, они востребованы, и Оракл в этом плане не собирается отставать...

Это тоже "правильная мысль" да?
Так же как и эта
>Правильная мысль.
>Что производительнее, MPP из сотни 386 или один пентиум?

Видимо все мысли Оракла по определению правильные.


"Oracle переходит к сокращению числа ядер в следующем поколен..."
Отправлено Anon Y Mous , 09-Дек-10 23:15 
> А Оракл ТОЛЬКО ПЛАНИРУЕТ увеличить число сокетов в системе до 64 к 2014 году...

А CS6400, Ultra Enterprise 10000, Sun Fire 15K, Sun fire E25k и M9000-64 конечно же не существовало и не существует, да?


"Oracle переходит к сокращению числа ядер в следующем поколен..."
Отправлено Square , 09-Дек-10 23:33 
>> А Оракл ТОЛЬКО ПЛАНИРУЕТ увеличить число сокетов в системе до 64 к 2014 году...
> А CS6400, Ultra Enterprise 10000, Sun Fire 15K, Sun fire E25k и
> M9000-64 конечно же не существовало и не существует, да?

Это вопрос не ко мне, а к тому кто писал статью...
Автор статьи считает что у Оракла такие системы только в перспективе...
Хотя... с другой стороны  - речь в статье может идти о системах на базе Т3, а СанФайр - это "старье" на базе UltraSPARC III


"Oracle переходит к сокращению числа ядер в следующем поколен..."
Отправлено Engineer , 09-Дек-10 10:21 
Интересно а что мешает Ораклу оптимизировать потоки с существующим количеством ядер в процесоре?

"Oracle переходит к сокращению числа ядер в следующем поколен..."
Отправлено balex , 11-Дек-10 07:02 
> Интересно а что мешает Ораклу оптимизировать потоки с существующим количеством ядер в
> процесоре?

Теоритически оракле ничего не мешает. Им даже теперь не мешает оптимизировать проц под архитектуру СУБД. Заточить конвеер, добавить инструкции просчёта хэшэй, обсчёт групповых интексов и .т.д. и т.п. Тут только мешает "потолок" полёту мыслей. Ну и как известно народу, плохому танцору уже ничего не мешает, жаль человека :)


"Oracle переходит к сокращению числа ядер в следующем поколен..."
Отправлено Аноним , 09-Дек-10 15:57 
двух ядер процессору вполне достаточно. просто пора уже ОС делать двух-ядерными, а не гнаться за радужными мыльными пузырями