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

Практика чего, замены 384гб памяти в мейнфрейме на дорогую ецц с последующими результатами в виде увеличения стабильности работы какого-нибудь многоюзерского продукта от Дассаулт?
Да не бывает такого.
Либо память гавидло и глючит сразу или по прошествии некоторого времени (дефекты производства), либо не совместима с соседней (другая ревизия), либо работает и хоть ты её торием посыпай.
Контроллеры рамы нынче уже не такие тупые как раньше.

Очень здравая идея сравнивать качество памяти на алгоритмах с потерями.
Ну если квад ХД в 4 мегабита кодировать там вообще каша будет, при адекватном уровне мегабит на квадратную секунду хоть два бита изменяй, не заметишь ничего среди общего фона какашек.

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

Я говорил.

А зачем на воркстейшне аниматора 12 ядер на 2.3 ГГц? Там что, задачи параллелятся на слабосвязанные потоки?


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


Вот незадача-то, предостаточно памяти которая дает 1-2 сбоя в сутки. Иногда - даже реже. Вы что, неделю платформу мемтестом гоняете перед установкой в продакшн? Не? А с чего такая наивная уверенность, что пмять не глючит?


А контроллер-то тут причем? Какой бы умный он ни был - ну не угадает он, что в конкретной ячейке памяти единичка в ноль флапнула или наоборот, блгодаря прошедшему сквозь затвор гамма-кванту. Эмулятор хрустального шара в контрллерах еще не запилили.


Ну упакуйте 100ГБ данных раром/зипом, измените 1 бит, попробуйте распаковать. Алгоритм - бес потерь, а результат - еще более печальный.


Возьмите 100 мбит поток. Поправьте в I-кадре любой бит. Полюбуйтесь на целиком запоротую последовательность (секунд 5-30, да).


Программист тут при чем?
Или вы не догадываетесь, что знак экспоненты кодируется одним-единственным битом, при изменении которого 10^-9 внезапно превразается в 10^9?
Что будет с вашими обожаемыми расчетами, если в матрице произойдет такая метаморфоза? И куда следует выкинуть потом результат?


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


А вас о нем спрашивали?

NiTr0

Например, делать превизы.

ЧТД - кушайте качественную память.
У меня раньше была коробка, в неё я складывал дохлую память, ецц там тоже была

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

А откуда уверенность в том что ошибка пришла из памяти?

Память толщиной в один атом? один затвор выбьет, а может строку или всю страницу разом?
А может два модуля сразу, насквозь?

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

5 секунд это 120-150 кадров, при 100мбит поплывет только в случае совсем статичной картинки в громадном формате, неубедительно.
Казалось-бы, причем тут оператива...

Ну да ну да, индусы хорошие, просто на них наговаривают.

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

Я полагаю что на частоте 4 гигагерца, заметить это, человеку - не дано.
Заметить нечто подобное можно будет только в случае устойчивой ошибки - например одна из вершин 3д модели улетит в ноль и будет там сидеть утягивая за собой полигон с текстурой, или пиксель будет не того цвета.
Впрочем, устойчивая ошибка она и в ЕЦЦ таковая, и не лечится.

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

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

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

Добавлено спустя 25 минут 38 секунд:
Да кстати.

Бывало и такое.
Чего только не сделаешь ради того чтобы эти с*ки работали стабильно.

И чо, 12 ядер по 2.3ГГц окажутся быстрее 8 ядер по 3.2-3.4ГГц?


Качественная память нечувствительна к фоновому излучению? Или вы о space/military? Так огорчу, нет оных на десктопы


Превосходит. При вероятности сбоя пускай 1 бит в сутки - какова вероятность того, что в слове 64 бита случатся 2 ошибки?


А откуда, из астрала?


А почему в атом? 10-15 атомов. Ионизировать их, образовав канал для утечки заряда - элементарно. Для этого в общем-то даже энерги фотона видимого спектра предостаточно. Пример - CMOS матрицы видеофотокамер.


Кеш ФС. А еще есть многомегабайтный словарь архиватора - который еще больше "нечувствителен" к ошибкам.


Открою вам огромный секрет: порча I-фрейма портит всю последовательность, P-фрейм - портит все последующие вплоть до нового I-фрейма. Малозаметна порча B-фреймов, но по факту их объем едва % до 30-40 от общего потока дотягивает.


Вы знаете методы программной проверки корректности вычислений, без проведения повторных расчетов?


Угу, вместо недели - потратить минимум 2, а то и 3, лишь бы сэкономить на нормальных комплектующих
А еще есть расчеты в реальном времени (billing сервисов к примеру), которые никто в здравом уме не пересчитывает многократно.


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


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


Если вершина модели улетела неведомо куда - она там и останется. Никто ведь модель не "перерисовывает" в памяти по-новой каждый такт процессора.


Не несет оно ответственности. Банально - по причине невозможности быстрой проверки корректности результатов.


Тем более - заметить ошибку становится еще труднее.


