|
2.2, Аноним (-), 16:38, 31/12/2006 [^] [^^] [^^^] [ответить]
| +/– |
Ну компилится на 64bit все быстрее :) Так что для gentoo 64bit-платформа готова вполне :D | |
|
|
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 | |
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 бит и нигде больше :) | |
|
|
|
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.
Самое интересное что я с этим и не спорил вроде.Я про дефолты.Но вам главное я так понимаю наехать на оппонента, да?Посему дефолты смещены в сторону "оппонент дурак и нии**т".Так?:)
>Вольно.
Ышь ты, свадебных генералофф развелось которые сами конкретики не помнят однако :) | |
|
|
9.26, lamer (??), 13:30, 16/02/2007 [^] [^^] [^^^] [ответить] | +/– | Ну вот, сам оказывается такой же Угу Кой-какие основы х86 я знаю Хотя и не ши... большой текст свёрнут, показать | |
|
|
11.28, lamer (??), 13:44, 26/02/2007 [^] [^^] [^^^] [ответить] | +/– | Ну да, ну да а может, в итоге программирование производительного сервера под ... большой текст свёрнут, показать | |
|
|
|
|
|
|
|
|
|
|
|