x86 vs amd64 (AMD Athlon 64)

[Gogast]

i386 уже нет, как и x86_64

http://kerneltrap.org/Linux/Removing_the_i..._64_Directories

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

[wyldrodney]

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

64 бита, 64... да 64, а в каком количестве...
Твой проц(Athlon 64/EM64T) это обычный 32-разрядный проц, в него добавили несколько регистров, вмещающих 64 бита данных, плюс он в теории может адресовать больше памяти. На практике это позволяет лишь быстрее(по сравнению с 32-разрядным процом) выполнять изначально 64 битный код, а не тот, который компилятор "заставил" содержаться в 64-битных регистрах, остальной код, по причине "занятости" 64-битных регистров, будет суваться в 32-битные регистры... раздели 64 на 32, и подумай, на сколько тактов проц затратит больше, по сравнению с 32-разрядной системой.

Могу согласиться -- некоторые программы, _ИЗНАЧАЛЬНО_ написанные для 64-разядных систем, или правильно использующие такие большие регистры, имеют значительное преимущество в скорости, но таких программ _МАЛО_ : Maya... а больше незнаю, хотя слышал что есть.

[serzh-z]

надо использовать возможности проца на максимум...

И как, используете?

зачем я тогда 64бита брал...

Может маркетологи напели?..

[oberlicht]

зачем я тогда 64бита брал...

Может маркетологи напели?..

Кто же знал?
Вот я, года три(?) назад услышав в очереди за пивом, о массовом производстве 64-хбитных процессоров, размечтался о "технологическом рывке", примерно таком, как при появлении 386го процессора. Мало того, что тогда регистры стали длиннее и из памяти за раз можно черпать вдвое больше, так ведь еще появился защищенный режим, многозадачность, новая модель памяти..
А "16-тибитными" программами пользутся и по сей день (и даже пишут новые, я знаю одного д.т.н, который ни за что не бросит 6-й ТурбоПаскаль)

В общем, я ожидал чего-то подобного. (:

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

[wyldrodney]

преимущества (какие?) шестидесятичетырехразрядности

Во! Именно, кто-нибудь обьясните мне пожалуйста ети самые преимущества. Никак не пойму _КАКОЙ_СМЫСЛ_ собирать, да, именно СОБИРАТЬ систему "под 64 бита". Буду премногобагодарен

[oberlicht]

Никак не пойму _КАКОЙ_СМЫСЛ_ собирать, да, именно СОБИРАТЬ систему "под 64 бита". Буду премногобагодарен

Смысл именно собирать (имхо) лежит на поверхности: те самые потенциальные возможности 64-х бит (gcc, я так понимаю, что-нибудь лучше оптимизирует с учетом архитектуры, чем для абстрактного i686)
Даже если ничего не оптимизирует, потерь никаких.
Все работает.

А вот чем ставить, например, 64-х битную Слаку, я бы подумал 16 раз..
Потому что мне трудно выбрать, что не нравится больше: ждать пока добрый дядя собирет для меня нужный пакет или собирать самому в системе для этого не приспособленной..

[wyldrodney]

те самые потенциальные возможности 64-х

Постом выше я про них и спросил. Какие!?

Даже если ничего не оптимизирует, потерь никаких.

Четырьмя постами выше мой пост, читал?

И прошу не повторять: "смысл лежит на поверхности...", хотелось-бы услышать аргументы, со ссылкой на устройство процессора(я не имею ввиду вики!).

[oberlicht]

Четырьмя постами выше мой пост, читал?

И прошу не повторять: "смысл лежит на поверхности...", хотелось-бы услышать аргументы, со ссылкой на устройство процессора(я не имею ввиду вики!).

А я в устройстве процессора, пардон муа, ничего не понимаю.
Все, что я знаю, это то, что Athlon 64 не хуже Pentium Pro, а чем-то лучше. Эта моя убежденность основана не на знании конкретных различий, а исключительно на вере в технический прогресс : )
Но кто-то из разработчиков (ядра, glibc, gcc,.. а, может, матлаба и ugs) эти улучшения может использовать.
И я не вижу никаких причин мне этим не пользоваться.
Именно в этом сакральный поверхностный смысл.

А вот, например, производители монитора рекомендуют подключать его через DVI.
У меня есть и видеокарта, и кабель.
Но я не знаю, чем DVI лучше D-SUB, а "визуально" я отличий не увидел.
А какие у меня причины пренебрегать рекомендациями производителя?
Вот я и подключаю через DVI.

Такая примерно логика.

[wyldrodney]

