The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Оценка производительности 32 и 64-разрядной сборки Ubuntu Linux

11.02.2008 22:40

В статье "AMD Phenom 32-bit vs. 64-bit Performance" проведена оценка производительности в 32 и 64-разрядной (x86_64) сборки Ubuntu Linux 8.04 alfa, на машине с 4-x ядерным процессором AMD Phenom. В 4 из 5 игровых тестов победила 32-разрядная сборка. При тестировании скорости кодирования mp3 и сжатия данных, перевес был на стороне 64-разрядной сборки.

  1. Главная ссылка к новости (http://www.phoronix.com/scan.p...)
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/14156-benchmark
Ключевые слова: benchmark, linux, ubuntu
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (34) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 00:51, 12/02/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    - ... ну и что это значит, Сэр!?
    - Ничего, Сэр!

    все равно уйдут на 64-бита, даже если это медленнее ... да собственно уже ушли ,)

     
     
  • 2.3, pavlinux (ok), 01:38, 12/02/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >- ... ну и что это значит, Сэр!?
    >- Ничего, Сэр!
    >
    >все равно уйдут на 64-бита, даже если это медленнее ... да собственно
    >уже ушли ,)

    Только не бери Феном - потерпи до Opteron 4-x цилиндрового.

     
     
  • 3.19, Аноним (-), 16:07, 12/02/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Аналогичные феномы не отличаются от оптеронов ничем, кроме как возможностью работать в многопроцессорных конфигурациях.
     
     
     
    Часть нити удалена модератором

  • 5.27, Аноним (-), 18:28, 12/02/2008 [ответить]  
  • +/
    Ну имелось ввиду что ядро Barcelona отличает от Agena возможность работать в многопроцессорных системах. Аналогичные, чтоб не говорили, что феномы и 3х ядерные будут..
     
  • 2.35, Аноним (-), 22:35, 28/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >- ... ну и что это значит, Сэр!?
    >- Ничего, Сэр!
    >
    >все равно уйдут на 64-бита, даже если это медленнее ... да собственно
    >уже ушли ,)

    кто - все? у всех моих знакомых 32 бита, только у меня - 64...

     

  • 1.2, pavlinux (ok), 01:33, 12/02/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Я даже не смотря на бенчмарки, если они там есть, скажу... 32-bit быстрее!

    А почему?!
    Да потому, что gcc -m64 это не есть 64-bit_ное приложение. Это есть 64-битные регистры данных
    программ. Препроцессор, пока, увы, алгоритмы не переделывает.
      64-bit_ное должно быть мышление и алгоритмы
    построенные на использовании 64 бит.

    Так что Кнут и спецификация по AMD64 и EMT64 вам в помощь.

     
     
  • 2.11, DeNIS (?), 10:05, 12/02/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Это ваше мнение. Ему надо обоснование.
    Я считаю, и свое мнение навязывать никому не стану, основанно на простом тесте.
    Я тестил две винды на одной и той же машине. Так вот 64бита винда работала на 10% быстрее вчем 32бита, но только в тесте АЛУ.
    Так что мышление и алгоритмы тут ни причем. Я считаю это высокими словами, и не более.
    А вот не используемые 64 битные регистры - это конечно не умение программировать.
    И пока разработают среды разработки, и пока перепишут функции, а в программах будут писать код с анализом битности платформы - вот тогда и надо сравнивать.
    И еще - один взгляд назад :-) как говаривал Никольский.
    Никто не спорит что 32битные проги быстреей чем 16битные %-)
    Вот собсно гря мое мнение.
     
     
  • 3.15, Konwin (ok), 15:07, 12/02/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    >Так что мышление и алгоритмы тут ни причем. Я считаю это высокими
    >словами, и не более.
    >А вот не используемые 64 битные регистры - это конечно не умение
    >программировать.
    >И пока разработают среды разработки, и пока перепишут функции, а в программах
    >будут писать код с анализом битности платформы - вот тогда и
    >надо сравнивать.
    >И еще - один взгляд назад :-) как говаривал Никольский.
    >Никто не спорит что 32битные проги быстреей чем 16битные %-)
    >Вот собсно гря мое мнение.

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

    Что касается ваших тестов - если вы скажите версию ОС я скорее всего смогу объяснить вам причину результата.

    Никакого анализа битности быть не может - приложение либо 32х либо 64х битное - по другому не бывает.

    Про мышление - вы хотите сказать что вам всё равно - сколько данных у вас в одном машине слове - 32 бита или 64? Это никак по-вашему не влияет на алгоритмизацию?


     
     
  • 4.20, Аноним (-), 16:15, 12/02/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Мнение было совершенно верным - не использую 64-х разрядные слова в приложении никакой >выгоды от использования 64х битной архитектуры получить нельзя.

    Простите, а как же 8 дополнительных регистров общего назначения? Думаю, что компилятор должен задействовать при сборке программы, и производительность тут может вырости.
    http://en.wikipedia.org/wiki/X86-64#AMD64

     

  • 1.4, Аноним (1), 03:42, 12/02/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Во-во, ибо нефиг! 32-битное даже запускается быстрее, не говоря уже и о стабильности...
     
     
  • 2.16, Konwin (ok), 15:08, 12/02/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Во-во, ибо нефиг! 32-битное даже запускается быстрее, не говоря уже и о
    >стабильности...

    Стабильность достигается путём исправления ошибок в коде - не имеет никакого значения битность, хоть 64, хоть 128...
    Если бы 32х битные приложения запускались медленнее - я бы сильно удивился - вы их размер не пробовали сравнивать? :)


     
  • 2.21, Аноним (-), 16:17, 12/02/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Во-во, ибо нефиг! 32-битное даже запускается быстрее, не говоря уже и о
    >стабильности...

    Говороя о стабильности можно вспомнить про nx-бит в amd64...

     

  • 1.5, FGL (?), 06:09, 12/02/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ну и бред.
    Во-первых, в игрушках FPS на 64bit меньше на 10-20%, что в пределах погрешности. А в Quake4 FPS на 64bit в 2 раза больше.
    Во-вторых, нигде не написано, использовали ли они на 64bit оси 64bit игрушки. И даже если так, неизвестно как они собраны. Сдается мне, не все у проприетарщины чисто, а опенсорс собранный под конкретную архитектуру, разумеется, работает на ура. Сравнили бы, скажем, sauerbraten и quake3.
    В общем, 32 бита уже гниют на свалке.
     
     
  • 2.6, Аноним (1), 07:36, 12/02/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >В общем, 32 бита уже гниют на свалке.

    Аргументированно... особенно смешно про "10-20%, что в пределах погрешности":)
    Погрешность слишком велика, вы не находите?

    >а опенсорс собранный под конкретную архитектуру, разумеется, работает на ура.

    Что означает "ура"? Ну не может оно быстрей работать, хоть -msse3 подставляй.
    Пока ВЕСЬ код не перепишут под "конкретную архитектуру" оно быстрей работать не станет!
    Могу согласиться, что gcc даёт хорошую прибавку скорости, но в "пределах погрешности" -- 5-10%. Не больше. В виде исключения можно рассмотреть аудио/видеодекодеры, но там сплошная математика! И несколько 64-битных регистров архитектуры x86_64 делают своё дело: вычисления проходят несколько быстрее(60-80% -- наиболее часто встречающиеся цифры).

     
     
  • 3.30, R007 (??), 03:01, 13/02/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >>В общем, 32 бита уже гниют на свалке.
    >Аргументированно...

    А то.Они тупо не адресуют имеющиеся 5Gb RAM :P

    >Что означает "ура"? Ну не может оно быстрей работать, хоть -msse3 подставляй.
    >Пока ВЕСЬ код не перепишут под "конкретную архитектуру" оно быстрей работать не
    >станет!

    Некоторые переменные нативно 64-битные.Скажем доступ к файлам >4Gb.У некоторых ФС нативный размер элементов 64 бита.Некоторые алгоритмы просто хорошо ложатся на 64 бита, скажем некоторые алгоримты хеширования.Они сами по себе выиграют за счет наличия энного числа регистров на 64 бита.Тупо и в лоб.

     

  • 1.7, Ne01eX (??), 07:43, 12/02/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Имхо, наиболее производителен тот процессор, на который тебе хватает денег без особого ущерба для семьи.
     
  • 1.9, WinIT2ch (?), 09:00, 12/02/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Господа, не стоит разжигать религиозных воин.
    Рано или поздно все перейдут под 64, как когда-то перешли от 16 к 32-разрядным машинам.
    Со временем будет написаны и актуальные приложения. Да, пока таковых мало. Но жизнь не стоит на месте.
    Выбор конечно у каждого свой, но и затягивать с переходом не стоит. Тем более, что Вы ничего не теряете (обратная совместимость).
     
     
  • 2.13, Аноним (1), 11:57, 12/02/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Обратная совместимость есть, и работает хорошо. Но издержек тоже не мало. Если запускать пару приложений (firefox-32 + flash-32) в производительности не сильно заметно, а вот дополнительный набор 32-битных либ ест памяти не мало. А всю систему собранную под 32 на 64-битном ядре не погоняешь (слишком большой оверхед).
    Хотя список софта портящего жизнь отсутствием 64-битной версии не так много. Главные - это adobe flash и adobe acroread - ну не свавнимо с другими pdf-просмотрщиками. 2 раза "adobe"
    настучать бы им по голове.
    Девелоперам вот задумывающимся о будущем деваться не куда. 64-битное ядро с поддержкой 32 просто не заменимо.
     

  • 1.10, Аноним (10), 10:00, 12/02/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Проблема состоит в том, что драйверы для видеокарт ATI в 64-битном пространстве работают через эмуляцию 32-битного пространства. Именно поэтому только в играх отставание.
     
     
  • 2.12, SlOPS (??), 11:02, 12/02/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Проблема состоит в том, что драйверы для видеокарт ATI в 64-битном пространстве
    >работают через эмуляцию 32-битного пространства. Именно поэтому только в играх отставание.
    >

    Сдаётся, что именно в этом и причина. Сравнивать в играх можно только скорость видеокарт и их драйверов, что и произошло. Неясно, почему не установлена видеокарта nVidia (у них дрова заведомо лучше) хотя бы для сравнения и удаления погрешности связанной с конкретным производителем. Короче полный непрофессионализм и некомпетентность при тестировании.

     

  • 1.14, Аноним (1), 12:45, 12/02/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    на мой взгляд 64 бита это не роскош, а необходимость когда речь заходит что даже в домашних компьютерах, память приближается за границы 4Гб, а после 4Гб как известно работать в 32-х битах очень не комфортно, потому как начинается более сложная адресация памяти
    так что не важно будет оно работать быстрее или медленнее (на мой взгляд памяти в любом случае будет жрать больеш :-) ) все равно дорога только туда, а не обратно.
     
     
  • 2.17, Konwin (ok), 15:15, 12/02/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >на мой взгляд 64 бита это не роскош, а необходимость когда речь
    >заходит что даже в домашних компьютерах, память приближается за границы 4Гб,
    >а после 4Гб как известно работать в 32-х битах очень не
    >комфортно, потому как начинается более сложная адресация памяти
    >так что не важно будет оно работать быстрее или медленнее (на мой
    >взгляд памяти в любом случае будет жрать больеш :-) ) все
    >равно дорога только туда, а не обратно.

    Вообще-то она после 4 Гб не более сложная, а просто другая, и давно уже аппаратно поддерживаемая (начиная со 2-го пня где-то). Другое дело что в ширпотребных версиях Windows (Pro/XP/Vista) программистам было лень нормально это всё реализовывать. В стандартных 32х битных сборках Линукса то же, но там по крайней мере можно пересобрать ядро (насколько я помню PAE в Линуксе всё-таки поддерживается). Весь вопрос - а когда проходит граница между "можно и на 32х" и "нужно уже 64".


     
     
  • 3.18, Аноним (-), 16:06, 12/02/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Вообще-то она после 4 Гб не более сложная, а просто другая, и давно уже аппаратно >поддерживаемая (начиная со 2-го пня где-то).

    PAE - костыль. Линейное адресное пространство всеравно не расширяется.

     
     
  • 4.22, Konwin (ok), 16:19, 12/02/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >>Вообще-то она после 4 Гб не более сложная, а просто другая, и давно уже аппаратно >поддерживаемая (начиная со 2-го пня где-то).
    >
    >PAE - костыль. Линейное адресное пространство всеравно не расширяется.

    Не знаю, что вы имели ввиду под "линейным адресным пространством" но при наличие 36 аппаратных линий а шине адреса (что и есть PAE) по-моему там всё весьма тривиально, вопрос в софте. В всяком случае у меня в 2003-м это пашет и не кашляет.....

     
     
  • 5.23, Аноним (-), 16:52, 12/02/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Имел ввиду, что процесс в ОС не сможет использовать памяти более чем 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."

    :)

     
     
  • 6.25, Аноним (1), 18:11, 12/02/2008 [^] [^^] [^^^] [ответить]  
  • +/
    то есть пока одно пользовательское приложение не сожрёт 4 гига проблем не будет?
     
     
  • 7.26, Аноним (-), 18:20, 12/02/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Похоже на то.


     
  • 6.28, Konwin (ok), 23:05, 12/02/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    >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х ОС использовать можно, правда не совсем напрямую конечно.

     
     
  • 7.33, Аноним (-), 13:16, 13/02/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Привел, чтоб не быть голословным.

    >Кстати больше 4 гиг на процесс в 32х ОС использовать можно, правда не совсем напрямую конечно.

    Каким образом?

     

  • 1.29, pavlinux (ok), 00:32, 13/02/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    По теме  - http://www.thg.ru/software/windows_vista_8_gb/index.html
     
     
  • 2.31, profalex (?), 11:46, 13/02/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Отжиг:
    "Если же вы отключите файл подкачки при установленных 512 Мбайт памяти, то вы не сможете открывать даже мелкие приложения Windows, такие как "Блокнот". Да и через некоторое время система сама "вылетает", даже если вы не будете ничего делать."

    Ай да Виста, ай да молодца...

     
     
  • 3.32, Konwin (ok), 12:32, 13/02/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Отжиг:
    >"Если же вы отключите файл подкачки при установленных 512 Мбайт памяти, то
    >вы не сможете открывать даже мелкие приложения Windows, такие как "Блокнот".
    >Да и через некоторое время система сама "вылетает", даже если вы
    >не будете ничего делать."
    >
    >Ай да Виста, ай да молодца...

    Винда никогда не умела по-человечески без свопа работать


     

  • 1.34, Простой Пользователь (?), 16:18, 13/02/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Мне в Убунте больше всего не нравится то, что они не собирают дистрибутивы для i686. Неприятно терять в производительности.
    Можно подумать, что у кого-то еще стоит процессор с логикой i386 и количество оперативы, необходимое для нормальной работы Убунты (256 как минимум)
     
  • 1.36, acid (?), 01:26, 28/05/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    убунта собирается по своей философии, почитав ее просто в справке, можно понять почему они делают ее для 368х процев
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру