Какие функции для работы с файлами на си вы предпочитаете?

ни разу о таком не слышаала. подозреваю, что это байка. разработчикам нет смысла скриывать команды.

да и медленно это всё

Не скажи. Я когда на бтр сидел, то использовал сжатие lzo, которое давало прирост производительности даже на слабых процах, вроде n450.

ну, есть разные ФС, которые вообще применяют сжатие данных. правда, я сто лет их не применяла, потому что сейчас это неактуально. да и медленно это всё. как и вывод в stdio. много туда не выведешь. будет тормозить.

Это палка о двух концах. Сжатые данные гораздо быстрее пишутся/читаются, поэтому в итоге можно даже выиграть в скорости.

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

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

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

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

ты измерял этот «прирост»?

Да, измерял. Конкретные цифры сейчас уже не приведу, т.к. тесты делал давно. Да и с бтр слез. На практике это приводило к тому, что программы запускались несколько быстрее. Разница была в единицы секунд, но всё же.

потому что лично гоняла много тестов со сжатием данных. и в 99% случаев оно приводи только к проседанию.

Потому что нужно использовать быстрое сжатие, которое «заточено» на скорость. Я когда zstd:15 для прикола включил, то при обращении к диску начались подвисания даже в тех местах, где их раньше не было.

Там суть в том, что уменьшается поток данных через интерфейс. Поэтому, если алгоритм сжатия использует минимум процессорного времени, то это даёт некий прирост. На обычных блинах это ощзущается в работе. На ссд это не заметно.

да какое угодно. гоняла на разных. один хрен не стоит овчинка выделки. и «быстрое» сжатие всё равно жрёт проц. то есть, производительность проседает.

и «быстрое» сжатие всё равно жрёт проц

Имхо, проблема даже не в сжатии как таковом, а в том что позиционироваться становится дОрого.

и «быстрое» сжатие всё равно жрёт проц

Конечно жрёт. Только ты учти, что при загрузке большого количества данных, процесс будет висеть в D в ожидании данных и процессор будет тупо «дежурить». А вместо этого он мог бы заняться распаковкой данных и тогда суммарный объём информации, который будет прочитан с диска, будет меньше. В результате время, которое потребуется для чтения данных с диска, будет меньше.

и это тоже. но основная нагрузка на проц - это сами алгоритмы сжатия/распаковки.

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

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

«Конечный» то как раз очень даже предсказуем

Ты ж написал, что не ясно какая из записей окажется на диске, как же «известен»?

запись с пожатием будет медленнее, чем запись без пожатия.

100% ложное утверждение. Если не рассматривать какие-то адово конские SSD за кучу денег с кучей PCI-e линий в них, то скорость записи в среднестатистический SSD в разы ниже, чем проц сможет пожимать данные. Таким образом, жмущиеся данные однозначно стоит всегда жать перед записью и через такой конвейер рельных данных на диск можно пихать с гораздо большей скоростью.

Ты ж написал, что не ясно какая из записей окажется на диске

Правильно. На момент выхода из fsync().

как же «известен»?

Между вами и диском - PageCache. Вы даже не можете просто так посмотреть что именно на диске в обход него. Eventually последняя запись упадёт на диск. Любые попытки чтения будут возвращать её вне зависимости синкнулось оно уже или нет.

Для этого в протоколах SATA/NVME/SCSI имеются специальные команды,

И что за команды такие? Имя, сестра!

Скорее всего, он имеет в виду барьерные запросы.

Что за бред? Многоядерное сжатие bzip2 даёт 22 мб/с. https://habr.com/ru/articles/53217/ Это на порядок ниже скорости унылого Sata SSD и на два порядка ниже бытового PCI-E SSD из ноутбука школьницы.

Если пишешь портабельные утилиты, то FILE*. Я предпочитаю писать портабельный софт, что не привязывается к ОС.

fd только если очень нужна производительность (и буферизацию делаешь сам) или доступ к каким-то особым объектам Linux (pipe например).

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

fsync() не гарантирует в реальном мире вообще ничего - ни просто записей на диск

По стандарту гарантирует, и обеспечивается это тем что ядро пошлёт железке FLUSH CACHE. Конечно же есть железо которое FLUSH CACHE может проигнорировать, но его обсуждать нет смысла - опять же, на нём физически невозможно построить надёжное хранилище.