А зачем вы приплетаете объем памяти к вопросу о ЕСС?


У меня замена памяти на ЕСС все проблемы прекрасно решала. В т.ч. и на домашних машинках. Ну кроме одного хламовника на кор2 - который с завидной регулярностью портит архивы бекапов (если они запускаются по расписанию), а менять на нем память смысла не вижу - ибо пора ему делать тотальный апгрейд, но пользуюсь нам мало, от того апгрейд откладывается.

Ничо, порядок производительности 1x3930k vs 2xeon2630 я приводил три страницы назад.

ЕЦЦ это обычная память, она так же беззащитна перед внешними воздействиями, у вояк такая-же.

Да нет конечно, не превосходит. Степень избыточности мизерная.

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

Ну, раз не атом - так и получи выбитой всю страницу.

Ключевой тезис.

Открыл? Теперь закрой с той стороны.

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

2% потерянных в результате ошибок блоков это плюс 2% к общему времени счета, а не 200% и тем более не 300%.

Ну так они и к ошибкам менее чувствительны.

Откуда мне знать? Какие требования такая и точность.

Позволит как минимум аппроксимировать результат.
Без проверки та же газодинамика просто крашится.

Детский сад.

Вершина останется в нуле только в случае устойчивой ошибки, и статичной картинки.

Всё что не несет - либо забивает на ошибки по причине их некритичности либо в кратчайшие сроки крашится.

Это не я приплетаю, это кто-то недостаточно внематочно читает.

Результат работы рендера видим, все существенные ошибки либо визуально идентифицируются либо валят рендер.

Шапочку из фольги не пробовал надевать?
Причин из-за которых память могла сбоить - вагон и тележка.

12 ядер на 2.3 ГГц, вот незадача, будут медленнее 8 таких же ядер по 3.2 ГГц, даже при абсолютно линейной масштабируемости софта.


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


Советую открыть учебник по теории вероятностей, что ли... Освежить память.
И да, степень избыточности - вполне достаточная. Ибо если вероятность ошибки допустим 10^-15 бит/сек, то вероятность двойной ошибки в том же слове будет 63*10^-30. Совсем незаметно, да...


Угу, угу. Считается СЛАУ эдак с 1М переменных, матрица 1М на 1М, объем данных - порядка 1 ТБ. И вы ее предлагаете в 3 местах хранить...


Реализуйте промежуточную проверку в алгоритме трассировки лучей... Да-да, а еще учесть, что вершина полигона может "улететь" в процессе расчетов в неведомую сторону...


С какой такой радости-то??? У вас что, один-единственный затвор полевого транзистора на всю страницу???


Угу. Террабайты хранить. И с какой периодичностью их сверять? И что делать с результатом вычислений - куда его натягивать? Или трижды считать?
А главное - приведите примеры такого софта, существующего в реальной жизни, а не в вашем воображении...


А откуда вы узнаете, в каком месте эти 2% потерялись? Без полного цикла повторных расчетов??? Из астрала знания придут?


Угу, угу. Поступила на счет сумма вместо 1$ в 8193$ - никто и не заметил такую мелочь Жжоте товарисч...


Ну вот и вывод - считаем неделю, получили на выходе хрензнаетчто, примерно похожее на правду, что с тем же успехом можно было посчитать за 5 минут примерным методом. И носимся, как дуркаи с писанной торбой, с этим хрензнаетчем, считая его верным результатом вычислений. Годный подход, чо. А потом удивляются - чего же это ракеты падают


Вы о себе? Вы действительно верите, что идетативный подход при изменившихся случайным образом исходных данных даст вам какой-то верный результат, а не результат для "новых" мусорных исходных данных?


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


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


И при этом упорно юзаете помоечную память без контроля ошибок...


Угу, угу. Только замена памяти на ЕСС - эту проблему устранила раз и навсегда.
А вы можете продолжать искать свой вагон и маленькую тележку причин, вместо устранения источника проблемы.

Нельзя пояснить, каким образом - камень, имеющий 60 метров кэша, больше потоков, больше "конечной частоты" будет медленней 8-ядерника в идеальных условиях масштабирования и если при этом закрыть на то, что с увеличением частоты постепенно и потихоньку начинает проявляться кукурузность частот?

NiTr0

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

Да мне по барабану что ты там себе придумываешь, есть результат научного исследования, и рапорт в открытом доступе, в среднем на модуль 3700 ошибок в год, из этих 3700, могущих быть скорректированными ECC - 5%.
Где теперь твой ЕЦЦ-бог?

А я тебе советую мне не советовать. Ты в тервере такое эпическое нубло что освежать что-то точно нужно не мне.

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

Зачем? 0_0


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

а) Нужно быть конченым дегенератом или вредителем чтобы не произвести анализ выходных данных.
б) Если считали скажем ветровую нагрузку небоскреба, ну пропали 2% - да и х*й с ними.

