какую архитектуру выбрать
johnpion 4 декабря, 2009 - 09:52
у меня два компа:
1) acer travelmate630 (2ГГц, 768МБ)
2) проц e3200 2гига оперативы -типа домашний сервер
в первом случае в чем разница в стейджах 486 и 686?
а на второй есть ли смысл ставить 64бита(я так понимаю оба ядра будут равномерно нагружаться?)
»
- Для комментирования войдите или зарегистрируйтесь
Цитата: а на второй есть ли
Битность архитектуры ни при чем. Есть специальная настройка в ядре для этого - SMP
Если проц 64-битный то и ставьте 64, нету никакого смысла x86.
1) Ну вообще-то при выборе
1) Ну вообще-то при выборе архитектуры важна не модель ноута, а процессор. Ну да ладно. Поправте если е прав, но на верняка там стоит или Сore2Duo или Pentium DualCore. В первом случае и во втором подходит i686. Однако если проц 64-й битный, то x86_64 лучщий вариант.
2) Я могу опять же ошибаться но и тут у вас скорее Core2Duo и опять же подойдёт и i686 и x86_64
Естественно разница между i486 и i686 есть - циферка побольше :) Ну а если серьёзно, то аршитектуры принадлежат разнам процессорам. Есткственно для каждой из них в пакетах будуь использоваться те или иные особенности пакетов, что может сильно сказаться на производительности. По этому предпочтительно выбрать архитектура вашего процессора. (я думаю она не ниже i686 гуглить лень) Однако i486 тоже подойдёт. Так же обстоят дела и с x86_64 и i686. Если поддерживается 64 бита, то надо ставить x86_64.
Не страшно даже если на ноуте и другом компе не совпадут архитектуры. (Я так думаю пакеты компилировать удобней на более мощном компе, которым как я думаю является сервер) Есть возможность собирать пакеты для другой архитектуры.
У меня например такая ситуация:
1) Acer Aspire One с Athom N270 на борту - архитектура - i686
2) Сервер с Athlon 64 X2 ну борту - архитектура - amd64
Для сборки пакетов для ноута пользуюсь этим рецептом.
johnpion написал(а): в
в первом случае используется меньшее количество инструкций и регистров оптимизация под меньшие размеры кеша и все в этом духе... в общем код i486 вы сможете запустить на P1, а i686 не ниже чем на P4
для многопроцессорной машины нужно включить SMP, а битность тут совсем не при чем! ;)
если проц поддерживает 64-бита, то имхо лучше и ставить 64-бита, ибо 64 бита нужны не только для того чтобы увеличить количество адресуемой памяти в нативном режиме и чтобы код стал больше... 64-хбитный проц всегда работает в 64-хбитном режиме, просто 32-хбитные указатели достраивает до 64-хбитных забивая остаток нулями... на это тратятся такты, а посему проц работает в 64-хбитном режиме быстрее, хоть и на глаз это не заметно...
имхо, есть просто люди со старым железом, которые успокаивают себя мыслью, что 64 бита им не надо, чтобы не апгрейдиться, и заводят других, а другие не понимая сути кричат, что им это тоже не надо... а потом появляются темы "что выбрать?", когда выбирать уже по сути нечего... все продиктовано временем и производителями железа :)
красиво сказал. буду вот
красиво сказал. буду вот таким сомневающимся ссылку на эот пост давать, дотсали глупыми вопросами. я для себя уже давно выбрал амд64.
эскадра ходит с максимальной
эскадра ходит с максимальной скоростью самого медленного фрегата....
i686 on PIII - проверено.... заводится...
опыт - суть ошибок личных (имхо)
если используются 32-битные приложения (wine- virtualbox- программы и\или др. бинарники) - то основным критерием выбора должна быть стабильность работы этих приложений.
по поводу "скорости"....
действительно, на глаз не заметно...
но вот тесты (nbench) показали заметное ухудшение на x64
однако я это списал на kde-4 и возможную недооптимизированность собранной x64-системы....
что-то добрый я сегодня ....
я возможно буду подымать
я возможно буду подымать virtualbox. Есть ли проблемы с 64битами? В ноуте (1) стоит четвертый пень
х.з. в прошлом году были с
х.з.
в прошлом году были
с тех пор на всех юзерских машинах стоит x86 + wine + virtualbox вне зависимости от проца
~amd64 с vbox'ом поставил нынче, но поднять win32 всё никак руки не доходят
что-то добрый я сегодня ....
у меня все работает. amd
у меня все работает. amd turion + ~amd64
у меня virtualbox-bin-3.0.12,
у меня virtualbox-bin-3.0.12, ~amd64
на ней 2 виртуалки, с виндой и centos, обе 32-битные; все работает на ура.
64-битные гостевые - нет
у меня уже 3.1.0 :) тоже
у меня уже 3.1.0 :) тоже 32битные гостевые. 64битные не пробовал.
64-x CentOS мне сказала, что
64-x CentOS мне сказала, что "your processor does not support long mode, use x86 instead" - ну или вроде того.
Но проц-то 64-разрядный...
Или VirtualBox 32 бита отрезает, или.. на этом мысль заканчивается.
У меня установлен
У меня установлен virtualbox-ose версии 3.0.8. На нём работает Debian 5.0 amd64
для запуска 64-битной
для запуска 64-битной гостевой ОС на 32-х битной хост системе кроме поддержки 64-битных инструкций процессор еще должен поддерживать виртуализацию vt-x (для intel) или amd-v. Иначе только 32.
ИМХО - если проц поддерживает 64 бита, то без колебаний ставлю amd64, если проц - 32-х битный, то естественно, тока i686. Ибо, как говорится, а зачем тогда вообще был куплен такой проц??? если тебе достаточно 32-х бит - купи самый младший целерон =)
:wq
код i486 вы сможете запустить
Тут вы маленько соврамши:
i486 собственно и есть i486 - очень популярный в с конца 80-х до середины 90- проц.
i686 - это пентиумПро и дальше (просто пентиум с частотами 60-66 мгц на сокет4 есть i586 ).
Вау, а биос то не вкурсе - потому стартует в реальном режиме.
если это так - покажите использование 64 разрядного регистра в 32 битном режиме - достаточно просто показать содержание
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
slepnoga написал(а): если
смотря когда, куда и откуда смотреть ;)
хм... тот же вопрос но на другой ляд
а какую архитектуру стоит выбрать для gentoo на флеш? что-то мне подсказывает что i486, я прав?
только если действительно
только если действительно собираешься юзать на компах слабее третьего пенька.
_SerEga_ написал(а): только
в том-то и проблема, что селезенкой чувствую, не только на них
_SerEga_ написал(а): только
Слабее Pentium, вообще-то.
Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.
Спасибо, теперь буду знать.
Спасибо, теперь буду знать.
зы тогда точно можно i686 ибо компы с до Pentium'ным процом большая редкость.
johnpion написал(а):у меня
ИМХО с таким количеством озу стоит ставить только i686, о 64 можете забыть, надо хотя-бы гига полтора для рормальной работы, ибо не забывайте что 64 жрет больше памяти.
Чушь!
Чушь!
+1
+1
+2
+2
+3
+3
Мы тоже не всего читали Шнитке!.. © В. Вишневский
Почему сразу чушь? Это ИМХО
Почему сразу чушь? Это ИМХО гостя, который так уверен в своих высказываниях, что даже не подписывается.
Стыдно, наверное, что его ИМХО является простым троллингом.
emacs — отличная операционка которой не хватает только хорошего текстового редактора.
Цитата: ИМХО с таким
Это - точно чушь.
А это - не совсем. В x86_64 размер указателя вдвое больше, чем в x86, соответственно - "жрет" таки больше. Но не настолько, чтобы это было реально заметно.
она не жрет больше, она может
она не "жрет" больше, она может "жрать" больше ;) для этого её и создали :)
стесняюсь спросить... Theli
стесняюсь спросить...
Вы занимаетесь практическим программированием?
А то, судя по Вашим категорическим утверждениям, - за плечами ох... опыт...
что-то добрый я сегодня ....
ну, не гуру, но работаю...
ну, не гуру, но работаю...
заразившись стеснением, тоже спрошу: вы можете воспринимать сообщение с улыбками и подмигиваниями, как заявление от истины в последней инстанции? О_о
эх... долго я молчал ;) Была
эх... долго я молчал ;)
Была поднята потенциально интересная тема - что лучше на 64-бит проце собирать - x86 или x64?
Почему amd64 "на глаз" не работает быстрее x86 ?
Вопрос, конечно, интересный
Но читать при этом ответы типа код больше или тратятся лишние такты на дополнение нулями указателей или еще что-то в этом роде - ну устал читать я этот бред.
Поэтому позволю себе дополнить этот холивар собственным бредом. ;)
Важное замечание - я давно уже не писатель, но иногда пользуюсь мозгами ;)
1) Несколько моментов, которые упускаются в дискуссиях подобного рода
- тактовая частота шины не влияет на прозводительность проца (частоты тут порядка 133-266 Mhz)
- обмен данными проца с памятью идет мимо шины (тут 133\266\400\800\1000 и т.д)
- проц получает код программы блоками в свой кэш (и не один) - а скорость обработки в кэше уже идет на скоростях работы проца
- в кэш код попадает не линейно (типа очередные 64K из файла-код-программы, и кусочно-блочными модулями с упреждающим прогнозом будущего выполнения)
Эти (выше) моменты не зависят от того в каком режиме работает проц - в 64- или 32- битном, равно как и не влияют на производительность системы в целом (возможность получить выигрыш производительности)
2) Упускается из виду конструкция 64-битных регистров.
Как они устроены, сколько их есть, когда и как они подключаются.
3) Замечания типа "больше, толще, шире" (о коде программ) - отметаются простой контрольной компиляцией.
Достаточно сравнить одни и те же программы (/sbin или /bin например) - насколько разница в длине?
%%10 -20 ???
Почему так мало? И где тут "больше, толще, шире"????
4)Замечания типа 64-битные процы "заточены" быстрее работать на 64-битном коде - чушь полнейшая.
-Достаточно посмотреть - Набор комманд процессора AMD64 - и посчитать (в % скоко много там 64-битных операций)
-Взять подручный дизассемблер и посмотреть в программе - а сколько 64-битных инструкций в ней наличествует?
-Подумать немного логически: Когда и зачем нужны реальные 64-бита, и как часто они используются по сравнению с "повседневным" операциями SUB, ADD, CALL NEAR, NEAR JUMP, XOR, NOT & e.t.c.
5)Всегда, когда это возможно, gcc будет использовать 32-битные команды, операнды, адреса.
Более того, даже тогда, когда нужно сработать с 64-битным указателем - байт-код по возможности будет оптимизирован.
Т.о. загрузить 0 в 32- или 64- регистр даже по тактам не будет отличаться.
Какой можно сделать вывод?
Для среднестатистического юзера выигрыш X64 по сравнению c X86 - не более как "маркетинговый ход" ;)
Реальный выигрыш можно получить при использовании охххххриняче больших программ, программ обработки видео- и звуко- и математико- моделировании с использованием сугубо специфических возможностей конкретных процов.
Но этот вопрос уже больше зависит не от конечного пользователя, а ,скорее, от автора-разработчика, имхо.
Таким образом (пока не увижу конкретных попугаев) смею утверждать, что разницы в производительности amd64- и x86- гентоо-сборки системы - нет!!!!
;)
что-то добрый я сегодня ....
позвольте задать Вам пару
позвольте задать Вам пару вопросов, просто для расширения кругозора и лизбеза, т.к. я не специалист в асме и компиляторах.
1. Есть ли разница в производительности памяти, когда ее 4G и больше при 32 разрядности(PAE) и 64 разрядности(нативно)?
2. Будет ли производительности выше у 64 битной системе при кодировании/декодировании видео, упаковке/распаковке архивов?
3. Поидее с каждым годом объямы памяти растут и все равно через 1-3 года вырастут до 12-16 гигабайт, так что все таки за архитектурой amd64 будущее, хотя бы по тому фактору, что kde4.3.1 были стабилизированы сначала на amd64, а потом уже на x86.
какие еще могут быть скрытые плюсы/минусы при сравнении этих архитктур?
зы амд64 при одинаковых флагах сборки и одинаковом софте все таки в памяти занимает на 10-20% больше - субъективная оценка имеющего 2 системы на одной машине.
Я тоже не специалист в асме
Я тоже
немножко понимаю (надеюсь, что понимаю) как работает проц.
1. Да, ПАЕ медленнее (теоретически) но! У вас много приложений, реально использующих более 4 GB RAM ? иначе разницы не заметить из-за железных особенностей
реализации (если на пальцах - ПАЕ-контроллер - это окошко шириной в 4 ГБ, двигающееся в памяти).
2. Сильно зависит от кода(софта, опций сборки, алгоритмов,етц )
3 он был стабилизирован на амд64 по простой причине - чисто 32 разрядных процев архитектуры ia32 в продаже нет ( из этого истекают простые логические выводы о наличии железа у девов)
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
leryc написал(а): Поэтому
"вот теперь тебя люблю я,
вот теперь тебя хвалю я" ;)
.
поясните, что вы понимаете под 64-битной операцией/инструкцией/командой
просто я не вижу здесь
QApplication a(argc, argv); 0x0000000000402d84 push %rbp 0x0000000000402d85 mov %rsp,%rbp 0x0000000000402d88 push %r12 0x0000000000402d8a push %rbx 0x0000000000402d8b sub $0x50,%rsp 0x0000000000402d8f mov %edi,-0x54(%rbp) 0x0000000000402d92 mov %rsi,-0x60(%rbp) MainWindow w; 0x0000000000402d96 mov -0x60(%rbp),%rdx 0x0000000000402d9a lea -0x54(%rbp),%rbx 0x0000000000402d9e lea -0x20(%rbp),%rax 0x0000000000402da2 mov $0x40600,%ecx 0x0000000000402da7 mov %rbx,%rsi 0x0000000000402daa mov %rax,%rdi 0x0000000000402dad callq 0x402848 <_ZN12QApplicationC1ERiPPci@plt> w.show(); 0x0000000000402db2 lea -0x50(%rbp),%rax 0x0000000000402db6 mov $0x0,%esi 0x0000000000402dbb mov %rax,%rdi 0x0000000000402dbe callq 0x402f08 <MainWindow> return a.exec(); 0x0000000000402dc3 lea -0x50(%rbp),%rax 0x0000000000402dc7 mov %rax,%rdi 0x0000000000402dca callq 0x402e34 <_ZN7QWidget4showEv>никаких 32-битных команд, операндов, адресов.
Это подпись, которую невозможно истолковать неправильно
Цитата: она может "жрать"
Напоминает эпизоды из "Понедельник начинается в субботу" Стругацких, когда Выбегалло создавал своих кадавров. :D
Прямо "модель идеального человека" :)
"У него же потребности!.. У него же они растут!.. Мои труды читать надо!"
"Потребности должны идти у нас как вглубь, так и вширь. Это, значить, будет единственно верный процесс." (с) проф. Выбегалло А. А.
хорошие цитаты, вы молодец,
хорошие цитаты, вы молодец, что много читаете ;) однозначно!
я всего лишь намекал на то, что 32 бита адресуют теоретически 4 гига памяти, а в реале получается 3 гига... (к стати буду благодарен, если кто-то напомнит почему ;) ) , а 64 бита сколько там терабайт? =)
лично у меня 8 гигов памяти, и i686 работало на них медленнее, даже если и видело всю память... заметил просто:
1. кодирование HD фильмов с одними и теми же параметрами дает вдвое больший прирост на системе amd64 по сравнению с x86 (при умолчальных параметрах компиляции mplayer/mecoder и с одним и тем же видеопотоком)
2. на amd64 я могу смотреть 1080i, а на x86 почему-то нет. 1080р и там и там воспроизводится прекрасно (vdpau не задействовано)
3. мною разрабатываемая программа, которая (если по простому) строит полином 5-й степени из массива данных в 700-800 тысяч элементов (x;y), собраная с -n64, выполняется существенно быстрее чем с -n32 (система amd64, т.ч. возможно конечно что по этому, ведь в идеале надо сравнивать -n32 на системе x86)
в общем, для меня это все решило ;)
Theli написал(а): я всего
Насколько я помню, дело в том, что процессор всего может адресовать 4 Гб, а не только оперативки. Это и видеопамять, и раздел подкачки, наверное, и прочая.
Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.
Основа верна, но...
Основа верна, но раздел подкачки не при чем.
Лимит в 3Gb не жесткий. Реально он формируется из:
1) областей памяти, выделяемых устройствами (тут-то как раз видео и прочие контроллеры)
2) областей памяти ring0 (собственно ядро и драйверы работающие в ring0, расходы на dma, bios)
Например, если в системе будет установлена, видеокарта с 2Gb RAM, то лимит доступной пользователю ОЗУ упадет ниже 2GB
По сути сумма объемов физической памяти всех устройств в системе не может превышать 4Gb, ибо процессор не сможет адресовать память за пределами 2^32 = 4Gb
Ну, а технология PAE (Physical Adres Extention), появилась довольно таки давно. Еще в Pentium Pro.
Благодаря ей процессор может адресовать 2^36 байт = 64Gb. При этом каждая задача всё равно лимитирована 32-битными сегментами -- соответствено 32-битной адресацией (4Gb)
emacs — отличная операционка которой не хватает только хорошего текстового редактора.