>это железячные потоки.не путать с х86 хайпертред ))

В курсе, это я случайно не туда "жмякнул" кнопкой.))

Давайте порадуемся вот чему. Тому что все таки выбрали спарк/соляру, а не intel/windows.

anonizmus (13.02.2010 18:32:38)

>Не совсем понял, чем Java под Solaris лучше ее же под, скажем, AMD64?

Тем что санки совмено с санычем точили жабу под соляроу.

> У Сана до 4 террабай ОЗУ и до 288 PCIe слотов на одной машине.

Это не у сана, это у Фуджицу-Сименса. От сана там только лейбл и солярис.

scott_tiger (13.02.2010 18:33:10)

а посчитай необходимую пропускную способность для 288 pci-e ;)
боюсь инфинибенд поплохеет.

EvgGad_303 (13.02.2010 18:33:28)

> Давайте порадуемся вот чему. Тому что все таки выбрали спарк/соляру, а не intel/windows. Плюсую..

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

А, понял, задача стоит подобрать железо под тормоза явки? Так бы сразу и сказал. А то проект, раздавать, юзеры, риалтайм.. ;)

> это железячные потоки.
> не путать с х86 хайпертред ))

Это ты рекламы начитался? Тменно так там и написано. И даже названо Simultaneous Multi Threading.
На деле, отключение потоков на ядрах дает до 1,5 раз повышение производительности на поток. Отключение ядер на кристалле - еще больший прирост производительности.

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

scott_tiger (13.02.2010 18:40:40)

>>Epic Fail. sun4v в single-thread проигрывает x86

эпик это кто покупает sun4v для single-thread ;)

>>M9000-64, лол. рекламку четал, just facts ниасилил?

а что не так? сам то хэндбук читал?
128 slots, expandable up to 288 slots, via optional external i/o expansion units, коих до 16 можно вставить.

EvgGad_303 (13.02.2010 18:42:15)

> здесь как бэ они нипричем, тут кол-во ядер и потоков на ядро

> Sun предоставил VANOC парк из 125 серверов Sun SPARC Enterprise и 475 серверов Sun Fire на базе процессоров AMD и Intel с архитектурой x64

Большинство железа — амдинтелы. У обоих контор есть 6-ядерники, у Т2 максимум 8. Где "здесь"?

> у Т2 максимум 8 (ядер).

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

scott_tiger (13.02.2010 18:52:32)

*обеих

Причем в 5220 проц максимум 1.

>Но потом настроение вернулось в предыдущее состояние, когда издалека показали компы, на которых венда хр.

Да-да-да, по евроспорту показывали. Отличное кино. Восхищен канадцами. В Сочях наверняка все будет на откатах, даже поставка букетиков для победителей. А в Канаде даже мысли об этом не возникло - дали букеты собирать бывшим теткам-зечкам, что б в социум их вернуть и денег дать заработать. Вот жеж, мля, страна так страна!

Ну да, и показали школу какую-то, а там у детишек сплошь Деллы стоят ноуты и везде Винда ХР :) Никакого Линукса :(

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

EvgGad_303 (13.02.2010 18:58:37)

а 8 потоков на ядро?

EvgGad_303 (13.02.2010 18:59:45)

ога, расскажешь об этом в ibm

shty (13.02.2010 19:11:54)

>Там же написано по 10 тыс. узлов. Во все эти узлы надо передавать копию данных одновременно и в РЕАЛЬНОМ ВРЕМЕНИ!!

Ура! Санки освоили мультикаст!

может потому, что aix то еще чудо? ))

EvgGad_303 (13.02.2010 19:13:35)

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

Тесткейс с цифрами можешь привести?

> sybase мол не умеет потоки и надо отключить железно

Это о чем вообще? Как на старках отключить процессор/поток "железно"?

> на usvii отключив треды по-сути отключишь половину проца.

Обосновать чем нибудь можешь? Почитай спецификацию на sparc vii - там вполне конкретно написано, что кэш - 45МБ на сокет используется совместно всеми потоками, плюс еще часть ресурсов.

scott_tiger (13.02.2010 19:14:13)

> а 8 потоков на ядро?

А с ядрами что? ;) Про разницу в количестве потоков не в курсе, а главное в том, как и насколько это тут проявится, на "Vancouver 2010 Information Diffusion System". А то некоторые тоже до сих пор продолжают исключительно на мегагерцы д***ить, как 10 лет назад.

Плюс повторюсь, там ~3/4 амд с интелами.

ололо, толстячок...

10e3 / 10e5 = 10e-2 Tb на канал... не то чтобы слишком много

и первыми "сдыхают" каналы в таком разе

а процы то во время передачи данных чем там нагружены? контрольные суммы считают?

shty (13.02.2010 19:21:09)

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

>>Тесткейс с цифрами можешь привести?

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

>>Это о чем вообще? Как на старках отключить процессор/поток "железно"?

obp в помощь, там много чего интересного можно делать в сервисном режиме ))

>>Обосновать чем нибудь можешь? Почитай спецификацию на sparc vii

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

EvgGad_303 (13.02.2010 19:25:53)

Ой ли?

Вот эти ребята http://www.top500.org/stats/list/34/os не согласны с такими словами

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

shty (13.02.2010 19:28:01)

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

EvgGad_303 (13.02.2010 19:29:38)

может :) но солярка, знаете ли, тоже не подарок

разговор ведь шёл о другом, не так ли? спокойно и нормально работает "линюкс" на вполне себе толстых системах

shty (13.02.2010 19:32:53)

ещё как да :)

вот это я не понял

это если кластер соответствующего типа

кластеры, они, знаете ли, разные бывают

shty (13.02.2010 19:34:48)

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

Естественно, платы, куда втыкаются CPU/память, тоже меняются по-горячему.

