[amd64]Вопрос к практикам

1. Да, готовы.

2. Для меня лично смысла нет

2. В два раза больше в два раза больших РОНов. Отсюда профит.

Пользуюсь уже несколько лет. Из проприетарного: опера, виртуалбокс и ничего-не-поделаешь-флеш. Что там у кого собрано - не знаю, ибо гента.

оно быстрее работает, да.

Ах, да, использую debian, если что.

Думаю что так напрягает в этой теме.. оказывается сейчас слушаю M. Jackson - Dirty Diana :)

Сижу второй год на amd64, проблем с софтом не имею, скорость немного выше в среднем, чем на i386.

Да, скорость выше. Но! Если у тебя, скажем, 2 ГБ памяти, то имеет смысл оставаться на 32 битах. На генте 64 битной мультилибной я горя не знаю, то, чего не существует под amd64, ставится 32 битное. Если же тебе надо pure 64 бит, то изучи вопрос более тщательно.

1.да готовы
2.имхо скорость работы выше

> Первый - достаточно ли готовы современные дистрибутивы на этой платформе?

достаточно

> То флеш не работает, то какой-то проприетарный софт не собран под amd64

флеш работает, проприетарный софт, собранный под 32 бита тоже.

> И второй вопрос - а какой в этом смысл?

Памяти больше можно, работает быстрее, особенно числодробильня.

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

Юзай нормальные дистры. И будет "всё как у меня" (ц). Например гента без мультилиба.

ну не знаю. может вопсче на 16бит все откатить?

Для меня смысл - в быстрой загрузке Ос.

Смысл есть, хотя бы из-за более прямого управления памятью в 64-битной системе даже при меньше, чем 4Гб. Кроме того, это субъективное ощущение, но мне кажется, что система на amd64 работает в целом стабильнее. Ну и если ставить 4 и более Гб памяти - тут точно без вариантов.

Помню, использовал на машине с amd64 Debian точно так же, как и на 32 битах. Мне, правда, не нужен был Flash. Мне не нужен был и проприетарный софт. Я вообще не заметил разницы.

Сетевое ПО, знаете, оно такое, что процессор — не последняя вещь, от которой оно тормозит, там больше завязка на ввод-вывод.

1. Да 2. Для себя не вижу смысла. Видео я не кодирую (единственное пожалуй место, где помогает большее число архитектурно видимых регистров), работа же 8Gb RAM нормально обеспечивается PAE.

Первый раз вижу внятное, короткое и ёмкое определение, спасибо!

А вот был бы FatELF, таких вопросов не возникало бы. :)

>Первый - достаточно ли готовы современные дистрибутивы на этой платформе?
Пользуюсь год арчем, никогда не возникало проблем, разве что с флешем, который через жопу приходилось запускать, и то сейчас он стал нативным.

>И второй вопрос - а какой в этом смысл
Если не видишь смысла, то тебе и не надо видимо?

>А вот был бы FatELF, таких вопросов не возникало бы. :)
Убейся. Есть машины с ppc, есть c arm, есть c alpha. Линукс работает везде. И что? Жирный эльф только лишнего хаоса привнесет.

1) Mandriva гоняет на ура, флэш 64битный робит отлично, да и и вообще косяко в редакции 2009.1 мало.

2)64бита + виртуалки = профит ням-ням. летает система превосходно.

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

> В два раза больше в два раза больших РОНов. Отсюда профит.

В два раза шире указатели и переменные типа long, поэтому больше кеш-промахов (кеши-то не резиновые). Отсюда лосс.

Кстати, количество РОНов не проблема за счет переименования регистров.

бггг

тэг [анабиоз] где?

использую pure 64bit gentoo уже давно. проприетарщина мне не нужна. ютюб смотрю с помощью swfdec (плагина swfdec-mozilla). Icedtea6 вместо сановской явы. Даль виртуалбокс очень сильно захотел собрать32х битные либы. Поставил kvm.

>Кстати, количество РОНов не проблема за счет переименования регистров.

Какого такого переименования?

1. java + фотонанизм = требования к памяти

Работаю с 2007 года. Система Gentoo. Чистый 64bit режим.

Всё нормально.

Отсутствуют только несколько приложений --- это Google earth, skype, adobe reader (прекрасно заменяется kde okular).

Ходят слухи, что wine не работает, но я не проверял, так как он мне не нужен.

Некоторые проблемы с виртуальными машинами, всё остальное работает на ура.

Я, правда настойчиво пытаюсь вытравить симлинк lib64, но пока он побеждает.

>Первый - достаточно ли готовы современные дистрибутивы на этой платформе?

Давно уже

>То флеш не работает

Линупс первый получил 64-битный флеш, а раньше были различные врапперы для 32-битных плагинов, которые в популярных дистрах работали из коробки.

>какой-то проприетарный софт не собран под amd64

Библиотеки совместимости никто не отменял

>И второй вопрос - а какой в этом смысл? :)

Смысла не больше, чем в установке 32-битного дистра на 64-битную систему

>Памяти больше можно, работает быстрее, особенно числодробильня.

Тут на ЛОР постоянно доказывают, что работает медленнее, особенно числодробильня, из-за более тормозной работы с памятью. ХЗ что там не так

>Ходят слухи, что wine не работает

С 32-битными либами — работает.

Тут на ЛОР постоянно доказывают, что работает медленнее, особенно числодробильня, из-за более тормозной работы с памятью

