В материале "Ubuntu: 32-bit v. 64-bit Performance (http://www.phoronix.com/scan.php?page=article&item=616&num=1)" представлены результаты сравнения производительности i386 и x86_64 сборок Ubuntu Linux 6.10 и 7.04 Herd 1 (Linux ядра 2.6.17-10 и 2.6.19-7, GCC 4.1.2).URL: http://www.phoronix.com/scan.php?page=article&item=616&num=1
Новость: http://www.opennet.me/opennews/art.shtml?num=9393
Походу неготова еще 64 платформа...
Ну компилится на 64bit все быстрее :) Так что для gentoo 64bit-платформа готова вполне :D
О да, дистрибутив, цель существования которого -- компилячить. :)
Gentoo хорошо подходит тем, кто думает головой и хорошо представляет себе что и зачем делает. Если устанавливая gentoo ты отвечаешь на вопрос "зачем ты это делаешь" словами "для того чтобы [что-то конкретное делать....]" а не "потому что [кто-то сказал что это круто...]" тогда этот дистр для тебя.В конце концов и "компилячить" на чем-то надо. Вот только понять, что в gentoo это не самоцель, видимо, не у всех получается ;)
PS
"Не _всем_ йогурты одинаково полезны"
Ха. В статье совсем противоположные результаты. х64 как раз почти во всех задачах быстрее. А UT2004 скорее всего поставляется в 32 разрядных бинарниках, так что пока его не перекомпилят на х64 - это не показатель.
Запуск же игр, ориентированных на х64 под оффтопиком показывает, что одна и та же игра быстрее работает в 64 разрядной версии. Только вот создатели поганого старфорса все никак не сделают его нормальную х64 версию, из-за чего многие игры приходится запускать на 32 разрядной системе.
А где ускорение то? Разница в 1% это не ускорение, а погрешность. Была бы хотя бы 10%, вот тогда можно было смело заявлять - быстрее. А то что компилится быстрее, это конечно хорошо, но не показатель. И что они там интересно за конфигурацию ядра использовали, что она полчаса компилится? Мой конфиг компилится 277 секунд на P4-2.4G под LFS 6.0
гы гы гы 141 сек. на 2-х Opteron 265
> Только вот создатели поганого старфорса все никак не сделают его нормальную х64 версию, из-за чего многие игры приходится запускать на 32 разрядной системе.
Не покупай каку.Зачем поддерживать производителей говна своими денежками и потом тр?*:ться с ним потом?
Выигрыш по производительности менее 20-30% просто не ощущается. Переход на 64 бита такой выигрыш дает (ке-где дает и 200-400 - openSSL), но не везде - компилятор и код должны быть оптимизированы. Как по мне, для десктопа на сегодня 64 бита не особо востребованы - ОО2 пока 32бит (инфровский), браузеры и флэш-плагин тоже, видеоплеера (32 кодеки),...
игрушки мне пофиг, вот манки аудио под 64 бит немного побыстрее, но никак не на 50%.
Впрочем, правильные дистрибутивы имеют полную поддержку 64 и 32бит программ благодаря 2 комплектам библиотек.
Что такое x64? x86_64(amd64) знаю, ia64 знаю, x64 - не знаю :)
Уверяю Вас всех что ubuntu на amd64 ведёт себя более шустро чем на 32 битной платформе.
Доказано ut2004
64 браузеры давно есть :) Опера есть точно :)
64 быстрее в компиляции и видеообработке ну и сжатии конечно. Вообщем везде где идет работа с целыми большими 32 бит и нигде больше :)
Странно, но на http://www.opera.com/download/index.dml?custom=yes нет версии под x86_64. Под SPARC и PowerPC есть. И то, только для линухов. (Ну, еще SPARC под солярку - куда без нее).
Не будет ли любезен многоуважаемый джин сообщить, где он видел оперу под 64 бита? Уж очень хоцца...
Оперы по x86_64 - пока нет.
>Оперы по x86_64 - пока нет.
Вкусите радость юзания проприетарщины и степень зависимости от вендора :).
ЗЫ Фокс 2.0.1 для х64 точно есть :)
такое ощущение что на ubuntu64 просто забили, некоторые пакеты глючат. Жаль буржуйским не бегло владею дабы на ланчпаде баг запостить.
>такое ощущение что на ubuntu64 просто забили, некоторые пакеты глючат. Жаль буржуйским
>не бегло владею дабы на ланчпаде баг запостить.
А можно конкретику?Багу заколочу если скажете как воспроизвести и у меня повторится.
ЗЫ пользую Kubuntu x64 - особо проблем не углядел пока.Работает, каши не просит...
Товаришь который писал про 64 бит. браузеры и видеообработку - теоретик. Неправда, про браузеры уже сказали, про кодирование видео - кодеки не оптимизированы (медленне чем 32, ну по крайней мере тогда было).
Сам сидел долго на FC5-x86_64 ушел на 32 бит. Щас FC6-i386, но не теряю надежды. Буду пробовать FC6-x86_64.
>Товаришь который писал про 64 бит. браузеры и видеообработку - теоретик. Неправда,
>про браузеры уже сказали, про кодирование видео - кодеки не оптимизированы
>(медленне чем 32, ну по крайней мере тогда было).
>Сам сидел долго на FC5-x86_64 ушел на 32 бит. Щас FC6-i386, но
>не теряю надежды. Буду пробовать FC6-x86_64.
Вот поэтому у меня и стоит i386 FC6.
В теории на 64 всё быстрее.
А на практике.. (gcc далеко не идеален)
Нет , кое-что на х86-64 реально быстрее.
Но на рабочей станции пофиг, что SSL быстрее в 2-4 раза.
Как и скорость mysql.
А из прикладных, реально грузящих процессор..
Например, кодирование и декодирование monkey audio. Но не намного.
Зато весь софт под 64 жрет сильно больше памяти - от иксов и далее.
>>Товаришь который писал про 64 бит. браузеры и видеообработку - теоретик.
Тогда пусть господа практики попробуют выделить более 4 гигов (реально даже меньше) одному процессу.При это пофиг на скорость - это просто невозможно из-за архитектуры.Невозможно vs с какой-то скоростью - слив по любому.А так 64-битная архитектура на чем-то быстрее (64-битных регистров больше и в них можно совать 64-битные числа без изгалений) а на чем-то медленнее (64-битные указатели вместо 32-битных все-таки не на халяву даются, да, а путем прокачки большего объема данных, правда?)
>>>Товаришь который писал про 64 бит. браузеры и видеообработку - теоретик.
>Тогда пусть господа практики попробуют выделить более 4 гигов (реально даже меньше)
>одному процессу.
/bin/sh, что ли? У Вас во всех тазиках под рукой в сумме памяти сколько, для начала? (у меня даже с учётом мобилки :) в среднем по больнице больше гига на штуку получается, но текущий максимум -- именно четыре [из шестнадцати])PS: можно не отвечать, вопрос риторический, я немного в курсе.
> в сумме памяти сколько, для начала?
7 Gb из того что тут стоит на моем столе.Правда, у меня на столе компьютеры - я, имхо, не в прачечной.>PS: можно не отвечать, вопрос риторический, я немного в курсе.
Думаю что мнение человека который "в курсе" но тем не менее, не отличает flash память в мобилке от RAM не является чем-то чрезмерно интересным, поэтому ваши остроты про /bin/sh оставьте при себе.А на досуге дайте себе труд разобраться хотя-бы в основных типах памяти прежде чем рот разинуть, остряк.Или вы нашли где-то мобилку с гигом RAM?Не верю, фантастика на другом этаже.А флеш, извините, не RAM :PИ, кстати для специалистов по тазикам намекну что 4Gb это полное адресное пространство ака 2^32.Процесс не может захапать _все_ 4 гига из него.Что-то должно остаться под системные области.Поэтому процесс в 32-битной системе обычно не может захапать себе более чем 1(кажись в линуксе столько, если не глючу), 2(винды) или 3 гига (винды с ключиком /3GB в ntldr).
>> в сумме памяти сколько, для начала?
>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.Вольно.
>А, ну тогда явно в министерстве культуры. Я ж не с
>Вами общаюсь, если не заметили вдруг. И соответственно в другом
>контексте.
Да это я же :) просто в другом месте.И браузер соответственно не 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.
Самое интересное что я с этим и не спорил вроде.Я про дефолты.Но вам главное я так понимаю наехать на оппонента, да?Посему дефолты смещены в сторону "оппонент дурак и нии**т".Так?:)>Вольно.
Ышь ты, свадебных генералофф развелось которые сами конкретики не помнят однако :)
>>А, ну тогда явно в министерстве культуры. Я ж не с
>>Вами общаюсь, если не заметили вдруг. И соответственно в другом
>>контексте.
>Да это я же :) просто в другом месте.И браузер соответственно не
>100% совпадает с браузером в том месте.В частности ником.
Хе. Сам всё не добирался синхронизировать на буке (gvy) и дома (Michael Shigorin).
Ладно, тогда остаётся только про министерство. :)[ ;-) ]
>давайте рассказывайте как я был неправ и как в х86 можно выдать
>более 4 гиг одному процессу.
Перечитайте -- я как раз о том, что даже не ">", а "=" -- не выйдет. Впрочем, это как раз мелочи и Вы и так знали вроде:
>Тогда пусть господа практики попробуют выделить более 4 гигов (реально даже меньше)
>одному процессу>>Вы не глючите, Вы просто не знаете. Разделение user/kernel в линуксе
>>бывает и иное, нежели 1/3.
>Самое интересное что я с этим и не спорил вроде.Я про дефолты.
Я тоже.>Но вам главное я так понимаю наехать на оппонента, да?Посему дефолты смещены
>в сторону "оппонент дурак и нии**т".Так?:)
Нет, конечно. Просто если оппонент решает сместиться в ту сторону, то до точки "в морг" может иметь маленький смысл наехать по существу. Не с тем, чтобы круто выпендриться (я давно не занимаюсь железом сколько-нибудь с толком -- на то другие тут есть), а с тем, чтобы по возможности чего интересного подсказать и заодно дать повод задуматься, а стоило ли начинать бузу.Возвращаясь к нашим баранам -- объёмы и характер организации памяти я упоминал к тому, чтобы разницу (критичную, а не "ну чуть медленней/быстрей") между 32/64-битными архитектурами подчеркнуть на _типичных_ задачах.
Так вот на сейчас тезис вида "ааа! на декстопе-32 нельзя выделить много байтов одному процессу!" -- несостоятелен при "много" порядка 2^32 по той простой причине, что /пока/ таких десктопных задач с аппетитами корпоративных СУБД -- скорее нет. /Завтра/ ими будут, ессно, игрушки -- такой себе ВПК писюка. Но к этому "завтра" уже не останется IA32-only из производимого, если правильно помню опубликованные планы по производству AMD/Intel на этот год.
Поэтому не было смысла орать о проблеме, которой нет: на сейчас для большинства применений достаточно (и зачастую оптимально) использовать 32-битный режим и x86_64-процессоров, а когда типичная продаваемая/пожираемая RAM дорастёт до порога в 4Gb -- то проблема будет скорее в том, где переход будет мягче и незаметней. На какой платформе, в каком дистрибутиве или конкретно взятой софтинке.
Так более внятно?
>>Вольно.
>Ышь ты, свадебных генералофф развелось которые сами конкретики не помнят однако :)
Так помню, где/как её искать ;)
>Хе. Сам всё не добирался синхронизировать на буке (gvy) и дома
>(Michael Shigorin).
>Ладно, тогда остаётся только про министерство. :)
Ну вот, сам оказывается такой же :)>Перечитайте -- я как раз о том, что даже не ">", а "=" -- не выйдет. Впрочем, это как раз мелочи и Вы и так знали вроде:
Угу.Кой-какие основы х86 я знаю.Хотя и не шибко сильно.Однако при нужде как и вы найду через непродолжительное время поисков.>>Самое интересное что я с этим и не спорил вроде.Я про дефолты.
>Я тоже.
Я там кстати похоже нагнал на линукс незаслуженно.Вроде, на х86 по дефолту наоборот - процесс может отожрать 3 гига или около того а системе остается около гига.>Нет, конечно. Просто если оппонент решает сместиться в ту сторону, то
>до точки "в морг" может иметь маленький смысл наехать по существу.
Это да, возможно вполне правильно :) просто перегибать тоже не надо - а то возникает стойкое и не очень конструктивное желание наехать в ответ.>с тем, чтобы по возможности чего интересного подсказать и заодно дать
>повод задуматься, а стоило ли начинать бузу.
Думаю что эта цель была в чем-то достигнута, во всяком случае я очень кстати наткнулся на интересную статью как раз про объем доступной в i386 линуксным программам памяти.>Возвращаясь к нашим баранам -- объёмы и характер организации памяти я упоминал
>к тому, чтобы разницу (критичную, а не "ну чуть медленней/быстрей") между
>32/64-битными архитектурами подчеркнуть на _типичных_ задачах.
Типичность задач - понятие относительное.Хотя да, пока еще - 4 гига памяти типичные задачи редко кушают.Но скоро будут.Лично я видел как программы (правда, в винде) вылетают когда 2Gb виртуального пространства закончились, хотя физической памяти при этом может жраться кстати вполне адекватно.Кстати эта проблема освещена на страничке посвященной проблеме C10K (10 000 соединений на 1 сервер) и серверам http использующим треды.Там меткое замечание что каждый тред жрет заметно виртуальной памяти (нечто типа 2 Мб на тред - под стек), итого после запуска заметного числа тредов процесс на 32-битной платформе может сурово обломаться из-за окончания адресного пространства (не окончании системной памяти!).Реально столько памяти конечно же процессом не используется (тред вовсе не обязан немедленно забить стек на 2 мега) - все это не представляло бы никаких проблем ... если б не ограниченность диапазона адресов.>Так вот на сейчас тезис вида "ааа! на декстопе-32 нельзя выделить много
>байтов одному процессу!" -- несостоятелен при "много" порядка 2^32 по той
>простой причине, что /пока/ таких десктопных задач с аппетитами корпоративных СУБД
>-- скорее нет. /Завтра/ ими будут, ессно, игрушки -- такой
Да ладно вам, просто задача с множественными тредами.См.выше про C10K.Задача с множеством тредов жрала бы не шибко то и много *физической* памяти и *свопа* (я так понимаю линукс выделяет страницы только когда они реально начинают юзаться?) но зато такая задача может налететь на тот факт что ее адресное пространство даденое процессу просто кончается(хотя ни своп ни физическая память не забиты).Итого получается бестолковое ограничение на число тредов на процесс, ничем особо не обоснованное кроме ограничений 32-битной архитектуры.>Поэтому не было смысла орать о проблеме, которой нет:
См.выше - иногда проблемы бывают там где не ждали - скажем окончание адресного пространства при том что реально память не закончилась это довольно забавно, а? :)> достаточно (и зачастую оптимально) использовать 32-битный режим
Ну, я использую в 64-битном :).Мне и так неплохо :).Как (временный?) бонус - некоторая устойчивость к фокусам скрипткиддей (у них сплойтов для х64 как-то не замечено тоннами).>Так помню, где/как её искать ;)
Если мне приспичит я тоже найду, а вы что подумали?:)
>Кстати эта проблема освещена на страничке посвященной проблеме C10K (10 000 соединений
>на 1 сервер) и серверам http использующим треды.Там меткое замечание что каждый тред
>жрет заметно виртуальной памяти (нечто типа 2 Мб на тред - под стек),
>итого после запуска заметного числа тредов процесс на 32-битной платформе может
>сурово обломаться из-за окончания адресного пространства (не окончании системной памяти!).
Так это проблема дизайна. Белые люди давно подметили, что в подобных задачах проблема часто сводится к тому, что держать хоть наполовину надутый инстанс на каждый чих -- не надо, и стали разделять задачи приёма соединений и отработки приложения в разные слои.Любимый пример -- тот же nginx, который легко и непринуждённо принимает 10K коннекшенов (есть и другие, например, мультиплексирующий boa) и не держит код для обработки запроса всё время от начала соединения до отваливания (что на медленных соединениях сильно поднимает произведение время*RAM при использовании того же apache и для отработки соединений, и в качестве application server для всякого PHP/Perl). При этом получается уменьшить нагрузку на память и заодно естественным образом "размазать" нагрузку на несколько бэкендов при необходимости.
[в сторону: разумеется, лучше подоткнуть под один эсс восемь гиг и четыре камня, чем сразу продумать нормальную систему без никаких SQL и тем более DBF -- ну или хотя бы не покупаться на заведомо немасштабируемое решение... зато гордо называется "ынтыпрайз солюшен"]
>>Кстати эта проблема освещена на страничке посвященной проблеме C10K
>Так это проблема дизайна.
Ну да, ну да... а может, в итоге программирование производительного сервера под 32-битную платформу страдает тупым ограничением на стиль программирования на ровном месте?>Белые люди давно подметили, что в подобных задачах проблема часто сводится
>к тому, что держать хоть наполовину надутый инстанс на каждый чих --
>не надо, и стали разделять задачи приёма соединений и отработки приложения в разные слои.
От себя замечу что по идее, многопоточный сервер лучше масштабируется на многопроцессорных платформах.Особенно если скажем файлы из hot cache выуживаются(что при достаточном объеме памяти вполне возможно и здорово поднимает скорость работы).И будущее - за многопроцессорными машинами, большим объемом памяти и т.п. - вот тут еще вопрос кто окажется эффективнее...>Любимый пример -- тот же nginx, который легко и непринуждённо принимает 10K
>коннекшенов (есть и другие, например, мультиплексирующий boa)
Юзаю для приватной файлопомойки lighttpd - насчет 10 000 конекшнов специально не тестил, но кучку юзвергов на 100 мбитах сервит и не икает.Кушая полпроцента проца и пару мегов памяти :).Да, он тоже не стартует процессы и треды на каждый чих :)>и не держит код для обработки запроса всё время от начала соединения до отваливания
>(что на медленных соединениях сильно поднимает произведение время*RAM при
>использовании того же apache и для отработки соединений, и в качестве application
>server для всякого PHP/Perl).
Апач это да... memory hog :)>заодно естественным образом "размазать" нагрузку на несколько бэкендов при необходимости.
Это да.Зато есть подозрения что без тредов нагрузка на процессоры 1 машины не очень размазывается.>[в сторону:
>... зато гордо называется "ынтыпрайз солюшен"]
Я заметил что бизнес-дядек программеры нынче совсем за лохов держат, чуть ли не соревнуясь - кто более дерьмовое и ресурсожоркое решение за как можно больше денег втюхает :)
>>Так это проблема дизайна.
>а может, в итоге программирование производительного сервера под 32-битную платформу
>страдает тупым ограничением на стиль программирования на ровном месте?
В данном разе -- не на ровном, бишь она страдает фактическим ограничением *для* тупого стиля проектирования. Не уверен, что Вы различаете здесь программирование и проектирование, поскольку проблема именно во втором, а не в реализации.>>Белые люди давно подметили, что в подобных задачах проблема часто сводится
>>к тому, что держать хоть наполовину надутый инстанс на каждый чих --
>>не надо, и стали разделять задачи приёма соединений и отработки приложения в разные слои.
>От себя замечу что по идее, многопоточный сервер лучше масштабируется на многопроцессорных
Так мультиплексирование не противоречит много{поточности,процессности}.>>Любимый пример -- тот же nginx