К сожалению, размещение статей сейчас является единственным эффективным методом рассказать разработчикам о том, что мы есть и что мы делаем. Эффективность контекстной рекламы, баннеров, прямого маркетинга в нашем случае крайне низкая. Дорогие виды продвижения нам сейчас недоступны.
Замечу, что на общем фоне мы не так уж выделяемся, если говорить об англоязычном интернете. Дело в том, что почти нет российских компаний, которые выпускают российские продукты в области программирования и пишут об этом на русском языке. В основном все статьи переводные. Вот и кажется, что нас МНОГО везде. ;)
Я не решился опубликовать здесь монстра — 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 минут, это совершенно точные результаты.
К сожалению, я видимо так и не смог донести мысль. Попробую еще раз. Общепризнано, что существенный рост дальнейшей производительности возможен только за счет распараллеливания. Увеличение разрядности (32->64), рост тактовой частоты процессоров, памяти, шины и так далее, дает прирост в процентах. Но не в разы. Существенный прирост дает только использование нескольких ядер. Программное обеспечение, не использующее несколько ядер, в ближайшее время будет получать все меньший и меньший прирост производительности при установке на новые системы. Для разных программ это наступит в разное время. В моем случае, я считаю, это произошло сейчас. Об этом я и рассказал.
Методика сравнения очень простая. Где-то года два назад, точно не помню, у меня появилась новая рабочая машина. Я увидел существенный прирост производительности, на задачах не ориентированных на многоядерность. Сейчас у меня новая машина из того же ценового диапазона. Я вижу прирост производительности, там где используется несколько ядер. И не вижу прирост, где не используется! Мне не интересуют теоретические рассуждения и замеры. Мне интересно практическое использование новой техники. :)
По поводу CPU Affinity. Я знаю, что привязка к ядрам немного ускорит работу. Я экспериментировал. Вот результат по юнит-тестам:
1 поток на 4 ядрах — 62 секунды
1 поток привязанный к одному ядру — 60 секунд
Я сознательно не стал затрагивать этот вопрос. Ведь хотелось показать, что просто приобретя чуть более мощный процессор с большим количеством ядер, я ничего не получу от неподготовленной к этому программе.
При запуске юнит-тестов жесткий диск точно роли не играет. Чистый счет, с потреблением порядка 2 Гб памяти.
При длительных тестах жесткий диск играет роль. Приходится препроцессировать много файлов. Но я думаю, это не влияет. Вот дополнительные сведения по памяти и дискам.
Память в обоих случаях: DDR2 Dual Symmetric 400 MGz
Диски:
1) WDC5000AAKS ATA 16 MB Cache 7200 RPM
2) WD3200AAKS ATA 16 MB Cache 7200 RPM
Наверное, имелось в виду (b + c) * a. Но вы сами ответили, почему выражение не оптимизируется подобным образом. Эти выражения не эквиваленты и результат их вычисления различен. Более того, в языке Си++ часто A+B != A-(-B). :)
Это весьма интересный и редкий опыт. Можете рассказать поподробнее? Если хотите, мы можем пообщаться по почте на тему написания совместной статьи. Или можете кратко рассказать здесь. Об SSE всем часто приходится слышать, но вот о практическом использовании почти ничего нет.
Согласен. Распределение нагрузки весьма важная задача. В одном из следующих постов я затрону данную тематику. Также еще можно вспомнить про закон Амдаля. А вот откуда взялось 2^n вообще не понятно… :)
Замечу, что на общем фоне мы не так уж выделяемся, если говорить об англоязычном интернете. Дело в том, что почти нет российских компаний, которые выпускают российские продукты в области программирования и пишут об этом на русском языке. В основном все статьи переводные. Вот и кажется, что нас МНОГО везде. ;)
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 минут, это совершенно точные результаты.
1 поток на 4 ядрах — 62 секунды
1 поток привязанный к одному ядру — 60 секунд
Я сознательно не стал затрагивать этот вопрос. Ведь хотелось показать, что просто приобретя чуть более мощный процессор с большим количеством ядер, я ничего не получу от неподготовленной к этому программе.
При длительных тестах жесткий диск играет роль. Приходится препроцессировать много файлов. Но я думаю, это не влияет. Вот дополнительные сведения по памяти и дискам.
Память в обоих случаях: DDR2 Dual Symmetric 400 MGz
Диски:
1) WDC5000AAKS ATA 16 MB Cache 7200 RPM
2) WD3200AAKS ATA 16 MB Cache 7200 RPM
А проблема простая. Программы, которые содержали (некорректный) код вида:
работали в 32-битном режиме и перестают работать в 64-битном. Простой перекомпиляции недостаточно. Необходимо еще выявить ошибки.
A Fundamental Turn Toward Concurrency in Software
Как веревочке не виться, …
A Picture of the Multicore Crisis