|
| 1.2, northbear (??), 13:13, 08/12/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +8 +/– |
 При всем моем неуважении к Oracle, данное решение выглядит более чем разумным. Гнаться за майнстримом (наращиванием количества ядер) заведомо проигрышный вариант. SPARC'у игра на поле х86 ничем не светит. Никаких, даже теоретических шансов на успех в этой игре у SPARC'а нет.
А эффективность в обработке данных будет востребована всегда.
| | |
| |
| 2.5, Толстый (ok), 13:23, 08/12/2010 [^] [^^] [^^^] [ответить]
| +/– |
 Да все правильно, а то надоела эта гонка по количеству ядер. От наращивания ядер выйграют только оптимизированные под многопоточность приложения, в то время как от наращивания производительности отдельных ядер выйгрыш будет во *всех* приложениях.
| | |
| |
| 3.9, tipa_admin (?), 14:16, 08/12/2010 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Да все правильно, а то надоела эта гонка по количеству ядер.
Да-да, гонка по количеству сокетов гораздо прикольнее.
| | |
| 3.11, Denisiuk (ok), 14:23, 08/12/2010 [^] [^^] [^^^] [ответить]
| +3 +/– |
 Может, кто-то помнить рекламу бритв.. там обыгрывался стеб над бритвами с большим количеством лезвий, тогда джилет, кажется 3 лезвия вставили в бритву.. где-то в 90х было дело
