Набор инструментов, используемых разработчиком, регулярно обновляется. Появляются совершенно новые инструменты, некоторые перестает быть актуальным, какие-то перестают развиваться и вытесняются более совершенными аналогами. За всем этим наблюдать достаточно интересно, и я решил поделиться некоторыми своими последними наблюдениями в этой области.

Еще сразу хочу заметить, что мне близка позиция, что чем меньше разнородных инструментов используется, тем лучше. Я заранее готов к критике в минимализме функциональности. Моя позиция спорная, но вполне заслуживает право на существование.

Этой тарахтелкой можно пугать беременных кошек, но какой прок от неё в бою? — генерал Китченер о первом танке, 1915.

Эта заметка получилась у меня странным образом. Изначально я сел, чтобы написать текст об особенностях использования юнит-тестов для ресурсоемких приложений. Хотелось написать, что вот-вот на наши столы взгромоздятся компьютеры с сотнями гигабайт оперативной памяти и сотнями процессорных ядер. А затем описать, как это может повлиять на разработку и тестирование приложений.

Но еще не приступив к сути, я почувствовал что со всех сторон стекаются комментарии «такая система мне не нужна», «программам не нужны такие ресурсы», «текущих ресурсов и так для всего хватает», «будущее за видеокартами».

Я сделал отступление, чтобы написать для чего это нужно. Потом развил отступление. А потом взял и написал пост, почему я считаю, зачем нужны и полезны гигабайты и много-много ядер.

Аннотация
Введение
1. auto
2. decltype
3. Ссылка на временный объект (R-value reference)
4. Правые угловые скобки
5. Лямбда-функции (Lambdas)
6. Suffix return type syntax
7. static_assert
8. nullptr
9. Новые стандартные классы
10. Новые направления в развитии статических анализаторов кода
Заключение
Библиографический список

Аннотация

В статье рассмотрены новые возможности языка Си++, описанные в стандарте C++0x и поддержанные в Visual Studio 2010. На примере PVS-Studio рассмотрено, как изменения языка отразятся на инструментах статического анализа кода.

На ISN уже затрагивалась тема, что последнее время наблюдается некоторые неудобства с качеством поддержки в программах различных разрешений. Особенно эта проблема выходит на передний план с развитием новых решений, таких как например нетбуков на базе Atom. У этих устройств обычно нестандартные разрешения экрана, хотя так далеко можно и не ходить. Достаточно взять мой вполне обычный настольный монитор с разрешением 1680x1050 и выставленным DPI 125%.

Предлагаю вашему вниманию очередную заметку посвященную знакомству с технологией параллельного программирования OpenMP. Рассмотрим директивы: atomic, reduction.

Продолжим знакомство с технологией OpenMP и рассмотрим некоторые функции и новые директивы.

Сейчас я скажу о том, что все знают и о чем говорят уже несколько лет. Параллельное программирование неизбежно. Я знаю, что прозвучало это банально! Но я специально выделил это в отдельный маленький пост, в надежде кто-то задумается над этой простой фразой чуть дольше. Часто то, о чем мы регулярно слышим, теряет всякий для нас смысл и не приводит к размышлениям и выводам. Попробуем же сделать несколько этих выводов.

Начнем знакомство непосредственно с использованием технологии OpenMP и рассмотрим в этой заметке некоторые базовые конструкции.

Прежде чем приступить к изучению методики распараллеливания программ с помощью технологии OpenMP рассмотрим инструментарий, который нам потребуется. А потребуется нам в первую очередь Visual Studio 2005/2008 и Intel Parallel Studio.

Мы регулярно пишем статьи посвященные разработке и тестированию 64-битных программ на языке Си/Си++. Каждая из статей представляет взгляд на задачу разработки 64-битных программ с разных точек зрения. Но существенная часть информации в них повторяется, так как необходимо знакомить читателя с проблематикой и вводить различные определения. Это, к сожалению, делает чтение подборки статей скучным занятием и соответственно не позволяет всесторонне изучить вопросы разработки 64-битных приложений.

Мы решили объединить все наши знания в единый труд, в котором будут рассмотрены сразу все вопросы, касающиеся 64-битного программирования. Для оформления в виде статьи материала оказалась слишком много и мы решили представить его в виде курса уроков.

Кратко опишу курс "Уроки разработки 64-битных приложений на языке Си/Си++" и приведу его содержание.

Казалось, закончились долгие обсуждения в форумах, как измерить время работы алгоритма, какие функции использовать, какую точность ожидать. Жаль, но опять придется вернуться к этому вопросу. На повестке дня, как лучше измерить скорость работы параллельного алгоритма.

Статья посвящена особенностям поведения компилятора Visual C++ при генерации 64-битного кода и связанными с этим потенциальными ошибками.

Аннотация

