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

Если я хочу поставить 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 приложений.

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

А>>Во вторых — какое отношение размер указателя в виртуальной памяти имеет к пропускной способности физической шины памяти, которая имеет фиксированную ширину
GN>Отношение — пропорция из средней школы, если размер поинтера в 2 раза бОльше, то таких элементов через ту же шину пройдёт в 2 раза меньше.
Через шину пойдет ровно столько какой размер шины. Шина — параллельная. Сколько то там проводков на плате. И как они используются совершенно не зависит от режима работы процессора.

А>>, и от разрядности операционки никак не зависит?
GN>Это конечно оффтоп, но разрядность шины косвенно присутствует в аппаратных требованиях для ОС.
Повторяю — разрядность аппаратной шины НЕ меняется в зависимости от того какую версию ОС исполняет процессор. Т.е. если у вас больше 4GB памяти, которые ХР х32 не юзает — просто по старшим адресам линии каждый раз будут передаваться нулики в каждой транзакции и все. Разрядность аппаратной шины конечно может быть разной на разных железках. Но если у вас есть железка на которой может работать 64битная ось — запуск на этой железке 32битной оси ровным счетом ничего не сделает с шиной. Разрядность ОС это вещь сугубо абстрагированная на уровне процессора, и на остальное железо никак не влияющая, являясь по сути просто набором дополнительных команд которые использует или не использует исполняемая программа.

А>> Скорость упадет от количества хранимых данных, но никто не заставляет вас на х64 держать в памяти больше данных.
GN>Да, данных (поинтеров) будет столько же, но объём занимаемой ими памяти возрастёт в 2 раза.
Поинтер это не данные. Поинтер — это указатель на данные. Т.е. конструкция
void *ptr = malloc(1000);
в идеальном случае (при отсутствии оверхеда на менеджер памяти etc) на x86 потребует 1004 байта а на х64 — 1008.
А код типа

static int src[1000];
int i = src[index];

На х64 потрубует на 1 или 2 байта, потому что src и код который его использует находятся в одном модуле-> в этом случае используется относительная 32хразрядная адресация. Как и в случае вызовов методов объектов родного модуля etc.

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

А>Через шину пойдет ровно столько какой размер шины. Шина — параллельная. Сколько то там проводков на плате. И как они используются совершенно не зависит от режима работы процессора.

Вот именно, количество проводков постоянно. И по этому количеству пройдёт либо N*32 бит, либо M*64. Как отностится N к M?

А>Поинтер это не данные. Поинтер — это указатель на данные.

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

А>>Через шину пойдет ровно столько какой размер шины. Шина — параллельная. Сколько то там проводков на плате. И как они используются совершенно не зависит от режима работы процессора.
GN>Вот именно, количество проводков постоянно. И по этому количеству пройдёт либо N*32 бит, либо M*64. Как отностится N к M?
Вы проигнорировали мое предыдущее сообщение. По этому количеству проводков всегда пойдет ровно столько бит, сколько есть этих самых проводков. То есть не N*32, и не на большинстве железа N*64. А N*ширину шины. То что процессор исполнит инструкцию-обращение по 32хразрядному _виртуальному_ адресу, котороый предположим оттранслируется VMM в физический, укладывающийся в 32 бита, просто значит что по более старшим битам шины будут переданы нолики. Но это ведь тоже биты И от того что передается по проводку — нолик или единичка — высокий уровен или низкий скорость транзакции не поменяется.
Говоря другими словами, пусть мы имеем щирину физической шины 48 бит (не удивляйтесь, что не 64), и тупой VMM, работающий в режиме прямой трансляции виртуальных адресов в физические:
При исполнении инструкции
mov eax, 0xffffffff
mov [eax], edi
по физической шине пройдет обращение по адресу 0x0000ffffffff

А при исполнении
mov rax, 0xffffffffffff
mov [rax], edi
по физической шине пройдет обращение по адресу 0xffffffffffff

Единственное чем будут отличаться эти 2 инструкции с точки зрения осциллографа (гипотетического) подключенного к шине это лишь _значениями_ переданных адресов
А если будет такой код:

При исполнении
mov rax, 0xffffffff
mov [rax], edi
То с "точки зрения" осциллографа на шине он будет полностью эквивалентен самому первому варианту.

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

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

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

void* pointersArray[1000000];

Дело в том, что в размер занятой памяти вот таким вот псевдо-объявлением:

x86
sizeof(pointersArray) == 4000000;

x64
sizeof(pointersArray) == 8000000;

Скорость обмена данными между процессором и памятью действительно мала. Если в первом случае, для обработки всего массива указателей, по шине придётся прогнать примерно 4 Мб, то во втором — в два раза больше, т.е. 8 Мб.
Только вот думается мне, что проблема эта вся надуманная. Мне сложно представить реальную задачу, для решения которой понадобится оперирование большим объемом указателей. Настолько большим, что бы даже кеши процессора не спасли. Чаще используется базовый адрес блока памяти фиксированной длины и набор(таблица) смещений в нём, а не прямые адреса на виртуальную память процесса.

Так что единственный вывод, какой могу сделать — я делал отдельные сборки для x64 и делать их буду, т.к. пока не решал в жизни задач, потенциально менее производительных в x64, чем в x86... Но, всё же, буду иметь ввиду.

Здравствуйте, <Аноним>, Вы писали:
и другие тоже
А>Вы проигнорировали мое предыдущее сообщение. По этому количеству проводков всегда пойдет ровно столько бит, сколько есть этих самых проводков. То есть не N*32, и не на большинстве железа N*64. А N*ширину шины.

Я и остальное "проигнорирую". Потому что через шину проходит "1*ширину шины" бит. Если шина 128 бит, можно сгрупировать: 2*64ти битных или 4*32х битных поинтера. Что может быть дальше, читать здесь

Автор: rastoman
Дата: 14.01.09

GN>Здравствуйте, <Аноним>, Вы писали:
GN>и другие тоже
А>>Вы проигнорировали мое предыдущее сообщение. По этому количеству проводков всегда пойдет ровно столько бит, сколько есть этих самых проводков. То есть не N*32, и не на большинстве железа N*64. А N*ширину шины.
GN>Я и остальное "проигнорирую". Потому что через шину проходит "1*ширину шины" бит. Если шина 128 бит, можно сгрупировать: 2*64ти битных или 4*32х битных поинтера.
У вас бурная фантазия. Это какой то гибрит последовательной и параллельной шин полечается. Проблема в том, что FSB не является такой. За одну транзакцию передается только один адрес, хоть убейтесь.

GN> Что может быть дальше, читать здесь

Автор: rastoman
Дата: 14.01.09

То что там написанро вообще не имеет отношения к тому, о чем мы спорим.

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

GN>> Что может быть дальше, читать здесь

Автор: rastoman
Дата: 14.01.09

А>То что там написанро вообще не имеет отношения к тому, о чем мы спорим.

Здаётся мне, что спорите вы о немного разных вещах, потому и не можете прийти к общему мнению.

GN>>> Что может быть дальше, читать здесь

Автор: rastoman
Дата: 14.01.09

А>>То что там написанро вообще не имеет отношения к тому, о чем мы спорим.
R>Здаётся мне, что спорите вы о немного разных вещах, потому и не можете прийти к общему мнению.
Ну я спорю о том , что неважно по какому физ. адресу памяти происходит обращение. Т.к. с точки зрения контроллера памяти длина адреса любой транзакции с памятью фиксирована и равна количеству адресных линий FSB. Более того — количество данных вытягиваемое при этой транзакции так же фиксировано, не помню правда точно сколько, но точно больше чем 64 или 32 бит. Даже если процессору понадобится всего 1 байт.

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

А>Это какой то гибрит последовательной и параллельной шин полечается.

