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

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

Можно вообще написать программу, которая будет работать в обеих ОС (32 и 64) используя "нативную" разрядность?
Или два exe-файла обязательны?

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

Где вообще почитать детальное описание отличий этих версий и "почему так"?

Здравствуйте, hurik, Вы писали:

H>Просьба подсказать по такому вопросу.
H>Раньше никогда особо не задумывался, не было необходимости.

H>Если я хочу поставить WinXP 64-х битную, это отдельный дистрибутив? По другим операционкам тоже самое?
H>Почему такая разница, в один запихнуть никак нельзя было?
Потому что это увеличит размер дистрибутива в 2 раза, что мало кому надо.

H>Можно вообще написать программу, которая будет работать в обеих ОС (32 и 64) используя "нативную" разрядность?
H>Или два exe-файла обязательны?
32-разрядные программы будут работать в 64-разрядных ОС. Но 64-разрядные программы будут там работать быстрее. Можно запускать 32-разрядный EXE-шник и из него запускать 64-разрядный на x64-операционках.

H>Если программа скомпилирована для обеих версий, как правильнее всего определять версию операционки на
H>которой программа запускается и значит запускать подходящий модуль?
IsWow64Process()

H>Где вообще почитать детальное описание отличий этих версий и "почему так"?
WOW64 в MSDN

Здравствуйте, hurik, Вы писали:

К тому что сказал bazis1 можно добавить, что WOW64 — среда исполнения 32-разрядного софта на 64-битной платформе.
Точно также как на 32-разрядных любое 16-разрядное приложение исполняется в среде WOW16.

Здравствуйте, bazis1, Вы писали:

B>32-разрядные программы будут работать в 64-разрядных ОС. Но 64-разрядные программы будут там работать быстрее.

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

Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, bazis1, Вы писали:

B>>32-разрядные программы будут работать в 64-разрядных ОС. Но 64-разрядные программы будут там работать быстрее.

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

Здравствуйте, hurik,

H>Можно вообще написать программу, которая будет работать в обеих ОС (32 и 64) используя "нативную" разрядность?
H>Или два exe-файла обязательны?

Я думаю что теоретически это возможно, но не рекомендуется. Вот ответ на этот вопрос от Raymond Chen, разработчика из Microsoft.

Здравствуйте, hurik, Вы писали:
H>Можно вообще написать программу, которая будет работать в обеих ОС (32 и 64) используя "нативную" разрядность?
H>Или два exe-файла обязательны?

Конечно. Используйте интерпретируемые языки или компилирующиеся в платформонезависимый байткод. Естественно, рантайм или интерпретатор должен быть собран под соответсвующую платформу.

Здравствуйте, Pzz, Вы писали:

Pzz>Вовсе не факт, что быстрее. 64-битные программы используют больше памяти для тех же целей, а память — штука медленная.

Выдержка из книги "Windows via C/C++, Fifth Edition" (Jeffrey Richter):
"For backward compatibility, 64-bit Windows can execute 32-bit applications. However, your application's performance will improve if the application is built as a true 64-bit application."
Так что, если хочется увеличить перформенс в 64-битных системах, будьте добры скомпилировать программу в 64-битный код.
Приведённый аргумент "64-битные программы используют больше памяти для тех же целей" в конктексте производительности высосан из пальца. Ваша 32-битная программа всё равно исполняется в 64-битной системе, к тому же под WOW64, что само по себе — снижение производительности.

p.s.
Прошу обратить внимание на сий пост и товарища "vayerx", который не думая раскидывает минусики/плюсики.

Здравствуйте, rastoman, Вы писали:

R>Выдержка из книги "Windows via C/C++, Fifth Edition" (Jeffrey Richter):
R>"For backward compatibility, 64-bit Windows can execute 32-bit applications. However, your application's performance will improve if the application is built as a true 64-bit application."

В некоторых случаях 64 бита будет быстрее, в некоторых — медленнее, в некоторых вы вообще не почуствуете разницу. Зависит от того, об какое место программа тормозит.

