Boeing737
Зачем?? Глюки-то одинаковые, не могут ведь все ставить одинаковую глючную память именно на А64,
а вот материнки запросто могут оказаться с одним чипсетом

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

awl
Если бы дело было только в чипсете это давно бы выяснилось.
А вот на счет связки память+материнка у меня самые большие сомнения. Начиная с рождения, А64 стала, наверное, самой капризной по отношению к памяти платформой (про разгон я даже не говорю) http://www.thg.ru/mainboard/20040604/index.html Допускаю, что AMD для себя уже все прояснили и либо втихую разослали очередные рекомендации производителям материнок, либо (в худшем случае) это проблема Винчестеров какой-то партии или ревижена.
Главное отличие Винчестеров - 0.9 процесс, а смена процесса еще никому не проходила даром (вспомним сколько проблем было у Intel). Плохо, что если действительно проблема в AMD, мы об этом никогда не узнаем, они это просто пофиксят, особо не афишируя...

Так что - только тестирование и с большим объемом комплектующих, иначе не получится исключить возможную несовместимость мамка+память ...

Ага, пример безглючной системы привел Последний раз студенты в качестве КУРСОВОЙ РАБОТЫ нашли 40 ошибок. Суперстабильность.
Не забываем про софтовое окружение. С разными системными DLL работать может по-разному. Я уже говорил, что они не использовали компилятор от Microsoft или Intel и поэтому уж не взыщите.

Может мне просто промолчать? Корректно реалищовать код cpuid для будущих процессоров невозможно. Ты сможешь расшифровать биты, которые еще не определены?
Ты уверен, что по наличию SSE2 они не считают что проц именно Pentium 4? Реализации многих процедур немного отличаются для процессоров AMD, можешь посмотреть примеры с сайтов Intel и AMD. Обратите внимание - Athlon 64 это первый проц от AMD с поддержкой SSE2. Я вполне допускаю, что проблема может быть именно здесь.

Почему?
А программа столетней давности об этом знает?

А их никто не ищет. Позиция разработчиков не изменилась - это глючит ваше кривое железо!

Увы, не может. Архитектура меняется. Athlon перенимает фишки Pentium'а и наоборот. И старая программа может их перепутать.
А здесь идет речь о сильно оптимизированном софте (по словам разработчика)
Снова мимо. В случае с nVidia SoundStorm проблема обнаружилась (и подтвердилась самой nVidia!) в драйверах. А в случае с Azalia поменялась архитектура и микшер стал несовместим с Виндовым стандартом. Для примера использовался референсный код из комплекта разработчика от Микрософта. Хотя и Realtek с дровишками тоже накосячил (опять же сами признали!).

У меня стати работает на всех машинах без проблем - запустил вчера как началось это обсуждение.
У меня позиция простая - если не работает одна из ПОЛЕЗНЫХ программ, то у меня будут претензии, в противном случае меня это не интересует.
И не надо подменять понятия! S&M разработан для тестов стабильности и я ему доверяю. Prime чисто рассчетная софтина и может глючить при использовании "специфических" алгоритмов особенно при их некорректной реализации. Давайте еще калькулятором вручную стабильность мерять!


А все системы в равных условиях? Весь остальной софт у всех одинаковый? Кстати, выполнение некорректного кода приводит к неопределенному результату...
Да, идти к производителю софта и требовать апдейт. Чесно говоря мне и в голову никогда не приходило что-то валить на железо. Если человек заплатил мне деньги, то я просто выпущу апдейт который эту проблему решит. ДАЖЕ ЕСЛИ ЭТО НЕ МОЯ ОШИБКА.

Я об этом уже говорил. Судя по предыдущей версии разработчики используют MASM для компиляции ассемблерного кода. А вот какой компилятор C++ используется непонятно. Даже если это Visual C++ от MS , то с какими апдейтами?

Про ошибку раньше никто не слышал, потому что Athlon 64 так же как и Prime95 не были особенно популярны до последнего времени. А сейчас все начали тестировать и началась шумиха. Athlon 64 для Prime процессор новый, он SSE2 поддерживает и на совместимость его никто не проверял и похоже не собирается.
Разработчик не желает искать ошибку, а нагоняет ажиотаж.

