зачем нужен FILE когда есть обычные дескрипторы?

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

А теперь не 0. Это проблема нуля и я не знаю нахрена запилено такое аутичное поведение.

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

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

Аргумент работает только, если уж падать никак нельзя, но это не раелизуемо вне изолированного окружения. Что мешает мне затрункатить твою память? А так проблема решается изоляцией и не является проблемой в 99% случаев.

Тем более проблема существует только когда трункатят в ноль.

Я пару лет назад видел сравнение mmap vs read, на больших файлах они работали примерно одинаково

Это не тот опус, в котором делали read по 1 байту?

Ну, типа

Ну типа твой fdgets только что не сумел прочитать из терминала на stdin. Садись, два. Eddy_Em, кстати, справился.

Я не тронул ни одного нормального комента (ты бы это знал если бы прочитал их). Я потёр только «ты дурак»/«нет это ты дурак». Ты это называешь «объяснением»?

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

Но у людей свербит от того что они о mmap не знали и теперь выдумывают причины по которым «mmap говно полное».

А вот и первый адепт

Т.е. по существу ты серанул и ответить тебе нечего?

EACCESS

К чему ты это высрал?

ENODEV
mmap должен поддерживаться драйвером фс

Расскажи мне пж, а что за драйверы фс такие?

Ах да, и высри мне что-то по теме, пж. Либо обосраться и съехать для балаболки это норма?

Это не тот опус, в котором делали read по 1 байту?

Там тестировали с разным размером буфера. Я этим всем тестам всё равно не стал бы доверять. Половина тестировщиков не в курсе про page cache, например.

Eddy_Em, кстати, справился.

Ну и славненько.

А т.е. это ты трёшь комменты? Ты же мне расскажешь где было «сам дурак» в моём предыдущем комменте?

Ну что я могу сказать, такая мразь должна жрать говно.

Не я, тут и другие модераторы орудуют.

Если не хочешь чтобы тебя тёрли то ты знаешь что надо делать. «не надо гадить в общественном транспорте» (c)

Т.е. по существу ты серанул и ответить тебе нечего?

Очередной безграмотный ананимус жиденько обосрался. man mmap, быдло.

Расскажи мне пж, а что за драйверы фс такие?

davfs2

Либо обосраться и съехать для балаболки это норма

Ты попутал типичную анонимную шавку и гордого регистранта.

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

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

Половина тестировщиков не в курсе про page cache, например.

99% любителей mmap почему-то не задумываются, что где-то должна жить таблица трансляции virtual => physical address. А она (сюрприз!) занимает память и требует, чтобы ее кто-то заполнял.

read из pagecache — невероятно легкая операция (memcpy, правда с нырянием в kernel-space, но нырять-то можно за большими кусками), а mmap — дополнительно заполнение дескрипторов 4-килобайтных (на 64 битах можно попробовать 4-мегабайтные) страниц после того, как данные уже лежат в page cache.

А она (сюрприз!) занимает память и требует, чтобы ее кто-то заполнял.

Для большинства задач оверхед незначительный (а ещё есть hugetlb). Более того, fread и FILE это оверхед сам по себе. Поэтому если хочешь скорости: работай с голыми дескрипторами.

Вот тут можно посмотреть на конкретные циферки и даже скачать бенчмарк чтобы проверить у себя: http://lemire.me/blog/archives/2012/06/26/which-is-fastest-read-fread-ifstrea...

Что мы видим - мы видим обезьяну. Во-первых обезьяна даже самая не знает когда сбрасывается буфер в его ахриненных FILE-говнах и форфан юзает fflush(stderr);

Ну, если бы ты вместо претенциозной болтовни на ЛОРе занялся бы полезным делом и написал бы своего демона для выдачи IPv6 в локальную сеть, то мы бы не увидели всего этого ужаса. Это был просто пример из реальной практики, и я таких уже немало видел. В тех самых программах, которые ты качаешь из репы.

Магичиским образом превращается в

Хорошо уметь превращать функции, даже до конца их не увидев. Рефакторинг при помощи телепатии, да?

Мы уже видим одну проблему fflush(), вернее одну фичу, которая мешает пацанам.

Если тебе чем-то мешает буферизация, то она спокойно отключается.

О да, о да. Это не аргумент. Это субъективное понятие. Если 95% понятна феня, то чтож ты на ней не говоришь?

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

