Существует ли язык высокого уровня, который устойчиво быстрее C?

любая программа течет

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

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

Хотя программисты про это задумывались последний раз ещё на ZX Spectrum. А потом началось: «память виртуальная, своп спасёт», «память дешёвая»...

Извини, я тебя поправлю, ок?

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

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

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

Почему так правильно? Потому что, ты рассматриваешь случай когда под хэш память выделяется динамически (realloc). А может быть случай, когда выделили несколько десятков Гб, по теории все что жует программа должно уместится в него. Однако, на пятый день, с восходом солнца, потребление памяти выросло на значительное число, скажем, 100 мегабайт. Хотя цикл для прогона всех возможных вариантов входных данных программы всего составляет день. Т.е. в течении последних 4 дней никто не заметил утечку в 25 мегабайт, но заметили в 100.

Ровно поэтому ява якобы никогда не течет — у нее просто есть лимиты для кучи. И если программа течет, то получается out of memory на уровне VM (хотя в системе полно свободной памяти).

Извините, еще раз.

Хотя программисты про это задумывались последний раз ещё на ZX Spectrum.

Не пугай людей :) LRU, MRU, etc используются активно.

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

Если браузер на каждую открываемую страницу (не посещённую ранее) будет увеличивать потребление памяти на 5 мегабайт ты не будешь считать это утечкой?

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

Почему? Может быть и malloc(100500100500). Всё равно память выделяется процессу по мере использования постранично.

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

Вот про это и речь. Если при произвольных данных можно гарантировать, что используемая не превысит заранее заданного предела, то утечки нет. А если нет, значит утечка есть (и программу придётся периодически перезапускать).

Не пугай людей :) LRU, MRU, etc используются активно.

Я имел в виду, что во времена ZX Spectrum (почти) все программисты думали про ограничение используемой памяти. А сейчас это скорее исключение. В СУБД есть, в ядре ОС есть, в браузере нет, в игрушках нет, даже в интерфейсе для торрента нет,

Если браузер на каждую открываемую страницу (не посещённую ранее) будет увеличивать потребление памяти на 5 мегабайт ты не будешь считать это утечкой?

Считаем, что браузер это черный ящик. В идеале как должно быть? Открыли вкладку, открыли страницу, закрыли вкладку. Обязательное условие: размер страницы (и ее данные) не меняется в ходе эксперимента. Повторим это 100500 раз. Повторим этот же эксперимент для двух, трех, десяти других, с теми же свойствами (неизменяемость) страниц. Записали значения, закрыли браузер, повторили этот же эксперимент еще раз. Потребление памяти должно быть одинаковым. Для одной страницы при открытие/закрытие не должно вообще ничего потреблятся после выделения памяти.

Увы, некоторые браузеры считают себя умнее тебя. И скажем, используют пул потоков для вкладок. Поэтому для них измерения сложно сделать верными (но можно). Такие браузеры, не будем называть их, жрут в среднем 2 гигабайта ОЗУ. Хотя более простые браузеры для этой же задачи укладываются в 300-500 Мб.

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

На бесконечном множестве входных данных все зависит от алгоритма. А алгоритм корректируется средой. Вот ты же сказал про «память дешёвая», однако, забыл уточнить, что у компов есть лимит на максимальный объем ОЗУ. Ты также забыл уточнить, что бесконечное число произвольных данных может обрабатываться в ограниченный промежуток времени. Вобщем, детали-детали-детали реализации. Да, можно сделать так, чтобы мемоизация была неограниченной. Да, можно запустить процесс и он сожрет всю доступную память. Возникает только вопрос, а что если бы не было ограничений, была бы утечка?

Считаем, что браузер это черный ящик. В идеале как должно быть? Открыли вкладку, открыли страницу, закрыли вкладку. Обязательное условие: размер страницы (и ее данные) не меняется в ходе эксперимента. Повторим это 100500 раз. Повторим этот же эксперимент для двух, трех, десяти других, с теми же свойствами (неизменяемость) страниц. Записали значения, закрыли браузер, повторили этот же эксперимент еще раз. Потребление памяти должно быть одинаковым. Для одной страницы при открытие/закрытие не должно вообще ничего потреблятся после выделения памяти.

Трижды прочитал, ответ на вопрос не понял. У тебя одна и та же страница 100500 раз открывается, а я немножко про другое. Предположим, открываем браузер и начинаем: открыть вкладку, перейти http://localhost/00001.htm, закрыть вкладку, открыть вкладку, перейти http://localhost/00002.htm, закрыть вкладку, ... , перейти http://localhost/01234.htm, ...

