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

G>>Ну да. Алгоритмы сборки мусора тоже много кому известны, код для них написан очень давно, да и еще очень много вещей известно давно и код написан.
CC>Каждый алгоритм выделения/освобождения памяти имеет свои преимущества и недостатки. И алгоритмы GC в том числе. В С++ можно выбрать оптимальный алгоритм под каждую задачу, если требуется. Или же можно использовать придуманный еще в прошлой ревизии стандарта метод аллокации, который старается беречь память. В управляемой среде будешь жрать что дают.
а)Далеко не все способны написать написать аллокатор или сборщик мусора
б)далеко не все могут нормально использовать аллокатор или сборщик мусора в С++
в)В С++ сборка мусора мне может происходить также, как в .NET
г)программисту на С# не надо знать все вышеперчисленное чтобы писать достаточно эффективные программы

G>>И все это можно использовать не задумываясь в управляемых средах, типа Java или .NET.
CC>Можешь ли ты в управляемый средах легко сменить аллокатор?
Нет, а зачем? Аккокатор в .NET выделяет память со скоростью O(1), куда еще быстрее?

G>>А можно на форумах рассказывать как все "легко" делается в C++.
CC>Не поверишь, оно и на самом деле легко.
Я писал аллокатор на C++, оно совсем не легко.

CC>>>Не надоело еще воздух сотрясать?
G>>Не-а. Можем еще вспомнить такие акронимы как ORM, IoC и другие
CC>Мы все еще говорим о произодительности написанной программы?
Мы говорим о преимуществаих и недостатках. Производительность тоже одно из преимуществ.
Но если рассматривать только производительность, то лучше писать на ассемблере.

CC>ЗЫ: Я вообще не понимаю, почему managed апологеты стараются увести ветку с обсуждения разницы в аллокаторах по умолчанию в С++ и .NET
Потому что программирование заключается не только в прикручивании аллокаторов.

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

G>а)Далеко не все способны написать написать аллокатор или сборщик мусора
Сборщик еще понятно — там не все однозначно в случае С++. Но не осилить простой аллокатор — наводит на размышления.

G>б)далеко не все могут нормально использовать аллокатор или сборщик мусора в С++
Тоже нифига не радует. Отупение налицо

G>в)В С++ сборка мусора не может происходить также, как в .NET
Разумеется. В .NET для GC предусмотрена поддержка компилятором — там GC работать проще.

G>г)программисту на С# не надо знать все вышеперчисленное чтобы писать достаточно эффективные программы
Ему надо знать другие вещи. GC не серебряная пуля, и если головой не думать то и им тоже можно себе по ногам популять. Только выразится это не в падении проги/порче данных, которое QA не пропустит, а к пожиранию памяти.

CC>>Можешь ли ты в управляемый средах легко сменить аллокатор?
G>Нет, а зачем? Аккокатор в .NET выделяет память со скоростью O(1), куда еще быстрее?
Кроме быстрее есть еще и потребление памяти и детерминизм.
С какой скоростью оно кстати память освобождает? Именно освобождает — отдает системе. Мы же не в однозадачной ОС работаем — рядом еще пучок таких же процессов крутится.
А в условиях большого кол-ва выделений/освобождений в единицу времени? Вот такой вот алгоритм написал аспирант Вася — можно же в самом вложенном цикле каждый раз звать new а потом поинтер занулять — не ругается компилер, нормально!
Не стоит считать что GC — best choice forever — идеального аллокатора вообще не существует. Но это не значит что не следует предусмотреть возможность удобного использования другого алгоритма аллокации. Впрочем как уже писали в ветке "заменить" его в .NET все таки можно.

G>>>А можно на форумах рассказывать как все "легко" делается в C++.
CC>>Не поверишь, оно и на самом деле легко.
G>Я писал аллокатор на C++, оно совсем не легко.
It depends. Что то уровня Hoard пишется действительно нетривиально. Обычный pooled alloc пишется гораздо проще.