Тесты им противоречат. :)

> но всегда нахожу какие-то проблемы?

Флэш, nvidia, java plugin уже имеются родные 64 бит. Год работаю под amd64. Вполне можно использовать для десктопа.

Есть еще некоторые программы, работающие только под 32 бит, но мне они не нужны. Так что, в принципе, можно было бы мою систему перевести на amd64 nomultilib.

http://tuxnotes.ru/reviews.php?a_id=13

Спасибо всем за обсуждение.

3GB RAM, доставлял до 8 - нет смысла. юзай x86, ext4 вырулит скорость у любого х64

1. все ок.
2. субъективно, на глаз - быстрее система шуршит. замеров не производил, ибо лень.

ext4 не работает на AMD64? Какой ужас!

Не знаю почему, но 64-битная гента (no-multilib) работала у меня ощутимо медленнее, чем 32-битная. В обоих случаях собирал с -O3 и флагами под процессор.

> ext4 не работает на AMD64?

и давно? О_О

denis@laptop:~$ uname -a
Linux laptop 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:05:01 UTC 2009 x86_64 GNU/Linux
denis@laptop:~$ mount |grep ext4
/dev/sda3 on / type ext4 (rw,relatime,errors=remount-ro)

уже полгода как все живо и здорово.

Кстати, количество РОНов не проблема за счет переименования регистров.

Какого такого переименования?

Вот тут хорошо объясняется: http://en.wikipedia.org/wiki/Register_renaming

Вкратце, РОНов у процессора на самом деле гораздо больше, чем доступно программисту. Их массив называется регистровым файлом. Процессор анализирует зависимости по данным между инструкциям и переименовывает регистры, чтобы исполнительные блоки могли обрабатывать инструкции, использующие эти регистры, параллельно.

Например:

// Блок 1
movl (%ebx), %eax
addl $0x100, %eax
movl %eax, (%ebx)
// Блок 2
movl 4(%ebx), %eax
addl $0x200, %eax
movl %eax, 4(%ebx)

Очевидно, процессор не может выполнить параллельно блок 1 и 2 потому что они оба используют регистр eax. Однако между ними нет зависимости по данным, поэтому процессор выделяет из своего регистрового файла регистр, пусть он будет называться r50, и заменяет eax на него, после чего код выглядит уже так:

// Блок 1
movl (%ebx), %eax
addl $0x100, %eax
movl %eax, (%ebx)
// Блок 2
movl 4(%ebx), %r50
addl $0x200, %r50
movl %r50, 4(%ebx)

Этот код делает то же самое, но теперь оба блока никак не пересекаются друг с другом и их можно выполнить параллельно. Каков размер регистрового файла неизвестно, но я слышал, что у Pentium 4 в нем было 128 регистров. ЕМНИП эта техника появилась в х86 еще лет 15 назад, вместе с ОоО. Но во многих до сих пор живет миф о нехватке регистров. :)

Тебя приглючило. Профиль нон-мультилиб влияет в основном на тулчейн, остальной софт от этого не меняется. У меня и там и там скорость работы была одинакова. Подозреваю, что дело в:
> O3
ССЗБ?

1. Готовы (благо недавно вышел 64-битный флэш) 2. Быстрее. Тот же флэш (недавно совершенно пересел с 32-битной). Да, пожалуй один только 64-битный флэш доставляет.

Какие буйные фантазии :))
1.Вкратце, если у вас совсем туго с аглицким и пониманием работы CPU - там есть по вашей же ссылке краткое описание этого на русском.
Скорее всего , gcc по барабану подобные аппаратные трюки .

2. Что подобный механизм ссылок на регистры может задействован и на 64-х битной архитектуре - конспирологам-манипуляторам представить подобное просто нереально :)))

Субъективно работает быстрей. Проблем с софтом за 4 года использования не наблюдал.

> Скорее всего , gcc по барабану подобные аппаратные трюки .

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

> Что подобный механизм ссылок на регистры может задействован и на 64-х битной архитектуре - конспирологам-манипуляторам представить подобное просто нереально :)))

Если вы не поняли, то мы о технологии переименования говорили. Естественно, она работает и в 64-битном режиме.

>Если вы не поняли, то мы о технологии переименования говорили. Естественно, она работает и в 64-битном режиме.

Это вы использовали как некий аргумент тут в пользу i386 - если вы не поняли:))
Типа : а в российских машинах зато круглые колеса - да, это обескураживает и не более :)))
Чуть ранее, кто-то там пытался прикрытся ext4 на i386 - мол, там она круто пашет и amd64 не надо :))

>>Если вы не поняли, то мы о технологии переименования говорили. Естественно, она работает и в 64-битном режиме.

>Это вы использовали как некий аргумент тут в пользу i386 - если вы не поняли:))

Это ни в коем случае не аргумент в пользу какой-либо архитектуры. Я просто рассказал про технологию и объяснил, что количество архитектурных регистров особой роли не играет.

Домашняя система у меня 64-битная, кстати.

> что количество архитектурных регистров особой роли не играет.

Феноменально :))
Может и 2-х должно хватать ? ^_^
И да, вы еще забыли про двойное ALU - тут тоже можно хорошо мозги запудрить ламерам ...:))

> Тебя приглючило
Возможно.

>> O3
>ССЗБ?
Никогда не задумывался. На x86 работает. Слышал только, что O3 может вызывать баги. А вот замедление - хз.