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

I>>Проблемы есть и было сказано, когда и при каких условиях они возникают.
E>А вот твой коллега утверждает

Автор: Sinix
Дата: 21.10.13

, что конкретно такая проблема -- редкость...

Более того — я сам говорил, что это не типичная проблема. Забыл ? "типичный случай нетипичного случая"

I>>Это никакого отношения к фраментации АП не имеет. Я показал два сценария, в которых твой VirtualAlloc ничем не помогает.

E>Это всё, как ты говоришь, "рассуждения о прекрасном", а в реальности ещё как помогает, и я даже уже пару раз объяснял тут почему помогает, но Ikemefula-то, если и читатель, то уж точно не пониматель

Я показал два сценария фрагментации, один из них простейший, проще не бывает — два фрагмента. Покажи как там поможет VirtualAlloc.

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

E>Это всё, как ты говоришь, "рассуждения о прекрасном", а в реальности ещё как помогает, и я даже уже пару раз объяснял тут почему помогает, но Ikemefula-то, если и читатель, то уж точно не пониматель

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

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

I>>Ты похоже отказываешься понять, что "память закончится" это вещь сильно относительная.

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

Как бы очевидно, что если прога должна работать с объемом данных Х, то на этом объеме не должно быть ни ООМ, ни свопа, ни лагов, ни замерзаний.

Вот тебе это очевидно ?

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

E>>Ты писал, что архитектуре 10 лет, но тормоза от листа вылечили тока в 2012...

I>Нет, такого не писал. Я написал что ООМ вылез в 2012м, а до того узким местом были не коллекции а совсем другие вещи, но ты, конечно, не читатель

Ну так может оно память и АП жрало не по делу и раньше, просто до ООМ не доходило пока?..

I>А это очевидно — ", если есть проект, то там указаны ограничения, или легко из него понятны, так скажем..."
Ну дык и? Вот, например, ограничения и всякие системные требования ОС виндовс майкрософт оценить в состоянии, например. У вас проект сложнее винды?..

I>Проектные нагрузки никто не превышал. Если кастомеру нужно скажем объем данных Х, то в релизе будет запас некоторый. Какие проблемы решаются до релиза, кастомера не интересует, главное что бы ООМ не было у кастомера.

Ну да. Но я так тебя понял, что ООМ в 2012 был для вас неожиданностью...
И что рвануло смотрели по профайлеру. Вот наши продукты, например, всё время проверяются на то, скока памяти ап и прочих ресурсов кушают и излишки каждый раз подрезаются...

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

НС>>А мой опыт оптимизации реального кода говорит, что 90% устраняемых при этом проблем вовсе не из-за неправильно выбранных структур данных.

E>Дык, по идее, это же и означает, что в 90% случаев программистам удаётся таки как-то выбрать адекватные структуры данных ещё на этапе проектирования, а не исходя из показаний профайлра...

Это какая то особенная логика нужна. если 90% проблем "не из-за неправильно выбранных структур данных" то есть варианты

1. выбрали структуры правильно
2. выбрали структуры неправильно, но сами и пофиксили, с профайлером
3. выбрали структуры неправильно, но сами и пофиксили, без профайлера
4. выбрали структуры правильно, масштабировали без профайлера, в структурах не накосячили
5. выбрали структуры правильно, масштабировали с профайлером, в структурах не накосячили

Дальше сам можешь дополнить.

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

I>С профайлером.
и что ты профилировал?..

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

I>В реальности те случаи VirtualAlloc, про которые ты говорил, организуются на раз самопальным аллокатором безо всякого VirtualAlloc.

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

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

I>>> (*) Ты похоже отказываешься понять, что "память закончится" это вещь сильно относительная.

I> (****) Как бы очевидно, что если прога должна работать с объемом данных Х, то на этом объеме не должно быть ни ООМ, ни свопа, ни лагов, ни замерзаний.

I>Вот тебе это очевидно ?

Мне не то, что бы неочевидно, а совсем не понятно, как (*) сочетается с (****)...

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

I>>>> (*) Ты похоже отказываешься понять, что "память закончится" это вещь сильно относительная.

I>> (****) Как бы очевидно, что если прога должна работать с объемом данных Х, то на этом объеме не должно быть ни ООМ, ни свопа, ни лагов, ни замерзаний.

I>>Вот тебе это очевидно ?

E>Мне не то, что бы неочевидно, а совсем не понятно, как (*) сочетается с (****)...

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

Объясняю еще раз — нужно не рассуждать о прекрасном, а смотреть реальный расклад, что же с памятью в приложении. То есть, максимальный непрерывный фрейм

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

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

I>>Нет, такого не писал. Я написал что ООМ вылез в 2012м, а до того узким местом были не коллекции а совсем другие вещи, но ты, конечно, не читатель