Серьёзный банк-ентерпрайз, использующий fsync в коде, будет отличаться от прочих организаций тем, что отвечающие за работу софта ОТЧЁТЛИВО себе представляют, что будет происходить при вызове fsync в ФС

Кончай фантазировать про то что ты никогда не видел. Какие-то банки-ентерпрайзы, это смешно просто читать. Никто в банках и ынтерплайзах понятия не имеет ни про какие fsync - там просто ставят сертифицированное железо и сертифицированный софт. Сертифицированное железо всего лишь не игнорирует FLUSH CACHE, а сертифицированный софт написан со знанием гарантий fsync, только и всего.

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

(вся мультимедия)

this

Она уже пожата, т.к. формат такой.

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

Фактически, по моему опыту, фс со сжатием хороши:

1. для архивов текстовых файлов с которыми есть активная работа: логи, html страницы, архивы чат переписок и т.д.

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

хм.

http ответы можно жать, но это только для экономии трафика и канала, в целом иногда может быть полезно.

https ответы жать смысла нет, почти не сожмется.

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

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

Это ты попробуй. На FreeBSD в ZFS, например, lz4 включено по умолчанию, и да, оно увеличивает пропускную способность всегда, и на HDD и на NVME. И почти не имеет накладных расходов, во-первых, потому что сжатие лёгкое, во-вторых потому что быстро определяет нежмущиеся данные и не тратит на них время. Чтобы не быть голословным,

% for _ in $(seq 5); do dd if=linux-6.17.tar of=/tmp/linux-6.17.tar bs=1m 2>&1 | grep /sec; done

sudo zfs set compression=lz4 zroot/tmp

1600399360 bytes transferred in 2.840330 secs (563455462 bytes/sec)
1600399360 bytes transferred in 3.231491 secs (495251043 bytes/sec)
1600399360 bytes transferred in 3.012270 secs (531293397 bytes/sec)
1600399360 bytes transferred in 3.539470 secs (452157865 bytes/sec)
1600399360 bytes transferred in 3.356365 secs (476825182 bytes/sec)

sudo zfs set compression=off zroot/tmp

1600399360 bytes transferred in 4.714207 secs (339484350 bytes/sec)
1600399360 bytes transferred in 4.085581 secs (391718907 bytes/sec)
1600399360 bytes transferred in 5.577560 secs (286935380 bytes/sec)
1600399360 bytes transferred in 6.641107 secs (240983835 bytes/sec)
1600399360 bytes transferred in 5.086201 secs (314655154 bytes/sec)

Ну может сейчас сплошная медийка в твоем трафике сидит, ее жать смысла нет. Раньше для модемов сжатие было обычным делом, да и сейчас в ppp этот функционал остался. Но это да, для экономии трафика.

Мелкие пакеты лучше не жать, от этого одни проблемы будут. Вообще пакеты лучше не жать, это же странно! Жать надо данные до разбивки на пакеты. Но в сегодняшнем мире веба это все стало бессмысленно, т.к. почти все медийка и почти все https, они не жмутся.

И почти не имеет накладных расходов
lz4

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

да полно ещё html, а это текст. но да, мультимедии в основной массе, конечно, больше. потому что она жирнее. но текст тоже фигово сжимается. я на тексте пробовала. просто нет смысла.

но текст тоже фигово сжимается.

?!

Возможно ты непонятно что пробовала. Сжимала пакеты, а не данные. В этом случае, конечно, эффекта особо не будет.

vectored i/o, writev() etc

Тоже мимо. Профит от экономии трафика действительно может быть не очевиден, если вебмастер будет думать только о себе и положит хер на клиентов многие из которых платят за трафик и имеют довольно скромный и нестабильный радиоканал. Но в современном вебе абсолютно критична лейтенси, а сжатие уменьшает её в разы. Это замечательно видно на клиентских метриках типа TTFB, всяких pagespeed insights, и даже на потреблении ресурсов сервером - когда запрос можно передать в 2 раза быстрее, одновременно живущих запросов в 2 раза меньше, и на них тратится в 2 раза меньше памяти. А CPU даже от gzip сжатия не видно на фоне нагрузки от базы и приложения.

У меня, к сожалению, графиков с огромной ступенькой от включения компрессии не осталось - мне профит от этого стал очевиден настолько давно, что тогда ещё для мониторинга использовался уродец munin вместо графаны.

порядок тормозов совсем другой, но всё равно сискол дёргается

