Здравствуйте, landerhigh, Вы писали:


L>Я в код н вчитывался , по заголовку оценил.
L>Но в C++ список — это тебе не массив какой, описанных тобой ужасов с распределением памяти не ожидается.

А контейнеры на массивах вызывают чудесный аналог realloc который гарантирует перераспределение по месту ? Чудеса !

Здравствуйте, Erop, Вы писали:

I>>В х64 эта проблема неактуальна, АП много больше чем доступно памяти. Для х86, проблема очень актуальна, если приложение большое, см выше.

E>ну я же уже писал, что сочувствую. Это просто ещё раз показывает, что большие списки не надо на шарпе делать, в С, например, памятью рулить можно намного более осмысленно, в том числе и фрагментацией АП процесса.

В C# тоже можно, нужно просто другие коллекции юзать или хотя бы следить за capacity.

E>Кстати, а раскидать объекты/подсистемы по нескольким процессам не помогает?

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

Здравствуйте, Erop, Вы писали:

I>>Оценка мастштаба трагедии для твоего случая уже дадена в первых ответах — никакой трагедии, абсолютно, ибо GC не выйдет за пределы одного-двух хипов (16мб).

E>И к чему тогда весь кипишь и стоны, что все умрут?

Я уже описал, где и когда это критично. Повторить ?

Здравствуйте, Erop, Вы писали:

E>Ну не надо массивы больше 100 метров хреначить просто и всё. Они на это не рассчитаны просто. Но это довольно-таки специфическая проблема, вообще-то...

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

Здравствуйте, Ночной Смотрящий, Вы писали:

I>>Собтсвенно ФП коллекции безбожно тормозят сами по себе.

НС>Однако построенный на них компилятор шарпа работает в разы быстрее нативного.

Я в курсе, но это не значит, что сами по себе они работают быстрее

Здравствуйте, Ikemefula, Вы писали:

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

а память разделять между процессами дорого выходит?

Здравствуйте, Ikemefula, Вы писали:


E>>И к чему тогда весь кипишь и стоны, что все умрут?

I>Я уже описал, где и когда это критично. Повторить ?

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

Здравствуйте, Ikemefula, Вы писали:

I>Специфическая, но на больших приложениях довольно часто дает проблемы, ибо там с фрагментацией по естественным причинам очень плохо. И фокус такой, что свалится GC необязательно на этом цикле. Т.е. пока найдешь и отловишь — семь раз поседеешь, если раньше не сталкивался.

некоторые люди, когда видят, что упала относительно болшая аллокация, начинают использовать ИНСТРУМЕНТЫ, что бы посмотреть что там в АП процесса и в кучах творится, как бы сразу, а не когда поседеют. Но тебе такие не нужны, я понимаю, тебе нужны такие, которые список верно угадают, как вертеть

Здравствуйте, Ikemefula, Вы писали:


L>>Но в C++ список — это тебе не массив какой, описанных тобой ужасов с распределением памяти не ожидается.

I>А контейнеры на массивах вызывают чудесный аналог realloc который гарантирует перераспределение по месту ? Чудеса !

А контейнеры на массивах предполагают включение девайса /dev/head при их использовании

Здравствуйте, Erop, Вы писали:

E>некоторые люди, когда видят, что упала относительно болшая аллокация, начинают использовать ИНСТРУМЕНТЫ, что бы посмотреть что там в АП процесса и в кучах творится, как бы сразу, а не когда поседеют.

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

>Но тебе такие не нужны, я понимаю, тебе нужны такие, которые список верно угадают, как вертеть

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

Здравствуйте, Erop, Вы писали:

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

E>а память разделять между процессами дорого выходит?

По разному. Если данные потоковые — то легко.

Здравствуйте, Erop, Вы писали:

I>>Я уже описал, где и когда это критично. Повторить ?

E>Э-э-э, ты эту тему насал с какого-то кидания калом, как выяснилось, речь шла о редком специальном случае и только. Тебе не хочется извиниться?..

Начни с себя.

Здравствуйте, Ikemefula, Вы писали:

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

Здравствуйте, Ikemefula, Вы писали:

I>Начни с себя.

Я топиков со слов "Алё ! Ты математик или погулять вышел ?" как бы не начинал...

Здравствуйте, Erop, Вы писали:

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

Както неочевидно — ты до сих пор пытаешься рассуждать про память, когда я говорю про адресное пространство

Здравствуйте, Erop, Вы писали:

I>>Начни с себя.

E>Я топиков со слов "Алё ! Ты математик или погулять вышел ?" как бы не начинал...

И что тут необычного для КСВ ?

Здравствуйте, Ikemefula, Вы писали:

I>Както неочевидно — ты до сих пор пытаешься рассуждать про память, когда я говорю про адресное пространство

Какая разница? Всё равно всё сводится к VirtualAlloc в конце концов. Просто GC дотнетический, как я понял, не умеет отдавать большие куски, или плохо умеет и рулить этим нельзя или неудобно.

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, Ikemefula, Вы писали:

I>>Както неочевидно — ты до сих пор пытаешься рассуждать про память, когда я говорю про адресное пространство

E>Какая разница? Всё равно всё сводится к VirtualAlloc в конце концов. Просто GC дотнетический, как я понял, не умеет отдавать большие куски, или плохо умеет и рулить этим нельзя или неудобно.

Разница такая — большое потребление памяти всегда большое потребление АП. малое потребление памяти совсем необязательно малое потребление АП. GC дотнета умеет отдавать и разруливать болшие куски намного лучше, чем большинство плюсовых аллокаторов.

Здравствуйте, Ikemefula, Вы писали:

I>Разница такая — большое потребление памяти всегда большое потребление АП. малое потребление памяти совсем необязательно малое потребление АП. GC дотнета умеет отдавать и разруливать болшие куски намного лучше, чем большинство плюсовых аллокаторов.

Что такое "большинство"? рантайм дефолтного компилятора куски боьлше какого-то порога, вроде 40К аллокируют сразу по VirtualAlloc,..

Здравствуйте, Erop, Вы писали:

I>>Разница такая — большое потребление памяти всегда большое потребление АП. малое потребление памяти совсем необязательно малое потребление АП. GC дотнета умеет отдавать и разруливать болшие куски намного лучше, чем большинство плюсовых аллокаторов.

E>Что такое "большинство"? рантайм дефолтного компилятора куски боьлше какого-то порога, вроде 40К аллокируют сразу по VirtualAlloc,..

Это как то решает проблемы с фрагментацией ?