LINUX.ORG.RU

32 vs 64


1

0

Часто задают вопрос о том, какой вариант конкретного дистрибутива выбрать - 32-битный или 64-битный. Для того, чтобы облегчить выбор, в FAQ помещена статья на эту тему: www.linux.org.ru/wiki/en/32_или_64_бита Материал будет расширяться и дополняться. Свободные обсуждения - в этом топике.

★★★★★

Ответ на: комментарий от Booster

Потому что так 2.71баться придется на каждый чих. Нафига это нужно, если можно поставить нормальный бинарный 64х битный дистрибутив и сэкономить время, электричество и при этом получить дополнительные бонусы от 64х битной системы ?

Reset ★★★★★ ()
Ответ на: комментарий от Booster

> Пруф выше, если даже 16-разрядных достаточно, то что говорить о 64-разрядных.

Тяжелый случай. Пока не изобрели dos2gw в dos'е такие пляски с бубном устраивали, чтобы заюзать всю память. Это по твоему нормально?

Reset ★★★★★ ()
Ответ на: комментарий от Booster

> Да забудь ты про дополнительные регистры, производительность ими не определяется.

Сколько ж можно метанировать? %) Ты считаешь, что из-за нехватки регистров (и, следовательно, постоянных spill/fill) в теле «горячего» цикла не может потеряться 10-20-30 процентов производительности?

Manhunt ★★★★★ ()
Ответ на: комментарий от Booster

> Читать лень, по рисункам ничего такого не увидел. Поясни.

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

Manhunt ★★★★★ ()
Ответ на: комментарий от Manhunt

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

Booster ★★ ()
Ответ на: комментарий от Booster

>> и, следовательно, постоянных spill/fill

Не знаю что это, гугел не помогает.


Ужас какой. http://lmgtfy.com/?q=register+spill+fill

Для повышения производительности.

Каким макаром?


Ссылка на википедию с описанием такой хэш-таблицы была выше. Там объяснено, каким макаром.

Manhunt ★★★★★ ()
Ответ на: комментарий от Booster

> Ты сам-то понимаешь что это за spill/fill?

Естественно.

Или нахватался вумных словцов и теперь сам стал вумным?


Что характерно, ты ничего не нахватался, и словцов не знаешь. Знаний - ноль, за то пузыри на ЛОР-е пускаешь - только в путь :D Это типично для читателей xakep.ru ? :D

Manhunt ★★★★★ ()
Ответ на: комментарий от Booster

>> Ссылка на википедию с описанием такой хэш-таблицы была выше. Там объяснено, каким макар

Полагаю, что не сам не понимаешь нафига оно надо.


Серьезно? Откуда взялось такое предположение? :D

Manhunt ★★★★★ ()
Ответ на: комментарий от Booster

> Да не знаю. Но кое-кто я смотрю горазд прятаться за умными словцами и корчить из себя.

Кое-кто начитался gcc-шных списков рассылки, и плача разрабов gcc про маленькое количество x86-регистров. Но Booster с ЛОР-а, конечно же, гораздо авторитетнее инженеров АМД и авторов GCC. Booster смело заявляет нам, что производительности на дополнительные регистры начхать.

Что с тобой обсуждать-то, Незнайка?

Manhunt ★★★★★ ()
Ответ на: комментарий от Manhunt

>Что с тобой обсуждать-то, Незнайка?
А что с тобой всезнайка?

Кое-кто начитался gcc-шных списков рассылки, и плача разрабов gcc про маленькое количество x86-регистров.

Читай и дальше.

Booster ★★ ()
Ответ на: комментарий от Booster

>> Серьезно? Откуда взялось такое предположение? :D

Оттуда что на вопрос не вопрос не отвечаешь.


Зачем мне перепечатывать сюда википедию? Из-за твоего заявления, что тебе лень пройти по ссылке и прочитать?

Manhunt ★★★★★ ()
Ответ на: комментарий от Manhunt

>Зачем мне перепечатывать сюда википедию? Из-за твоего заявления, что тебе лень пройти по ссылке и прочитать?
Мне лень читать всю эту бодягу. Если ты не можешь ответить на простой вопрос, значит не знаешь.

Booster ★★ ()
Ответ на: комментарий от madcore

Под заумным термином spill/fill оказались банальные операции чтения/записи в память или кэш. То есть при наличии большего числа регистров какие-то данные можно долго не сохранять в память. Согласен, профит имеется.

Booster ★★ ()
Ответ на: комментарий от annulen

Во фряхе, к примеру, неактуально. И вообще, что мешает увеличить размер time_t до 64 бит? Кривые руки д*ов, которые где можно и нельзя писали int/unsigned int вместо time_t? На помойку такой софт вместе с авторами!

linuxfan ()
Ответ на: комментарий от Sylvia

>перекомпиливать придется все

Кэп, вы сегодня невероятно очевидны!

глюки вылезут обязательно

Большинство глюков уже успешно отловлено. Я намекаю на то, что почти все проблемы размерности переменных уже были выявлены во время появления x86_64. С тех пор прошло ого-го сколько лет.

linuxfan ()
Ответ на: комментарий от Reset

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

anonymous ()