Имеет ли смысл ставить 64-битный дистрибутив?

[andrew_bye]

Если не дошло, то тут речь не о синтетических тестах и придумках типа Java рвёт C++ тока шум стоит. Разговор идёт о преимуществах использования 64-бит супротив 32-бит системы в процессе работы обычного пользователя, точка.

А преимущество, на мой взгляд, пока только одно и называется оно > 4Gb RAM. Но в данное время 4Gb RAM для обычного пользователя - это явный перебор.
Однако следует учитывать, что большинство софта разработано для 32-битных систем и его нормальная работа в 64-битных системах не гарантирована.

[zeus]

long long a;

возводить a в квадрат последовательно от единицы до предела переменной. смотреть на время. думать.

Хех, ну, даст выполнение конкретной операции прирост, пусть даже в разы. Какой процент времени приходится на выполнение этой конкретной операции в процессе работы какой-нибудь программы? Думать надо иногда, ага.

Если не дошло, то тут речь не о синтетических тестах и придумках типа Java рвёт C++ тока шум стоит. Разговор идёт о преимуществах использования 64-бит супротив 32-бит системы в процессе работы обычного пользователя, точка.

все операции с 64битными типами long/int64... в 4 раза быстрее (1 такт x86_64 против 4х тактов x86_32). Грепаем сурцы любимой программы и смотрим, будет ли прирост.

[Sirx]

Во всех спорах про "32 против 64" приводил тест по адресу http://www.phoronix.com/scan.php?page=article&item=616&num=1 - не мог не привести и в этот раз Ибо реально ощутимого прироста производительности в 64 битной системе, кроме как в теории, нету и в помине.

[Kwah]

long long a;

возводить a в квадрат последовательно от единицы до предела переменной. смотреть на время. думать.

Хех, ну, даст выполнение конкретной операции прирост, пусть даже в разы. Какой процент времени приходится на выполнение этой конкретной операции в процессе работы какой-нибудь программы? Думать надо иногда, ага.

Если не дошло, то тут речь не о синтетических тестах и придумках типа Java рвёт C++ тока шум стоит. Разговор идёт о преимуществах использования 64-бит супротив 32-бит системы в процессе работы обычного пользователя, точка.

все операции с 64битными типами long/int64... в 4 раза быстрее (1 такт x86_64 против 4х тактов x86_32). Грепаем сурцы любимой программы и смотрим, будет ли прирост.

Зевс, ну-ка ну-ка, покажи на примере. Это поди ни много ни мало, а новое слово в Computer Science: оценка производительности программы по исходному коду в зависимости от архитектуры, на которой программа будет исполняться. Можно, наверное, подавать заявку на нобелевку (математикам точно не дают, может такое шарлатанство прокатит )

[teop]

Во всех спорах про "32 против 64" приводил тест по адресу http://www.phoronix.com/scan.php?page=article&item=616&num=1 - не мог не привести и в этот раз Ибо реально ощутимого прироста производительности в 64 битной системе, кроме как в теории, нету и в помине.

Не было в конце 2006-го года, согласно этой статье.

А вообще, то "быстродействие", которое мы как правило наблюдаем(и скорее всего обсуждаем), больше относится к скорости работы графических оболочек. В быту наиболее заметные тормоза - это если меню не сразу вылезают, приложения не сразу запускаются, на нажатие кнопок система не сразу реагирует, идет загрузка уровня в игре. Т.е. реакция на действия пользователя. Тут, как мне кажется, наибольший прирост производительности даст быстрая оперативка и грамотно настроенная оболочка, все остальное - спорно, потому как у меня 2000-я Windows на 800-м атлоне вполне комфортно ощущается даже в сравнении с двухядерным 3200+, где стоят Ubuntu и ХР. Равенство достигается за счет полного отсутствия каких-либо графических наворотов в 2000-й.
Правда, в последнее время все реже выключаю оба компа и со временем кое-какие неудобства на старом компе вылезают - в убунте у меня разом открыты 6-7 приложений, закрытием которых я себя не утруждаю, на 2000-м такие фокусы приводят со временем к тормозам, но это опять же нехватка оперативы.
Подводя итог этому почти оффтопу - я не представляю(с позиции домашнего пользования), как система может работать быстрее, чем Ubuntu с отключенным компизом или ХР с минимальными настройками эффектов и отключенным антивиром(помечтать-то можно?).
P.S. И все же пересборка ядра с правильно подобранными параметрами может дать эффект - грамотная настрока видиоплеера позволяет иногда на более слабой машине смотреть фильмы, тормозящие на более сильной с неграмотной настройкой.

[zeus]

Зевс, ну-ка ну-ка, покажи на примере. Это поди ни много ни мало, а новое слово в Computer Science: оценка производительности программы по исходному коду в зависимости от архитектуры, на которой программа будет исполняться. Можно, наверное, подавать заявку на нобелевку (математикам точно не дают, может такое шарлатанство прокатит )

иногда лучше молчать. правда правда:

main()
{
long long i;
i=1;
long long b;
for (i=1;i<100000000;i++)
{
 b=i*i;
};
};

