Практика показывает, что в больших командах, особенно с большой wintel частью не выберут и не быстро и git тут лишь верхушка айсберга. Единственное, что остается делать профессионалам так это медленно и планомерно создать невыносимые условия для неэффективных подходов и простые и легкие для эффективных.

По моему истина где-то посередине. Приведу простой пример. Я работаю в конторе, где для работы над продуктом мы вынуждены были портировать код под нормальные архитектуры от wintel «команды». Эти лохи используют древнючие компиляторы из-за которых куча ненужных костылей в коде, и даже ими толком не умеют пользоваться, не используют систему контроля версий (точнее у них начальник использует VSS просто тупо складывая туда надерганные файлы от других разработчиков) в результате невозможно даже движение наших патчей критинизма назад и каждый новый релиз кода этих орлов это серьезная головная боль для всей цепочки. Это явная ситуация, где необходим принудительный перевод на git flow начала цепочки, принудительное соблюдение стандартов, стиля кодирования, изменение архитектуры, подхода к тестированию, релиз планов…

Возьмите сначала логарифм, тогда задача сведется к складыванию :)

long long в примере вместо size_t ранит сердца опытных разработчиков (особенно знающих, что такое n32).
Кроме того всегда нужно оценивать необходимую разрядность мантиссы вместо тупого использования double вместо float.

Если в вашем числе с плавающей запятой P разрядов (7 для float, 16 для double) точности, а в ваших данных S разрядов значимости, то у вас остаётся P-S разрядов для манёвра и можно сложить 10^(P-S) значений без проблем с точностью. Так, если бы мы использовали 16 разрядов точности вместо 7, то могли бы сложить 10^(16-3) = 10 000 000 000 000 значений без проблем с точностью.

(Существуют численно стабильные способы сложения большого количества значений. Однако простое переключение с float на double гораздо проще и, вероятно, быстрее).

Проблемы с точностью у double могут возникнуть уже после сложения 2 чисел при разности порядков более 13, разве нет?
Не нужно поселять необоснованную уверенность универсальности double в мозги юных подаванов.
И это не частность, достаточно не мало задач, где нас интересует потом SAD в данных или именно младшие разряды.

Поправляю опечатку, на всякий случай, latency — это задержка (время) выполнения инструкции (и вообще чего либо) а не скорость.

Обычно бывает наоборот, если у нас большие задержки на I/O, то для увеличения IPC нужно поместить, как можно больше вычислительных инструкций не связанных с необходимым I/O между I/O инструкциями.

Нет, не обязательно так, IPC может быть меньше 1 не только из-за задержек при доступе к периферийным шинам.
Есть куча инструкций которые выполняются больше чем один такт и не позволяют их выполнять параллельно с другими.

BTW непонятно, почему автор считает IPC>1 проблемой производительности?

Проблема производительности это скорее IPC не близко к максимально возможному для данной архитектуры CPU.
Конечно для окончательного вывода требуется более комплексный анализ алгоритма, оптимальности загрузки внешних шин, кэшей, page faults, branch miss predictions, interrupt rate, trap/exception/taskswitch/cpu migration rate.

Небольшое пояснение на то, что измеряется в качестве загрузки CPU для процесса.

В моменты времени когда может осуществляться принудительное переключение контекста задачи (т.е. 1 раз за JIFFY) происходит инкремент в структуре task активных в данный момент задач их load_time. Поэтому если по каким либо причинам переключение задач окрашено данная статистика может «безбожно» врать. Т.е. мы, например, можем сделать искусственный процесс, который будет на 100% загружать ресурсы CPU четко между JIFFY затем переключаться в режиме I/O SHCHEDUILIG на короткое время на другой процесс и результатом будет 0% загрузка по данным TOP.

Если бы ребята приняли в стандарт атрибут при декларации целочисленной переменной для указания endian при ее сериализации, как это будет в стандарте для ANSI C (и уже реализовано в новых GCC), то очень много ABIшного кода можно было бы выпрямить и избежать многих ошибок.

