>Какая тут собака еще ? применение переключения банков регистров...

Поясню о чем шла речь, если мы имеем большое количество вложенных вызовов, рекурсия например, то рано или поздно количество регистровых окон исчерпается и их содержимое будет необходимо сохранять в стеке. Поскольку функция, столкнувшаяся с невозможностью безболезненно взять себе очередное окно, будет вынуждена сохранять содержимое самого старшего окна в стек, то ей придется сохранять все содержимое окна даже если из него использовались всего пара регистров и перед выходом повторять все наоборот. А если не пользоваться регистровыми окнами то какое количество регистров получится реально использовать? В GNU C есть опция -mflat, но в этом случае просто генерится код без save/restore, и используется всего одно окно.

>зы:понавыдумывают себе проблем ...

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

> Это точно! Особенно если считаешь себя Д'Артаньяном, а всех остальных - идиотами ;)
особенно когда к этому просто вынуждают ;)

> окна были неплохой идеей, но явно устарели.
Itanium?

оглушительный успех! браво!

> Уверены, что сможете аргументированно и технически грамотно об этом беседовать?
gcc не писал, но представление об ассемблере имею.

> Про неоптимальность оставлю без комментариев. Особенно часть про "большинство задач".
в среднем функция использует до 10 переменных (не по моим наблюдениям). куда засунуть остальные регистры, используемые в 5% случаев?

> Вот когда Вы из разряда пользователей перейдете хотя бы в разряд программистов, а еще лучше - разработчиков CPU, разговор у нас будет более предметным.
мусье - разработчик ЦПУ? тогда мусье должен догадываться откуда ему деньги на зарплату берутся.

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

>> много вы серверов видели на 80960
> Intel Paragon? Только ради этого стоило делать чип. Причем тут сервера?

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

Все понятно. Технической дискуссии не получилось. Про Itanium - не ошибайтесь, его производительность пока покрывается только PowerCell8i (не тот Cell что в PS3, а тот, что в Roadrunner.)

> http://infocenter.arm.com/help/topic/com.arm.doc.ddi0210c/DDI0210B.pdf стр 2-8 & 2-9

> Banked registers are discrete physical registers in the core that are mapped to the available registers depending on the current processor operating mode.

Не катит, похоже: "In ARM state, 16 general registers and one or two status registers are accessible at any one time. In privileged modes, mode-specific banked registers become available". Насколько я понял, это вырожденный случай банка - для системных вызовов.

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

Рвет-то оно рвет, но как правило до определенного уровня нагрузки, после которого это самое лезвие на Интеле сдувается, а SPARC продолжает пыхтеть дальше...

Вот, кстати, пример: http://blogs.sun.com/mrbenchmark/entry/the_hare_and_the_tortoise

> Все понятно. Технической дискуссии не получилось.
ну да, вы правы. реальный мир несколько сложнее выхолощенных синтетических тестов

> Про Itanium - не ошибайтесь, его производительность пока покрывается только PowerCell8i (не тот Cell что в PS3, а тот, что в Roadrunner.)
жаль что вы не поняли простой вещи: абсолютные показатели производительности очень редко имеют приоритет. всегда (отбросим пару процентов чудаков, имеющих финансирование напрямую из ФРС) смотрят на ценник. и это правильно, т.к. в противном случае в мире по-прежнему рынок сбыта для компьютеров имел бы емкость 5-10 штук

за сим откланиваюсь. спорить нам не о чем, вселенные не пересеклись

> Рвет-то оно рвет, но как правило до определенного уровня нагрузки, после которого это самое лезвие на Интеле сдувается, а SPARC продолжает пыхтеть дальше...

так-то оно так, но только за ту небольшую разницу в цене я могу поставить не одно лезвие на зионах, а спокойно набить корзинку доверху, а остаток (стоимость еще 3-х таких же корзин) весело попилить^H^H^H^H^H сэкономить ;)

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

Если кончаются регистровые окна и начинается кэщ - ничего страшного.
1. Большинство функций у нас имеют малое колличество аргументов(как правило один и уж точно тех которые больше 6 мало). Не верите? Просканируйте исходники программ. По этому даже если придётся юзать кэш то на общем фоне это совершенно не страшно.
2. на спарках вы можете сами настраивать размер регистрового окна. так вот и эксперементируйте.

ЗЫ дома стоит UltraSparcII вполне себе удачно работает и позволяет мучать эту архитектуру.

> 2. на спарках вы можете сами настраивать размер регистрового окна. так вот и эксперементируйте.

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

http://web.spcoast.com/photos/albums/wpw-20090421/normal_DSCN9113.jpg http://web.spcoast.com/photos/albums/wpw-20090421/normal_DSCN9114.jpg

Вот с такой штукой действительно можно мучить архитектуру.

Ларри, не отдавай спарки!

Это, ИМХО, нужно совсем быть клиническим идиотом, чтоб, имея средства для развития, отдавать кому-то такую вещицу, как СПАРК.

Ну это расскажите создателям ARM и обучите их тонкостям российской терминологии.

Хотя , в этом треде, вполне нормально перекручивать факты , отрицать очевидное и прикидываться забаненными в google.

"Ничего не знаю.Нам не угодили .И вообще, и нереально угодить по определению." - удобная роль.

>так-то оно так, но только за ту небольшую разницу в цене я могу >поставить не одно лезвие на зионах, а спокойно набить корзинку >доверху, а остаток (стоимость еще 3-х таких же корзин) весело >попилить^H^H^H^H^H сэкономить ;)

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

Чего в пустую говорить ?
Ну организуйте нормальное железо на 128 (а это 2 чипа спарка) потоков на альтернативных подходах ,покажите стоимость,потребление,надежность.
А так, и я умею грузить лапшу.

От блин, шутники:))) - "оральные опросы шаровиков"

> Дисковая система дисковой системе рознь ;-)

В приличной конфигурации при подаче питания на массив диски спинапятся по одному, поскольку если они все попытаются разогнаться одновременно, ИБП проседает и впадает в истерику. Так что на фоне такой корзины потребление тока одним или двумя лезвиями никому не интересно.

> Рвет-то оно рвет, но как правило до определенного уровня нагрузки, после которого это самое лезвие на Интеле сдувается

Когда оно "сдуется", рядом с ним будет поставлено еще одно в параллель, либо оно будет заменено на в два раза более производительное за те же деньги.

Имея опыт работы с sunтехникой, могу сказать, что поддержание на протяжении двух лет в работопригодном состоянии четырех 4-летних спарков обходится сильно дороже чем выкинуть их и покупать каждые два года новые интелы. Сейчас уже нет нужды покупать "апгрейдабельную платформу", ибо через полтора года те же самые платформы торгуются на вес текстолита, а вот запчасти к ним тоже на вес, но уже не текстолита а серебра.

И напоследок попробуйте задуматься, какую из двух железок выберет покупатель:

а) 1 x UltraSPARC T1 (6 cores) 1GHz, 1GB RAM, размер 10U, цена 17108$
б) 4 x Xeon E7450 (6 cores) 2.4GHz, 8GB RAM, RAID-контроллер, размер 4U, цена 18739$

Можно кстати еще помоделировать ситуации, например слох процессор (малазийцы были с похмела и налажали на заводе). Только не рассказывайте что спарки не дохнут, лично держал в руках сановского "жмурика". О производительности кстати тоже рекомендую не начинать - я уже показывал ссылки на тесты где понятным по белому демонстрировалось что интел об 3.2GHz в два с половиной раза быстрей чем спарк об 2.5GHz. А тут даже не 2.5, а всего 1 гигагерц. Не вытянет спарка нагрузки, ой не вытянет.

> Когда оно "сдуется", рядом с ним будет поставлено еще одно в параллель, либо оно будет заменено на в два раза более производительное за те же деньги.

Вообще, если вы заметили, в том примере, что приводил я, сравнивалось лезвие на 2-x Xeon'ах с левием на 1 UltraSPARC T2 (которые, кстати, даже в одну корзину ставятся), так что совершенно точно так же можно поставить рядом еще одно SPARC'овое лезвие.

На счет в два раза более производительное за те же деньги - это вы загнули. Или факты в студию, плиз.

> И напоследок попробуйте задуматься, какую из двух железок выберет покупатель:

> а) 1 x UltraSPARC T1 (6 cores) 1GHz, 1GB RAM, размер 10U, цена 17108$

> б) 4 x Xeon E7450 (6 cores) 2.4GHz, 8GB RAM, RAID-контроллер, размер 4U, цена 18739$

Не надо сравнивать теплое с жидким. UltraSPARC T1 - это процессор, который был представлен в 2005 году. Xeon E6450 - представлен на три года позже. Что ж, это очень типично для бенчмаркетеров сравнивать современный процессор от Интел (или кого угодно другого) с SPARC'ом, который года на три старше.