так вот, там стебанулись, мол: а теперь мы представляем бритву с 16ю лезвиями! ...а сейчас бритва с 5ю лезвиями - обычное дело О_о
Так вот... сначала 2 ядра - было диковиной, а теперь 16ю никого не удивишь..
| | |
| |
| 4.66, user455 (?), 15:44, 13/12/2010 [^] [^^] [^^^] [ответить]
| +/– |
немного оффтоп, но самый прикол во всех этих наращивания лезвий - это то, что каждый раз говорят, что их бритвы бреют идеально гладко. но с увеличеним количества лезвий оказывается, что 2-3-4 и т.д. уже не бреют :(
| | |
|
| 3.13, pavlinux (ok), 14:59, 08/12/2010 [^] [^^] [^^^] [ответить]
| –2 +/– |
 > От наращивания ядер выиграют только оптимизированные под многопоточность приложения
Например ядро Linux.
Написали бы, что НИАСИЛИЛИ многоядерность, а то давай отмазки придумывать.
| | |
| |
| 4.15, Аноним (-), 15:19, 08/12/2010 [^] [^^] [^^^] [ответить]
| +/– |
не тупи. вместе с уменьшением количества ядер - увеличивается объем кэша принадлежаший каждому ядру и потоку. А ты сразу "ниасилили .. ниасилили"..
Это как с включением и выключением HT у интеля - есть задачи на которых HT будет медленее обычного, за счет того что без HT данные и код будут влезать в кэш и не потребуется доп загрузка из памяти (что не дешево - в случае NUMA, а спарки это NUMA)
| | |
| |
| 5.17, filosofem (ok), 15:25, 08/12/2010 [^] [^^] [^^^] [ответить]
| +/– |
 Меняю свой двухъядерный проц на ваш шестиядерный. Конечно с вашей доплатой.
| | |
| |
| 6.28, Толстый (ok), 16:55, 08/12/2010 [^] [^^] [^^^] [ответить]
| +/– |
Типичный вброс. Если у тебя каждое ядро будет как минимум в три раза моего шестиядерника, то я с удовольствием поменяюсь и тебе доплачу.
| | |
| |
| 7.42, filosofem (ok), 08:55, 09/12/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
Нет не вброс.
Вброс это про кэш и HT. Во-первых HT не многоядерность, а многопоточность, здесь же говорят про многоядерность. Во-вторых кэш может быть общим и использоваться весь хоть одним потоком при необходимости. В-третьих никому кроме Оракула религия не запрещает одновременно оптимизировать производительность отдельного потока и увеличивать количество ядер.
Единственное объяснение - это ERP приложения, которые пишут орды студентов и индусов в сжатые сроки и до оптимизации дело конечно не доходит. У этих программ совершенно безумная логика и оверхед и конечно они однопоточны. Видел случаи, когда одно обращение из джава-приложения к оракловой базе, возвращающее одну запись, длилось до нескольких минут на двух процессорах Зион 5580 и конечно же работал один поток.
А так же лохматое проприетарное ПО, которое давно не обновляется и не обслуживается производителем.
| | |
| |
| 8.46, nagual (ok), 11:12, 09/12/2010 [^] [^^] [^^^] [ответить] | +/– |  gt оверквотинг удален Кто вам сказал что проприентарное по оптимизируется Доп... текст свёрнут, показать | | |
|
|
|
| 5.18, pavlinux (ok), 15:28, 08/12/2010 [^] [^^] [^^^] [ответить]
| +/– |
> не тупи. вместе с уменьшением количества ядер - увеличивается объем кэша принадлежаший
> каждому ядру и потоку. А ты сразу "ниасилили .. ниасилили"..
> Это как с включением и выключением HT у интеля - есть задачи
> на которых HT будет медленее обычного, за счет того что без
> HT данные и код будут влезать в кэш и не потребуется
> доп загрузка из памяти (что не дешево - в случае NUMA,
> а спарки это NUMA)
NUMA в проце??? Зачем?!
| | |
| |
| 6.33, Square (ok), 19:18, 08/12/2010 [^] [^^] [^^^] [ответить]
| +/– |
 >> не тупи. вместе с уменьшением количества ядер - увеличивается объем кэша принадлежаший
>> каждому ядру и потоку. А ты сразу "ниасилили .. ниасилили"..
>> Это как с включением и выключением HT у интеля - есть задачи
>> на которых HT будет медленее обычного, за счет того что без
>> HT данные и код будут влезать в кэш и не потребуется
>> доп загрузка из памяти (что не дешево - в случае NUMA,
>> а спарки это NUMA)
> NUMA в проце??? Зачем?!
Opteron тоже построен на архитектуре NUMA
А нужна она там наверное затем, что в Оптероне например - контроллер памяти находится в самом проце...а NUMA - это архитектура доступа к памяти...
| | |
| |
| 7.36, pavlinux (ok), 22:50, 08/12/2010 [^] [^^] [^^^] [ответить]
| +/– |
>>> не тупи. вместе с уменьшением количества ядер - увеличивается объем кэша принадлежаший
>>> каждому ядру и потоку. А ты сразу "ниасилили .. ниасилили"..
>>> Это как с включением и выключением 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 кило. Вот это было бы клёво!
| | |
| 7.47, nagual (ok), 11:16, 09/12/2010 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
>>> Это как с включением и выключением HT у интеля - есть задачи
>>> на которых HT будет медленее обычного, за счет того что без
>>> HT данные и код будут влезать в кэш и не потребуется
>>> доп загрузка из памяти (что не дешево - в случае NUMA,
>>> а спарки это NUMA)
>> NUMA в проце??? Зачем?!
> Opteron тоже построен на архитектуре NUMA
> А нужна она там наверное затем, что в Оптероне например - контроллер
> памяти находится в самом проце...а NUMA - это архитектура доступа к
> памяти...
Лол какие удивительные подробности ... ;-) а ведь феномы когда проходят тесты хомячками перемаркируются в оптероны ... а двуядерные атлоны это теже феномы но из отбраковки ... ;-)
| | |
|
|
|
| 4.58, Vkni (?), 20:28, 09/12/2010 [^] [^^] [^^^] [ответить]
| +/– | |
Дорогой Павлинукс, возьми практический любой алгоритм вычмата по нахождению корня уравнения - не параллелизуется. Если брать алгоритмы решенения систем алгебраических уравнений, то, что на современных компах тоже относительно долго считается, то алгоритм Гаусса-Зейделя тоже не параллелизуется.
Т.е. можно его частично превратить в алгоритм Гаусса, который можно распараллелить, но он будет едва ли не медленнее считать.
И тут можно хоть 5000 000 000 штук PDP-11 поставить, всё равно они будут считать со скоростью одной машины.
| | |
| |
| 5.59, pavlinux (ok), 21:41, 09/12/2010 [^] [^^] [^^^] [ответить]
| +/– |
> - не параллелизуется. Если брать алгоритмы решенения систем алгебраических уравнений,
> то, что на современных компах тоже относительно долго считается, то алгоритм
> Гаусса-Зейделя тоже не параллелизуется.
> Т.е. можно его частично превратить в алгоритм Гаусса, который можно распараллелить, но
> он будет едва ли не медленнее считать.
> И тут можно хоть 5000 000 000 штук PDP-11 поставить, всё равно
> они будут считать со скоростью одной машины.
Распердолить матрицу на части равным количеству ядров/процов,
и методом,... как его там.., Крамера.
Вот и будет чем занять 5000000000 штук PDP-11 :)
Ах да, через алг. дополнения можно параллелить
| | |
| |
| 6.62, Аноним (-), 03:51, 10/12/2010 [^] [^^] [^^^] [ответить]
| +/– |
Крамер подходит, afaik, для ручного счета небольших систем, но уж никак не для машинного решения уравнений 1000+-порядка
| | |
| |
| 7.63, pavlinux (ok), 04:10, 10/12/2010 [^] [^^] [^^^] [ответить]
| +/– |
> Крамер подходит, afaik, для ручного счета небольших систем, но уж никак не
> для машинного решения уравнений 1000+-порядка
Вы такую матрицу три года составлять будете. А уж посчитать за недельку можно.
| | |
|
|
|
|
| 3.31, User294 (ok), 18:41, 08/12/2010 [^] [^^] [^^^] [ответить]
| –1 +/– |
 КО намекает: наращивание производительности одного ядра упирается в его сложность и максимальную частоту при которой схема еще нормально работает. Интель и амд уже уперлись в пределы ограниченные тепловыделением и гоняются за количеством ядер ... просто потому что в случае существующих нынче кремниевых CMOS технологий задирать частоту выше 3 с небольшим ГГц - не выходит, а добавление новых ядер дает по простому достаточно большой эффект в ряде программ. Оракл хочет порубаться с ними в general purpose? Удачи ораклу - им она понадобится.
