The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Oracle переходит к сокращению числа ядер в следующем поколении процессоров SPARC

08.12.2010 12:20

Компания Oracle изменила стратегию усовершенствования процессоров SPARC, вместо практикуемого другими производителями наращивания числа процессорных ядер, в следующем поколении процессоров Sparc (T4) число ядер будет сокращено в два раза. Все усилия инженеров будут сосредоточены на оптимизации производительности отдельных потоков, так как по результатам исследования именно данная область является слабым звеном присутствующих на рынке CPU Sparc.

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

В соответствии с опубликованным планом, процессор Sparc T4 будет иметь 8 ядер (в поставляемом недавно Sparc T3 задействовано 16 ядер по 8 потоков в каждом, для ОС такой CPU выглядит как SMP-система с 128 процессорами) и заметно увеличенный размер внутреннего кэша. Производительность отдельных потоков обещают увеличить в три раза. Компенсировать снижение числа ядер внутри одного CPU, сможет увеличение числа CPU-сокетов в серверных платформах будущего от компании Oracle. Например, к 2013 году прогнозируется использование до 8 сокетов, а в 2014 году число сокетов в одном сервере достигнет 64.

Дополнение: Компания Oracle объявила о начале портирования дистрибутива Oracle Enterprise Linux на платформу SPARC.

  1. Главная ссылка к новости (http://www.pcworld.idg.com.au/...)
  2. OpenNews: Компания Oracle дала обещание форсировать развитие SPARC и Solaris
  3. OpenNews: Книга про внутреннее устройство процессоров OpenSPARC
  4. OpenNews: Компания Sun Microsystems наградила лучших участников проекта OpenSPARC
  5. OpenNews: Компании Sun Microsystems и Fujitsu представили процессор SPARC64 VII
  6. OpenNews: Sun перевел CPU Niagara 2/UltraSPARC T2 в разряд открытых проектов
Лицензия: CC-BY
Тип: К сведению
Короткая ссылка: https://opennet.ru/28919-Sparc
Ключевые слова: Sparc, cpu, oracle
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (64) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Max (??), 13:00, 08/12/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Надоело Футжикам деньги за SPARC64 отстегивать?
     
  • 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.29, Толстый (ok), 16:56, 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.4, Аноним (-), 13:23, 08/12/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Ага, значит теперь Лари решил и железо санок под откос пустить.
     
  • 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.

     
  • 5.30, psiho (?), 18:10, 08/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    так старые эльбрусовцы по моему и попали в комаду итаниума
     
  • 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 году...
    То есть на рынке такие системы есть, они востребованы, и Оракл в этом плане не собирается отставать...Вот об этом говорит эта ремарка.. А не о "компенсации".

     
     
  • 8.57, filosofem (ok), 19:09, 09/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Это тоже правильная мысль да Так же как и эта Видимо все мысли Оракла по опре... текст свёрнут, показать
     
  • 8.60, Anon Y Mous (?), 23:15, 09/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    А CS6400, Ultra Enterprise 10000, Sun Fire 15K, Sun fire E25k и M9000-64 конечно... текст свёрнут, показать
     
     
  • 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 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    двух ядер процессору вполне достаточно. просто пора уже ОС делать двух-ядерными, а не гнаться за радужными мыльными пузырями
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2021 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру