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

>> Так оно и есть. У чуваков спрашивали про линакс. Они сказали, что он тупо сосет на «большом железе» (big iron).

Угу, уже десять лет сосет на IBMовском железе ;-)

Линукс на IBMовском железе - это только повод зайти в аккаунт под соусом открытости, экономии и прочего бла-бла-бла... а потом приходит IBM Global Services и эта экономия становится такой экономной ;-)

> Мда. Кластеры это маленькое железо, да :)

Кластеры в TOP500 - это большое количество маленького железа. Там центральные железки - это нифига не писюки, а коммутаторы Infiniband.

И линукс там в основном (причем бесплатный, а не всякие RHEL и SLES) потому, что с Infiniband'ом в нем, пожайлуй, лучше всего, в силу того, что его университеты именно под линуксом строгают.

> по принципу обращения к памяти очень даже, я это имел ввиду.

В SPARC64 VI потоки переключаются по весьма нетривиальным правилам.

В UltraSPARC T серии потоки в одном исполнительном модуле (4 в каждом, то есть 8 потоков на ядро) переключаются каждый такт, причем те, которые ждут данные из памяти, пропускаются.

В SPARC64 VI же, есл поток не обращается за данными в память (все что нужно - в кэше), то ЕМНИП там есть какое-то правило, что принудительное переключение (чтобы дать и другому поработать) произойдет через несколько тысяч тактов.

с той лишь разницой, что у т2 2 паралельных потока на 1 такт.

не о двух ли параллельных потоках на ядро UltraSPARC T2 на один такт идет речь? То есть 16 потоков на процессор.

Впрочем, то что ты среагировал, красноречиво говорит

А то что ты на мой пост среагировал, тоже кагбэ говорит нам...

И всё-таки не чтец ты в сердцах :)

>>В SPARC64 VI потоки переключаются по весьма нетривиальным правилам.
по каким правилам переключаются не суть, смысл в старте следующего треда по обращению предыдущего к памяти.

В UltraSPARC T

дак мы про Т или Т2? =)

не о двух ли параллельных потоках на ядро UltraSPARC T2 на один такт идет речь?

о нем и есть, но принято говорить/писать по 2 на ядро.
а то и так потоки не любят, но вот ядра это прорыв... ))

>>Но тогда эти результаты не вполне понятно, как сравнивать
когда непонятно что тестируешь и сравнивать непонятно что.
очень мучает вопрос - перегружались ли домены между тестами? подозреваю, что этого ты не учел.
так же интересно былоб глянуть как ты ресурс группы создавал, но боюсь, лучше тебе этого не показывать.
ну и /dev/urandom конечно самый лучший источник энтропии, емнип, АЖ, 75mhz.
а на sql сам себе и показал, что треды это не так уж и плохо.
и таки да, smt свое дело делает, только обратно тому, что ты тут пытаешся доказать.

Но тогда эти результаты не вполне понятно, как сравнивать. Впрочем, то, что результаты с одним процессором хуже не в два раза, а гораздо меньше, то нужно признать, что SMT свое дело таки делает.

Когда выполняемых процессов столько-же или больше чем strand-ов - таки делает. Когда меньше - делает она следующее (или делала до недавнего времени). С ситуацией столкнулись после переноса системы с us iv+ на sparc64 vii. Задачи которые на полноценных ядрах выполняются одинаковое время (1,5 часа +/- минута, максимум 2), начинают выполняться от 1,5 до двух часов. Очевидно - кривость диспетчеризации, ОС может выполнять 2 задачи на двух нитях одного прцессора вместо двух отдельных ядер, при том что ядер больше чем выполняемых задач. После отключения нитей - снова все как и было - задачи выполняются одинаковое время.

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

Вот в этом то и дело. В семействе UltraSPARC T они переключаются каждый такт, но не между всеми, а между теми из четырех, которые не ожидают данных из памяти.

В UltraSPARC T

дак мы про Т или Т2? =)

да и про те, и про другие. В Т2 просто два модуля выполнения на ядро, в T - всего один, соответственно в T2 восемь потоков, а в T - четыре

>>В семействе UltraSPARC T они переключаются каждый такт, но не между всеми, а между теми из четырех, которые не ожидают данных из памяти.

отот, дак и на sparc64vi переключаются на второй, когда тот закончил обращение к памяти.
только в Т и Т2 их 4 и 8 соответственно, а в vi всего 2 на ядро. и потому иногда надо прерывать принудительно. вот вобщемто и вся разница.

>это на каждый слот.

Ну, а кроссбару-то сколько чего идет? Слотов на коммутаторах сколько угодно можно понатыкать, лишь бы питания хватило. Или это секретная информация?

свичи 32х.

когда непонятно что тестируешь и сравнивать непонятно что.

очень мучает вопрос - перегружались ли домены между тестами?

зачем перегружать домен?

так же интересно былоб глянуть как ты ресурс группы создавал

зачем они в данном конкретном случае?

ну и /dev/urandom конечно самый лучший источник энтропии

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

а на sql сам себе и показал, что треды это не так уж и плохо.

pl/sql выполняется в 1,6 раз медленнее

очень мучает

но боюсь,

феерия самовлюбленной тупизны. не заглядывай сюда и не придется страдать и бояться.

анабиоз

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

выйди из анабиоза - 10ка давно уже условно бесплатна - в отличие от 9ки и 8ки. подтверждение - ищи на сайте sun по словам solaris 10 и licensing, мне сейчас лень искать через 3g, но оно там есть.

OBP (интерфейс к микрокоду машины, а точнее, домена) есть у всех Sun

SPARC машин

спасибо! давно так не смеялся! rotfl
завтра всем знакомым сантехникам разошлю.=D
OBP=Open Boot PROM, аналог BIOS в писюках, весь «микрокод» там - библоитечка на форте.
и потом, какой может быть домен на 280R или тем более Blade 150 - а OBp там есть.;)

> отот, дак и на sparc64vi переключаются на второй, когда тот закончил обращение к памяти

скорее не закончил, а инциировал. То есть переключение с первого потока на второй происходит тогда, когда первый пошел за данными в память, либо когда он проработал заранее опредленное количество тактов, порядка нескольких тысяч ЕМНИП. Какое количество тактов пройдет от одного переключениядо другого - заранее неизвестно. В UltraSPARC T серии же модуль исполнения каждый такт выбирает инструкцию из среди потоков, не находящихся в стадии ожидания данных из памяти, выбирая из таковых тот, который дольше всех ждет (а ждать приходится максимум 4 такта).

Так понятно?

>>закончил обращение к памяти
мдее, хорошо посидели.

Так понятно?

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

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

зачем они в данном конкретном случае?

поведай, как ты передавал своим, кхмм, тестам, какие ядра/цпу надо использовать?

зачем энтропия в данном случае?

незачем. но что по твоему urandom и почему его использовал...

феерия самовлюбленной тупизны.

черезвычайно хреновый психолог

зачем перегружать домен?

а кэш не надо обнулять, для чистоты результатов?

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

зачем они в данном конкретном случае?

поведай, как ты передавал своим, кхмм, тестам, какие ядра/цпу надо использовать?

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

зачем энтропия в данном случае?

незачем. но что по твоему urandom и почему его использовал...

незачем - ключевое слово. не нужна. Использовал как источник данных которые с одинаковой скоростью жмутся gzip-ом.

феерия самовлюбленной тупизны.

.черезвычайно хреновый психолог

для этого не нужно быть психологом :)