| | |
|
|
| 1.6, Аноним (6), 13:38, 08/12/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +5 +/– |
 Только мне кажется что они хотят увеличить количество ЦПУ чтто бы снимать бабло за лицензии на камень для ОracleDB? Такое не прикрытое надувательство )
| | |
| |
| 2.8, Аноним (-), 14:16, 08/12/2010 [^] [^^] [^^^] [ответить] | +2 +/– | А смысл То есть, конечно, понятно, что Оракл любит рубить бабло хотя какая не ... большой текст свёрнут, показать | | |
| 2.12, Max (??), 14:24, 08/12/2010 [^] [^^] [^^^] [ответить]
| +/– |
Enterprise edition лицензируется по числу ядер, а не сокетов.
Поэтому на Т-серии множитель лицензий ниже, чем на М.
| | |
| 2.64, balex (??), 06:52, 11/12/2010 [^] [^^] [^^^] [ответить]
| +/– |
> Только мне кажется что они хотят увеличить количество ЦПУ чтто бы снимать
> бабло за лицензии на камень для ОracleDB? Такое не прикрытое надувательство
> )
Дык вроде ядра тоже считаются в случае лицензирования. Или я напутал? В этом случае желание оракла уменьшить кол-во ядер понятны - уменьшить стоимость конечной лицензии СУБД. А далее народу проще впаривать - ходите дешевле - берите с малым кол-вом сокетов...
| | |
|
| 1.10, анонимус (??), 14:16, 08/12/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– | |
>Oracle переходит к сокращению числа ядер в следующем поколении процессоров SPARC
А ведь можно было бы просто остановить рост их кол-ва и заниматься допилкой ядер.
Пройдёт поколение-два и никуда не денутся, всё равно будут наращивать кол-во ядер. А со стороны будет выглядеть как метания...
| | |
| 1.14, pavlinux (ok), 15:11, 08/12/2010 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
x86 - держит рынок ядрами.
power - держит гигагерцами.
итаниум - ошень длинными инструкциями.
ARM - малыми ваттами.
спарк - ни в пиз...у ни вж...у :)
| | |
| |
| 2.16, Аноним (-), 15:21, 08/12/2010 [^] [^^] [^^^] [ответить]
| +/– |
> x86 - держит рынок ядрами.
> power - держит гигагерцами.
сдох.
> итаниум - ошень длинными инструкциями.
сдох.
> ARM - малыми ваттами.
> спарк - ни в пиз...у ни вж...у :)
Да да.. мозги стоит включать прежде чем пишешь.
| | |
| |
| 3.20, pavlinux (ok), 15:35, 08/12/2010 [^] [^^] [^^^] [ответить]
| –2 +/– |
>> x86 - держит рынок ядрами.
>> power - держит гигагерцами.
> сдох.
>> итаниум - ошень длинными инструкциями.
> сдох.
>> ARM - малыми ваттами.
>> спарк - ни в пиз...у ни вж...у :)
> Да да.. мозги стоит включать прежде чем пишешь.
У тя его ваще нет.
IBM на Power7 строит кластер для ДАРПы, обещают 7 Петафлоп.
Ну и глянь в тор500 - Opteron, Xeon и Power
| | |
| |
| 4.23, jSnake (??), 15:51, 08/12/2010 [^] [^^] [^^^] [ответить]
| +/– |
 Поздравляю.