G>>>Не-а. Можем еще вспомнить такие акронимы как ORM, IoC и другие
CC>>Мы все еще говорим о произодительности написанной программы?
G>Мы говорим о преимуществаих и недостатках. Производительность тоже одно из преимуществ.
Нет, это тебя куда то в сторону потянуло.
Напоминаю — разговор начинался с того, что для тех задач, в которых С# обгоняет по производительности аналог на С++ узким местом является рантайм компонент стандартной библиотеки — аллокатор. Если использовать предоставляемую С++ возможность замены аллокатора — выигрывание управляемых языков пропадает.
По большому счету в подобных сравнениях сравнивают не языки а реализацию определенного рода функционала стандартной библиотеки языка.

CC>>ЗЫ: Я вообще не понимаю, почему managed апологеты стараются увести ветку с обсуждения разницы в аллокаторах по умолчанию в С++ и .NET
G>Потому что программирование заключается не только в прикручивании аллокаторов.
Разумеется. Но ты опять не туда.

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

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

G>>а)Далеко не все способны написать написать аллокатор или сборщик мусора
CC>Сборщик еще понятно — там не все однозначно в случае С++. Но не осилить простой аллокатор — наводит на размышления.
Осилить могут многие, тут вопрос времени. Часто такое будет невыгодно.

G>>б)далеко не все могут нормально использовать аллокатор или сборщик мусора в С++
CC>Тоже нифига не радует. Отупение налицо
Есои человек не может написать аллокатор, то это сразу отупение?

G>>г)программисту на С# не надо знать все вышеперчисленное чтобы писать достаточно эффективные программы
CC>Ему надо знать другие вещи. GC не серебряная пуля, и если головой не думать то и им тоже можно себе по ногам популять. Только выразится это не в падении проги/порче данных, которое QA не пропустит, а к пожиранию памяти.
Если память сильно и постоянно отжирается, то это вызовет заметные тормозняки. Это будет сразу заметно. А если тормозов нет, то какая разница какая там цифирка в диспетчере задач?

CC>>>Можешь ли ты в управляемый средах легко сменить аллокатор?
G>>Нет, а зачем? Аккокатор в .NET выделяет память со скоростью O(1), куда еще быстрее?
CC>Кроме быстрее есть еще и потребление памяти и детерминизм.
CC>С какой скоростью оно кстати память освобождает? Именно освобождает — отдает системе. Мы же не в однозадачной ОС работаем — рядом еще пучок таких же процессов крутится.
.NET не отбирает память навсегда. ОС может в любой момент вытеснить страницы .NETовского приожения из памяти. Тут становится вопрос насколько интенсивно приложение работает с памятью. Если это десктопная прога с минимальными действиями в фоне, то она никому не помешает.

CC>А в условиях большого кол-ва выделений/освобождений в единицу времени? Вот такой вот алгоритм написал аспирант Вася — можно же в самом вложенном цикле каждый раз звать new а потом поинтер занулять — не ругается компилер, нормально!
В таких условиях .NET работает быстрее C++
Все создаваемые во внутреннем цикле объекты будут попадать в нулевое поколоение. Так как ссылок на них не будет, то они все будут убраны GC на первом проходе. В идеале за один проход GC будет очищаться все нулевое поколение. Это теоретический предел скорости выделения-освобождения памяти, только издержки на вызов GC будут.

CC>Не стоит считать что GC — best choice forever — идеального аллокатора вообще не существует. Но это не значит что не следует предусмотреть возможность удобного использования другого алгоритма аллокации. Впрочем как уже писали в ветке "заменить" его в .NET все таки можно.
Но мало кому нужно. И это радует.

G>>>>Не-а. Можем еще вспомнить такие акронимы как ORM, IoC и другие
CC>>>Мы все еще говорим о произодительности написанной программы?
G>>Мы говорим о преимуществаих и недостатках. Производительность тоже одно из преимуществ.
CC>Нет, это тебя куда то в сторону потянуло.
CC>Напоминаю — разговор начинался с того, что для тех задач, в которых С# обгоняет по производительности аналог на С++ узким местом является рантайм компонент стандартной библиотеки — аллокатор. Если использовать предоставляемую С++ возможность замены аллокатора — выигрывание управляемых языков пропадает.
Зато сильно проявляется другое преимущество — в скорости разработки