Далее, потрудитесь указывать, какие конкретно модели систем вы сравниваете. Поскольку, например, мне интересно, где вы взяли систему на UltraSPARC T1 с 1GB RAM и аж в 10 юнитах. К вашему сведению, минимальная предлагаемая конфигурация сервера Sun Fire T1000 стоит $3695 (6 ядер, 1 ГГц, 8GB RAM) и занимает всего 1 юнит. Соответственно, в 4 юнита поместится 4 таких, а по цене получится даже меньше, чем ваш пресловутый Xeon. И на определенных классах задач они (несмотря на то, что им уже 3 с половиной года) вполне себе составят конкуренцию по пропускной способности системе на Xeon'ах.

Так что давайте без этих грязных трюков со сравнением непонятно чего.

> Можно кстати еще помоделировать ситуации, например слох процессор (малазийцы были с похмела и налажали на заводе). Только не рассказывайте что спарки не дохнут, лично держал в руках сановского "жмурика".

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

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

Быстрее на тесте SPECint. Вы таки и есть тот самый красноглазый линуксоид, который скоростью распаковки линуксового ядра меряется? Кроме SPECint тестов нету, да?

> А тут даже не 2.5, а всего 1 гигагерц. Не вытянет спарка нагрузки, ой не вытянет.

А мужики то и не знают, что великий no-dashi сказал, что спарка нагрузки не выдержит. Пойдите, расскажите это товарищам, перечисленным на этой страничке:

http://www.sun.com/servers/coolthreads/testimonials/

> В приличной конфигурации при подаче питания на массив диски > спинапятся по одному, поскольку если они все попытаются разогнаться > одновременно, ИБП проседает и впадает в истерику. Так что на фоне > такой корзины потребление тока одним или двумя лезвиями никому не > интересно.

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

> К вашему сведению, минимальная предлагаемая конфигурация сервера Sun Fire T1000 стоит $3695 (6 ядер, 1 ГГц, 8GB RAM) и занимает всего 1 юнит.

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

Sun SPARC Enterprise T1000: 8-core UltraSPARC T1, 8GB RAM, 2x72GB SAS == 5800$
HP Proliant DL160: 2 x 4-core Xeon, 8GB RAM, SmartArray P410 RAID controller 256MB BBWC, + 2x72GB 10k rpm SAS == 4400$

Как бы даже не смешно - за меньшие деньги железка с лучшей начинкой.

> Быстрее на тесте SPECint. Вы таки и есть тот самый красноглазый линуксоид, который скоростью распаковки линуксового ядра меряется? Кроме SPECint тестов нету, да?

Я вас порадую - например, есть еще SPECfp. Я не стал его приводить, поскольку убогих стараются не обижать, но если они (убогие) сами лезут, то ингода приходится напоминать... И еще я вам по секрету скажу, что как раз SPECint и SPECfp и характеризуют производительность процессора.

Потому как когда сервер озадачился группировкой с суммированием по 500000 проводок этого месяца, предварительно поднятых запросом с 50 параметрами, то все эти регистровые окна и прочие тут обфапанные сферические кони в вакууме я видел где-то между пряжкой ремня и коленной чашечкой. Ибо спасти тут могут только гигагерцы в процессоре и мегабайты в секунду на дисковом контроллере (если приложение переписать нет возможности).

Так что если система не может справиться с распаковкой линуксового ядра, про остальное можно даже не задумываться.

> Пойдите, расскажите это товарищам, перечисленным на этой страничке

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

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

Если E-Bay, Bank of America, America, Вымпелком наконец - религиозные фанатики, то вы то тогда кто?

Сдается мне, что все-таки перечисленные ребята - это бизнесы, решающие свои бизнес-задачи, а религиозный фанатик - это вы, господин no-dashi.

Из атеистов, кстати, записные фанатики получаются.

В догонку - МТС там тоже фигурирует...

> И еще я вам по секрету скажу, что как раз SPECint и SPECfp и характеризуют производительность процессора.

> Ибо спасти тут могут только гигагерцы в процессоре и мегабайты в секунду на дисковом контроллере

Интересно! А меня в детстве учили, что "плясать надо от приложения, а не от гигагерцев".

>> И еще я вам по секрету скажу, что как раз SPECint и SPECfp и характеризуют производительность процессора.

