Sun планирует (http://www.theregister.com/2007/07/26/sun_2048_thread_niagara/) в 2008 году выпустить систему c 2048 CPU потоками (четыре 16-ядерных процессора Rock, с разделением на 32 потока в каждом ядре, возможно появление Rock с 64 потоками на ядро). Для ОС сервер будет выглядеть как SMP система с 2048 CPU.
URL: http://www.theregister.com/2007/07/26/sun_2048_thread_niagara/
Новость: http://www.opennet.me/opennews/art.shtml?num=11574
Нехило так... =)
Это какой нужен монитор, чтобы в винде диспетчер задач на вкладке "быстродействие" открыть
Винда столько процессоров не поддерживает. Также не поддерживает SPARC
Сила в простом. Умножить одно на другое и получить МЕГАтретье. Осталось вообразить себе кластер из таких машинок.
осталось переписать софт и оптимизировать ядро для такого монстра =) или может патчи на ядро уже есть???
Солряке один фиг на чем работать, на одном ядре, или 2048, там уже все давно работает как надо.
да-да, "все нормально, у нас спинлоки", бугога. ОС масштаба предприятия. тьфу, ей-богу. сначала запустите на 2048way, потом рот раскрывайте. в 2008 ... бугога
Опять бестолковая погоня за попугаями. Еще придется поискать задачи, которые будут эффективно решаться подобной архитектурой.
А остальном это просто сшибалово денег с лохов, которые между собой меряются всем что имеется...
Вы о прогрессе что нибудь слышали?
>Вы о прогрессе что нибудь слышали?Угу. Например, была хорошая машина на 4-х колесах. Производитель, Бац! и выпускает новую модификацию машины на 2048 колес?
По вашему это может быть и прогресс. А по-моему это гигантомания...
>Еще придется поискать задачи, которые будут эффективно решаться подобной архитектурой.Oracle
Oracle? C 2048 потоками? А данные все эти потоки откуда будут брать? Правильно, через одну шину данных.А какой там размер кэша? И сколько его приходится на один поток?
И каковы будут накладные расходы для того, что бы своевременно данные для всех этих потоков загружать в кэш.И будут эти потоки сами с собой и между собой "жить".
А деньги SUN-овцы возьмут в полном объеме. Они уж стесняться не будут...
GOTO http://www.opennet.me/opennews/art.shtml?num=11545
:)
Угу... С той же песни.
>Опять бестолковая погоня за попугаями. Еще придется поискать
>задачи, которые будут эффективно
>решаться подобной архитектурой.
>А остальном это просто сшибалово денег с лохов, которые между собой меряются
>всем что имеется...У вас слишком узкий взгляд. Чего там искать? Подбор паролей, сканирование действительно больших объёмов информации. Как минимум, военным пригодится.
а какова производительность одного ядра ?
Т-1 в этом отношении не сильно порадовал
не зря же они говорят о поточных приложениях.
есть неплохая статья об архитектуре и особенностях: http://www.osp.ru/os/2007/05/4259887/
каждый поток выполняется относительно медленно, но суммарная "пропускная способность" процессора должна рвать конкурентов в куски.
естественно, для линейных задач этот процессор совершенно бесполезен.
Это вам приложение надо потоковое. К примеру на таких ящиках себя очень комфортно будут чувствовать различные СУБД и вебсервера.
Но почему-то ниагара в чистую сливает оптероном с ксеонами именно на СУБД и вебсерверах.
При-этом системы на x86 (даже продаваемые Sun) стоят в два-три раза дешевле.
http://www.tpc.org/tpch/results/tpch_price_perf_results.asp
от задач зависит, требований, софта, лицензирования итд итп..... Sun вполне на уровне....
Рвать он должен хорошо хотябы с темже Oracle на борту. Это реально крутая тачила получится!
сначала пусть солярку хотя бы там нормально запустят ... с ее децким локингом.
дешевый понт, дороже денег :)
вот тока не надо про oracle, на SunFire T2000(niagara T1) oracle показывает худшие результаты по сравнению со скажем SunFire v490(Sparc IV+)
Как не прискорбно... это правда.
Ниагара создавалась для веба. То, что она плохо будет работать с СУБД говорили еще при ее разработке. Нефть, напрмер, возят не самосвалами а цистернами, но почему-то у грузовиков такая спецификация ни у кого изумления не вызывает.
Ога, поставить базу и заплатить за каждый процессор ! не в оракле так ? напомните плз.
T2000 - это платформа для узкой ниши.
Удел T2000 - мелкие WEB-серверы, прокси-серверы, DNS-серверы, всякое вспомогалово, где не нужно особо сильно напрягаться с диском, ОЗУ, и плавающей точкой.
Запускать Оракель на T2000 просто глупо. Результат был известен заранее.
нада заметить что санки даже когда они ТРУБИЛИ о "самом самом " и что они де уже "три шага вперёд" от ... других :+) и то специально оговаривали о НИШЕВОСТИ ниагары
они специально оговаривали что ни бд ни счётные задачи для этого семейста не есть их лучшее применение "ибо"... вощем много там всего того что "ибо" ...
а вот эти роки которые они вроде как должны будут и счётчиками хорошими быть так что оракел и всё прочее считающее и пишущее будет хорошо себя там типа чувствовать ...
и мне в это верится ...
но вот что действительно реальность - дак это, что в наше время прогеры и их продукты НЕ поспевают за изменениями и нововведениями жезезячных вендоров ...
>но вот что действительно реальность - дак это, что в наше время
>прогеры и их продукты НЕ поспевают за изменениями и нововведениями жезезячных
>вендоров ...Это так потому, что аппаратурщики сами с собой играются не обращая внимания на потребности системщиков. Сексопатология.
Для кого-то озвученные вами ниши и есть production.
А всякие мелкие серваки с DB - это так, мишура, бекенд.
Во всяком случае для ISP это очень хороший вариант - вместо горожения кластера из десятков тормозных (для задач почты, DNS и пр) узлов вполне можно будет обойтись кластером из двух узлов (что на порядок проще).
угу, в точку про отставание софта. ещё пяток лет, если не все десять уйдут на "переформирование индустрии" на кучу-цати-ядерность (если оно вообще будет завершено - это переформирование)
>угу, в точку про отставание софта. ещё пяток лет, если не все
>десять уйдут на "переформирование индустрии" на кучу-цати-ядерность (если оно вообще будет
>завершено - это переформирование)Будет как с Merced/Itanium: пока делали процессор и компиляторы оказалось что вместо такой революции проще и дешевле делать многоядерные.
нада заметить что как бы эти "5 десят лет " уже идут и давольно давно :+)у мени друг в качестве диплома писал парсер к компилятору языка программирования который заточен под паралельное программирование (может неверный термин - имлось ввиду что программы будут писатся под много много ядерную архитектуру ...)
и было это в 2001 году ...
тобишь подготовка то есть ...
только вот как уже замечалось выше "Сексопатология" железячников имеет место быть в том смысле а может оно и не нада ...
хотя как там говорили:
" ...если бы все думали как ты, то мир не узнал бы всех прелестей анального секса" :+)))
Что самое прикольное, даже на такой машине OpenOffice будет долго думать
Зато на ней сможет долго думать одновременно 2048 опенофисов. ;)
>Зато на ней сможет долго думать одновременно 2048 опенофисов. ;)Херня! зато это будет быстрее, чем запустить 2048 опенофисов на одном и ждать результата :-) ))
Pashke:
> Это какой нужен монитор, чтобы в винде диспетчер задач на вкладке "быстродействие" открыть:)
northbear:
> Опять бестолковая погоня за попугаями. Еще придется поискать задачи, которые будут эффективно решаться подобной архитектурой.Лично у меня создалось ощущение, что развитие современных писюков остановилось, т.к. практически все возможные задачи можно решать на существующих машинах, а более продвинутые задачи (типа голографического изображения) находятся далеко запределами возможностей. Кстати, голография как раз отлично распараллеливается.
> А данные все эти потоки откуда будут брать? Правильно, через одну шину данных.
Вовсе необяз%