Я вообще не понимаю этого способа дискуссии, "а вот в умной книжке написано". Чем умную книжку мне в морду тыкать, возьмите и померьте, тогда будет тема для разговора.

Здравствуйте, Pzz, Вы писали:

Pzz>В некоторых случаях 64 бита будет быстрее, в некоторых — медленнее, в некоторых вы вообще не почуствуете разницу. Зависит от того, об какое место программа тормозит.
Pzz>Я вообще не понимаю этого способа дискуссии, "а вот в умной книжке написано". Чем умную книжку мне в морду тыкать, возьмите и померьте, тогда будет тема для разговора.

Офигеть... Предполагая, что слова Рихтера будут несколько весомее моих, я и привёл цитату из его труда. Что ж, раз мои слова важнее, сообщу следующее:
1. Мерял.
2. Скорость выполнения 64-битного кода в 64-битной среде (Windows 2008 Ent SP1 x64) оказалась выше, чем 32-битного в этой же среде.
3. Измерялись специфичные(критичные) для задачи куски кода.

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

Здравствуйте, rastoman, Вы писали:

R>Офигеть... Предполагая, что слова Рихтера будут несколько весомее моих, я и привёл цитату из его труда. Что ж, раз мои слова важнее, сообщу следующее:

Конечно ваши слова важнее: вам можно задать уточнающий вопрос, Рихтеру — нет

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

Вы на каких задачах мерили — вычислительных, memory bound, i/o bound, ...?

Здравствуйте, rastoman, Вы писали:

R>Расскажите, пожалуйста, в каких случаях эффект обратный

Самое узкое место в процессоре — пропускная способность шины памяти. Поэтому, например, 4х байтные индексы могут оказаться быстрее 8ми байтных поинтеров, несмотря на бОльшее кол-во вычислений.

Самое узкое место в системе — пропускная способность канала RAM <-> HDD. Своппинг бОльшего по размеру кода и данных (64) окажется медленне.

На последок, риторический вопрос к размышлению: кто сочинял анонсы о бенефитах от 64 бит, сейлзы, либо технари?

Здравствуйте, Pzz, Вы писали:

Pzz>Вы на каких задачах мерили — вычислительных, memory bound, i/o bound, ...?
Задача использовала смешанные алогритмы. На вход подавались разнородные данные большого объёма. Измерялось user time/kernel time процесса, затраченного на обработку потока данных.
Тестирование конкретных алгоритмов не проводилось. Результаты теста, к сожалению не сохранились.

Здравствуйте, rastoman, Вы писали:

Pzz>>Вы на каких задачах мерили — вычислительных, memory bound, i/o bound, ...?
R>Задача использовала смешанные алогритмы. На вход подавались разнородные данные большого объёма. Измерялось user time/kernel time процесса, затраченного на обработку потока данных.
R>Тестирование конкретных алгоритмов не проводилось. Результаты теста, к сожалению не сохранились.

Если у вас задача тормозит в основном о системные вызовы, то понятно, что исключение из пути wow64 может дать некоторое ускорение (то, что это ускорение заметно, говорит о плохой реализации самой wow64, т.к. содержательно эта подсистема ничего не добавляет, и в принципе должна бы быть "тонкой").

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

Любопытно что у линуха нет никакого эквиавалента wow64. Сисколы из 32 и 64-битных программ обрабатываются вполне "параллельно" до того места, где начинается уже содержательный общий код. Поэтому я не ожидал бы под линухом какого-то специфического оверхеда в том случае, когда 32-битная программа исполняется под управлением 64-битного ядра. Это вот — преимущество архитектуры с очень маленьким количеством системных вызовов.