нет, я очень понятно что пробовала. и для каждого пакета при сжатии отправляются также дополнительные данные: CRC и вот это всё. и это накладные расходы. так что для мелких текстовых данных это тоже оказывается невыгодно. и медленно.

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

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

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

конечно, пакеты. смысл сжатия http трафика в сжатии пакетов

Что ещё за пакеты ты жала? HTTP про пакеты ничего не знает, он несколько выше уровнем, и жмётся там поток данных. На пакеты сжатый и несжатый трафик режется совершенно одинаково, пакеты получаются абсолютно такого же формата без каких-то дополнтельных данных типа «CRC и вот этого всего».

Вот смысл этого то мне и непонятен, чего ты ожидала?

Вот у тебя 1000 tcp пакетов, ты их сжала, но все равно их 1000. Потратила процессорное время на сжатие, потом его еще потратят на декомпрессию. Небось, еще это перенесло часть нагрузки с сетевой карты на проц. Если кол-во пакетов не уменьшается, то смысл их сжимать?

Другое дело, если ты сжала сами данные, и потом разбила на пакеты, тогда выгода может быть весьма существенной.

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

Но эт такое, интереснее другое, если например напрягать тачку сутки в режиме без сжатия и с сжатием, а потом посмотреть сколько по времени проц был занят накладными расходами, то можно сделать «ой». Ну типа на спринте в частном случае показатали здоровские, а на марафоне, проц вместо полезной нагрузки молотил хероты много, отнимая вычислительное время от основных задач. Просто он отнимат так размазано во времени что минус от всего этого виден только в масштабе.

Иными словами, всё зависит от ситуации. Например слать по сети в gzip чаще выгоднее и быстрее и даже энергоэфективнее (в теории тут я набрасываю) чем слать просто так.

может, на совсем дохлых каналах что-то там и «видно», особенно на древнем софте и музейном железе. но в обычном вебе это только жрёт проц и ничего не даёт. на клиенте это тоже жрёт проц, кстати. потому что надо распаковывать.

Но в современном вебе абсолютно критична лейтенси, а сжатие уменьшает её в разы.

во-первых, в вебе лейтенси неактуальна и риалтайм там в принципе нереализуем. но его туда никто и не пытается пихать, потому что там гоняется жир, который всё равно будет тормозить. и всё это ходит через произвольное количество серверов и каналов с разными пропускными способностями, где скорость значительно падает. во-вторых, средний размер пакета в вебе 1000 байт. и пожатие тыщи байт никак не ускорит «лейтенси». а вот накладных расходов добавит.

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

во-первых, в вебе лейтенси неактуальна

Ах, вот оно как. Ну иди и читай https://developers.google.com/speed

риалтайм там в принципе нереализуем

Покажи в моём сообщении слово рилтайм

во-вторых, средний размер пакета в вебе 1000 байт. и пожатие тыщи байт никак не ускорит «лейтенси». а вот накладных расходов добавит.

Опять ты со своими пакетами - прочитай для начала как работает HTTP, и осознай что жмётся весь ответ, а не отдельные пакеты. Ответ в 1000 байт действительно нет смысла жать, но средний размер ответа таки гораздо больше. Как и на что влияет размер ответов я уже написал.

а в определённых условиях может ещё и начать жрать больше трафика. например, всякие модные ныне json-api будут жрать больше. потому что пакеты мелкие

Честно говоря, ты пишешь какую-то чушь.

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

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

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

Тут нет никакого нюанса, чтение данных также как и запись упирается в пропускную способность диска, а сжатые данные читать можно быстрее. И в кэш их влезает кратно больше. Кроме того, декомпрессия сильно легче компрессии, поэтому накладных расходов тут ещё меньше.

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

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

прочитай для начала как работает HTTP, и осознай что жмётся весь ответ, а не отдельные пакеты

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

чушь пишешь ты. погоняй реальный трафик и увидишь сам.

поэтому накладных расходов тут ещё меньше.

меньше - не значит, что их нет. а при отсутствии компрессии их просто ноль. и это не только время, это тоже работа проца. а так как работа с ФС происходит не всегда строго последовательно, то кэши тоже засираются и обновляются. так что они не очень-то спасут при рандомном обращении к диску.

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

и ты мне пытаешься доказать, что есть какой-то магический способ улучшить КПД системы вопреки закону сохранения. но этого не бывает в физическом мире. ты получаешь какую-то временную/частичную выгоду за счёт потерь в других ресурсах. только и всего. и потерь всегда больше, чем полученной выгоды. это физика, через неё не перепрыгнешь.