time ./test32

real    0m1.171s
user    0m1.167s
sys     0m0.001s

time ./test64

real    0m0.454s
user    0m0.422s
sys     0m0.001s

следует подумать прежде, чем вещать, товарисч, в темах, в которых вы абсолютно ничего не понимаете 

[Kwah]

time ./test32
real    0m1.171s
user    0m1.167s
sys     0m0.001s

time ./test64
real    0m0.454s
user    0m0.422s
sys     0m0.001s

следует подумать прежде, чем вещать, товарисч, в темах, в которых вы абсолютно ничего не понимаете 

Аналогичное замечание.

А теперь смотрим, во что превратилось

все операции с 64битными типами long/int64... в 4 раза быстрее (1 такт x86_64 против 4х тактов x86_32). Грепаем сурцы любимой программы и смотрим, будет ли прирост.

на выполнении такой простой программы. Думаем...

При использовании реальных программ получатся единицы (от силы десятки) процентов выигрыша, никак не разы, ч.т.д. в общем-то.

[zeus]

time ./test32
real    0m1.171s
user    0m1.167s
sys     0m0.001s

time ./test64
real    0m0.454s
user    0m0.422s
sys     0m0.001s

следует подумать прежде, чем вещать, товарисч, в темах, в которых вы абсолютно ничего не понимаете 

Аналогичное замечание.

А теперь смотрим, во что превратилось

все операции с 64битными типами long/int64... в 4 раза быстрее (1 такт x86_64 против 4х тактов x86_32). Грепаем сурцы любимой программы и смотрим, будет ли прирост.

на выполнении такой простой программы. Думаем...

При использовании реальных программ получатся единицы (от силы десятки) процентов выигрыша, никак не разы, ч.т.д. в общем-то.

не надо извращать смысл.
я где-то заявил прирост в разы везде? нет.
я сказал, что прирост зависит от кода. конкретно - от использования 64 битных переменных. на что получил:

Зевс, ну-ка ну-ка, покажи на примере. Это поди ни много ни мало, а новое слово в Computer Science: оценка производительности программы по исходному коду в зависимости от архитектуры, на которой программа будет исполняться. Можно, наверное, подавать заявку на нобелевку (математикам точно не дают, может такое шарлатанство прокатит Wink)

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

[Kwah]

zeus
ты вклинился в разговор, и поддержал утверждение, что 64-бит система работает "гораздо быстрее" разве не так?

В качестве обоснования, вот этого "гораздо быстрее" получается, ты привёл пример операций с 64-битными целыми числами, которые, есть такое, исполняются в разы быстрее.

Возвращаясь к нашим баранам... На практике прирост скорости работы конкретных приложений с переходом на 64-битные вычисления выражается не такими драматическими величинами, причём зачастую это единицы процентов. С этим ты согласишься?

А теперь, по поводу исходничка... Может оценишь выигрышь в скорости на исходниках какого-нибудь приложения, используемого обычным пользователем день ото дня? На Firefox-ике, например? Или на каком-нибудь lame или gzip?

[zeus]

zeus
ты вклинился в разговор, и поддержал утверждение, что 64-бит система работает "гораздо быстрее" разве не так?

я сообщил, тебе в том числе, что, прирост производительности при смене архитектуры напрямую зависит от исходных кодов программы.

yum install ImageMagick.i386

Код: [Выделить]

time convert test.png -negate test.1.png

real    0m4.346s
user    0m3.676s
sys     0m0.037s

yum install ImageMagick.x86_64

Код: [Выделить]

$ time convert test.png -negate test.1.png

real    0m3.002s
user    0m2.580s
sys     0m0.039s
Прирост производительности при банальной обработке графики - 30%. Хотя понятие "Гораздо быстрее" относительно, да. Для некоторых прикладных приложений составляет до 80-90%.

Для баз данных, использующих 64битные индексы - 64битная система - самое Ъ

[Sirx]

Во всех спорах про "32 против 64" приводил тест по адресу http://www.phoronix.com/scan.php?page=article&item=616&num=1 - не мог не привести и в этот раз Ибо реально ощутимого прироста производительности в 64 битной системе, кроме как в теории, нету и в помине.

Не было в конце 2006-го года, согласно этой статье.
P.S. И все же пересборка ядра с правильно подобранными параметрами может дать эффект - грамотная настрока видиоплеера позволяет иногда на более слабой машине смотреть фильмы, тормозящие на более сильной с неграмотной настройкой.

Не было и не видно до сих пор - иное докажите. Тормоза с оболочками? Увольте - глупости. Если элементарные вещи типа кодирования аудио или видео, где в принципе идёт работа с большими массивами не даёт ожидаемого и вроде как должного по теории прироста, что уж про остальное говорить.
А Ваш З.Ы. простите уж - наивен. В том плане что не имеет отношения к обсуждаемому вопросу, и тем более что то что Вы говорите имеет смысл и на 32 битной системе и на 64 битной и не показывает превосходства одной архитектуры над другой, а показывает лишь прямоту рук

[teop]