Какие нахрен такие обёртки? Ты же мне расскажешь.

Т.е. ты перед каждым вызовом любимого write руками форматируешь вывод? sprintf() каждый раз вызываешь? Хоть макросы себе там запили, побойся Бога.

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

Согласен. Мне вот, например, никогда не нравилось, что данные из kernel-space при выдаче в user-space копируются. Вообще не нравится, что у каждого процесса своя область памяти, надо всю ее общей сделать, сразу проблемы с межпроцессным взаимодействием решатся.

Даст. Давай я тебе опишу вменяемое api.

А при чем здесь это? Я речь вел больше о чтении/записи из/в файл, смотря на конкретные примеры с /proc/modules, а не о IPC.

С похожим api у нас бы было илитное зерокопи в тех же сокетах, а не та параша, что есть сейчас.

Если тебе не нравится дизайн языка/библиотеки/ОС/etc - это не мои проблемы.

Зачем ты пишешь о том, в чем нихрена не шаришь? Какое нахрен такое говно с выравниванием, осилишь примерчик?

EINVAL. Там нужно следить за выравниванием по размеру страницы оперативной памяти.

Мне насрать на то, что там и у кого «Обычно». Именно по этой причине 99% не могут в бинарь, ибо нулёвые обезьяны, которые пишут на libc, glib, а не на си.

Окружающим тоже очень интересно твое Мнение.

И я вижу эти килобайты когда там, где это можно сделать сотней строк. Эту лапшу, это говно. Это убожество в api, которое я вижу в той же libc.

Там зачем мучаться? Займись икебаной, сбереги свои нервы.

http://lemire.me/blog/archives/2012/06/26/which-is-fastest-read-fread-ifstrea...

Это тот самый «бенчмарк», где делают read(fd, &intvar, sizeof(int)). Чур меня от таких «бенчмарков» :D

Хорошо, я поищу другой бенчмарк. А пока предлагаю подумать над тем что read копирует из памяти ядра, а mmap нет.

А пока предлагаю подумать над тем что read копирует из памяти ядра, а mmap нет.

А fread еще и в дополнительный буфер пхает.

Очередной безграмотный ананимус жиденько обосрался

Ты же мне скажешь в чем я конкретно обосрался, либо так и будешь уходить от ответа?

davfs2

Серанул, давай дальше.

Ты попутал типичную анонимную шавку и гордого регистранта.

Т.е. ты о5 серанул и ответа не будет? Мне вот интересно на что ты рассчитываешь? Ты боишься мне ответить, ибо потом уже не отмажешься?

Но у людей свербит от того что они о mmap не знали

Знали, вот только он изначально предполагался для быстрого галопа по здоровому файлу _фиксированного блджад_ размера в несколько потоков, shm-карочь. Пайпы и сокеты оно не умеет, что впринципе убивает трюки с подстановкой таковых в виде файлов. Ну и не забываем, что mmap может сильно подкачать при фрагментированной памяти.

Пайпы и сокеты оно не умеет

А жаль! Надо срочно найти того, кто сможет ведро на этот счет пропатчить.

Я вообще не понимаю, какого хрена нельзя сделать mmap на трубу или сокет?

Но у людей свербит от того что они о mmap не знали и теперь выдумывают причины по которым «mmap говно полное».

Некоторые знают не только о mmap, но и о том, что mmap не всегда поддерживается.

Я вообще не понимаю, какого хрена нельзя сделать mmap на трубу или сокет?

Потому что неизвестно сколько оттуда прилетит 1К или 1Т. И при такой архитектуре, сэкономив пару строчек на классическом read/write - эту устанешь окостыливать поведение в случае нехватки непрерывных блоков памяти.

Вот на скорую руку немного говнокода. Проверял как с холодным кэшем так и с горячим, с разным размером блока. Т.к. мерял на скорую руку то результаты не привожу, меряй сам. Ну и код посмотри, может я там где-то что-то сделал неправильно. Файл сгенерен через dd if=/dev/urandom of=file.bin bs=1M count=1000 .

#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <err.h>

int main(void) {
  char buf[10240];
  FILE *f = fopen("/home/file.bin", "r");
  if (!f) {
    err(1, "fopen");
  }

  while (!feof(f)) {
    int r = fread(buf, sizeof(buf), 1, f);
    //if (r < sizeof(buf)) {
    //  err(1, "fread");
    //}
      for (int i=0; i<sizeof(buf) ; i++) {
        char y = *(buf+i);
      }
  }
}

