Linux 2.6, 32-разрядный + BIGMEM по сравнению с 64-разрядным Linux 2.6?
Вы могли установить Samba на виртуальной машине для доступа к сети со стороны Vista.
При использовании VMware для хостинга виртуальной машины, существует что-то названное совместно используемыми папками. Это могло бы также работать.
Самое чистое решение, конечно, состояло бы в том, чтобы использовать svn с обеих сторон.
в x86 процессорах 64-битный код помогает двум путям:
- большие адреса позволяют Вам доступ больше памяти непосредственно (только важный для процессов, которые управляют огромными наборами данных),
- больше регистров могло бы позволить компилятору уменьшить доступы памяти для трудных переменных (небольшая дополнительная оптимизация, непримечательная кроме жестких циклов очень оптимизированного кода).
и имеет следующие недостатки:
- больше и большие регистры означают больше состояния сохранять/восстанавливать на каждом контекстном переключении.
- большие указатели означают больше использования RAM и больших структур, больше данных к чтению-записи.
поэтому, в большом количестве случаев, лучшим из обоих миров является 64-разрядная ОС и 32-разрядные процессы:
- 64-разрядная ОС может обработать много RAM, и для содержания многих процессов и для больших кэшей
- 32-разрядные приложения ограничены 2 или 3 ГБ RAM для каждого процесса, но это достаточно для подавляющего большинства задач.
- неважно, где в 64-разрядном пространстве RAM 32-разрядной задачи расположена, этому только будут нужны 32-разрядные указатели для доступа к ее памяти, таким образом, все указатели и структуры данных будут все еще меньшим 32-разрядным разнообразием.
- 32-разрядная задача (процесс или поток) только должна сохранить/восстановить некоторых и небольшие регистры, доступные в 32-разрядном x86, 64-разрядный планировщик Linux обрабатывает этот случай хорошо.
но, всего, преимущество редко примечательно (просто предположение, что это были бы далеко меньше чем 5%), поэтому просто пойдите с 64-разрядным везде и получите все это более простое.
единственный случай, куда я определенно пошел бы с 32 на 64, при выполнении OpenVZ-отчасти изоляции. Тем путем каждый владелец раздела максимально использовал бы ограниченную RAM, к которой он может получить доступ.
тем не менее я не знаю ни о каком преимуществе PAE по 64-разрядному (даже небольшие указатели, так как каждый указатель PAE имеет 32-разрядное смещение, и дополнительное (до 32-разрядного) 'запускаются' (помните сегментированную память 8 086? какая загрузка чрезмерного увеличения размера!)
Помимо того, чтобы быть менее исчерпанным ресурсы регистром, x86_64 дает Вам более разумную операцию в секунду плавающих точек. Это также гарантирует, что Ваши двоичные файлы получили лучшие оптимизации, потому что компилятор никогда не должен был испускать назад совместимые коды операций. При выполнении чего-либо зависящего от ЦП это - большая победа.
PAE повреждает производительность. Единственное возможное усиление было бы то, что указатели являются половиной размера, но теперь необходимо иметь дело со свопингом страниц памяти вокруг.