Мой P.S. хоть и наивен, но все же имеет отношение к дискуссии, т.к. утверждение andreas о превосходстве пересобранного 64-го ядра над 32-м основано на достаточно субъективном факторе - увеличилась скорость запуска программ. Кто-то тут принялся доказывать, что переход на 64-хбитную архитектуру не дает преимуществ. У меня нет причин не доверять кому-либо, потому я рассматриваю случай, при котором каждый прав по своему, а именно: прирост в скорости запуска программ andreas может быть обусловлен не сменой архитектуры, а оптимизацией ядра под конкретную машину вообще.

Из того, что я усомнился в актуальности выводов годовалой статьи не следует, что я делаю какое-то конкретное утверждение о преимуществах той или иной архитектуры.  Вы уж извините, Sirx, но по-моему Вам просто нравится спорить.
Лично я ничего не хочу никому доказывать, моя цель - понять каково реальное положение дел и как я могу это использовать.

[Sirx]

Мой P.S. хоть и наивен, но все же имеет отношение к дискуссии, т.к. утверждение andreas о превосходстве пересобранного 64-го ядра над 32-м основано на достаточно субъективном факторе - увеличилась скорость запуска программ. Кто-то тут принялся доказывать, что переход на 64-хбитную архитектуру не дает преимуществ. У меня нет причин не доверять кому-либо, потому я рассматриваю случай, при котором каждый прав по своему, а именно: прирост в скорости запуска программ andreas может быть обусловлен не сменой архитектуры, а оптимизацией ядра под конкретную машину вообще.

Из того, что я усомнился в актуальности выводов годовалой статьи не следует, что я делаю какое-то конкретное утверждение о преимуществах той или иной архитектуры.  Вы уж извините, Sirx, но по-моему Вам просто нравится спорить.
Лично я ничего не хочу никому доказывать, моя цель - понять каково реальное положение дел и как я могу это использовать.

Ага, делать больше нечего. Я привёл цифры - Вы же голословны. Так кому тут нравится просто так спорить? Скорость запуска программ? Хи-хи, на 32 битах в Gentoo они у меня тоже быстрее запускаются - ибо оптимизация (ядро самосборное и софт весь пересобран с нужными флагами) - буду тоже голословным как и Вы     

[teop]

Вы привели цифры, я указал на их возраст. В конце статьи кстати достаточно явно говорится, что с выходом убунты 7.04 ситуация может поменяться.
Еще раз повторю, не ведите себя так, будто я утверждаю превосходство 64-хбитной архитектуры. Я верю, что у andreas запуск ускорился, я верю что у Вас он ускорился. Я утверждаю, что эти два факта не дают ответа на вопрос "какая архитектура предпочтительнее".
Изначально просто хотел разобраться, кто о чем говорит - все имеют ввиду совершенно разные скорости. Кто-то просто смотрит фильмы и пользует офисные программы, кто-то работает с графикой, кто-то запускает технические расчеты. В зависимости от того, чем человек занимается большую часть времени, понятие "скорости" будет различаться. Так какую мы обсуждаем?

[Sirx]

Вы привели цифры, я указал на их возраст. В конце статьи кстати достаточно явно говорится, что с выходом убунты 7.04 ситуация может поменяться.
Еще раз повторю, не ведите себя так, будто я утверждаю превосходство 64-хбитной архитектуры. Я верю, что у andreas запуск ускорился, я верю что у Вас он ускорился. Я утверждаю, что эти два факта не дают ответа на вопрос "какая архитектура предпочтительнее".
Изначально просто хотел разобраться, кто о чем говорит - все имеют ввиду совершенно разные скорости. Кто-то просто смотрит фильмы и пользует офисные программы, кто-то работает с графикой, кто-то запускает технические расчеты. В зависимости от того, чем человек занимается большую часть времени, понятие "скорости" будет различаться. Так какую мы обсуждаем?

Прошу прощения, но выглядело именно как утверждения превосходства. А изменилось ли что со времени тестов - имхо вряд ли. Как в начале пятого года впервые попробовал 64 на дженту, так потом чуть позже и на убунте 64 убедился что оно того не стоит, и начиная с 6.10 плотно пересел на 32 бита. В принципе я наскока понимаю ситуацию - разрядность не влияет на скорость запуска системы или приложений. По идее (наскока помню наших преподов любимых  )  должна была б давать прирост в операциях типа кодирования видео, аудио и криптографии. Ну за криптографию я не скажу, а вот с обработкой аудио/видео ничего не изменилось. Может кто (кому не лень ) померяет на нынешних версиях дистрибах разницу в компрессии файлов, изготовлению mp3, ogg, acc, mpg и т.д. в зависимости от разрядности. Вообще же наскока я понимаю ситуацию  - на скорость работы больше влияет оптимизация ядра (не в плане разрядности, а выкидывания всего лишнего из конфига - а по умолчанию там мусора не мало - фиг ли на все случаи жизни собирают), стартовые скрипты.
З.Ы. Небольшой оффтоп - поздравляю - с нашим спором Вы стали фулл мембером