Многим известен цикл зрелости технологий (Hype Cycle), предложенный аналитической компанией Gartner. В википедии его ещё называют циклом ажиотажа или циклом общественного интереса к технологиям. Сейчас общественный интерес ярко проявляется в количестве поисковых запросов по названию технологии или технологического продукта. И (О радость!) у Google есть мощное средство для анализа популярности поисковых запросов — Google Trends. Ради справедливости надо сказать, что у Яндекса и некоторых других тоже есть статистика, но значительно менее функциональная. Соответственно мы можем проверить проявляется ли Hype Cycle в открытых данных гугла, а заодно и сравнить популярность некоторых технологий.

Под катом пара графиков по технологиям из Hype Cycle и множество графиков по холиварным темам из IT — от XML vs JOSN до MySQL vs HBase. В целом, благодатная почва для диванной аналитики.

Как известно, бесконечности бывают разных типов. Бывают счетные, бывают несчетные. Несчетные делятся на множества мощности континуум и все остальные. Счетные множества это такие, элементы которых можно упорядочить в длинный ряд и занумеровать натуральными числами. С несчетными такой фокус не удается. Тогда как же можно представить несчетное множество, в частности множество вещественных чисел [0;1)? Ответ — дерево бесконечной высоты.

Недавно заинтересовался инстанцированием плюсовых шаблонов. В интернетах втречается термин code bloat. Для с++ это может означать неконтроллируемое увеличение кода генерируемого компилятором. Код увеличивается за счет того что инстанцирование новой функции имеет более высокий приоритет чем преобразование аргументов к более удобному типу. Т.е. template T foo(T a); для int и char — это две разные функции. Получить одну функцию можно либо отказом от шаблонов, либо использованием явного преобразования типов.
Но давайте вывернем проблему наизнанку и попробуем получить из минимума строк кода исполняемый файл максимально возможного размера.
Результат не очень впечатил — у меня получилось всего 53Mb из 60 строк кода. И то лишь для одного из трех опробованных компиляторов и ценой нескольких часов компиляции. Максимальное отношение объем/строки — 2.3МБ/строку для объема 14МБ.
Как и почему так получилось — под катом.

Недавно заинтересовался реализацией std::string в libstdc++. Не в связи с принятием нового стандарта, а чтобы разобраться. Благо требования к строковму типу почти не изменились.

Основным средством для анализа кода несомненно является метод пристального вглядывания, но чтобы сузить область вглядывывания и сделать процедуру более захватывающей можно реализовать для строки идиому «трассер» подсмотренную в «C++ Templates: The Complete Guide». Трассировка позволяет выявлять подозрительные интересные операции над строками.

Как известно, std::string это псевдоним для

std::basic_string<char>

и нам ничего не мешает определить

std::basic_string<X>

. В X можно определить несколько статических счетчиков и итерировать их в конструкторе, деструкторе и остальных методах. Выполняя разные операции над такой строкой можно будет проследить эффективность применяемых алгоритмов в терминах количества операций.
Кроме того, в g++ для

std::string a(«entrails»); 

выражение

std::cout << reinterpret_cast<char*>(*((void**)(&a))); 

выведет содержимое строки. Т.е. std::string — является, по сути, указателем на char.
Вобщем, эти и другие шокирующие поднобности под катом.

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

volatile unsigned long int incremented;

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

Далее о структуре теста и результатах.

Однажды заинтересовался, содержимым стека функции main процесса в linux. Провел некоторые изыскания и теперь представляю вам результат.

Варианты описания функции main:
1. int main()
2. int main(int argc, char **argv)
3. int main(int argc, char **argv, char **env)
4. int main(int argc, char **argv, char **env, ElfW(auxv_t) auxv[])
5. int main(int argc, char **argv, char **env, char **apple)

argc — число параметров
argv — нуль-терминальный массив указателей на строки параметров командной строки
env — нуль-терминальный массив указателей на строки переменных окружения. Каждая строка в формате ИМЯ=ЗНАЧЕНИЕ
auxv — массив вспомогательных значение (доступно только для PowerPC [1])
apple — путь к исполняемому файлу (в MacOS и Darwin [2])
Вспомогательный вектор — массив с различной дополнительной информацией, такой как эффективный идентификатор пользователя, признак setuid бита, размер страницы памяти и т.п.

Далее о том как получить массив вспомогательных значений для i386 и x86_64, а также об остальном содержимом «сегмента» стека.