Разные интересные примеры можно посмотреть в нашем блоге. Вот выборка записей по 64-битности. Блог регулярно пополняется.
Правда не очень понятна актуальность адресации массивов больше INT_MAX.
Я работал с подобными задачами, где это удобно. Хотя конечно не скажу, что это повседневные задачи. Еще раз замечу, что 64-битные ошибки проявляются не обязательно на больших массивах. Разные ссылки я уже приводил выше.
Кстати, если есть желание, можно поиграть здесь в игру. Я буду приводить различные примеры кода, а участники будут пытаться найти в них ошибки силой мысли. Ошибки будут на тему 64-битности, параллельности и просто на внимательность.
Вам поможет проект PortSample входящий в состав дистрибутива PVS-Studio. Этот проект можно открыть в Visual Studio 2005/2008 и полюбоваться на разнообразные 64-битные ошибки, поиграть с ними. Многие из них приводят к падению. Заодно этот проект полноценно проверяется демонстрационной версией PVS-Studio. Скачать демонстрационную версию можно здесь. Подробнее познакомиться с PVS-Studio и PortSample можно здесь.
А причем здесь компилятор? Если код некорректен, то не спасет, если он собирается GCC или является скажем OpenSource. Все это никак не связано. Вот пример.
Я не хочу здесь сильно надоедать статьями по разработке 64-битных приложений, но обязан сделать эту запись. Без нее знакомство с потенциальными 64-битными проблемами неполно. Ошибки, возникающие при переносе программы на 64-битные системы коварны тем, что могут проявлять себя только при попытке обработать объем данных большего размера, чем было доступно для 32-битной систем. Или при незначительной модернизации кода.
Часто после перекомпиляции для 64-битной системы складывается впечатление, что программа успешно работает. Но при этом она может содержать массу временно скрытых дефектов. Чтобы предупредить разработчиков об этом, и сделана эта статья. В дополнении также хочу предложить еще одну запись в блоге на нашем сайте: "Оптимизация в мире 64-битных ошибок".
Не могу удержаться. Вы, например, сайт Abraxas Software и Gimpel Software не видели. Они тоже инструменты статического анализа делают. И живут успешнее многих. :) Так что дизайн конечно важен, но часто далеко не основное. :)
100% гарантию может дать только методология математического доказательства корректности программного кода. Этот вариант естественно не рассматриваем. Любой инструмент позволяет обнаружить часть программных ошибок.
Можно привести аналогию. Задача — выловить всю рыбу в пруду. Ручной метод — удочка. Инструментальный метод — большая сеть. Естественно сеть не даст гарантии, что выловлена вся рыба, но это явно лучше, чем удочка.
Инструменты статического анализа выявляют в программах те места, которые с большой вероятностью содержат ошибку. Пример кода, на который выдаст предупреждение статический анализатор, встроенный в Visual Studio Team System (ключ /analyze): «if (m_x < 10 && m_x < 10)» — слева и справа от && одинаковые выражения. Это пример диагностики, которая практически всегда выявляет ошибку. В другом случае, диагностика гораздо менее точна. Пример:
void Foo(char *array, size_t size) {
for (int i = 0; i < size; ++i)
array[i] = 'A';
}
Имеется здесь 64-битная ошибка или нет, сказать сложно даже человеку. Ему необходимо знать с какими (маленькими или большими) массивами работает функция. Однако анализатор Viva64 предупредит об потенциальный ошибке и человек решит, стоит исправить int на size_t, отключить это диагностическое сообщение или указать в настройках, что программа не обрабатывает массивы более 2 гигабайт (Viva64 не будет считать этот код опасным).
И еще инструменты статического анализа часто выдают ложные срабатывания, предлагая обратить внимание на совершенно безобидный код.
Статический анализ не исключает просмотр человеком исходного кода. Но позволяет существенно сократить объем, необходимый для просмотра. Если прочитать 200 МБайт исходного кода почти нереальная задача (внимание быстро рассеивается и эффективность чтения очень низкая), то используя статический анализ можно просмотреть почти все места, потенциально содержащие 64-битные ошибки за несколько дней. Да, не все места, но почти все.
Программа ВСЕГДА содержит ошибки. Задача свести какой-то класс ошибок к разумному минимуму. Будь то ошибки GUI, ошибки, приводящие к замедлению или не освобождения памяти. Нет смысла стараться вывести все 64-битные ошибки, оставив тысячи обыкновенных. :) Звучит несколько необычно, но думаю Вы согласитесь. :)
Вывод – 100% уверенности от использования Viva64 нет. Но очень близко. И еще мы плотно работаем с клиентами и быстро реализуем их пожелания по диагностике и интерфейсу инструмента.
Мы готовы и делаем совместные статьи! Если у Вас есть интересные идеи или просто интересные наблюдения, связанные с параллельностью или 64-битностью — пишите нам. Мы обсудим создание совместную статью. Мы живые, мы общаемся, мы прислушиваемся к людям! Мы не абстрактные разработчики и авторы, с которыми нет связи. Мы готовы к общению! Поддержите нас и не ругайте. :) Так сложно быть самостоятельным разработчиком программного обеспечения.
К сожалению, размещение статей сейчас является единственным эффективным методом рассказать разработчикам о том, что мы есть и что мы делаем. Эффективность контекстной рекламы, баннеров, прямого маркетинга в нашем случае крайне низкая. Дорогие виды продвижения нам сейчас недоступны.
Замечу, что на общем фоне мы не так уж выделяемся, если говорить об англоязычном интернете. Дело в том, что почти нет российских компаний, которые выпускают российские продукты в области программирования и пишут об этом на русском языке. В основном все статьи переводные. Вот и кажется, что нас МНОГО везде. ;)
Я не решился опубликовать здесь монстра — 20 ловушек переноса Си++ — кода на 64-битную платформу. Тем более эта статья 2007 года уже устарела. Мы теперь знаем куда больше ловушек. Недавно мы подготовили курс по разработке 64-битных приложений, где ошибки и способы их диагностики описаны гораздо полнее. Скоро представим публике.
Работоспособность кода на 64-битность системе зависит от множества факторов. Основные: возраст и размер проекта, объем потребляемой памяти. Отсюда и сильные вариации. От простой перекомпиляции до многих месяцев устранения ошибок.
Эх… Это ограничение на размер поста… В «предпросмотре» все хорошо. А здесь обрезается. И ведь главное немножко не влезает. Напишу в виде комментария.
Есть еще одна неприятная новость. Вам вряд ли удастся использовать инструменты, подобные BoundsChecker для поиска ошибок в ресурсоемких 64-битных программах, поглощающих большой объем памяти. Дела в колоссальном замедлении тестируемых программ, что делает такой подход крайне неудобным. Инструмент Parallel Inspector входящий в состав Intel Parallel Studio в режиме диагностики всех ошибок связанных с работой с памятью, замедлит скорость выполнения приложения в среднем в 100 раз (рисунок 10). Вполне есть вероятность, что тестируемый алгоритм, который работает 10 минут, придется оставлять на ночь и смотреть результаты работы только на следующий день. При этом я уверен, что Parallel Inspector в режиме поиска ошибок работы с памятью один из самых полезных и удобных инструментов. Просто надо быть готовым к изменению практики диагностики ошибок и закладывать это в планы освоения 64-битных систем. Рисунок 10. Окно настроек программы Parallel Inspector перед запуском приложения.
Последнее. Не забудьте добавить тесты, проверяющие совместимость форматов данных между 32-битной и 64-битной версией. Совместимость данных при миграции достаточно часто нарушается из-за записи в файлы таких типов как size_t или long (в случае Linux систем).
Я не могу ответить на ряд вопросов в силу недостаточно высокой компетентности в сфере Benchmark, а также из-за отсутствия необходимой технической базы для более детальных сравнений и экспериментов. Я могу строить гипотезы, не более. Но не хочу. По этому, и написал, что оставляю это без комментариев, так как признаю, что я могу быть не прав и не точен.
P.S.
Измерения в юнит-тестах осуществляются с использованием GetThreadTimes с расчетом среднего арифметического. Это вполне достоверно, если мы говорим об одном потоке. В многопоточном режиме использовался простой таймер, но для порядка 100 минут, это совершенно точные результаты.
Правда не очень понятна актуальность адресации массивов больше INT_MAX.
Я работал с подобными задачами, где это удобно. Хотя конечно не скажу, что это повседневные задачи. Еще раз замечу, что 64-битные ошибки проявляются не обязательно на больших массивах. Разные ссылки я уже приводил выше.
Кстати, если есть желание, можно поиграть здесь в игру. Я буду приводить различные примеры кода, а участники будут пытаться найти в них ошибки силой мысли. Ошибки будут на тему 64-битности, параллельности и просто на внимательность.
Дополнительно предлагаю вниманию вот эти записи:
Почему A + B != A-(-B)
Красивая 64-битная ошибка на языке Си
Магические константы и функция malloc()
Проблемы 64-битного кода в реальных программах: магические константы
Изменения выравнивания типов и последствия
Поиск ошибок явного приведения типа в 64-битных программах
Это примеры, которые работоспособны в 32-битном режиме, но приводят к ошибкам при компиляции для 64-битной системы.
Часто после перекомпиляции для 64-битной системы складывается впечатление, что программа успешно работает. Но при этом она может содержать массу временно скрытых дефектов. Чтобы предупредить разработчиков об этом, и сделана эта статья. В дополнении также хочу предложить еще одну запись в блоге на нашем сайте: "Оптимизация в мире 64-битных ошибок".
7 шагов по переносу программы на 64-битную систему
А затем приглашаю в раздел ресурсов на нашем сайте где имеются наши статьи по разработке 64-битных приложений, обзоры сторонних статей, блог по тематике 64-битного программирования и так далее. Примеры статей:
20 ловушек переноса Си++ — кода на 64-битную платформу
Как оценить процесс 64-битной миграции Си/Си++ приложений?
Архитектура AMD64 (EM64T)
64-битный конь, который умеет считать
Что такое size_t и ptrdiff_t
Оптимизация 64-битных программ
Можно привести аналогию. Задача — выловить всю рыбу в пруду. Ручной метод — удочка. Инструментальный метод — большая сеть. Естественно сеть не даст гарантии, что выловлена вся рыба, но это явно лучше, чем удочка.
Инструменты статического анализа выявляют в программах те места, которые с большой вероятностью содержат ошибку. Пример кода, на который выдаст предупреждение статический анализатор, встроенный в Visual Studio Team System (ключ /analyze): «if (m_x < 10 && m_x < 10)» — слева и справа от && одинаковые выражения. Это пример диагностики, которая практически всегда выявляет ошибку. В другом случае, диагностика гораздо менее точна. Пример:
void Foo(char *array, size_t size) { for (int i = 0; i < size; ++i) array[i] = 'A'; }Имеется здесь 64-битная ошибка или нет, сказать сложно даже человеку. Ему необходимо знать с какими (маленькими или большими) массивами работает функция. Однако анализатор Viva64 предупредит об потенциальный ошибке и человек решит, стоит исправить int на size_t, отключить это диагностическое сообщение или указать в настройках, что программа не обрабатывает массивы более 2 гигабайт (Viva64 не будет считать этот код опасным).
И еще инструменты статического анализа часто выдают ложные срабатывания, предлагая обратить внимание на совершенно безобидный код.
Статический анализ не исключает просмотр человеком исходного кода. Но позволяет существенно сократить объем, необходимый для просмотра. Если прочитать 200 МБайт исходного кода почти нереальная задача (внимание быстро рассеивается и эффективность чтения очень низкая), то используя статический анализ можно просмотреть почти все места, потенциально содержащие 64-битные ошибки за несколько дней. Да, не все места, но почти все.
Программа ВСЕГДА содержит ошибки. Задача свести какой-то класс ошибок к разумному минимуму. Будь то ошибки GUI, ошибки, приводящие к замедлению или не освобождения памяти. Нет смысла стараться вывести все 64-битные ошибки, оставив тысячи обыкновенных. :) Звучит несколько необычно, но думаю Вы согласитесь. :)
Вывод – 100% уверенности от использования Viva64 нет. Но очень близко. И еще мы плотно работаем с клиентами и быстро реализуем их пожелания по диагностике и интерфейсу инструмента.
Замечу, что на общем фоне мы не так уж выделяемся, если говорить об англоязычном интернете. Дело в том, что почти нет российских компаний, которые выпускают российские продукты в области программирования и пишут об этом на русском языке. В основном все статьи переводные. Вот и кажется, что нас МНОГО везде. ;)
www.google.ru/search?hl=ru&newwindow=1&q=64-bit+-viva64
Вы зря считаете, что это удел только плохих программистов и кривых проектов. :) Пара примеров:
Проблемы 64-битного кода в реальных программах: FreeBSD
Проблемы 64-битного кода в реальных программах: виртуальные функции
Проблемы 64-битного кода в реальных программах: qsort
Есть еще одна неприятная новость. Вам вряд ли удастся использовать инструменты, подобные BoundsChecker для поиска ошибок в ресурсоемких 64-битных программах, поглощающих большой объем памяти. Дела в колоссальном замедлении тестируемых программ, что делает такой подход крайне неудобным. Инструмент Parallel Inspector входящий в состав Intel Parallel Studio в режиме диагностики всех ошибок связанных с работой с памятью, замедлит скорость выполнения приложения в среднем в 100 раз (рисунок 10). Вполне есть вероятность, что тестируемый алгоритм, который работает 10 минут, придется оставлять на ночь и смотреть результаты работы только на следующий день. При этом я уверен, что Parallel Inspector в режиме поиска ошибок работы с памятью один из самых полезных и удобных инструментов. Просто надо быть готовым к изменению практики диагностики ошибок и закладывать это в планы освоения 64-битных систем.
Рисунок 10. Окно настроек программы Parallel Inspector перед запуском приложения.
Последнее. Не забудьте добавить тесты, проверяющие совместимость форматов данных между 32-битной и 64-битной версией. Совместимость данных при миграции достаточно часто нарушается из-за записи в файлы таких типов как size_t или long (в случае Linux систем).
Библиографический список
1. Wikipedia. 64-bit. http://www.viva64.com/go.php?url=203
2. Wikipedia. AMD64. http://www.viva64.com/go.php?url=204
3. Wikipedia. IA-64. http://www.viva64.com/go.php?url=205
4. Wikipedia. Itanium. http://www.viva64.com/go.php?url=206
5. Андрей Карпов. Забытые проблемы разработки 64-битных программ http://www.viva64.com/art-1-1-1609701563.html
6. Wikipedia. WOW64. http://www.viva64.com/go.php?url=207
7. Nick Hodges. The Future of the Delphi Compiler. http://www.viva64.com/go.php?url=208
8. Mike Becker. Accessing 32-bit DLLs from 64-bit code. http://www.viva64.com/go.php?url=209
9. Eric Palmer. How to use all of CPUID for x64 platforms under Microsoft Visual Studio .NET 2005. http://www.viva64.com/go.php?url=210
10. Андрей Карпов, Евгений Рыжков. Поиск ловушек в Си/Си++ коде при переносе приложений под 64-битную версию Windows. http://www.viva64.com/art-1-1-329725213.html
11. Андрей Карпов. 64 бита, /Wp64, Visual Studio 2008, Viva64 и все, все, все… http://www.viva64.com/art-1-1-253695945.html
12. Андрей Карпов, Евгений Рыжков. 20 ловушек переноса Си++ — кода на 64-битную платформу. http://www.viva64.com/art-1-1-1958348565.html
13. Евгений Рыжков. Viva64: что это и для кого? http://viva64.com/art-1-1-2081052208.html
14. Андрей Карпов. Сравнение диагностических возможностей анализаторов при проверке 64-битного кода. http://www.viva64.com/art-1-1-1441719613.html
P.S.
Измерения в юнит-тестах осуществляются с использованием GetThreadTimes с расчетом среднего арифметического. Это вполне достоверно, если мы говорим об одном потоке. В многопоточном режиме использовался простой таймер, но для порядка 100 минут, это совершенно точные результаты.