Есть сетевая прилага. Ее нужно протестировать на нагрузку. Понять, почему ограничивается скорость - ethernet-платой или, может, записью информации на диск.
Как вообще проводят тестирование (не функциональное) сетевых утилит?

1) Выясняют, почему им неподходит netperf.
2) Пытаются найти что-нибудь такое жэ, но другое.

А как измеряют нагрузку на систему (загрузка ОП, загрузка процессора)?
Интересен еще такой факт, как узнать, куда записывается пакет сетевая карта - в оперативную память или сразу в кэш (для эффективного использования процессорного кэша)? 
Как узнать время обработки пакета? Как я понию, то только тесты, написанные вручную, или подойдут утилиты, которые измеряют время работы участка кода? Где-то видел такие, но не понимаю, как работают. Смотрят ли они только написанный пользователем код или считают еще системные вызовы? А что с динамической линковкой?

Добавлено через 6 минут и 14 секунд
И какие есть средства и/или методы, для увеличения производительности?

вопрос бредовый. К кэшу процессора имеет доступ только сам процессор. Сетевая карта принимает данные в свою внутреннюю память, а потом по требованию выдает. Теоретически возможен вариант, когда сетевуха использует системную память для этого, но не думаю, что в обычных машинах это используется (ради экономии нескольких десятков центов геморроиться с синхронизацией?). Если сетевая карта хоть немного умная (не только PHY), то процессор она грузит по минимуму - ему остается только принимать/передавать готовые пакеты данных (преобразование и проверку целостности производит сама сетевуха, а когда данные готовы, то высылает сигнал процессору).
Если речь про твой код, то профилер тебе в помощь (man gprof).
Профилеровщики считают разницу времени на входе и выходе из твоей функции.
А что не так?
Это все имеет общее название "оптимизация". Для начала включи оптимизацию компиляции (попробуй каждый вариант: -Os, -O2, -O3), если не поможет, то тогда надо с помощью профилеровщика найти узкое место и как-то его ускорить. Возможно, придется применить openmp, opencl или даже ассемблер.

Как это не странно, вопрос не совсем бредовый   У Intel есть технология DCA (Direct Cache Access) в группе Intel I/O Acceleration Technology, которая позволяет заливать данные с PCIe непосредственно в кэш:
Доступно только в серверных чипсетах, и никаких спеков не нее нет (только рекламные брошюры)   

я читал про прямой доступ к кэшу здесь

Как правильно сказал xvr, у Intel есть такая технология, чего я, к слову, не заметил, что речь идет только про intel, а не все современные процессоры.


почему нет, если это не идет в убыток компании, проекту или еще чему-нибудь?
да и тем более, если можно это сделать и проверить, почему бы это не попробовать, если хочется?
Но не об этом спор:)




Да, про него читал, спасибо:)



Это понятно. Но это то, на что я не совсем могу влиять. Я могу только компилятору помочь. А вот как помочь, вот об этом и спрашиваю, а не о самих алгоритмах:)
Чтобы было понятнее, вот примеры:
Ключевое слово restrict
или что-то такое
 
Вот тут выражение  
будет при каждой итерации высчитывать или только один раз?
Если при каждой, то можно ведь сделать так:


Вот о каких-то таких практиках имел ввиду 
Есть такая организация CERT, где на у них на сайте собраны стандарты по безопасному программированию и книги есть. Вот и подумал, что может есть какой-то ресурс(ы), где что-нибудь собирают подобное для лучшей оптимизации под определенный компилятор. Конечно, меня интересует gcc, но было бы интересно посмотреть и на другие:)

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


про intel - на сайте intel

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

Я не знаю, с чего начать отвечать, и вряд ли когда-нибудь соберусь.

Добавлено через 3 минуты и 52 секунды


Осцыллографом. Я серьёзен -- учитывая буфера карточки, все программные методы требуют слишком хорошэго понимания жэлеза (PCI/конкретная карточка/вот это всё), чтобы пытаться начать выяснять на них этот вопрос.

Впрочем, этот вопрос чаще всего интересует людей для HFT. для всего остального -- измеримого на соседней с испытуемой системе раундтрипа в 200мкс вполне достаточно, а интересует throughput, который ужэ вполне реально померить.

Добавлено через 14 минут и 37 секунд


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

Если f(i) -- какая-то достаточно простая функцыя без побочных эффектов (в частности, без записи глобальных переменных, да вроде дажэ и без чтения, хотя здесь я могу ошыбаться, и чтение переменных, не объявленных volatile допускается если там потом в цыкле тожэ всё вычислимо и не изменяет этой жэ переменной), которая определена в том жэ исходнике, что и этот цыкл или вообще является макросом, и something[i] -- не объявлен volatile и не изменяется в теле этого цыкла -- то компилятор можэт решыть, что можно и закэшыровать значение этого выражэния.

Шансов на это, впрочем, не много, и если ты считаешь, что k = f(i)*something[i] будет быстрее -- то лучшэ ставь так.

Впрочем, практика -- критэрий истины...

Да, первые проблемы в скорости, которые обычно надо решать -- алгоритмические. Т.е. O(n^2) где достаточно O(n*log(n)) или наоборот иницыализатор итэратора O(log(n)) занимает большэ, чем в среднем требуется для простого прохода O(n^2).

Потом -- cache locality, оптимизацыя хранения и выборки данных, вот это всё.

Вопросы правильного заполнения конвеера (нужными командами и малым количеством нужных ветвлений) -- идут чаще на третьем месте.

Стрэсс-тэстами, чаще всего.

А на боевую систему -- есть top, iotop, несколько других и системы мониторинга (nagios/zabbix/etc), которые рисуют графики и шлют сообщения при перегрузках.

Правильная -- в оперативную память (ну, возможно, сейчас в L3 кэш, в общем, именно туда, куда PCIe контроллер пишэт), херовые -- сразу в кэш.

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

Под архитектуру есть - http://www.intel.com/content/dam/www/publi...tion-manual.pdf