Linux malloc //малко e flame...

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

Не, потребителската програма изобщо не ги решава, а прехвърля топката на ядрото, което пък прави някакво може би добро решение, но определено противоречащо на Посикс стандарта.

Програмта няма да е посикс(т.е. една част от нея няма да е посикс), или пък ако е сорс - с условна компилация пак ще е преносима.

Тя с бързодействието си ги решава, за сметка на иконоимята на памет.
Оверкомит върши чудесна работа на многопотребителски сървър, примерно в някой институт, където вървят много изчислителни програми едновременно. Имайки предвид, освен всичко друго, че там хората не са кой знае какви програмисти и не използват паметта рационално, без този номер щеше да е много зле положението.

> Имайки предвид, освен всичко друго, че там хората не са кой знае какви
> програмисти и не използват паметта рационално, без този номер щеше да е
> много зле положението.

Точно каквото казах аз -- overcommit наказва добрите програмисти за сметка на некадърниците.

> Имайки предвид, освен всичко друго, че там хората не са кой знае какви програмисти и не използват паметта рационално, без този номер щеше да е много зле положението.
без този номер щяха да се научат да ползват паметта по-рационално.

Satan`s Defloration Incorporated

В случая да, но сега ще ти дам пример когато не:
Представи си, че правиш сметка и запълваш масив с междинните резултати примерно с експоненциално намаляваща скорост байт по байт. Тогава в зависимост от това колко е експоненциално - в по голямата(най-малко 2 пъти) част от времето програмата ти ще е използвала по малко от половината заделена памет(може и 100 пъти да се случи). Този проблем естествено може да се реши със заделяне на паметта на по малки блокове, но колкото по малки - толкова по голям брой заделяния - толкова повече ЦПУ.
За нарушаването на посикс съм съгласен, но при оверкомит 2 не се нарушава :). Проблема за програмистите е, че по дефаулт не е 2.

Ами представи си, че имаш две такива програми, и двете си мислят че реално са получили паметта, работили са 120 дни да решат проблема с world hunger ;) ...

Въпроса е кого да псува потребителя, чиято програма е убита от OOM killer-a на 121-ия ден ;Р

Неволята учи - следващия път ще се сети да си съхранява периодично текущите резултати във файл.

И даже да си направи скрипт, който да следи, след като падне програмата да я стартира и да и подаде фаила с текущите резултати от където да продължи сметката. При това юзера може спокойно да спи 120 дена.

Мдаа, още един пример как неправилно решение води до друго такова :) Ами ако алгоритъма е такъв, че не позволява рестартиране без да имаш резултата от целия масив досега? И _повечето_ стойности в масива се променят, а не само малък брой. Някой тук спомена за бързодействие ... Как се включва бързодействието със записа на диск на (теоретично) огромен масив?

Не, ще направи memset на заделената памет веднага след като я задели, и по този начин ще унищожи ползата от overcommit-а. Не че това ще помогне много, защото не е ясно кого и кога OOM killer-a ще избере да убие. Недетерминираност отвсякъде.

Като казвам периодично - може да е на час може да е на ден.

Ами точно толкова периодично може да си заделя памет :Р

Различно е, масива мога да го запълвам примерно за 1 мин. но през първите 50 сек да е на 10% само, после да го освобождавам, и пак да го заделям за следващата итерация. Това например при итеративни алгоритми, когато да кажем имаме 2(или повече) масива, и на базата на сметки от първия попълваме втория.След това резултатите в първия вече не ни трябва, освобождаваме го и заделяме масив за следващата итарация. А итерациите могат да са 1000.. много. И освен това имай предвид че това не е чистата скорост на запълване на масив, а основната част от времето ще отива за сметките. А съхраняването на диска и на час да е, то времето необходимо за това ще е пренебрежимо малко в сравнение с този интервал. Т.е. >99% от времето ще смята програмта.