Вот это уже реальная польза.

так спарки все таки rip?

>так спарки все таки rip?

угу. а теперь интель через негрософт с помощью сан зарипает amd :(

Sparc не RIP хотябы из-за Fujitsu. AMD польза будет - у SUNа огромный опыт создания многопроцессорных систем, чего у АМД нет вовсе. Напомню, что в свое время SUNу досталась половина Крея вместе с разработчиками, а разработки Крея до сих пор считаются эталонными в плане реализации многопроцессорных архитектур. Кроме того, SUN примерно на два года опережает Intel/AMD в плане многоядерных архитектур, и тут АМД тоже есть чего перенять. В общем, если посмотреть непредвзято на железо SUN, то много чего хорошего, что не помешало бы АМД можно там найти. :) Другое дело, что АМД не позиционировал себя до этого как производитель платформ.Хотя чем черт не шутит, может скоро придется вместо серверных мамок RioWorks покупать мамки АМД?

SUN

> Sparc не RIP хотябы из-за Fujitsu.
гы-гы - а на семинаре Павел Анни сказал что сан продаёт в год 320 000 систем а фудзицу - около 15 000. так тчо если что фудзицу не спасёт ОРД. Другое дело что Сан объявил о выпуске в начале 2006 г Niagara,
уделывающего на 1,2G (32 потока и 60W!) кипятильник тип PIV dualcore с его 200W.

на самом деле очень удачный союз, ниши у спарков и у оптеронов разные, сантехники знают что делают, бабки будут рубить и там и тут =)

Может будет ещё один никому не нужный итаник от AMD & SUN ?

Маргиналы нашли друг друга...

> Другое дело что Сан объявил о выпуске в начале 2006 г Niagara,
> уделывающего на 1,2G (32 потока и 60W!) кипятильник тип PIV dualcore с
> его 200W.

1) во первых пусть сначала выпустит а там и сравним
2) почитай ради интереса что там выпустит интель или амд в 2006 году

%)))

Новость не может не радовать)

SUN

> почитай ради интереса что там выпустит интель или амд в 2006 году
дык а чо читать - и так понятно что интель со своими итаником и прожорливым монстром PIV в тупик зашёл - недаром PIII реанимировали (под другим именем правда).
А AMD сану не конкурент, а стратегический партнёр.
у них ниши несколько разные, слабоперекрывающиеся.

Aha, vse kto ne intel i ne microsoft - marginaly, i voobwe otstoj. I zachem ja zhivu? Gde tam vash bioreaktor? pojdu zdavat'sia :))

> А AMD сану не конкурент, а стратегический партнёр.

ага, оптерон прошибить у санок кишка тонка, так запишемся в партнеры.
как это там было типа "если враг сильнее тебя, подружись с ним"

А SUN не хочет заодно поучавствовать в конкурсе ложечников? Или с жабой дела настолько плохи, что приходится одной жопой прыгать на все стулья?

> 2) почитай ради интереса что там выпустит интель или амд в 2006 году

Интел вообще не собирается в 2006-м ничего нового выпускать

>А SUN не хочет заодно поучавствовать в конкурсе ложечников? Или с жабой дела настолько плохи, что приходится одной жопой прыгать на все стулья?

Хм. Представил себе. Какого же размера тогда, по-вашему, должна быть жопа IBM, чтобы сидеть сразу на тысяче стульев и постоянно делать себе новые стулья? :)

Бенефис аналитиков ЛОР :)))

А что кто то уже видал железки с 64 CPU AMD на борту? О чем спорим?

АМД - это сервера начального уровня (для яслей, школ и ПТУ).

А выше это уже Advanced Product Line (APL) там будут Niagara и Fujitsu Sparc64 VI.

ну вот пришёл саныч и развеял всё надежды ;)

//alex

> так спарки все таки rip?

Sun с Fujitsu-Siemens партнеряться в развитии линейки SPARC. У меня есть ощущение, что они попытаются объединить обе архитектуры, хотя я не знаю, возможно ли это...

Тоже мне, аналитик. Для почтового релея тоже будешь Sun Fire покупать? Иногда без лишних сложностей - проще.

А при чем тут релей?

Теза в том, АМД просто выгоден на данном этапе, вот с ним и сотрудничают, раньше делали сервера на Xeon, будет выгодно будут делать на каком нибудь Xeon-64++. Но при любом раскладе, серьезное железо будут
делать на своих чипах.

