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

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

Угу. В целом мы с этого с НС начали, что есть целая школа такого программирования, когда стандартность и шаблонность кода ценится больше, чем его эффективность и элегантность. Я тока не пойму, почему ты бросился доказывать, что решение с обращением односвязного списка через промежуточный массив ссылок на элементы плохое. Ты же его ещё не профилировал, вроде?..

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

I>А может у тебя в ДНК чтото особенное ?
Ну с этим-то я и не спорю. Я умный

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

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

Кстати, ты им тоже говори так гордо, что они в IT не работают и не программисты вовсе?..

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

I>Вобщем твои понты прошли мимо кассы.
В смысле "понты"? Пока что всё, что ты рассказываешь, точно соответствует моим "понтам", ну кроме того, что ты "не математик", и, похоже, этим горд и менять такого важного статуса не планируешь...
Хотя я же уже писал, что это тоже вполне подход и для некоторыхх задач он очень даже в тему.

I>Были даже еще более убогими 10 лет назад С++ за С++ не считался, если с теперешним сравить.

Не знаю, кто там у кого не считался, и за что, но 10 лет назад был 2003 год, ну это так, для сведения о календаре и прочих жизненных обстоятельствах на нашей планете
А на вашей что было?..

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

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

Чёрт! Я же так и понял, что в случае если нужны таки большие массивы, то пишем на С++ и не жужжим. И так и написал в нескольких местах. Ты можешь пояснить кто тут с чем не согласен-то?

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

EP>Согласен. Но мой поинт в том, что большой класс проблем с производительностью можно избежать в зародыше, правильно выбрав структуры данных, а не ждать что-же скажет profiler по этому поводу.

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

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

То есть,в большом приложении совершенно не ясно, как повлияет на общий расклад изменение одной единственной операции, которая нужна везде, всем и постоянно. Она может вызываться на порядок другой чаще других, быть написаной сколь угодно неэффективно, но при это её вклад в общее время работы меньше 1-10%. И на кой ляд её трогать ?

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

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

EP>>Согласен. Но мой поинт в том, что большой класс проблем с производительностью можно избежать в зародыше, правильно выбрав структуры данных, а не ждать что-же скажет profiler по этому поводу.
I>Я за свои годы в основном тем и занимался, что реанимировал убитые проекты, занимаясь, в т.ч. оптимизацией.
I>[skip]

Это всё конечно очень интересно, но к чему всё это?
Ты притянул за уши какой-то случай из своей практики, где замена вектора на деку не помогла бы, потому что (surprise!) вектор изначально был выбран не правильно
Хотя у нас тут обсуждается случай вектора, который валится на фрагментации из-за плохого аллокатора.

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

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

E>Кстати, ты им тоже говори так гордо, что они в IT не работают и не программисты вовсе?..

Им то зачем ? Они уверенно отличают адресное пространство от памяти, и четко понимают, что VirtualAlloc в обсуждаемом вопрос как козе боян.

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

Представь себе продукт навроде САПР, в котором только дотнетного кода 50мб, а есть еще джава, С++, куча скриптов и даже кое что на ассемблере + кучка 3rd party либ. Над продуктом на старте работало почти пол-сотни человек, при том, что индусского кода в нём практически нет, и бОльшая часть — или математики, или с математическим образованием. Алгоритмы — свои же наработки из R&D, так и заимствования из разных разделов математики.

Но, не сомневаюсь, ты бы за день все требования вкурил, за второй проанализировал код, а за третий переписал все с нуля на С++.

I>>Вобщем твои понты прошли мимо кассы.
E>В смысле "понты"? Пока что всё, что ты рассказываешь, точно соответствует моим "понтам", ну кроме того, что ты "не математик", и, похоже, этим горд и менять такого важного статуса не планируешь...

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

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

E>Угу. В целом мы с этого с НС начали, что есть целая школа такого программирования, когда стандартность и шаблонность кода ценится больше, чем его эффективность и элегантность. Я тока не пойму, почему ты бросился доказывать, что решение с обращением односвязного списка через промежуточный массив ссылок на элементы плохое.

Просто так. У меня КСВ это способ пар выбросить, а не чтото дельное показать. За прошлые две недели я вкинул кода больше, чем за всё лето, так что нужно было где то отвлекаться, что бы мозг не закипел.

