Архив категории: performance

lowlevel performance

glibc’s memory allocator

malloc_never_fails_tshirt-r8bdfeac6456e4703803a0d7bb91679da_va6lr_512
Когда приложение интенсивно создаёт и удаляет различные объекты при этом не производя над ними каких-либо ресурсоёмких вычислений, производительность приложения ограничивается в основном подсистемой управления памятью. И для более аккуратной разработки приложения необходимо воспринимать эту подсистему уже не как «чёрный ящик», а уже учитывать некоторые его особенности. Рассмотрим аллокатор из библиотеки glibc на платформе linux x86_64.

Какое же API предоставляет аллокатор из glibc? Как он работает? Какие неожиданности в себе таит? Читать далее »

performance programming

Погрешность вычислений с числами с плавающей запятой

В ходе всех этих развлечений с оптимизациями обнаружился интересный, но очень неприятный эффект. Результат вычислений для разных компиляторов и разных флагов оптимизации порой значительно менялся.
Для более удобного наблюдения этого эффекта был выбран простой пример(полный код на github):

В этом маленьком тесте изменение результата от изменения флагов обнаружить не удалось, но всё равно обилие результатов удивляет — 5 различных, с 13 совпадающими знаками из 15-17 возможных для double.

Исходник и компилятор Результат Время выполнения, с
Assembler 1.53436944477410652787 3.81
gcc long 1.53436944477462278158 4.4
gcc double 1.53436944477389380914 4.4
icc long 1.53436944477397574360 6.88
icc double 1.53436944477334602510 1.50

*результаты по одному измерению, по этому совсем серьёзно воспринимать их не стоит. Время указано для процессора FX-8120
p.s. ну и обнаружилось, что написание кода на ассемблере пока ещё не абсолютно потеряло смысл — получился до 15% быстрее, чем на C.

performance programming

CUDA мы катимся?

Сразу извиняюсь за название — взято с потолка.
Неудержался и нафигачил вычислительную задачу, которую уже упоминал в прошлых топиках на CUDA. Ничего хитрого не делал — просто расставил директивы __device__.
В итоге получилось даже медленнее чем на CPU раз в 5 :’-(
Сей ужас можно увидеть здесь.

performance programming

Хватит использовать устаревший софт!

Каким бы тёплым и ламповым старый софт не был, но рано или поздно от него приходится отказываться, и сейчас я покажу это на примере компиляторов.
Допустим у нас есть приложение, которое выполняет некоторые вычисления.
Попробуем скомпилировать его различными версиями gcc и icc. И измерим время выполнения. Опции компиляции следующие:

Версия компилятора Время выполнения,c Во сколько раз медленнее лидера
gcc-4.1 70.0 3.68
gcc-4.3 45.3 2.38
gcc-4.4 45.9 2.42
gcc-4.5 34.9 1.84
gcc-4.6 34.7 1.83
gcc-4.7 34.9 1.84
icc-13.1.1 19.0 1.0

Читать далее »

build linux performance programming

Операционные системы и фарс с производительностью

Закончился простой тест производительности двух ОС: Windows 7 и Linux (Xubuntu 12.10)

Эксперимент:

  1. Выбирается проект на Java, с большим числом модулей, проектных файлов, зависимостей и этапов сборки
  2. Собирается начисто без замеров времени
  3. Собирается повторно, время замеряется, этот этап повторяется несколько раз, вычисляется среднее время

Использовались: система сборки Gradle (режим --daemon), JDK 1.7_13 (x64).
Файловые системы: Windows — NTFS, Linux — ext4.
Все ОС в тесте 64-битные, файлы проекта и файлы системы (а также приложений) расположены на разных физических дисках.
Для виртуальной машины использовался Oracle Virtual Box (4.1), в качестве хоста Windows 7, без дополнительного дискового кэша на стороне VM.

Итого:

Операционная система Время сборки, сек (PC 1) Время сборки, сек (PC 2) Время сборки, сек (PC 3)
Windows 7 20.5 22.0 21.2
VM Xubuntu 12.10 14.6
Xubuntu 12.10 9.4 9.6

Приведённые результаты для машины, на которой пробовались все варианты ОС, получены без специальных настроек производительности.

Результаты плачевны. И можно сколь угодно спорить о настройках, тюнинге, особенностях. Интегральная производительность вот такая.
Ну а я уже перешёл на правильную ОС.

CPU hardware performance

Тесты производительности нескольких отдельно взятых процессоров

Собрал ядрышко линукса на 2х своих машинках(и ещё на одной товарища artamonov). Конфигурация — которая генерируется при запуске и выходе make menuconfig. Это около 2500 модулей и ещё много всего ненужного.
Читал как-то что потоков нужно больше чем ядер, т.к. что-то полезное они начинают делать не сразу. Оказывается это не особо то и нужно, и даже, скорее, вредно. Ниже есть тесты с разным количеством потоков.
Intel(R) Core(TM) i5 CPU 760:

AMD FX(tm)-8120 Eight-Core Processor:

AMD FX(tm)-8120 Eight-Core Processor:

Intel(R) Core(TM) i7 CPU 2600K:

Intel(R) Core(TM) i7 CPU 2600K:

Читать далее »