Теми темпами, которыми идет развитие разработки программного обеспечения, скоро тяжелым станет любой софт. :)) Это не хорошо и не плохо. Это плата за простоту и скорость разработки. Готов поспорить, что через десяток лет мы увидим программу для просмотра картинок, загружающую 10 ядер и музыкальный проигрыватель, съедающий гигабайт памяти. :))) Когда то ведь казалось невероятным, что драйвер какого-то устройства может занимать более 100 кб памяти.
P.S. Кстати при разработке лишние гигабайты и ядра очень сильно помогают.
Насколько я понимаю большее значение имеет не битность ОС, а возможности самого приложения распараллеливать свои процессы.
Безусловно. Именно поэтому нет смысла ожидать, что что-то в 64-битной / многоядерной системе что-то начнет быстро работать само по себе. Нужна большая работа по модернизации существующего ПО. Результат должен быть очень хорошим, но поскольку все это сложно мы в самом начале пути освоения таких систем.
Очень даже хорошо понимаю. :) Мы о разработке параллельных и 64-битных решений пишем и пишем. :) Возможно прозвучала это и вульгарно, но по сути так оно есть. Нет программ, как следствие нет желания приобретать мощную систему. Не у всех 64-битные системы с несколькими ядрами — нет смысла писать ПО для таких систем. Жаль.
А оно и не позиционируется. К сожалению. Игры могли бы многое получить от 64-битности. Малое количество памяти уже является узким местом. Только вместо того, чтобы разрабатывать и рекомендовать использовать 64-битные версии разработчики держатся за совместимость с 32-битами до последнего. Это понятно. Вести 2 ветки намного сложнее. Вот и начинаются разные противоестественные рекомендации. :)
Так вот и нет его. В том смысле, что потребления нет. Мало желающих ставить более 4-х гигабайт памяти и процессор с несколькими ядрами. Как следствие нет и программ под такие системы. В общем-то, замкнутый круг получается.
Intel старается развить блог и наполнить его тематическими записями не только о самом Intel. Для этого он приглашает в гости сторонних авторов. Я не имею отношения к Intel, хотя связан с родственной тематикой – созданием инструмента для разработчиков ресурсоемких приложений. Подробности можно посмотреть в профиле. Вообще я планирую писать здесь более технические вещи, но иду к этому постепенно. :)
Не стал придумывать примеры, так как, скорее всего они получатся неубедительными. Написал пример из практики. А вообще реализаций использования «простой параллельности» должно быть много. Кто поделится своим примером?
Я думаю, я еще сделаю не один пост и мы не раз продолжим спор в этом ключе. :) Вы относитесь ко второй группе (теоретиков). А я скорее себя ставлю ближе к первой группе (практиков и реалистов). Это не хорошо и не плохо, просто у нас разная картина мира. :) Когда я услышал про модели описания параллельных процессов и сети петри, я был готов поспорить, что Вы работаете или как-то связаны с ИПС/ИММ/xxx РАН. Посмотрел профиль – и действительно ИММ УрО РАН. ;))) Только боже упаси не подумайте, что я не считаюсь с теоретическими аспектами. Только на практике это может выглядеть так. Приходит в компанию, занимающуюся аутсорсом, очередной проект, который нужно развивать. И НИКТО не знает, что там. И никакие модели тут не помогут. :)
Не так все плохо. Появляются соответствующие инструменты. И они уже умеют очень многое. Пожалуй, лучшим универсальным инструментом сейчас в этой области является динамический анализатор Intel Parallel Inspector. Развиваются альтернативные подходы, основанные на статическом анализе. Для OpenMP программ: Intel “Parallel Lint” и VivaMP. Для POSIX Threads можно взять PC-Lint.
И если вы параллелите модуль A, который вы разрабатываете, то вам не нужно знать более низкоуровневые модули B и C.
В идеальной программе – да. В реальной — нет. Устройство низкоуровневых модулей B и C может не рассчитано на параллельные вызовы. Достаточно наличие одной глобальной (общей) переменной в этих модулях и мы уже имеем дело с состоянием гонки.
Но так оно и есть. И по меркам истории компьютеров именно давно. Еще Эдсгер Дейкстра писал о кризисе в программировании и что программы стали крайне сложными и недетерминированными. Например, в статье «Смиренный программист» 1972 года он пишет:
Во-первых, мы получили прерывания ввода/вывода, происходящие в непредсказуемые и невоспроизводимые моменты времени; в сравнении со старыми последовательными машинами, которые прикидывались полностью детерминированными автоматами, это разительное изменение, и преждевременная седина многих системных программистов служит свидетельством тому, что нам не стоит легкомысленно отзываться о логических проблемах, порожденных этой возможностью.
Так что вполне себе «давным-давно никто не знает, как работают реальные программы» :)
Согласен. Да и вообще используя OpenMP распараллелить УЖЕ существующий код ой как не просто. Кстати, вот еще на тему OpenMP:
"32 подводных камня OpenMP при программировании на Си++"
http://www.viva64.com/articles/32_OpenMP_traps_%28rus%29.html
P.S. Кстати при разработке лишние гигабайты и ядра очень сильно помогают.
Безусловно. Именно поэтому нет смысла ожидать, что что-то в 64-битной / многоядерной системе что-то начнет быстро работать само по себе. Нужна большая работа по модернизации существующего ПО. Результат должен быть очень хорошим, но поскольку все это сложно мы в самом начале пути освоения таких систем.
А еще вот список — Специализированные параллельные библиотеки
2) +1
В идеальной программе – да. В реальной — нет. Устройство низкоуровневых модулей B и C может не рассчитано на параллельные вызовы. Достаточно наличие одной глобальной (общей) переменной в этих модулях и мы уже имеем дело с состоянием гонки.
Во-первых, мы получили прерывания ввода/вывода, происходящие в непредсказуемые и невоспроизводимые моменты времени; в сравнении со старыми последовательными машинами, которые прикидывались полностью детерминированными автоматами, это разительное изменение, и преждевременная седина многих системных программистов служит свидетельством тому, что нам не стоит легкомысленно отзываться о логических проблемах, порожденных этой возможностью.
Так что вполне себе «давным-давно никто не знает, как работают реальные программы» :)
У меня не получилось… :-(
P.S. Прошу откликнуться, кому удалось.
7 шагов по переносу программы на 64-битную систему
20 ловушек переноса Си++ — кода на 64-битную платформу
64 бита, /Wp64, Visual Studio 2008, Viva64 и все, все, все...
Безопасность 64-битного кода
"32 подводных камня OpenMP при программировании на Си++"
http://www.viva64.com/articles/32_OpenMP_traps_%28rus%29.html