bigbit (13.02.2010 20:23:33)

без Windows правда там не обошлось -_-'

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

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

В них вполне конкретно написано нечто противоречащее твоему утверждению.
"when one thread reaches an idle state, the executing thread can then fully leverage shared resources - a feature that improves the performance of single-threaded operation"

Далее, написано что стренды не блокируют друг друга, но
While SMT supports execution of both threads simultaneously, these threads still share
the same pipeline core.
и
A few resources remain shared between threads, such as instruction buffers, commit stack entry (CSE), branch history storage (BSD) and __caches__.

Далее. Могу выложить блок на Oracle PL/SQL который не обращается к БД, а выполняет примитивные числовые расчеты с массивами integer и float. Я запускал его в 8 потоков на сервере следующим образом.
Конфигурация 1 - 4core x 2strands
Конфигурация 2 - 8 core x 1 strands.
В первом случае падение производительности ~1,4 раза. на реальных задачах в БД - до 2+ раз. Если есть желание - могу выложить, попробуй сам и сравним результаты. Сайбейза у меня нет, если напишешь аналог и прогонишь аналогичный тест - будет очень любопытно. Сомневаюсь что разницы не будет, но если не будет - я с радостью скажу, что да, теперь я знаю один случай когда SMT дает прирост производительности.

Доки:
SUN CPARC ENTERPRISE M4000 .... M9000 SERVER ARCHITECTTURE white paper july 2008,

Chapter 4 ... Simultaneous multithread,

A few resources remain shared between threads, such as instruction buffers, commit stack entry (CSE), branch history storage (BSD) and __caches__.

и чуть ниже

While SMT supports execution of both threads simultaneously, these threads still share
the same pipeline core. The SPARC64 VII processor works to optimize performance by
minimizing interference between threads. For example, the instruction fetch stage,
instruction decoding stage, and commit stage facilitate selection of either thread
within each cycle. This measure helps avoid the potential for a stalled thread to block
the progress of an executing thread. In addition, while two threads are executing
within a single core, the hardware resources specifically assigned to each thread are
kept isolated. At the same time, when one thread reaches an idle state, the executing
thread can then fully leverage shared resources - a feature that improves the
performance of single-threaded operation

Документ
PERFORMANCE CONSIDERATIONS FOR DEVELOPERS UTILIZING SUN SPARC ENTERPRISER M-SERIES SERVERS


The SPARC64 VII processor provides an improved multistrand model. Both strands
share the instruction pipeline, alternating instruction initiation every cycle. This
approach is known as Simultaneous Multithreading (SMT). On the first cycle, the
first strand issues a group of instructions. On the second cycle, the second strand
issues a group of instructions - then back to the first strand, and the cycle
continues. Instructions from either strand progress through the instruction
pipeline according to functional unit and input data availability. There are two
integer, two floating point, two load/store, and one branch functional unit
available to execute instructions. Any functional unit can handle instructions from
either thread. This flexible design allows both threads to gain roughly equal
access to the processor. Throughput results depend on the application
characteristics. Utilizing two threads can result in very small throughput gains if
both threads are competing for a single resource. In contrast, if the two strands
are limited by other factors such as memory latency, utilizing the SMT processing
model can lead to nearly double the effective throughput.

scott_tiger (13.02.2010 22:45:51)

Хороший выбор.

>не доверяют еще линаксу

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

>линакс

К логопеду, быдло!

>где линаксу не место

Быдлу место на приеме у логопеда.

>у линакса

К логопеду, быдло!

Капча idiocy forced как бы намекает.

>с dynamic reconfiguration на спарках

Кому нужны эти рипнутые поделия?

>А выбирают его из-за качества и надёжности

Да-да. Ынтерпрайзу - Ынтерпрайз ping of death.

>Мощные процы, которые имею очень хорошую производительность, x86 далеко до этого

Бугагец, просто без комментариев.

>А где новость про то, что Linux использовался при съемках Аватара? Или LORовцы принципиально копипастят только с опеннета?

http://www.linux.org.ru/add-section.jsp?section=1

sinister666 (14.02.2010 0:06:31)

>128 slots, expandable up to 288 slots, via optional external i/o expansion units, коих до 16 можно вставить

Стало быть, коммутаторы, коммутаторы и еще раз коммутаторы.

Сколько лейнов идет к процам и какого поколения?

Сейчас смотрю биатлон. Так комментатор только и делает, что ругается на компьютеры, мол ничего не работает (режиму реального времени достается больше всего)!

Jurik_Phys (14.02.2010 0:42:03)

Дык, зато трустед Ынтерпрайз соулэрис.

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

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

Sanitar (14.02.2010 1:25:47)

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

Лучше природа и винда, чем срач и линукс >_<

sv75 (14.02.2010 3:09:06)

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

Из ответов профессионалов вообще можно составлять юмористические цитатники, если спрашивать их о том, что они не любят или не понимают.

sv75 (14.02.2010 3:11:12)

санкластер это все умеет "искаропки"
других кластеров незнаю )))

EvgGad_303 (14.02.2010 3:49:10)

чито? вообще вкурсе что это такое?

EvgGad_303 (14.02.2010 3:58:36)

текнолоджи-текнолоджи, всем плясать ))
конечно не 16х, как в модных пц, но 8х.
а вы что-то более 8х видели, кроме видеокарты?

EvgGad_303 (14.02.2010 4:16:12)

>>"when one thread reaches an idle state, the executing thread can then fully leverage shared resources

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

>>примитивные числовые расчеты с массивами integer и float

подозреваю, это не самые лучшие примеры многопоточности ))

>>Далее. Могу выложить блок на Oracle PL/SQL который не обращается к БД

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

и 2008 год как бы намекает )

EvgGad_303 (14.02.2010 5:32:47)