Как вы хитро выкрутились
Логика верна, именно некоторые разработчики эти улучшения используют.
На вашей системе с Гентой некоторые "потенциальные возможности" раскрываются, и менно основа системы glibc, ядро, раскрывают потенциал, так как изначально была некоторая оптимизация кода. Но "жирные" приложения типа КДЕ, QT, будут иметь больший отклик по сравнению с 32 битной системой, за счёт недостаточной скорости работы с памятью. Проверено: стояло 2 компа Athlon 64 4200+/1GB, полностью одинаковых, двое людей, оба 3 дня подрят работали за ними, а потом поменялись на 2 дня, говорили что комп "1" работает быстрее. а он был собран под 32 бита.
И не надо мне говорить что на втором винт дохлюй стоял

[serzh-z]

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

О Святой Патрег,.. ещё одна жертва маркетинга. :-) Прошу прощения, но мне вспомнилась старая сказка про вершки и корешки, которые делили мужик с медведем - очень к месту. :-)

[oberlicht]

Но "жирные" приложения типа КДЕ, QT, будут иметь больший отклик по сравнению с 32 битной системой, за счёт недостаточной скорости работы с памятью.

ой! а расскажите вот про это подробней?
Я так понимаю (дилетански), что процессор с вдвое более широкой шиной данных за раз вдвое больше из памяти черпает. Что, вообще говоря, ведет к ускорению работы с массивами, например
Другое дело, что памяти якобы должно тратиться больше (при выравнивании "скалярных" данных по "границе слова")

Где здесь подвох?

О Святой Патрег,.. ещё одна жертва маркетинга. :-) Прошу прощения, но мне вспомнилась старая сказка про вершки и корешки, которые делили мужик с медведем - очень к месту. :-)

Жертва, и от этого деваться некуда.
Хоть процессоры покупай, хоть ботинки.

Впрочем, когда я выбирал процессор, думал про другие вершки, такие как "два ядра", "двухканальная память", "ddr2"..
Ну, и, понятное дело, число в обозначении процессора должно быть максимальнодлинным :-)

а 64 бита оставлю до тех пор, пока не обнаружится, что оно хуже "i686" (чем?)

[Civil]

http://en.wikipedia.org/wiki/Amd64#Architectural_features - помоему вполне хорошее краткое описание того, что есть AMD64.

[Davinel]

ой! а расскажите вот про это подробней?
Я так понимаю (дилетански), что процессор с вдвое более широкой шиной данных за раз вдвое больше из памяти черпает. Что, вообще говоря, ведет к
ускорению работы с массивами, например
Другое дело, что памяти якобы должно тратиться больше (при выравнивании "скалярных" данных по "границе слова")

Где здесь подвох?

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

а 64 бита оставлю до тех пор, пока не обнаружится, что оно хуже "i686" (чем?)

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

[sspphheerraa]

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

ага, когда 64 гигов оперативы будет мало... тогда просто прийдется перелазить.

[serzh-z]

когда 64 гигов

Ну, скажем, не 64, а 4... :-)

[sspphheerraa]

когда 64 гигов

Ну, скажем, не 64, а 4... :-)

Согласно Вике

In legacy mode, Physical Address Extension (PAE) is supported, as it is on most current 32-bit x86 processors, allowing access to a maximum of 64 gibibytes

[serzh-z]

MAA, вика не врёт, но использование PAE не означает, что процессу будет доступно более 4 Гб (на самом деле ещё меньше) адресов. Это означает, что одним махом распределить более чем 4-х гбайтный буфер и считать в него, скажем, весь образ DVD программа не сможет, даже при наличии огромных объёмов памяти и включённом PAE.

[Shlomo]

У меня уже давно компы только AMD. Был AthlonXP, сейчас 64-бит. Никакой разницы в скорости не заметил. Как основная система стоит Arch i686, на другом разделе Gentoo amd64, работает абсолютно одинаково. Но особенно раньше под amd64 было невозможно запустить многие 32-бит проги, которых нет под 64, правда в Генте это не так заметно, как в других системах.
ЗЫ А не место ли топикуво "флейме"?

[Тушисвет]

Когда-то давно я покупал принципиально Интел, с тех пор ничего не изменилось. Поэтому теперь я до конца света буду сидеть на своем х86, потом (ран или поздно) куплю 64, но тоже Интел, но в ближайшие 5 лет не виду причин что-либо менять.

[nrg]

Когда-то давно я покупал принципиально Интел, с тех пор ничего не изменилось. Поэтому теперь я до конца света буду сидеть на своем х86, потом (ран или поздно) куплю 64, но тоже Интел, но в ближайшие 5 лет не виду причин что-либо менять.