Спарки RIP. Еще маркетёры потреплятся малька о том, что 128 процовый Ultra-Super-Puper SPARC - это типа "майнфрейм", однако народ на местах ушлый и понимает, что можно собрать более дешевую и более производительную стоечку на AMD Opteron серваках форм-фактора U1.

Следующий RIP - Солярка, потом Сан бросит в /dev/null весь свой софт и будет устанавливать на свои компы Microsoft Windows Vista.:)

> А что кто то уже видал железки с 64 CPU AMD на борту? О чем спорим?

http://forums.amd.com/lofiversion/index.php/t41706.html
речь идет в основном о 8 процессорныx системах.

это для какого детсада ? и что интересно в твоем детсаде ?

> с 64 CPU

1) Если собрать 9 беременных женщин со сроком беременности в 1 месяц, то ни одна из них не родит через месяц.

2) Если заставить копать колодец с диаметром в 1 метр 10 землекопов, то они не выкопают его быстрее одного землекопа.

Масяныч, а тебе про правило 80% в твоём детском садике не еще не рассказывали? Тогда кури букварь и продолжай смешить народ дальше. А пока отдыхай.

саныча не трогай!
существует некоторое количество задач которые хорошо распаралеливаются
например сборка ядра :)

Ну да, чо там действительно, маргиналы, не маргиналы. А на самом деле линукс последние гвозди забивает в гроб SUN. Вот их и кидает из стороны в сторону, где бы обьедки подобрать.

Что такое 'Vista'?

rem offtopic

А что означает слово "Vista"? В последнее время употребляется вместе со словами "Microsoft" и "Windows", я что-то пропустил?

Нда, отвечаю сам себе - http://channels.lockergnome.com/news/archives/20050722_overview_what_is_micro...

> существует некоторое количество задач которые хорошо распаралеливаются

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

и чем слабее процессор тем больше допустимое количество процессоров в системе при прочих равных условиях %)))

>саныча не трогай!

присоединяюсь. а то испачкаешься или заразишься гадостью какой нибудь. лучше с ноги, пинками

просто не имеет смысла его увеличивать - шина, память, ввод-вывод станут ограничивать производительность

Идиот, ты почитал бы сначала про современные НЕ ПИСЮКОВЫЕ SMP архитектуры, а потом бы тут вякал.

>существует некоторое оптимальное значеник количества процессоров, выше которого просто не имеет смысла его увеличивать - шина, память, ввод-вывод станут ограничивать производительность, накладные расходы и т.д. начиная с такого момента кластеры эффективнее.

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

>и чем слабее процессор тем больше допустимое количество процессоров в системе при прочих равных условиях %)))

откуда вы взяли такую траву? Или вы исходили из тепловыделения?да, предствил себе сотню-другую PIV в одном корпусе - страшно стало.

>vlTepes (*) (27.07.2005 10:46:11):...откуда вы взяли такую траву? Или вы исходили из тепловыделения?да, предствил себе сотню-другую PIV в одном корпусе - страшно стало.

Зато там пирожки печь можно :)

2 Tester << существует некоторое оптимальное значение количества процессоров >> Это справедливо для интел процессоров - итаниум, хеон. Они в многопроцессорных конфигурациях делят ресурсы одной общей шины. Следовательно все вопросы согласования, взаимных блокировок, узости общей шины ограничивают реальное число многопроцессорности для интел процессоров неким максимумом, по моему 127 .

В этом смысле АМД процессоры находятся в несравнимо лучшей ситуации. У них много шин для связи процессоров друг с другом, благодаря этому они отлично масштабируются.

Однако их способности к масштабированию лежат между интелом как неким условным минимумом масштабирования и максимумом масштабируемости у сан и ибм процессоров.

Ну и наконец истинная правда, что не все задачи можно распаралелить, как утверждает математическая теория. Для этих задач всегда 2х1000 = 1000 .

> Некорректное высказывание. Ввод-вывод в общем случае к количеству
> процессоров отношение имеет очень слабое и по крайней мере от
> лишнего процессора хуже не становится.

становится. эффективность падает. процессор сидящий в кластере в это время не простаивает. предположим имеем дисковый массив на таком суперкомпе. предположим идет к нему конкурентный доступ со всех задач на всех процах. грубо говоря на каждый процессор приходится тем меньшая доля пропускной способности массива чем больше этих процов => производительность задачи на дисковом доступе падает.
то же самое касается и скажем сетевого интерфейса. предположим пусть у него интерфейс (или интерфейсов) на 10 гбит - какая полоса придется на каждый проц в 64 процессорной системе ? и сколько в 8 процессорной