>> Ибо спасти тут могут только гигагерцы в процессоре и мегабайты в секунду на дисковом контроллере

> Интересно! А меня в детстве учили, что "плясать надо от приложения, а не от гигагерцев".

Дык товарищ-то тут распаковкой ядра линукс меряется... Видимо такой у него бузинесс... А тут как раз гигагерцы и отказ от fsync() после растаривания каждого файла рулят ;-)

> Видимо такой у него бузинесс... А тут как раз гигагерцы и отказ от fsync() после растаривания каждого файла рулят ;-)

Linux kernel занимает порядка 50MB в упакованном и порядка 500MB в распакованном виде. В принципе все эти данные можно запихнуть в память и про диск забыть. Исходные 50МB нужно держать в кэш второго-третьего уровня (что больше). Товарищ меряет скорость записи из регистров в память, или попросту L2(L3)-memory bandwidth.

Не удивительно, что прирост частоты в 1.5 раза ведет у него к приросту производительности в 1.5 раза.

Что-то мне подсказывает, что к регистровым окнам тест не имеет никакого отношения ;).

> Так что если система не может справиться с распаковкой линуксового ядра, про остальное можно даже не задумываться.

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

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

Да не это Ораклу от спарков нужно.

>>И напоследок попробуйте задуматься, какую из двух железок выберет >>покупатель:

>>а) 1 x UltraSPARC T1 (6 cores) 1GHz, 1GB RAM, размер 10U, цена 17108$ >>б) 4 x Xeon E7450 (6 cores) 2.4GHz, 8GB RAM, RAID-контроллер, размер >>4U, цена 18739$

Все зависит от задачи: если апач и пхп запускать - конечно интел. Если Оракловую базу хостить - тот тут выбор не однозначен.

Реальный случай на работе:

На девелоперскую рассылку приходит письмо от админов(не помню юниксовых или оракловых) приблизительно следующего содержания:

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

В понедельник пришло: проц заменили, база онлайн.

Ну-ка, любители интела, расскажите как поведет себя сервер на ксеонах, при выгорании одного из процессоров, и когда нужно реально 24х7.

Да и не надо мне рассказывать, про репликацию в оракле, и как можно круто сделать кластер из ораклов, цена такой настройки будет несоизмерима с ценой железа.

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

Сервера в нашей конторе спарки и редхаты на интеле. Нумеруются и те, и другие четерехзначными цифрами - т.е. и тех и других много.

Просто под у спарков надежность выше - не в плане, что они не горят, а в плане, то что горят - это нормально, нет перебоев в работе. Так как иногда цена простоя приложения - решает.

ЗЫ. Еще одно наблюдение не претендующее на объективность - при малой нагрузке линукс(редхат5) на ксеонах заметно шустрее, чем солярка на спарке(Скажем так, есть тестовые сервера, но которых может работать много инстансов одного и того же приложения). Но если количество инстансов приложения возрастает, то редхат начинает тупить как даун, а солярка кряхтит, но ворочается. Так что не все однозначно с производительностью. Но сервера сильно разные по мощности, так что это просто наблюдение о реакции на возрастающую нагрузку.

>много знаете процессоров с аппаратной поддержкой 16 byte плав. запятой?

AMD K10 (Barcelona/Phenom)

>В новости речь о том, что Ларри хочет пропихнуть комплексную систему, т.е. чтобы и железо свое, и Ось своя, и софт в придачу свой. А вы тут про архитектуру... Здесь про маркетинг надо думать :)

Вылазь из анабиоза: нет уже давно у Sun "своего железа" - почти всё Fuji'ку давно спихнули.

>Например, насколько обращение к регистрам быстрее обращений к закэшированной в самом быстром кэше например вершине стэка?

Да нинасколько, практически

>. Как можно не понимать простой вещи, что чем больше регистров, то тем меньше работы со стеком. Однако для переключения контекстов все используемые регистры надо сохранять. Куда? В стек. Медленно.

на счёт "медленно"... Цифры, плиз.

> Если E-Bay, Bank of America, America, Вымпелком наконец - религиозные фанатики, то вы то тогда кто?

Если по историческим причинам сложилось так, что у них куча спарков, то чтобы не плодить зоопарка имеет смысл продолжать брать спарки, и не более того.

>Оракл пока что не выпускает собственного железа (или под собственной маркой), в отличие от яблока со своими маками и проч.

