Comments 8
У меня сложилось впечатление, что так много шагов потребовалось, потому что вы мерили не то, что действительно хотели. Хотели померить, какая реализация функции быстрее, а стали мерить все, включая запуск программы. Из-за этого вы очень много боролись с ядром, когда этого не требовалось. Например, копировали файлы в рамдиск, хотя после первого чтения они попадут в файловый кэш и не будут читаться с диска. Искали самый ненагруженный cpu и планировали задачу именно на него и раскидывали с него все остальные существующие userspace процессы на другие cpu — это же сделает планировщик задач при большой нагрузке. И ядро все еще может вытеснить ваш процесс. И если процесс не бездействует, а вы не запускаете другие ресурсоемкие процессы, то вероятность того, что его память будет вытеснена в swap нулевая.
А могли бы просто старым-добрым способом узнать время перед выполнением функции, прогнать ее множество раз, узнать время, рассчитать дельту. Сделать множество таких замеров и взять минимальное значение — тогда получите максимально правдоподобное значение, которое только возможно получить на системе общего назначения.
Иногда действительно есть смысл отобрать у планировщика несколько ядер для ресурсоемких вычислений. И это можно сделать даже так, что и ядерные потоки не будут планироваться на эти ядра — это параметр isolcpus. Тогда ваши задачи не сможет вытеснить никто, даже ядро. Правда, если у вас несколько таких изолированных процессов, то и балансировкой этих процессов между изолированными ядрами никто заниматься не будет.
Не понял заморочки с ramdisk.
Почему бы включить код непосредственно в ядро как статический модуль?
Так и надо было делать!
Пишется модуль на Си.
Модуль включается в статический список и mkinitcpio собирает ядро.
Потом создаётся qemu-виртуалка с ограниченными ресурсами.
В ней загружается ядро в single user mode.
Песочница для запуска готова.
Только меня смущает использование time, не слишком ли высокоуровневая тулза?!
Статья хороша как ликбез по Linux — лично я почерпнул что-то новое, за что благодарен автору.
Но вот именно решение задачи, на примере которой проводились бенчмарки, заставляет немного поволноваться. Причина возможного беспокойства — то, что определение чётности-нечётности работает только для two's complement целых чисел, представленных в памяти последовательностью битов. Здесь есть две вещи которые могу пойти не так:
- Представление целых чисел со знаком в системе может быть в форме one's complement, при которой отлицательные числа инвертируются (00000001 (+1) -> 11111110 (-1)), что делает невозможным и некорректным определение чётности через бинарное AND единицы с младшим битом. Да, здесь можно справедливо заявить, что one's complement представление уже никем не используется, но нет, и нет. Вероятность мала, но она есть.
- Числа в используемом языке/библиотеке/whatever могут представляться ну совсем не в виде последовательности битов ограниченной длины. В Common Lisp, который я всей душой люблю, в том числе за его систему типов, нет чётко специфицированного метода хранения bignum-ов, и число может, в зависимости от реализации языка, храниться даже в куче, по частям. Операции же над отдельными битами bignum-ов, в силу их реализации, часто превращаются в непредсказуемые числа, потому что программист мог не учитывать, к примеру, нули в начале числа, коих много, и получить при их инвертировании, к примеру, негативный ответ (вспоминаем, как работает two's complement и one's complement представление). Может случиться и такое, что определённая реализация определённого языка будет использовать младшие биты числа для какой-то своей нужды (что звучит подозрительно, но не значит, что кто-то так не сделает), а не для представления, собственно, низших битов числа, и при этом сможет допустить прямое взаимодействие с ними (нет программ без багов — есть только те, где их пока что не нашли).
Все эти риски могут рано или поздно выстрелить, потому рекомендация использовать модуло в общем случае для определения чётности относительно оправдана.
Тестирование производительности кода в ОС Linux с примерами