В статье "AMD Phenom 32-bit vs. 64-bit Performance (http://www.phoronix.com/scan.php?page=article&item=998&num=1)" проведена оценка производительности в 32 и 64-разрядной (x86_64) сборки Ubuntu Linux 8.04 alfa, на машине с 4-x ядерным процессором AMD Phenom. В 4 из 5 игровых тестов победила 32-разрядная сборка. При тестировании скорости кодирования mp3 и сжатия данных, перевес был на стороне 64-разрядной сборки.URL: http://www.phoronix.com/scan.php?page=article&item=998&num=1
Новость: http://www.opennet.me/opennews/art.shtml?num=14156
- ... ну и что это значит, Сэр!?
- Ничего, Сэр!все равно уйдут на 64-бита, даже если это медленнее ... да собственно уже ушли ,)
>- ... ну и что это значит, Сэр!?
>- Ничего, Сэр!
>
>все равно уйдут на 64-бита, даже если это медленнее ... да собственно
>уже ушли ,)Только не бери Феном - потерпи до Opteron 4-x цилиндрового.
Аналогичные феномы не отличаются от оптеронов ничем, кроме как возможностью работать в многопроцессорных конфигурациях.
Ну имелось ввиду что ядро Barcelona отличает от Agena возможность работать в многопроцессорных системах. Аналогичные, чтоб не говорили, что феномы и 3х ядерные будут..
>- ... ну и что это значит, Сэр!?
>- Ничего, Сэр!
>
>все равно уйдут на 64-бита, даже если это медленнее ... да собственно
>уже ушли ,)кто - все? у всех моих знакомых 32 бита, только у меня - 64...
Я даже не смотря на бенчмарки, если они там есть, скажу... 32-bit быстрее!А почему?!
Да потому, что gcc -m64 это не есть 64-bit_ное приложение. Это есть 64-битные регистры данных
программ. Препроцессор, пока, увы, алгоритмы не переделывает.
64-bit_ное должно быть мышление и алгоритмы
построенные на использовании 64 бит.Так что Кнут и спецификация по AMD64 и EMT64 вам в помощь.
Это ваше мнение. Ему надо обоснование.
Я считаю, и свое мнение навязывать никому не стану, основанно на простом тесте.
Я тестил две винды на одной и той же машине. Так вот 64бита винда работала на 10% быстрее вчем 32бита, но только в тесте АЛУ.
Так что мышление и алгоритмы тут ни причем. Я считаю это высокими словами, и не более.
А вот не используемые 64 битные регистры - это конечно не умение программировать.
И пока разработают среды разработки, и пока перепишут функции, а в программах будут писать код с анализом битности платформы - вот тогда и надо сравнивать.
И еще - один взгляд назад :-) как говаривал Никольский.
Никто не спорит что 32битные проги быстреей чем 16битные %-)
Вот собсно гря мое мнение.
>[оверквотинг удален]
>Так что мышление и алгоритмы тут ни причем. Я считаю это высокими
>словами, и не более.
>А вот не используемые 64 битные регистры - это конечно не умение
>программировать.
>И пока разработают среды разработки, и пока перепишут функции, а в программах
>будут писать код с анализом битности платформы - вот тогда и
>надо сравнивать.
>И еще - один взгляд назад :-) как говаривал Никольский.
>Никто не спорит что 32битные проги быстреей чем 16битные %-)
>Вот собсно гря мое мнение.Мнение было совершенно верным - не использую 64-х разрядные слова в приложении никакой выгоды от использования 64х битной архитектуры получить нельзя. Как правило наибольшую выгоду можно заметить на переписанных математических приложениях, где сильно заметно когда за такт обрабатывается 64 бита данных, а не 32.
Что касается ваших тестов - если вы скажите версию ОС я скорее всего смогу объяснить вам причину результата.
Никакого анализа битности быть не может - приложение либо 32х либо 64х битное - по другому не бывает.
Про мышление - вы хотите сказать что вам всё равно - сколько данных у вас в одном машине слове - 32 бита или 64? Это никак по-вашему не влияет на алгоритмизацию?
>Мнение было совершенно верным - не использую 64-х разрядные слова в приложении никакой >выгоды от использования 64х битной архитектуры получить нельзя.Простите, а как же 8 дополнительных регистров общего назначения? Думаю, что компилятор должен задействовать при сборке программы, и производительность тут может вырости.
http://en.wikipedia.org/wiki/X86-64#AMD64
Во-во, ибо нефиг! 32-битное даже запускается быстрее, не говоря уже и о стабильности...
>Во-во, ибо нефиг! 32-битное даже запускается быстрее, не говоря уже и о
>стабильности...Стабильность достигается путём исправления ошибок в коде - не имеет никакого значения битность, хоть 64, хоть 128...
Если бы 32х битные приложения запускались медленнее - я бы сильно удивился - вы их размер не пробовали сравнивать? :)
>Во-во, ибо нефиг! 32-битное даже запускается быстрее, не говоря уже и о
>стабильности...Говороя о стабильности можно вспомнить про nx-бит в amd64...
Ну и бред.
Во-первых, в игрушках FPS на 64bit меньше на 10-20%, что в пределах погрешности. А в Quake4 FPS на 64bit в 2 раза больше.
Во-вторых, нигде не написано, использовали ли они на 64bit оси 64bit игрушки. И даже если так, неизвестно как они собраны. Сдается мне, не все у проприетарщины чисто, а опенсорс собранный под конкретную архитектуру, разумеется, работает на ура. Сравнили бы, скажем, sauerbraten и quake3.
В общем, 32 бита уже гниют на свалке.
>В общем, 32 бита уже гниют на свалке.Аргументированно... особенно смешно про "10-20%, что в пределах погрешности":)
Погрешность слишком велика, вы не находите?>а опенсорс собранный под конкретную архитектуру, разумеется, работает на ура.
Что означает "ура"? Ну не может оно быстрей работать, хоть -msse3 подставляй.
Пока ВЕСЬ код не перепишут под "конкретную архитектуру" оно быстрей работать не станет!
Могу согласиться, что gcc даёт хорошую прибавку скорости, но в "пределах погрешности" -- 5-10%. Не больше. В виде исключения можно рассмотреть аудио/видеодекодеры, но там сплошная математика! И несколько 64-битных регистров архитектуры x86_64 делают своё дело: вычисления проходят несколько быстрее(60-80% -- наиболее часто встречающиеся цифры).
>>В общем, 32 бита уже гниют на свалке.
>Аргументированно...А то.Они тупо не адресуют имеющиеся 5Gb RAM :P
>Что означает "ура"? Ну не может оно быстрей работать, хоть -msse3 подставляй.
>Пока ВЕСЬ код не перепишут под "конкретную архитектуру" оно быстрей работать не
>станет!Некоторые переменные нативно 64-битные.Скажем доступ к файлам >4Gb.У некоторых ФС нативный размер элементов 64 бита.Некоторые алгоритмы просто хорошо ложатся на 64 бита, скажем некоторые алгоримты хеширования.Они сами по себе выиграют за счет наличия энного числа регистров на 64 бита.Тупо и в лоб.
Имхо, наиболее производителен тот процессор, на который тебе хватает денег без особого ущерба для семьи.
Господа, не стоит разжигать религиозных воин.
Рано или поздно все перейдут под 64, как когда-то перешли от 16 к 32-разрядным машинам.
Со временем будет написаны и актуальные приложения. Да, пока таковых мало. Но жизнь не стоит на месте.
Выбор конечно у каждого свой, но и затягивать с переходом не стоит. Тем более, что Вы ничего не теряете (обратная совместимость).
Обратная совместимость есть, и работает хорошо. Но издержек тоже не мало. Если запускать пару приложений (firefox-32 + flash-32) в производительности не сильно заметно, а вот дополнительный набор 32-битных либ ест памяти не мало. А всю систему собранную под 32 на 64-битном ядре не погоняешь (слишком большой оверхед).
Хотя список софта портящего жизнь отсутствием 64-битной версии не так много. Главные - это adobe flash и adobe acroread - ну не свавнимо с другими pdf-просмотрщиками. 2 раза "adobe"
настучать бы им по голове.
Девелоперам вот задумывающимся о будущем деваться не куда. 64-битное ядро с поддержкой 32 просто не заменимо.
Проблема состоит в том, что драйверы для видеокарт ATI в 64-битном пространстве работают через эмуляцию 32-битного пространства. Именно поэтому только в играх отставание.
>Проблема состоит в том, что драйверы для видеокарт ATI в 64-битном пространстве
>работают через эмуляцию 32-битного пространства. Именно поэтому только в играх отставание.
>Сдаётся, что именно в этом и причина. Сравнивать в играх можно только скорость видеокарт и их драйверов, что и произошло. Неясно, почему не установлена видеокарта nVidia (у них дрова заведомо лучше) хотя бы для сравнения и удаления погрешности связанной с конкретным производителем. Короче полный непрофессионализм и некомпетентность при тестировании.
на мой взгляд 64 бита это не роскош, а необходимость когда речь заходит что даже в домашних компьютерах, память приближается за границы 4Гб, а после 4Гб как известно работать в 32-х битах очень не комфортно, потому как начинается более сложная адресация памяти
так что не важно будет оно работать быстрее или медленнее (на мой взгляд памяти в любом случае будет жрать больеш :-) ) все равно дорога только туда, а не обратно.
>на мой взгляд 64 бита это не роскош, а необходимость когда речь
>заходит что даже в домашних компьютерах, память приближается за границы 4Гб,
>а после 4Гб как известно работать в 32-х битах очень не
>комфортно, потому как начинается более сложная адресация памяти
>так что не важно будет оно работать быстрее или медленнее (на мой
>взгляд памяти в любом случае будет жрать больеш :-) ) все
>равно дорога только туда, а не обратно.Вообще-то она после 4 Гб не более сложная, а просто другая, и давно уже аппаратно поддерживаемая (начиная со 2-го пня где-то). Другое дело что в ширпотребных версиях Windows (Pro/XP/Vista) программистам было лень нормально это всё реализовывать. В стандартных 32х битных сборках Линукса то же, но там по крайней мере можно пересобрать ядро (насколько я помню PAE в Линуксе всё-таки поддерживается). Весь вопрос - а когда проходит граница между "можно и на 32х" и "нужно уже 64".
>Вообще-то она после 4 Гб не более сложная, а просто другая, и давно уже аппаратно >поддерживаемая (начиная со 2-го пня где-то).PAE - костыль. Линейное адресное пространство всеравно не расширяется.
>>Вообще-то она после 4 Гб не более сложная, а просто другая, и давно уже аппаратно >поддерживаемая (начиная со 2-го пня где-то).
>
>PAE - костыль. Линейное адресное пространство всеравно не расширяется.Не знаю, что вы имели ввиду под "линейным адресным пространством" но при наличие 36 аппаратных линий а шине адреса (что и есть PAE) по-моему там всё весьма тривиально, вопрос в софте. В всяком случае у меня в 2003-м это пашет и не кашляет.....
Имел ввиду, что процесс в ОС не сможет использовать памяти более чем 4ГБ. Вот что по повоуд PAE сказано в книге Understanding The Linux Kernel:
"However, the main problem with PAE is that linear addresses are still 32 bits long. This forces kernel programmers to reuse the same linear addresses to map different areas of RAM...
Clearly, PAE does not enlarge the linear address space of a process, because it deals only with physical addresses. Furthermore, only the kernel can modify the page tables of the processes, thus a process running in User Mode cannot use a physical address space larger than 4 GB. On the other hand, PAE allows the kernel to exploit up to 64 GB of RAM, and thus to increase significantly the number of processes in the system.":)
то есть пока одно пользовательское приложение не сожрёт 4 гига проблем не будет?
Похоже на то.
>[оверквотинг удален]
>linear addresses to map different areas of RAM...
>Clearly, PAE does not enlarge the linear address space of a process,
>because it deals only with physical addresses. Furthermore, only the kernel
>can modify the page tables of the processes, thus a process
>running in User Mode cannot use a physical address space larger
>than 4 GB. On the other hand, PAE allows the kernel
>to exploit up to 64 GB of RAM, and thus to
>increase significantly the number of processes in the system."
>
>:)Не совсем понял к чему вы цитату привели - то что я сказал не противоречит тому что там написано, за исключением того заблуждения, что 32х разрядный указатель не может адресоваться более чем к 4 Гб памяти :) - может. Кстати больше 4 гиг на процесс в 32х ОС использовать можно, правда не совсем напрямую конечно.
Привел, чтоб не быть голословным.>Кстати больше 4 гиг на процесс в 32х ОС использовать можно, правда не совсем напрямую конечно.
Каким образом?
По теме - http://www.thg.ru/software/windows_vista_8_gb/index.html
Отжиг:
"Если же вы отключите файл подкачки при установленных 512 Мбайт памяти, то вы не сможете открывать даже мелкие приложения Windows, такие как "Блокнот". Да и через некоторое время система сама "вылетает", даже если вы не будете ничего делать."Ай да Виста, ай да молодца...
>Отжиг:
>"Если же вы отключите файл подкачки при установленных 512 Мбайт памяти, то
>вы не сможете открывать даже мелкие приложения Windows, такие как "Блокнот".
>Да и через некоторое время система сама "вылетает", даже если вы
>не будете ничего делать."
>
>Ай да Виста, ай да молодца...Винда никогда не умела по-человечески без свопа работать
Мне в Убунте больше всего не нравится то, что они не собирают дистрибутивы для i686. Неприятно терять в производительности.
Можно подумать, что у кого-то еще стоит процессор с логикой i386 и количество оперативы, необходимое для нормальной работы Убунты (256 как минимум)
убунта собирается по своей философии, почитав ее просто в справке, можно понять почему они делают ее для 368х процев