CC>По большому счету в подобных сравнениях сравнивают не языки а реализацию определенного рода функционала стандартной библиотеки языка.
Это все взаимосвязано. C# был бы совершенно другим языком, если бы там не было автоматической сборки мусора (GC — часть CLR, к конкретному языку отношения не имеет)

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

Y>>Дык, давайте устроим мини соревнование, придумаем задание на пару дней, пусть ее kuj & Sheridan порешают на своих любимых языках, потом независимое жюри и общественность оценять результаты, ну как вам такая идея?

kuj>Запросто. Час моего времени стоит $12.

Как ты съехал. Слабо?

ЗЫ: Мой час стоит 890 р

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

kuj>>>Всего сообщений 10041

kuj>>>

M>>Я и не говорю, что час моей работы стоит 12$ и, прикрываясь этим, не пытаюсь уйти от вопроса о компетенции

kuj>С удовольствием посмотрю что вы с Шериданом наваяете.

Скользкий и ушлый ты типок, однако.

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

S>yumi однажды (09 июня 2008 [Понедельник] 14:33) писал:

>> Дык, давайте устроим мини соревнование, придумаем задание на пару дней, пусть ее kuj & Sheridan порешают на своих любимых языках, потом независимое жюри и общественность оценять
>> результаты, ну как вам такая идея?
S>С тебя жесткое ТЗ.



Хардкор ТЗ?

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

S>yumi однажды (09 июня 2008 [Понедельник] 14:33) писал:

>> Дык, давайте устроим мини соревнование, придумаем задание на пару дней, пусть ее kuj & Sheridan порешают на своих любимых языках, потом независимое жюри и общественность оценять
>> результаты, ну как вам такая идея?
S>С тебя жесткое ТЗ.

Шеридан молодец — не сдрейфил

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

CC>>А в условиях большого кол-ва выделений/освобождений в единицу времени? Вот такой вот алгоритм написал аспирант Вася — можно же в самом вложенном цикле каждый раз звать new а потом поинтер занулять — не ругается компилер, нормально!
G>В таких условиях .NET работает быстрее C++
G>Все создаваемые во внутреннем цикле объекты будут попадать в нулевое поколоение. Так как ссылок на них не будет, то они все будут убраны GC на первом проходе. В идеале за один проход GC будет очищаться все нулевое поколение. Это теоретический предел скорости выделения-освобождения памяти, только издержки на вызов GC будут.
А вот это совершенно верно. Очень хороший пример — программисты C++ как правило очень плохо себе представляют природу работы GC, потому что инстинктивно ожидают тормозов от "большого кол-ва выделений/освобождений в единицу времени".
В то время, как управляемые среды работают наоборот — стоимость сборки мусора зависит от количества долгоживущих объектов.
Поведение GC очень напоминает тот самый Pooled Allocator, не к ночи будь помянут.

_d_m_ однажды (10 июня 2008 [Вторник] 05:19) писал:

> S>С тебя жесткое ТЗ.
> Хардкор ТЗ?
Такое чтобы было понятно что писать, чтобы "шаг влево шаг вправо" не было.

--
...belive in the matrix...

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

G>>>б)далеко не все могут нормально использовать аллокатор или сборщик мусора в С++
CC>>Тоже нифига не радует. Отупение налицо
G>Есои человек не может написать аллокатор, то это сразу отупение?
Если человек не может нормально использовать тривиальный алгоритм — да, отупение.

G>>>г)программисту на С# не надо знать все вышеперчисленное чтобы писать достаточно эффективные программы
CC>>Ему надо знать другие вещи. GC не серебряная пуля, и если головой не думать то и им тоже можно себе по ногам популять. Только выразится это не в падении проги/порче данных, которое QA не пропустит, а к пожиранию памяти.
G>Если память сильно и постоянно отжирается, то это вызовет заметные тормозняки. Это будет сразу заметно.
Пример из жизни — тормоза проявились только у заказчика, т.к. памяти на рабочих машинах там было сильно меньше чем у разработчиков. А тому было плевать — предыдущая версия работала отлично, "и пофигу что вы там на что то перешли — мне надо чтоб работало как прежде!"