Толи я чего то не досмотрел, толи.....

с чего вы взяли, авторы Prime 95 нагоняют ажиотаж и "кричат про ваше глючное железо" ????
где эти заявления от разработчиков?

я просил народ протестить Прайм с заниженными таймингами памяти ....

Давай вот не будем, а? А то можно и "маздай глючный" припомнить, и ошибочки, по которым УДАЛЕННО можно было поиметь систему.

Неужели, наивные, вы думаете, что профессионализм определен корочками и возрастом? У меня, вон, полгруппы корочки получат, а дубы дубами.
А иные троечники реальные профессионалы.

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

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

А они на все вопросы про ошибку тычут пальцем в FAQ, где написано, что Prime абсолютно безглючен и во всем виновато железо! С этого вся истерика и началась.
Нормальный разработчик сказал бы что работает над ошибкой или ОТКРЫЛ БЫ КУСОК КОДА КОТОРЫЙ ВЫЗЫВАЕТ ОШИБКУ, ЧТОБЫ ЭКСПЕРТЫ МОГЛИ ДАТЬ СВОЮ ОЦЕНКУ.

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

С чего я и начал, к тому и пришли...

По-моему здесь многие постоянно забывают, что Prime как Windows-приложение сам по себе не сбоит (с сообщением вроде "Недопустимая ошибка"). А выявляет неточность в вычислениях ! Так что никакие проблемы с ОС или DLL тут не присутствуют.

Предлагаю новый способ - проверить глючит Прайм или все-таки Athlon 64: надо "превратить" A64 в обычный Athlon.
Для этого надо отключить кратковременно поддержку SSE2, например через BIOS или написав специальную прогу (помню для AXP была прога для отключения определения SSE)..
Если это сложно - то можно просто подправить (т.к. исходников Прайма не достать) код Прайма (определение SSE2 с помощью CPUID) например hiew'ом, так чтобы SSE2 не определялся.
Если и после этого Прайм будет глючить, то скорее всего проблема в проце(комплектующих)..
Впрочем если глюков не будет, то все равно имеется небольшая вероятность например того, что A64, криво работает с SSE2..

Айс, не надо на пустом месте спорить...
Изложи точку зрения, пожалуйста. Для идиотов в двух, трех словах...

BloodyWerewolf
Элементарно, при инсталяции XP задаешь соотв. тип процессора - получится чистый 386. Но без SSE проц не будет работать на полную катушку и проблема может не возникнуть. Кому не влом - проверяйте

Сначала немного оффтопа (уж не могу удержаться - простите люди добрые...)
Mosga
Выражаю искренне восхищение твоей позицей. Честно. Просто приятно видеть.

Nord1504
Спасибо за конструктивный диалог.

Теперь к теме:
Лично я верю, да-да именно верю в Prime95. Вообщем при объеме кода измеряемого мегабайтами немудренно, что ошибки в программе есть. Этого я не оспариваю. Но, именно стрессовое тестирование протестированно (извините за тавтологию) многократно. Для математического расчета это почти не нужно (надеюсь меня правильно поняли: математические аспекты почти любой программы пишутся влет(знай стучи по кнопкам...)). Хотя я понимаю: никого мне не убедить, но все равно...

Кстати много раз здесь упоминалась S&M, ничего не имею против, но это тоже всего лишь программа и когда я читаю доводы о том, что на Prime95 выдает ошибку, а S&M - нет, а следовательно Prime95 нам не нужен, я думаю:"А какое основание для данного вывода? Почему не наоборот?".

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

1. В новых 64 процессорах какая-то недоработка. (Ок это мнение понятно)

Теперь мое мнение
2. Допустим в Prime95 ошибка - ок. На новых процах все вылетает - Ок. Но почему одно и тоже программное исключение (несомненно оно возникает и на процессорах другой серии (ведь Prime95 ничего не знает об AMD64)) обрабатывается различно? Теперь мой вывод: или нет обратной совместимости с предш. моделями процессоров или п.1.

3. В Prime95 серьзный баг - в это как-то слабо верится(в баги верится), а вот в серьезный баг в тестировании ... мои доводы см. выше.

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