Что касается обращения списка, то оно ужасное. Я хотя ошибся в масштабе проблемы, с математикой плохо, но в целом все верно — добавление в List без указания размераслишком часто не имеет права на жизнь. Нагрузка на GC слишком большая, хоть это и неочевидно.
Во вторых, оно громоздкое, втрое длиннее обычного решения "в лоб" — в большинстве случаев короткий код чаще всего понятнее, правильнее, быстрее и вообще эффективнее.
Вот надо будет к проекту студента "на вырост" подключить — он в таких местах накосячит будь здоров. А с понятным кодом таких мин не будет.

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

EP>Это всё конечно очень интересно, но к чему всё это?
EP>Ты притянул за уши какой-то случай из своей практики, где замена вектора на деку не помогла бы, потому что (surprise!) вектор изначально был выбран не правильно

Если рассуждать о прекрасном то можно далеко зайти. Вектор вообще то изначально правильно был выбран. Узким местом он стал только в 2012м году и в основном потому, что
1 в проекте нельзя было уйти от х32 — 3rd party, плюсовый код и тд
2 потребовалось увеличить вдвое объем данных в памяти, специфика такая

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

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

EP>Это всё конечно очень интересно, но к чему всё это?
EP>Ты притянул за уши какой-то случай из своей практики, где замена вектора на деку не помогла бы, потому что (surprise!) вектор изначально был выбран не правильно

Сюрприз — код работал 10 лет правильно и вектор не был узким местом.

Вопрос — на каком основании считать правильность выбора вектора ? У тебя есть ответ или ограничишься рассуждениями о прекрасном ?

Более того — если отказаться от х32, то можно и нужно оставлять этот же вектор. Все что надо изменить — алгоритмы работы с данными, например InsertAt, RemoveAt и лишние Contains можно исключить вовсе. Новые алгоритмы будут жрать вчетверо больше памяти и раз в 10 больше АП, но это все достанется забесплатно.

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

I>Им то зачем ? Они уверенно отличают адресное пространство от памяти, и четко понимают, что VirtualAlloc в обсуждаемом вопрос как козе боян.

Второе -- это они зря. Вот у вас ООМ 10 лет и выскакивает поэтому...
Кстати "0 лет" -- это опечатка, правильно было читать "10 лет", но я думаю, что все, кроме тебя догадались, кстати

I>Представь себе продукт навроде САПР, в котором только дотнетного кода 50мб, а есть еще джава, С++, куча скриптов и даже кое что на ассемблере + кучка 3rd party либ. Над продуктом на старте работало почти пол-сотни человек, при том, что индусского кода в нём практически нет, и бОльшая часть — или математики, или с математическим образованием. Алгоритмы — свои же наработки из R&D, так и заимствования из разных разделов математики.

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

Могут, конечно, вылезти потом совсем неожиданные косяки, но чем лучше управление проектом, тем этих неожиданных косяков, а если вы 10 лет, как на вулкане живёте и строгаете затычки по результатам профилирования, то значит качество управления не очень хорошее. Я не хочу сказать, что у вас так или сяк, я не знаю как у вас. Я просто указал два полюса, тебе виднее к какому ближе ваша контора...

I>Но, не сомневаюсь, ты бы за день все требования вкурил, за второй проанализировал код, а за третий переписал все с нуля на С++.

В смысле? Какие требования?

I>Время нельзя потратить на всё подряд. Есть вещи, которые у меня получаются лучше математики. Так что я спокойно смотрю, если у кого то математика получается лучше, чем у меня.

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

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

I>Просто так. У меня КСВ это способ пар выбросить, а не чтото дельное показать. За прошлые две недели я вкинул кода больше, чем за всё лето, так что нужно было где то отвлекаться, что бы мозг не закипел.

Сочувствую. IMHO, решать психологические проблемы путём форумов почти так же плохо, как с помощью еды или алкоголя
Кстати, если ты всё это про пар, напишешь в подписи, то к тебе будут относиться с большим пониманием...

I>Что касается обращения списка, то оно ужасное. Я хотя ошибся в масштабе проблемы, с математикой плохо, но в целом все верно — добавление в List без указания размера слишком часто не имеет права на жизнь. Нагрузка на GC слишком большая, хоть это и неочевидно.
1) У этого "не имеет права на жизнь" и "ужасное" есть какие-то ЧИСЛЕДННЫЕ оценки?..
2) Как я тебя понял, ты оценить издержки того или иного кода без профайлера не можешь, как ты это сделал тут?