Последовательная шина — я так понимаю одна сигнальная линия используется, при чём здесь это? В том то и дело, что в твоих рассуждениях все намешано — разрядность ОС, виртуальная память зачем то... Скорость — в данном случае количество информации за единицу времени, поскольку результат оказывается неверный, для простоты выявления ошибки, я убрал время и предлагаю расмотреть ШД в статике. Пусть это будет 128 линий. То есть 2 "длинных" или 4 "обычных" поинтеров. Теперь можено домножать это на любое количество тактов и продолжать доказывать что количество переданных поинтеров не будет зависить от их разрядности.

А> Проблема в том, что FSB не является такой. За одну транзакцию передается только один адрес, хоть убейтесь.

Адреса по шине адреса передаются, мы про другую шину (данных) говорим. Пусть даже если они совмешены в железе.

А>То что там написанро вообще не имеет отношения к тому, о чем мы спорим.

Я на эту тему и при зашите с преподом не спорил, а программистов этому, к сожалению, не учат, уж извините за бестактность.

А>>Это какой то гибрит последовательной и параллельной шин полечается.
GN>Последовательная шина — я так понимаю одна сигнальная линия используется, при чём здесь это? В том то и дело, что в твоих рассуждениях все намешано — разрядность ОС,
Последовательная шина — это когда транзакция "размазана" на несколько стробов по времени
FSB — параллельная и использовать "лишние" не умееь
GN>виртуальная память зачем то...
Виртуальная память при том, что начиная с Р6 (пентиум про) физическая шина адреса имеет ширину 36 бит, и 32 битные виртуальные адреса транслируются в 36битные физические. И совершенно неважно при этом говорить что всем-известная-ОС просто не пользуется ее старшими 4мя битами, начиная с СП2. Потому вообще говоря даже говорить о том что в физическую шину пихается 32хразрядный указатель некорректно.

>Скорость — в данном случае количество информации за единицу времени, поскольку результат оказывается неверный, для простоты выявления ошибки, я убрал время и предлагаю расмотреть ШД в статике. Пусть это будет 128 линий. То есть 2 "длинных" или 4 "обычных" поинтеров. Теперь можено домножать это на любое количество тактов и продолжать доказывать что количество переданных поинтеров не будет зависить от их разрядности.
Скорость — это время за которое исполняется mov [rdi], eax или mov [edi], eax. Так вот оно одинаково на одинаковом железе. И лишние по вашим вредставлениям линии никак не могут использоваться для каких либо других целей кроме посылки по ним нулей.


А>>То что там написанро вообще не имеет отношения к тому, о чем мы спорим.
GN>Я на эту тему и при зашите с преподом не спорил, а программистов этому, к сожалению, не учат, уж извините за бестактность.
А я вообще программированию не учился. Физик я по образованию

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

А>Последовательная шина — это когда транзакция "размазана" на несколько стробов по времени

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

А>FSB — параллельная и использовать "лишние" не умееь

Предлагаю разобраться для начала с моей упрощенной схемой, где нет ни FSB, ни другого лишнего.

А>Физик я по образованию

Вот и представь, что появляется некто программист и начинает доказывать, что Солнце яко бы не черное, какие будут действия?

А>>Последовательная шина — это когда транзакция "размазана" на несколько стробов по времени
GN>Если продолжать в таком духе, то можно показать, что любая шина является последовательной.
Нет. Ключевое слово транзакция — передача блока данных по определенному адресу. Так вот за одно транзакцию (за один фронт импульса в FSB/DDR) можно обратиться только к одному такому блоку. И размер его кстати фиксирован.

А>>FSB — параллельная и использовать "лишние" не умееь
GN>Предлагаю разобраться для начала с моей упрощенной схемой, где нет ни FSB, ни другого лишнего.
Я писал парой сообщений выше. Ваша упрощенная съема с передачей двух адресов используя одну адресную шину большей ширины чем вы хотите обратиться за одну транзакцию не укладывается с реальным положением вещей.

А>>Физик я по образованию
GN>Вот и представь, что появляется некто программист и начинает доказывать, что Солнце яко бы не черное, какие будут действия?
Ну раз скатились на демагогию... Солнце является очень хорошей моделью абсолютно черного тела. Спорить будете?