G> А если тормозов нет, то какая разница какая там цифирка в диспетчере задач?
Огромная. Не надо думать что кроме данной программы не будет запущено что либо еще. Опять таки есть живые примеры...

G>.NET не отбирает память навсегда. ОС может в любой момент вытеснить страницы .NETовского приожения из памяти.
Вытеснить в своп = тормоза. Дисковые операции сильно медленнее операций с памятью. А если GC захочет помацать потными ручонками то, что уже выгрузилось?

G> Тут становится вопрос насколько интенсивно приложение работает с памятью. Если это десктопная прога с минимальными действиями в фоне, то она никому не помешает.
Десктопная прога с минимальными действиями вообще не имеет права на существование если ест слишком много. Тут уже упоминали про тул от ATI...

CC>>А в условиях большого кол-ва выделений/освобождений в единицу времени? Вот такой вот алгоритм написал аспирант Вася — можно же в самом вложенном цикле каждый раз звать new а потом поинтер занулять — не ругается компилер, нормально!
G>В таких условиях .NET работает быстрее C++
Так уже и быстрее любого С++ Правильный Pool Alloc как раз в таком случае гарантирует О(1) как для выделения так и для детерминированного удаления. Так что это еще вопрос — быстрее ли .NET в таком use case. Кроме того есть серьёзные подозрения что памяти C++ отъест меньше, а скорость аллокации будет такой же.

G>Все создаваемые во внутреннем цикле объекты будут попадать в нулевое поколоение. Так как ссылок на них не будет, то они все будут убраны GC на первом проходе. В идеале за один проход GC будет очищаться все нулевое поколение. Это теоретический предел скорости выделения-освобождения памяти, только издержки на вызов GC будут.
Как часто будет происходить проход GC? Сколько к этому моменту будет сидеть объектов в памяти? Впрочем стоит заметить что разница в скорости должна быть достаточно небольшой.

G>Зато сильно проявляется другое преимущество — в скорости разработки
Мимо кассы — мы сейчас о другом. Не будем отходить от темы, plz

ЗЫ: Очень кстати интересный пример есть в статье VladD2 http://www.rsdn.ru/article/dotnet/GC.xml#EHAAE

Автор(ы): Чистяков Влад (VladD2)
Дата: 14.06.2006
Уже много сказано слов о том, что такое GC, чем он хорош и как лучше его применять. Но, наверно, очень многим хочется знать, как устроен конкретный GC. Данная статья открывает некоторые подробности устройчтва GC в .NET Framework.

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

S>Очень хороший пример — программисты C++ как правило очень плохо себе представляют природу работы GC, потому что инстинктивно ожидают тормозов от "большого кол-ва выделений/освобождений в единицу времени".
Неверно
Выделение там простое, тормознуть может только когда понадобится еще кусок физической памяти от ОС — но это будет везде так и можно не принимать во внимание. Удаление же отложенное, происходит периодически. Тормознуть может на уплотнении — это уже почти непредсказуемо.
Пример был про то, что пока не пройдет вызов GC прога будет тупо есть память. Для случая выделения кучи небольших объектов вызов GC впрочем должен произойти до того как оно отожрет слишком большой кусок.

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

S>_d_m_ однажды (10 июня 2008 [Вторник] 05:19) писал:

>> S>С тебя жесткое ТЗ.
>> Хардкор ТЗ?
S>Такое чтобы было понятно что писать, чтобы "шаг влево шаг вправо" не было.

Да понял я. Просто смешно звучит.

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

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

S>>Очень хороший пример — программисты C++ как правило очень плохо себе представляют природу работы GC, потому что инстинктивно ожидают тормозов от "большого кол-ва выделений/освобождений в единицу времени".
CC>Неверно
Ну почему неверно? Ты же сам написал этот вопрос "с подковыркой". Надо полагать, тебе неочевидно, что освобождение объектов, созданных по new в цикле почти ничего не стоит.
Сравнимо по стоимости с убиением пула для Pooled Allocator.

