форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение		[Проследить за развитием треда]

"OpenNews: Сравнение производительности 32 и 64-битных сборок..."

Сообщение от opennews (ok) on 31-Дек-06, 16:13

В материале "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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Сообщения по теме

[Сортировка по ответам]

	1. "Сравнение производительности 32 и 64-битных сборок Ubuntu Li..."
	Сообщение от voyt (ok) on 31-Дек-06, 16:13
	Походу неготова еще 64 платформа...
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	2. "Сравнение производительности 32 и 64-битных сборок Ubuntu Li..."
	Сообщение от Аноним on 31-Дек-06, 16:38
	Ну компилится на 64bit все быстрее :) Так что для gentoo 64bit-платформа готова вполне :D
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	3. "Сравнение производительности 32 и 64-битных сборок Ubuntu Li..."
	Сообщение от dimus (??) on 31-Дек-06, 16:39
	Ха. В статье совсем противоположные результаты. х64 как раз почти во всех задачах быстрее. А UT2004 скорее всего поставляется в 32 разрядных бинарниках, так что пока его не перекомпилят на х64 - это не показатель. Запуск же игр, ориентированных на х64 под оффтопиком показывает, что одна и та же игра быстрее работает в 64 разрядной версии. Только вот создатели поганого старфорса все никак не сделают его нормальную х64 версию, из-за чего многие игры приходится запускать на 32 разрядной системе.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	4. "Сравнение производительности 32 и 64-битных сборок Ubuntu Li..."
	Сообщение от NaGoS on 31-Дек-06, 17:04
	А где ускорение то? Разница в 1% это не ускорение, а погрешность. Была бы хотя бы 10%, вот тогда можно было смело заявлять - быстрее. А то что компилится быстрее, это конечно хорошо, но не показатель. И что они там интересно за конфигурацию ядра использовали, что она полчаса компилится? Мой конфиг компилится 277 секунд на P4-2.4G под LFS 6.0
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	5. "Сравнение производительности 32 и 64"
	Сообщение от Michael Shigorin on 01-Янв-07, 02:15
	О да, дистрибутив, цель существования которого -- компилячить. :)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	6. "Сравнение производительности 32 и 64-битных сборок Ubuntu Li..."
	Сообщение от Аноним on 01-Янв-07, 12:17
	> Только вот создатели поганого старфорса все никак не сделают его нормальную х64 версию, из-за чего многие игры приходится запускать на 32 разрядной системе. Не покупай каку.Зачем поддерживать производителей говна своими денежками и потом тр?*:ться с ним потом?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	7. "Сравнение производительности 32 и 64-битных сборок Ubuntu Li..."
	Сообщение от Евгений (??) on 01-Янв-07, 14:12
	Выигрыш по производительности менее 20-30%  просто не ощущается.  Переход на 64 бита  такой выигрыш дает  (ке-где дает и 200-400 - openSSL), но не везде - компилятор и код должны быть оптимизированы.   Как по мне, для десктопа на сегодня 64 бита  не особо востребованы - ОО2 пока 32бит  (инфровский),  браузеры и флэш-плагин тоже,  видеоплеера (32 кодеки),... игрушки мне пофиг, вот манки аудио под 64 бит немного побыстрее, но никак не на 50%. Впрочем,  правильные  дистрибутивы имеют полную  поддержку 64 и 32бит программ благодаря 2 комплектам библиотек.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	8. "Сравнение производительности 32 и 64-битных сборок Ubuntu Li..."
	Сообщение от pavlinux (??) on 01-Янв-07, 15:16
	гы гы гы 141 сек. на 2-х Opteron 265
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	9. "Сравнение производительности 32 и 64-битных сборок Ubuntu Li..."
	Сообщение от Аноним on 01-Янв-07, 17:07
	Уверяю Вас всех что ubuntu на amd64 ведёт себя более шустро чем на 32 битной платформе. Доказано ut2004
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	10. "Сравнение производительности 32 и 64-битных сборок Ubuntu Li..."
	Сообщение от Dimez (??) on 02-Янв-07, 00:01
	Что такое x64? x86_64(amd64) знаю, ia64 знаю, x64 - не знаю :)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	11. "Сравнение производительности 32 и 64-битных сборок Ubuntu Li..."
	Сообщение от Sunder on 02-Янв-07, 23:38
	64 браузеры давно есть :) Опера есть точно :) 64 быстрее в компиляции и видеообработке ну и сжатии конечно. Вообщем везде где идет работа с целыми большими 32 бит и нигде больше :)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	12. "Сравнение производительности 32 и 64-битных сборок Ubuntu Li..."
	Сообщение от praporshik on 03-Янв-07, 04:24
	Странно, но на http://www.opera.com/download/index.dml?custom=yes нет версии под x86_64. Под SPARC и PowerPC есть. И то, только для линухов. (Ну, еще SPARC под солярку - куда без нее). Не будет ли любезен многоуважаемый джин сообщить, где он видел оперу под 64 бита? Уж очень хоцца...
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	13. "Сравнение производительности 32 и 64-битных сборок Ubuntu Li..."
	Сообщение от arruah (??) on 03-Янв-07, 07:02
	такое ощущение что на ubuntu64 просто забили, некоторые пакеты глючат. Жаль буржуйским не бегло владею дабы на ланчпаде баг запостить.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	14. "Сравнение производительности 32 и 64-битных сборок Ubuntu Li..."
	Сообщение от ананим on 05-Янв-07, 03:49
	Оперы по x86_64 - пока нет.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	15. "Сравнение производительности 32 и 64"
	Сообщение от CDigger on 05-Янв-07, 19:35
	Gentoo хорошо подходит тем, кто думает головой и хорошо представляет себе что и зачем делает. Если устанавливая gentoo ты отвечаешь на вопрос "зачем ты это делаешь" словами "для того чтобы [что-то конкретное делать....]" а не "потому что [кто-то сказал что это круто...]" тогда этот дистр для тебя. В конце концов и "компилячить" на чем-то надо. Вот только понять, что в gentoo это не самоцель, видимо, не у всех получается ;) PS "Не _всем_ йогурты одинаково полезны"
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	16. "Сравнение производительности 32 и 64-битных сборок Ubuntu Li..."
	Сообщение от Аноним on 07-Фев-07, 01:20
	Товаришь который писал про 64 бит. браузеры и видеообработку - теоретик. Неправда, про браузеры уже сказали, про кодирование видео - кодеки не оптимизированы (медленне чем 32, ну по крайней мере тогда было). Сам сидел долго на FC5-x86_64 ушел на 32 бит. Щас FC6-i386, но не теряю надежды. Буду пробовать FC6-x86_64.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	17. "Сравнение производительности 32 и 64-битных сборок Ubuntu Li..."
	Сообщение от ламусанонимус on 07-Фев-07, 06:07
	>такое ощущение что на ubuntu64 просто забили, некоторые пакеты глючат. Жаль буржуйским >не бегло владею дабы на ланчпаде баг запостить. А можно конкретику?Багу заколочу если скажете как воспроизвести и у меня повторится. ЗЫ пользую Kubuntu x64 - особо проблем не углядел пока.Работает, каши не просит...
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	18. "Сравнение производительности 32 и 64-битных сборок Ubuntu Li..."
	Сообщение от ламусанонимус on 07-Фев-07, 06:09
	>Оперы по x86_64 - пока нет. Вкусите радость юзания проприетарщины и степень зависимости от вендора :). ЗЫ Фокс 2.0.1 для х64 точно есть :)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	19. "Сравнение производительности 32 и 64-битных сборок Ubuntu Li..."
	Сообщение от evgeniy1 (ok) on 07-Фев-07, 12:16
	>Товаришь который писал про 64 бит. браузеры и видеообработку - теоретик. Неправда, >про браузеры уже сказали, про кодирование видео - кодеки не оптимизированы >(медленне чем 32, ну по крайней мере тогда было). >Сам сидел долго на FC5-x86_64 ушел на 32 бит. Щас FC6-i386, но >не теряю надежды. Буду пробовать FC6-x86_64.    Вот поэтому у меня и стоит i386 FC6. В теории на 64 всё быстрее. А на практике..  (gcc далеко не идеален) Нет ,  кое-что на х86-64 реально быстрее. Но на рабочей станции пофиг, что SSL быстрее в 2-4 раза. Как и скорость mysql. А из прикладных, реально грузящих процессор.. Например, кодирование и декодирование monkey audio.  Но не намного.   Зато весь софт под 64 жрет сильно больше памяти - от иксов и далее.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	20. "Сравнение производительности 32 и 64-битных сборок Ubuntu Li..."
	Сообщение от lamer (??) on 08-Фев-07, 11:37
	>>Товаришь который писал про 64 бит. браузеры и видеообработку - теоретик. Тогда пусть господа практики попробуют выделить более 4 гигов (реально даже меньше) одному процессу.При это пофиг на скорость - это просто невозможно из-за архитектуры.Невозможно vs с какой-то скоростью - слив по любому.А так 64-битная архитектура на чем-то быстрее (64-битных регистров больше и в них можно совать 64-битные числа без изгалений) а на чем-то медленнее (64-битные указатели вместо 32-битных все-таки не на халяву даются, да, а путем прокачки большего объема данных, правда?)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	21. "32  64?  32 && 64 :)"
	Сообщение от gvy on 08-Фев-07, 20:47
	>>>Товаришь который писал про 64 бит. браузеры и видеообработку - теоретик. >Тогда пусть господа практики попробуют выделить более 4 гигов (реально даже меньше) >одному процессу. /bin/sh, что ли?  У Вас во всех тазиках под рукой в сумме памяти сколько, для начала? (у меня даже с учётом мобилки :) в среднем по больнице больше гига на штуку получается, но текущий максимум -- именно четыре [из шестнадцати]) PS: можно не отвечать, вопрос риторический, я немного в курсе.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	22. "32  64?  32 && 64 :)"
	Сообщение от ламусанонимус on 14-Фев-07, 00:01
	> в сумме памяти сколько, для начала? 7 Gb из того что тут стоит на моем столе.Правда, у меня на столе компьютеры - я, имхо, не в прачечной. >PS: можно не отвечать, вопрос риторический, я немного в курсе. Думаю что мнение человека который "в курсе" но тем не менее, не отличает flash память в мобилке от RAM не является чем-то чрезмерно интересным, поэтому ваши остроты про /bin/sh оставьте при себе.А на досуге дайте себе труд разобраться хотя-бы в основных типах памяти прежде чем рот разинуть, остряк.Или вы нашли где-то мобилку с гигом RAM?Не верю, фантастика на другом этаже.А флеш, извините, не RAM :P И, кстати для специалистов по тазикам намекну что 4Gb это полное адресное пространство ака 2^32.Процесс не может захапать _все_ 4 гига из него.Что-то должно остаться под системные области.Поэтому процесс в 32-битной системе обычно не может захапать себе более чем 1(кажись в линуксе столько, если не глючу), 2(винды) или 3 гига (винды с ключиком /3GB в ntldr).
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	23. "32  64?  32 && 64 :)"
	Сообщение от gvy on 14-Фев-07, 12:50
	>> в сумме памяти сколько, для начала? >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. Вольно.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	24. "32  64?  32 && 64 :)"
	Сообщение от ламусанонимус on 14-Фев-07, 23:43
	>А, ну тогда явно в министерстве культуры.  Я ж не с >Вами общаюсь, если не заметили вдруг.  И соответственно в другом >контексте. Да это я же :) просто в другом месте.И браузер соответственно не 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. Самое интересное что я с этим и не спорил вроде.Я про дефолты.Но вам главное я так понимаю наехать на оппонента, да?Посему дефолты смещены в сторону "оппонент дурак и нии**т".Так?:) >Вольно. Ышь ты, свадебных генералофф развелось которые сами конкретики не помнят однако :)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	25. "32  vs 64?  32 -> 64 :)"
	Сообщение от Michael Shigorin on 15-Фев-07, 12:47
	>>А, ну тогда явно в министерстве культуры.  Я ж не с >>Вами общаюсь, если не заметили вдруг.  И соответственно в другом >>контексте. >Да это я же :) просто в другом месте.И браузер соответственно не >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 -- то проблема будет скорее в том, где переход будет мягче и незаметней.  На какой платформе, в каком дистрибутиве или конкретно взятой софтинке. Так более внятно? >>Вольно. >Ышь ты, свадебных генералофф развелось которые сами конкретики не помнят однако :) Так помню, где/как её искать ;)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	26. "32  vs 64?  32 -> 64 :)"
	Сообщение от lamer (??) on 16-Фев-07, 13:30
	>Хе.  Сам всё не добирался синхронизировать на буке (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 как-то не замечено тоннами). >Так помню, где/как её искать ;) Если мне приспичит я тоже найду, а вы что подумали?:)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	27. "C10K"
	Сообщение от Michael Shigorin on 16-Фев-07, 14:16
	>Кстати эта проблема освещена на страничке посвященной проблеме C10K (10 000 соединений >на 1 сервер) и серверам http использующим треды.Там меткое замечание что каждый тред >жрет заметно виртуальной памяти (нечто типа 2 Мб на тред - под стек), >итого после запуска заметного числа тредов процесс на 32-битной платформе может >сурово обломаться из-за окончания адресного пространства (не окончании системной памяти!). Так это проблема дизайна.  Белые люди давно подметили, что в подобных задачах проблема часто сводится к тому, что держать хоть наполовину надутый инстанс на каждый чих -- не надо, и стали разделять задачи приёма соединений и отработки приложения в разные слои. Любимый пример -- тот же nginx, который легко и непринуждённо принимает 10K коннекшенов (есть и другие, например, мультиплексирующий boa) и не держит код для обработки запроса всё время от начала соединения до отваливания (что на медленных соединениях сильно поднимает произведение время*RAM при использовании того же apache и для отработки соединений, и в качестве application server для всякого PHP/Perl).  При этом получается уменьшить нагрузку на память и заодно естественным образом "размазать" нагрузку на несколько бэкендов при необходимости. [в сторону: разумеется, лучше подоткнуть под один эсс восемь гиг и четыре камня, чем сразу продумать нормальную систему без никаких SQL и тем более DBF -- ну или хотя бы не покупаться на заведомо немасштабируемое решение... зато гордо называется "ынтыпрайз солюшен"]
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	28. "C10K"
	Сообщение от lamer (??) on 26-Фев-07, 13:44
	>>Кстати эта проблема освещена на страничке посвященной проблеме C10K >Так это проблема дизайна. Ну да, ну да... а может, в итоге программирование производительного сервера под 32-битную платформу страдает тупым ограничением на стиль программирования на ровном месте? >Белые люди давно подметили, что в подобных задачах проблема часто сводится >к тому, что держать хоть наполовину надутый инстанс на каждый чих -- >не надо, и стали разделять задачи приёма соединений и отработки приложения в разные слои. От себя замечу что по идее, многопоточный сервер лучше масштабируется на многопроцессорных платформах.Особенно если скажем файлы из hot cache выуживаются(что при достаточном объеме памяти вполне возможно и здорово поднимает скорость работы).И будущее - за многопроцессорными машинами, большим объемом памяти и т.п. - вот тут еще вопрос кто окажется эффективнее... >Любимый пример -- тот же nginx, который легко и непринуждённо принимает 10K >коннекшенов (есть и другие, например, мультиплексирующий boa) Юзаю для приватной файлопомойки lighttpd - насчет 10 000 конекшнов специально не тестил, но кучку юзвергов на 100 мбитах сервит и не икает.Кушая полпроцента проца и пару мегов памяти :).Да, он тоже не стартует процессы и треды на каждый чих :) >и не держит код для обработки запроса всё время от начала соединения до отваливания >(что на медленных соединениях сильно поднимает произведение время*RAM при >использовании того же apache и для отработки соединений, и в качестве application >server для всякого PHP/Perl). Апач это да... memory hog :) >заодно естественным образом "размазать" нагрузку на несколько бэкендов при необходимости. Это да.Зато есть подозрения что без тредов нагрузка на процессоры 1 машины не очень размазывается. >[в сторону: >... зато гордо называется "ынтыпрайз солюшен"] Я заметил что бизнес-дядек программеры нынче совсем за лохов держат, чуть ли не соревнуясь - кто более дерьмовое и ресурсожоркое решение за как можно больше денег втюхает :)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	29. "C10K"
	Сообщение от Michael Shigorin on 26-Фев-07, 15:24
	>>Так это проблема дизайна. >а может, в итоге программирование производительного сервера под 32-битную платформу >страдает тупым ограничением на стиль программирования на ровном месте? В данном разе -- не на ровном, бишь она страдает фактическим ограничением *для* тупого стиля проектирования.  Не уверен, что Вы различаете здесь программирование и проектирование, поскольку проблема именно во втором, а не в реализации. >>Белые люди давно подметили, что в подобных задачах проблема часто сводится >>к тому, что держать хоть наполовину надутый инстанс на каждый чих -- >>не надо, и стали разделять задачи приёма соединений и отработки приложения в разные слои. >От себя замечу что по идее, многопоточный сервер лучше масштабируется на многопроцессорных Так мультиплексирование не противоречит много{поточности,процессности}. >>Любимый пример -- тот же nginx
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]