• Профилирование сборки проекта

    • Перевод
    Пару месяцев назад я прикрутил профилирование к нашей билд-системе (форке JamPlus). Оно было реализовано на уже описанном мной ранее Chrome Tracing View, так что добавить его поддержку в Jam было просто. Jam написан на С, так что я просто нашел подходящую библиотеку для профилирования на С (это была minitrace) и буквально несколькими строками обернул интересующие меня места (собственно, сборку).

    image

    Здесь нет ничего выдающегося. Однако… как только у вас появляются первые результаты профилирования, они чаще всего заставляют задуматься и начать кое-что замечать.
    Читать дальше →
  • Plugin for HANA Database project in Visual Studio

    Я работаю по SCRUM-у в ASP .NET MVC-проекте, в котором HANA используется как база данных, а в качестве Source Control-а – TFS. На уровне базы данных преимущественно используем View (Calculation, Attributes and DB Views), а также Stored Procedure – для выполнения транзакционных запросов на сервер.

    После окончания каждого релиза у меня всегда возникал вопрос: «А что именно изменилось в этом релизе?» или «Кто какое изменение сделал?» В связи с этим я подумал: «Почему бы не трекать состояние объектов в TFS после каждого изменения?»

    В результате я решил создать плагин, который позволяет использовать Database-проект в Visual Studio (VS) и импортировать изменения, которые есть в базе данных. Так родилась идея создания данного приложения.

    Начинаем с простого и смотрим, какие прототипы есть у Microsoft. Как пример возьмем MS-SQL-сервер и Database-проект в Visual Studio и рассмотрим все возможности, которые у них существуют:

    1. Можно создать свою схему (использовать существующую) в MS-SQL и потом импортировать ее в Database-проект в Visual Studio (DB VS).
    2. Можно создать (изменить) объект в Database и трансформировать изменения в базу данных.
    3. Можно трекать изменения в Source Control (в моем случае в TFS).
    4. Таким образом, мы можем отслеживать все изменения, которые происходят в ходе разработки, а также их авторов.

    Сразу говорю, что поддерживать все эти возможности очень непросто, тем более что в HANA существует такой вид объектов, как Graphic View: он создается в графическом виде и его никак не продемонстрируешь в Visual Studio (но тем не менее для этого типа объектов тоже нашелся подход, чтобы импортировать его в VS).

    Я пошел по простому пути. Рассмотрим каждую возможность по отдельности.
    Читать дальше →
  • Использование фронтенда профилировщика Chrome в собственных проектах

    • Перевод
    Возможно, вы знаете, что у браузере Google Chrome есть встроенный профилировщик. Но даже из тех людей, кто его видел, большинство считает, что использовать его можно только для отладки Javascript или отрисовки кадров в браузере. Но на самом деле его весьма просто можно прикрутить в качестве средства визуализации данных профилирования в вашем проекте.

    Я не открою здесь каких-то уникальных секретов, например, Colt McAnlis писал о подобном применении профилировщика Chrome в игровых проектах ещё в 2012 году. Всё, написанное там, всё ещё является правдой, а я напишу ещё один материал — просто для лучшего распространения знаний о столь полезном инструменте.

    Предыстория


    Для некоторой части нашей системы сборки кода мы когда-то написали простенький профилировщик (называется TinyProfiler). Он достаточно тривиален — замеряет время выполнения определенных блоков кода и создаёт набор HTML+SVG файлов, которые визуализируют эти данные в стиле flame-графов:

    image

    Это, в принципе, неплохо работало, но полученный HTML был не очень интерактивным. Можно было подвести мышку к определенному блоку и увидеть его название во всплывающей подсказке, но на этом все удобства и заканчивались. Не было ни зума, ни фильтрации, ни скрола, ни поиска — в общем ничего, чего хотелось бы получить от более-менее профессионального инструмента. Всё это можно было, конечно, сесть и написать, но… зачем же это делать, если можно этого не делать? Ведь уже есть кто-то (разработчики Chrome), кто всё это уже сделал.
    Читать дальше →
  • «Магическая константа» 0x5f3759df

    • Перевод
    В этой статье мы поговорим о «магической» константе 0x5f3759df, лежащей в основе элегантного алгоритмического трюка для быстрого вычисления обратного квадратного корня.

    Вот полная реализация этого алгоритма:

    float FastInvSqrt(float x) {
      float xhalf = 0.5f * x;
      int i = *(int*)&x;  // представим биты float в виде целого числа
      i = 0x5f3759df - (i >> 1);  // какого черта здесь происходит ?
      x = *(float*)&i;
      x = x*(1.5f-(xhalf*x*x));
      return x;
    }

    Этот код вычисляет некоторое (достаточно неплохое) приближение для формулы

    image

    Сегодня данная реализация уже хорошо известна, и стала она такой после появления в коде игры Quake III Arena в 2005 году. Её создание когда-то приписывали Джону Кармаку, но выяснилось, что корни уходят намного дальше – к Ardent Computer, где в середине 80-ых её написал Грег Уолш. Конкретно та версия кода, которая показана выше (с забавными комментариями), действительно из кода Quake.
    В этой статье мы попробуем разобраться с данным хаком, математически вывести эту самую константу и попробовать обобщить данный метод для вычисления произвольных степеней от -1 до 1.

    Да, понадобится немного математики, но школьного курса будет более, чем достаточно.
    Читать дальше →
  • Метаклассы в C++

      В этой статье мы поговорим о новом предложенном расширении языка С++ — метаклассах. Герб Саттер с коллегами работал над этим предложением около 2 лет и, наконец, этим летом представил его общественности.

      Итак, что же такое «метакласс» с точки зрения Герба Саттера? Давайте вспомним наш С++ — самый прекрасный в мире язык программирования, в котором, однако, веками десятилетиями существуют примерно одни и те же сущности: переменные, функции, классы. Добавление чего-то фундаментально нового (вроде enum classes) занимает очень много времени и рассчитывать дождаться включения чего-то нужного вам здесь и сейчас в стандарт — не приходится. А ведь кое-чего и правда не хватает. Например, у нас всё ещё нет (да, наверное, и не будет) интерфейсов как таковых (приходится эмулировать их абстрактными классами с чисто виртуальными методами). Нет properties в полном их понимании, нет даже value-типов (чего-то такого, что можно было бы определить как набор переменных простых типов и сразу использовать во всяких там контейнерах/сортировках/словарях без определения для них разных там операций сравнения, копирования и хеширования). Да и вообще постоянно чего-то кому-то не хватает. Разработчикам Qt вот не хватает метаданных и кодогенерации, что заставляет их использовать moc. Разработчикам C++/CLI и C++/CX не хватило способов взаимодействия со сборщиком мусора и своими системами типов. Ну и т.д.

      А давайте на секунду представим, что мы сами можем вводить в язык новые сущности. Ну или пусть не прямо «сущности», а правила проверки и модификации классов.
      Читать дальше →
    • Прочитайте код своего продукта. Весь

      • Перевод
      Основываясь на всём моём многолетнем опыте разработчика и техлида, я могу с уверенностью назвать одну конкретную вещь, которая наиболее сильно повышает продуктивность работы программиста: это прочтение абсолютно всего кода разрабатываемого командой продукта. Это «простое» действие (хотя оно и займёт некоторое время, а также потребует внимания для понимания прочитанного), но удивительно, как мало людей в командах делают это. А ведь разработчики, которые никогда не читали всего кода, всегда будут зависеть от тех, кто сделал это.
      Читать дальше →
    • Изучите все языки программирования

      • Перевод
      Когда я был ещё первокурсником, то познакомился с другим студентом, который утверждал, что может писать код на любом языке программирования, который я смогу назвать. Я был несколько шокирован и ответил подначкой:

      — Что, даже на том нечитаемом эзотерическом языке, где есть всего пара команд, которые едва-едва симулируют машину Тьюринга?
      — Да, этот язык называется brainfuck. Я знаю brainfuck.

      И это был не трюк — мы проверили. Я называл известный мне язык программирования, он тратил пару минут в Интернете на то, чтобы освежить свои знания по нему — и был способен писать на этом языке работающие алгоритмы. Я никак не мог понять этого. Ему, как и мне, было тогда около 18 лет — как он мог в этом возрасте знать все эти языки?

      image
      Интерпретатор brainfuck, написанный на brainfuck

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

      Сегодня я советую своим студентам «постараться изучить все языки программирования». Подумайте сами — ведь эта идея лучше, чем все вот эти «В этом году я выучу Go! Ой, нет, теперь говорят что в моде Rust — выучу лучше Rust! Или Swift ...». Просто выучите все — не ошибётесь. А эта статья, возможно, вам в этом немного поможет.
      Читать дальше →
    • Вы — не Google

      • Перевод
      Мы, программисты, иногда почему-то сходим с ума. Причём по каким-то совершенно нелепым причинам. Нам нравится думать о себе, как о супер-рациональных людях, но когда дело доходит до выбора ключевой технологии нового продукта, мы погружаемся в какое-то безумие. Вдруг оказывается, что кто-то слышал что-то об одной классной вещи, а его коллега читал комментарий о другой на Хабре, а третий человек видел пост в блоге о ещё чём-то похожем… и вот мы уже пребываем в полнейшем ступоре, беспомощно барахтаясь в попытках выбора между совершенно противоположными по своей сути системами, уже и забыв, что мы вообще пытаемся выбрать и почему.

      Рациональные люди не принимают решения таким образом. Но именно так программисты часто решают использовать что-то вроде MapReduce.

      Вот как комментировал этот выбор Joe Hellerstein своим студентам (на 54-той минуте):

      Дело в том, что в мире сейчас есть где-то 5 компаний, обрабатывающие данные подобных объёмов. Все остальные гоняют все эти данные туда-сюда, добиваясь отказоустойчивости, которая им на самом деле не нужна. Люди страдают гигантоманией и гугломанией где-то с середины 2000-ых годов: «мы сделаем всё так, как делает Google, ведь мы же строим один из крупнейших (в будущем) сервисов по обработке данных в мире!»

      image

      Сколько этажей в вашем датацентре? Google сейчас строит четырёхэтажные, как вот этот в Оклахоме.
      Читать дальше →
    • Краткая история случайных чисел

      • Перевод
      «Когда я задался целью получить действительно случайное число, то не нашел для этого ничего лучшего, чем обычная игральная кость» — писал в 1890 году Фрэнсис Гальтон в журнале Nature. «После того, как кости встряхивают и бросают в корзинку, они ударяются друг о друга и о стенки корзинки столь непредсказуемым образом, что даже после легкого броска становится совершенно невозможным предопределить его результат».

      image
      (Игральные кости времён Римской Империи)

      Как мы можем сгенерировать равномерную последовательность случайных чисел? Случайность, столь прекрасная в своём многообразии, часто встречается в живой природе, но её не всегда легко было извлечь искусственным путём. Самые древние из игральных костей были найдены на Среднем Востоке, и они датируются примерно 24 столетием до нашей эры. Другим примером может быть Китай, где ещё в 11 столетии до нашей эры применялось разбивание ударом черепашьего панциря, с дальнейшей интерпретацией размера полученных случайных частей. Столетиями позже люди разрубали несколько раз стебли растений и сравнивали размеры полученных частей.
      Читать дальше →
      • +29
      • 14,5k
      • 9
    • Вы неверно измеряете загрузку процессора

      • Перевод
      Та метрика, которую мы называем «загрузкой процессора» на самом деле многими людьми понимается не совсем верно. Что же такое «загрузка процессора»? Это то, насколько занят наш процессор? Нет, это не так. Да-да, я говорю о той самой классической загрузке CPU, которую показывают все утилиты анализа производительности — от диспетчера задач Windows до команды top в Linux.

      Вот что может означать «процессор загружен сейчас на 90%»? Возможно, вы думаете, что это выглядит как-то так:



      А на самом деле это выглядит вот так:



      «Работа вхолостую» означает, что процессор способен выполнить некоторые инструкции, но не делает этого, поскольку ожидает чего-то — например, ввода-вывода данных из оперативной памяти. Процентное соотношение реальной и «холостой» работы на рисунке выше — это то, что я вижу изо дня в день в работе реальных приложений на реальных серверах. Есть существенная вероятность, что и ваша программа проводит своё время примерно так же, а вы об этом и не знаете.
      Читать дальше →
    Самое читаемое