Обычный fwrite из этого примера начинает писать быстрее 2ГБ/с при использовании крупных блоков — бутылочным горлышком становится оборудование, а не способ записи.
В нормальных случаях код должен в разы быстрее поставлять данные на запись, чем физическое устройство будет их записывать.
Писать в файл по байту за вызов так себе вариант, чудовищно медленный даже в случае использования буферизующей прослойки в виде stdio.
В данном случае это просто пример как можно за бесплатно ускорить легаси, но тот же самый код пишущий большими блоками справляется с задачей за доли секунды.
Это нужно учитывать на уровне алгоритма.
Я наконец добрался до виндовой машины и попробовал этот же пример, но с записью крупными блоками, а не побайтно.
Собственно вот что я имел ввиду: C:\>write-byte.exe
Time: 16242738
C:\>write-block.exe
Time: 234701
Версия записывающая байт за байтом чудовищно медленная и грузит ядро на 100%. И кэширование записи в ОС не заметно только потому, что бенчмарк пишет в файл медленнее чем идет запись на диск.
В случае записи блоками все заканчивается практически мгновенно и бенчмарк завершается еще до того, как файл физически будет записан на диск.
Поэтому даже реальную скорость записи на диск таким простым тестом не получится узнать.
Это не кэш, это внутренний буффер в библиотеке. Потом все это попадет в кэш ОС.
А влияния в данном случае не будет, потому что бутылочное горлышко где то в другом месте.
Тут даже близко не подошли к пределу по линейной записи.
И вы точно не напутали с размерностью МБ/ГБ? :)
На рыбалку/охоту кататься к примеру, живя в деревне.
Или может я хочу <роскомнадзор> совершить.
Это строго мое право купить машину в той комплектации что я хочу, но государство лезет в мою жизнь и вынуждает переплачивать.
И касается это не только экологии.
При этом MCAS они спокойно сунули даже не упомянув в документации.
Как с этим обстоит у Airbus? Они раньше начали внедрять компьютерные системы управления полетом.
Так в том и дело, угол атаки не так то уж и нужен для полета, как то и без него обходятся.
Весь вопрос в абсолютных значениях — насколько этот угол атаки может отличаться от направления «вперед», какие углы являются критическими, в каких пределах/условиях можно пилотировать самолет без реальных показаний угла атаки?
Просто скорее всего сбойный датчик давал показания сильно отличающиеся от реальности.
Вообще система управления самолетом в идеале должна иметь какую то цифровую модель полета, постоянно обновляемую на основе показаний датчиков. Тогда будет четкое понимание происходящего с самолетом.
Про запись я вас случайно запутал. Да, я именно чтение имел в виду, мне одно время нужно было достоверно измерить разницу между разными вариантами чтения и кеш все портил.
Но у вас все равно получается, что измеряется время когда вы отдали файл в кеш ОС, а не когда он по факту был записан на диск.
В любом случае переделывание алгоритма на последовательную запись большими кусками позволит ускориться в несколько раз, потому что даже для HDD на 7200 rpm скорость линейной записи обычно > 200 МБ/с.
Но для бинарных патчей это наверное не актуально :)
Спасибо за исследование, это вполне годный вариант забесплатно получить ускорение, там где нет возможности что то кардинально поменять.
Но побайтное чтение/запись в stdio все равно слишком медленные и лучше менять алгоритм что бы было линейное чтение/запись большими кусками.
Хотел спросить как вы замеряли скорости что бы избежать побочных эффектов от кеширования файла в памяти после первого прогона, но судя по низким скоростям это не имеет большого смысла в данном случае.
Собственно вопросы всё равно остались:
1. Зачем так сложно? Зачем там unique_ptr?
2. Почему в случае ошибки перед завершением программы делается file.release(), а при нормальном завершении — нет?
Писать в файл по байту за вызов так себе вариант, чудовищно медленный даже в случае использования буферизующей прослойки в виде stdio.
В данном случае это просто пример как можно за бесплатно ускорить легаси, но тот же самый код пишущий большими блоками справляется с задачей за доли секунды.
Это нужно учитывать на уровне алгоритма.
Собственно вот что я имел ввиду:
C:\>write-byte.exe
Time: 16242738
C:\>write-block.exe
Time: 234701
Версия записывающая байт за байтом чудовищно медленная и грузит ядро на 100%. И кэширование записи в ОС не заметно только потому, что бенчмарк пишет в файл медленнее чем идет запись на диск.
В случае записи блоками все заканчивается практически мгновенно и бенчмарк завершается еще до того, как файл физически будет записан на диск.
Поэтому даже реальную скорость записи на диск таким простым тестом не получится узнать.
Пилоты не знали об этой системе.
а двигатели в данном случае связаны с кобрирующим моментом.
В других облаках винду почти не используют.
Вот первая попавшаяся ссылка:
www.google.com/amp/s/fossbytes.com/ubuntu-linux-is-the-most-popular-operating-system-in-cloud/amp
А влияния в данном случае не будет, потому что бутылочное горлышко где то в другом месте.
Тут даже близко не подошли к пределу по линейной записи.
И вы точно не напутали с размерностью МБ/ГБ? :)
Или может я хочу <роскомнадзор> совершить.
Это строго мое право купить машину в той комплектации что я хочу, но государство лезет в мою жизнь и вынуждает переплачивать.
И касается это не только экологии.
Как с этим обстоит у Airbus? Они раньше начали внедрять компьютерные системы управления полетом.
Весь вопрос в абсолютных значениях — насколько этот угол атаки может отличаться от направления «вперед», какие углы являются критическими, в каких пределах/условиях можно пилотировать самолет без реальных показаний угла атаки?
Просто скорее всего сбойный датчик давал показания сильно отличающиеся от реальности.
Вообще система управления самолетом в идеале должна иметь какую то цифровую модель полета, постоянно обновляемую на основе показаний датчиков. Тогда будет четкое понимание происходящего с самолетом.
Но у вас все равно получается, что измеряется время когда вы отдали файл в кеш ОС, а не когда он по факту был записан на диск.
В любом случае переделывание алгоритма на последовательную запись большими кусками позволит ускориться в несколько раз, потому что даже для HDD на 7200 rpm скорость линейной записи обычно > 200 МБ/с.
Но для бинарных патчей это наверное не актуально :)
и за ЭРА-ГЛОНАСС изволь заплатить.
Но побайтное чтение/запись в stdio все равно слишком медленные и лучше менять алгоритм что бы было линейное чтение/запись большими кусками.
Хотел спросить как вы замеряли скорости что бы избежать побочных эффектов от кеширования файла в памяти после первого прогона, но судя по низким скоростям это не имеет большого смысла в данном случае.
1. Зачем так сложно? Зачем там unique_ptr?
2. Почему в случае ошибки перед завершением программы делается file.release(), а при нормальном завершении — нет?