У меня райд нормально работает 130 мб\сек

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

DenisMak, не противоречит. Банальная перекомпиляция 32->64 не приводит к ускорению. По крайней мере, те приложения, с которыми мне приходится иметь дело, не получили сколь-нибудь заметного ускорения.
Ускоряются те вещи, где программер 'руками' сделал эту оптимизацию.
Версия х64 чуть медленнее потому, что ростет размер кода. Посмотрите внимательнее, есть версии х32 и х64, тогда версия х64 будет в 1.5 раза больше. Т.е. процессору для выполнения той-же программы надо прокачать больше кода программы. Кроме того, при этом задейчтвуется больше cache. Были обзоры по сравнению производительности C2D от разного L2. Переход на x64, грубо говоря, означает, что у процессора стал L2 в 1.5 раза меньше. Отсюда и падение скорости. Чем более накручен код, тем вредоностнее переход на x64.

На JMicron переход на x64 снизил линейную скорость чтения с 130 до 125MB/s. Для маленьких блоков чуть хуже.
Впрочем, если сравнить хоть с Vista x32, то там и 120 не будет. Что тогда есть Vista х64?

компилятор сам задействует новые регистры (ну конечно можно на asm'е писать, но никто в здравом уме этим не занимается, в лучшем случае отдельные вставки спец кода). Действительно, особых преимуществ простая перекомпиляция не дает, я по крайней мере на своих программах не увидел, но и заметного падения производительности тоже нет, разница - мизер, преимущества архитектуры x64 съедаются возросшими накладными расходами (указатели к примеру в два раза больше места занимают). Какая-то особенная оптимизация которую можно сделать под x64, но глупые программеры не делают - миф, если в задаче требуется интенсивная работа с _int64, то только тогда и возрастет заметно производительность, в остальных случаях SIMD решает, хоть по 32битами хоть под 64, кропотливая переделка алгоритмов нужна только для использования многоядерности.

Основной бонус от x64 виндов - это более свободная работа с памятью, теперь процесс может получить сколько угодно памяти, а не только 2Гб (с бубном 3Гб), свободная адресация 4Гб и более.

serj
по твоей теории у атлонов кеша остаётся всего 384кб, а работают они быстрее корок смотрю ты плохо смыслишь в том о чём написал....
Добавлено спустя 18 минут, 26 секунд
progn
+1

Народ подскажите, купил 4гб оперативки, но видит почему только 3гб, в биосе при старте определяется 3000мб, в CPU-Z написано 4, т.е в каждом слоте есть модуль. Виндовс в свойствах показывает доступность только 2,93гб. В чём может быть проблема ?

Build 3790_srv_03_sp2

I_AM_BACK, что говорит BIOS после своей загрузки?
1. сколько памяти?
2. dual channel или flex?

Смотрите сами. Софт которы мы используем на 95-99% состоит из исключительно 32 биовых программ. Поэтому хорошо конечно что 64 битовые приложения все таки есть и они дают прирост - и в таком случае получится что на 95-99% программ прироста небудет или будет падение. А в 1-5% мы получаем прирост. вот мне и интересно зачем же тогда выбирать х64 виндоус? Вот ответте мне на этот вопрос. Или я чего не понимаю.
к сожалению больше на тесты у меня пока времени не было. но в ближайшее время как будет - проведу еще тестирование двух систем ХР и х64.
Добавлено спустя 6 минут, 58 секунд

Сомнительное преимущество мне как домашнему пользователю. у меня и на ХР все работает. хотя и не скажу чтобы супер отлично. Но более чем.

Смотрите пост выше

Вы меня извините, но протрите глаза что-ли. Я тестировал работу винчестеров в х64 среде и в х32. и разница не 1%, а 20сек на каждые 5.5мин. работы. Я проведу еще тесты винчестеров без рейда (чтобы исключить влияние рейда). Как будет время. это ой какая разница.
Добавлено спустя 4 минуты, 49 секунд

Ну программ на х64 немного. И потом какой смысл отказыватся от х32 программ ради горстки ускорения в х64? И получать торможение в х32?

Говорит 3008мб, v CPU-Z пишет дуал.

А вы как смотрели? Я тоже успел при копировании увидеть цифры с рейда на не рейд в 100мб в сек. Что самая что ни на есть ерунда. реальное тестирование на копирование это показало. Да и винчестер без рейда был бы на это неспособен. я говорю чтобы проверить работу винтов - собираюсь сравнить работу с блоком информации в режиме сата без рейда. тогда можно будет говори драйвер виноват или нет

Xmast, лично я это сделал для того, чтоб нормально работали 4G.
Потом, глядишь, будет порт на x64 .... но портировать asm на x64 'скучно'.

I_AM_BACK, что говорит BIOS - DUAL или FLEX?
Что говорит CPU-Z ты уже озвучил, я это понял.

И потом, ты включил remap в BIOS? (Вопросы? - тогда сюда. Очень подробно разобрано)

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

3

Я замерял время виндовыми часами с секундомером. Разве они для этого не подходят? время есть время. Чем его не замеряй. и важно кто делает быстрее. А не то что у кого то найдутся отмазы на
При замере производительности копирования никаких других задач на компьютере не выполнялось

3

Да хоть какие сервисы. на ход времени они не влияют. Это на х486 и менее компьютерах при долгой загрузке системный таймер начинал отставать. на современных такого нет.

3

Копирование 10495Мб с одного сата на другой дали один результат. 3 мин. 41сек. И то хорошо. Я уже и здесь ждал подвоха. Значит мой драйвер рейда не очень хорош.
но и выигрыша нет даже при использовании спид-командера х64.
какие нибудь дополнительные тесты проведу потом по возможности.

Подскажет можно ли как-нибудь добавить широкоформатные разрешение ниже родного? Чтобы можно было выставлять их в играх

пробовал в висе 32бит и XP x64 копировать (родным проводником) файл 12Гиг в Висте 2:23 в x64 XP - 2:02, но тут 100% тормозной проводник Висты виноват.