32/64 разряда в чем цмес/смысл?

[rfund.livejournal.com]

Компьютерщики поясните плз. "попрастому" для лоха, Вот есть винда7я 32 разрядная, а есть 64х.
Суть разницы только в том. что первая видит до 2х гигов оперативы, а
64х более 2х? В этом ВСЯ разница?
Если на компе оперативы 2 гига (два ядра)(с) :-) То 64х нинужна ниразу?
А то не понимаю, зачем вообще ставят 64х винду то??
Может она быстрее в разы, чем 32?
PS
Использование компа такое:
В игры не играю/не ставлю их, фотошопом не пользуюсь,
ночью не храплю юзаю тока браузер и почту и фильмишки гатткие
смотрю на компе. Может поставить 64 разрядную?

Comments

[zakirov78.livejournal.com]

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

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

[ru-pchel.livejournal.com]

Знаете что такое указатель? Ну или хотя бы в C/C++
int* ptrCounter;
?
В 32-х разрядных программах указатели занимают 4 байта, в 64-х разрядных - 8 байт.

Соответственно, если мы программу перекомпилируем в 64-х битный режим (и считаем что программа запустилась и работает нормально) - программа будет больше по размеру.

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

Соот-но при том же размере кэша 32-х разрядный код будет работать быстрее, так как больше покрывается кэшом.

Да, можно жестко программу заоптимизировать в 64 бита, и она будет быстрее. Но, во первых, это делается только для очень малого класса программ. Они мало распространены, и очень дороги.
Короче редкость ;)

[zakirov78.livejournal.com]

хотите бодаться - хорошо.
да я знаю что такое С/C++ и даже знаю что такое байт (вы не поверите)

да. если вы перекомпилируете программу в 64 бита, то она будет длиннее. Но! в большинстве случаев она или ее процессороемкий цикл все равно влезет в кеш процессора. А ведь вы знаете что важно в данном случае? Попало все в кеш или нет - остальное неважно. А ваш 64 битный указатель, который вы так ругаете - будет сидеть как влитой в 64битном регистре ни тратя ни йоту дополнительных ресурсов.

Да, делается для малого класса программ, самых процессороемких и памятеемких - не спорю.

[ru-pchel.livejournal.com]

:) Да я даже не предполагал что вы знаете что такое байт. Это-то в нашу эпоху, когда любой человек отличает мегабиты от килобит. Модем от оптики.

А что такое процессороемкий цикл?
То есть вы утверждаете что весь код и все данные все равно влезут в кэш процессора? Типа как 640 кб хватит всем? ;)
А что вы таки путаете кэш и регистр? ;) Причем тут влитой ? ;) Вы меня удивляете.

[zakirov78.livejournal.com]

обычно все сложные вычисления находятся в циклах
например обработка последовательности байтов в изображении которое обрабатывается фильтром фотошопа (все упрощаю).

for () {
делаем что-то
}

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

вот это и есть процессороемкий цикл.

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

[ru-pchel.livejournal.com]

Хм. Я боюсь предположить. Вы аватары в фотошопе фильтрами обрабатываете?
Или все ж фотографии? Если фотографии, то они, в нынешнее время могут до десятков мегобайт быть. и 640 кб ну никак не хватит.

Вы действительно думаете что указатели только на начало памяти где изображение лежит?
Попробуйте какой-нибудь алгоритм написать один раз на C. Тогда вам откроется истина про указатели.
Ну или в ассемблер залезьте и посмотрите как часто данные передаются by value ;)

[zakirov78.livejournal.com]

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

зачем мне при сложной обработке изображения скажем... передавать данные by value
вы сами подумайте. у меня из сущностей - есть само изображение т.е. указатель на его начало. а все остальное можно вычислить через его битность и т.д. ну ладно пусть там доступ к памяти ограничен +-128 байт скажем - относительность. Это не сильно повлияет.

т.е. я тут даже представить не могу зачем мне доступ к памяти не относительно начала изображения или не относительн его частей.

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

[ru-pchel.livejournal.com]

зачем нужно множество указателей - сложные структуры данных.
Про все остальное - говорить смысла дальше не вижу.

[archaicos.livejournal.com]

Указатель-то длиннее, но мы же указатели не грузим в регистры все время, так, на что нам оптимизатор в компиляторе? Да и регистров-то больше вдвое в 64-х битном режиме, чем в 32-х битном. В итоге, если самих данных (а не указателей) столько же, мы ничего особо не проиграем, и наверняка выиграем за счет большего кол-ва регистров под вычисления.