Pzz>>>Вы на каких задачах мерили — вычислительных, memory bound, i/o bound, ...?
R>>Задача использовала смешанные алогритмы. На вход подавались разнородные данные большого объёма. Измерялось user time/kernel time процесса, затраченного на обработку потока данных.
R>>Тестирование конкретных алгоритмов не проводилось. Результаты теста, к сожалению не сохранились.
Pzz>Если у вас задача тормозит в основном о системные вызовы, то понятно, что исключение из пути wow64 может дать некоторое ускорение (то, что это ускорение заметно, говорит о плохой реализации самой wow64, т.к. содержательно эта подсистема ничего не добавляет, и в принципе должна бы быть "тонкой").
Она и так достаточно тонкая. Просто по другому раскладываются аргументы на стеке и вызывается системный сервис.

Pzz>Вычислительные задачи скорее всего что-то проиграют, т.к. будут вынуждены ворочать 64-битными данными там, где хватило бы и 32 бит. Кроме того, если я не ошибаюсь, 64-битные опкоды в среднем более длинные, что приводит к некоторому увеличению объема кода, и опять же не способствует ускорению программы.
Заметно что вы плохо знаете х64. Никто не заставляет вас там "ворочать 64-битными данными". Более того — int в родном мс компиляторе все такой же 32х-битный. Если возьмете среднюю 32 битную прогу и перекомпиляете в х64 — 64 битными станут лишь указатели. Более того — 64битными станут лишь те указатели, которые выходят за пределы текущего модуля. Фишка в том что в х64 многие инструкции работы с памятью расширены возможностью относительной адресации. Типа вместо mov eax, [some ptr] теперь будет mov eax, [rip + some ptr]. Где eax — все тот же 32битный регистр (младшая половинка rax), а some ptr — 32битное смещение относительно самой инструкции. А поскольку модули в РЕ формате ограничены размером 2 гига — то по сути 64хбитными указателями адресуются лишь указатели на данные/код из других модулей. Остальное — остается 32битными с 32битными инструкциями, если вы только в коде явно не указали что хотите не int а __int64. Присвоение 64битного значения из памяти будет mov rax, [rip + some ptr] где some ptr — все тоже 32битное смещение.

Добавлю, т.к. анинимные посты низзя редактировать — все таки изучите подробно х64. Она довольно экономно спроектирована. Гораздо экономнее IA64 где действительно получается арифметически 2х-кратное увеличение всего.

Есть еще один нюанс: инструкции х64 в среднем больше, чем х32, значит, кеш используется менее эффективно. Проявляется это не часто (ибо кеши сейчас большие), но разработчикам помнить об этом нужно.

R>>Расскажите, пожалуйста, в каких случаях эффект обратный
GN>Самое узкое место в процессоре — пропускная способность шины памяти. Поэтому, например, 4х байтные индексы могут оказаться быстрее 8ми байтных поинтеров, несмотря на бОльшее кол-во вычислений.
Во первых — какие индексы?
Во вторых — какое отношение размер указателя в виртуальной памяти имеет к пропускной способности физической шины памяти, которая имеет фиксированную ширину, и от разрядности операционки никак не зависит? Скорость упадет от количества хранимых данных, но никто не заставляет вас на х64 держать в памяти больше данных.

Здравствуйте, <Аноним>, Вы писали:

А>Во первых — какие индексы?

Абстрактные, а какие еще бывают? Главное, что их размер меньше чем у поинтера в 2 раза. Например, вместо указателя на элемент массива можно хранить его номер.

А>Во вторых — какое отношение размер указателя в виртуальной памяти имеет к пропускной способности физической шины памяти, которая имеет фиксированную ширину

Отношение — пропорция из средней школы, если размер поинтера в 2 раза бОльше, то таких элементов через ту же шину пройдёт в 2 раза меньше.

А>, и от разрядности операционки никак не зависит?

Это конечно оффтоп, но разрядность шины косвенно присутствует в аппаратных требованиях для ОС.

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

Да, данных (поинтеров) будет столько же, но объём занимаемой ими памяти возрастёт в 2 раза.

Добавлю несколько своих копеек в эту дискуссию.
Андрей Карпов. Оптимизация 64-битных программ
Аннотация. В статье рассмотрен ряд способов повышения производительности 64-битных Windows приложений.