Для ATA: FLUSH CACHE, FLUSH CACHE EXT; для SCSI: SYNCHRONIZE CACHE.

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

Если не знаешь даже терминологии, то latency это просто задержки, они бывают и наносекундые, и секундные, и к rt отношениями никакого не имеют, к rt имеют отношение дедлайны. В вебе задержки критичны, документации я тебе насыпал.

если у тебя HTTP ответ не поместился в один пакет, то это практически всегда значит, что передаётся какая-то мультимедия

Расскажи, всё-таки, что за пакеты ты имеешь в виду. IP пакеты? В IP пакет обычно влезает меньше 1500 байт, где ты видела ответы таких размеров? HTML морды лора, очень лёгкого сайта, весит 48kb, например. Сжатый 12kb. Это в 4 раза меньше пакетов, в 4 раза меньше время на передачу, в 4 раза ниже вероятность потери одного из пакетов ответа, что приведёт к задержке в несколько round trip. Это если даже не погружаться в tcp transmit window, из-за которой начиная с некоторого размера передача становится в разы медленнее.

ты получишь оверхед на каждом пакете и тоже тормоза

Я ещё раз повторяю, от включения сжатия http потока IP пакеты не меняются никак. Ты с этим согласна или нет? Если да, то что за чуешь ты пишешь про оверхед на каждом пакете? Если нет, то ты даже примерно не представляешь как работает http и tcp/ip стек протоколов, не позорься и иди читать документацию. Если настаиваешь, то опиши на пальцах что происходит с IP пакетами при включении компрессии в http, мы все вместе посмеёмся.

меньше - не значит, что их нет. а при отсутствии компрессии их просто ноль. и это не только время, это тоже работа проца

Во-первых, нет, их не ноль. Каждая I/O операция тоже тратит CPU такты, а вдобавок ещё кучу ресурсов других устройств, например диска и шины. Со сжатыми данными мы экономим их.

Во-вторых, ты почему-то считаешь что во что бы то ни стало нельзя нагрузить CPU лишней работой. Почему? Мы говорим о размене I/O throughput на CPU cycles. Понятно что есть кейсы когда система упёрлась в CPU и нужно экономить именно его. Во всех остальных случаях CPU простаивает, дополнительная нагрузка на него ни повлияет ни на что, а операции с данными ускорятся в разы, эффективность кэша вырастет в разы, и место будет на накопителе будет расходоваться в разы эффективнее.

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

Ты тут начинаешь пытаться совершенно левые аргументы притягивать, мимо. Паттерны работы с ФС никак не меняются от использования компрессии. Если паттерны такие что кэши не работают, они не работают что без компрессии что с ней. Когда они работают, с компрессией в них влезает больше. Когда они не работают, всё равно мы читаем меньше.

запример, запусти какой-нибудь торрент с огромным числом файлов или с одним жирным файлом

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

и ты мне пытаешься доказать, что есть какой-то магический способ улучшить КПД системы вопреки закону сохранения. но этого не бывает в физическом мире. ты получаешь какую-то временную/частичную выгоду за счёт потерь в других ресурсах. только и всего. и потерь всегда больше, чем полученной выгоды. это физика, через неё не перепрыгнешь

Я уже писал - это размен IO throughput на CPU. Почему ты думаешь что в одну сторону это потери, а в другую нет? Я говорю что в общем случае компрессия выгодна, потому что в общем случае мы упираемся не в CPU, а в IO и размеры кэшей, а они значительно выигрывают. С чем ты пытаешься тут спорить?

Если не знаешь даже терминологии, то latency это просто задержки, они бывают и наносекундые, и секундные,

ага, и многочасовые... давай не будем. с английским у меня проблем нет (домыслы онанимусов - такие тупые домыслы!). только вот и понятия латенси в вебе смысла не имеет, если оно не относится к внутренним параметрам работы самого сервера.

Расскажи, всё-таки, что за пакеты ты имеешь в виду.

я чётко сказала про HTTP. что-то непонятно? не надо приписывать. вернись и прочитай то, что я написала. повторять не буду.

где ты видела ответы таких размеров

статистика на крупных проксирующих серверах в сети. внезапно, ответы HTTP - это не только запросы юзеров ЛОРчика, а по большей части это клиент-серверный обмен разнообразного софта, который гоняет довольно мелкие данные. эти данные не просто с потолка взяты.

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