I>Во вторых, оно громоздкое, втрое длиннее обычного решения "в лоб" — в большинстве случаев короткий код чаще всего понятнее, правильнее, быстрее и вообще эффективнее.
Зато код со списком проще, и, если такого рода кода в проекте много, то копирование туда и сюда будут функциями...

I>Вот надо будет к проекту студента "на вырост" подключить — он в таких местах накосячит будь здоров. А с понятным кодом таких мин не будет.

Не-не-не, Давид Блейн, студент, скорее накосячит с кодом, который жонглирует ссылками, а не с кодом, который сначала в массив всё перекладывает, а потом обратно...

Кстати, обрати внимание, скока споров в основной ветке вызвало решение Дворкина. А всё из-за непонятности, кстати...

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

S>2. Ок, в четвёртый раз: если написать софт, который
S>a. работает исключительно под x86
S>b. всё время аллоцирует короткоживущие массивы всё увеличивающегося размера
S>c. вперемешку аллоцирует долгоживущие массивы

Есть способ проще, надо всего лишь, чтобы приложение работало с COM-компонентом x86.
За свою практику я уже несколько раз видел проекты с OOM из-за фрагментации памяти именно в таких условиях. Ещё один опыт был в Silverlight приложении, которое тоже работает в x86-браузере ессно.

--
С Уважением, Andir!

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

A>Есть способ проще, надо всего лишь, чтобы приложение работало с COM-компонентом x86.
A>За свою практику я уже несколько раз видел проекты с OOM из-за фрагментации памяти именно в таких условиях. Ещё один опыт был в Silverlight приложении, которое тоже работает в x86-браузере ессно.

Кстати, да — с интеропом всегда грабель немеряно.

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

E>Второе -- это они зря. Вот у вас ООМ 10 лет и выскакивает поэтому...

Несовсем ясно, откуда с 2012 по 2013й взялось десять лет

E>И что? Ты хочешь сказать, что этот проект сложнее, чем вы можете управлять, или что?

Я хочу сказать, что проект сложнее чем ты себе нафантазировал.

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

Спасибо, капитан очевидность.

E>Могут, конечно, вылезти потом совсем неожиданные косяки, но чем лучше управление проектом, тем этих неожиданных косяков, а если вы 10 лет, как на вулкане живёте и строгаете затычки по результатам профилирования, то значит качество управления не очень хорошее. Я не хочу сказать, что у вас так или сяк, я не знаю как у вас. Я просто указал два полюса, тебе виднее к какому ближе ваша контора...

Покажи откуда следует "строгаете затычки по результатам профилирования"

I>>Но, не сомневаюсь, ты бы за день все требования вкурил, за второй проанализировал код, а за третий переписал все с нуля на С++.

E>В смысле? Какие требования?

О, дурачка включил.

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

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

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

I>>Что касается обращения списка, то оно ужасное. Я хотя ошибся в масштабе проблемы, с математикой плохо, но в целом все верно — добавление в List без указания размера слишком часто не имеет права на жизнь. Нагрузка на GC слишком большая, хоть это и неочевидно.
E>1) У этого "не имеет права на жизнь" и "ужасное" есть какие-то ЧИСЛЕДННЫЕ оценки?..

Все уже было сказано.

E>2) Как я тебя понял, ты оценить издержки того или иного кода без профайлера не можешь, как ты это сделал тут?

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

I>>Во вторых, оно громоздкое, втрое длиннее обычного решения "в лоб" — в большинстве случаев короткий код чаще всего понятнее, правильнее, быстрее и вообще эффективнее.
E>Зато код со списком проще, и, если такого рода кода в проекте много, то копирование туда и сюда будут функциями...

Который проще ? Который в три раза больше нормального ?

E>Не-не-не, Давид Блейн, студент, скорее накосячит с кодом, который жонглирует ссылками, а не с кодом, который сначала в массив всё перекладывает, а потом обратно...

Да как то наоборот выходит

E>Кстати, обрати внимание, скока споров в основной ветке вызвало решение Дворкина. А всё из-за непонятности, кстати...

Оно, во первых, на плюсах, с указателями. Во вторых, полный вариант решения, а не огрызок.

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

I>Несовсем ясно, откуда с 2012 по 2013й взялось десять лет
Ты писал, что архитектуре 10 лет, но тормоза от листа вылечили тока в 2012...
А до того их не замечали. Или ты как-то неточно выразился?

