Продолжаем мучиться фигней. Что же быстрее, 32-разрядный процессор или 64-разрядный?
Сейчас это можно относительно легко проверить, так как современные процессоры могут одновременно выполнять как те, так и другие приложения.
Кратко напомню достоинства и недостатки обоих вариантов.
Достоинства 64: 16 регистров общего назначения, большая разрядность данных, огромная адресуемая память.
Недостатки 64: в два раза более длинные указатели, что может существенно увеличить нагрузку на шину памяти.
У 32 разрядов достоинство по сравнению с 64, только одно: меньшая длина указателей, и соответственно, меньшая нагрузка на подсистему памяти.
И полно недостатков: 8 РОН, в два раза меньшая максимальная разрядность данных и всего 4 ГБайта адресуемой памяти.
Вот как думаете, если решаемая задача не требует огромной точности и не обрабатывает гигантские массивы информации, кто будет быстрее? Что победит, 16 РОН или меньшая загрузка шины памяти?
Я думаю дополнительные регистры 64-bit архитектуры должны быть более практичны, чем указатели меньшего размера:
ОтветитьУдалить- Кроме указателей есть и другие данные, размер которых остаётся таким же.
- Данные читаются не отдельными байтами, а страницами (вроде 64 байта), и значит далеко не всегда реально меньше байтов будет читаться.
Но в общем зависит от конкретной задачи. Оперативная память ведь тормоз по сравнению с кэшем процессора, и думаю можно придумать задачу когда при 32-х битах - кэша хватает, а вот при 64-х - постоянные промахи. Но вот на сколько эта задача будет реальной...
Да сейчас уже не такой и тормоз оперативная память. И да, ты совершенно прав, данные из памяти читаются страницами, поэтому, в принципе, какая разница, прочитать 8 байтов или 4? Поэтому чисто технически вроде как 16 регистров должны дать выигрыш. Интересно было бы посмотреть на это дело на реальных задачах.
УдалитьПо-моему для процессора она все ещё тормоз. Судя по https://gist.github.com/jboner/2841832 в ~20 раз медленнее L2 кэша. На реальных задачах, там где действительно нужно выжать максимум из процессора, думаю стараются просто избегать указателей и используют линейное размещение данных. Дабы помочь кэшу предсказать что нужно загрузить из RAM.
УдалитьТут, я думаю, все зависит от данных, а не от стремления разработчиков. Можно все данные разместить и в массиве, но если доступ к ним будет происходить хаотично, эффект будет как от использования указателей.
УдалитьС другой стороны, если указатели указывают на рядом расположенные места в памяти, то они будут более эффективны, чем массив.
Обычно действительно задача диктует структуру данных, но все таки иногда есть выбор: очередь на связанном списке или на массиве, хэш таблица на списках или с открытой адресацией, дерево из полноценных объектов или на массивах и т.д. У меня, к сожалению, нет никакого опыта такого вида оптимизаций, так как далеко не процессор узкое место, но вот например сравниваются разные реализации HashMap на Java: http://elizarov.livejournal.com/25221.html
УдалитьО, оказывается, есть еще люди, которые страдают подобной же ерундой :)
УдалитьК сожалению, заценить работу указанного автора не могу, так как о Java скорее только слышал, поэтому познаний не хватает для того, что бы познать смысл деталей.
В общем, смысл моего предыдущего комментария был следующий: массив, конечно, может быть эффективней, однако при хаотичном доступе к нему (что соответствует древовидным структурами или хэшам) эффект может быть крайне не значительным.