Как приложение должно работать в 64-разрядном по сравнению с 32-разрядными архитектурами Intel?
Время для освобождения памяти, занятой объектом, - когда Вам больше не нужен тот конкретный объект. В Вашем особом случае пользователе класса AnimalLister запросил указатель на новый выделенный объект класса Животное. Так, он - тот, который ответственен за освобождение памяти, когда ему действительно больше нужен тот указатель/объект.
AnimalLister lister;
Animal* a = lister.getNewAnimal();
a->sayMeow();
delete a;
, По-моему, нет никакой потребности сверхспроектировать что-либо в этом случае. AnimalLister является просто фабрикой, которая создает новые объекты Животных и вот именно.
7 ответов
Краткий ответ: вы, вероятно, не заметите большой разницы.
Более длинный ответ: 64-битный x86 имеет регистры общего назначения, что дает компилятору больше возможностей для оптимизации локальные переменные в регистры для более быстрого доступа. компилятор может также использовать более современные функции, например. не нужно оптимизировать код для 386, и можно предположить, что ваш процессор имеет такие вещи, как SSE, вместо старого FPU x87 для математики с плавающей запятой. но указатели будут вдвое шире, что хуже для кеша.
Есть ли у вас какие-либо требования для> 4G памяти? Использование больших объемов памяти - действительно главная причина перейти на 64-разрядную версию.
В общем, вы не найдете эквивалентных процессоров, которые бы отличались только поддержкой 64-битных операций, поэтому будет сложно дать какие-либо конкретные сравнения между 1) и 2). С другой стороны, разница между сборкой для 32- и 64-разрядного режима полностью зависит от приложения. 64-разрядная версия может быть немного медленнее или немного быстрее 32-разрядной версии. Если ваше приложение использует много временных переменных, то увеличенный набор регистров 64-битного режима может очень сильно повлиять на производительность.
По опыту я обнаружил, что 64-битная повторная компиляция 32-битного приложения обычно ускоряет работу примерно на 30%. Это приблизительная цифра, но она актуальна для целого ряда приложений, которые я перенес на 64-разрядную версию. В основном это по причинам, описанным выше. У вас больше регистров, что является находкой и позволяет гораздо меньше менять местами память (которая, вероятно, в любом случае будет кэширована, что сделает выигрыш довольно небольшим). Определенные оптимизации также можно сделать намного проще. ОДНАКО, вы страдаете от проблемы с указателями большего размера, которые действительно сводят на нет часть выигрыша, не говоря уже о том, что переключение контекста требует использования большего объема памяти из-за большего набора регистров.
Тщательная ручная оптимизация в 64-битной среде однако может обеспечить ОГРОМНЫЙ выигрыш в производительности.
Лучше всего перекомпилировать как 64-битную, так и профильную.
Программы, интенсивно использующие ЦП, могут быть заметно быстрее в 64-разрядной версии. Процессор имеет 16 регистров общего назначения вместо 8, которые также вдвое шире (64 вместо 32 битов).
Также количество регистров для инструкций SSE увеличено вдвое с 8 до 16, что помогает для мультимедийных приложений или других приложения, которые выполняют много вычислений с плавающей запятой.
Подробнее см. x86-64 в Википедии.
Еще не упоминалось, что 64-разрядные версии операционных систем, такие как поскольку Windows и Linux используют другое соглашение о вызовах для вызовов функций в 64-битных системах; вместо передачи аргументов в стек аргументы (предпочтительно) передаются в регистрах, что в принципе быстрее.
Ребята, знаете ли вы что-нибудь о многоканальных параллельных пакетах шины данных MC, IMC и многоядерных функциях новых архитектур x86_64? по крайней мере, memcpy может быть оптимизирован быстрее, если 64-битный, из-за использования 64-битной шины и регистров, независимо от одновременного пакета. по крайней мере, новые арки могут предварительно загружать данные из нескольких модулей памяти в кеш одновременно. и многое другое ...
Производительность, скорее всего, будет зависеть от вашего приложения и может сильно различаться в зависимости от того, используете ли вы библиотеки, оптимизированные для 64-битных сред. Если вы хотите рассчитывать на ускорение, вам следует сосредоточиться на улучшении своих алгоритмов, а не на рассмотрении архитектуры набора инструкций.
Что касается подготовки / разработки для 64-разрядной версии ... главное - не делать предположений относительно к типам и их размерам. Если вам нужен тип определенного размера, используйте типы, определенные в < stdint.h >. Всякий раз, когда вы видите функции, которые используют size_t или ptrdiff_t , вам следует использовать typedefs, а не какой-либо другой тип.