The OpenNET Project / Index page

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

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

31.12.2006 15:15

В материале "Ubuntu: 32-bit v. 64-bit Performance" представлены результаты сравнения производительности i386 и x86_64 сборок Ubuntu Linux 6.10 и 7.04 Herd 1 (Linux ядра 2.6.17-10 и 2.6.19-7, GCC 4.1.2).

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


Обсуждение (29) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, voyt (ok), 16:13, 31/12/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Походу неготова еще 64 платформа...
     
     
  • 2.2, Аноним (-), 16:38, 31/12/2006 [^] [^^] [^^^] [ответить]  
  • +/
    Ну компилится на 64bit все быстрее :) Так что для gentoo 64bit-платформа готова вполне :D
     
     
  • 3.5, Michael Shigorin (?), 02:15, 01/01/2007 [^] [^^] [^^^] [ответить]  
  • +/
    О да, дистрибутив, цель существования которого -- компилячить. :)
     
     
  • 4.15, CDigger (?), 19:35, 05/01/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Gentoo хорошо подходит тем, кто думает головой и хорошо представляет себе что и зачем делает. Если устанавливая gentoo ты отвечаешь на вопрос "зачем ты это делаешь" словами "для того чтобы [что-то конкретное делать....]" а не "потому что [кто-то сказал что это круто...]" тогда этот дистр для тебя.

    В конце концов и "компилячить" на чем-то надо. Вот только понять, что в gentoo это не самоцель, видимо, не у всех получается ;)

    PS
    "Не _всем_ йогурты одинаково полезны"

     

  • 1.3, dimus (??), 16:39, 31/12/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ха. В статье совсем противоположные результаты. х64 как раз почти во всех задачах быстрее. А UT2004 скорее всего поставляется в 32 разрядных бинарниках, так что пока его не перекомпилят на х64 - это не показатель.
    Запуск же игр, ориентированных на х64 под оффтопиком показывает, что одна и та же игра быстрее работает в 64 разрядной версии. Только вот создатели поганого старфорса все никак не сделают его нормальную х64 версию, из-за чего многие игры приходится запускать на 32 разрядной системе.
     
     
  • 2.4, NaGoS (?), 17:04, 31/12/2006 [^] [^^] [^^^] [ответить]  
  • +/
    А где ускорение то? Разница в 1% это не ускорение, а погрешность. Была бы хотя бы 10%, вот тогда можно было смело заявлять - быстрее. А то что компилится быстрее, это конечно хорошо, но не показатель. И что они там интересно за конфигурацию ядра использовали, что она полчаса компилится? Мой конфиг компилится 277 секунд на P4-2.4G под LFS 6.0
     
     
  • 3.8, pavlinux (??), 15:16, 01/01/2007 [^] [^^] [^^^] [ответить]  
  • +/
    гы гы гы 141 сек. на 2-х Opteron 265
     
  • 2.6, Аноним (-), 12:17, 01/01/2007 [^] [^^] [^^^] [ответить]  
  • +/
    > Только вот создатели поганого старфорса все никак не сделают его нормальную х64 версию, из-за чего многие игры приходится запускать на 32 разрядной системе.
    Не покупай каку.Зачем поддерживать производителей говна своими денежками и потом тр?*:ться с ним потом?
     
     
  • 3.7, Евгений (??), 14:12, 01/01/2007 [^] [^^] [^^^] [ответить]  
  • +/
         Выигрыш по производительности менее 20-30%  просто не ощущается.  Переход на 64 бита  такой выигрыш дает  (ке-где дает и 200-400 - openSSL), но не везде - компилятор и код должны быть оптимизированы.   Как по мне, для десктопа на сегодня 64 бита  не особо востребованы - ОО2 пока 32бит  (инфровский),  браузеры и флэш-плагин тоже,  видеоплеера (32 кодеки),...
    игрушки мне пофиг, вот манки аудио под 64 бит немного побыстрее, но никак не на 50%.
    Впрочем,  правильные  дистрибутивы имеют полную  поддержку 64 и 32бит программ благодаря 2 комплектам библиотек.  
     
  • 2.10, Dimez (??), 00:01, 02/01/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Что такое x64? x86_64(amd64) знаю, ia64 знаю, x64 - не знаю :)
     

  • 1.9, Аноним (-), 17:07, 01/01/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Уверяю Вас всех что ubuntu на amd64 ведёт себя более шустро чем на 32 битной платформе.
    Доказано ut2004
     
  • 1.11, Sunder (?), 23:38, 02/01/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    64 браузеры давно есть :) Опера есть точно :)
    64 быстрее в компиляции и видеообработке ну и сжатии конечно. Вообщем везде где идет работа с целыми большими 32 бит и нигде больше :)
     
     
  • 2.12, praporshik (?), 04:24, 03/01/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Странно, но на http://www.opera.com/download/index.dml?custom=yes нет версии под x86_64. Под SPARC и PowerPC есть. И то, только для линухов. (Ну, еще SPARC под солярку - куда без нее).
    Не будет ли любезен многоуважаемый джин сообщить, где он видел оперу под 64 бита? Уж очень хоцца...
     
     
  • 3.14, ананим (?), 03:49, 05/01/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Оперы по x86_64 - пока нет.
     
     
  • 4.18, ламусанонимус (?), 06:09, 07/02/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >Оперы по x86_64 - пока нет.
    Вкусите радость юзания проприетарщины и степень зависимости от вендора :).
    ЗЫ Фокс 2.0.1 для х64 точно есть :)
     

  • 1.13, arruah (??), 07:02, 03/01/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    такое ощущение что на ubuntu64 просто забили, некоторые пакеты глючат. Жаль буржуйским не бегло владею дабы на ланчпаде баг запостить.
     
     
  • 2.17, ламусанонимус (?), 06:07, 07/02/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >такое ощущение что на ubuntu64 просто забили, некоторые пакеты глючат. Жаль буржуйским
    >не бегло владею дабы на ланчпаде баг запостить.
    А можно конкретику?Багу заколочу если скажете как воспроизвести и у меня повторится.
    ЗЫ пользую Kubuntu x64 - особо проблем не углядел пока.Работает, каши не просит...
     

  • 1.16, Аноним (-), 01:20, 07/02/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Товаришь который писал про 64 бит. браузеры и видеообработку - теоретик. Неправда, про браузеры уже сказали, про кодирование видео - кодеки не оптимизированы (медленне чем 32, ну по крайней мере тогда было).
    Сам сидел долго на FC5-x86_64 ушел на 32 бит. Щас FC6-i386, но не теряю надежды. Буду пробовать FC6-x86_64.
     
     
  • 2.19, evgeniy1 (ok), 12:16, 07/02/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >Товаришь который писал про 64 бит. браузеры и видеообработку - теоретик. Неправда,
    >про браузеры уже сказали, про кодирование видео - кодеки не оптимизированы
    >(медленне чем 32, ну по крайней мере тогда было).
    >Сам сидел долго на FC5-x86_64 ушел на 32 бит. Щас FC6-i386, но
    >не теряю надежды. Буду пробовать FC6-x86_64.


       Вот поэтому у меня и стоит i386 FC6.
    В теории на 64 всё быстрее.
    А на практике..  (gcc далеко не идеален)
    Нет ,  кое-что на х86-64 реально быстрее.
    Но на рабочей станции пофиг, что SSL быстрее в 2-4 раза.
    Как и скорость mysql.
    А из прикладных, реально грузящих процессор..
    Например, кодирование и декодирование monkey audio.  Но не намного.  
    Зато весь софт под 64 жрет сильно больше памяти - от иксов и далее.


     
     
  • 3.20, lamer (??), 11:37, 08/02/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >>Товаришь который писал про 64 бит. браузеры и видеообработку - теоретик.
    Тогда пусть господа практики попробуют выделить более 4 гигов (реально даже меньше) одному процессу.При это пофиг на скорость - это просто невозможно из-за архитектуры.Невозможно vs с какой-то скоростью - слив по любому.А так 64-битная архитектура на чем-то быстрее (64-битных регистров больше и в них можно совать 64-битные числа без изгалений) а на чем-то медленнее (64-битные указатели вместо 32-битных все-таки не на халяву даются, да, а путем прокачки большего объема данных, правда?)
     
     
  • 4.21, gvy (?), 20:47, 08/02/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >>>Товаришь который писал про 64 бит. браузеры и видеообработку - теоретик.
    >Тогда пусть господа практики попробуют выделить более 4 гигов (реально даже меньше)
    >одному процессу.
    /bin/sh, что ли?  У Вас во всех тазиках под рукой в сумме памяти сколько, для начала? (у меня даже с учётом мобилки :) в среднем по больнице больше гига на штуку получается, но текущий максимум -- именно четыре [из шестнадцати])

    PS: можно не отвечать, вопрос риторический, я немного в курсе.

     
     
  • 5.22, ламусанонимус (?), 00:01, 14/02/2007 [^] [^^] [^^^] [ответить]  
  • +/
    > в сумме памяти сколько, для начала?
    7 Gb из того что тут стоит на моем столе.Правда, у меня на столе компьютеры - я, имхо, не в прачечной.

    >PS: можно не отвечать, вопрос риторический, я немного в курсе.
    Думаю что мнение человека который "в курсе" но тем не менее, не отличает flash память в мобилке от RAM не является чем-то чрезмерно интересным, поэтому ваши остроты про /bin/sh оставьте при себе.А на досуге дайте себе труд разобраться хотя-бы в основных типах памяти прежде чем рот разинуть, остряк.Или вы нашли где-то мобилку с гигом RAM?Не верю, фантастика на другом этаже.А флеш, извините, не RAM :P

    И, кстати для специалистов по тазикам намекну что 4Gb это полное адресное пространство ака 2^32.Процесс не может захапать _все_ 4 гига из него.Что-то должно остаться под системные области.Поэтому процесс в 32-битной системе обычно не может захапать себе более чем 1(кажись в линуксе столько, если не глючу), 2(винды) или 3 гига (винды с ключиком /3GB в ntldr).

     
     
  • 6.23, gvy (?), 12:50, 14/02/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >> в сумме памяти сколько, для начала?
    >7 Gb из того что тут стоит на моем столе.Правда, у меня
    >на столе компьютеры - я, имхо, не в прачечной.
    А, ну тогда явно в министерстве культуры.  Я ж не с Вами общаюсь, если не заметили вдруг.  И соответственно в другом контексте.

    >>PS: можно не отвечать, вопрос риторический, я немного в курсе.
    >Думаю что мнение человека который "в курсе" но тем не менее, не
    >отличает flash память в мобилке от RAM
    Я, к сожалению, отличаю (к Вашему сведению, в мобилках есть и RAM; некоторые даже знают, почему на 160 ASCII-символов в SMS получается 70 UCS2'шных).

    >дайте себе труд разобраться хотя-бы в основных типах памяти прежде чем
    >рот разинуть, остряк.
    Спасибо на добром разрешении, дяденька.

    >И, кстати для специалистов по тазикам намекну что 4Gb это полное адресное
    >пространство ака 2^32.
    Вот только перед тем, как намёкивать, идите-ка куда послушать курс лекций по ба^H^Hфичам организации адресного пространства x86, если в непрачечной спросить не у кого.

    >Процесс не может захапать _все_ 4 гига из него.Что-то
    >должно остаться под системные области.
    Хуже: user+kernel на x86 тоже не могут захапать все 4 гига в сумме.  Насколько понимаю, хак по имени PAE не отменяет ограничения на адресное пространство одного процесса и при наличии более чем 4Gb RAM (но тут не в курсе).

    >Поэтому процесс в 32-битной системе обычно не может захапать себе
    >более чем 1(кажись в линуксе столько, если не глючу)
    Вы не глючите, Вы просто не знаете.  Разделение user/kernel в линуксе бывает и иное, нежели 1/3.  Мне лень ходить вспоминать конкретику обсуждений и [возможностей] изменений этого соотношения по linux 2.x, можете посмотреть краткую историю в glibc-2.5/malloc/malloc.c по словам threshold и 2006.

    Вольно.

     
     
  • 7.24, ламусанонимус (?), 23:43, 14/02/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >А, ну тогда явно в министерстве культуры.  Я ж не с
    >Вами общаюсь, если не заметили вдруг.  И соответственно в другом
    >контексте.
    Да это я же :) просто в другом месте.И браузер соответственно не 100% совпадает с браузером в том месте.В частности ником.

    >>>PS: можно не отвечать, вопрос риторический, я немного в курсе.
    >>Думаю что мнение человека который "в курсе" но тем не менее, не
    >>отличает flash память в мобилке от RAM
    >Я, к сожалению, отличаю (к Вашему сведению, в мобилках есть и RAM;
    Да что вы говорите?А я то, тупой, писал для мобилок флешеры и (тута ирония) конечно же понятия не имею, куда там грузится мой бутлоадер пока я перезаписываю системный флеш и он недоступен, ага.И уж конечно не в курсе сколько там и чего, ага.Спасибо за лекцию, улыбнуло.Пишите еще! :D

    >некоторые даже знают, почему на 160 ASCII-символов в SMS получается 70
    >UCS2'шных).
    160 * 7 бит == 140 * 8 бит == 70 * 2.Вопросы?

    >Спасибо на добром разрешении, дяденька.
    Незачто, дядя :)

    >Вот только перед тем, как намёкивать, идите-ка куда послушать курс лекций по
    >ба^H^Hфичам организации адресного пространства x86, если в непрачечной спросить не у
    >кого.
    Ух какие мы злые.Я в x86 конечно не супер про, но основы знаю.Если у вас пальцы в дверь не пролазят - давайте рассказывайте как я был неправ и как в х86 можно выдать более 4 гиг одному процессу.

    >Хуже: user+kernel на x86 тоже не могут захапать все 4 гига в
    >сумме.  Насколько понимаю, хак по имени PAE не отменяет ограничения
    А это вообще левак какой-то ) решение через жопу.

    >Вы не глючите, Вы просто не знаете.  Разделение user/kernel в линуксе
    >бывает и иное, нежели 1/3.
    Самое интересное что я с этим и не спорил вроде.Я про дефолты.Но вам главное я так понимаю наехать на оппонента, да?Посему дефолты смещены в сторону "оппонент дурак и нии**т".Так?:)

    >Вольно.
    Ышь ты, свадебных генералофф развелось которые сами конкретики не помнят однако :)

     
     
  • 8.25, Michael Shigorin (?), 12:47, 15/02/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Хе Сам всё не добирался синхронизировать на буке gvy и дома Michael Shigori... большой текст свёрнут, показать
     
     
  • 9.26, lamer (??), 13:30, 16/02/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Ну вот, сам оказывается такой же Угу Кой-какие основы х86 я знаю Хотя и не ши... большой текст свёрнут, показать
     
     
  • 10.27, Michael Shigorin (?), 14:16, 16/02/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Так это проблема дизайна Белые люди давно подметили, что в подобных задачах пр... текст свёрнут, показать
     
     
  • 11.28, lamer (??), 13:44, 26/02/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Ну да, ну да а может, в итоге программирование производительного сервера под ... большой текст свёрнут, показать
     
     
  • 12.29, Michael Shigorin (?), 15:24, 26/02/2007 [^] [^^] [^^^] [ответить]  
  • +/
    В данном разе -- не на ровном, бишь она страдает фактическим ограничением для ... текст свёрнут, показать
     
     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



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

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