32 vs 64

Почему собрать под целевую платформу это задротcтво?

> А какие проблемы в Gentoo с 32-битными библиотеками?

Нет libsane.

>>Занавес

Ты в театре?

Кажется, да.

Надо _всю_ систему с ним пересобирать и всё равно будет медленнее чем на современных процах.

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

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

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

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

>>> Кста, хеш таблицы выровнены по степени 2.

Не всегда.

Как так? Не встречал такого.

Повстречай: http://en.wikipedia.org/wiki/Hash_table#Separate_chaining_with_list_heads

>Пока не изобрели dos2gw в dos'е такие пляски с бубном устраивали, чтобы заюзать всю память
Вопрос в том для чего использовать, для адресации или вычислений.

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

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

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

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

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

нет

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

> Нафига такое извращение?

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

>и, следовательно, постоянных spill/fill
Не знаю что это, гугел не помогает.

>Для повышения производительности.
Каким макаром?

Не важно для чего. В 32х битном режиме было и проще и быстрее.

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

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

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

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

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

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

>Не важно для чего. В 32х битном режиме было и проще и быстрее.
Важно, если большую часть времени что-то висит без дела.

> Важно, если большую часть времени что-то висит без дела.

Что именно у тебя там висит? :)

Не важно, так как программировать проще и нет тормозящей косвенной адресации.

Ты сам-то понимаешь что это за spill/fill? Или нахватался вумных словцов и теперь сам стал вумным?

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

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

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

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

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

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

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

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

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

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

Тут много кто знает что такое spill/fill?

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

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

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

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

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

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

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

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

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

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

> Если ты не можешь ответить на простой вопрос, значит не знаешь.

Мне не интересно разжевывать сюда тривиальные вещи.

>Мне не интересно разжевывать сюда тривиальные вещи.
Ну а мне просто лениво читать, то что мне не интересно.

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

dos4gw

Фи, трололо, которое даже ленится читать.

Убойный аргумент против 32 бит: http://ru.wikipedia.org/wiki/Проблема_2038_года

>Тут много кто знает что такое spill/fill?

Это понятно даже из значения словей.
На х86 это как правило сводится к push/pop

Когда-то Билл Гейтц всех пугал «проблемой 2000».

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

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

>что мешает увеличить размер time_t до 64 бит

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

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

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

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

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

По ссылке бред школьника.

annulen> Убойный аргумент против 32 бит: http://ru.wikipedia.org/wiki/Проблема_2038_года

http://www.linux.org.ru/jump-message.jsp?msgid=112256&cid=112965

Какие таки бонусы?

Самый главный это 64х битная адресация.

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

Проблемы абстрактного юзера в вакууме меня не 2.71бут. А меня лично как юзера это волнует.