Зачем вызывать delete если программа сама завершается?

Это сервер СУБД так делать? ЛОЛ

Siborgium monk - что же вы за инвалиды такие? Вы с чего там бенчите? С с? Вы понимаете, что бенчите свои говнодиски, а не программы?

Не берите 1/8гигов, если у вас нету столько памяти. Берите там 200 метров. Абсолютно неважно сколько вы там и чего возьмёте - программа почти полностью линейна. Поэтому 1 гиг будет в 5 раз медленнее 200метров.

На чём там … 40 секунд намерил - я не знаю.

Устроили тут тест скорости чтения с диска. :)

Алгоритмически задача проста как пробка. Поэтому если на ожидание/блокировку тратится больше 50% времени, то это тест на скорость работы ввода-вывода и к решаемой задаче не имеет никакого отношения.

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

Так что будь как все, дропай кеши перед запуском и хвались своим nvme диском.

А читерить с tmpfs (особо извращенные могут и ramdisk подрубить) - это сразу перманентный бан. У нас тут честные математические бенчмарки, только честное чтение данных с магнитной ленты.

Про время ожидания/блокировки – согласен, хорошее замечание. Я считаю, что его стоит включать в тест хотя бы потому, что исходное условие задачи состояло в том, что данные нужно читать с IO. Иначе их можно просто запихать в бинарник как сырые данные и наслаждаться заоблачной скоростью.

Читы вообще смысла не имеют, так как ты все программы гоняешь на одном и том же файле, и неважно, в какой fs он находится.

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

Зачем хоронить, если в итоге все равно истлеет?

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

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

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

Потому что mmap там читает сразу весь файл, а из-за того, что у тебя нету рамы - он потом выгружает и читается заново. Убери MAP_POPULATE.

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

Но все же, раз «реализация на баше не сильно отстанет от лидера», то почему результаты-то разные?

Какие результаты? Результатов нет.

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

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

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

Посоны, нужно срочно выдвигаться. Раст опять обосрался - https://habr.com/ru/post/482318/#comment_21072142 - седлайте коней.

результатов нет

Есть, в посвященном им топике. Царь сюда протек потому, что ему туда рейтинг постить не позволяет.

тест системы ввода-вывода

Еще раз,

• Часть доводов применима и к 200мб-файлу, так как чтение из кэша всяко быстрее чтения с диска, а 200мб окажутся кэшированы с куда большей вероятностью, чем, скажем, 500мб.

• Кэширование окажется бесполезным на 8гб

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

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

И да, разговор действительно лучше перенести в соответствующий топик.

результатов нет

Есть, в посвященном им топике.

Это не результаты.

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

можно по п4 конкретный пример того что ось освободить не сможет?

Например, временные файлы или области общей памяти, если им заранее не сделали unlink/shm_unlink по какой-то причине. Деинициализация экзотического оборудования, которое при запуске процесса нужно инициализировать средствами вроде ioctl и которое при смерти процесса автоматически не возвращается в состояние, в котором процесс успешно перезапустится

В какой-то статье на хабре PVS-Studio рассказывали что они в своём анализаторе не вызывают delete и это сэкономило 0.1с для каждого файла проверяемого анализатором.

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

всегда приятно когда твоя программа не выдаёт ошибок под Valgrind

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

вот сейчас нагуглил тот комент, который мне вспомнился про PVS

https://habr.com/ru/company/pvs-studio/blog/327994/#comment_10203324

для Ъ

А вы проверяли PVS-Studio Valgrind’ом? Было ли найдено что-нибудь интересное?

Пока не пробовали. Там ожидаемо будет 100500 утечек памяти, так как узлы дерева не удаляется в процессе работы, так как построенное дерево используется до конца работы программы. А в конце просто завершить программу, без предварительного удаления дерева. Этакая оптимизация скорости работы

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

Механизм освобождения в менеджере памяти используется только при прогоне юнит-тестов, чтобы не сжирать слишком много памяти при проверке различных тестовых *.i файлов. В случае же работы в пользовательском режиме память освобождает операционная система, завершая процесс. Такой подход экономит порядка 0.1 секунду (значение приблизительное, давно не замерял время) на запуск. Проверили 1000 файлов и вот уже экономия в 100 секунд: приятно.

Зачем убираться в квартире, если можно купить новую, когда в эту нельзя будет войти?

временные файлы

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

области общей памяти

На то и общей, что памятью этой и другие пользуются.

экзотического оборудования

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

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

ult&

дык если уверенно что нужно без вызова -

пусть само.

в чём собственно вопрос?(какой контекст - какая архитектура решения какой задачи-проблемы)

многие

Многие это сколько? «Я сам придумал и считаю, что многие» не считается.

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

И пох что оставшиеся от прежних запусков занимают место. Можно же cleaner запилить, да?

На то и общей, что памятью этой и другие пользуются.

Кто именно пользуется этой памятью?

И пох что оставшиеся от прежних запусков занимают место. Можно же cleaner запилить, да?

И сколько места оно занимает? Аааа, ты создаёшь на каждый запуск уникальный временный файл? ССЗБ! Использовать нужно один и тот же. Понятно, что если программа запускается в нескольких экземплярах, то использовать один и тот же временный файл нельзя, но, как правило, имя временного файла зависит от переданных программе опций. Не нужен никакой клинер.

Кто именно пользуется этой памятью?

Начнём с того, что шаред мемори (и семафоры) есть часть SystemV IPC, а IPC это интер процесс комуникейшн. Так, шареная память в первую очередь для этого, в том числе, если пользоваться ей по принципу временных файлов, и для сохранения данных между запусками одного экземпляра программы. И, максимум, что произойдет с этой памятью — содержимое в ней будет перезаписано новым запуском программы или другая программа туда какой-то статус положит. Или ты опять на каждый запуск новый сегмент шареной памяти выделяешь? Ну, ССЗБ, чо...

Ну, например:

https://instagram-engineering.com/dismissing-python-garbage-collection-at-instagram-4dca40b29172

но, как правило, имя временного файла зависит от переданных программе опций

Как правило или всегда? Или у тебя «исключение только подтверждает правило»? Как обрабатывается версионность «программы»?

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

То есть, такая память не освобождается при завершении процесса? Если да, вопросы те же, что и по временным файлам

Как правило или всегда?

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

такая память не освобождается при завершении процесса

Именно! Оно и ведёт себя так же как тпмфс — до перезагрузки.

Как правило

К чему тогда был твой предыдущий пост? Как быть если данные зависят от, к примеру, текущего времени, а не только «опций»? И повторю вопрос: версионирование программы как обрабатывается?

Именно! … до перезагрузки

И при чём здесь перезагрузка? Ты решил развить мысль ТС-а до чего-то такого: «плевать на всё, а когда песец придёт мы перезагружаемся»? А до перезагрузки ресурс будет занят, потому что он использовался процессом, который сдох, да?

зачем тебе временный файл от текущего времени? это какойто способ самоистязания?

ресурс занят и ресурс существует - разные понятия, в частности для шмем, он есть но не занят.

ах, версионирование - ну создай новый файл или шмем, сколько их там будет? 100? 1000?

зачем тебе временный файл от текущего времени?

Да и сами временные файлы тоже незачем юзать - вот и нет проблемы

для шмем, он есть но не занят

Его никто не освобождает до перезагрузки, но он не занят, ага

сколько их там будет? 100? 1000?

Действительно, что это я заморачиваюсь?

обьясни, зачем юзать разные временные файлы/шмем сегменты только ради для таймстампа?

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

действительно, у тебя там реально сто версий программы/скрипта одновременно пашет?

зачем юзать разные временные файлы/шмем сегменты только ради для таймстампа?

Понятия не имею. В частности, с чего ты взял только

у тебя там реально сто версий программы/скрипта одновременно пашет?

Нет, у меня по несколько версий разных приложений

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

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

и все они используют файл/шмем?

Вот выйдет метапрог, ваще ничего не нужно будет delete! все само будет ибо графика.

Аха. И в первую очередь он удалить сам себя))

Это совершенно нормальная ситуация когда взял и отвалился сервер с СУБД, транзакции для того и придумали.

В биореактор.
/thread

зачем закрывать программы если все равно перезагружаешь компьютер

Ну в андроеде так и происходит — программы не закрываются... притом и «компьютер» никто не перезагружает. Апофигей оптимизации.

Время перезапуска 1 секунда, никто и не заметит.

Оно так не работает.
Сперва процессы в системе начнут тупить из-за нехватки памяти, потом сработает OOM Killer, затем приложение грохнется на середине своей операции, потеряв несохраненные данные, и уже тогда перезапустится супервизором с чистого листа.