ставить для каждого проца свой ввод-вывод ? придется привязывать свою задачу к своему процессору => ничем кроме организации связи между нодами такая система от кластера отличаться не будет.

> Что касается ограничений, накладываемых на рост производительности
> особенностями архитектуры (а судя по умоминанию шины, у вас
> представление об архитектуре на уровне ПК только), то тут все
> зависит от архитектуры как раз.

я имел в виду совсем другую шину. коммутатор - не знаю как это называется на современный лад, но в пору моей молодости он назывался так - то есть устройство которое обеспечивает связь процессоров между собой. если вспомнить организацию транспьютеров - каждый проц имел свою память и контактировал с окружающими посредством коммутатора. так вот этот самый коммутатор должен обеспечивать прямой связью между собою любые два процессора в системе (он и есть шина) а значит сложность его возрастает пропорционально квадрату количества процессоров в системе. допустимая сложность а значит и цена этого коммутатора при том что вклада в производительность он не вносит и ограничивает допустимую сложность системы целиком. думаю поэтому оптероны и выпускаются модификаций - на 2, 4 и 8 процов в системе.

вот саныч хвалится 64 процессорными спарками - а почему не выпускаются 256 или 1024 процессорные системы ? разве на систему такой мощности не будет спроса ? да просто они стоить в силу вышеуказанных причин будут на порядки дороже кластера сравнимой производительности.

приведу аналогию - производительность свичей ограничена внутренней пропускной шиной - и хоть разорвись 32 портовый свитч на 100 мегабит не обеспечит 100 мегабит в 16 пар (16 гбит) при внутренней пропускной шине в 5 гигабит. в данном случае эффективнее будет взять две 16 портовки - он обеспечит лучшую производительность. кому нибудь встречались свитчи на 128 портов ?

> Кластеры не могут быть эффективнее, по банальной причине -
> параллелелизм с быстрой связью всяко эффективней такогово с \
> медленной. На некоторых задачах кластер может быть почти так же
> эффективен, но никогда более эффективен.

вот уж нет. во первых - если задача распаралеливается то кластер может быть эффективнее. по той простой причине что кластер масштабируется до бОльших систем чем многопроцессорная система. сумеет ли кластер в котором 128 или 256 спарков побить 64 спарковый компьютер ? разумееся, если только распаралеливаемая задача не требует уж очень большого межпроцессорного обмена.
во вторых - эффективность это не производительность. в данном случае под эффективностью я подразумевал отношение производительности к цене. кластер который рассчитывает задачу за 1 сутки может и чаще всего оказывается дешевле 64 процессорного монстра который рассчитывает эту же задачу за те же сутки.

> Идиот, ты почитал бы сначала про современные НЕ ПИСЮКОВЫЕ SMP
> архитектуры, а потом бы тут вякал.

я читал про старые - до 1990 года. что-то сильно изменилось ? кстати тогда выпускали 1024+ процессорные системы. покажи мне стольки же процессорный спарк.
а, смысла нет ? во что все упрется ?

> магистраль межпроцессорной связи

вот что я имею в виду под шиной, я бы сказал "шина межпроцессорной связи"

> А SUN не хочет заодно поучавствовать в конкурсе ложечников? Или с жабой дела настолько плохи, что приходится одной жопой прыгать на все стулья?

Каждый мнит себя стратегом, видя бой со стороны. Ты хоть что-нибудь в жизни сделал, мой юный, частично образованный друг? Или если ты разок-другой подержался за клавиатуру, то решил что ты теперь опупенный специалист, который ремарки может раздавать?

> НЕ ПИСЮКОВЫЕ SMP архитектуры
эээ, вероятно ты хотел сказать NUMA архитектуры

Какие нафик 100Mb свичи, ты про латентность когда-нибудь слышал ?

Беспорно есть задачи, в основном счетные, где хоть по email-у данными обменевайся не сильно замедлит, но представь сколько общих блокировок внутри AS или серьезной БД ?

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

> Какие нафик 100Mb свичи, ты про латентность когда-нибудь слышал ?

в смысле ? 100 мбит никоим образом в любом случае не выйдет ? так то же для примера. представь 90 мбит в среднем в 16 пар - это изменит суть примера ?

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