Ну и зачем дарпе гигагерцы взамен многоядерности? И причём здесь кластер? Речь идёт о непростом выборе - ориентироваться на одну большую задачу или на миллиард мелких. В Оракле решили начать с первого и попросили у фуджитсу именно такой спарк. Оправдается это или нет - время покажет. Ктому же есть T3, он отлично масштабируется, лет на пять вполне хватит.
| | |
| 4.24, Square (ok), 15:56, 08/12/2010 [^] [^^] [^^^] [ответить]
| +2 +/– |
>[оверквотинг удален]
>>> 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 - это оптерон.
| | |
|
| 3.34, Avator (ok), 19:42, 08/12/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
 ошибаетесь... Power уж точно не сдох, замечательно себя чувствует, правда рынок он конечно не гигагерцами держит =))
| | |
|
| 2.22, Square (ok), 15:49, 08/12/2010 [^] [^^] [^^^] [ответить]
| +/– |
> x86 - держит рынок ядрами.
> power - держит гигагерцами.
> итаниум - ошень длинными инструкциями.
> ARM - малыми ваттами.
Все это разные рынки.
на рынке персональных компьютеров, бюджетных бизнес систем - x86 держится из-за цены и популярности. power для этого рынка умер. итаниум - даже не рождался. ARM - присутствует но слабо.
На рынке корпоратива - x86 держится из-за цены и популярности. power,спарк - из-за поддержки. итаниум - умер. ARM - отсутствует.
На рынке встраиваемых устройств - x86 держится из-за цены и популярности.
power,спарк,итаниум - отсутствуют. ARM - присутствует.
| | |
| |
| 3.25, pavlinux (ok), 16:02, 08/12/2010 [^] [^^] [^^^] [ответить]
| –1 +/– |
Я вот даже не знаю, но почему-то исследованиям сотрудников РАН и МГУ больше верю,
о том что Итаниум2 на данный момент лучший проц в галакитке.
| | |
| |
| 4.26, Square (ok), 16:03, 08/12/2010 [^] [^^] [^^^] [ответить]
| +2 +/– |
> Я вот даже не знаю, но почему-то исследованиям сотрудников РАН и МГУ
> больше верю,
> о том что Итаниум2 на данный момент лучший проц в галакитке.
Смотря для чего лучший...
К тому же от сотрудников РАН и МГУ хотелось бы услышать о перспективах Эльбруса а не Итаниума2
| | |
| |
| 5.27, pavlinux (ok), 16:44, 08/12/2010 [^] [^^] [^^^] [ответить]
| +/– |
>> Я вот даже не знаю, но почему-то исследованиям сотрудников РАН и МГУ
>> больше верю,
>> о том что Итаниум2 на данный момент лучший проц в галакитке.
> Смотря для чего лучший...
> К тому же от сотрудников РАН и МГУ хотелось бы услышать о
> перспективах Эльбруса а не Итаниума2
Эльбрусовцы это другие, я иха не знаю. :)
А про Итаники речь шла о платформе для SQL.
Диагноз был такой что, Оптероны и у тем более Зеоны
генерят кучу ошибок, и масса времени проца уходит на
повторы и исправления. Про Powerы_ы - то что они сцуки,
хороши только на AIX, под который надо переписывать/дописывать софт.
Так как портабельный софт не использует всех возможностей ни AIX ни Power. :(
По секрету: Бабло на Итаники не дали, купили Оптеронов :)
| | |
| |
| 6.37, vle (ok), 01:48, 09/12/2010 [^] [^^] [^^^] [ответить]
| +/– |
 >>> Я вот даже не знаю, но почему-то исследованиям сотрудников РАН и МГУ