CC>Выделение там простое, тормознуть может только когда понадобится еще кусок физической памяти от ОС — но это будет везде так и можно не принимать во внимание. Удаление же отложенное, происходит периодически. Тормознуть может на уплотнении — это уже почти непредсказуемо.
Кто станет тормозить?

CC>Пример был про то, что пока не пройдет вызов GC прога будет тупо есть память.
Ну и что? Прога не будет "есть память", будет распределяться память пула нулевого поколения, которая была получена у системы еще до начала цикла.
GC будет вызван в зависимости от настроек, но как правило можно быть уверенным, что при исчерпании размера нулевого поколения очередной new и вызовет полную очистку.
Стоимость уплотнения зависит только от количества живых объектов, которых в твоем примере мало.
Более того, искусственное продление времени жизни (в противоположность частому a = new ...; ... a = null, которое ты так с усмешкой критиковал), способно ухудшить производительность программы.

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

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

G>>>>г)программисту на С# не надо знать все вышеперчисленное чтобы писать достаточно эффективные программы
CC>>>Ему надо знать другие вещи. GC не серебряная пуля, и если головой не думать то и им тоже можно себе по ногам популять. Только выразится это не в падении проги/порче данных, которое QA не пропустит, а к пожиранию памяти.
G>>Если память сильно и постоянно отжирается, то это вызовет заметные тормозняки. Это будет сразу заметно.
CC>Пример из жизни — тормоза проявились только у заказчика, т.к. памяти на рабочих машинах там было сильно меньше чем у разработчиков. А тому было плевать — предыдущая версия работала отлично, "и пофигу что вы там на что то перешли — мне надо чтоб работало как прежде!"
При банальном переписывании бизнес приложения с C++ на C# скорость может измениться на 15% в любую сторону. Сам 2 таких пример видел.
Хватит создавать миф о черезмерной тормознутости .NET. Про большой расход памяти я еще иногда верю, но мне обычно пофигу сколько занимает прога в памяти 30 метров или 60.

G>> А если тормозов нет, то какая разница какая там цифирка в диспетчере задач?
CC>Огромная. Не надо думать что кроме данной программы не будет запущено что либо еще. Опять таки есть живые примеры...
Учите матчасть, циферка в дисетчере задач ничего не решает.

G>>.NET не отбирает память навсегда. ОС может в любой момент вытеснить страницы .NETовского приожения из памяти.
CC>Вытеснить в своп = тормоза. Дисковые операции сильно медленнее операций с памятью. А если GC захочет помацать потными ручонками то, что уже выгрузилось?
Учите матчасть. ОС регулярно скидывает в своп копии страни памяти, поэтом вытеснение ничего не стоит. Если приложение активно не пользуется всей выделенной памятью, то страницы в свопе пролежат пока приложение не завершится.
Для того чтобы GC не мацал своп надо не создавать сликом долгоживущих объектов.

G>> Тут становится вопрос насколько интенсивно приложение работает с памятью. Если это десктопная прога с минимальными действиями в фоне, то она никому не помешает.
CC>Десктопная прога с минимальными действиями вообще не имеет права на существование если ест слишком много. Тут уже упоминали про тул от ATI...
Это всетаки проблемы программистов, а не .NET. Плохо можно писать на лююбом языке и платформе.

CC>>>А в условиях большого кол-ва выделений/освобождений в единицу времени? Вот такой вот алгоритм написал аспирант Вася — можно же в самом вложенном цикле каждый раз звать new а потом поинтер занулять — не ругается компилер, нормально!
G>>В таких условиях .NET работает быстрее C++
CC>Так уже и быстрее любого С++ Правильный Pool Alloc как раз в таком случае гарантирует О(1) как для выделения так и для детерминированного удаления. Так что это еще вопрос — быстрее ли .NET в таком use case. Кроме того есть серьёзные подозрения что памяти C++ отъест меньше, а скорость аллокации будет такой же.
Да никто не мешает на C++ написать аналог CLR и потом радоваться как все хорошо работает
Но встает вопрос времени и стоимости такой разработки.
В .NET все преимущества получаете сразу.