#include <sys/mman.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <err.h>

const int file_size=1048576000;
const int page_size=0x1000;
int off=0;
void *data;
          
int main() {
  int fd = open("/home/file.bin", O_RDONLY);
  if (fd < 0) {
    err(1, "open"); 
  }
    data = mmap(NULL, 1048576000, PROT_READ, 0, fd, off);
    // do stuff with data
    for (int i=0; i< file_size; i++) { 
      char y = data++;
    }
    munmap(data, page_size); 
    off += page_size;
} 

какого хрена нельзя сделать mmap на трубу или сокет?

Смысла мало для поточного IO. Но если нужно просто передать данные на другой комп то fibre channel, например, умеет remote dma. Но это другая история.

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

Ну, если бы ты вместо претенциозной болтовни на ЛОРе занялся бы полезным делом и написал бы своего демона для выдачи IPv6 в локальную сеть, то мы бы не увидели всего этого ужаса. Это был просто пример из реальной практики, и я таких уже немало видел. В тех самых программах, которые ты качаешь из репы.

Т.е. по существу ты серанул? Ок, так и запишем. Зачем мне писать для выдачи одного говна в другое говна, которое мне нахрен не нужно?

Я пишу то, что мне нужно, а то, что кому-то это нужно, даже пусть будет нужно ещё и мне - никак не отменяет того факта, что оно говно.

Хорошо уметь превращать функции, даже до конца их не увидев. Рефакторинг при помощи телепатии, да?

И о5 тебе посуществу сказать нечего и ты слился как 5-летка. Выкатывай полностью, показывай, почему мой «рефакторинг» не работает.

Если тебе чем-то мешает буферизация, то она спокойно отключается.

Зачем тогда мне FILE?

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

Т.е. о5 ответ не посуществу, а слива ради.

Т.е. ты перед каждым вызовом любимого write руками форматируешь вывод?

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

Хоть макросы себе там запили, побойся Бога.

Ты меня будешь учить как писать? Рили?

Согласен. Мне вот, например, никогда не нравилось, что данные из kernel-space при выдаче в user-space копируются. Вообще не нравится, что у каждого процесса своя область памяти, надо всю ее общей сделать, сразу проблемы с межпроцессным взаимодействием решатся.

Т.е. ты о5 серанул и начал нести херню.

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

А при чем здесь это? Я речь вел больше о чтении/записи из/в файл, смотря на конкретные примеры с /proc/modules, а не о IPC.

Это здесь притом, что а) ммап не работает по той причине, что запиливал его даун. Никакая память на память тут непричем, а как сделать вменяемое api я даже показал.

Чтение запись из/в файл, если это не ядерная параша идеальные.

Конкретные примеры из /proc/modules я уже дал.

Если тебе не нравится дизайн языка/библиотеки/ОС/etc - это не мои проблемы.

Потому ты жрёшь говно, а пацаны пилят и исправляют это говно.

EINVAL. Там нужно следить за выравниванием по размеру страницы оперативной памяти.

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

Окружающим тоже очень интересно твое Мнение.

Понимаешь моё мнение имеет вес, ибо я умею в код лучше тебя, да и любой рандомной балаболки.

По существу тебе о5 ответить нечего. Зачем ты сливаешься на херню. Ответь что-то про бинарь.

Там зачем мучаться? Займись икебаной, сбереги свои нервы.

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

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

Щито?

Потому что неизвестно сколько оттуда прилетит 1К или 1Т

Известно - ровно PIPE_BUF.

Проблема не в этом - проблема в том, что тебе у тебя один хрен будет обмен сообщениями записал->принял->записал.

Поэтому вменяемые люди не гоняют больше PIPE_BUF по пайпам, ибо это говно и для этого есть шаредмем.

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

ЛОЛЩТО?

А вот если-бы у тебя была совесть

Да, можно было взять какой-нить /dev/sda и не париться. Но я хотел избежать ситуации когда тест запускается на ssd которые сжимают данные (sandforce какой-нить). Не знаю чем это может грозить, перестраховываюсь.

Зачем это?

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

read копирует из памяти ядра, а mmap нет

