From 989c4b0aedc76eeaa57b22721ef3431019068c3c Mon Sep 17 00:00:00 2001 From: Sergey Matveev Date: Thu, 8 Apr 2021 15:22:58 +0300 Subject: [PATCH] =?utf8?q?=D0=A3=D0=B4=D0=B8=D0=B2=D0=B8=D1=82=D0=B5=D0=BB?= =?utf8?q?=D1=8C=D0=BD=D0=BE=20=D0=BC=D0=B5=D0=B4=D0=BB=D0=B5=D0=BD=D0=BD?= =?utf8?q?=D1=8B=D0=B5=20=D0=BE=D0=BF=D0=B5=D1=80=D0=B0=D1=86=D0=B8=D0=B8?= MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit https://gregoryszorc.com/blog/2021/04/06/surprisingly-slow/ Понравилась статья о том, что на наших мощнейших компьютерах, некоторые операции могут быть на удивление медленными. * Environment detection in build system Множество раз замечал что, действительно, сама сборка софта может занимать в разы меньше времени чем отработка autoconf ./configure скрипта. На работе когда я перевёл Си проект, в котором прилично вещей автоматически определяется, на redo, то все эти цели стали распараллеливаться и конфигурирование плюс сборка занимают пару секунд * Про fork/exec overhead и file close на Windows системе не в курсе, ибо не работаю с этим миром в принципе * То что можно в разы ускорить сборку софта просто не заставляя выводить это всё в терминал -- давно знал. Медленные терминалы это ещё какая реальность, особенно часто они почему-то являются default-ными в системе. Ну и то, что сам по себе системный вызов write() имеет вполне себе ощутимый вес -- об этом тоже не забываю и вовсю стараюсь буферизировать данные в памяти перед его вызовом * С изменением частоты процессора не особо знаком. Уже давно все ноутбуки держу в режиме постоянного числодробления и полного отключения всех этих фич по управлению питанием и частотами -- и стабильность и простота. Но да, помню что читал про забавный факт о том что если заряжать Apple ноутбуки не с той стороны -- то будет падение производительности. И особенно на текущем ноутбуке я замечал что запустив какую-то ресурсоёмкую задачу можно поднять частоту, соответственно и производительность и снизить время выполнения многих команд, из-за которых процессор даже не попытается ускориться. У меня в фоне distributed.net числодробящий клиент висит с idprio 31 приоритетом поэтому. Экономия это конечно хорошо, но всему должна быть мера * Время запуска интерпретаторов Python, Ruby, Node.js -- оно просто громадное! Именно только из-за этого времени я множество скриптов и программ переписывал на другом языке. Запуск долгоживущего сервера -- не критично сколько будет запускаться, но если это часто вызываемая утилита (даже просто для ведения заметок), то жутко угнетает видимая задержка * Раздел про I/O я не очень понял. Ну точнее я прекрасно понимаю почему fsync() может быть достаточно медленной операцией -- для меня это не вызывает удивления. Видимо, потому что любил читать и понимать устройства файловых систем. Ну а то что из-за NVMe действительно кардинально может меняться подход к I/O -- это да, факт. С NVMe I/O может перестать быть бутылочным горлышком, чем оно де-факто всюду и везде всегда являлось * И отсюда, соответственно, появляется и тот факт, что сжатие данных может наоборот вести к тому, что CPU будет узким местом, а не дисковая подсистема или сеть. Благо, у меня чёткое осознание что нужно проверять где и в чём затык, а не слепо что-то там пытаться сжимать. Иногда сжатие может помочь с уменьшением кол-ва round-trip-ов, из-за уменьшенного кол-ва пакетов, тем самым сокращая задержки, хотя запросто и ни капли не увеличивая пропускной способности * Тема про то, что заранее скомпилированные пакеты/бинари могут не иметь кучу оптимизаций под современные процессоры -- мне тоже хорошо знакома. Когда я пользовался FreeBSD на AMD K6-2 233MHz, то точно помню перекомпилирование всей системы/ядра/софта с нужным -march позволяло на 10% поднимать производительность в целом. Ещё один довод чтобы собирать софт из исходников. Хотя я скорее поверю и в то, что в общем случае для yet another home computer или yet another server все эти оптимизации не существенно чем будут помогать. А CPU-hungry софт и так следит за тем чтобы собираться с нужными оптимизациями * Тема про то, что банальное разбиение на строки может быть более долгой операцией чем целые алгоритмы создающие diff на основе этого -- мне тоже понятна. И, честно, когда в Go приходится что-то делать над каждым байтом/символом просто итерируясь -- скрепя сердцем, закрываю на это глаза, слепо надеясь (зная что это наверняка не так) что компилятор мог бы это и прооптимизировать Но вообще это отличные примеры того что нужно всегда всё мерить, а не делать предположения, если неизвестно устройство/особенности. Без устали повторяют про то, что надо оптимизировать нечто только после измерений и понимания что действительно такое то место является бутылочным горлышком. -- 2.50.0