G>>Все создаваемые во внутреннем цикле объекты будут попадать в нулевое поколоение. Так как ссылок на них не будет, то они все будут убраны GC на первом проходе. В идеале за один проход GC будет очищаться все нулевое поколение. Это теоретический предел скорости выделения-освобождения памяти, только издержки на вызов GC будут.
CC>Как часто будет происходить проход GC? Сколько к этому моменту будет сидеть объектов в памяти? Впрочем стоит заметить что разница в скорости должна быть достаточно небольшой.
Это зависи от размера объектов. GC вроде как ведет статистику сборки мусора и динамически меняет размеры поколений для оптимизации работы.

G>>Зато сильно проявляется другое преимущество — в скорости разработки
CC>Мимо кассы — мы сейчас о другом. Не будем отходить от темы, plz
Если вам нужно ТОЛЬКО быстродействие, то пишите на ассемблере.

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

G>>>>г)программисту на С# не надо знать все вышеперчисленное чтобы писать достаточно эффективные программы
CC>>>Ему надо знать другие вещи. GC не серебряная пуля, и если головой не думать то и им тоже можно себе по ногам популять. Только выразится это не в падении проги/порче данных, которое QA не пропустит, а к пожиранию памяти.
G>>Если память сильно и постоянно отжирается, то это вызовет заметные тормозняки. Это будет сразу заметно.
CC>Пример из жизни — тормоза проявились только у заказчика, т.к. памяти на рабочих машинах там было сильно меньше чем у разработчиков. А тому было плевать — предыдущая версия работала отлично, "и пофигу что вы там на что то перешли — мне надо чтоб работало как прежде!"

И этот человек обвинял меня в некомпетентности. Смешно.

Разработка того же приложения на С++ займет в 5-10 раз больше человеко-часов, а следовательно .NET разработка будет более продуманной, архитектура — более качественной, код, покрытый unit-тестами будет гораздо легче поддаваться рефакторингу, а следовательно легче будет оптимизировать критические места. Так что с очень высокой вероятностью конечное приложение будет: во-первых, производительнее аналогичного на C++, во-вторых, будет иметь гораздо меньше багов, и в-третьих, в большей мере будет удовлетворять запросам пользователей (см. про agile-методы, continuous integration, fit/fitnesse и т.п.).

Учи матчасть, короче.

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

CC>Удаление же отложенное, происходит периодически. Тормознуть может на уплотнении — это уже почти непредсказуемо.

В Sun JVM объекты, умирающие молодыми, на GC не влияют вообще никак. Ни дырки от них не остаются, ни подчищать их как-то специально не надо. http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html.

Более того, в 7-ой JDK ожидается сборщик мусора с soft realtime-овыми характеристиками, G1. Правда, это ещё вилами на воде писано, но статья уже есть

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

S>Более того, искусственное продление времени жизни (в противоположность частому a = new ...; ... a = null, которое ты так с усмешкой критиковал), способно ухудшить производительность программы.
Пока наблюдал только обратное.

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

G>Хватит создавать миф о черезмерной тормознутости .NET. Про большой расход памяти я еще иногда верю, но мне обычно пофигу сколько занимает прога в памяти 30 метров или 60.
Да я и не создавал

G>Учите матчасть, циферка в дисетчере задач ничего не решает.
Опа, выясняется... Т.е. все что показывает мне ProceXP — лажа?

G>Это всетаки проблемы программистов, а не .NET. Плохо можно писать на лююбом языке и платформе.
+1

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

kuj>И этот человек обвинял меня в некомпетентности. Смешно.
Где я такое писал? Прошу ссылку на "обвинение в некомпетентности" открытым текстом. На свои домыслы ссылки приводить не надо.

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

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

S>>Более того, искусственное продление времени жизни (в противоположность частому a = new ...; ... a = null, которое ты так с усмешкой критиковал), способно ухудшить производительность программы.
CC>Пока наблюдал только обратное.
Это показывает твое плохое знание предмета.