Является ли утечкой, если при этом тесте объём используемой памяти постоянно растёт?

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

А вот всё то, потребление, что выходит за рамки чистой памяти и есть утечка. Т.е. реальная память - чистая память = утечка. Она может течь постоянно, может просто один раз вытечь - это не важно.

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

Но даже на основании этого определения - фрагментация и прочие не постоянные оверхеды рантайма, а строго все оверхеды рантайма - это такая же утечка памяти.

Проблема с маллоком в том, что malloc(10gb), malloc(10), free(10gb) - у тебя память теперь НИКОГДА ниже 10гб не опустится - будут либо 10гб, либо будет расти.

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

Там, где много данных - это пакетная обработка и там вообще ни маллок, ни гц не нужны. А вот на malloc(1kb) x 1mb, malloc(10); - тут нище 10гб так же никогда не уйдёт.

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

Да, является. Это я описал выше - если ты называешь это утечкой, то я тебя хвалю - хоть что-то в этом жизни ты понимаешь.

А сейчас это скорее исключение.

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

в браузере нет

По этой причине тормазит и течёт. А если это запилить на жабке/аде, то это бы вообще не работало.

в игрушках нет

То-то в дерьмо. Да и есть это в игрушках - память на вядяшке не резиновая.

даже в интерфейсе для торрента нет

Именно поэтому нет ни одного «интерфейса для торрента», который был бы не ущербным дерьмом.

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

Вот ты же сказал про «память дешёвая», однако, забыл уточнить, что у компов есть лимит на максимальный объем ОЗУ.

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

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

??? Это как? Физически.

Возникает только вопрос, а что если бы не было ограничений, была бы утечка?

Утечка — свойство не среды, а алгоритма. Если используемая память алгоритма не ограничена, значит есть утечка. Если у неё есть строгая верхняя граница, значит утечки нет. Да, память считается только ОЗУ. Использование файлов, растущих пропорционально входным данным допустимо.

открыть вкладку, перейти http://localhost/00001.htm, закрыть вкладку, открыть вкладку, перейти http://localhost/00002.htm, закрыть вкладку, ... , перейти http://localhost/01234.htm, ...

Сложно сказать. Опять же возращаемся к циклам. Допустим известно, что сколько каждая страница будет потреблять памяти. Тогда, утечка будет в том случае, если при повторном проходе этих же действий потребление ОЗУ вырастит.

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

Или спустимся с небес. realloc (в большую сторону) не является утечкой памяти. Плюс анон тебе описал про оптимистичную работу malloc (в этом случае он не может вернуть память обратно в ОС). Однако, википедия говорит, что реализации malloc с возратом памяти в ОС имеются:

https://en.wikipedia.org/wiki/C_dynamic_memory_allocation#Implementations

См. dlmalloc и openbsd malloc.

Утечка — свойство не среды, а алгоритма.

Нет. Утечка это когда ты забыл чистить данные, которые тебе не нужны. Неважно, указатели это или данные, или то и другое. Утечка может быть такой, что ты постоянно выделяешь все больше и больше памяти под новые данные, а про старые ты забыл, они даже могут быть доступны и использоваться алгоритмом (!).

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

Так что в вопросе бесконечного роста потребления памяти алгоритмом есть только один ключевой момент: насколько это разумно, когда в моем распоряжении имеются компы лишь со 128Мб ОЗУ. А вот когда, ты включил разум, все сделал и вдруг алгоритм стал жрать больше чем положено — это утечка. Положено мемоизации использовать бесконечно ОЗУ — значит так задумано. Хотя от потребления больше ОЗУ чем минимально необходимо (утечка) такой подход не спасет.

Сложно сказать. Опять же возращаемся к циклам. Допустим известно, что сколько каждая страница будет потреблять памяти. Тогда, утечка будет в том случае, если при повторном проходе этих же действий потребление ОЗУ вырастит.

То есть реализация браузера, который хранит в памяти все страницы, на которых хоть раз побывал считается нормальной, а не утечкой памяти?

Ещё можно текстовый редактор такой сделать... А ещё лучше дисковый кэш операционной системы. А как память кончается принудительно перезагружать :-)

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

Выделяет — нормально. Но если браузер при непрерывной работе стабильно через некоторое время начинает свопиться — это ненормально. То есть открыл я 100 страниц, закрыл, открыл другие 100, закрыл. Открываю одну страницу — у браузера уже больше 4Гб. И уменьшить этот объём только его перезапуском.

А рост потребления пропорционально входным данным это нормально.

Чтоб ты grep'ом пользовался, у которого объём памяти растёт пропорционально входным данным! Нормально...

Go? Почему ещё никто не предложил Go?!