Дурь. Видел я как 2 доллара превращаются в 0.27, а потом в 3, а потом в 0.12, но шоб в 8 кусков, ни за что не поверю

См выше. За неделю посчитается точная модель небоскреба.

Всё работает, один ты умный, матрицы иди учи.

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

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

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

ВААРТ не лечит ВИЧ.

Пффф.

А "кукурузность" ядер/потоков - не, не проявляется?
MIPS/МГц - растет какбы линейно от частоты. Упирается все в ПСП/cache misses - но первое какбы не зависит от кол-ва ядер, а второе - чем больше потоков, тем больше кеша надо для их обслуживания.
И да, 8 ядер на 3.2 ГГц будет тупо быстрее по суммарной проивзодительности...


А охлаждать сего монстра, жрущего в указаном вами режиме Вт под 500, кто будет??? Пушкин???


Что мсье курил??? Посмотрите исследование гугла что ли. 3700 скорректированных ошибок в год. В среднем на 8% модулей. При этом нескорректированные ошибки наблюдались у в среднем 0.22% модулей.
И это даже без chipkill, обычная ЕСС.
Как-то не вяжется с вашей альтернативной реальностью


3.14 же.
Мсье хамло не осилил курс тервера, и не знает как считается вероятность двух несвязанных событий? Или мсье хамло может привести доказательства связанности двух сбоев в одной строке памяти?


Ога. В исходных данных особенно


Да к примеру расчет устойивости конструкции какого-либо крупного здания. Ну или метеопрогноз.


Ну если 1000 ядер офисных тазиков - то да, гарантия


Вам не важен результат рендеринга?


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


Если они в явном и неизменном виде сохраняются до конца расчетов - можно конечно и провести сравнение. Но далеко не в каждой задаче такое возможно.


А нафига тогда собссно считать что-либо, если достаточно обойтись примерной "прикидкой"? Все равно ваши расчеты-то будут столь же "точными", как и данная прикидка...


Мсье не догадывается о том, как данные хранятся в памяти?
Сумма - число с фиксированной запятой. 16 или 32бит целое в общем. то будет с суммой, если поплывет не младший бит, а старший??? Или мсье с помощью магии запретил старшим битам слов меняться из-за ошибок?


Халва, халва...


Ну и кто будет вершину возвращать на место в процессе рендеринга кадра сцены? Пушкин?


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


Я уже помоечную десктопную память не юзаю какбы. Где сколь-либо важные данные - стоит ЕСС. Вы - можете продолжать отбирать лучшие кусочки из помоев и кричать, что ЕСС не нужно. Перепроверяя результаты 100500 раз.


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


Аналогия некорректна.

И все-таки ответ нечеткий. Чем выше частота - тем сильней выражена кукурузность - или теперь все по-другому?
В чем проявляется кукурузность при увеличении потоков при идеальном масштабировании - а точней, где можно глянуть как, например, 8-ядерник 3 ггц (20мб) сливает 6-ядернику 3,7 ггц (15мб) в задачах (с х2 количества относительно количества ядер) где поддерживаются 12 и 16 потоков соответственно?

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

Да, тут я порядошно лоханулся, давно не видал этот документъ.

Собственно чипкилла и касалось моё упоминание о "не тупых" контроллерах, от которых пользы очевидно гораздо больше чем от просто ECC памяти.
Так же вполне очевидно что эдакий "raid" чипкилла обладает существенно бОльшей избыточностью нежели сама ЕЦЦ память.
Отсюда вполне резонный вывод - ецц память сама по себе днище

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

И че? Кусками считается, склеивается, всё что из ряда вон - игнорируется или тем или иным образом подгоняется.

Вот уж чему чему, а метеопрогнозу на ошибки по барабану.

Нет такой гарантии, всё работало.

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


Выдыхай

Если фон высокий, ЕЦЦ ничем не поможет.
Были даже безумные идеи - локальная защита полупроводниковых компонентов, свинцом, карбидом вольфрама 0_о

Значит считальщики будут в последствии СТРАДАТЬ.

Кто сказал что достаточно?
Пересчет 2% данных это не примерно, это почти точно.

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

Железо работает, без сбоев, большой аптайм.
Проблемы?

Никто не будет, по результатам бсода память заменят и всё. Всё как у всех.

Не в кассу.

Эко тебе припекло, лол.

См. выше.
а) Дегенерат
б) Вредитель.

Вероятность приобретения битой памяти равнозначна как в случае с ЕЦЦ, так и в случае обычной.
Можно целый год просидеть с одним битым модулем и не знать что он битый просто потому что потребление памяти меньше общего объёма.

Можно и не проверять, кому какая наплевать что очередная ракета упала.

Чеито?
У тебя на матери кондер вздулся в цепи питания памяти, побежишь брать ецц шоб комп не падал?

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

Диплом штрих кодом на затылке пойдет?

Если ваш диплом пойдёт, то его нужно поймать, и писать по нему диссертацию. Не меньше чем докторскую.
А там и нобелевская недалеко ))