И какое же такое "железо" "выпускает" Apple?

>На x86-64 в 128-разрядном поле содержится 80-разрядное интеловское вещественное число. Вспомните архитектуру процессора -- или почитайте описания. Именно этот режим gcc имеется в виду.

В AMD K10 SIMD-регистры могут использовать как честные 128-битные long double

> Ну-ка, любители интела, расскажите как поведет себя сервер на ксеонах, при выгорании одного из процессоров, и когда нужно реально 24х7.

"Когда нужно реально 24x7" начинаются слова HA-кластеры и им подобные решения.

И еще один маленький ноут - я беседовал с преподавателями когда меня отправляли в учебный центр на специфические сановско-солярисные курсы (обнаружение и устранение неисправностей) на предмет того, как поведет себя солярка при "вылете" процессора. Ответ был примерно такой "если процессор в это время стоял без дела или занимался прикладной задачей, то все будет нормально. Если же там крутились ядерные нити - да, приходит кернел паник".

> Просто под у спарков надежность выше - не в плане, что они не горят, а в плане, то что горят - это нормально, нет перебоев в работе

Ок. Простой пример - у меня есть две железки, на одной ультраспарк Т2, на второй 2 четырехядерных интела. На той и на другой симулируем одинкаовую неисправность - сдохший процессор. Спарка отправляется в простой на 8 часов минимум (ближайший большой сановский сервис в соседней области), и то не факт что чип там будет в наличии, в интеле я просто выдерну процессор вернув систему в работу через 15 минут. Если сдохнет платформа, то для сантехники все еще печальней.

> Но если количество инстансов приложения возрастает, то редхат начинает тупить как даун, а солярка кряхтит, но ворочается

Для начала, в таких сравнениях принято приводить характеристики железа. По факту, вы например можете "проседать" на I/O, и спарк это или интел уже не имеет значения.

>>много знаете процессоров с аппаратной поддержкой 16 byte плав. запятой?

> AMD K10 (Barcelona/Phenom)

Первый раз такое слышу. То, что Barcelona "наконец-то научилась" выполнять 128-бит SSE инструкцию каждый такт - знаю (8 Flop/clk), но про 128-бит арифметику не знаю.

Ссылка?

В подтверждение своих слов, вот моя:

http://developer.amd.com/documentation/articles/Pages/682007171.aspx

"The typical implementation relies on a series of 128-bit registers into which multiple smaller data items are placed. These items can be small 8-bit integers just as well as 64-bit floating point numbers."

Чтобы избежать непонимание - уметь загрузить два 64-бит числа в 128-бит регистр, и уметь выполнять арифметику со 128-битовыми чиcлами - не одно и то же.

>>Например, насколько обращение к регистрам быстрее обращений к закэшированной в самом быстром кэше например вершине стэка?

> Да нинасколько, практически

Вы бы хоть дискуссию то почитали - комментатор!

В 5-6 раз. Нисколько...

>> Если E-Bay, Bank of America, America, Вымпелком наконец - религиозные фанатики, то вы то тогда кто?

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

Вы искренне считаете, что у товарищей такого калибра нет зоопарка? Думаю, что они берут и SPARC, и Интел, и используют каждый там, где он дает наибольшее преимущество.

Заметьте, no-dashi, участники дискуссии, говорящие что-то хорошее о SPARC не отрицают, как правило, Intel/AMD. Потому что реалии жизни таковы, что для задач где требуется высокая однопоточная производительность для небольшого числа паралелльных потоков Интел/АМД являются наиболее логичным выбором. В задачах же, где требуется большая пропускная способность, и скорость одного потока не играет большой роли, там расстановка сил меняется. Плюс есть еще некоторые частные моменты, которые могут влиять на выбор той или иной платформы.

Вы же, почему-то, с пеной у рта путем грязноватых манипуляций с фактами и передергивания пытаетесь представить дело так, что нет бога кроме Интела и Xeon пророк его. Это простительно слышать от красноглазого школьника-линуксоида, но странно слышать от взрослого мужчины с неплохим послужным списком.

> И еще один маленький ноут - я беседовал с преподавателями когда меня отправляли в учебный центр на специфические сановско-солярисные курсы (обнаружение и устранение неисправностей) на предмет того, как поведет себя солярка при "вылете" процессора. Ответ был примерно такой "если процессор в это время стоял без дела или занимался прикладной задачей, то все будет нормально. Если же там крутились ядерные нити - да, приходит кернел паник".