а что я ? вот объясни это санычу - он похоже думает что можно сколько угодно наращивать количество процессоров. я же всего лишь сказал что выше некоторого предела наращивать количество процессоров (в силу принципиальных архитектурных органичений и стоимости) не имеет смысла.

> в смысле ? 100 мбит никоим образом в любом случае не выйдет ? так то же для примера. представь 90 мбит в среднем в 16 пар - это изменит суть примера ?
да хоть 10 GE, я про НАНОСЕКУНДЫ, представь разницу между записью в не локальную память (возможно через мосты) и полным цыклом досавки ethernet пакета, в результате приложеные на твоем кластере парализовано не эффективной синхранизацией.

> он похоже думает что можно сколько угодно наращивать количество процессоров
сколько угодно нельзя, больше мостов больше латентность, а принципиальные архитектурные органичения как раз у кластеров

>будет взять две 16 портовки - он обеспечит лучшую производительность. кому нибудь встречались свитчи на 128 портов ?

Вы будете смеяться, но я встречал свичи на 512 портов GE. :) И должен вам сказать, что их даже сравнивать нельзя с 16 портовыми собратьями. Примерно также можно сравнивать программируемые калькуляторы c теми же мейнфреймами.

Что касается кластеров. Кластеры, имеют главную проблему в медленной связи между узлами. Для задач с слабосвязанными данными это годится, для задач с сильносвязанными - нет. В результате кластер имеет ОЧЕНЬ узкую область применения.

> да хоть 10 GE, я про НАНОСЕКУНДЫ, представь разницу между записью в не
> локалью память (возможно через мосты) и полным цыклом досавки ethernet
> пакета

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

во вторых - причем тут эзернет ? есть специализированные решения для кластеров. в принципе можно хоть по scsi ноды соединить. мне как-то на эту тему хаутушка попадалась.

и в третьих - насчет латентности я выше оговаривался - "если задача не требует уж очень большого межпроцессорного взаимодействия"

> сколько угодно нельзя, больше мостов больше латентность, а
> принципиальные архитектурные органичения как раз у кластеров

а вот и нет - "больше мостов больше латентность" это принципиальное архитектурное ограничение. если предположить что межпроцессорная шина - это типа общая шина с разделением по времени - то мы быстро натыкаемся на bottleneck. если это типа numa - своя память ближе, чужая дальше то все зависит уже от его организации - если опять таки по типу общей шины - то натыкаемся на bottleneck при чуть большем количестве процессоров - если же шина построена по типу коммутатора n*n - то bottleneck имеем при еще большем количестве процессоров но усложняется серьезно сам коммутатор.

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

> Вы будете смеяться, но я встречал свичи на 512 портов GE. :)

конечно - только внутри он представляет собой 8 32 портовок включенных в 1 восьмипортовку. это грубое приближение конечно.

> Что касается кластеров. Кластеры, имеют главную проблему в медленной
> связи между узлами

я с этим не спорю. да у кластера более медленная связь между нодами - но он не ограничен в масштабах. многопроцессорные же компьютеры архитектурно ограничены в масштабе. загляните в top500 - много ли там не_кластеров ?

покажите мне 1024 процессорный компьютер ? а раньше такие чуть ли не массово производились.

> 8 32 портовок

мда, математика подвела. но сути это не меняет

>А что кто то уже видал железки с 64 CPU AMD на борту? О чем спорим?

С 64 процами AMD? Нет, не видел. А надо?

> во первых, ты не понял.
это ты не в курсе, http://www.pmc-sierra.com/10GE/

> во вторых - причем тут эзернет ? есть специализированные решения для кластеров. в принципе можно хоть по scsi ноды соединить. мне как-то на эту тему хаутушка попадалась.

да только обработка прерывания от этого устройства чего стоит

> и в третьих - насчет латентности я выше оговаривался - "если задача не требует уж очень большого межпроцессорного взаимодействия"
основной смысл в том как БЫСТРО, а не как много и это и есть принципиальное архитектурное ограничение кластеров.

> а вот и нет - "больше мостов больше латентность" это принципиальное ...
это принципиальное ограничение и компютеров и кластеров и ВК в общем, а очень высокая латентность с любым кол. узлов это принципиальное ограничение только кластеров.

> это типа общая шина с разделением по времени
каменный век ?

> АМД - это сервера начального уровня (для яслей, школ и ПТУ).

Меня от смеха аж согнуло. "Сервера для ПТУ" это мощно! :) :) :)

> основной смысл в том как БЫСТРО, а не как много

да ладно придираться, в общем мы друг друга поняли