Страница 4 из 4
Добавлено: 24 апр 2007, 21:37
alpax
tiasur писал(а):Ещё раз для тех кто в каске.
В каске тут, похоже, всего один.
tiasur писал(а):У меня процессор Opteron 175.
Я добавил вот эти двбе строчки:
AuthenticAMD Family 15 Model 12 atlas_Athlon.dll # Athlon 64 (Newcastle)
AuthenticAMD Family 15 Model * atlas_Athlon.dll # AMD64
Прчём тут мой процессор?
При том, что он как раз подходит под последнюю строчку, которую криворукие авторы сами не догадались добавить.
Добавлено: 24 апр 2007, 21:41
tiasur
Ну может я и соглашусь что подходит. Но ведь Матлаб это не ворд процессинг, продукт гораздо серьезнее, а чайники в програмерах по 100К с лишним получают?
Отрыжка дот нет программеров? Печально всё это.
Добавлено: 25 апр 2007, 11:23
Gadi
tiasur писал(а):Но ведь Матлаб это не ворд процессинг, продукт гораздо серьезнее
С точки зрения сфер применения - возможно.
А с точки зрения сложности создания "продукта" - далеко не однозначно.
Добавлено: 21 май 2007, 21:36
Шэф
Gadi писал(а):tiasur писал(а):В общем как было так и осталось; программные продукты затачиваются под Intel
Мне кажется в этом утверждении кое-что пропущено. Правильнее будет так:
"В общем как было так и осталось; программные продукты,
которые затачивались кривыми руками, затачиваются под Intel"
ПС
Это же как нужно было код написать, чтобы список "поддерживаемых" (видимо за шкирку) процессоров определялся наличием или отсутствием соответствующей строчки в текстовом файле?
т.е. если убрать строчки:
Код: Выделить всё
GenuineIntel Family 6 Model 7 atlas_PIII.dll # Pentium III (Katmai)
GenuineIntel Family 6 Model 8 atlas_PIII.dll # Pentium III (Coppermine)
то эти модели тоже будут глючить? При использовании одной и той же dll и неизменном коде? Мда ...
АМД не дрянь. программы без указанных строчек глючить не будут.
все дело в микрокоде который реализован внутри камня. т.е. оригинальный - это собственность интела. инженеры амд разработали собственный учитывающий отличия в архитектуре.
я сталкивался с подобными вопросами еще лет 10 назад. в конце концов выяснилось, что некоторые приложения включают библиотечные процедуры добавляемые по умолчанию при компиляции которые перед запуском программы проверяют скорость проца. так вот, у амд конкретно этот кусок мкрокода реализован эффективнее и это процЭдурка вылетает с переполнием стека так как скорость просто зашкаливает. такой вот суксь.