>>> больше верю,
>>> о том что Итаниум2 на данный момент лучший проц в галакитке.
>> Смотря для чего лучший...
>> К тому же от сотрудников РАН и МГУ хотелось бы услышать о
>> перспективах Эльбруса а не Итаниума2
> Эльбрусовцы это другие, я иха не знаю. :)
"Тот самый Эльбрус" - это Бабаян, а Бабаян -- это еще и "новый Эльбрус",
который вроде почти умер с тех пор, как Бабаяна купил Intel.
А "новый Эльбрус" -- этот тот самый, который рвал как Тузик грелку
Mersed-а IIRC в конце 90-х, а Mersed -- это тот самый Итаник, который
вот те самые люди из РАН и МГУ хвалят за VLIW, а VLIW -- это ...
> Про Powerы_ы - то что они сцуки,
> хороши только на AIX, под который надо переписывать/дописывать софт.
Ну что за бред. Игровые приставки работают
практически полностью на семействе Power.
| | |
|
|
| 4.38, nagual (ok), 04:10, 09/12/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Я вот даже не знаю, но почему-то исследованиям сотрудников РАН и МГУ
> больше верю,
> о том что Итаниум2 на данный момент лучший проц в галакитке.
Первый вопрос про какую галактику речь ?
И второй где они берут такую траву ?
ЗЫ РАН это дармоеды ... история с фильтрами для воды весьма показательна.
| | |
|
|
| 2.32, User294 (ok), 19:16, 08/12/2010 [^] [^^] [^^^] [ответить] | +/– | Потому что уткнулись в пределы улучшения 1 ядра - есть существенные барьеры в пр... большой текст свёрнут, показать | | |
| |
| 3.39, nagual (ok), 04:19, 09/12/2010 [^] [^^] [^^^] [ответить]
| +/– |
> Гонка гигагерцев налетела на
> физические ограничения технологий.
Единственно что мешает далнейшему развитию это патентные войны.
> Итаниум? Итаник! Задуман мощно, система команд внушает. Но ... но где он?!
> АМД с своим амд64 + интел с своим жлобством практически на
> пару его закопали, живьем. Потому что АМД64 - дешево, сердито, работает.
> А больше покупателей ничего особо и не волнует. Вот и вышел
> у интеля итаник.
Даже несмотря на навязчивую рекламу интела, везде гне надо, ненадо и даже совсем ненадо :-) амд покупают. Недавно смотрел обзор на украинском оверклокере - еще один тест процессора. В начале статьи более менее а на последней странице скрины какие то совсем левые вместо ддр3 в тесте вдруг появилась ддр2 ... автор непроводил тесты а просто написал статью. Реь идет о амд процессоре ...
>> спарк - ни в пиз...у ни вж...у :)
Спарки это готовые решения как маки в десктопном сегменте так спарки в серверном. В частности R3 ...
| | |
| |
| 4.49, fidaj (ok), 13:17, 09/12/2010 [^] [^^] [^^^] [ответить]
| +/– |
 >> Гонка гигагерцев налетела на
>> физические ограничения технологий.
> Единственно что мешает далнейшему развитию это патентные войны.
Войны - это единственный быстрый и надежный способ регулировки численности популяции homoerectus на планете...
| | |
|
| 3.43, www2 (ok), 09:07, 09/12/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
 По-моему Power нифига не умер, а очень даже здравствует на серверах IBM. x86 и x86_64 не годятся ему в подмётки по одной причине - они работают с памятью по одной шине, а Power в компьютерах IBM - по NUMA. То есть процессорные ядра и блоки памяти связаны между собой через коммутационную матрицу. В своём классе задач эти системы просто незаменимы, так что скорее всего Power не только не сдох, но будет жив ещё очень долго.
