https://slinkov.ru/openforum/vsluhforumID3/87349.html Опубликован (http://www.top500.org/blog/lists/2012/11/press-release/) 40 выпуск рейтинга (http://www.top500.org/lists/2012/11/) 500 самых высокопроизводительных компьютеров мира. Самым высокопроизвдительным суперкомпьютером, достигнувшим в тесте Linpack производительности в 17.59 Petaflop/s, признан построенный компанией Cray кластер Titan (http://www.top500.org/system/177975), недавно внедрённый в Национальной лаборатории Оук-Ридж (http://ru.wikipedia.org/wiki/%D0%9D%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%B0%D0%BB%D1%8C%D0%BD%D0%B0%D1%8F_%D0%BB%D0%B0%D0%B1%D0%BE%D1%80%D0%B0%D1%82%D0%BE%D1%80%D0%B8%D1%8F_%D0%9E%D1%83%D0%BA-%D0%A0%D0%B8%D0%B4%D0%B6) (США). Кластер включает в себя 560640 16-ядреных процессоров Opteron 2.200GHz и 261632 вычислительных акселераторов на базе GPU NVIDIA Tesla K20x. <br><br><br>Прошлый лидер рейтинга, кластер Sequoia (http://www.top500.org/system/177556), базирующийся на платформе IBM BlueGene/Q и содержащий 1572864 процессоров Power, оказался на втором месте по производительности (16.32 Peta https://slinkov.ru/openforum/vsluhforumID3/87349.html#225 Tue, 20 Nov 2012 14:38:49 GMT &gt;&gt; Речь была о наличии, а не о покупке.<br>&gt; Речь шла о разработке. Что-то, полученное на бумаге или в крошечной <br>&gt; серии для испытаний - бесконечно далеко от разработанного продукта.<br>&gt; Как думаете, много было бы проку от "разработанного" т-34 без проведенной до <br>&gt; этого индустриализации?<br><br>Я и не спорю ;-)<br><br>&gt;&gt; Конечно, комдив купить нельзя, это для отечественной оборонки железка.<br>&gt; Звучит довольно жалко...<br><br>Ну так вообще состояние российской микроэлектроники сейчас иначе как жалким не назовёшь, это да.<br><br> https://slinkov.ru/openforum/vsluhforumID3/87349.html#224 Tue, 20 Nov 2012 12:10:38 GMT &gt; Речь была о наличии, а не о покупке.<br><br>Речь шла о разработке. Что-то, полученное на бумаге или в крошечной серии для испытаний - бесконечно далеко от разработанного продукта.<br><br>Как думаете, много было бы проку от "разработанного" т-34 без проведенной до этого индустриализации?<br><br>&gt; Конечно, комдив купить нельзя, это для отечественной оборонки железка.<br><br>Звучит довольно жалко...<br><br> https://slinkov.ru/openforum/vsluhforumID3/87349.html#223 Tue, 20 Nov 2012 12:01:07 GMT &gt;&gt; google KOMDIV-32 <br>&gt; Китайские аналоги, в отличие от - можно купить.<br><br>Речь была о наличии, а не о покупке. Конечно, комдив купить нельзя, это для отечественной оборонки железка.<br>В своё время покопаться удалось с ней, отчёт тут: http://kibab.ya.ru/replies.xml?item_no=307<br> https://slinkov.ru/openforum/vsluhforumID3/87349.html#222 Tue, 20 Nov 2012 10:55:06 GMT &gt; google KOMDIV-32 <br><br>Китайские аналоги, в отличие от - можно купить.<br> https://slinkov.ru/openforum/vsluhforumID3/87349.html#221 Tue, 20 Nov 2012 06:12:17 GMT &gt; во начианаешь понимать почему один блок на всё плохо? <br><br>А где я предлагал "один блок на всё"? Вроде бы склерозом и маразмом не страдаю...<br><br>&gt; мы все структуры ядра заблокировали на "почесаться"<br><br>"Мы" - так не делаем.<br> https://slinkov.ru/openforum/vsluhforumID3/87349.html#220 Tue, 20 Nov 2012 00:31:39 GMT &gt;&gt;&gt; Средняя плотность выделения тепла AFAIK выше <br>&gt;&gt; иии что?<br>&gt; Иии соответственно охлаждать приходится интенсивней[, мониторить оперативней].<br><br>охлаждать интенсивнее - да, мониторить оперативнее - не обязательно. конечно, можно превратить систему мониторинга в АСУ, но АСУ заметно дороже. <br><br>&gt;&gt; во-первых, не загруженные на 100% серверы в ДЦ - это не нормально, КМК <br>&gt; Интересно, я до сих пор сталкивался только с народом, который предпочитает оперативный <br>&gt; запас порядка хотя бы 10--20%. (без подковырок, сам-то не ДЦ-шник) <br><br>не вижу в этом ничего плохого. LA 3-5 это нормально, главное, чтобы оно не прыгало непредсказуемо и не упиралось в i/o. конечно, следует смотреть, как такая нагрузка выглядит со стороны клиента; виндовым терминальным серверам может поплохеть и при загрузке меньше 80%. и без вопросов, закладываться на полную нагрузку, не имея в ферме резервных машин в стендбае это плохо.<br><br>&gt;&gt; там есть какая-то HPC специфика, которую я упустил?<br>&gt; Ну и опосредованная -- через латентность -&gt; длину линко https://slinkov.ru/openforum/vsluhforumID3/87349.html#219 Mon, 19 Nov 2012 23:18:36 GMT &gt;&gt; Средняя плотность выделения тепла AFAIK выше<br>&gt; иии что?<br><br>Иии соответственно охлаждать приходится интенсивней[, мониторить оперативней].<br><br>&gt; во-первых, не загруженные на 100% серверы в ДЦ - это не нормально, КМК<br><br>Интересно, я до сих пор сталкивался только с народом, который предпочитает оперативный запас порядка хотя бы 10--20%. (без подковырок, сам-то не ДЦ-шник)<br><br>&gt; ага, спасибо, интересная штука. а бывает и так: <br><br>Сурово :)<br><br>&gt; что касается той системы, на которую вы кинули ссылку, то у меня <br>&gt; на второй странице сложилось четкое ощущение, что система предназначена для мониторинга <br>&gt; любой системы, генерящей большое количество ивентов, будь то суперкластер, или например <br>&gt; какой-нибудь 5ess.<br><br>В принципе да; см. тж. слайд 12 вот здесь: http://ftp.linux.kiev.ua/pub/conference/peers/foss-sea/2011/reports/shigorin-hpc_integrated.pdf<br><br>&gt; там есть какая-то HPC специфика, которую я упустил?<br><br>Возможно, имеющая отношение -- в модели установки описываются платформы, которые в точности (до сенсора) соо https://slinkov.ru/openforum/vsluhforumID3/87349.html#218 Mon, 19 Nov 2012 18:40:07 GMT &gt;&gt; ну не все заблокировано без "если" а это сетевка буфер переполнится и <br>&gt;&gt; данные пропадут - нада быро в зад за новой порцией ну <br>&gt;&gt; карта тупая без dma.<br>&gt; не все ядерные спинлоки требуют блокировки прерываний. если мы знаем, что в <br>&gt; обработчике прерывания данный лок не понадобится с вероятностью 101% (1% добавлен <br>&gt; для исключения самоуверенности пишущего код :), то мы можем смело использовать <br>&gt; лок с включенными прерываниями. контекст свитчинг в ядре внутри спинлоков выключается <br>&gt; кроме того - как уже обсуждали - общая рекомендация по любым исключительным <br>&gt; блокировкам - минимальное время просиживания в оных. либо уход от оных <br>&gt; на другие механизмы <br><br>во начианаешь понимать почему один блок на всё плохо? мы все структуры ядра заблокировали на "почесаться" а могут происходит процессы которые тоже внимания требуют, и без оного могут терять данные, без относительно что разрешал ты прерывания или нет. ну короче в этом суть, но блин а что если прерывания не запрешал и оно произошло? круто а нужен https://slinkov.ru/openforum/vsluhforumID3/87349.html#217 Mon, 19 Nov 2012 18:27:11 GMT &gt; ну не все заблокировано без "если" а это сетевка буфер переполнится и <br>&gt; данные пропадут - нада быро в зад за новой порцией ну <br>&gt; карта тупая без dma.<br><br>не все ядерные спинлоки требуют блокировки прерываний. если мы знаем, что в обработчике прерывания данный лок не понадобится с вероятностью 101% (1% добавлен для исключения самоуверенности пишущего код :), то мы можем смело использовать лок с включенными прерываниями. контекст свитчинг в ядре внутри спинлоков выключается<br><br>кроме того - как уже обсуждали - общая рекомендация по любым исключительным блокировкам - минимальное время просиживания в оных. либо уход от оных на другие механизмы сериализации<br>