E>Ну так может оно память и АП жрало не по делу и раньше, просто до ООМ не доходило пока?..

А это не важно. Результат оценивается исходя из поставленых целей. Достигли — есть результат. Не достигли — нет результат. А руководствоваться рассуждениями о прекрасном только тебе и EP интресно.

I>>А это очевидно — ", если есть проект, то там указаны ограничения, или легко из него понятны, так скажем..."
E>Ну дык и? Вот, например, ограничения и всякие системные требования ОС виндовс майкрософт оценить в состоянии, например. У вас проект сложнее винды?..

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

I>>Проектные нагрузки никто не превышал. Если кастомеру нужно скажем объем данных Х, то в релизе будет запас некоторый. Какие проблемы решаются до релиза, кастомера не интересует, главное что бы ООМ не было у кастомера.

E>Ну да. Но я так тебя понял, что ООМ в 2012 был для вас неожиданностью...

Это твои фантазии.

E>И что рвануло смотрели по профайлеру. Вот наши продукты, например, всё время проверяются на то, скока памяти ап и прочих ресурсов кушают и излишки каждый раз подрезаются...

Ты внятно скажи что у вас за продукты и какие требования ставятся по расходу ресурсов.

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

I>>С профайлером.
E>и что ты профилировал?..

Потребление памяти.

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

E>>и что ты профилировал?..
I>Потребление памяти.
Код какой, и на каком запросе?

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

E>>>и что ты профилировал?..
I>>Потребление памяти.
E>Код какой, и на каком запросе?

Нет никаких запросов Код — разный. Какую часть из 50мб показать ?

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

I>Нет никаких запросов Код — разный. Какую часть из 50мб показать ?
Чё? Тебе понадобилось 50 метров кода что бы попрофилировать реверс списка?
А ты прикольный...

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

I>>Нет никаких запросов Код — разный. Какую часть из 50мб показать ?
E>Чё? Тебе понадобилось 50 метров кода что бы попрофилировать реверс списка?

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

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

E>Не "никто", а люди, отметившиеся в теме. Например такие эксперты, как ты...

Перешел на личности — слил.

НС>>Затем что посчитал интересным на них ответить. Но это вовсе не означает, что если я на какие то другие, напрямую мне не заданные вопросы в этом топике не ответил, то это означает что я не способен на них ответить.

E>Этот вопрос я тебе уже несколько раз задал напрямую.

Где?

E> На всякий случай и здесь вот ещё раз спрашиваю...

Что именно?


НС>>Если надо быстро считать, то тут точно на С++ писать придется. Но не из-за памяти, а потому что CLR до сих пор не имеет интринсиков для векторных расширений.
E>У-у-у, а зачем тут векторные расширения?..

Для быстрого вычисления сверток. DSP — он такой.

НС>>Нет, так не есть.
E>Доказательства?..

Утверждение ты делал, тебе и доказывать.

НС>>У тебя какие то помехи в канале, я твою фразу не достраивал, я ее привел as is, путем копирования через буфер обмена.
E>Ну ты ещё раз подтвердил, что не поймёшь меня, потому, что хочешь не понять...

Или ты просто понял, что фигню сморозил, а признать неправоту не способен. Вот и прячешься за софистикой.

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

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

А вопрос то и был не по этому вопросу, а по твоим фантастическим обобщениям.

НС>>2) а переделкой алгоритмов на такие, которые способны работать без индексного доступа.
E>Да понял я это, не волнуйся.

Пальцем в небо. Я не волнуюсь.

E> Я не только понял, но даже кратко сформулировал и повторил... почему это вызвало такой протест я не понимаю.

Протест вызвали твои фантастические обобщения.

E>Засим тему предлагаю зарыть, ты уже вполне достаточно объяснил, что в шарпе наступил коммунизм, в том смысле, что нет не нормальной коллекции с доступом по индексу, а потребности в ней, ровно как и в колбасе при коммунизме

Опять какие то левые выводы без намеков на логику.

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

E>Дык, по идее, это же и означает, что в 90% случаев программистам удаётся таки как-то выбрать адекватные структуры данных ещё на этапе проектирования

Ну да. Но есть нюансы. К примеру, передать byte[] через практически все RPC фреймворки существенно проще, чем Stream или какой нибудь MySuperCollection.

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

E>>Не "никто", а люди, отметившиеся в теме. Например такие эксперты, как ты...
НС>Перешел на личности — слил.

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

Не, самокритично, конечно, но несколько неожиданно...
IMHO, ты скромничаешь...

НС>Для быстрого вычисления сверток. DSP — он такой.
В данном случае для быстрого вычисления свёрток, надо из интеграла сигнала в конце диапазона вычесть интеграл сигнала в начале и просуммировать по диапазонам...
Чем тут тебе векторные расширения я