Зависимость скорости malloc от выделяемого объема
а эксперимент поставить не судьба?
Можно. Но Если ставить, то надо по сотню мег выделять (иначе погрешность большая). А при этом память будет фрагментироваться, следовательно поздние тесты будут медленнее. Т.е. погонять можно, но предпочтительнее узнать точные данные.
нифига не ясное дело
Как оно зависит? Ясное дело, что замедляется с увеличением выделяемого куска, быстрее, чем линейный рост?
во первых это конечно от аллокатора зависит, коих дофига разных реализаций
для нормального аллокатора не должно зависеть вообще
и в худшем случае время должно быть логарифмическим от общего количества выделенных и свободных блоков-фрагментов, а не размера их (если алгоритмы выделения/освобождения медленнее, аллокатор - дерьмо).
Такие вещи нужно определять только опытным путем. Любые теоретические рассуждения скорее всего будут неверны.
Понятно. Кстати, почему нефига не ясное дело? Понятно что растет, а вот быстрее линейного или медленнее - это вопрос. И от этого зависит, какую мне реализацию делать.
Вобщем, логарифмический рост времени поиска, это хорошо. Будем исходить из этого.
Вобщем, логарифмический рост времени поиска, это хорошо. Будем исходить из этого.
Такие вещи нужно определять только опытным путем. Любые теоретические рассуждения скорее всего будут неверны.вовсе нет,
средние величины намного легче (и при правильно поставленном тесте более корректно) определяются опытным путем, а максимальное время выполнения какого-то действия (т.е. для наихудшего случая) и его ассимптотические свойства намного проще определить теоретически для известного алгоритма.
Кстати, почему нефига не ясное дело?очевидно потому, что размер выделяемого блока во внутренних структурах аллокатора - это всего лишь одна из записей в описании блока-фрагмента (или разность двух записей, если блок-фрагмент описан диапазоном адресов скорость работы алгоритма зависит от количества таких описаний, но никак не от значений их записей.
го ассимптотические свойства намного проще определить теоретически для известного алгоритмафигня тут в том что алгоритм размазан по куче кода - libc, ядро.
и зависит от архитектуры VM операционки и вообще мог меняться со временем очень сильно много раз.
так что лучше и быстрее экспериментально проверить в требуемых условиях, чем изучать теоретически.
> Как оно зависит?
Никак, пока не дойдёшь до конца выданной под кучу памяти.
---
...Я работаю антинаучным аферистом...
Никак, пока не дойдёшь до конца выданной под кучу памяти.
---
...Я работаю антинаучным аферистом...
> фигня тут в том что алгоритм размазан по куче кода - libc, ядро.
Фигня ещё в том, что может не быть ни libc, ни ядра.
---
VARIABLE 1
Фигня ещё в том, что может не быть ни libc, ни ядра.
---
VARIABLE 1
фигня тут в том что алгоритм размазан по куче кода - libc, ядро.обычно конечно так
и зависит от архитектуры VM операционки
но все равно максимальное время выполнения и его ассимптотику ты не выяснишь быстрее чем теоретическим анализом всего алгоритма (поскольку не знаешь какой случай наихудший).
и вообще мог меняться со временем очень сильно много раз.а это тут причем?
вместе с алгоритмом менялась скорость его выполнения.
ясно, что мы анализируем (теоретически или экспериментально) именно тот алгоритм, который нас интересует.
так что лучше и быстрее экспериментально проверить в требуемых условиях, чем изучать теоретически.что и как - лучше зависит исключительно от того, что собственно требуется выяснить
> но все равно максимальное время выполнения и его ассимптотику
> ты не выяснишь быстрее чем теоретическим анализом всего алгоритма
Теоретически, конечно, это так.
Но в практически полезных случаях это не так.
---
...Я работаю антинаучным аферистом...
> ты не выяснишь быстрее чем теоретическим анализом всего алгоритма
Теоретически, конечно, это так.
Но в практически полезных случаях это не так.
---
...Я работаю антинаучным аферистом...
> но все равно максимальное время выполнения и его ассимптотикуэти 2 предложения противоречат друг другу
> ты не выяснишь быстрее чем теоретическим анализом всего алгоритма
Теоретически, конечно, это так.
Но в практически полезных случаях это не так.
Может ты хотел сказать, что максимальное время выполнения и его ассимптотика не является практически полезным показателем?
Если так, то можешь так считать. Лично меня этот показатель интересует в первую очередь, поскольку он не зависит от условий использования, которые могут меняться.
> Может ты хотел сказать, что максимальное время выполнения
> и его ассимптотика не является практически полезным показателем?
Нет.
В практически полезных случаях память выделяется за время,
не зависящее от запрашиваемого объёма (случай особой наглости
отбрасываем, как несущественный) либо за бесконечно большое время,
если операционная система не гарантирует предоставления времени для работы.
Хотя, навскидку, можно заставить камповский malloc заниматься занулением
или замусориванием выделяемой памяти.
---
...Я работаю антинаучным аферистом...
> и его ассимптотика не является практически полезным показателем?
Нет.
В практически полезных случаях память выделяется за время,
не зависящее от запрашиваемого объёма (случай особой наглости
отбрасываем, как несущественный) либо за бесконечно большое время,
если операционная система не гарантирует предоставления времени для работы.
Хотя, навскидку, можно заставить камповский malloc заниматься занулением
или замусориванием выделяемой памяти.
---
...Я работаю антинаучным аферистом...
Могу ещё больше разочаровать: то что память выделилась, ещё не факт что её на самом деле VM выделила. Запросто может так получиться, что ты начнёшь её использовать и начнутся ДИКИЕ тормоза.
От размера блока вообще скорре всего ничего не зависит. От размера зависит скорость первого использования.
От размера блока вообще скорре всего ничего не зависит. От размера зависит скорость первого использования.
Хотя, навскидку, можно заставить камповский malloc заниматься занулениемпо идее аллокатор не должен этим заниматься
или замусориванием выделяемой памяти.
это софтина освобождающая память с чувствительными данными должна их сама предварительно занулять/замусоривать.
хотя согласен, что некоторые могут перестраховаться
http://www.joelonsoftware.com/articles/fog0000000319.html
вот здесь есть немного про аллокаторы, понятными словами
вот здесь есть немного про аллокаторы, понятными словами
>> Хотя, навскидку, можно заставить камповский malloc заниматься занулением
>> или замусориванием выделяемой памяти.
> по идее аллокатор не должен этим заниматься
Я не говорю, чем он должен или не должен заниматься,
я говорю, что камповский malloc, судя по всему, можно
заставлять заниматься такими вещами. Именно в том
виде, в котором этот malloc распространяется.
---
...Я работаю антинаучным аферистом...
>> или замусориванием выделяемой памяти.
> по идее аллокатор не должен этим заниматься
Я не говорю, чем он должен или не должен заниматься,
я говорю, что камповский malloc, судя по всему, можно
заставлять заниматься такими вещами. Именно в том
виде, в котором этот malloc распространяется.
---
...Я работаю антинаучным аферистом...
Оставить комментарий
sollariss
Как оно зависит? Ясное дело, что замедляется с увеличением выделяемого куска, быстрее, чем линейный рост?