I>Я хочу сказать, что проект сложнее чем ты себе нафантазировал.
А уоткуда ты знаешь, что я себе нафантазировал?..

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

E>>Я просто указал два полюса, тебе виднее к какому ближе ваша контора...

I>Покажи откуда следует "строгаете затычки по результатам профилирования"

Ну, бывает так, а бывает этак, а как у вас -- тебе виднее. Я там оставил то, до чего ты походу не дочитал...

E>>В смысле? Какие требования?
I>О, дурачка включил.
Попробуй выражаться яснее...

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

E>>1) У этого "не имеет права на жизнь" и "ужасное" есть какие-то ЧИСЛЕДННЫЕ оценки?..
I>Все уже было сказано.

То есть ответ
1а) оценок нет
1б) ты не математик к тому же

Я верно перевл?

I>Рассуждать о прекрасном можно сколько угодно. Профайлер сообщит те самые константы, которые почему то всегда исключают из рассмотрения.
Так как ты оценил-то без профалера?
И, кстати, кто конкретно "всегда исключает из рассморения"? Математики из вашей конторы или кто-то ещё?..

I>Который проще ? Который в три раза больше нормального ?
"Больше" не значит "сложнее".

I>Да как то наоборот выходит
О! У вас и студенты тоже *высший клас*... А вот у НС большинство не осиливают таки реверс списка в том ключе, какой он и ты хотите, а вот с промежуточнм листом осиливают. Интересно, как так выходит?..

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

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

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

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

S>>>Итак, раз уж мы говорим за 10 лет — где хоть одна статья с описанием нерешаемых проблем, вызванными особенностями LOH? Только плиз, написанная нормальным разработчиком со знанием матчасти, а не "Вау, мы поломали дотнет!"

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

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

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

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

I>>Несовсем ясно, откуда с 2012 по 2013й взялось десять лет
E>Ты писал, что архитектуре 10 лет, но тормоза от листа вылечили тока в 2012...

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

E>А до того их не замечали. Или ты как-то неточно выразился?

Похоже твои навыки чтения оставляют желать лучшего

I>>Я хочу сказать, что проект сложнее чем ты себе нафантазировал.
E>А уоткуда ты знаешь, что я себе нафантазировал?..

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

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

Проектные нагрузки никто не превышал. Если кастомеру нужно скажем объем данных Х, то в релизе будет запас некоторый. Какие проблемы решаются до релиза, кастомера не интересует, главное что бы ООМ не было у кастомера.
Новые требования — увеличить объемы данных примерно вдвое. И при всем этом проект масштабировался __постоянно__, а не раз в 10 лет.
Поэтому в условиях ограниченного АП, т.е. х32, ООМ это вполне ожидаемая проблема.

Более того, после оптимизации, если кастомеры снова захотят удвоить объем данных, снова вылезет ООМ. В общем случае для х32 это не решается, все что можно — это найти решение для текущего объема данных, с некоторым запасом.

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

E>То есть ответ
E>1а) оценок нет
E>1б) ты не математик к тому же

E>Я верно перевл?

Твои навыки чтения оставляют желать лучшего. Поищи что я писал про фрагментацию и размер непрерывного окна в АП в большом приложении под х32

I>>Рассуждать о прекрасном можно сколько угодно. Профайлер сообщит те самые константы, которые почему то всегда исключают из рассмотрения.
E>Так как ты оценил-то без профалера?

С профайлером.

E>И, кстати, кто конкретно "всегда исключает из рассморения"? Математики из вашей конторы или кто-то ещё?..

В зависимости от сложности математики.

I>>Который проще ? Который в три раза больше нормального ?
E>"Больше" не значит "сложнее".

В большинстве случаев наоборот.

I>>Да как то наоборот выходит
E>О! У вас и студенты тоже *высший клас*... А вот у НС большинство не осиливают таки реверс списка в том ключе, какой он и ты хотите, а вот с промежуточнм листом осиливают. Интересно, как так выходит?..

Не знаю, чего умеют ваши студенты, в свое время я попал на собеседование в голландскую контору, где предложили за час решить около двух десятков задач, включая реверс списка. Как оказалось, эти задания они дают джуниорами и от джуниора требуется решить не менее 80% задач и реверс это обязательное условие. Для более опытного кандидата 100% это просто повод для дальнейшего разговора. Так что вот.

Да и вообще, по честному, задача по сложности навроде реверса, решается вменяемым студентом за пол-часа от силы.