как программист я сам не раз сталкивался с тем, что прога работая на одном компе не работает на другом, в том числе и работая на десятке компов не работала на одном, и в большинстве случаев при выяснении обнаруживалось, что ошибка моя, иногда еще из за различного поведения софта (например при использовании DDE в NT системах exe-шник запускается, если не объект не найден, в 9х - вызывающий объект попросту виснет намертво).

еще из своего опыта:
2Айс
я вижу ты человек воспитанный, вежливый и сдержанный, я этим не скован
много раз сталкивался - человек, употребляющий подобные выражения -



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

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

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

Полнейший оффтопик:
А может все же сисадмином?

Boeing737

Боюсь, что это не отключит SSE...

В таком случае излагаю все доводы последовательно:
Ошибка может проявиться на следующих уровнях:
1. Сам код программы. Ассемблерная оптимизация собранная с миру по нитке. Неправильное определение типа процессора
2. Компилятор. Пока фактор неизвестный, но далеко не последний
3. Операционная система - имеются ввиду системные библиотеки
4. Драйвера, да, да, драйвера. И не только для процессора
5. Одновременно запущенные программы - вполне могут даже вышибить другой процесс.
6. Новые технологии в Athlon 64 могут неккоректно взаимодействовать с данной программой - SSE2, C&Q, NX-bit

Ошибка далеко не всегда проявляется как Некорректная операция. Вполне достаточно не сохранить значения регистров или регистра состояния FPU.
Теперь вспоминаем различия в реализации блока FPU, различия в реализации поддержки SSE и SSE2. Я давно этим не занимался(не буду углубляться, но если есть желание, то подниму документацию), но переключение режимов и сохранение состояния для AMD и Intel отличается.
Тем более, что SSE эмулируется через вызовы 3DNow! Т.е. нюансов много. Оптимизация велась под SSE и очевидно SSE2.
Изначально предполагалось, что SSE2 будет выполняться только на Intel Pentium4. Вот тебе и корректно написанная программа - кто мог предположить, что SSE2 будет на процессоре AMD заранее!
Если прога определила наличие SSE2 в проце, то она запускает процедуру позаимствованную с сайта Intel. А будет ли она работать на AMD?

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

P.S. Приношу извинения за большое количество опечаток в постах - еще не привык к новой клаве.

TOB.CTAJIuH
Лично не проверял, но не тока SEE даже MMX отрубится %)

Добавлено спустя 23 минуты, 7 секунд:
Айс
пункты 1,2,4,5 : Prime просто не шел бы на A64 или вылетал бы с ошибкой приложения (чего не наблюдается).
3: уже пробовали на разных ОС
6: если теперь SSE от AMD не совместим с SSE от Intel, то это личная проблема AMD. Без C&Q, думаю, кто-то догадался попробовать, по NX - см. пункт 3.

Опять отвечаю по пунктам:
1. Никто не заставляет вылетать программу с ошибкой. Неправльно выставленный флажок приведет к ошибке в рассчетах. Несохраненный регистр состояния FPU опять же приведет к ошибке в рассчатх. Использование подпрограммы, оптимизированной для другого процессора приведет неизвестно к чему...
Забыли выравнять данные на границу параграфа и прощай SSE.
2. Не надо мне говорить, что перепробовали на всех Виндах. Все Винды у разных людей вполне могут отличаться хотя бы одной DLL или драйвером.
3. Я уже говорил, что некоторые функции из наборов SSE не поддерживаются на Athlon 64. И если программа этого не знает, то это ее проблема.

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

Еще все забыли о необратимых последствиях разгона. Я с этим сам уже сталкивался. Чел запускает Prime на суперразогнанной тачке и он у него вылетает.
Из-за разгона вполне могли произойти необратимые изменения в модуле FPU или в контроллере памяти. После этого человек снимает разгон и кричит, что Prime глючит даже на номинальных частотах. Этого тоже нельзя исключать.

Айс
опять же по п.1: тогда бы проблема наблюдалась на ВСЕХ А64.
п.2 на линуксе тоже кто-то пробовал.
п.3 аналогично п.1

убитые процы ? т.е. вы уже морально согласны, что проблема аппаратная ?