Есть ли улучшение пропускной способности от установки 32-разрядной операционной системы на 64-разрядной машине? - PullRequest
5 голосов
/ 31 октября 2008

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

Мой вопрос: можно ли избежать этой проблемы, установив 32-разрядную операционную систему на 64-разрядную машину? И есть ли тесты с высокой пропускной способностью, которые демонстрируют преимущество в этом случае?

Ответы [ 4 ]

6 голосов
/ 31 октября 2008

Пропускная способность здесь не совсем правильный термин. То, о чем на самом деле говорил Кнут, это плотность данных, поскольку она связана с размером кеша. Представьте, что у вас есть кэш данных L1 размером 16 КБ: если вы храните только указатели, вы можете хранить 2 ^ 14/2 ^ 2 = 2 ^ 12 = 4096 32-разрядных указателей, но только 2048 64-разрядных указателей. Если производительность вашего приложения зависит от возможности отслеживать более 2 КБ разных буферов, вы можете увидеть реальное преимущество в производительности благодаря 32-разрядному адресному пространству. Однако в большинстве случаев настоящий код работает не так, и реальная выгода от производительности системы кеширования часто достигается за счет возможности кэшировать обычные целочисленные структуры данных и структуры данных с плавающей запятой, а не огромное количество указателей. Если ваш рабочий набор не перегружен указателями, обратная сторона 64-битной системы становится незначительной, а обратная сторона становится намного более очевидной, если вы выполняете большую 64-битную целочисленную арифметику.

4 голосов
/ 31 октября 2008

Я не думаю, что Кнут возражал против 64-битных систем. Он только что сказал, что использование 64-битных указателей в системе с оперативной памятью менее 4 ГБ - идиотизм (по крайней мере, если у вас много указателей, подобных указанным в двойном списке). Я не могу сказать, что я согласен с ним, вот 3 различных способа, которыми можно воспользоваться. Предположим, у вас есть 64-битный процессор, который также может работать в 32-битном режиме, как некоторые Intel Core Duo.

1 - все 32-битное, ОС, APPZ, все они. Таким образом, у вас есть 32-разрядные указатели, но вы не можете использовать дополнительные регистры / инструкции, доступные в 64-разрядном режиме.

2 - все 64-битное, ОС, APPZ, все они. Таким образом, у вас есть 64-битные указатели, и вы можете использовать дополнительные регистры / инструкции, которые доступны в 64-битном режиме. Но так как у вас меньше 4 ГБ оперативной памяти, использование 64-битных указателей кажется идиотским. Но так ли это?

3 - ОС является 64-битной, и ОС интересно следит за тем, чтобы все указатели кода / данных находились в диапазоне 0x00000000 - 0xFFFFFFFF (Виртуальная память !!!). ABI работает очень странным образом: все указатели кода / данных, хранящиеся в памяти / файлах, имеют 32-разрядную ширину, но загружаются в 64-разрядные регистры как расширенные нулями. Если есть место для кода для перехода, компилятор / ABI выполняет необходимые исправления и выполняет фактический 64-разрядный переход. Таким образом, указатели являются 32-разрядными, но APPZ может быть 64-разрядным, что означает, что они могут использовать 64-разрядные регистры и инструкции. Я думаю, что этот процесс похож на thunking; -P

Мой вывод таков: *

Третий вариант показался мне выполнимым, но это не простая проблема. Теоретически это может работать, но я не думаю, что это возможно. И я также думаю, что его цитата «Когда такие значения указателя появляются внутри структуры, они не только тратят впустую половину памяти, они эффективно отбрасывают половину кэша». преувеличено ...

4 голосов
/ 31 октября 2008

Ответ: да, это может в определенной степени, хотя разница в производительности вряд ли будет большой.

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

2 голосов
/ 31 октября 2008

Я где-то видел, что лучшее сочетание (на процессорах x86) - это использовать 64-битную ОС и 32-битные приложения.

с 64-битной ОС вы получаете:

  • способность обрабатывать более 4 ГБ адресного пространства
  • больше, большие регистры, помогающие в операциях копирования данных

с 32-битным приложением вы получаете:

  • меньшие указатели
  • меньше, меньшие регистры для экономии на переключателях контекста

минусы:

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

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

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

и нет, меня не волнует это небольшое ускорение. но это не «обижает» меня на запуск 32-битного FireFox на 64-битной машине KUbuntu (как я видел на некоторых форумах)

...