Свежие комментарии

У Nvidia - нет, не был, естественно. А вообще на SC12 - да был.

Вопрос открытый и интересный. По спекам - это терафлопсный (DP) чип, т.е. чуть похуже чем NVidia K20X (1.3 TF) по перформансу, чуть получше по гигафлопсам на ватт, т.е. примерно та же хрень.

При этом его позиционируют как "fully compatible with code written for multi-core Xeon" (прямо из рекламной листовки текст перебил) - что, по-моему, есть чистое вранье. Т.е. там векторные инструкции другие (AVX2-512 бит) и просто SSE4 (от предыдущих Xeon) код - очевидно не пойдет. Скалярный - вероятно пойдет, но смысла в этом никакого нет.
При этом перенос впрямую (перекомпиляцией) векторизуемого кода с SSE/AVX - возможен, но не всегда будет оптиммальным т.к. инструкции могут больше (gather, как минимум).

При этом, интел уже вложился туда неплохо. Т.е. вроде бы новые версии MKL умеют туда что-то оффлоадить (пока мало, будет больше).

Ну и на фоне MIC - будущее OpenCL в HPC становится интереснее. Потому что у AMD в этом месте, как мне кажется, руки уже опустились совсем (несмотря на выпусе свежих профессиональных акселераторов - никакой внятной жизни в районе APP я что-то давно не вижу). А Intel OpenCL для Phi уже раздает (для Linux only пока), и вполне возможно, что HPC-жизнь в этом месте оживится.

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

Оно отвечает только за перформанс по обычным операциям i/o в процессе ребилда - чем выше приоритет, тем хуже перформанс по чтению-записи в процессе.
Относительно наших печалей - это все ниачом, т.к. ребилды обычно валятся на плохом/ремапленом секторе, который в обычной жизни никто и никогда не читает - лежит в блоке с этим сектором какой-нибудь файл корейской локали, или гзипованный лог из прошлого века, и до ребилда никому ничем не мешает. Причем чем больше массив, тем больше в нем таких "потаенных уголков".
Я у себя пришел к выводу о необходимости включения Patrol Read или аналогичных по смыслу проверок линейным чтением, которые данный конкретный контроллер умеет. По крайней мере это снижает шанс именно "нежданчика".

даже больше - 1,2
но с выводом из группы по любому чиху можно смело делить на 4.

да ладно - на примере пчелайна все было очень похоже - MTBF ~ 300кчасов, ~10к наших (hi-end HP) дисков, вылет - раз в день. вот только raid5 без hot spare - это зло...

У адаптека есть приоритет задачи (ребилда). Но за что он отвечает - не в курсе.

Мы поэтому зареклись вообще даже по одному менять без двойного бекапу для начала - сначала нужные данные, потом фулл-дамп, just to be on the safe side. "Береженого бог бережет", - сказала монашка, натягивая презерватив на свечку..
ИЧСХ, вот делишься с окружающими "веселым" опытом замены хардов в рейде (за последние лет пять ожидаемых нежданчиков было штук шесть, причем разных, вплоть до отвала башки у контроллера на старых LSI Logic) - и все равно эти "окружающие" потом прибегают с вопросом - ой, у нас все распалось, что делать, как жить дальше.

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

Частнику трудно так.

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

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

Да все понятно. Оставшие 4 сигейта буду по одному менять. Снять с полки, развинтить, поменять, свинтить.
У меня же не hotswap и вообщее трудно разобрать-собрать, потому и по два.

Просто вот эти вот вероятности, 1млн часов и все такое - они к реальной жизни совершенно никакого отношения не имеют. И жизнь про это периодически напоминает.

Добился вроде с 2012-м. Хотя и сексуально
1) Пересобираем Qt 2012-м компилятором.
2) При работе со своим проектом:
- ставим пути к 2010-му VC++ и QMAKESPEC=win32-msvc2010
- запускаем qmake -tp vc
- получившийся проект (для 2010-го) - апгрейдим 2012-м при первом открытии.

Вот так - все работает. Генерированный для 2012-го проект, равно как и генерированный для 2010-го (spec win32-msvc2010) но c путями к тулчейну в 2012-й - не работают.

Да и с 2012 вижуалом что то не завелось. Пичаль и фэйспалм какойто.

Да, я видел. Ну деваться некуда, если уж взялись все на QML.

BTW, в Beta2 скачанной с сайта - OpenGL-примеры в QML - не работают. У той что скачивал пару дней назад и собирал сам - работали не все (базовые работали, а плагин с материалами профукался). Мне они не то чтобы нужны сейчас, но обидно.

Базовые OpenGL-примеры (с QGLWidget) - работают т.е. дело не профуканной поддержке.

Можно, наверное (ничего про это не знаю, google:wxwidget declarative programming ничего приличного не выдает).

Но так как обсуждаем мы другое, то ссылочку вашу я того...