А>>Во первых — какие индексы?
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