Конкретно команда ls имеет столько флагов по причине оптимизации.

Если все реализовывать в виде последовательности фильтров, то на больших файловых системах, где в каталогах бывает > 10^6 файлов будет невозможно получить необходимый функционал либо он потребует неадекватного количества ресурсов.
— Кроме того непонятен наезд на иерархичность файловых систем. В UNIX это вообще-то многосвязный граф (с возможностью использования механизмов предотвращения зацикливания при рекурсивном сканировании), а вовсе не строгая иерархия.

Замечание.

Оптимизация JPEG происходит за счет построения оптимальной таблицы Хаффмана вместо таблицы по умолчанию, применяющейся большинством JPEG кодировщиками по известному алгоритму (типичный выигрыш ~20% объема) перед Хаффманом есть еще стадия RLE (run length encoding), которую теоретически можно немножко подстроить под последующий Хаффман и выиграть доли процентов на которые в общем-то и отличаются оптимизаторы.

А вовсе не за счет подбора параметров компрессии которая для JPEG это изменение коэффициентов таблицы квантования, любое уменьшение которых ведет к потере качества, либо никак не сказывается на размере картинки, если уменьшают коэффициент для отсутствующих частот после FDCT.

Оптимизация PNG происходит за счет более умного упаковщика LZ77 который по сути находит и кладет в словарь более длинные и более часто встречающиеся цепочки входных «символов».

Здесь действительно возможен вариант подбора настроек для DEFLATE (LZ77+Хаффман) алгоритма типа размера словаря и окна, но это дает слабый выигрыш.

Первое что приходит на ум сравнить логи tcpdump/wireshark c логами strace -tt
на типичном офисном x86-32 и x86-64 точность будет порядка 50us если нужно точнее тогда придется встраиваться в ядро и «дампить» куда-нибудь в «отмепленную» память результаты rdtsc и в user space сравнивать и не забыть привязать ваш event loop к конкретному ядру процессора. На ppc и mips аналогично а вот у arm плохо с таймерами и гранулярность порядка 100ns к сожалению обычно предел :(

Кстати не забывайте отключать алгоритм nagle, если вам важна скорость доставки сообщений через TCP (TCP_NODELAY и выключенный TCP_CORC вам в помощь)

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

Не целесообразно на больших масштабах времени из за накопления ошибок измерения. Кроме того далеко не во всех смартфонах есть 3D магнитометр и гироскопический датчик.

В этом нет ничего удивительного поскольку всю первичную обработку делает GPS/GLONASS приемник, который всего лишь отдельный модуль телефона, а доступа у телефона к сырым данным нет (меткам точного времени спутников и их ID). Софтом телефона возможна лишь вторичная обработка по фильтрации навигационного решения, которая весьма сомнительна при небольших искажениях решения и может быть сведена к инвалидации данных решения при его больших искажениях (минимум >150м) если доступны надежные альтернативные источники данных навигации и времени (Сети сотовой связи, WIFI сети, и прочие).

В протестированных нами приемниках uBlox и МНП данные GPS при дефолтных установках имеют больший приоритет. ГЛОНАС спутники попадают в список спутников не участвующих в навигационном решении при даже несущественном расхождении решений не смотря на заметно больший уровень SNR. МНП к томуже глюкавая поделка, и от ее использования мы в итоге отказались из за многочисленных проблем главная из которых надежность.

Минимум 6 вариантов для локального android устройства:
1. Подменяешь символьное устройство на FIFO (модифицируя udev скрипты или жестко ручками через unink и mkfifo) в которое потом пишешь свои сгенерированные NMEA данные.
2,3. Делаешь это же но на уровне драйвера или через strace.
4,5. Модифицируешь библиотеку доступа статически или через LD_PRELOAD…
6 через штатную эмуляцию местоположения.