И тем не менее, mmap медленнее. А комбинация вызовов read+write, кстати говоря, не уступает sendfile в производительности.

When fildes represents a typed memory object opened with either the POSIX_TYPED_MEM_ALLOCATE flag or the POSIX_TYPED_MEM_ALLOCATE_CONTIG flag, mmap() shall, if there are enough resources available, map len bytes allocated from the corresponding typed memory object which were not previously allocated to any process in any processor that may access that typed memory object. If there are not enough resources available, the function shall fail. If fildes represents a typed memory object opened with the POSIX_TYPED_MEM_ALLOCATE_CONTIG flag, these allocated bytes shall be contiguous within the typed memory object. If fildes represents a typed memory object opened with the POSIX_TYPED_MEM_ALLOCATE flag, these allocated bytes may be composed of non-contiguous fragments within the typed memory object. If fildes represents a typed memory object opened with neither the POSIX_TYPED_MEM_ALLOCATE_CONTIG flag nor the POSIX_TYPED_MEM_ALLOCATE flag, len bytes starting at offset off within the typed memory object are mapped, exactly as when mapping a file or shared memory object. In this case, if two processes map an area of typed memory using the same off and len values and using file descriptors that refer to the same memory pool (either from the same port or from a different port), both processes shall map the same region of storage. [Option End]

Известно - ровно PIPE_BUF.

По-сколько раз?

ЛОЛЩТО?

Выше

s/fread/fread_unlocked/.

И даже после этого компилятор имеет полное право выкинуть цикл, что приведет к тому, что тест с mmap будет состоять из «mmap, munmap», а тест с fopen честно зачинает файл.

Кстати, я что-то не пойму: я говорю, что read блоками уделывает mmap, ты почему-то подсовываешь fread.

Размер блока можно взять из cat: 32768.

#include <fcntl.h>
#unclude <unistd.h>
#include <stdio.h>

int main(int argc, char **argv)
{
  unsigned int cksum = 0;
  int fd = open(argv[1], O_RDONLY);
  if (fd != -1) {
    unsigned int buf[8192];
    for (;;) {
      unsigned i;
      int bytes = read(fd, buf, sizeof(buf));
      if (bytes <= 0) break;
      for (i = 0; i < bytes / 4; i++)
        cksum += buf[i];
    }
    close(fd);
  }
  printf("cksum = %u\n", cksum);
  return 0;
}

И тем не менее, mmap медленнее

Пруф? Ну или хотя бы запусти те тесты что я привёл.

А комбинация вызовов read+write, кстати говоря, не уступает sendfile в производительности.

Это вброс такой?

И тем не менее, mmap медленнее.

Пруфец будет?

А комбинация вызовов read+write, кстати говоря, не уступает sendfile в производительности.

Куллстори.

Иди уже померяй, чтобы не тявкать попусту. «Бенчмарк» для read я привел. Для mmap напиши самостоятельно, чтобы не позорить анонимусов.

Ты офигел такое царю предлагать. Он не умеет в «уже померяй». Он сильно илитин для этого.

А комбинация вызовов read+write, кстати говоря, не уступает sendfile в производительности.

Я на этот счет обосрался в одной теме. Очень сильно sendfile выигрывает в производительности!

read блоками уделывает mmap

Но последующая обработка, да и собственно ручная буферизация — проигрывает.

Это вброс такой?

Это не вброс. Это факт, который меня также поразил. Для pagecache => /dev/null sendfile очень быстрый, но как только дело доходит до file => file, разница теряется на фоне ожидания IO.

/* gcc -o fastcat -O2 -Wall fastcat.c */
#include <unistd.h>
#include <sys/sendfile.h>
#include <fcntl.h>
#include <sys/stat.h>
#include <stdio.h>

int main(int argc, char **argv)
{
  int i;
  for (i = 1; i < argc; i++) {
    struct stat st;
    if (stat(argv[i], &st) == 0 && S_ISREG(st.st_mode)) {
      off_t off = 0;
      int fd = open(argv[i], O_RDONLY);
      if (fd == -1)
        continue;
      // posix_fadvise(fd, 0, 0, POSIX_FADV_SEQUENTIAL); // this will significantly improve performance
      while (off < st.st_size) {
        ssize_t bytes = sendfile(STDOUT_FILENO, fd, &off, st.st_size - off);
        if (bytes <= 0)
          break;
      }
      close(fd);
    }
  }
  return 0;
}

После этого я перестал считать syscall-ы «дорогими»

sendfile(STDOUT_FILENO

И что ты так измеришь? Скорость своего терминала?

Я на этот счет обосрался в одной теме

Ты неправильно обосрался. Разница теряется на фоне чтения с диска/сетевых задержек, если речь идет о real time. Существенные различия в потреблении CPU при использовании гигабитной сети заметить не удалось.

И что ты так измеришь? Скорость своего терминала?

Я даже не знаю, что сказать

Как думаешь, много здесь терминала?

fastcat file > output

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

разница теряется на фоне ожидания IO

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

В споре mmap vs read тоже можно сказать «разница теряется на фоне ожидания IO».

PS мой бенчмарк c mmap нерабочий. После исправления аргументов mmap он прилично проигрывает голому read. Но я ещё разбираюсь.

Как думаешь, много здесь терминала?

А ничего, что там pipe и лишняя буферизация?

Говно твой тест!

sendfile «быстрее» в том плане что не требует копировать данные туда-сюда

sendfile удобнее использовать. Но, увы, zero copy не получается. Все равно в ядре идет копирование в буфер сокета (а что, ты думал, там кто-то будет делать munmap/mmap?). sendfile всего лишь избегает copy_to_user/copy_from_user, которые в этом конкретном случае привносят «близкий к никакому» overhead (юзерспейсный буфер успевает осесть в L2 кеше).

А ничего, что там pipe и лишняя буферизация?

Лол. Думаю, дальше с тобой можно не разговаривать. Пайп у него при перенаправлении в файл :D

Вот код, работает столько же сколько и read. Выдаёт тот же cksum. По поводу sendfile лень спорить. У меня есть локальный инстанс nginx и siege, но там siege весь проц жрёт.

#include <sys/mman.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <err.h>

const int file_size=1048576000;

int main(int argc, char *argv[]) {
  unsigned int cksum = 0;
  unsigned int *data;
  int i;
  
  int fd = open(argv[1], O_RDONLY);
  if (fd < 0) {
    err(1, "open");
  }
  
  data = mmap(NULL, file_size, PROT_READ, MAP_SHARED, fd, 0);
  if (data == MAP_FAILED) {
    err(2, "mmap");
  }
  for (i = 0; i < file_size / 4; i++)
    cksum += data[i];

  printf("cksum = %u\n", cksum);
  //munmap(data, page_size);
}

Я пишу то, что мне нужно, а то, что кому-то это нужно, даже пусть будет нужно ещё и мне - никак не отменяет того факта, что оно говно.

Ты пишешь говно, я правильно понял?

И о5 тебе посуществу сказать нечего и ты слился как 5-летка. Выкатывай полностью, показывай, почему мой «рефакторинг» не работает.

Очевидно, что там есть statement'ы, которые не канают по твоему шаблону. Код можешь сам нагуглить, это же opensource.

Зачем тогда мне FILE?

А почему не FILE?

Т.е. о5 ответ не посуществу, а слива ради.

Давай по-другому: тебя по месту работы никто еще в ссаные тряпки носом не тыкал?

Форматированный вывод нахрен не нужен, кроме как для притф"а.

И помимо stdout других файлов, куда можно\нужно выдать форматированный вывод, конечно же, нет.

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

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

Это здесь притом, что а) ммап не работает по той причине, что запиливал его даун. Никакая память на память тут непричем, а как сделать вменяемое api я даже показал.

Чем принципиально отличается read от какого-нибудь fgets в случае c /proc/modules? Только наличием буфера?
Строго говоря, в данном случае даже все эти вызовы необязательны - несколько строчек шелла все вызовут за тебя и покажут... Что там было? Путь до файла модуля?

Потому ты жрёшь говно, а пацаны пилят и исправляют это говно.

Что-то не заметил кардинальных изменений ни в работе сокетов, ни в работе тех же пайпов. Документация десятилетней давности все так же к ним подходит.

Ответь что-то про бинарь.

Бинарный код? Дизассемблирование? Ты о чем вообще?

Понимаешь моё мнение имеет вес, ибо я умею в код лучше тебя, да и любой рандомной балаболки.

Ты хотел сказать «ЧСВ»?
Дашь посмотреть, что ты умеешь? Ну там сорцы проектов каких-нибудь?