В статье рассмотрены основные шаги, обеспечивающие корректный перенос 32-битных Windows приложений на 64-битные Windows системы. Хотя статья ориентирована на разработчиков, использующих язык Си/Си++ в среде Visual Studio 2005/2008, она будет полезна и другим разработчикам, планирующим перенос своих приложений под 64-битные системы.

Есть достаточно известная статья Герба Саттера "The Free Lunch Is Over. A Fundamental Turn Toward Concurrency in Software". В ней говорится, что не стоит более надеяться на рост тактовой частоты микропроцессоров. Для повышения производительности программ теперь необходимо использовать несколько ядер в микропроцессоре. Хотя статья написана в 2005 году, до настоящего времени она для меня была скорее теоретической, чем практическим руководством к действию. Ранее я всегда получал ускорение, приобретая новый компьютер. Но вот настал тот момент, когда этого не произошло.

Рисунок 1 — Время работы unit-тестов на моей старой и новой машине.

Распараллелить решение задачи можно на нескольких уровнях. Между этими уровнями нет четкой границы и конкретную технологию распараллеливания, бывает сложно отнести к одному из них. Приведенное здесь деление условно и служит, чтобы продемонстрировать разнообразие подходов к задаче распараллеливания.

На Хабре вообще и в этом блоге в частности нередко можно прочитать о счастье, которое вот-вот придет в дом всем смертным. Я имею в виду то многоядерные процессоры, то гигабайты оперативной памяти, то 64-битные системы… Хотите узнать насколько будущее близко на самом деле?

Наверняка продвинутые геймеры знают про Steam. Для тех же, кто менее продвинут, или просто обладает «провинциальным» небыстрым интернетом скажу, что это система online дистрибуции компьютерных игр, причем именно хитов, которые у всех на слуху и которые очень популярны в мире. Разработчики сервиса Steam имеют подробную статистику по компьютерам своих пользователей и эту статистику всегда можно посмотреть.

Числа Фибоначчи — элементы числовой последовательности 1, 1, 2, 3, 5, 8, 13, 21, 34,… в которой каждое последующее число равно сумме двух предыдущих чисел. Числа Фибоначчи мы можем заметить во многих объектах природы, в соотношении пропорций туловища или увидеть реализацию спирали Фибоначчи в раковине моллюска.

С недавнего времени мне не дают покоя эти самые числа Фибоначчи! С какими бы материалами по параллельному программированию я не знакомился, я всюду встречаю эти числа. Возникает ощущение, что все параллельное программирование связано исключительно с проблемой вычислений чисел Фибоначчи.

Вычисление чисел Фибоначчи приводится во множестве печатных и электронных статей. Даже Wikipedia-статья о Parallel computing содержит пример их вычисления.

Какой пример любят приводить разработчики Cilk? Конечно, вычисление чисел Фибоначчи. Числа Фибоначчи в проспекте Cilk "Parallelism for the Masses". Числа Фибоначчи в описании Cilkview. Про Фибонначи идет речь в "Cilk Reference Manual". Проще говоря, везде.

Около двух месяцев назад состоялся первый экспериментальный русскоязычный онлайн-семинар от Intel "Intel Parallel Studio workflow". На этом семинаре была сделана попытка показать, что существуют такие волшебные инструменты, которые помогут реализовать распараллеливание и оптимизацию кода на языке Си++, даже если вы не имеете полного представления о принципах работы программы. Я знаю, что подобный подход часто критикуется. И очередное напоминание, что показанные на вебинаре действия являются некорректными, сподвигло меня на этот пост.



Аналогичные разногласия существовали когда-то между сторонниками и противниками использования инструментов отладки («дебаггеров»). Противники утверждали, что отладчики являются следствием неверной методологии, а пользователи отладчиков просто малограмотны. Основной их аргумент заключался в том, что использование инструментов отладки поощряет написание кода методом проб и ошибок, без попытки как следует продумать алгоритм и переписать его, разбить на маленькие функции, сделать более лаконичным и простым — таким, чтобы не осталось места для ошибок. Поскольку противников инструментов отладки сейчас мало, то многие, возможно, даже не слышали о подобных спорах. Ну а сейчас мы наблюдаем начало нового витка.

В настоящее время сформировались и обсуждаются два подхода к проблеме распараллеливания программ. Сторонники первого хотят получить какие-то средства, которые позволят им при минимальной переделке программы осуществить ее распараллеливание. Это практики, которые хотят приспособить свои решения к возможностям многоядерных систем, появляющихся на столах обыкновенных пользователей. Вторые любят поговорить о различных теориях распараллеливания, о языках параллельного программирования и том, что необходимо четко понимать, как будет работать параллельный код. Ведь, по их мнению, иначе невозможно достичь его корректности и эффективности.