Здравствуйте, yoriсk.kiev.ua, Вы писали:
YKU>Топовые игры. ИМХО 32 поддерживаются для того, чтоб оно хоть как-то запустилось и там, но во всяких Фаркраях2 и прочих последних Сталкерах 64 — хардли рекоммендед и всё такое.
По поводу игр как-то сомнительно. Большинство игр на ПС приходят с консолей, где вообще памяти не густо (256+256 или 512 общей). И тут внезапно на ПС им начинает не хватать памяти?
YKU>Как только манагеры дадут отмашку, что рынок на 32 можно забить, так сразу будет 64 only. Хотя может я и ошибаюсь, хотелось-бы коментариев кого-нибуть из гейм-дева.
В смысле забить на все консоли и делать только для 64-бит ПС?
Здравствуйте, TK, Вы писали:
TK>Здравствуйте, MxMsk, Вы писали:
MM>>>>Далеко не всегда. В WPF, например, время жизни контрола вообще трудоуловимое в силу таких фичей, как шаблоны данных. Что касается "удаления из лямбд", то как же он сам это сделает? TK>>>В WPF никак. А в С++ есть готовые решения. MM>>Я про эти решения и спрашиваю.
TK>Для С++ есть "слабые" указатели которые уходят в 0 при явном удалении объекта (а не тогда, когда GC в голову придет). Есть сигналы которые могут автоматически разрывать связь с объектом при его удалении (не надо думать кто и куда подписал удаляемый объект и как его потом отписывать). Для всего этого написаны нормальные библиотеки которые позволяют выразит намерения разработчика без лишнего шума.
Почему вы ручное удаление продолжаете называть "автоматическим управлением ресурсами"? Разницу между "удалить объект когда не останется ссылок" и "удалить все ссылки когда не останется объекта" не видим?
TK>В итоге, проблема циклических ссылок стоит не так явно как то может казаться. Проблема циклических ссылок есть скорее в .net — каждая подписка на событие это фактически разделение владения объекта с источником событий. А учитывая, что детерминированного освобождения объектов нет (а в GUI как раз обычно все детерминировано) — это лишняя головная боль.
Здравствуйте, Константин Б., Вы писали:
КБ>Почему вы ручное удаление продолжаете называть "автоматическим управлением ресурсами"? Разницу между "удалить объект когда не останется ссылок" и "удалить все ссылки когда не останется объекта" не видим?
Надо понимать, что подлинной автоматики нет нигде. Добиться ситуации "когда не останется ссылок" это такое-же ручное управление — любая отписка от "глобальных" событий это и есть ручное управление памятью.
КБ>В .Net проблема циклических ссылок не стоит
Любая ссылка "из вне" на объект и проблема встанет в полный рост.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re[13]: No mention of either Silverlight or .NET on Windows
Здравствуйте, yoriсk.kiev.ua, Вы писали:
y> H>А что нибудь из недевелоперского?
y> Топовые игры. ИМХО 32 поддерживаются для того, чтоб оно хоть как-то запустилось и там, но во всяких Фаркраях2 и прочих последних Сталкерах 64 — хардли рекоммендед и всё такое. Как только манагеры дадут отмашку, что рынок на 32 можно забить, так сразу будет 64 only. Хотя может я и ошибаюсь, хотелось-бы коментариев кого-нибуть из гейм-дева.
Недавно, не то здесь, не то на хабре, видел статистику пользовательских конфигураций (выборка вроде приличная, жаль ссылку не могу найти). Там большинство пользовательских систем имеют менее 4 Gb Но даже если игруха будет хотеть 4Gb, ей для этого не обязательно быть 64-битной. А иметь две версии всегда более геморойно чем одну.
Здравствуйте, TK, Вы писали:
MM>>>>Далеко не всегда. В WPF, например, время жизни контрола вообще трудоуловимое в силу таких фичей, как шаблоны данных. Что касается "удаления из лямбд", то как же он сам это сделает? TK>>>В WPF никак. А в С++ есть готовые решения. MM>>Я про эти решения и спрашиваю. TK>Для С++ есть "слабые" указатели которые уходят в 0 при явном удалении объекта (а не тогда, когда GC в голову придет). Есть сигналы которые могут автоматически разрывать связь с объектом при его удалении (не надо думать кто и куда подписал удаляемый объект и как его потом отписывать). Для всего этого написаны нормальные библиотеки которые позволяют выразит намерения разработчика без лишнего шума.
Погоди погоди. Я же просил нормальный, реальный пример. Понятно, что можно напридумывать кучу костылей. Я привел пример, когда отдаю контрол в несколько лямбд. На что был получен ответ, типа это не проблема для C++. Однако, внятного решения — автоматической заботы об объекте, вырванном из дерева, мне никто не приводит. Вон, как что не скажешь про C++, у FR на всё ответ "при желании можно", но что-то пример продакшн уровня реализации этих желаний никто не приводит, только самопальные костыли... или Python!
TK>В итоге, проблема циклических ссылок стоит не так явно как то может казаться. Проблема циклических ссылок есть скорее в .net — каждая подписка на событие это фактически разделение владения объекта с источником событий. А учитывая, что детерминированного освобождения объектов нет (а в GUI как раз обычно все детерминировано) — это лишняя головная боль.
Проблемы циклических ссылок в .Net нет. И потом, я не уверен, что разрыв связи — это правильный путь. Если кто-то подписался на event, значит это ему нужно. Да и weak event при желании реализовать можно. А лучше научится реализовывать GUI без этих заморочек.
Здравствуйте, TK, Вы писали:
MM>>А если хук понадобиться мне после того, как "кнопка решит отдать концы"? Давай повторю, что мне хочется. Мне хочется, чтобы объекты могли собираться тогда, когда GUI фреймворк о них не имеет понятия. Когда они "в пределах видимости" GUI, т.е. находятся в визуальном дереве, ну или там в списке Components — то всё легко. А если я их временно оттуда выкидываю, что тогда? А если не выкину, но контрол понадобиться мне после удаления его родителя? Тут и начинаются танцы с бубнами и ручное управление. TK>Не надо путать враппер для кнопки (OkButton) и ресурс связанный с данной кнопкой (окно).
Да я видел полно кнопок, в которых еще таймер задействуется или какой-нибудь битмап грузится. Чем не ресурс? В конце концов, мы в нативной среде — там и сам враппер тоже ресурс.
Здравствуйте, MxMsk, Вы писали:
MM>Погоди погоди. Я же просил нормальный, реальный пример. Понятно, что можно напридумывать кучу костылей. Я привел пример, когда отдаю контрол в несколько лямбд. На что был получен ответ, типа это не проблема для C++. Однако, внятного решения — автоматической заботы об объекте, вырванном из дерева, мне никто не приводит. Вон, как что не скажешь про C++, у FR на всё ответ "при желании можно", но что-то пример продакшн уровня реализации этих желаний никто не приводит, только самопальные костыли... или Python!
Я уже писал выше GUI библиотеки предлагают решение, автоматическое управление с помощью подсчета ссылок:
Да это хуже GC из-за циклов, но никак ни ничего как пытаешься доказать тут ты.
Ну и потом проблемы с отвязкой — привязкой событий из NET вызванные особенностью реализации делегатов и событий
не нужно проецировать на другие среды в которых таких проблем нет.
Здравствуйте, FR, Вы писали:
MM>>Погоди погоди. Я же просил нормальный, реальный пример. Понятно, что можно напридумывать кучу костылей. Я привел пример, когда отдаю контрол в несколько лямбд. На что был получен ответ, типа это не проблема для C++. Однако, внятного решения — автоматической заботы об объекте, вырванном из дерева, мне никто не приводит. Вон, как что не скажешь про C++, у FR на всё ответ "при желании можно", но что-то пример продакшн уровня реализации этих желаний никто не приводит, только самопальные костыли... или Python!
FR>Я уже писал выше GUI библиотеки предлагают решение, автоматическое управление с помощью подсчета ссылок: FR>http://docs.wxwidgets.org/trunk/overview_refcount.html FR>http://www.gtk.org/api/2.6/gtk/GtkObject.html#id3557216 FR>Да это хуже GC из-за циклов, но никак ни ничего как пытаешься доказать тут ты.
Я что, где-либо отрицал наличие либ с reference counting? Речь идет о решении проблемы циклов через какой-то сторонний модуль, который типа их разруливает. Вот такое я и жду.
FR>Ну и потом проблемы с отвязкой — привязкой событий из NET вызванные особенностью реализации делегатов и событий FR>не нужно проецировать на другие среды в которых таких проблем нет.
Да не проецировал я делегаты, не я про них начал. Давайте уже последовательно!
Здравствуйте, MxMsk, Вы писали:
MM>Я что, где-либо отрицал наличие либ с reference counting? Речь идет о решении проблемы циклов через какой-то сторонний модуль, который типа их разруливает. Вот такое я и жду.
Я показал что это принципиально возможно, в питоне реализовано, в C++ я реализаций не видел.
В контексте темы GUI такой механизм не является необходимостью и каким-либо существенным стоп фактором,
так как циклы очень редки при типичном сценарии использования, и вполне нормально при необходимости разруливаются
вручную.
FR>>Ну и потом проблемы с отвязкой — привязкой событий из NET вызванные особенностью реализации делегатов и событий FR>>не нужно проецировать на другие среды в которых таких проблем нет. MM>Да не проецировал я делегаты, не я про них начал. Давайте уже последовательно!
Ну эта тема сразу вспоминается так как явный косяк и GC ничем ни помогает.
Re[14]: No mention of either Silverlight or .NET on Windows
Здравствуйте, Воронков Василий, Вы писали:
YKU>>Топовые игры. ИМХО 32 поддерживаются для того, чтоб оно хоть как-то запустилось и там, но во всяких Фаркраях2 и прочих последних Сталкерах 64 — хардли рекоммендед и всё такое.
ВВ>По поводу игр как-то сомнительно. Большинство игр на ПС приходят с консолей
Угу. Идут-идут и приходят.
ВВ>где вообще памяти не густо (256+256 или 512 общей). И тут внезапно на ПС им начинает не хватать памяти?
А вы требования к PC играм давно читали? А то я и не припомню уже, что-бы в recommended ниже 2G было. А так, всё больше 4G+ хотят, даже всякие Цивилизации, которым, по идее, оно вообще не сильно надо.
Re[15]: No mention of either Silverlight or .NET on Windows
Здравствуйте, yoriсk.kiev.ua, Вы писали:
ВВ>>где вообще памяти не густо (256+256 или 512 общей). И тут внезапно на ПС им начинает не хватать памяти? YKU>А вы требования к PC играм давно читали? А то я и не припомню уже, что-бы в recommended ниже 2G было. А так, всё больше 4G+ хотят, даже всякие Цивилизации, которым, по идее, оно вообще не сильно надо.
Мало ли что они пишут в требованиях. 32-битной игре *минимум* 4ГБ? Это сложно назвать технически обоснованным. Скорее всего просто подстраховываются на случай, если большая часть этих 4ГБ уже занята.
Re[14]: No mention of either Silverlight or .NET on Windows
Здравствуйте, Воронков Василий, Вы писали:
ВВ>По поводу игр как-то сомнительно. Большинство игр на ПС приходят с консолей, где вообще памяти не густо (256+256 или 512 общей). И тут внезапно на ПС им начинает не хватать памяти?
В играх легко забить почти любую доступную память увеличив детализацию, ну и получить ~квадратичный рост потребления памяти при этом.
Re[15]: No mention of either Silverlight or .NET on Windows
Здравствуйте, FR, Вы писали:
FR>В играх легко забить почти любую доступную память увеличив детализацию, ну и получить ~квадратичный рост потребления памяти при этом.
Ну вот, в ПС3 оперативной памяти — 256 ГБ. Увеличиваем детализацию вдвое (чего я вообще обычно не наблюдаю) — получаем увеличение памяти в четыре раза. А ведь текстурками потребление памяти не ограничивается. И откуда дефицит памяти на 32-битах?
Re[14]: No mention of either Silverlight or .NET on Windows
Здравствуйте, hattab, Вы писали:
H>Пардон, а как же дефрагментация хипа?
Для LOH компактификация не делается, там классический алгоритм с поиском свободных блоков.
H> Или куски такие большие что для них дефрагментация не выполняется?
Именно. Такие большие = 80 Кб.
H> А пулы проблему не решают?
Не всегда возможно пулы использовать. Отчасти проблему решают IO потоки, но и с ними проблем предостаточно.
НС>> Смотря где. На рынке серверных приложений вполне массовое. Да и решарперы всякие огребают по полной программе.
H>Натив позволяет этого избежать выбрав политику управления памятью под задачу
Нет тут никакой разницы с нативом. И там и там, чтобы ужаться до 2 Гб, нужно использовать целый комплекс мер, усложняющих решение и снижающих производительность даже при небольшой нагрузке. Намного проще просто перейти на 64 бита.
Здравствуйте, Ночной Смотрящий, Вы писали:
FR>>Ну эта тема сразу вспоминается так как явный косяк и GC ничем ни помогает.
НС>Что это за загадочный косяк такой?
Возможно Microsoft ожидает заметных перемен в компьютерных железках. Если нововведения будут достаточно привлекательными ( А тот же Apple постарается, чтобы так оно и было ) то потребуется обновлять весь софт.
При таком раскладе надо успевать выдать свежую версию и ОС и средств разработки и это надо делать паралелльно. Нет времени ждать, пока .Net устаканится под новые реалии, она слишком мнолитна и громоздка для резких поворотов.
Вот на правах свободного полета фантазии:
Представьте, если у кого-то уже дозревает до рыночной кондиции технология хранения данных со скоростью процессорного кэша и емкостью + себестоимость + энегронезависимость HDD. Как это повлияет на поведение крупных производителей софта ?!
Re[15]: No mention of either Silverlight or .NET on Windows
Здравствуйте, Ночной Смотрящий, Вы писали:
НС> НС>> Смотря где. На рынке серверных приложений вполне массовое. Да и решарперы всякие огребают по полной программе.
НС> H>Натив позволяет этого избежать выбрав политику управления памятью под задачу
НС> Нет тут никакой разницы с нативом.
При использование специализированных менеджеров памяти можно вообще избежать фрагментирования кучи
НС> И там и там, чтобы ужаться до 2 Гб, нужно использовать целый комплекс мер, усложняющих решение и снижающих производительность даже при небольшой нагрузке. Намного проще просто перейти на 64 бита.
Зачем ужиматься до 2Gb, когда позволяется 3Gb на 32-битных системах и 4Gb на 64? Разумеется, я не отрицаю явного преимущества 64-битного адресного пространства, но нужно это далеко не всем.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, FR, Вы писали:
НС>>>Что это за загадочный косяк такой? FR>>Тут http://habrahabr.ru/blogs/net/89529/ S>Ткните пальцем — в чём косяк?
В утечке памяти на платформе с GC и переходе на практически ручное управление чтобы ее избежать.
Но даже если игруха будет хотеть 4Gb, ей для этого не обязательно быть 64-битной. А иметь две версии всегда более геморойно чем одну.