А>>>Физик я по образованию
GN>>Вот и представь, что появляется некто программист и начинает доказывать, что Солнце яко бы не черное, какие будут действия?
А>Ну раз скатились на демагогию... Солнце является очень хорошей моделью абсолютно черного тела. Спорить будете?
"Среди тел Солнечной системы свойствами абсолютно чёрного тела в наибольшей степени обладает Солнце. "
(c) http://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%BA%D0%BE%D0%BD_%D0%92%D0%B8%D0%BD%D0%B0
я шучу конечно же, но в каждой шутке... Мораль в том что не всегда кажущийся самый простой здравый смысл оказывается самым верным

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

А>Ключевое слово транзакция — передача блока данных по определенному адресу.

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

А> Так вот за одно транзакцию (за один фронт импульса в FSB/DDR) можно обратиться только к одному такому блоку. И размер его кстати фиксирован.

И в моем примере был выбран блок размером 128 бит.

А>Я писал парой сообщений выше. Ваша упрощенная съема с передачей двух адресов используя одну адресную шину большей ширины чем вы хотите обратиться за одну транзакцию не укладывается с реальным положением вещей.

Давай разбираться с адресами. Поскольку речь о шинах между ЦП и ОЗУ, то адресом называется номер физической ячейки памяти. К типу процессора это отношения не имеет. Контроллер памяти получает его по шине адреса, генерирует всякие RAS/CAS (для DRAM) — все эти моменты неинтересны, для простоты можно считать что шина адреса имеет бесконечную пропускную способность (а на практике это почти так, учитывая возможность передачи блоков данных).

Поэтому в моей схеме использовалось слово "поинтер" — логическая интерпретация тех 0й и 1ц, что будет выставлена на шину данных после получения номера ячейки по шине адреса — фиксированный блок в 128 бит. То есть 2 64х разрядных поинтера или 4 32х разрядных, в единицу времени. Потом ПЦ проинтерпретирует эти данные, выставит значение поинтера (возможно после табличных преобразований, как в случае с виртуальной\физической памятью) на шину адреса и начнет ждать данные — это всё опять не интересно, поскольку не влияет на производительность. Влияет то, что количество переданных за единицу времени 64ти битных данных всегда в 2 раза меньше, чем 32х битных, при той же ширине шины, поскольку в обоих случаях передача идет по 128 бит.

А>Ну раз скатились на демагогию... Солнце является очень хорошей моделью абсолютно черного тела. Спорить будете?

К тому и веду, что у нас никакой не спор

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

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

Вот что вышло у меня (на сервере). Unix Bench 4.1.0-wht.2. Больше — лучше.

TEST                                        BASELINE  RESULT-64  RESULT-32   INDEX-64   INDEX-32

Dhrystone 2 using register variables        376783.7 17372160.2 18026866.1      461.1      478.4
Double-Precision Whetstone                      83.1     2516.0     2337.3      302.8      281.3
Execl Throughput                               188.3     6971.3    16801.8      370.2      892.3 <-
File Copy 1024 bufsize 2000 maxblocks         2672.0   130451.0   121827.0      488.2      455.9
File Copy 256 bufsize 500 maxblocks           1077.0    39683.0    39832.0      368.5      369.8
File Read 4096 bufsize 8000 maxblocks        15382.0   882821.0   867809.0      573.9      564.2
Pipe-based Context Switching                 15448.6   449286.0   422322.4      290.8      273.4
Pipe Throughput                             111814.6  1615346.6  1249083.6      144.5      111.7
Process Creation                               569.3    20961.1    31867.5      368.2      559.8 <-
Shell Scripts (8 concurrent)                    44.8     1101.6     1136.9      245.9      253.8
System Call Overhead                        114433.5  2846590.5  1866794.9      248.8      163.1
                                                                            =========  =========
     FINAL SCORE                                                                330.0      344.4

Почему-то 32-битный вариант значительно быстрее делает fork/exec, остальное примерно на том же уровне.

model name      : AMD Athlon(tm) 64 X2 Dual Core Processor 5600+
stepping        : 3
cpu MHz         : 1000.000
cache size      : 1024 KB