Как видите, ответ it depends. Ответ также depends от того, что это за SPARC, что это за Solaris, и еще массы факторов.

>> Просто под у спарков надежность выше - не в плане, что они не горят, а в плане, то что горят - это нормально, нет перебоев в работе

> Ок. Простой пример - у меня есть две железки, на одной ультраспарк Т2, на второй 2 четырехядерных интела. На той и на другой симулируем одинкаовую неисправность - сдохший процессор. Спарка отправляется в простой на 8 часов минимум (ближайший большой сановский сервис в соседней области), и то не факт что чип там будет в наличии, в интеле я просто выдерну процессор вернув систему в работу через 15 минут. Если сдохнет платформа, то для сантехники все еще печальней.

Мы, кажется, недавно рассматривали 4 T1000 вместо четырехголового Интела за одну цену. И если из 4 сдохнет 1, то при правильной архитектуре приложения пользователи вообще ничего не заметят.

У UltraSPARC T2 обладает большой живучестью - неисправные ядра могут отключаться в процессе POST и всего делов. А количество компонентов в системах на базе T2 заметно меньше, чем в системах на Intel/AMD, что делает их более надежными в силу банальной статистики.

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

Впрочем, не могу отрицать, что фактор доступности сервисной поддержки немаловажен при выборе оборудования под ответственные задачи.

>> Но если количество инстансов приложения возрастает, то редхат начинает тупить как даун, а солярка кряхтит, но ворочается

> Для начала, в таких сравнениях принято приводить характеристики железа. По факту, вы например можете "проседать" на I/O, и спарк это или интел уже не имеет значения.

Вам же сказали, что Интел сдувается, а SPARC кряхтит, но ворочается. Если бы все упиралось в IO, то сдувались бы примерно одинаково. Может все-таки стоит открыть ссылку и почитать про зайца и черепаху. Я понимаю что это ЛОР, и ходить по ссылкам тут не принято, но все же...

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

Пример такой задачи, при этом чтобы задача не упиралась в дисковый ввод-вывод (то есть 1000 сессий оракла эта не такая задача, ибо там как раз в диск все и упирается) в студию.

Я тоже не отрицаю осмысленность использования спарков в унаследованной инфраструктуре, а вот для новых проектов выбирать эту платформу, с которой неизвестно что случится дальше как минимум неосторожно. Те же центробанк и ЖД работающие с IBM, сбербанк и налоговая работающие с HP как бы подтверждают сей факт.

> Вы же, почему-то, с пеной у рта путем грязноватых манипуляций с фактами и передергивания

Где я передернул? Я честно признался что ошибся, и привел новую расстановку в ответ на ваш пример, с указанием моделей и конфигураций. А также привел примеры того, что не все так гладко как вы рассказываете. И про полетевшую систему и компоненты я не просто так приводил пример - это все было.

> Вам же сказали, что Интел сдувается, а SPARC кряхтит, но ворочается.

Это не я сказал. По опыту выжимания производительности из информикса и оракла, сервер БД крайне редко упирается в CPU, и на 64-битных архитектурах слабым местом является I/O. Когда интелы были 32-битными, спарки имели заметное преимущество. Теперь увы, главное спарковское преимущество - размер адресного пространства процесса - кануло в лету.

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

Я вообще с ними не сталкиваюсь. Самая серьезная проблема была - глюкнувший RAID-контроллер (1 раз).

Впрочем, такая статистика закономерна: срок полезной эксплуатации интела порядка 3-5 лет - если через 3 года он не начал глючить и его ресурсов хватает на обслуживание задач на него возложенных, с ним ничего не делается. Если ресурсов не хватает, то он просто меняется, старая банка уходит под некритичные задачи, а новая принимает ответственные.

>если количество инстансов приложения возрастает, то редхат начинает тупить как даун, а солярка кряхтит, но ворочается.

Кхм... не говоря о строго количественной интерпретации "тупит как даун" и "кряхтит, но ворочается", здесь может быть виновать исключительно софт. Сколько сбея помню, солярщики всегда били себя пяткой в грудь насчет "Солярис лучше работает под тяжелыми нагрузками". Причем это равно относилось к Solaris/SPARC и Solaris/x86. Так что не нужно приводить такие данные в качеств преимущества SPARC как архитектуры сервреров.