| | |
|
|
| 1.19, johnjoy (??), 15:32, 08/12/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Имхо, логично вполне.
Было 2 разработки - Rock и CoolThreads (T1/2/3), нацеленные на разные задачи - первый для СУБД, ERP и пр OLAP-подобные задачи, второй на многопоточные (более) легкие приложения.
CoolThreads вполне успешно выпустили, довели до ума ко второму релизу, знатная молотилка получилась.
А вот Rock умер так и не родившись - и Oracle оказалась в ситуации, когда они имеют отработанные и перспективные железные технологии - но, увы, совсем не для их флагманского продукта.
Даже хорошо, что вместо того, чтобы забыть спарк и дать ему потихоньку умирать - стали допиливать и адаптировать то, что имеют.
К тому же CoolThreads довольно специфичны: нужно еще постараться (и админством и программированием), чтобы разогнать их до потенциала.
| | |
| 1.21, Square (ok), 15:36, 08/12/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Правильная мысль.
Что производительнее, MPP из сотни 386 или один пентиум?
Один пентиум.
Как говаривал классик - вся ваша конница не заменит одного подростка с фаустпатроном...
| | |
| |
| 2.35, User294 (ok), 20:04, 08/12/2010 [^] [^^] [^^^] [ответить]
| –2 +/– |
> Что производительнее, MPP из сотни 386 или один пентиум?
> Один пентиум.
А что проще, дешевле и технологичнее - воткнуть 2 проца на 3ГГц или один но на 6? Может быть, нынче немного иные технологические проблемы чем в девяностые? Чтобы проц на 6ГГц не зажарился - потребуется жидкий азот в системе охлаждения... всего-то так, ага ;)
А что до производительности - от задач зависит. На ряде задач пень упрется в свою тормозную память, которая не сильно лучше чем у 386. А у 386 она у каждого своя. Так что у сотни процов в 100 раз больше бандвиза памяти чем у одного. Профит, ага. Да и просто отгрузка вебпаг кластером из 100 386-х будет пожалуй лучше чем одним несчастным пеньком, за счет того что винт и сетевуха у пня ну никак не в 100 раз лучше, пардон :)
| | |
| |
| 3.40, nagual (ok), 04:24, 09/12/2010 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
> проблемы чем в девяностые? Чтобы проц на 6ГГц не зажарился -
> потребуется жидкий азот в системе охлаждения... всего-то так, ага ;)
> А что до производительности - от задач зависит. На ряде задач пень
> упрется в свою тормозную память, которая не сильно лучше чем у
> 386. А у 386 она у каждого своя. Так что у
> сотни процов в 100 раз больше бандвиза памяти чем у одного.
> Профит, ага. Да и просто отгрузка вебпаг кластером из 100 386-х
> будет пожалуй лучше чем одним несчастным пеньком, за счет того что
> винт и сетевуха у пня ну никак не в 100 раз
> лучше, пардон :)
Вообще у процессора кеш сильно греетца, а сама молотилка не очень.
| | |
| |
| 4.41, Square (ok), 06:08, 09/12/2010 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
>> потребуется жидкий азот в системе охлаждения... всего-то так, ага ;)
>> А что до производительности - от задач зависит. На ряде задач пень
>> упрется в свою тормозную память, которая не сильно лучше чем у
>> 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 - то суммарная частота получится в ВОСЕМЬ раз больше чем у предыдущего кандидата примерно такой же производительности.
Определенно, один фаустпатрон - лучше конницы :))
| | |
| |
| 5.48, svv (??), 12:39, 09/12/2010 [^] [^^] [^^^] [ответить]
| +/– |
Это кто же тебя учил умножать частоту на число ядер?
| | |
| |
| 6.50, Square (ok), 13:56, 09/12/2010 [^] [^^] [^^^] [ответить]
| +/– | |
> Это кто же тебя учил умножать частоту на число ядер?
А в чем проблема? Смысл многоядерности как раз в том, чтобы решать задачу параллельно...
Решается задача при этом на каждом из узлов с некой скорость зависящей от частоты...
Суммарная производительность реальных систем состоящих из множества процессоров работающих на некой частоте - никогда не достигает производительность процессора работавшего бы на этой эквивалентной частоте. Что хорошо видно в списке top500. Весь ВОЗМОЖНЫЙ прирост производительности "съедают" накладные расходы.
Именно по этому, на практике - такую операцию как сделал я- умножил частоты на количество процессоров- люди не делают, потому что заранее известно что производительность в мультипроцессорных системах не растет линейно.
Если вас смущает умножение частоты на ядра - можете перевести частоту во время исполнения одного такта и этот показатель умножить на число ядер. Число которое получится- будет показывать за какое время мультиядерная система совершит тот же (эквивалентный) объем вычислений.
| | |
|
|
|
|
| 2.44, filosofem (ok), 09:12, 09/12/2010 [^] [^^] [^^^] [ответить]
| +/– |
> Правильная мысль.
> Что производительнее, MPP из сотни 386 или один пентиум?
> Один пентиум.
> Как говаривал классик - вся ваша конница не заменит одного подростка с
> фаустпатроном...
Вы "правильную мысль" до конца не дочитали. Вот дублирую для писателей не читателей:
"Компенсировать снижение числа ядер внутри одного CPU, сможет увеличение числа CPU-сокетов в серверных платформах будущего от компании Oracle. Например, к 2013 году прогнозируется использование до 8 сокетов, а в 2014 году число сокетов в одном сервере достигнет 64."
| | |
| |
| 3.51, Square (ok), 15:31, 09/12/2010 [^] [^^] [^^^] [ответить] | –1 +/– | gt оверквотинг удален Правильность мысли заключается в работе над улучшением а... большой текст свёрнут, показать | | |
| |
| 4.52, filosofem (ok), 15:50, 09/12/2010 [^] [^^] [^^^] [ответить]
| +/– | |
>Экстенсивный - это развитие "вширь", связанный с количественным, а не качественным изменением, увеличением числа ядер в кристалле.
А увеличение числа сокетов до 64 это стало быть интенсивный путь?
| | |
| |
| 5.53, Square (ok), 15:56, 09/12/2010 [^] [^^] [^^^] [ответить] | +/– | Вы как-то избирательно читаете новость Они оптимизировать потоки собираются В... большой текст свёрнут, показать | | |
| |
| 6.55, filosofem (ok), 16:30, 09/12/2010 [^] [^^] [^^^] [ответить]
| +/– |
Цитата опять же для нечитателей из оригинала:
"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 раза, смотрите бенчмарки однопоточный приложений.
Теперь задумаемся, ок?
Один производитель оптимизирует архитектуру и увеличивает количество ядер.
Другой производитель собирается оптимизировать архитектуру и уменьшает число ядер, зато зверски увеличивает количество сокетов.
Ну и кто здесь конница, а кто с фаустпатроном?
И главный вопрос: кто в каске? =)
| | |
| |
| 7.56, Square (ok), 16:37, 09/12/2010 [^] [^^] [^^^] [ответить]
| +/– | |
> И главный вопрос: кто в каске? =)
Может быть тот, кто путает серверную платформу и отдельный процессор?
И если вам любопытно -то вот ваше "зверски увеличивает числа сокетов" шо называется в железе:
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 году...
То есть на рынке такие системы есть, они востребованы, и Оракл в этом плане не собирается отставать...Вот об этом говорит эта ремарка.. А не о "компенсации".
| | |
| |
| |
| 9.61, Square (ok), 23:33, 09/12/2010 [^] [^^] [^^^] [ответить] | +/– | Это вопрос не ко мне, а к тому кто писал статью Автор статьи считает что у Ор... текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
| 1.45, Engineer (??), 10:21, 09/12/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Интересно а что мешает Ораклу оптимизировать потоки с существующим количеством ядер в процесоре?
| | |
| |
| 2.65, balex (??), 07:02, 11/12/2010 [^] [^^] [^^^] [ответить]
| +/– |
> Интересно а что мешает Ораклу оптимизировать потоки с существующим количеством ядер в
> процесоре?
Теоритически оракле ничего не мешает. Им даже теперь не мешает оптимизировать проц под архитектуру СУБД. Заточить конвеер, добавить инструкции просчёта хэшэй, обсчёт групповых интексов и .т.д. и т.п. Тут только мешает "потолок" полёту мыслей. Ну и как известно народу, плохому танцору уже ничего не мешает, жаль человека :)
| | |
|
| 1.54, Аноним (-), 15:57, 09/12/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
двух ядер процессору вполне достаточно. просто пора уже ОС делать двух-ядерными, а не гнаться за радужными мыльными пузырями
| | |
|
