Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Игoрь, Вы писали:
G>>>Маленький ликбез: G>>>1)Стандартный аллокатор поддерживает связный список блоков памяти, выделение нового и освобождение блока вызывает проход по списку, который имеет алгоритмическое время O(n) от количества блоков. И>>Ты сам в это веришь? Это наивная реализация 80-ых годов. Сейчас используются всякого рода оптимизации, позволяющие минимизировать время поиска и частично отказаться от блокировок кучи. Например, в windows heap создается, если мне память не изменяет, на одну кучу 128 ассоциативных однонаправленных списков, не требующих блокировок. G>Эта наивная реализация во многих местах осталась и по сей день.
Это не аргумент, вообще.
G>>>При постоянных выделениях-освобождениях памяти получются очень большие затраты на эту простую операцию. И>>В С# в целом та же херня. G>Доказательства? Может сначала статью про .NETовский JIT прочитаете. На этом сайте статьи есть.
Еще раз. То, что ты написал в предыдущем посте о преимуществах хипах — ерунда полнейшая. Почему? Да потому что в С++ используется связка стэк + хип. И мелкие часто создаваемые/удаляемые объекты создаются на стэке, а не в хипе. Поэтому все те "преимущества" .net идут лесом. Когда я говорил, что "в C# таже херня", я имел ввиду ситуацию в целом, а не какие-то частные случаи. А именно — работу сборщика мусора и дефрагментатора, который осуществляет перенос объектов в памяти. А это совсем не дешевые операции. Кроме того, если я правильно помню, то при выделении памяти под объект, происходит еще и предварительное обнуление памяти. Далее, все, что ты тут расписал — это касается только мелких объектов. А крупные объекты размещаются в LOH, которая работая скорее по принципу сишной кучи.
G>>>2)При выделении блока идет небольшой оверхед, который зависит от реализации, 16-32 байта кажись. Исследования исходных кодов программ показывают что средний размер объекта составляет от 32 до 128 байт, при такких размерах оверхед является очень значительным. И>>Достаточно в таск менеджере взглянуть на кол-во используемой памяти .net прогой и С++ с эквивалентной функциональностью, чтобы понять, что ты гонишь. G>Покажите две программы на .net и C++ с эквивалнтной функциональностью сложнее HelloWorld, потом посмотрим кто гонит. G>Кроме того цифра в таск менеждере ни о чем не говорит, просто сверните приложение, будете удивлены.
Расскажи как сервисы свернуть... Я поищу что-то из публичных прог.
И>>Кроме того, в С++ принято мелкие объекты создавать на стеке. А если нужно в динамической памяти разместить объект, то есть placement new, который позволяет разместить объект в уже выделенной памяти. G>Ага, это все увеличивает энтропию языка, то есть количество свпособов сделать одно и тоже по-разному.
Глупость.
G>>>3)Выделение памяти таким алгоритмом создет фрагментацию памяти, то есть остаются блоки невыделенной памяти малых размеров. И>>Угу, только проблема фрагментации кучи есть и в .net, кстати, как и мемори лики. G>Доказательства? Опять отправляю вас читать как работает выделение памяти и сборка мусора в .NET.
Лучше сам дуй читать про размещение объектов в LOH и ее фрагментацию. G>Про мемори лики хочу узнать поподробнее, как их получить, потом сравните это с простотой получчения лика в unamanged коде.
В unamanaged коде лик легко обнаружить и избавиться от него, в managed его получить гораздо сложнее, но и найти и избавиться сложнее. мемлики в С++ — страшилки для детей. Я вот сейчас глянул в С++ проект — на 10МБ кода 16 явных вызовов new.
G>>>4)Алгоритм выделения памяти не потокобезопасный, требуется синхронизация. И>>GC тоже не потокобезопасный, и зачастую требует не просто синхронизации, но и приостановки работы потоков. G>Не зачастую, всегда, но GC работает в сотни раз реже, чем выделение-совобождение памяти стандартным аллокатором.
gc и работы гораздо больше выполняет.
G>>>5)В программах на С++ часто делают свои аллокаторы, которые выделяют память для маленькиз объектов чтобы избежать описанно выше оверхеда как по потребляемой памяти, так и по времени этой операции И>>В С++ такое делают крайне-крайне редко. Потому что И>>а) есть стэк; G>Стек заставляет копировать объекты чаще, чем нужно.
просто глупость.
И>>b) есть placement new; G>Теже яйца что и кастомный аллокатор, только сбоку
Нет, кастомный аллокатор — штука серьезная, который пишется месяцами. А это бесплатная штукенция, которая позваоляет оптимизировать критичный код и уделать .net.
И>>c) на мелких объектах свет клином не сошелся — можно и без них обойтись в критичной к скорости части; G>Я тоже говорю что критичные по скорости вещи надо писать на C, а некритичные, на более высокоуровневых языках. C++ в таком раскладе места нет.
На С стоит писать код режима ядра, а вот околосистемные сервисы для С++ — самое оно. Например, у меня есть железка на которой крутится линукс под высокой нагрузкой. Нужно написать какой-то демон для него — однозначно С++.
G>>>Теперь о GC G>>>6)Выделение памяти в .NET происходит очень просто — инкремент указателя. Никаких дополнительных операций не происходитю И>>Ага, аж десять раз. Это как бог на душу положит. Может и GC запуститься с полной остановкой всех потоков. Веселуха... G>Читайте как работает GC, он не может просто так взять и запуститься.
А я и не говорю, что он совсем от фонаря запускается. Но речь же шла о вызове new, так вот далеко не всегда этот вызов будет сведен к одному инкременту.
G>>>7)Оверхед по выделяемой памяти равен 8 байтам на 32-битной платформе (может ошибаюсь немного, лень смотреть) И>>уже писал про мелкие объекты и про то, что общий оверхед памяти для .net программ хорошо больше цэпэпэ. G>А вы вообще ветку читали перед тем как это постить?
читали
G>>>8)Кроме того что выделение памяти выполняется моментально, эта операция еще и потокобезопасна. И>>в c# выделение памяти не более потокобезопасно, чем в с++ G>Полный бред.
взаимно.
G>>>9)такое распределение памяти увелиичивает cache-locality И>>стандартные аллокаторы windows тоже оптимизированы на это дело G>Рад за аллокатор Windows, только зачем он нужен если можно выделять память смещением указателя. Быстрее просто нечего придумать.
Запарил, учи мат часть. Далеко не всегда выделение памяти сводится к простому смещению. И кроме того, в С++ при выделении на стэке для малых объектов это буквально одна инструкция.
G>>>10)GC собирает мусор не тогжа когда захочется, а при нехватке памяти в нулевом поколении И>>по сути это и означает, что когда захочется, особенно если речь идет о более-менее больших системах G>И че? сборка памяти в нулевом поколении работает быстре чем использование алоокатора на списках при выделении-освобождении того же объема памяти.
Того же размера, это какого? Возьмем размер 100 килобайт, быстрее? С учетом того, что такой размер будет выделен не в SOH, а в LOH. А если речь опять про что-то мелкое, так оно и стэке может быть выделено.
G>>>12)Единственный критический недостаток GC заключается в том, что он очень плохо работает когда кончается свободная физическая память, сборка мусора во втором поколении заставляет поднимать все страницы памяти из свопа и это может нереально тормозить. G>>>13)Но даже этот недостаток можно побороть. Можно сборку мусора во втором поколении маскировать под каую-либо длительную операцию (например сохранение или открытие файла), а при расчетах использовать рецепт описанный здесь И>>это в общем-то самообман G>Самообман — думать что C++ всегда быстрее.
Не всегда, на каких-то синтетических тестах может быть быстрее. А-ля выделение/удаление мелких объектов.
И>>PS И>>существенное преимущество GC — не надо следить за уничтожением объектов, что облегчает программирование, позволяет использовать всякие инетересные техники программирования, вроде замыканий. Но за эти удобства мы платим скоростью исполнения и большим расходом памяти. Вот собственно и все. G>Тесты будут? Или вы тоже омновываете свое мнение на просмотре пары говнопрограмм?
Ну я от тебя тестов тоже что-то не видел. А мое мнение базируется на трехлетнем опыте работы с .net. Не сильно много, но достаточно, чтобы делать определенные выводы. А ты, похоже, просто фанатик.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Игoрь, Вы писали:
G>>>3)Выделение памяти таким алгоритмом создет фрагментацию памяти, то есть остаются блоки невыделенной памяти малых размеров. И>>Угу, только проблема фрагментации кучи есть и в .net, кстати, как и мемори лики. CC>Тока мемлики там другие, не такие как в unmanaged. Ну и фрагментация скорее pin-анием вызывается. Обычную кучу GC утаптывать умеет.
Не, я имел ввиду Large Object Heap (LOH), которая работает как сишная куча, и для нее дефрагментация не осуществляется из-за трудоемкости процесса.
Здравствуйте, gandjustas, Вы писали:
G>Когда вы пишите vector<string> то читаемость улучшается. А когда идет vector<sometemple<anothertemplate<param> >, anotherparam> > то читаемости не остается вообще.
Это очень плохой стиль.
NBN>>>>Ну вот если нашу прогу для WM портануть на NET — то она как минимум будет запускатся не секунду, а 15-20 секунд. G>>>Ну если вашу портануть может и будет тормозить, а если нормально написать на .NET не факт что будут лишние тормоза. NBN>>Факт. G>Доказательства будут?
Нет необходимости, это 1. проверялось у нас. 2. отсутствуют решения на шарпе у конкурентов.
NBN>>02-25. Зависит. На тормозявых и неоптимальных языках нельзя писать оптимальные приложения. Практика это подтверждает самым что ни есть великолепным образом. G>Не надо обвинять язык в том что вы не можете написать на нем нетормозявое приложение. Это не его вина.
Написать нетормозявое приложение можно, просто оно будет сильно уступать по функционалу приложениям созданным более подходящими средствами.
NBN>>>>Её будет существенно сложнее ставить, она дольше загружаться и жрат существенно больше ресурсов. G>>>За исключением установки .NET CF (один раз) проблем нет. NBN>>1. Один раз для каждого нета. G>Если у вас одно приложение, то как оно вас волнует?
У нас несколько десятков приложений.
NBN>>2. Это минимум в _2_ раза усложняет процесс инсталляции, это просто недопустимо, даже для писюка. G>Какой ужас, как же люди живут...
Пользуются удобным и быстрым нативом.
G>>>Ну от него никуда не деться. NBN>>Ага, он делает разработку на С++ значительно проще, чем разработка на шарпе и лучший результат в конечном результате. G>Он ниче проще не делает, во многих случаях даже делает хуже. Переписывание всего — огромный риск, на который далеко не все идут.
Не беспокойся — с нуля на шарпе тоже не пишут Точнее пишут! Ещё как пишут, ведутся на рекламу. Потом либо переписывают на С++, либо пропадают
NBN>>Тут ведь как — чуть слажал и тебя конкуренты съели G>Только от языка это ну вообще никак не зависит.
Ну ты голову из песка вытащи и пойми, что не все языки вместе со своими енвайраментами неодинаково полезны.
G>не смешите, вы уже многократоно показали свое невладение ничем кроме С++, да еще и бравируете этим.
Я знаю возможности шарпа и хорошо представляю как он устроен внутри.
G>>>"Думаю" — слабый аргумент. NBN>>Достаточный. Это называется экспертная оценка G>Какой из вас эксперт, если вы ниче дальше С++ и шароварок толком не видели.
Переход на личности означает то что аргументы у тебя кончились, а следовательно ты слил.
Здравствуйте, gandjustas, Вы писали:
NBN>>>>Думаю, что на шарпе было бы невозможно обеспечить даже близкое качество) G>>>"Думаю" — слабый аргумент. NBN>>Достаточный. Это называется экспертная оценка
G>Ваши высказывания отлично иллюстрирует следующая картинка: G>http://i41.tinypic.com/30vemo1.jpg G>ЗЫ. Мопед не мой, привет QBitу
У меня тут пару вопросов возникло и дополнений...
И>Еще раз. То, что ты написал в предыдущем посте о преимуществах хипах — ерунда полнейшая. Почему? Да потому что в С++ используется связка стэк + хип. И мелкие часто создаваемые/удаляемые объекты создаются на стэке, а не в хипе. Поэтому все те "преимущества" .net идут лесом. Когда я говорил, что "в C# таже херня", я имел ввиду ситуацию в целом, а не какие-то частные случаи. А именно — работу сборщика мусора и дефрагментатора, который осуществляет перенос объектов в памяти. А это совсем не дешевые операции. Кроме того, если я правильно помню, то при выделении памяти под объект, происходит еще и предварительное обнуление памяти. Далее, все, что ты тут расписал — это касается только мелких объектов. А крупные объекты размещаются в LOH, которая работая скорее по принципу сишной кучи.
В .Net ведь стек тоже вполне себе используется. И если объект выгоднее размещать в стеке, то можно его просто сделать структурой. Единственное, можно попенять на то, что уже готовые конструкции, такие как, например массив, фиг запихнешь в стек. Т.е. я к чему. Связку "стек + хип" вполне можно и в C# юзать, если почти все эти классы сам пишешь. И, чесс говоря, есть ощущение, что это преимущество C++ высосано из пальца.
И>В unamanaged коде лик легко обнаружить и избавиться от него, в managed его получить гораздо сложнее, но и найти и избавиться сложнее. мемлики в С++ — страшилки для детей. Я вот сейчас глянул в С++ проект — на 10МБ кода 16 явных вызовов new.
Если бы в unmanaged всё было так легко, про GC ничего бы не говорили. Теоретически в unmanaged утечку можно вообще не обнаружить. В managed такие вещи решаются на ура при помощи профайлеров.
G>>>>7)Оверхед по выделяемой памяти равен 8 байтам на 32-битной платформе (может ошибаюсь немного, лень смотреть) И>>>уже писал про мелкие объекты и про то, что общий оверхед памяти для .net программ хорошо больше цэпэпэ.
А вот это можно неплохо подтвердить на примере WPF. Центральным классом там является DependencyObject со свойствами зависимостей. Так вот этот самый DependencyObject хранит значения всех этих свойств, не являющихся конструкциями языка, в виде object. Поэтому получается, что если тип свойства — структура, имеем боксинг. А это в любом случае, да — лишний расход памяти.
Здравствуйте, NikeByNike, Вы писали:
NBN>Не беспокойся — с нуля на шарпе тоже не пишут Точнее пишут! Ещё как пишут, ведутся на рекламу.
Так это получается, что все в форумах NET и NET GUI просто дебилы какие-то, выбирающие инструмент по рекламкам.
Считай это как призыв не юзать подобные аргументы. Все же в деле заняты, а не в бирюльках.
Здравствуйте, gandjustas, Вы писали:
H>>Давай ты последуешь своему совету и подумаешь, что такое граф и, как с помощью битового флага (а точнее речь идет битовом массиве, как я понимаю) можно определить находжение объекта в куче для последующих манипуляций с оным. G>http://www.rsdn.ru/article/dotnet/GC.xml
Ты этой ссылкой только подтверждаешь мой тезис о том, что инфраструктура управления памятью в .Net более требовательна к оной
Из заключения:
При наличии большого объема памяти .NET-приложения действительно не стесняются в запросах. Но на самом деле это связано с тем, что алгоритмы GC работают более эффективно при использовании больших объемов памяти. Если памяти в системе начинает не хватать, GC переходит в более экономный режим работы.
Ну и про отрицательное влияние на перформанс тоже сказано... не смотря на все оптимизации.
H>>>>Ты же сам про процессорный кэш упоминал... Забыл? G>>>Не забыл — сборка муроса достаточно редкий процесс и на время его работы программа останавливается. H>>Ты посмотри, как этот редкий процесс накручивает счетчик, когда ты мышкой водишь над кнопками на тулбаре. G>Накручивает до определенной степени, потом переставет.
У меня не получилось дождаться, пока перестанет. Не перестанет он.
H>>К тому же не забывай, я давал пример, когда на один вызод метода по XML-RPC происходит 3 сборки мусора. Не веришь мне, проверь сам. G>Не надо в пример приводить какую-то левую либу.
Да какой бы я пример не привел, ты назовешь его левым или говнософтом. Ладно, еще пример из говнософта. Запускаем Paint.NET и открываем в нем картинку (я открыл 1600x1200). Выделяем всю картинку Ctrl+A. Смотрим на счетчики GC и видим, что в мирно крутящем пунктир выделения Paint.NET'е, счетчик GC тикает раз-два-три в секунду.
H>>Вообще-то тут речь идет об освобождении ресурсов. У стандартного аллокатора есть информация о размере освобождаемого блока, и нет нужды мотаться за ней в мету. G>"мотаться" — громко сказано, это пара ассемблерных команд. Стандартному аллокатору чтобы поместить свободный блок в список приходится мотаться.
Стандартный подчиняется ручному управлению, и на работу влияния не оказывает. В отличие от GC решившего вдруг марафет навести.
H>>Так Рихтер и говорит, что управляемая куча это есть потеря перформанса. Впрочем, я уже понял, что твою слепую веру ничто не способно поколебать. G>Слепая вера и невежество у тебя. G>http://www.rsdn.ru/forum/Default.aspx?mid=3164491
Во-первых это синтетика, не имеющая ничего общего с реальным миром. Во-вторых это не правильная синтетика.
H>>>>Это реальный показатель: H>>>>
Private Bytes represents the amount of private virtual memory a process has allocated and is the value that will rise of a process exhibiting a memory leak bug.
G>>>Такой же эфимерный показательнь для GC. H>> При чем тут GC? Это показатель реально используемого/выделенного (не зарезервированного) объема, хоть с GC, хоть без GC G>Что значит "реально используемого", ты ведь понимаешь что это далеко не тоже самое что "выделенного", GC нет смысла релизить память первых двух поколений, даже если она не используется. Метаданные в памяти также используются далеко не всегда, несмотря на то что память под них выделлена. G>Неиспользуемые страницы могут долго находится в памяти, пока память не понадобится другим приложениям.
Мне, как пользователю, не интересны резоны GC. Я вижу результат -- чрезмерное потребление. Делаем простой эксперимент. Запускаем Paint.NET, который откушал сразу 35Mb (судя по твоим словам, большая часть этой цифры -- резерв, который будет возвращен в систему по первому требованию). Теперь начинаем запускать много тяжелого софта: две Delphi IDE, Open Office Writer, Abode Reader, Opera (она у меня жрет в районе 160Mb, из-за размера почтовой базы), VirtualBox. Все система ушла в своп. Смотрим на потребление Paint.NET... оно снизилось ровно на 300Кб. Выводы?
Здравствуйте, hattab, Вы писали:
H>Мне, как пользователю, не интересны резоны GC. Я вижу результат -- чрезмерное потребление. Делаем простой эксперимент. Запускаем Paint.NET, который откушал сразу 35Mb (судя по твоим словам, большая часть этой цифры -- резерв, который будет возвращен в систему по первому требованию). Теперь начинаем запускать много тяжелого софта: две Delphi IDE, Open Office Writer, Abode Reader, Opera (она у меня жрет в районе 160Mb, из-за размера почтовой базы), VirtualBox. Все система ушла в своп. Смотрим на потребление Paint.NET... оно снизилось ровно на 300Кб. Выводы?
Блин, вот что правда 100 или 200 мегов оперативы сейчас кому-то принципиально? Я когда приводил скриншот с Creative Docs, там еще Оракл светился. Жрал 250 мегов, но при этом он у меня вообще никак не юзается. Я его однажы установил и всё. И вот оно тяпает 200 мегов при запуске и оно нативное. Но чесс говоря, что есть оно, что нет, мне фиолетово. На компе 1 Гиг оперативы. Ххах. А было бы оно managed, наверняка бы и эти 200 мег припомнили
Здравствуйте, MxKazan, Вы писали:
MK>В .Net ведь стек тоже вполне себе используется. И если объект выгоднее размещать в стеке, то можно его просто сделать структурой. Единственное, можно попенять на то, что уже готовые конструкции, такие как, например массив, фиг запихнешь в стек. Т.е. я к чему. Связку "стек + хип" вполне можно и в C# юзать, если почти все эти классы сам пишешь. И, чесс говоря, есть ощущение, что это преимущество C++ высосано из пальца.
Я тоже сильной применимости не вижу, но вещь определенно не плохая.
И>>В unamanaged коде лик легко обнаружить и избавиться от него, в managed его получить гораздо сложнее, но и найти и избавиться сложнее. мемлики в С++ — страшилки для детей. Я вот сейчас глянул в С++ проект — на 10МБ кода 16 явных вызовов new. MK>Если бы в unmanaged всё было так легко, про GC ничего бы не говорили. Теоретически в unmanaged утечку можно вообще не обнаружить. В managed такие вещи решаются на ура при помощи профайлеров.
Нативный FastMM умеет рапортовать об утечках (с адресами, с типами). Плюс есть различные тулы для контроля.
Здравствуйте, CreatorCray, Вы писали:
H>>Новая работает CC>Надо будет как нить ее доработать. CC>К примеру она не "видит" аллокации из динамически подгружаемых DLL, только из статики. Не будет работать с упакованными/защищенными EXE и т.п. Как нить сделать чтобы можно было отловить откуда была выделена/освобождена память (StackWalk), правда глядя на объем данных, получаемый с простой программки (~200Mb) становится понятно что stackwalk на каждый alloc/free — это будет черезчур. CC>Плюс почему то к моменту выгрузки DLL не на все аллокации приходит освобождение, причем часто строго на определенном блоке заканчивается работа.
Ага, заметил некоторые траблы с использованием. Но вообще, интересная софтинка
Здравствуйте, MxKazan, Вы писали:
MK>Блин, вот что правда 100 или 200 мегов оперативы сейчас кому-то принципиально? Я когда приводил скриншот с Creative Docs, там еще Оракл светился. Жрал 250 мегов, но при этом он у меня вообще никак не юзается. Я его однажы установил и всё. И вот оно тяпает 200 мегов при запуске и оно нативное. Но чесс говоря, что есть оно, что нет, мне фиолетово. На компе 1 Гиг оперативы. Ххах. А было бы оно managed, наверняка бы и эти 200 мег припомнили
Во времена DOS'а, когда только начали появляться графические и псевдографические интерфейсы, а "мыши" были большой редкостью, в одном журнале прочитал интервью с каким-то разработчиком. Он отвечая на вопрос журналиста об использовании "мышки" в качестве единственного средства управления, ответил: "Если вы делаете "мышь" единственным средством управления, будьте готовы обеспечить им ваших пользователей". Вот, когда мне говорят о дешевых гигабайтах, я всегда эту фразу вспоминаю Не нужно забывать, что техника бывает очень разной, и часто бывает так, что купив ноутбук с распаянными на плате 512 метрами, заапгрейдить его можно только выкинув и купив новый.
Здравствуйте, Игoрь, Вы писали:
И>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, Игoрь, Вы писали:
G>>>>Маленький ликбез: G>>>>1)Стандартный аллокатор поддерживает связный список блоков памяти, выделение нового и освобождение блока вызывает проход по списку, который имеет алгоритмическое время O(n) от количества блоков. И>>>Ты сам в это веришь? Это наивная реализация 80-ых годов. Сейчас используются всякого рода оптимизации, позволяющие минимизировать время поиска и частично отказаться от блокировок кучи. Например, в windows heap создается, если мне память не изменяет, на одну кучу 128 ассоциативных однонаправленных списков, не требующих блокировок. G>>Эта наивная реализация во многих местах осталась и по сей день. И>Это не аргумент, вообще.
Ну тогда все ваши аргументы по поводу GC вообще не аргументы.
G>>>>При постоянных выделениях-освобождениях памяти получются очень большие затраты на эту простую операцию. И>>>В С# в целом та же херня. G>>Доказательства? Может сначала статью про .NETовский JIT прочитаете. На этом сайте статьи есть. И>Еще раз. То, что ты написал в предыдущем посте о преимуществах хипах — ерунда полнейшая. Почему? Да потому что в С++ используется связка стэк + хип. И мелкие часто создаваемые/удаляемые объекты создаются на стэке, а не в хипе. Поэтому все те "преимущества" .net идут лесом. Когда я говорил, что "в C# таже херня", я имел ввиду ситуацию в целом, а не какие-то частные случаи.
Ну статистику покажите чтоли, а то сильно голословное утверждение.
И>А именно — работу сборщика мусора и дефрагментатора, который осуществляет перенос объектов в памяти. А это совсем не дешевые операции.
Но они дешевле работы стандартного аллокатора. Это факт подтверждаемый тестами.
И>Кроме того, если я правильно помню, то при выделении памяти под объект, происходит еще и предварительное обнуление памяти.
О, да... это супер дорогая операция.
И>Далее, все, что ты тут расписал — это касается только мелких объектов. А крупные объекты размещаются в LOH, которая работая скорее по принципу сишной кучи.
Крупные объекты — это от 84 кб, это очень много. Статистка говорит что большенство объектов в программах гораздо меньше.
G>>>>2)При выделении блока идет небольшой оверхед, который зависит от реализации, 16-32 байта кажись. Исследования исходных кодов программ показывают что средний размер объекта составляет от 32 до 128 байт, при такких размерах оверхед является очень значительным. И>>>Достаточно в таск менеджере взглянуть на кол-во используемой памяти .net прогой и С++ с эквивалентной функциональностью, чтобы понять, что ты гонишь. G>>Покажите две программы на .net и C++ с эквивалнтной функциональностью сложнее HelloWorld, потом посмотрим кто гонит. G>>Кроме того цифра в таск менеждере ни о чем не говорит, просто сверните приложение, будете удивлены. И>Расскажи как сервисы свернуть... Я поищу что-то из публичных прог.
Сервис не отменяет факта, что цифра в таск менеджере не поеказывает реального потребления памяти.
И>>>Кроме того, в С++ принято мелкие объекты создавать на стеке. А если нужно в динамической памяти разместить объект, то есть placement new, который позволяет разместить объект в уже выделенной памяти. G>>Ага, это все увеличивает энтропию языка, то есть количество свпособов сделать одно и тоже по-разному. И>Глупость.
Факт. Есть указатели и есть ссылки. Различия для них чисто синтаксические.
G>>>>3)Выделение памяти таким алгоритмом создет фрагментацию памяти, то есть остаются блоки невыделенной памяти малых размеров. И>>>Угу, только проблема фрагментации кучи есть и в .net, кстати, как и мемори лики. G>>Доказательства? Опять отправляю вас читать как работает выделение памяти и сборка мусора в .NET. И>Лучше сам дуй читать про размещение объектов в LOH и ее фрагментацию.
Как часто объекты в LOH попадают?
G>>Про мемори лики хочу узнать поподробнее, как их получить, потом сравните это с простотой получчения лика в unamanged коде. И>В unamanaged коде лик легко обнаружить и избавиться от него, в managed его получить гораздо сложнее, но и найти и избавиться сложнее. мемлики в С++ — страшилки для детей.
Ты сам понял какой бред написал?
С каких пор в unmanaged стало легче лики находить? В больших проектах только smart pointerы и RAII спасают, ручками все отследить нереально.
В managed ликов как таковых нету, проблемы чаще всего связаны с незадиспозенными объектами. Все ошибки такого рода отлавливают автоматические утилиты анализа кода.
И>Я вот сейчас глянул в С++ проект — на 10МБ кода 16 явных вызовов new.
И 6487 malloc?
G>>>>4)Алгоритм выделения памяти не потокобезопасный, требуется синхронизация. И>>>GC тоже не потокобезопасный, и зачастую требует не просто синхронизации, но и приостановки работы потоков. G>>Не зачастую, всегда, но GC работает в сотни раз реже, чем выделение-совобождение памяти стандартным аллокатором. И>gc и работы гораздо больше выполняет.
Но в среднем оказывается быстрее стандартного аллокатора.
G>>>>5)В программах на С++ часто делают свои аллокаторы, которые выделяют память для маленькиз объектов чтобы избежать описанно выше оверхеда как по потребляемой памяти, так и по времени этой операции И>>>В С++ такое делают крайне-крайне редко. Потому что И>>>а) есть стэк; G>>Стек заставляет копировать объекты чаще, чем нужно. И>просто глупость.
Напишите код со сложением векторов на стеке.
И>>>b) есть placement new; G>>Теже яйца что и кастомный аллокатор, только сбоку И>Нет, кастомный аллокатор — штука серьезная, который пишется месяцами. А это бесплатная штукенция, которая позваоляет оптимизировать критичный код и уделать .net.
Только деструктор не вызывается, значит применима такая штукенция далеко не всегда.
Да и откуда память под placement new возьмется? Не из воздуха же, а будет выделена тем же стандартным аллокатором.
И>>>c) на мелких объектах свет клином не сошелся — можно и без них обойтись в критичной к скорости части; G>>Я тоже говорю что критичные по скорости вещи надо писать на C, а некритичные, на более высокоуровневых языках. C++ в таком раскладе места нет. И>На С стоит писать код режима ядра, а вот околосистемные сервисы для С++ — самое оно. Например, у меня есть железка на которой крутится линукс под высокой нагрузкой. Нужно написать какой-то демон для него — однозначно С++.
Ну и флаг вам в руки.
G>>>>9)такое распределение памяти увелиичивает cache-locality И>>>стандартные аллокаторы windows тоже оптимизированы на это дело G>>Рад за аллокатор Windows, только зачем он нужен если можно выделять память смещением указателя. Быстрее просто нечего придумать. И>Запарил, учи мат часть. Далеко не всегда выделение памяти сводится к простому смещению. И кроме того, в С++ при выделении на стэке для малых объектов это буквально одна инструкция.
Я открою маленький секрет. В .net тоже есть стек и есть структуры, которые на стеке размещаются.
G>>>>10)GC собирает мусор не тогжа когда захочется, а при нехватке памяти в нулевом поколении И>>>по сути это и означает, что когда захочется, особенно если речь идет о более-менее больших системах G>>И че? сборка памяти в нулевом поколении работает быстре чем использование алоокатора на списках при выделении-освобождении того же объема памяти. И>Того же размера, это какого? Возьмем размер 100 килобайт, быстрее? С учетом того, что такой размер будет выделен не в SOH, а в LOH. А если речь опять про что-то мелкое, так оно и стэке может быть выделено.
Твое "может быть выделено на стеке" имеет мало отношения к реальности. Статистические данные, на который опирается .NETовский GC собраны были до его создания. Угадай на чем было большенство проанализированных программ написано?
G>>Самообман — думать что C++ всегда быстрее. И>Не всегда, на каких-то синтетических тестах может быть быстрее. А-ля выделение/удаление мелких объектов.
А погуглить перформанс тесты вместо написания откровенного бреда?
Причем большентсво тестов написаны с применением .NET 1.1, с тех пор перформанс неоднократно улучшали.
И>Ну я от тебя тестов тоже что-то не видел. А мое мнение базируется на трехлетнем опыте работы с .net. Не сильно много, но достаточно, чтобы делать определенные выводы.
За 3 года могли бы и разобраться как сделать на .NET программу, которая не тормозит. Это вообще говоря не очень сложно делается.
И>А ты, похоже, просто фанатик.
Кто бы говорил...
Здравствуйте, NikeByNike, Вы писали:
NBN>Здравствуйте, gandjustas, Вы писали:
G>>Когда вы пишите vector<string> то читаемость улучшается. А когда идет vector<sometemple<anothertemplate<param> >, anotherparam> > то читаемости не остается вообще. NBN>Это очень плохой стиль.
Ага, и он достаточно часто встречается при использовании чего-то типа буста.
NBN>>>>>Ну вот если нашу прогу для WM портануть на NET — то она как минимум будет запускатся не секунду, а 15-20 секунд. G>>>>Ну если вашу портануть может и будет тормозить, а если нормально написать на .NET не факт что будут лишние тормоза. NBN>>>Факт. G>>Доказательства будут? NBN>Нет необходимости, это 1. проверялось у нас. 2. отсутствуют решения на шарпе у конкурентов.
То есть вы не смогли написать нетормозящую программу на .NET, а потом объявляете фактом что все программы под .NET CF тормозят?
NBN>>>02-25. Зависит. На тормозявых и неоптимальных языках нельзя писать оптимальные приложения. Практика это подтверждает самым что ни есть великолепным образом. G>>Не надо обвинять язык в том что вы не можете написать на нем нетормозявое приложение. Это не его вина. NBN>Написать нетормозявое приложение можно, просто оно будет сильно уступать по функционалу приложениям созданным более подходящими средствами.
Какие-то абстрактные размышления.
NBN>>>>>Её будет существенно сложнее ставить, она дольше загружаться и жрат существенно больше ресурсов. G>>>>За исключением установки .NET CF (один раз) проблем нет. NBN>>>1. Один раз для каждого нета. G>>Если у вас одно приложение, то как оно вас волнует? NBN>У нас несколько десятков приложений.
И все требуют разные версии .NET CF?
NBN>>>2. Это минимум в _2_ раза усложняет процесс инсталляции, это просто недопустимо, даже для писюка. G>>Какой ужас, как же люди живут... NBN>Пользуются удобным и быстрым нативом.
Да не, я про тех кто .NET юзает. Некоторые об этом даже не подозревают.
G>>>>Ну от него никуда не деться. NBN>>>Ага, он делает разработку на С++ значительно проще, чем разработка на шарпе и лучший результат в конечном результате. G>>Он ниче проще не делает, во многих случаях даже делает хуже. Переписывание всего — огромный риск, на который далеко не все идут. NBN>Не беспокойся — с нуля на шарпе тоже не пишут
А с чего еще писать? Разве есть сейчас обширный codebase на шарпе для десктопов\КПК ?
NBN>Точнее пишут! Ещё как пишут, ведутся на рекламу. Потом либо переписывают на С++, либо пропадают
Ну если с шарпа переписывают на С++, то точно пропадают.
NBN>>>Тут ведь как — чуть слажал и тебя конкуренты съели G>>Только от языка это ну вообще никак не зависит. NBN>Ну ты голову из песка вытащи и пойми, что не все языки вместе со своими енвайраментами неодинаково полезны.
А я разве не так говорю?
Там где нужен перформанс — там C или асм. Тем где скорость не очень важна C#, F#. Скрипты можно на python\ruby писать, есть рантаймы для .NET, Java, и родные интерпретаторы.
G>>не смешите, вы уже многократоно показали свое невладение ничем кроме С++, да еще и бравируете этим. NBN>Я знаю возможности шарпа и хорошо представляю как он устроен внутри.
Вы уже несколько раз показали поверхность своих знаний.
G>>>>"Думаю" — слабый аргумент. NBN>>>Достаточный. Это называется экспертная оценка G>>Какой из вас эксперт, если вы ниче дальше С++ и шароварок толком не видели. NBN>Переход на личности означает то что аргументы у тебя кончились, а следовательно ты слил.
Называние себя экспертом — переход на личности.
Здравствуйте, hattab, Вы писали:
H>Во времена DOS'а, когда только начали появляться графические и псевдографические интерфейсы, а "мыши" были большой редкостью, в одном журнале прочитал интервью с каким-то разработчиком. Он отвечая на вопрос журналиста об использовании "мышки" в качестве единственного средства управления, ответил: "Если вы делаете "мышь" единственным средством управления, будьте готовы обеспечить им ваших пользователей". Вот, когда мне говорят о дешевых гигабайтах, я всегда эту фразу вспоминаю Не нужно забывать, что техника бывает очень разной, и часто бывает так, что купив ноутбук с распаянными на плате 512 метрами, заапгрейдить его можно только выкинув и купив новый.
Я, конечно, согласен, но только в определенной степени. Речь все-таки не о гигабайтах и 512 мегов сейчас уже редкость. Managed проги хоть и требуют памяти больше нативных, но все же не по 200 мегов на каждую фенечку. Тот же Creative Docs не отобрал у меня больше 120 Мб и при открытии всех сэмплов в поставке (я их покрутил/повертел/поперетаскивал).
Здравствуйте, gandjustas, Вы писали:
G>Статистика показывает что плотность ошибок на строку кода от языка не зависит. При этом для реализации како-то функционала на С++ требуется написть когда больше (иногда гораздо больше), поэтому багов на единицу функционала для С++ получается больше.
Что за статистика такая? Я вот, например, не верю, что число ошибок на строчку BF и MODULA 2 будет одинаковым...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
H>>>Давай ты последуешь своему совету и подумаешь, что такое граф и, как с помощью битового флага (а точнее речь идет битовом массиве, как я понимаю) можно определить находжение объекта в куче для последующих манипуляций с оным. G>>http://www.rsdn.ru/article/dotnet/GC.xml
H>Ты этой ссылкой только подтверждаешь мой тезис о том, что инфраструктура управления памятью в .Net более требовательна к оной
Офигеть, дайте две, а причем тут перформанс?
H>Из заключения: H>
При наличии большого объема памяти .NET-приложения действительно не стесняются в запросах. Но на самом деле это связано с тем, что алгоритмы GC работают более эффективно при использовании больших объемов памяти. Если памяти в системе начинает не хватать, GC переходит в более экономный режим работы.
Ключевое выделил.
H>Ну и про отрицательное влияние на перформанс тоже сказано... не смотря на все оптимизации.
Ну а где же цитата про перформанс?
H>>>>>Ты же сам про процессорный кэш упоминал... Забыл? G>>>>Не забыл — сборка муроса достаточно редкий процесс и на время его работы программа останавливается. H>>>Ты посмотри, как этот редкий процесс накручивает счетчик, когда ты мышкой водишь над кнопками на тулбаре. G>>Накручивает до определенной степени, потом переставет. H>У меня не получилось дождаться, пока перестанет. Не перестанет он.
У тебя определенно плохая карма. Прмерно 10 мб от первоначального объема кушат при двигании мышкой туда-сюда.
Это обсасывали еще при появлении персого дотнета.
H>>>К тому же не забывай, я давал пример, когда на один вызод метода по XML-RPC происходит 3 сборки мусора. Не веришь мне, проверь сам. G>>Не надо в пример приводить какую-то левую либу.
H>Да какой бы я пример не привел, ты назовешь его левым или говнософтом. Ладно, еще пример из говнософта. Запускаем Paint.NET и открываем в нем картинку (я открыл 1600x1200). Выделяем всю картинку Ctrl+A. Смотрим на счетчики GC и видим, что в мирно крутящем пунктир выделения Paint.NET'е, счетчик GC тикает раз-два-три в секунду.
И че, вам жалко? Че за фобия сборки мусора?
При этом отъедается 20% CPU на "бегающих тараканчиков", которые кстати бегают честно по кругу и очень плавно, в отличие от многих других программ.
H>>>Вообще-то тут речь идет об освобождении ресурсов. У стандартного аллокатора есть информация о размере освобождаемого блока, и нет нужды мотаться за ней в мету. G>>"мотаться" — громко сказано, это пара ассемблерных команд. Стандартному аллокатору чтобы поместить свободный блок в список приходится мотаться. H>Стандартный подчиняется ручному управлению, и на работу влияния не оказывает. В отличие от GC решившего вдруг марафет навести.
Надо бы ло внимательнее статью читать, "вдруг" не бывает. тем более это тоже контролируется.
H>>>Так Рихтер и говорит, что управляемая куча это есть потеря перформанса. Впрочем, я уже понял, что твою слепую веру ничто не способно поколебать. G>>Слепая вера и невежество у тебя. G>>http://www.rsdn.ru/forum/Default.aspx?mid=3164491
H>Во-первых это синтетика, не имеющая ничего общего с реальным миром. Во-вторых это не правильная синтетика.
Да, синтетика, которая как раз наглядно показывает что аллокатор в делфях медленее GC.
H>Мне, как пользователю, не интересны резоны GC. Я вижу результат -- чрезмерное потребление.
Тебе как пользователю разница от цифирки в таскманагере есть?
Ты даже не можешь сопоставить быстродействие с этой цифиркой никак.
H>Делаем простой эксперимент. Запускаем Paint.NET, который откушал сразу 35Mb (судя по твоим словам, большая часть этой цифры -- резерв, который будет возвращен в систему по первому требованию). Теперь начинаем запускать много тяжелого софта: две Delphi IDE, Open Office Writer, Abode Reader, Opera (она у меня жрет в районе 160Mb, из-за размера почтовой базы), VirtualBox. Все система ушла в своп. Смотрим на потребление Paint.NET... оно снизилось ровно на 300Кб. Выводы?
Вывод один — тебе срочно надо курить про workset. до этого больше тут ничего не пиши.
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, gandjustas, Вы писали:
G>>Статистика показывает что плотность ошибок на строку кода от языка не зависит. При этом для реализации како-то функционала на С++ требуется написть когда больше (иногда гораздо больше), поэтому багов на единицу функционала для С++ получается больше.
E>Что за статистика такая? Я вот, например, не верю, что число ошибок на строчку BF и MODULA 2 будет одинаковым...
Когда на BF хотябы один большой проект сделают тогда поговорим.
Эта статистика собирается для крупных проектов. Мелочи могут давать перекосы в разные стороны в зависимости от подходящих библиотек.
Здравствуйте, MxKazan, Вы писали:
H>>Во времена DOS'а, когда только начали появляться графические и псевдографические интерфейсы, а "мыши" были большой редкостью, в одном журнале прочитал интервью с каким-то разработчиком. Он отвечая на вопрос журналиста об использовании "мышки" в качестве единственного средства управления, ответил: "Если вы делаете "мышь" единственным средством управления, будьте готовы обеспечить им ваших пользователей". Вот, когда мне говорят о дешевых гигабайтах, я всегда эту фразу вспоминаю Не нужно забывать, что техника бывает очень разной, и часто бывает так, что купив ноутбук с распаянными на плате 512 метрами, заапгрейдить его можно только выкинув и купив новый. MK>Я, конечно, согласен, но только в определенной степени. Речь все-таки не о гигабайтах и 512 мегов сейчас уже редкость.
Полгода назад у Ровера вышла очень удачная машинка класса UMPC, там распаяно 768 и установлена Виста. В свое время Compaq выпустил очень удачный планшетник TC-1100 (HP'шники, суки, убили эту линейку) с Windows XP Tablet PC с которым сразу обнаружились проблемы с "заиканием" стандартной распознавалки вполть до отказа пользователей от ее использования (массово ставили Квартовскую или Парагоновскую). Причина проста -- стандартная распознавалка Tablet PC является/являлась .Net приложением (видимо GC и давал эффект заикания. На хоботе исследование вопроса проводили, но я детали не помню).
MK>Managed проги хоть и требуют памяти больше нативных, но все же не по 200 мегов на каждую фенечку. Тот же Creative Docs не отобрал у меня больше 120 Мб и при открытии всех сэмплов в поставке (я их покрутил/повертел/поперетаскивал).
Тут ведь какое дело, если софтина работает одна, так и не жалко. Но когда их много, а ресурсы ограничены... Просто выберет человек продукт конкурента и всех делов
Здравствуйте, MxKazan, Вы писали:
MK>Вот тут я тебя полностью понимаю. И я тоже против огульного охаивания .Net и его приравнивания к VB.
А зря ты так про VB. На VB целая индустрия держалась. Софта который нужен "уже вчера", и "послезавтра точно устареет"...
Кстати, сейчас эту нужную и важную нишу занял .Net...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, hattab, Вы писали:
H>Полгода назад у Ровера вышла очень удачная машинка класса UMPC, там распаяно 768 и установлена Виста. В свое время Compaq выпустил очень удачный планшетник TC-1100 (HP'шники, суки, убили эту линейку) с Windows XP Tablet PC с которым сразу обнаружились проблемы с "заиканием" стандартной распознавалки вполть до отказа пользователей от ее использования (массово ставили Квартовскую или Парагоновскую). Причина проста -- стандартная распознавалка Tablet PC является/являлась .Net приложением (видимо GC и давал эффект заикания. На хоботе исследование вопроса проводили, но я детали не помню).
Я честно не знаю, как некоторым удается писать такие дерьмовые проги на .Net. За 3 года я ни разу не сталкивался с этими чудесами подвисаний GC. Допускаю, что они могут быть в высоконагруженных системах, но вот я не сталкивался и всё. Возможно потому, что у меня не развита GC-фобия.
MK>>Managed проги хоть и требуют памяти больше нативных, но все же не по 200 мегов на каждую фенечку. Тот же Creative Docs не отобрал у меня больше 120 Мб и при открытии всех сэмплов в поставке (я их покрутил/повертел/поперетаскивал). H>Тут ведь какое дело, если софтина работает одна, так и не жалко. Но когда их много, а ресурсы ограничены... Просто выберет человек продукт конкурента и всех делов
В общем это бесконечный спор...
Точнее пишут! Ещё как пишут, ведутся на рекламу. Потом либо переписывают на С++, либо пропадают 