Чтоб ты grep'ом пользовался, у которого объём памяти растёт пропорционально входным данным! Нормально...

Хорошо, шутку понял. Но не смешно. grep'у не нужно откатываться обратно к предыдущим значениям, он тупо выводит все сразу по FIFO, если так можно выразиться. А вот мемоизации нужно хранить значения, ибо они могут понадобиться в любой момент.

Всё. Спор получается странным. Тебя не убедить.

Так что в вопросе бесконечного роста потребления памяти алгоритмом есть только один ключевой момент: насколько это разумно, когда в моем распоряжении имеются компы лишь со 128Мб ОЗУ.

Вопрос про утечки был в контексте языка Ада. Так вот там вопрос утечек стоит именно в контексте условно бесконечного потока входных данных (времени работы программы). При этом объём памяти обязан быть ограничен. Так как перезапускать программу управления реактором или авионикой истребителя при недостатке памяти попросту опасно.

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

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

Как страшно жить.

Надо математически доказывать, что память не кончится в самый неподходящий момент.

Не знаю как у нас, в США ЯП для военных объектов должен быть сертифицирован и стандартизирован. Чтобы в случае ЧП никто не смог свалить вину на ЯП. Почему эту методологию не применяют для реакторов и самолетов я не знаю. Видимо, такова стоимость жизни.

Нашел. https://en.wikipedia.org/wiki/Comparison_of_programming_languages

Ада стандартизирована, так что тебе не надо ничего доказывать :)

Хорошо, шутку понял. Но не смешно. grep'у не нужно откатываться обратно к предыдущим значениям

Тут периодически предлагается написать grep кратко (например для оффтопика). Видел вариант

#!/usr/bin/perl
@strings=<STDIN>;
foreach (grep /$ARGV[0]/, @strings) {print $_};

Как считаешь, есть в нём утечка памяти?

Чтобы в случае ЧП никто не смог свалить вину на ЯП.

При чём тут язык? Если ты на Ада будешь использовать new где попало, то память кончится. И виноват будет разработчик алгоритма, а не язык.

Почему эту методологию не применяют для реакторов и самолетов я не знаю.

Применяют. Поэтому пишут для них на Ада, а не на Си/Си++.

Тут двойное потребление ОЗУ из-за незнания особенностей Perl. Можно переписать иначе и тогда потребление снизится до минимума:

while (<STDIN>) { print grep /$ARGV[0]/ }

А вообще, проблема кроется в том, как Perl выделяет память под данные. В частности, для строк и элементов массива в строковом представлении обычно выделяется намного больше памяти, чем они действительно занимают. Кроме того, при операциях со строками, Perl их не модифицирует, если происходят операции «вырезания» куска из строки, а использует счетчики. В итоге, если загнать файл как указано в оригинальном примере скажем в 123 678 байт, то Perl выделит скорее больше памяти, чем ожидается (может 192 кб, может 256 кб, зависит от длин строк).

И виноват будет разработчик алгоритма, а не язык.

Да. Но я думал ты говоришь про случай, когда разраб все сделал правильно, а на деле оказалось, что спецификации ЯП неверные (выделяет на 1 байт больше чем положено). А если спек нету — ты должен этот момент доказать. В этом вся разница.

Смысл в том, что @strings=<STDIN> загонит входной файл в ОЗУ, а это для данной задачи не нужно.

Вот это я и пытаюсь доказать как критерий «утечки памяти». И в этом смысле наличие/отсутствие GC сильно не помогает.

А если спек нету — ты должен этот момент доказать. В этом вся разница.

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

адепт тотально
Адепт старается

Какой адепт, ты про что вообще?

Можно мне увидеть примеры нечёткости в текущем мире?

Чтение рукописного текста например. Распознавание глазами неразборчивого почерка - отличный пример нечеткой логики ИРЛ.

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

В таком случае твоя секретарша эникейщик программист, поскольку справляется со своими задачами.
Тут видишь-ли всплывает нюанс: Какие задачи должен решать программист, а какие нет. Задач очень много от ИИ-подобных систем и физических движков до операционных систем и компиляторов с оптимизациями. Все они разные, требуют знания разных разделов математики и нет людей, которые все это делают одинаково хорошо. Зато есть люди, которые сильны в своей области. Так кто же из них программист? ОС - программисты, ИИ и компиляторы - макаки за клавиатурой? Компиляторы - программисты, ОС и ИИ - макаки?

Поэтому пишут для них на Ада, а не на Си/Си++.