Ранее был интел ещё во времена П4-1600, потом взял ноут на Турионе X2 TL52, а потом и домашнюю машину грейднул на Семпрон3к АМ2 с учётом на будущий апгерйд на Атлон Х2. Не жалуюсь А выгоды брать для ноута корадуу с ценой от 30к за более-менее нормальную конфу я не хочу, ибо вне зависимости от проца другие части бука проседают (винты, видяхи и проч.) и им часто просто не нужен такой проц. Ноуту уже полгода .... проблем с производительностью ни разу не видел.... хотя машинка используется для довольно сложной местами математики, попутно работает ДНС и НАТ сервером для домашней сетки

Архитектура, кстати x64, поэтому по поводу связки математика + 64 битный проц советую ознакомиться вот с этим: http://gmplib.org/32vs64.html
Вот цитата оттуда

If we instead would compare an Athlon XP and an Athlon 64, the latter would be almost 4 times faster. Why 4 times and not just 2 times? Because a 64x64=>128 bit integer multiplication actually performs 4 times more work than a 32x32=>64 bit integer multiplication!

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

[VladimirP]

настоящие 64-х битные приложения показывают существенный прирост производительности.. но таких к сожалению мало.

Вот это я не понял. Мы здесь обсуждаем Gentoo, в котором программы в основном компилируются на месте. Значит, можно установить 64-битный режим компиляции. Объясните, как может быть мало родных 64-битных приложений.

[serzh-z]

компилируются на месте

Представим гипопетическую ситуацию?

Допустим есть 32-х разрядное приложение, которое использует битовый массив размеров в, скажем, 256 бит. Поскольку разработчики исходили из предположения, что их приложение будет компилироваться на процессоре с целым типом максимальной длины в 32 бита. Соответственно, для представления 256-битного массива, они использовали 8 переменных long. Вся логика программы была построена на том, что один компонент этого массива будет вмещать всего 32 бита (не будем брать пример, в котором разработчики реализуют более сложную логику без предположения о размере long)...

Далее, что будет при пересборке этой программы на 64-х разрядной системе: (допустим что на какую-то конкретную операцию с одним компонентом массива, тратится N тактов процессора) вместо того, чтобы сократить количество частей массива до 4 и тратить на это меньше времени, процессор будет тратить столько же, это при том, что потребление памяти будет в два раза больше (просто по четыре байта в каждой переменной не будут использоваться). Что-то типа того...

[Andrew S]

Судя во вике (да и в Компьютерре я раньше об этом же читал): "Additional registers: In addition to increasing the size of the general-purpose registers, the number of named general-purpose registers is increased from eight (i.e. eax,ebx,ecx,edx,ebp,esp,esi,edi) in x86-32 to 16. It is therefore possible to keep more local variables in registers rather than on the stack, and to let registers hold frequently accessed constants; arguments for small and fast subroutines may also be passed in registers to a greater extent."
То есть в коде для 64-битной системы будет меньше пересылок между регистрами и памятью. А длина регистров действительно влияет только на работу с 64-разрядным целым типом.

[serzh-z]

То есть в коде для 64-битной системы будет меньше пересылок между регистрами и памятью.

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

[_YT_]

Купите себе памяти 4 Гб или больше, вот и поймете, зачем amd64 нужна.
Это как плюс (поддержка большого количества памяти),
ну а как минус — часть пакетов только под x86, но эмуляцию x86 на amd64 никто не отменял.

Одним словом на amd64 отлично живется.

[DZhon]

Купите себе памяти 4 Гб или больше, вот и поймете, зачем amd64 нужна.

32-х битное ядро Linux поддерживает до 64 Гб памяти (кажись, "PAE" называется, могу ошибаться)

[rm_]

http://rm.pp.ru/dl/amd64vsi386/html/
О чём разговор вообще?

[Gogast]

вообщето выигрыш значительный... его нестоит приуменьшать
надо ставить нормальную march опцию

[serzh-z]

32-х битное ядро Linux поддерживает до 64 Гб памяти (кажись, "PAE" называется, могу ошибаться)

На колу висит мочало, начинаем всё сначала, ага? В этой же теме выше это уже обсуждалось. PAE не поможет приложениям адресовать больше 4 Гб памяти на 32-х разрядной платформе.

вообщето выигрыш значительный... его нестоит приуменьшать
надо ставить нормальную march опцию

Голословные заявления, аргументы и факты, плз. И ещё "нормальную опцию march" можно увидеть?

По ссылке выше приведены какие-то фантастические цифры... Куда реалистичнее выглядит http://www.mwales.net/Software/LinuxVsWind...vs_Windows.html

[Gogast]

тогда компилятор был древний... кстати заявление о голословности - тоже голословное