https://217.65.3.21/openforum/vsluhforumID3/73156.html Компания Oracle изменила (http://www.pcworld.idg.com.au/article/370535/oracle_halve_core_count_next_sparc_processor/) стратегию усовершенствования процессоров SPARC, вместо практикуемого другими производителями наращивания числа процессорных ядер, в следующем поколении процессоров Sparc (T4) число ядер будет сокращено в два раза. Все усилия инженеров будут сосредоточены на оптимизации производительности отдельных потоков, так как по результатам исследования именно данная область является слабым звеном присутствующих на рынке CPU Sparc. <br><br><br>Несмотря на то, что число ядер благотворно влияет на производительность систем, задачи в которых разбиваются на множество мелких частей (например, обслуживание web-запросов или online-транзакций), для выпускаемых Oracle программных продуктов, таких как большие СУБД и ERP-приложения, гораздо важнее производительность отдельных потоков. По словам Ларри Эллисона, руководителя Oracle, выпуск Sparc T4 является критичной для компании задачей, в первую оче...<br><br>URL: http://www.pcw https://217.65.3.21/openforum/vsluhforumID3/73156.html#66 Mon, 13 Dec 2010 12:44:25 GMT немного оффтоп, но самый прикол во всех этих наращивания лезвий - это то, что каждый раз говорят, что их бритвы бреют идеально гладко. но с увеличеним количества лезвий оказывается, что 2-3-4 и т.д. уже не бреют :( <br> https://217.65.3.21/openforum/vsluhforumID3/73156.html#65 Sat, 11 Dec 2010 04:02:26 GMT &gt; Интересно а что мешает Ораклу оптимизировать потоки с существующим количеством ядер в <br>&gt; процесоре?<br><br>Теоритически оракле ничего не мешает. Им даже теперь не мешает оптимизировать проц под архитектуру СУБД. Заточить конвеер, добавить инструкции просчёта хэшэй, обсчёт групповых интексов и .т.д. и т.п. Тут только мешает "потолок" полёту мыслей. Ну и как известно народу, плохому танцору уже ничего не мешает, жаль человека :)<br> https://217.65.3.21/openforum/vsluhforumID3/73156.html#64 Sat, 11 Dec 2010 03:52:44 GMT &gt; Только мне кажется что они хотят увеличить количество ЦПУ чтто бы снимать <br>&gt; бабло за лицензии на камень для ОracleDB? Такое не прикрытое надувательство <br>&gt; ) <br><br>Дык вроде ядра тоже считаются в случае лицензирования. Или я напутал? В этом случае желание оракла уменьшить кол-во ядер понятны - уменьшить стоимость конечной лицензии СУБД. А далее народу проще впаривать - ходите дешевле - берите с малым кол-вом сокетов...<br> https://217.65.3.21/openforum/vsluhforumID3/73156.html#63 Fri, 10 Dec 2010 01:10:38 GMT &gt; Крамер подходит, afaik, для ручного счета небольших систем, но уж никак не<br>&gt; для машинного решения уравнений 1000+-порядка<br><br>Вы такую матрицу три года составлять будете. А уж посчитать за недельку можно.<br> https://217.65.3.21/openforum/vsluhforumID3/73156.html#62 Fri, 10 Dec 2010 00:51:00 GMT Крамер подходит, afaik, для ручного счета небольших систем, но уж никак не для машинного решения уравнений 1000+-порядка<br> https://217.65.3.21/openforum/vsluhforumID3/73156.html#61 Thu, 09 Dec 2010 20:33:12 GMT &gt;&gt; А Оракл ТОЛЬКО ПЛАНИРУЕТ увеличить число сокетов в системе до 64 к 2014 году... <br>&gt; А CS6400, Ultra Enterprise 10000, Sun Fire 15K, Sun fire E25k и<br>&gt; M9000-64 конечно же не существовало и не существует, да?<br><br>Это вопрос не ко мне, а к тому кто писал статью...<br>Автор статьи считает что у Оракла такие системы только в перспективе...<br>Хотя... с другой стороны - речь в статье может идти о системах на базе Т3, а СанФайр - это "старье" на базе UltraSPARC III <br> https://217.65.3.21/openforum/vsluhforumID3/73156.html#60 Thu, 09 Dec 2010 20:15:33 GMT &gt; А Оракл ТОЛЬКО ПЛАНИРУЕТ увеличить число сокетов в системе до 64 к 2014 году... <br><br>А CS6400, Ultra Enterprise 10000, Sun Fire 15K, Sun fire E25k и M9000-64 конечно же не существовало и не существует, да?<br> https://217.65.3.21/openforum/vsluhforumID3/73156.html#59 Thu, 09 Dec 2010 18:41:28 GMT &gt; - не параллелизуется. Если брать алгоритмы решенения систем алгебраических уравнений,<br>&gt; то, что на современных компах тоже относительно долго считается, то алгоритм<br>&gt; Гаусса-Зейделя тоже не параллелизуется.<br>&gt; Т.е. можно его частично превратить в алгоритм Гаусса, который можно распараллелить, но<br>&gt; он будет едва ли не медленнее считать.<br>&gt; И тут можно хоть 5000 000 000 штук PDP-11 поставить, всё равно<br>&gt; они будут считать со скоростью одной машины.<br><br>Распердолить матрицу на части равным количеству ядров/процов, <br>и методом,... как его там.., Крамера. <br>Вот и будет чем занять 5000000000 штук PDP-11 :)<br><br>Ах да, через алг. дополнения можно параллелить <br> https://217.65.3.21/openforum/vsluhforumID3/73156.html#58 Thu, 09 Dec 2010 17:28:15 GMT Дорогой Павлинукс, возьми практический любой алгоритм вычмата по нахождению корня уравнения - не параллелизуется. Если брать алгоритмы решенения систем алгебраических уравнений, то, что на современных компах тоже относительно долго считается, то алгоритм Гаусса-Зейделя тоже не параллелизуется. <br><br>Т.е. можно его частично превратить в алгоритм Гаусса, который можно распараллелить, но он будет едва ли не медленнее считать.<br><br>И тут можно хоть 5000 000 000 штук PDP-11 поставить, всё равно они будут считать со скоростью одной машины.<br>