Добавлено: 01 дек 2005, 08:10
Можно ещё Turion попробовать...
Linux.by
Linux-портал Республики Беларусь
https://forum.linux.by/
Действительно ли вам нужен x64-процессор?
Страница 2 из 3
Добавлено: 01 дек 2005, 11:35
Victor Gr., пока что это можно считать просто быстрым 32bit процессором.
Добавлено: 13 фев 2006, 17:41
Про такую штуку, как prelink слышали? Так вот на AMD64 он вообще не нужен из-за того, что добавлен режим адресации относительно счетчика инструкций. Соответственно быстрее загружаются программы.Victor Gr. писал(а): Хотя, посмотрим, что нам покажет AMD64.
Вообще, в каких реальных задачах полезны 64 бита? Адресация памяти? А что ещё?
Вообще AMD64 кроме поддержки 64-битности - приведенная в порядок и "вылизанная" система команд x86. Увеличено количество доступных регистров, для floating point в ABI вместо x87 используется SSE2 и прочие мелкие усовершенствования. Прирост быстродействия вполне наблюдается, хотя и не столь существенный (правда на отдельных задачах, где требуется 64-битность, типа криптографии или arbitrary precision math, быстродействие растет в разы).
Добавлено: 22 фев 2006, 15:49
Особо и не нужен. 
Хотя, если попытаться написать что-нить под 64 бита... Боюсь, геморроя будет много. Словом, не готов пока к использованию. То, что линукс будет хорошо работать на АМД64, не сомневаюсь. 
Хотя, если попытаться написать что-нить под 64 бита... Боюсь, геморроя будет много. Словом, не готов пока к использованию. То, что линукс будет хорошо работать на АМД64, не сомневаюсь. Добавлено: 22 фев 2006, 17:00
Некому не захочется покупать быстрый 32битный проц если за эти же деньги можно купить такой же быстрый 64битный процесор
Добавлено: 22 фев 2006, 18:10
Gnida, разница между 32bit и 64bit пока что больше ИМХО маркетинговая... Если есть результаты выполнения одних и тех же тестов в tru64bit и обычным окружении - хотелось бы на них посмотреть. Я возможно заблуждаюсь, но ИМХО для полноценного использования 64bit простой перекомпляции будет маловато...
Добавлено: 22 фев 2006, 22:32
В любом случае , в преспективе 64 бита , а делать лишний раз апгрейд это геморой и деньги
Добавлено: 22 фев 2006, 22:54
Gnida, апгрейд - всегда геморрой....
Пример: SocketA жил долго и упорно. В материнскую плату с этим сокетом можно поставит _практически_ всегда любой процессор SocketA - т.е. можно последний Barton вставить в KT133 - и будет работать. примерно то же самое у интеля со SLot1/Socket370 - если мать умеет FBS133 - то ставить можно все что угодно, абы питание выдержало... Но все это в прошлом. ТЕперь производители нас так не балуют. AMD одарили нас Socket 754/939 и вкоре появится AM2. Intel "радует" своих фанов Socket428/478/775. И все они друг с другом никак уже не совместимы. Вообще.
Выводы: покупать систему под будущий апгрейд - занятие малоперспективное. Все равно через год-полтора у производителя появится новая платформа со всеми вытекающими....
Пример: SocketA жил долго и упорно. В материнскую плату с этим сокетом можно поставит _практически_ всегда любой процессор SocketA - т.е. можно последний Barton вставить в KT133 - и будет работать. примерно то же самое у интеля со SLot1/Socket370 - если мать умеет FBS133 - то ставить можно все что угодно, абы питание выдержало... Но все это в прошлом. ТЕперь производители нас так не балуют. AMD одарили нас Socket 754/939 и вкоре появится AM2. Intel "радует" своих фанов Socket428/478/775. И все они друг с другом никак уже не совместимы. Вообще.
Выводы: покупать систему под будущий апгрейд - занятие малоперспективное. Все равно через год-полтора у производителя появится новая платформа со всеми вытекающими....
Добавлено: 23 фев 2006, 08:50
Llama
Для полноценного использования 64bit перекомпиляции как раз достаточно (дополнительных наборов multimedia инструкций типа SSEx, которые нужно использовать специальным образом, там по сравнению с 32-битным режимом нет). Единственная проблема - в случае, если в программе используются ассемблерные вставки. Их необходимо переписать или придется использовать вместо них более медленную, но универсальную C-версию кода. Именно из-за этого на некоторых программах кодирования аудио/видео пока есть проигрыш (64-bit C vs 32-bit optimized asm). Но ситуация очень быстро исправляется.
Разница обычно в пределах 10-20% максимум, на некоторых задачах даже есть небольшой проигрыш, но в среднем результат положительный. Причем все очень сильно зависит от того, как проводились тесты и какая версия компилятора использовалась (новые версии gcc генерят лучший код для amd64).
http://forums.gentoo.org/viewtopic-t-22 ... hmark.html
Заблуждаться, конечно, не наказуемо, но обосновать свое мнение хоть каким-либо аргументом было бы неплохо.разница между 32bit и 64bit пока что больше ИМХО маркетинговая... Я возможно заблуждаюсь, но ИМХО для полноценного использования 64bit простой перекомпляции будет маловато...
Для полноценного использования 64bit перекомпиляции как раз достаточно (дополнительных наборов multimedia инструкций типа SSEx, которые нужно использовать специальным образом, там по сравнению с 32-битным режимом нет). Единственная проблема - в случае, если в программе используются ассемблерные вставки. Их необходимо переписать или придется использовать вместо них более медленную, но универсальную C-версию кода. Именно из-за этого на некоторых программах кодирования аудио/видео пока есть проигрыш (64-bit C vs 32-bit optimized asm). Но ситуация очень быстро исправляется.
google is your friendЕсли есть результаты выполнения одних и тех же тестов в tru64bit и обычным окружении - хотелось бы на них посмотреть.
Разница обычно в пределах 10-20% максимум, на некоторых задачах даже есть небольшой проигрыш, но в среднем результат положительный. Причем все очень сильно зависит от того, как проводились тесты и какая версия компилятора использовалась (новые версии gcc генерят лучший код для amd64).
http://forums.gentoo.org/viewtopic-t-22 ... hmark.html
Добавлено: 24 фев 2006, 16:12
Не так давно апгрейдил свой комп. Поменял материнку с сокет 478 на мамашу с сокет А. Селерон на Семпрон. Выбирал 32-битный проц из следующих соображений:
1) На компе вместе с линухом живёт винда, ибо моей девушке периодически периодически нужен InDesign. И чем похожим можно заменить его под Линухом я не знаю. Под винду соответственно есть СТАБИЛЬНО РАБОТАЮЩМЕ дрова не под все девайсы, да и сама 64-битная винда - это скорей экзотика.
2) Да на АМД-64 можно запускать обычную 32-х битную винду и 64-битный линукс. Но отчего-то у меня такое чувство, что когда будет следующий апгрейд, процы под сокеты 754 и 939 производиться не будут, а память будет юзаться ДДР2.
3)Платить лишних 25-30 баксов за прирост производительности в 10-20% как то жалко... Я лучше себе 256Мб памяти куплю.... Это будет подейственней.
1) На компе вместе с линухом живёт винда, ибо моей девушке периодически периодически нужен InDesign. И чем похожим можно заменить его под Линухом я не знаю. Под винду соответственно есть СТАБИЛЬНО РАБОТАЮЩМЕ дрова не под все девайсы, да и сама 64-битная винда - это скорей экзотика.
2) Да на АМД-64 можно запускать обычную 32-х битную винду и 64-битный линукс. Но отчего-то у меня такое чувство, что когда будет следующий апгрейд, процы под сокеты 754 и 939 производиться не будут, а память будет юзаться ДДР2.
3)Платить лишних 25-30 баксов за прирост производительности в 10-20% как то жалко... Я лучше себе 256Мб памяти куплю.... Это будет подейственней.
Добавлено: 24 фев 2006, 17:55
LOL.... Если б за рост в 10-20% можно было платить всего-то $$25-30
Производительность компьютера - величина весьма условная и явно интегральная...
Мифические +10-20 попугаев будут иметь место раз в год... разве что решаются сверхспецифические задачи которые наиболее требовательны к CPU. ИМХО на сегодянший день наиболее оптимальна плтформа с быстрой низколетнной памятью - что-то типа DDR500 - к сожалению работа чипсетов под SocketA на таких частотах (>=250Mhz)- явление не слишком-то распространенное и более оверклокерское... Другое дело - всяческие S745/S939 платформу. Весьма распространено заблуждение насчет "рулезности" DDR2 - выигрыш будет сугубо в применениях требущих последовательного доступа к большим объемам данных - например кодирование видео, архивирование чего-то там.... В случае произвольного плохопредсказуемого (читай - нагруженая многозадачная система) доступа - DDR2 с ее большой латентностью резко теряет свои преимущества... Вишка в том, что сама по себе латентность памяти весьма влияет на КПД процессора, минимузируя простои процессора при отсутсвии данных в кэше...
Производительность компьютера - величина весьма условная и явно интегральная...
Мифические +10-20 попугаев будут иметь место раз в год... разве что решаются сверхспецифические задачи которые наиболее требовательны к CPU. ИМХО на сегодянший день наиболее оптимальна плтформа с быстрой низколетнной памятью - что-то типа DDR500 - к сожалению работа чипсетов под SocketA на таких частотах (>=250Mhz)- явление не слишком-то распространенное и более оверклокерское... Другое дело - всяческие S745/S939 платформу. Весьма распространено заблуждение насчет "рулезности" DDR2 - выигрыш будет сугубо в применениях требущих последовательного доступа к большим объемам данных - например кодирование видео, архивирование чего-то там.... В случае произвольного плохопредсказуемого (читай - нагруженая многозадачная система) доступа - DDR2 с ее большой латентностью резко теряет свои преимущества... Вишка в том, что сама по себе латентность памяти весьма влияет на КПД процессора, минимузируя простои процессора при отсутсвии данных в кэше...
Добавлено: 24 фев 2006, 18:02
Обычно софт играет гораздо большую роль. sleep на device
занимает одинаковое время и на x86, и на 32 bit и на 64 бит.
Но опять же до определенного предела.
И вообще производительность обычно невозможно точно измерить.
Фишка по приколу для тех кто видео перекодирует. На чистой винде
mp2 -> avi работает раза в 2-3 быстрее чем если софта наставить
занимает одинаковое время и на x86, и на 32 bit и на 64 бит.
Но опять же до определенного предела.
И вообще производительность обычно невозможно точно измерить.
Фишка по приколу для тех кто видео перекодирует. На чистой винде
mp2 -> avi работает раза в 2-3 быстрее чем если софта наставить
Добавлено: 24 фев 2006, 18:15
Отклоняемся от основной темы, но все же я думаю, что производительность все же худо-бедно измерить можно. Что-то вроде:
# time mencoder [some cool options] coolvideo.mp2 -o coolvideo.avi
Думаю, разброса в 2-3 раза при запуске с одинаковыми настройками точно не будет
edit: mencoder для win32 запускаем из msys
# time mencoder [some cool options] coolvideo.mp2 -o coolvideo.avi
Думаю, разброса в 2-3 раза при запуске с одинаковыми настройками точно не будет
edit: mencoder для win32 запускаем из msys
Добавлено: 24 фев 2006, 19:45
serge, угу... и это будут весьма условные попугаи... Причем с явным преимуществом, как ни странно, Intel NetBurst/DDR2 что в 32bit что в 64bit. Сугубо из-за "толстого" канала процессор-память. Я придпчел бы что-нить комплексное, типа того же TPC.
Добавлено: 24 фев 2006, 20:57
Llama Дело не в том, чем именно мерять (это уже выбирает каждый для себя, в зависимости от того, какие задачи для него критичны). Просто exe поставил под сомнение возможность проведения самих измерений c более-менее нормальной точностью
Кстати, причина 'непонятного' замедления перекодирования скорее всего в том, что в систему вместе с установкой софта устанавливается и другой, более тормозной кодек, который потом используется вместо старого, т.е. тестирование проводится при различных условиях и разброс результатов наблюдается именно из-за этого. Тестировать нужно одну и ту же версию программы на тех же самых исходных данных и с теми же самыми настройками, тогда и будут более-менее вменяемые результаты. Параллельно запущенные другие задачи time тоже пытается учитывать, но лучше все же при тестировании не грузить комп чем-либо еще.
edit: Кстати, могу потестить и сравнить быстродействие в 64 и 32 битах чего-нибудь в gentoo linux. Пока еще полностью на 64-бита не переселился, установлены обе системы на разных разделах. Хотя флаги оптимизации использую довольно консервативные
Кстати, причина 'непонятного' замедления перекодирования скорее всего в том, что в систему вместе с установкой софта устанавливается и другой, более тормозной кодек, который потом используется вместо старого, т.е. тестирование проводится при различных условиях и разброс результатов наблюдается именно из-за этого. Тестировать нужно одну и ту же версию программы на тех же самых исходных данных и с теми же самыми настройками, тогда и будут более-менее вменяемые результаты. Параллельно запущенные другие задачи time тоже пытается учитывать, но лучше все же при тестировании не грузить комп чем-либо еще.
edit: Кстати, могу потестить и сравнить быстродействие в 64 и 32 битах чего-нибудь в gentoo linux. Пока еще полностью на 64-бита не переселился, установлены обе системы на разных разделах. Хотя флаги оптимизации использую довольно консервативные