И вообще, давайте флеймить о _процессорных_ архитектурах :) Вот, например, что сказал один MIPSовец о хваленых регистровых окнах: http://yarchive.net/comp/register_windows.html (ссылка, правда, древняя).

<Ъ>

2) Implementations (such as HP or MIPS, for example) that started with split I & D caches normally have 1-cycle loads and 1-2 cycle stores, depending on the implementation. Hence, a lower bound on the cost is something like: 2 registers * (1-2 (per save) + 1 per restore) = 4-6 cycles. One expects that the restore should seldom cache-miss. In a write-back cache, the first store may cause a writeback and/or a memory read. Of course, the instructions may I-cache miss.

...

So, as a gross rule of thumb, what's happening is that a MIPS_like CPU is probably spending about 5% of the cycles saving/restoring registers across function calls, in user-level code typical of the early 1980s. It's probably less for FORTRAN code (I guess 3%) and maybe for kernel code.

4) Now, most earlier SPARCs use joint caches, and hence have 2-cycle loads and 2-3-cycle stores, and so the penalty *there* for explicit save/restores, assuming same compiler technology: is 2 * (2 + 2-3) or 8-10 cycles, hence there are more cycles to go after in that kind of implementation (although %-wise it's probably the same, as the joint-cache SPARCs have higher CPIs than 1.2). Put another way: if you have fast loads and stores, and don't have to save/restore many registers anyway, you're less interested in register windows.

</Ъ>

> В 5-6 раз. Нисколько...

Эта разница мгновенно нивелируется, когда речь начинает идти от объемах данных хотя-бы в 1 мегабайт. Какая разница сколько у вас регистров, если предстоит сделать in-memory sort с последующей группировкой и суммированием для 10 мегабайт? Все равно все упрется в шину данных. А если дело дошло до sort-on-disk, то будь то четырехрегистровая или сторегистровый процессор, все упрется в диск. И сколько проку от этих регистров, если у меня в dictionary cache 16 мегабайт?

> Вам же сказали, что Интел сдувается, а SPARC кряхтит, но ворочается

А это ничего что операционки разные, и в них например те же самые I/O scheduler'ы разные? :-)

>А это ничего что операционки разные, и в них например те же самые I/O scheduler'ы разные? :-)

Вас и вашими методами:
"Если, факты указывают на проигрыш спарков - это хорошие факты.
Если, факты указывают на проигрыш Intel - это сомнительные факты. "

> Если, факты указывают на проигрыш спарков - это хорошие факты. Если, факты указывают на проигрыш Intel - это сомнительные факты.

А вот индейский дом вам, а не троллинг. Если есть цифры (деньги, бенчмарки и длинномерки) это факты. Если есть "субъективные ощущения" вида "тормозит" и "шевелится" - это не факты. Так что ФАКТЫ (цифры) в студию

Ну не я же сравниваю i7 c спарком 7 и делаю выводы о превосходстве итаниумов.:))

Вполне можно взять затрапезный Cel & 256 RAM и упорно доказывать клиническую смерть Intel. Сообственно, вы этим тут и занимаетесь для спарков.
Если ,ваше руководстово приобрело спарки по существу и не по назначению
- причем тут архитектура CPU ?

> Вполне можно взять затрапезный Cel & 256 RAM и упорно доказывать клиническую смерть Intel

Та что ви говорите?! Это вы про сравнение UltraSPARC T1 с Xeon? Так оно сейчас на сайте предлагается саном и HP, и не находится в EOL. А теперь покажите, пожалуйста, _сейчас_ в продаже в продаже указанную вами конфигурацию с Celeron (причем не second hand).

>То, что Barcelona "наконец-то научилась" выполнять 128-бит SSE инструкцию каждый такт - знаю (8 Flop/clk), но про 128-бит арифметику не знаю. Ссылка? В подтверждение своих слов, вот моя: http://developer.amd.com/documentation/articles/Pages/682007171.aspx "The typical implementation relies on a series of 128-bit registers into which multiple smaller data items are placed. These items can be small 8-bit integers just as well as 64-bit floating point numbers."

Ну так по вашей же ссылке:

With the advent of Barcelona's SSE128, the execution units that handle SSE have widened from 64 bits to 128 (first row in Table 1). The new execution units can perform a 128-bit register operation in a single micro-op, rather than as two 64-bit ops. To support this increased capability, the floating-point operations scheduler has been widened to 128 bits as well (bottom row in Table 1).