The OpenNET Project / Index page

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

Сравнение производительности 32 и 64-битных версий Linux дистрибутивов

11.07.2008 01:00

Алексей Михайлов представил результаты тестирования времени выполнения определенных задач для i386 и x86_64 сборок Linux дистрибутивов Fedora 9, OpenSUSE 11.0 (GNOME Edition) и Ubuntu 8.04.1. Тестирование проведено с целью количественной оценки преимуществ производительности 64-битной системы над 32-битной.

Была измерена скорость загрузки системы, проведено кодирование звука, сжатие данных, компиляция ядра Linux. Приведены конкретные цифры производительности вышеприведенных систем.

В результате были получены данные, в соответствии с которыми, в процентном соотношении преимущество 64-битной системы над 32-битной колеблется от 0.6% до 45%:

  • для дистрибутива Fedora 9 - от 1.2% до 26.9%;
  • для OpenSUSE 11.0 - от 0.6% до 45%;
  • для Ubuntu 8.04.1 - от 0.6% до 31.7%.


  1. Главная ссылка к новости (http://tuxnotes.ru/reviews.php...)
Автор новости: Александр
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/16907-64bit
Ключевые слова: 64bit, 32bit, performance, speed, benchmark
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (45) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Прохожий (??), 07:21, 11/07/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Фигасе... а чем это 64 бита производительнее?
    Я думал дело только в адресации: 64бита понимает большее адресное пространство и все... о каком преимуществе идет речь? или я чего-то не понимаю?
     
     
     
    Часть нити удалена модератором

  • 3.13, fidaj (??), 09:52, 11/07/2008 [ответить]  
  • +/
    АМД-ешники Да-а-а-а-леко не первые это смекнули...;)
     
  • 3.30, madcore (?), 16:45, 11/07/2008 [ответить]  
  • +/
    А ничего, что в 64-режиме sizeof(int) оп умолчанию 32?
     
     
  • 4.34, MiG (?), 18:25, 11/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    А он и не обязан быть 64 бита. Это long должен быть 64 бита.
    Учим матчасть.
     
     
  • 5.41, User294 (ok), 00:18, 12/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >А он и не обязан быть 64 бита. Это long должен быть
    >64 бита.

    А нельзя ли уточнить сишный или си++ный стандарт по которому long именно *должен* быть 64 бита?То что он *обычно* 64 бита на 64-бит системах... ну мало ли чего.

     
     
  • 6.44, dmitry.kuzmenko (ok), 02:33, 12/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Страуструпа почитай! long -- это машинное слово
     
  • 2.38, User294 (ok), 00:00, 12/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >  Фигасе... а чем это 64 бита производительнее?

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

    ..но реалии нынче таковы что системы с DDR2 и DDR3 работающем в 2...3 канальном режиме (т.е. все современные системы от AMD и интеля) могут в принципе пропихать данных явно больше чем может обмолотить процессор.Посему переход на 64 бита уже не обязательно несет заметный penalty в скорости сам по себе.Просто bandwith оперативки начнет юзаться более полно :) а вот на юзании 64-битных регистров да еще коих побольше - можно и что-то выиграть.

     

  • 1.2, guest (??), 07:27, 11/07/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ясен перец ты вообще ничерта не понимаешь :-)
    Это всё-таки более современная архитектура - возможность адресовать больше памяти, возможности посчитать больше данных за такт, новые инструкции процессора, большее количество регистров большей размерности и т. д.
    Это только корявая винда одинаково плохо работает на любой архитектуре, а GNU/Linux использует возможности железа полностью - что сразу показывает преимущество одной архитектуры над другой.
     
     
  • 2.5, Аноним (-), 08:26, 11/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Бла-бла-бла Фундаментальных, принципиальных отличий amd64 перед чистым x86 де... большой текст свёрнут, показать
     
     
  • 3.7, Осторожный (?), 08:50, 11/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >в 64битный режим быстрее не становятся :) Преимущества этой архитектуры могут
    >проявиться разве что в каких-либо числодробильных приложениях при большом количестве установленной
    >_физической_ памяти. А что касается обыкновенных домашних писюков с объемом памяти

    вот это заблуждение - насчет того что нужно очень много памяти чтобы заметить разницу

    Во-первых мы имеем больше регистров общего назначения в 64 long mode
    А это весьма существенно, ибо в 32 mode этих самых регистров кот наплакал.

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

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

    В-четвертых я проводил benchmark-тесты на
    дохлый Xeon, зато c 4Gb памяти и 2x2 процами
    Athlon 64 3000+
    под управлением CentOS 5.1 32-bit и 64-bit

    В целом в 64-битном режиме считает либо так же, либо быстрее.
    Xотя были отдельные тесты где в 32-bit было чуть быстрее чем в 64-bit

    Заодно выяснил, что Xeon-ы надо брать большой частоты (за гораздо большие деньги), так как даже старый-старый Athlon 3000+ уделывает Xeon низкой частоты при использовании 1 CPU :)))

     
     
  • 4.24, Аноним (-), 12:45, 11/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Во-вторых - ассемблер в 64-mode другой и система команд другая - более
    >адекватная.

    Неправда. Ассемблер и система команд в long mode те же самые, только некоторые опкоды (типа AAA, AAD, AAM и др. - всего около 20-ти) не поддерживаются, а у ARPL и INC/DEC reg64 опкоды изменены. Читаем AMD64 Architecture Programmer’s Manual Volume 3: General-Purpose and System Instructions, Appendix C: Differences Between Long Mode and Legacy
    Mode.

     
  • 3.10, Konwin (??), 09:08, 11/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    А если не секрет - вы какие конкретно процессоры имеет ввиду под IA64? Что касается объёма памяти на домашних компах - это вопрос времени, у меня вот 8 гиг дома и 64х битные ОС соотвественно, и стоит это удовольствие отнюдь не космические деньги - 8 гиг памяти это 5к рублей. В офисе же и 4 гига как правило не к чему и 64х битные ОС тоже соотвественно не нужны.
     
     
  • 4.16, Аноним (-), 10:54, 11/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Тут выбор, по-моему, невелик Intel Itanium 2, ну и младшие его поколения То, ... большой текст свёрнут, показать
     
     
  • 5.20, Konwin (ok), 11:55, 11/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Тут выбор, по-моему, невелик:) Intel Itanium 2, ну и младшие его поколения.
    >То, что память дешевеет, это конечно очевидно, но вот зачем домашней
    >машине столько памяти? У меня вот стоит 4 гига, но очень
    >редко когда потребление ее переваливает за полтора гигабайта. Возникает вопрос, "что
    >я буду делать с 8 гигабайтами?" Запускать на домашней машине большую
    >базу данных я не планирую, пока:) Разве что пару-тройку экзмемпляров Висты
    >погонять в вмваре :-D

    Интересно - как можно сравнивать Итаниум и с другими Интелами и АМД - это принципиально разные архитектуры... А что касается до памяти - на 32х битной ОС она вам конечно не нужна - те же 4 гига в большинстве 32х битных виндов и в Линуксе без перезборки ядра вы просто не увидите. А на вопрос что можно делать с N гигабайтами - каждый найдёт себе ответ сам - я вот люблю в VMWare поэкспериментировать, причём зачастую - не с одной одновременно... Кто-то графикой занимается.... Не все замыкаются на офисные приложения, прослушивание музыки и игры.

     
     
  • 6.27, Аноним (-), 14:25, 11/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Интересно - как можно сравнивать Итаниум и с другими Интелами и АМД
    >- это принципиально разные архитектуры...

    Интересно, как можно смотреть в монитор и не понимать, что в нем написано:) Вы читали предыдущие посты? Не для кого это не секрет, что это принципиально разные архитектуры, тоже мне открыли Америку.
    прочитайте еще раз вот это:

    >>Фундаментальных, принципиальных отличий amd64 перед "чистым" x86 действительно кот наплакал (другое дело х86 vs IA-64).

    особенно стоит обратить внимание на содержимое скобочек :)

     
  • 3.42, User294 (ok), 00:35, 12/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >большее количество и размерность регистров, да кучка новых инструкций.

    А этого что, мало?Вместо постоянного push\pop которое ничего полезного не делает и только греет воздух можно просто поюзать лишние регистры и кроме того если надо работать с 64-бит числами, не надо делать кучу лишних операций с регистрами (коих у х86 и так то не дофига чтобы их лишний раз дергать).

    >на данный момент узким местом любой вычислительной системы является память

    Дааа?Вот блин, а чудаки в интеле и амд этого и не знают с своими быстрыми 2...3 канальными DDR 2 и 3 и интель вон козыряет что новый процессор дескать сможет полнее использовать bandwidth памяти.Ваши познания кажется отстали на несколько годков.Да, в древней система с одноканальной памятью типа первого DDR на мизерной частоте все так как вы говорите.Только вот с тех пор скорость работы RAM кардинально подросла.

    >в 64битный режим быстрее не становятся :)

    В *современных* системах а не выкопанных на помойке, RAM зачастую может выдать больше данных чем может обмолотить процессор и там есть запас.В итоге переход на х64 приведет к более полному юзанию bandwidth оперативы просто напросто и замедление за счет бОльшего объема прокачиваемых данных если и будет то весьма незначительное.А вот то что 64-бит режим быстрее молотит 64-бит числа а операции регистр-регистр особенно когда регистры 64 битные и их много а не 32-бит и несколько - быстрее, это думаю очевидно.

    >до 4Гб и стандартным офисным софтом - то тут невооруженным глазом
    >различий вы и не заметите.

    Зато с 5Gb RAM на борту можно наслаждаться тем как практически любая запись на диск изящно и красиво буфферизуется, вообще не тормозя систему ни на йот.

     
  • 2.12, DeNIS (?), 09:39, 11/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Это только корявая винда одинаково плохо работает на любой архитектуре, а GNU/Linux
    >использует возможности железа полностью - что сразу показывает преимущество одной архитектуры
    >над другой.

    Знаеш ли ты про что поеш ?
    Попробуй запусти Сандру на 32-й винде и на 64 ... получиш разницу в работе АЛУ 10 %.
    А работать с линухо тебе еще рановато.

     
     
  • 3.15, Хелагар (ok), 10:51, 11/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >>Это только корявая винда одинаково плохо работает на любой архитектуре, а GNU/Linux
    >>использует возможности железа полностью - что сразу показывает преимущество одной архитектуры
    >>над другой.
    >
    >Знаеш ли ты про что поеш ?
    >Попробуй запусти Сандру на 32-й винде и на 64 ... получиш разницу
    >в работе АЛУ 10 %.
    >А работать с линухо тебе еще рановато.

    Уху.
    В синтетике - есть разница.
    Вот только в реальных приложениях разница эта как-то мало ощутима. А почему?
    Да потому, что Микрософт опять перемудрил с переключениями режимов с х86-64 на х86 и обратно.
    Вот и имеем такую картину - в синтетике на сандре - +10%, в тестах на реальных приложениях.... - +2-3%. А иногда и - 2-3%. :-)
    А тут вон стабильный плюс. и не 10, а 45.

     
     
  • 4.45, DeNIS (?), 21:17, 12/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Практически полностью согласен.
    В рельных приложениях разницы почти нету. Теоретически мы понимаем что выигрыш должен быть. И линух его использует.
    Но вот как то странно дистрибы работают. Мне кажется это пиарная акция - типа наш дистр лушее, ширее и бесплатнее.
    Опять же - подход компилятора может быть разным, и на разных архитектурах он может компилировать разный код, как по использованию железа, так и по использованию стандарта С/С++.
     

  • 1.3, Анонимус (?), 07:28, 11/07/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    У сюси подозрительная разница при flac кодировании, аж 45% при том что у остальных не больше 6%
     
  • 1.4, Аноним (4), 08:17, 11/07/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Не на тех программах тестировали. Во времена появления этих 64 битных процессоров провели тест на алгоритмах шифрации, и там был выигрыш 4-х кратный ( за счет частых умножений 64x64).

     
  • 1.6, Mike (??), 08:40, 11/07/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А вот мой производитель софта сказал, что их 32-битная версия быстрее 64-битной. И если мне не надо памяти больше 4 гиг, то лучше оставить 32-бита (система+софт).
     
     
  • 2.8, Осторожный (?), 08:57, 11/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >А вот мой производитель софта сказал, что их 32-битная версия быстрее 64-битной.
    >И если мне не надо памяти больше 4 гиг, то лучше
    >оставить 32-бита (система+софт).

    Твой производитель софта - это не Microsoft часом ? :)

     
  • 2.17, Аноним (4), 11:14, 11/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    тебе нагнали.
    MS Windows XP 32bit не позволяет выделить больше 1.5Gb
    ключи /3gb /pae добавляют только глюков.
     
     
  • 3.21, Andrew Kolchoogin (?), 11:57, 11/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    > MS Windows XP 32bit не позволяет выделить больше 1.5Gb

        Linux тоже.

    > ключи /3gb /pae добавляют только глюков.

        Ну, насчет /3GB -- наверное, все-таки, нет, как и опция ядра Линукса, позволяющая ему адресовать 4 ГБ ОЗУ (BIGMEM, если мне ни с кем не изменяет мой склероз).
        А вот PAE -- таки да (как и опция ядра Линукса, позволяющая ему адресовать 64 ГБ ОЗУ -- HUGEMEM, если опять-таки мой склероз ни с кем не изменяет, которая, впрочем, и отвечает за то, чтобы включить PAE).

        Впрочем, с PAE проблемы практически на всех операционных системах, если периферийные устройства поддерживают DMA, но не поддерживают его 64'х-битный режим. Такие уж вот кривые эти самые Physical Address Extensions.

     
     
  • 4.35, Если поставить перед email... (?), 19:56, 11/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >> MS Windows XP 32bit не позволяет выделить больше 1.5Gb
    >Linux тоже.

    lol
    ---------
    cat test.c
    #include <stdio.h>
    #include <stdlib.h>

    int main() {
            int s;
            for( s = 0; malloc(1024*1024); ++s );
            printf("maximum is %d mb\n",s);
            return 0;
    }

    gcc ./test.c -o test
    ./test
    maximum is 3056 mb


     
     
  • 5.40, Александр Ломанов (?), 00:09, 12/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    А надо бы:

    #include <stdio.h>
    #include <stdlib.h>

    int main() {
            int s;
            void *pv=NULL;
            for( s = 1; (pv = malloc(1024*1024*s)); ++s, free(pv), pv = NULL );
            printf("maximum is %d mb\n",s);
            return 0;
    }

     
     
  • 6.43, Сообщение (?), 02:07, 12/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    > А надо бы:

    не надо.

    >for( s = 1; (pv = malloc(1024*1024*s)); ++s, free(pv), pv = NULL );

    Это ищет максимальный непрерывный кусок памяти, который можно выделить. pv = NULL - не нужно. Если выделить сразу на несколько мб меньше этого "максимума", а после заново начать цикл, то результат будут другой.

     
     
  • 7.46, Александр Ломанов (?), 01:25, 13/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Тогда уж лучше проанализировать как работает менеджер памяти, или
    он в разных Линуксах разный ? Вроде ядро одно, и управление памятью
    в зависимости от выбора опций производительности в конфигурации
    ядра может быть разным. У меня стоит Desktop, если не ошибаюсь.
    Или это не влияет ?
    Для обработки массива указателей CS:EIP для x86 16+32=48 бит.
    Или ядро не воспринимает память как один буфер, длиной меньше
    чем 2^48 байт для x86 ?
    Какую часть памяти занимает ядро ?
    Я подозреваю, что в ядре есть статическая область памяти и
    динамическая(например кэш), то есть та, длина которой зависит от
    ресурсов машины, на которой ядро работает. Хотя знания мои о ядре
    поверхностные, но думаю, что принцип такой.
    Может драйвер памяти придумают ?
     
     
  • 8.49, Michael Shigorin (ok), 11:26, 15/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Бывает и разный, см на kerneltrap org по VM Выделение тоже бывает разное, ч... текст свёрнут, показать
     

  • 1.22, waiby (?), 12:16, 11/07/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Разница в win и linux получается от того, что в в linux'е и программы и библиотеки идут 64 битные и потому возможности и адресации и операции с 64битными числами они используют, а в win из 64 разрядных поди только комплектные .dll, большая же часть - это 32-х разрядные приложения и сторониие библиотеки.
     
  • 1.23, ге (?), 12:39, 11/07/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    фигасе тест, 3 дистра в разных разрядностях. маловато однака
     
  • 1.25, Аноним (4), 13:33, 11/07/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    как прочитал что
    "Для более точных результатов мы взяли сборки дистрибутивов с оконным менеджером GNOME." - воспринял тест сразу за юмор ))))))
    и раз уж ядро кампилили - что трудно было потестить на gentoo  ..??
     
     
  • 2.31, madcore (?), 17:01, 11/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >"Для более точных результатов мы взяли сборки дистрибутивов с оконным менеджером GNOME."
    >- воспринял тест сразу за юмор ))))))

    Ну какбэ имеется ввиду, чтоб wm/de везде одинаковы были. Лучше б в консоли меряли...

     
  • 2.50, Michael Shigorin (ok), 11:27, 15/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >и раз уж ядро кампилили - что трудно было потестить на gentoo

    Потестите
    > ..??

     

  • 1.29, pavlinux (ok), 16:14, 11/07/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А чёй-то все забыли Power5/6, Spark,  PA-RISC, Cell
     
  • 1.32, srgaz (?), 17:36, 11/07/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    1Тест отцтой !!
    2Зачем он меряет его винт, надо было в /dev/null
    3Дестребутивы обновить а не токо Бубунту
    4Файлы размером надо больше
     
  • 1.33, pavlinux (ok), 18:04, 11/07/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    В общем, проверил,
    ставлю 5,
    минус - за избыточное округление,
    минус - за не учёт расчётных и статических погрешностей хотя бы в 2%.
    минус - за использование 32-х битных дистров на 64-х разрядных CPU.
    плюс - за попытку.

    итого 2 с + :)



     
  • 1.36, white_raven (?), 20:26, 11/07/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Здесь что никто не вкурсе что в x64 регистров проца в 2 (два) раза стало больше???
    Засчёт этого прирост основной. Сходите спецификацию почитайте на amd.com
     
     
  • 2.37, pavlinux (ok), 23:58, 11/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Да все в курсе,  мы пришли к выводу что 64 бита это круто,
    только никто писать программы или пользоваться не умеет или не хотят. :)

     

  • 1.39, pavlinux (ok), 00:04, 12/07/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Да, кстати,  видимо Алексей Михайлов не читал лицензии Novell к SuSE 11,
    кроме всего прочего, там написано, что делать и опубликовывать бенчмарки
    OpenSuSE 11 без разрешения Novellя нельзя.  :-\


     
     
  • 2.51, Michael Shigorin (ok), 11:29, 15/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Да, кстати,  видимо Алексей Михайлов не читал лицензии Novell к SuSE 11,
    >кроме всего прочего, там написано, что делать и опубликовывать бенчмарки
    >OpenSuSE 11 без разрешения Novellя нельзя.  :-\

    Интересно, какую законную силу это "написано" имеет в РФ.

     
     
  • 3.52, pavlinux (ok), 15:04, 15/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >>Да, кстати,  видимо Алексей Михайлов не читал лицензии Novell к SuSE 11,
    >>кроме всего прочего, там написано, что делать и опубликовывать бенчмарки
    >>OpenSuSE 11 без разрешения Novellя нельзя.  :-\
    >
    >Интересно, какую законную силу это "написано" имеет в РФ.

    При желании могли бы судится, но выгоднее дать 100$ редактору сайта, за удаление и молчание.
      

     

  • 1.47, Аноним (4), 11:08, 13/07/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Мне вот что стало интересно... Никто не учитывает, что i686 сборка из расширений поддерживает лишь MMX, а i386 и того даже не учитывает. Так что о чем разговор?
     
     
  • 2.48, pavlinux (ok), 05:15, 14/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Мне вот что стало интересно... Никто не учитывает, что i686 сборка из
    >расширений поддерживает лишь MMX, а i386 и того даже не учитывает.
    >Так что о чем разговор?

    #man gcc

    i686

          Same as "generic", but when used as "march" option, PentiumPro instruction set

          will be used, so the code will run on all i686 family chips.


    А MMX не было в PPRO.


    Но! Этак в сентябре, я пытался поставить сначала SuSE 10.3, потом Sabyon (вроде так)
    на AMD K6 266MHz, обеими дистрибутивами был послан нах... ибо - Kernel used unsupported instruction set this СPU.

     

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



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

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