На самом деле и для авиации, и для машиностроения, и для военных, и для космоса софт на C++ пишут очень давно. См.например JSF C++ coding standards, Orion C++ coding standards, MISRA-C++. Правда C++ там сильно отличается от того, что используется в мейнстриме, что не удивительно.

Это называется неэффективный алгоритм, а не утечка памяти.

Подожди. Я процитирую то, на что я задал вопрос:

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

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

Можно такое даже про Hello, world на C сказать. Программа большую часть времени загружается в память == течет.

Ну а по поводу

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

Это вообще-то бред. Java использует память вполне предсказуемым (известным заранее) образом. Возможно не все ява-макаки о нем знают, но это тоже некоторый алгоритм.

Итого: память растет, по-твоему это у нее память течет?

Если алгоритмически у неё есть верхний предел, то нет.

Потому, что go(его компиляторы) не порождает устойчево код, который быстрее кода, который порождает C(его компиляторы).

Ну так у java есть ограничение GC.

Ну так у java есть ограничение GC.

Только при его достижении программа падает. Так и у всех остальных ulimit есть. Я про алгоритмическое ограничение. Типа: «служебная информация СУБД не превышает K * log(размер БД)». Далее можно получить строгое ограничение (для БД = размер диска).

А я и не говорил про чистоту - он так же не претендовал жабку, но почему-то жабкой оказался. Как так?

Ну я не лиспер, но всё-таки кажется, что такое сравнение не совсем честное. Ну то есть, если ты на джаве не будешь пользоваться ГЦ, то да, такой код явно не идиоматический. Как и сплошные асм-вставки в лиспе, ну а если там циклы и мутабельные переменные, то вполне нормально, как по мне.

пруфцуем безопасность safe, а быстроту unsafe-портянками. Казалось бы - где тут ошибка?

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

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

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

Почему ещё никто не предложил Go?!

А он быстрее?

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

А (теоретически) проанализировать сорцы компилятора (если доступны)? Ведь и при наличии спек, в нём могут быть баги.

А (теоретически) проанализировать сорцы компилятора (если доступны)? Ведь и при наличии спек, в нём могут быть баги.

Тогда можно. Но очень долго, так как компилятор больше, чем большая часть прикладных задач.

И при чем тут «утечка памяти»? По-моему ты уже сменил тему разговора, пройдись по комментариям вверх.

К слову, упадет, только если не дать GC ему освободить память. Например, держать объекты в массиве. Ну так тут и C упадет, разницы никакой.

Ну а про тонкую настройку — а зачем такая настройка общей задаче? Нам достаточно задать верхнее ограничение, а пока оно не достигнуто — пусть делает что хочет.

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

И еще, я не считаю, что кричать «только ручное управление, только хардкор!» или «GC всегда лучше» — это что-то хорошее. Все зависит от задачи. Так что вернем разговор в старое русло — мы обсуждали , что есть «утечка памяти».

И при чем тут «утечка памяти»?

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

Например, держать объекты в массиве.

Вот-вот. GC не панацея. А ещё он просто может тупить: google://tardy gc.

Ну а про тонкую настройку — а зачем такая настройка общей задаче?

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

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

Неограниченный рост потребления памяти реализованным алгоритмом.

Неограниченный рост потребления памяти реализованным алгоритмом.

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

К слову, упадет, только если не дать GC ему освободить память

Иногда сам GC роняет. Например в Lisp'е (SBCL) если сделать список элементов на 80% доступной памяти, то всё будет работать пока этот список доступен. А при попытке GC его собрать вылетает. Или надо его собирать как при ручном удалении: с конца и после каждого пакета элементов вызывать вручную GC.

Неограниченного не бывает, если нет ошибки в алгоритме

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

Более того, если можно доказать, что динамические объекты не превысят заранее определённый объём, то можно аллоцировать и очищать нужный объём при запуске, что позволит обезопасить свою программу от OOM-killer'а.

Ну, баги Gc тоже бывают. Но сама концепция тут ни при чем.

вероятность ошибки в алгоритме, использующем динамическую память больше, чем в не использующем

Алгоритме — да, программе в общем случае — все зависит от программы.

Go близок

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

Так а чем C не устраивает?

Если слишком тяжело, то возьми C++.

праильно програмировать на C++ ещё тяжелее чем на C

Хэш таблица приватная и снаружи недоступная.

Да, я об этом потом подумал. Так скажем, доступна, если всё сделать пабликом. Или из отладчика без кастов целого к указатели. В С (и в Аде, насколько я понимаю) возможны случаи, когда память «совсем» потерялась. Она числится выделенной, но на неё ничто не указывает.

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

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

Не делай unchecked.

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

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

Иногда сам GC роняет. Например в Lisp'е (SBCL)

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

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