Здравствуйте, Sheridan, Вы писали:
S>Я просто в англицком не очень...
Раньше Silverlight позиционровался как такая Java или flash внутри броузера.
Теперь Silverlight это никакая не кросплатформа, а сугубо основа Windows Phone 7.
Т.е. вместо SL на Web рекомендуется использовать html[5]. Например <canvas> и JavaScript.
Здравствуйте, Sheridan, Вы писали:
S> Чтото я не понял что МС собирается с сильверлайтом сделать? Примораживают разработку в пользу хтмл5? S> Я просто в англицком не очень...
Здравствуйте, c-smile, Вы писали:
CS>Раньше Silverlight позиционровался как такая Java или flash внутри броузера. CS>Теперь Silverlight это никакая не кросплатформа, а сугубо основа Windows Phone 7. CS>Т.е. вместо SL на Web рекомендуется использовать html[5]. Например <canvas> и JavaScript.
Не понятно откуда вы это взяли. Написано англиским по белому. Сильверлайт никто не кидает, но в связи с выходом html5 сменился фокус на реально кроссплатформенную платформу ( ). А сильверлайт так и остается.
Здравствуйте, vladimir.vladimirovich, Вы писали:
VV>Здравствуйте, c-smile, Вы писали:
CS>>Раньше Silverlight позиционровался как такая Java или flash внутри броузера. CS>>Теперь Silverlight это никакая не кросплатформа, а сугубо основа Windows Phone 7. CS>>Т.е. вместо SL на Web рекомендуется использовать html[5]. Например <canvas> и JavaScript.
VV>Не понятно откуда вы это взяли. Написано англиским по белому. Сильверлайт никто не кидает, но в связи с выходом html5 сменился фокус на реально кроссплатформенную платформу ( ). А сильверлайт так и остается.
Это вольный перевод вот этого:
... Bob Muglia, the Microsoft President in charge of the company’s server and tools business ... :
“Silverlight is our development platform for Windows Phone,” he said.
... But when it comes to touting Silverlight as Microsoft’s vehicle for delivering a cross-platform runtime, “our strategy has shifted,” Muglia told me.
“But HTML is the only true cross platform solution for everything, including (Apple’s) iOS platform,” Muglia said.
Здравствуйте, c-smile, Вы писали:
VV>>Не понятно откуда вы это взяли. Написано англиским по белому. Сильверлайт никто не кидает, но в связи с выходом html5 сменился фокус на реально кроссплатформенную платформу ( ). А сильверлайт так и остается. CS>Это вольный перевод вот этого:
CS>
CS>... Bob Muglia, the Microsoft President in charge of the company’s server and tools business ... :
CS>“Silverlight is our development platform for Windows Phone,” he said.
CS>... But when it comes to touting Silverlight as Microsoft’s vehicle for delivering a cross-platform runtime, “our strategy has shifted,” Muglia told me.
CS>“But HTML is the only true cross platform solution for everything, including (Apple’s) iOS platform,” Muglia said.
Здравствуйте, vladimir.vladimirovich, Вы писали:
CS>>
CS>>... Bob Muglia, the Microsoft President in charge of the company’s server and tools business ... :
CS>>“Silverlight is our development platform for Windows Phone,” he said.
CS>>... But when it comes to touting Silverlight as Microsoft’s vehicle for delivering a cross-platform runtime, “our strategy has shifted,” Muglia told me.
CS>>“But HTML is the only true cross platform solution for everything, including (Apple’s) iOS platform,” Muglia said.
VV>Ну и что вы считаете там написано?
Ну я так понимаю — в изначальном посте и написано, что Андрей считает. Я кстати из прочитанного примерно те же выводы сделал. С чем вы конкретно несогласны?
Здравствуйте, vladimir.vladimirovich, Вы писали:
VV>Здравствуйте, c-smile, Вы писали:
VV>>>Не понятно откуда вы это взяли. Написано англиским по белому. Сильверлайт никто не кидает, но в связи с выходом html5 сменился фокус на реально кроссплатформенную платформу ( ). А сильверлайт так и остается. CS>>Это вольный перевод вот этого:
CS>>
CS>>... Bob Muglia, the Microsoft President in charge of the company’s server and tools business ... :
CS>>“Silverlight is our development platform for Windows Phone,” he said.
CS>>... But when it comes to touting Silverlight as Microsoft’s vehicle for delivering a cross-platform runtime, “our strategy has shifted,” Muglia told me.
CS>>“But HTML is the only true cross platform solution for everything, including (Apple’s) iOS platform,” Muglia said.
VV>Ну и что вы считаете там написано?
Там написаны три ключевые фразы:
1) "Silverlight is our development platform for Windows Phone".
2) cross-platform runtime — “our strategy has shifted”
3) "HTML is the only true cross platform solution"
Что еще надо людям с головой на плечах и достаточным опытом чтения между строк?
По-моему тут практически всё черным по белому написано. Сообственно то что я и написал в начальном ответе.
Если ты думаешь об этом всем как-то по другому то попробуй изложить список мотиваций MSу поддерживать SL на Linux или Mac ...
Особенно на фоне боданий Adobe vs. Apple и пр.
Здравствуйте, vladimir.vladimirovich, Вы писали:
VV>Не понятно откуда вы это взяли. Написано англиским по белому. Сильверлайт никто не кидает, но в связи с выходом html5 сменился фокус на реально кроссплатформенную платформу ( ). А сильверлайт так и остается.
макрос "а Х так и остается" — один из любимых у майкрософта. Лично я утратил веру когда они выпустили бэту winFS, а потом сказали "а winFS так и остается, только войдет в другие проекты, а не будет самостоятельным продуктом". И ни гу-гу с тех времен. Вот и сильвер для веба "так и остается"
If the message above is in English — means I'm wasting my work time and work computer to post here. No hard feelings
Здравствуйте, CreatorCray, Вы писали:
CC>ИМХО бобик сдох. CC>После непродолжительной панихиды останки бобика преданы земле вопхнуты в сомнительный проект под названием наш ответ жопсу! WP7
а чего удивительного?
1. в стандартную поставку ИЕ его не вкинули, заставив юзеров проходи все круги ада
2. жутко сложная установка по сравнению с флешем (особенно если уже стоит sdk)
3. очень высокая чувствительность к версиям, которые выходили раз в неделю
4. политика "выпустить лишь бы что-то, главное выпустить" — уродец версии 1.0, работающий только на джаваскрипте, альфа 1.1 от которой ничего к 2.0 не осталось. Нехватка контролов в 2.0, неполная работа с диском там же, нет веб-камеры, микрофона
5. асинхронная модель, превращающая код в лапшу. Сделать 5 запросов в одном методе низзя — надо генерить 10 методов по одной строке
6. несовместимость рантаймов, из-за которой надо было перекомпиливать даже самый безобидный код
потому, господа, продолжаем кушать html5/6/7, колоться, плакать и опять кушать. Продолжаем извращаться аки google gears для оффлайн программ, и конечно же огромное спасибо эплу который ничего не поддерживает и поддерживать не собирается.
If the message above is in English — means I'm wasting my work time and work computer to post here. No hard feelings
Здравствуйте, Niemand, Вы писали:
N>макрос "а Х так и остается" — один из любимых у майкрософта.
Дык Сильвер для веба вроде не особо и был. Остаётся он для "media and line-of-business applications". Вон управление Azure на Silverlight переписали.
N>Лично я утратил веру когда.
А я пока нет Сколько вони было по поводу linq2SQL. Причём именно такими-же самыми словами: бобик сдох, поматросили и бросили, знаем мы это "так и остаётся". Ан нет, и поддерживают, и обновления выпускают. Так что будем посмотреть.
Здравствуйте, yoriсk.kiev.ua, Вы писали:
YKU>А я пока нет Сколько вони было по поводу linq2SQL. Причём именно такими-же самыми словами: бобик сдох, поматросили и бросили, знаем мы это "так и остаётся". Ан нет, и поддерживают, и обновления выпускают. Так что будем посмотреть.
по поводу линка переживать не стоит — это состоявшийся продукт или фича или что там, которая может существовать сама по себе без поддержки долгое время. Т.к. просто работает. А сильвер без усилий майкрософта никому не нужен в принципе.
If the message above is in English — means I'm wasting my work time and work computer to post here. No hard feelings
Здравствуйте, Sheridan, Вы писали:
S>Приветствую! S>Чтото я не понял что МС собирается с сильверлайтом сделать? Примораживают разработку в пользу хтмл5? S>Я просто в англицком не очень...
Выживет. Как замена HTML, он никогда не позиционировался.
Здравствуйте, Farsight, Вы писали:
F>Выживет. Как замена HTML, он никогда не позиционировался.
Собственно никто никогда и не утверждал что SL это такой HTML.
Просто когда-то SL работал в <object> в HTML. Теперь не работает. Во всяком случае в IE 7.5 (из WP7)
Просто silverlight реинкарнирован в WP7. SL как среда исполнения кода на mobile это наверное правильно.
WP7 и Android, С# и Java.
Но вот что интересно. Примерно на одном и том же железе iPhone (native code) как-то по ощущениям лучше работатет чем Android (Java).
В свете последних событий я так понимаю Oracle дожмет Google и последний будет вынужден перейти на Android на С или что-то близкое ему.
В результате Microsoft останется одна с managed mobile... Ну посмотрим.
Здравствуйте, c-smile, Вы писали:
CS>В свете последних событий я так понимаю Oracle дожмет Google и последний будет вынужден перейти на Android на С или что-то близкое ему.
Почему обязательно на native-код, а не на другое managed-решение (моно, например, гыгы)?
Здравствуйте, c-smile, Вы писали:
CS>Но вот что интересно. Примерно на одном и том же железе iPhone (native code) как-то по ощущениям лучше работатет чем Android (Java). CS>В свете последних событий я так понимаю Oracle дожмет Google и последний будет вынужден перейти на Android на С или что-то близкое ему.
Это до тех пор, пока не появится червяк, гуляющий по айфонам через удаленную уязвимость на переполнение буфера в каком-нибудь нативном приложении.
Возможно LLVM окажется хорошим балансом между требованиями безопасности и производительности.
Здравствуйте, Mazay, Вы писали:
M>Это до тех пор, пока не появится червяк, гуляющий по айфонам через удаленную уязвимость на переполнение буфера в каком-нибудь нативном приложении. M>Возможно LLVM окажется хорошим балансом между требованиями безопасности и производительности.
Насколько я понимаю — подобные червяки на iPhone являются уже нормой. Но пользователи как-то защищены от этого кошмара тем, что Apple верифицирует программы, которые доступны через их маркет. А все остальные способы (разлочить и поставить) — табу. И если что — пользователи ССЗБ.
Но это невероятно дорогое в стоимости решение (полу-автоматическая верификация приложений). Также вызывает много трений с разработчиками приложений (которые долго ждут разрешения положить на маркет или недоумевают, почему было отказано и почему разбор занял столько времени) и с пользователями, которые не хотят быть ограниченными только маркетом (это в меньшей мере).
Кроме того, как показал недавний пример с приложением под Android, которое невозможно обнаружить стандартными средствами на телефоне после установке и которое пересылает входящие СМС на чужой телефон — через маркет такое просочится тоже может легко. Так что — да. Платформа должна быть как можно более безопасная изначально. И если МС останется одна с managed платформой — это будет серьезный козырь в гонке.
Здравствуйте, Кэр, Вы писали:
Кэр>Здравствуйте, Mazay, Вы писали:
M>>Это до тех пор, пока не появится червяк, гуляющий по айфонам через удаленную уязвимость на переполнение буфера в каком-нибудь нативном приложении. M>>Возможно LLVM окажется хорошим балансом между требованиями безопасности и производительности.
Кэр>Насколько я понимаю — подобные червяки на iPhone являются уже нормой. Но пользователи как-то защищены от этого кошмара тем, что Apple верифицирует программы, которые доступны через их маркет. А все остальные способы (разлочить и поставить) — табу. И если что — пользователи ССЗБ.
Откуда вы взяли что черви на iPhone это норма?
Кэр>Но это невероятно дорогое в стоимости решение (полу-автоматическая верификация приложений). Также вызывает много трений с разработчиками приложений (которые долго ждут разрешения положить на маркет или недоумевают, почему было отказано и почему разбор занял столько времени) и с пользователями, которые не хотят быть ограниченными только маркетом (это в меньшей мере).
Полуавтоматическая верификация вовсю используется
Кэр>Кроме того, как показал недавний пример с приложением под Android, которое невозможно обнаружить стандартными средствами на телефоне после установке и которое пересылает входящие СМС на чужой телефон — через маркет такое просочится тоже может легко. Так что — да. Платформа должна быть как можно более безопасная изначально. И если МС останется одна с managed платформой — это будет серьезный козырь в гонке.
Андроид тоже по умолчанию использует managed платформу.
Здравствуйте, Кэр, Вы писали:
Кэр>Здравствуйте, Mazay, Вы писали:
M>>Это до тех пор, пока не появится червяк, гуляющий по айфонам через удаленную уязвимость на переполнение буфера в каком-нибудь нативном приложении. M>>Возможно LLVM окажется хорошим балансом между требованиями безопасности и производительности.
Кэр>Насколько я понимаю — подобные червяки на iPhone являются уже нормой.
эээээ. да?
Кэр>Но пользователи как-то защищены от этого кошмара тем, что Apple верифицирует программы, которые доступны через их маркет. А все остальные способы (разлочить и поставить) — табу. И если что — пользователи ССЗБ.
В айфоне есть не только это. Каждое приложение ограничено собственной песочницей (вплоть собственного до набора /usr, /lib, /etc и т.п. для каждого приложения) и не имеет доступа к внешним ресурсам, кроме специально разрешенных через API.
Здравствуйте, Mazay, Вы писали:
M>Здравствуйте, c-smile, Вы писали:
CS>>Но вот что интересно. Примерно на одном и том же железе iPhone (native code) как-то по ощущениям лучше работатет чем Android (Java). CS>>В свете последних событий я так понимаю Oracle дожмет Google и последний будет вынужден перейти на Android на С или что-то близкое ему.
M>Это до тех пор, пока не появится червяк, гуляющий по айфонам через удаленную уязвимость на переполнение буфера в каком-нибудь нативном приложении. M>Возможно LLVM окажется хорошим балансом между требованиями безопасности и производительности.
Если ты сам производитель платформы то у тебя есть возможность обеспечить песочницу аппаратным образом.
Тем более на мобильных устройствах — у тебя есть одно front running приложение. В принципе ты можешь
построить ACL на hardware в этом случае.
Скажем для GUI thread все области памяти кроме собственных страниц являются скажем readonly.
Т.е. переполнение буфера системе до фени.
Здравствуйте, Кэр, Вы писали:
Кэр>Кроме того, как показал недавний пример с приложением под Android, которое невозможно обнаружить стандартными средствами на телефоне после установке и которое пересылает входящие СМС на чужой телефон — через маркет такое просочится тоже может легко. Так что — да. Платформа должна быть как можно более безопасная изначально. И если МС останется одна с managed платформой — это будет серьезный козырь в гонке.
Это говорит лишь о том что "managed" ≠ "secure". Т.е. managed это не козырь в смысле security. Во всякос случае не основной.
У managed платформы есть свои достоинства и есть недостатки.
Скажем если на Android кто-то сделает killer app использующий native code (там это возможно) то WP7 будет с этим соревноваться трудно.
Т.е. пока managed код работает как клей между native functions — все OK. А как что-то серьёзное ...
Здравствуйте, c-smile, Вы писали:
CS>Скажем если на Android кто-то сделает killer app использующий native code (там это возможно) то WP7 будет с этим соревноваться трудно. CS>Т.е. пока managed код работает как клей между native functions — все OK. А как что-то серьёзное ... Ты не путай интерпритаторы динамически типизированных скриптов и компилируемый код.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Sheridan, Вы писали:
S>Приветствую! S>Чтото я не понял что МС собирается с сильверлайтом сделать? Примораживают разработку в пользу хтмл5? S>Я просто в англицком не очень...
1. Silverlight is very important and strategic to Microsoft.
2. We’re working hard on the next release of Silverlight, and it will continue to be cross-browser and cross-platform, and run on Windows and Mac.
3. Silverlight is a core application development platform for Windows, and it’s the development platform for Windows Phone.
we’ll continue to invest in Silverlight and enable developers to build great apps and experiences with it in the future.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, c-smile, Вы писали:
CS>>Скажем если на Android кто-то сделает killer app использующий native code (там это возможно) то WP7 будет с этим соревноваться трудно. CS>>Т.е. пока managed код работает как клей между native functions — все OK. А как что-то серьёзное ... WH> Ты не путай интерпритаторы динамически типизированных скриптов и компилируемый код.
Я не путаю. Native код это не просто возможность исполнять нечто в машинных командах.
Это еще также возможность использовать memory manager оптимальный для данной конкретной функции или подсистемы.
Скажем для задачи представления XML/HTML в памяти managed heap только вреден. View владеет документом. Документ владеет своими children (nodes).
Такая структура очень хорошо ложится на reference counting memory management — детерминирована и эффективна.
В случае же pure managed solution heap получается забит набором мелких объектов на которые приходится тратить прцессорное время в GC циклах совершенно необоснованно.
Еще раз: managed среды хорошо себя ведут в ситуациях кода они являются top level управлющим кодом — например установить свойство native объекта по каким нибудь business правилам используя данные полученные из опять же native DB.
Т.е. для UI automation, business logic processing и т.д. Но есть low level код (например в играх) который лучше бы если был non-managed.
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Приветствую, WizardBox, вы писали:
WB> S>Я просто в англицком не очень... WB> Ответ от Bob Muglia пр.... WB> we’ll continue to invest in Silverlight and enab...
Здравствуйте, WizardBox, Вы писали:
WB>Здравствуйте, Sheridan, Вы писали:
S>>Приветствую! S>>Чтото я не понял что МС собирается с сильверлайтом сделать? Примораживают разработку в пользу хтмл5? S>>Я просто в англицком не очень...
WB>Ответ от Bob Muglia про его интервью — Сильверлайт очень важен: WB>http://team.silverlight.net/announcement/pdc-and-silverlight/
WB>1. Silverlight is very important and strategic to Microsoft. WB>2. We’re working hard on the next release of Silverlight, and it will continue to be cross-browser and cross-platform, and run on Windows and Mac. WB>3. Silverlight is a core application development platform for Windows, and it’s the development platform for Windows Phone.
WB>we’ll continue to invest in Silverlight and enable developers to build great apps and experiences with it in the future.
Здравствуйте, Кэр, Вы писали:
Кэр> Но пользователи как-то защищены от этого кошмара тем, что Apple верифицирует программы, которые доступны через их маркет.
Э.. Не понял. Скажем, jailbreakme.com используют уязвимость в коде pdf-viewer'а от Apple, а вовсе не 3rd party apps. Как пользователь может уберечься от открытия неправильного документа?
Здравствуйте, henson, Вы писали:
WB>>we’ll continue to invest in Silverlight and enable developers to build great apps and experiences with it in the future. H>Бедняга вынужден отдуваться за бред Балмера
А что же нам говорит сам Стив?
We will also enable browser scenarios that provide additional capabilities, including Silverlight. Silverlight provides the richest media streaming capabilities on the web, and we will continue to deliver that on both Windows and Mac.
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, WolfHound, Вы писали:
WH>>Здравствуйте, c-smile, Вы писали:
CS>>>Скажем если на Android кто-то сделает killer app использующий native code (там это возможно) то WP7 будет с этим соревноваться трудно. CS>>>Т.е. пока managed код работает как клей между native functions — все OK. А как что-то серьёзное ... WH>> Ты не путай интерпритаторы динамически типизированных скриптов и компилируемый код.
CS>Я не путаю. Native код это не просто возможность исполнять нечто в машинных командах. CS>Это еще также возможность использовать memory manager оптимальный для данной конкретной функции или подсистемы. CS>Скажем для задачи представления XML/HTML в памяти managed heap только вреден. View владеет документом. Документ владеет своими children (nodes). CS>Такая структура очень хорошо ложится на reference counting memory management — детерминирована и эффективна.
Ага, особенно если у каждого узла есть parent
CS>В случае же pure managed solution heap получается забит набором мелких объектов на которые приходится тратить прцессорное время в GC циклах совершенно необоснованно.
Странный аргумент. Что-то мне кажется что представление развесистого дерева в managed heap потребует гораздо меньше ресурсов, чем в unmanaged. Именно managed heap отлично работает с кучей мелких объектов. Кроме того никаких проблем с ссылкой на родителя не будет.
CS>Еще раз: managed среды хорошо себя ведут в ситуациях кода они являются top level управлющим кодом — например установить свойство native объекта по каким нибудь business правилам используя данные полученные из опять же native DB. CS>Т.е. для UI automation, business logic processing и т.д. Но есть low level код (например в играх) который лучше бы если был non-managed.
Это слишком общее утверждение, которое еще надо доказать в каждом конкретном случае.
Здравствуйте, gandjustas, Вы писали:
CS>>Скажем для задачи представления XML/HTML в памяти managed heap только вреден. View владеет документом. Документ владеет своими children (nodes). CS>>Такая структура очень хорошо ложится на reference counting memory management — детерминирована и эффективна. G>Ага, особенно если у каждого узла есть parent
Здесь отношения владения более чем очевидны: родительский узел владеет дочерними, а дочерние не владеют родителем. Поэтому дочерние хранят слабый указатель на родителя, который не увеличивает счетчик.
Здравствуйте, yoriсk.kiev.ua, Вы писали:
YKU>Здравствуйте, henson, Вы писали:
WB>>>we’ll continue to invest in Silverlight and enable developers to build great apps and experiences with it in the future. H>>Бедняга вынужден отдуваться за бред Балмера
YKU>А что же нам говорит сам Стив?
Здравствуйте, gandjustas, Вы писали:
CS>>Я не путаю. Native код это не просто возможность исполнять нечто в машинных командах. CS>>Это еще также возможность использовать memory manager оптимальный для данной конкретной функции или подсистемы. CS>>Скажем для задачи представления XML/HTML в памяти managed heap только вреден. View владеет документом. Документ владеет своими children (nodes). CS>>Такая структура очень хорошо ложится на reference counting memory management — детерминирована и эффективна. G>Ага, особенно если у каждого узла есть parent
parent это голый pointer т.е. weak reference как уже сказали.
CS>>В случае же pure managed solution heap получается забит набором мелких объектов на которые приходится тратить прцессорное время в GC циклах совершенно необоснованно. G>Странный аргумент. Что-то мне кажется что представление развесистого дерева в managed heap потребует гораздо меньше ресурсов, чем в unmanaged. Кроме того никаких проблем с ссылкой на родителя не будет.
Чем конкретно мой аргумент странный? И проблема с ссылкой на родителя мне не известна.
"представление развесистого дерева" в managed heap абсолютно такое же по памяти как и в случае unmanaged.
Я имплементировал оба варианта (в D и в C++) поэтому знаю достоверно.
Единственно в случае reference counting каждый node должен иметь поле ref_counter. Но этот overhead он опять же а) детерминирован и б) явно меньше в целом чем overhead managed heap.
G>Именно managed heap отлично работает с кучей мелких объектов.
"работает" понятие сугубо растяжимое.
managed heap отлично справляется с аллокацией мелких объектов. Инкремент указателя фактически. Но на предаврительно и с большим запасом отобранной у системы памяти прошу заметить.
Но вот когда дело доходит до GC... GС цикл как ты понимаешь это O(N) операция. Т.е. чем больше у тебя объектов тем больше ему работы.
Странно, я думал это очевидно.
CS>>Еще раз: managed среды хорошо себя ведут в ситуациях кода они являются top level управлющим кодом — например установить свойство native объекта по каким нибудь business правилам используя данные полученные из опять же native DB. CS>>Т.е. для UI automation, business logic processing и т.д. Но есть low level код (например в играх) который лучше бы если был non-managed. G>Это слишком общее утверждение, которое еще надо доказать в каждом конкретном случае.
У меня есть конкретные примеры. Sciter есть система в которой используется и детерминированый heap и managed (TIScript VM). Там где они нужны и оптимальны.
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, gandjustas, Вы писали:
CS>>>Я не путаю. Native код это не просто возможность исполнять нечто в машинных командах. CS>>>Это еще также возможность использовать memory manager оптимальный для данной конкретной функции или подсистемы. CS>>>Скажем для задачи представления XML/HTML в памяти managed heap только вреден. View владеет документом. Документ владеет своими children (nodes). CS>>>Такая структура очень хорошо ложится на reference counting memory management — детерминирована и эффективна. G>>Ага, особенно если у каждого узла есть parent
CS>parent это голый pointer т.е. weak reference как уже сказали.
CS>>>В случае же pure managed solution heap получается забит набором мелких объектов на которые приходится тратить прцессорное время в GC циклах совершенно необоснованно. G>>Странный аргумент. Что-то мне кажется что представление развесистого дерева в managed heap потребует гораздо меньше ресурсов, чем в unmanaged. Кроме того никаких проблем с ссылкой на родителя не будет.
CS>Чем конкретно мой аргумент странный? И проблема с ссылкой на родителя мне не известна.
CS>"представление развесистого дерева" в managed heap абсолютно такое же по памяти как и в случае unmanaged. CS>Я имплементировал оба варианта (в D и в C++) поэтому знаю достоверно. CS>Единственно в случае reference counting каждый node должен иметь поле ref_counter. Но этот overhead он опять же а) детерминирован и б) явно меньше в целом чем overhead managed heap.
И какой оверхед по памяти у manаged heap?
G>>Именно managed heap отлично работает с кучей мелких объектов. CS>"работает" понятие сугубо растяжимое.
Очень даже конкретное.
CS>managed heap отлично справляется с аллокацией мелких объектов. Инкремент указателя фактически. Но на предаврительно и с большим запасом отобранной у системы памяти прошу заметить.
Во-первых зачем она системе? Во-вторых зачем заранее отбирать у системы больше памяти?
CS>Но вот когда дело доходит до GC... GС цикл как ты понимаешь это O(N) операция. Т.е. чем больше у тебя объектов тем больше ему работы. CS>Странно, я думал это очевидно.
Ниче что аллокация и освобождение памяти в unmanaged heap чаще всего тоже O(N)? (правда там N разные)
Ниче что конкретная реализация heap в windows сосет на массовых выделениях-освобождениях памяти по сравнению с .NET GC?
Это еще refcounting никто там не занимался.
Ты такие наивные глупости говоришь.
CS>>>Еще раз: managed среды хорошо себя ведут в ситуациях кода они являются top level управлющим кодом — например установить свойство native объекта по каким нибудь business правилам используя данные полученные из опять же native DB. CS>>>Т.е. для UI automation, business logic processing и т.д. Но есть low level код (например в играх) который лучше бы если был non-managed. G>>Это слишком общее утверждение, которое еще надо доказать в каждом конкретном случае.
CS>У меня есть конкретные примеры. Sciter есть система в которой используется и детерминированый heap и managed (TIScript VM). Там где они нужны и оптимальны.
Докажи выделенное.
Здравствуйте, gandjustas, Вы писали:
CS>>"представление развесистого дерева" в managed heap абсолютно такое же по памяти как и в случае unmanaged. CS>>Я имплементировал оба варианта (в D и в C++) поэтому знаю достоверно. CS>>Единственно в случае reference counting каждый node должен иметь поле ref_counter. Но этот overhead он опять же а) детерминирован и б) явно меньше в целом чем overhead managed heap. G> G>И какой оверхед по памяти у manаged heap?
managed heap отбирает у системы памяти заведомо больше чем нужно для представления объектов.
Как правило чтобы GC себя комфортно чувствовал он должен у системы отобрать в два раза больше памяти чем нужно.
Т.е. если у тебя есть скажем DOM tree в памяти то managed heap'у нужен space в два раза больше. Если
же размер heap равен размеру этого самого DOM tree то каждая следующая аллокация будет приводить к полномоу GC. Т.е. O(N) операция.
Что явно больше чем в C heap где аллокация стоит от O(1) до O(log(N)) (очень крайний случай).
G>>>Именно managed heap отлично работает с кучей мелких объектов. CS>>"работает" понятие сугубо растяжимое. G>Очень даже конкретное.
Ну тебе виднее.
CS>>managed heap отлично справляется с аллокацией мелких объектов. Инкремент указателя фактически. Но на предаврительно и с большим запасом отобранной у системы памяти прошу заметить. G>Во-первых зачем она системе? Во-вторых зачем заранее отбирать у системы больше памяти?
Аллокация в GC heap дешевая только тогда когда она сводится к alloactedPtr += requiredSize. Этот alloactedPtr указывает на позицию в буффере —
фрагменту RAM предварительно отобранных у системы "про запас".
CS>>Но вот когда дело доходит до GC... GС цикл как ты понимаешь это O(N) операция. Т.е. чем больше у тебя объектов тем больше ему работы. CS>>Странно, я думал это очевидно. G>Ниче что аллокация и освобождение памяти в unmanaged heap чаще всего тоже O(N)? (правда там N разные)
Тебя обманули. Освобождение памяти в unmanaged heap это опреация O(1) — удалить элемент из одного двухсвязанного списка и поместить в другой (free blocks list). Если при этом еще исполняется объединение блоков то больше чем O(1). То же самое или близкое к тому и с выделением.
Основная проблема в unmanaged heap это проблема фрагментации. Но это другая история.
G>Ниче что конкретная реализация heap в windows сосет на массовых выделениях-освобождениях памяти по сравнению с .NET GC? G>Это еще refcounting никто там не занимался. G>Ты такие наивные глупости говоришь.
Я не один такие глупости говорю. Скажем разработчики Windows не стали писать систему на .NET. Хотя у них все инструменты есть для этого.
А вопрос что лучше managed или non-managed heap он имеет ту же ценность что и "мальчик, ты кого больше любишь — маму или папу?"
Т.е. и то и то хорошо если употреблено по делу — а не квадратно-гнездовым образом. Silver bullets их таки нет, да.
В прошлую среду кстати был в Evernote. Они сделали попытку написать Evernote 3.5 в WPF/.NET.
Дело закончилось Evernote 4.0 как сугубо native application. Хотя это другая крайность. Надо было на Sciter это все делать изначально
CS>>У меня есть конкретные примеры. Sciter есть система в которой используется и детерминированый heap и managed (TIScript VM). Там где они нужны и оптимальны. G>Докажи выделенное.
Здравствуйте, c-smile, Вы писали:
CS>Основная проблема в unmanaged heap это проблема фрагментации. Но это другая история.
Другая-не другая, но очень интересная.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Eugeny__, Вы писали:
E__>Здравствуйте, c-smile, Вы писали:
CS>>Основная проблема в unmanaged heap это проблема фрагментации. Но это другая история.
E__>Другая-не другая, но очень интересная.
Согласен что интересная. И кстати для частных случаев хорошо решаемая. Например для блоков фиксированного размера сделать эффективный аллокатор тривиально.
Для блоков переменного размера например для парсинга очень хорошо подходят memory pools a la APR и т.д.
Это к своему тезису: каждая задача/функциональность имеет свой, оптимальный memory manager. Говорить что все должно быть managed или все non-managed это технически безграмотно.
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, gandjustas, Вы писали:
CS>>>"представление развесистого дерева" в managed heap абсолютно такое же по памяти как и в случае unmanaged. CS>>>Я имплементировал оба варианта (в D и в C++) поэтому знаю достоверно. CS>>>Единственно в случае reference counting каждый node должен иметь поле ref_counter. Но этот overhead он опять же а) детерминирован и б) явно меньше в целом чем overhead managed heap. G>> G>>И какой оверхед по памяти у manаged heap?
CS>managed heap отбирает у системы памяти заведомо больше чем нужно для представления объектов. CS>Как правило чтобы GC себя комфортно чувствовал он должен у системы отобрать в два раза больше памяти чем нужно. CS>Т.е. если у тебя есть скажем DOM tree в памяти то managed heap'у нужен space в два раза больше.
Ну это бред. Может у тебя пруфлинк есть, подтверждающий твои слова?
CS>Если же размер heap равен размеру этого самого DOM tree то каждая следующая аллокация будет приводить к полномоу GC. Т.е. O(N) операция.
Тоже бред.
CS>Что явно больше чем в C heap где аллокация стоит от O(1) до O(log(N)) (очень крайний случай).
Что такое C heap? Вот компилятор MS использует виндовый хип, который еще пару лет назад был очень даже O(N). GCC видел очень давно, но там тоже ,sk хип с асимптотикой O(N)
CS>>>managed heap отлично справляется с аллокацией мелких объектов. Инкремент указателя фактически. Но на предаврительно и с большим запасом отобранной у системы памяти прошу заметить. G>>Во-первых зачем она системе? Во-вторых зачем заранее отбирать у системы больше памяти?
CS>Почитай основы GC, скажем http://en.wikipedia.org/wiki/Garbage_collection_(computer_science)#Implementation_strategies
Думаешь я не знаю как работает GC?
CS>Аллокация в GC heap дешевая только тогда когда она сводится к alloactedPtr += requiredSize. Этот alloactedPtr указывает на позицию в буффере — CS>фрагменту RAM предварительно отобранных у системы "про запас".
Ты про mem_reserve не слышал чтоли?
CS>>>Но вот когда дело доходит до GC... GС цикл как ты понимаешь это O(N) операция. Т.е. чем больше у тебя объектов тем больше ему работы. CS>>>Странно, я думал это очевидно. G>>Ниче что аллокация и освобождение памяти в unmanaged heap чаще всего тоже O(N)? (правда там N разные)
CS>Тебя обманули. Освобождение памяти в unmanaged heap это опреация O(1) — удалить элемент из одного двухсвязанного списка и поместить в другой (free blocks list). Если при этом еще исполняется объединение блоков то больше чем O(1). То же самое или близкое к тому и с выделением.
Даже если использовать двусвязный список все равно выделение будет (N). Кроме того двусвязный список дает больший оверхед.
CS>Основная проблема в unmanaged heap это проблема фрагментации. Но это другая история.
Основная проблема unmanaged heap в том что этот хип unmanaged. Единственное преимущество, которое потенциально можно получить, это использование оптимальной для задачи стратегии выделения и освобождения памяти.
G>>Ниче что конкретная реализация heap в windows сосет на массовых выделениях-освобождениях памяти по сравнению с .NET GC? G>>Это еще refcounting никто там не занимался. G>>Ты такие наивные глупости говоришь.
CS> Я не один такие глупости говорю. Скажем разработчики Windows не стали писать систему на .NET. Хотя у них все инструменты есть для этого.
Снова наивные глупости. Цена переписывания во много раз больше выгод от этого.
CS>А вопрос что лучше managed или non-managed heap он имеет ту же ценность что и "мальчик, ты кого больше любишь — маму или папу?" CS>Т.е. и то и то хорошо если употреблено по делу — а не квадратно-гнездовым образом. Silver bullets их таки нет, да.
Когда начинают говорить о refcounting как раз GC становится "по делу".
CS>В прошлую среду кстати был в Evernote. Они сделали попытку написать Evernote 3.5 в WPF/.NET. CS>Дело закончилось Evernote 4.0 как сугубо native application.
Ну видимо ниасилили.
CS>>>У меня есть конкретные примеры. Sciter есть система в которой используется и детерминированый heap и managed (TIScript VM). Там где они нужны и оптимальны. G>>Докажи выделенное. CS>Что конкретно доказать осталось?
Оптимальность.
Здравствуйте, gandjustas, Вы писали:
CS>>managed heap отбирает у системы памяти заведомо больше чем нужно для представления объектов. CS>>Как правило чтобы GC себя комфортно чувствовал он должен у системы отобрать в два раза больше памяти чем нужно. CS>>Т.е. если у тебя есть скажем DOM tree в памяти то managed heap'у нужен space в два раза больше. G>Ну это бред. Может у тебя пруфлинк есть, подтверждающий твои слова?
Аккуратнее со словами если хочешь чтобы тебя уважали в профессиональной среде.
Вот тебе основы: http://chaoticjava.com/posts/how-does-garbage-collection-work/
Если облом читать то можешь послушать например здесь как устроен heap/GC в V8 от Google: http://www.youtube.com/watch?v=FrufJFBSoQY
Как минимум young generation heap состоит из двух половин одна из которых не используется в отдельно взятый момент времени.
CS>>Что явно больше чем в C heap где аллокация стоит от O(1) до O(log(N)) (очень крайний случай). G>Что такое C heap? Вот компилятор MS использует виндовый хип, который еще пару лет назад был очень даже O(N). GCC видел очень давно, но там тоже ,sk хип с асимптотикой O(N)
О, а это еще откуда? И что здесь есть N ? В managed heap N это общее количество аллоцированных (т.е. managed) объектов.
N можно сократить за счет generations но не сильно. Но в теории GC это всегда O(N). Если тебе известен другой способ — ссылку приведи.
Вот тебе имплементация быстрого thread local allocator http://www.garret.ru/threadalloc/readme.html от Константина Книжника.
Там все просто и прозрачно. Можно посмотреть Doug Lee malloc. В целом работа malloc() и free() функций в C/C++ не зависит от количества аллоцированных объектов. Вернее если и зависит то весьма незанчительно. Во всяком случае далеко не O(N).
CS>>>>managed heap отлично справляется с аллокацией мелких объектов. Инкремент указателя фактически. Но на предаврительно и с большим запасом отобранной у системы памяти прошу заметить. G>>>Во-первых зачем она системе? Во-вторых зачем заранее отбирать у системы больше памяти?
CS>>Почитай основы GC, скажем http://en.wikipedia.org/wiki/Garbage_collection_(computer_science)#Implementation_strategies G>Думаешь я не знаю как работает GC?
Судя по твоей бурной реакции я подозреваю что нет.
CS>>Аллокация в GC heap дешевая только тогда когда она сводится к alloactedPtr += requiredSize. Этот alloactedPtr указывает на позицию в буффере — CS>>фрагменту RAM предварительно отобранных у системы "про запас". G>Ты про mem_reserve не слышал чтоли?
Если mem_reserve это MEM_RESERVE то упоминание этого флага можно найти здесь: http://code.google.com/p/tiscript/source/browse/trunk/int/cs_heap.cpp
Это код моего TIScript. (Credits for VirtalAlloc there go to Дмитрий Якимов)
G>>>Ниче что аллокация и освобождение памяти в unmanaged heap чаще всего тоже O(N)? (правда там N разные)
CS>>Тебя обманули. Освобождение памяти в unmanaged heap это опреация O(1) — удалить элемент из одного двухсвязанного списка и поместить в другой (free blocks list). Если при этом еще исполняется объединение блоков то больше чем O(1). То же самое или близкое к тому и с выделением. G>Даже если использовать двусвязный список все равно выделение будет (N). Кроме того двусвязный список дает больший оверхед.
О как. Ну глянь в исходники по ссылкам вверху. Покажи мне то место где "выделение будет (N)".
CS>>Основная проблема в unmanaged heap это проблема фрагментации. Но это другая история. G>Основная проблема unmanaged heap в том что этот хип unmanaged. Единственное преимущество, которое потенциально можно получить, это использование оптимальной для задачи стратегии выделения и освобождения памяти.
Ну дык и я о чем говорю? Есть задачи для которых non-managed heap оптимален и есть задачи для которых managed heap — самое оно.
Истина в том что ты должен иметь возможность выбирать оптимальный heap manager для конкретной подсистемы.
Если кто-то говорит "мы все будем писать managed" то на таком проекте можно ставить крест. Ибо посыл неверный.
G>>>Ниче что конкретная реализация heap в windows сосет на массовых выделениях-освобождениях памяти по сравнению с .NET GC? G>>>Это еще refcounting никто там не занимался. G>>>Ты такие наивные глупости говоришь.
CS>> Я не один такие глупости говорю. Скажем разработчики Windows не стали писать систему на .NET. Хотя у них все инструменты есть для этого. G>Снова наивные глупости. Цена переписывания во много раз больше выгод от этого.
Тем не менее WP7 была переписана несмотря на цену. Но IE там кстати нативный.
CS>>А вопрос что лучше managed или non-managed heap он имеет ту же ценность что и "мальчик, ты кого больше любишь — маму или папу?" CS>>Т.е. и то и то хорошо если употреблено по делу — а не квадратно-гнездовым образом. Silver bullets их таки нет, да. G>Когда начинают говорить о refcounting как раз GC становится "по делу".
Одна из форм GC есть ref counting. Т.е. что ты имеешь ввиду?
CS>>В прошлую среду кстати был в Evernote. Они сделали попытку написать Evernote 3.5 в WPF/.NET. CS>>Дело закончилось Evernote 4.0 как сугубо native application. G>Ну видимо ниасилили.
Искренне желаю тебе достичь их уровня.
CS>>>>У меня есть конкретные примеры. Sciter есть система в которой используется и детерминированый heap и managed (TIScript VM). Там где они нужны и оптимальны. G>>>Докажи выделенное. CS>>Что конкретно доказать осталось? G>Оптимальность.
Здравствуйте, gandjustas, Вы писали:
CS>>Т.е. если у тебя есть скажем DOM tree в памяти то managed heap'у нужен space в два раза больше. G>Ну это бред. Может у тебя пруфлинк есть, подтверждающий твои слова?
Это известный практический результат. Хороший GC работает так же быстро, как и ручное управление памятью, но требует в 2-5 раз больше памяти.
CS>>Если же размер heap равен размеру этого самого DOM tree то каждая следующая аллокация будет приводить к полномоу GC. Т.е. O(N) операция. G>Тоже бред.
Ничуть. Сложность GC — это O(N), где N — это количество выживших объектов (в лучшем случае).
CS>>Что явно больше чем в C heap где аллокация стоит от O(1) до O(log(N)) (очень крайний случай). G>Что такое C heap? Вот компилятор MS использует виндовый хип, который еще пару лет назад был очень даже O(N). GCC видел очень давно, но там тоже ,sk хип с асимптотикой O(N)
Никогда он не был таким. Там всегда было амортизованное O(1).
CS>>Почитай основы GC, скажем http://en.wikipedia.org/wiki/Garbage_collection_(computer_science)#Implementation_strategies G>Думаешь я не знаю как работает GC?
Видимо.
CS>>Аллокация в GC heap дешевая только тогда когда она сводится к alloactedPtr += requiredSize. Этот alloactedPtr указывает на позицию в буффере — CS>>фрагменту RAM предварительно отобранных у системы "про запас". G>Ты про mem_reserve не слышал чтоли?
Не получится, большая часть памяти один фиг закоммитится.
CS>>>>У меня есть конкретные примеры. Sciter есть система в которой используется и детерминированый heap и managed (TIScript VM). Там где они нужны и оптимальны. G>>>Докажи выделенное. CS>>Что конкретно доказать осталось? G>Оптимальность.
Практика...
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, gandjustas, Вы писали:
CS>>>managed heap отбирает у системы памяти заведомо больше чем нужно для представления объектов. CS>>>Как правило чтобы GC себя комфортно чувствовал он должен у системы отобрать в два раза больше памяти чем нужно. CS>>>Т.е. если у тебя есть скажем DOM tree в памяти то managed heap'у нужен space в два раза больше. G>>Ну это бред. Может у тебя пруфлинк есть, подтверждающий твои слова?
CS>Аккуратнее со словами если хочешь чтобы тебя уважали в профессиональной среде.
CS>Вот тебе основы: CS>http://chaoticjava.com/posts/how-does-garbage-collection-work/ CS>Если облом читать то можешь послушать например здесь как устроен heap/GC в V8 от Google: CS>http://www.youtube.com/watch?v=FrufJFBSoQY CS>Как минимум young generation heap состоит из двух половин одна из которых не используется в отдельно взятый момент времени.
1)MEM_RESERVE. память не обязательно отбирать у кого-либо до того как она будет использована.
2)Каков размер этого young generation heap? Я так понимаю даже мегабайта не будет.
CS>>>Что явно больше чем в C heap где аллокация стоит от O(1) до O(log(N)) (очень крайний случай). G>>Что такое C heap? Вот компилятор MS использует виндовый хип, который еще пару лет назад был очень даже O(N). GCC видел очень давно, но там тоже ,sk хип с асимптотикой O(N)
CS>О, а это еще откуда? И что здесь есть N ? В managed heap N это общее количество аллоцированных (т.е. managed) объектов. CS>N можно сократить за счет generations но не сильно. Но в теории GC это всегда O(N). Если тебе известен другой способ — ссылку приведи.
Для GC N — количество живых объектов. Для list-based алокатора N может быть количество выделенных блоков или количеством свободных блоков (эти величины линейно зависимы)
CS>Вот тебе имплементация быстрого thread local allocator http://www.garret.ru/threadalloc/readme.html от Константина Книжника. CS>Там все просто и прозрачно. Можно посмотреть Doug Lee malloc. В целом работа malloc() и free() функций в C/C++ не зависит от количества аллоцированных объектов. Вернее если и зависит то весьма незанчительно. Во всяком случае далеко не O(N).
Если не O(N) тогда оверхед по памяти большой. Например на выделение блоков по 68 байт будут реально расходоваться блоки по 128.
CS>>>>>managed heap отлично справляется с аллокацией мелких объектов. Инкремент указателя фактически. Но на предаврительно и с большим запасом отобранной у системы памяти прошу заметить. G>>>>Во-первых зачем она системе? Во-вторых зачем заранее отбирать у системы больше памяти?
CS>>>Почитай основы GC, скажем http://en.wikipedia.org/wiki/Garbage_collection_(computer_science)#Implementation_strategies G>>Думаешь я не знаю как работает GC? CS>Судя по твоей бурной реакции я подозреваю что нет.
Где ты увидел бурную реакцию?
CS>>>Аллокация в GC heap дешевая только тогда когда она сводится к alloactedPtr += requiredSize. Этот alloactedPtr указывает на позицию в буффере — CS>>>фрагменту RAM предварительно отобранных у системы "про запас". G>>Ты про mem_reserve не слышал чтоли?
CS>Если mem_reserve это MEM_RESERVE то упоминание этого флага можно найти здесь: CS>http://code.google.com/p/tiscript/source/browse/trunk/int/cs_heap.cpp CS>Это код моего TIScript. (Credits for VirtalAlloc there go to Дмитрий Якимов)
Ну так ты понял что заранее отбирать не надо?
G>>>>Ниче что аллокация и освобождение памяти в unmanaged heap чаще всего тоже O(N)? (правда там N разные)
CS>>>Тебя обманули. Освобождение памяти в unmanaged heap это опреация O(1) — удалить элемент из одного двухсвязанного списка и поместить в другой (free blocks list). Если при этом еще исполняется объединение блоков то больше чем O(1). То же самое или близкое к тому и с выделением. G>>Даже если использовать двусвязный список все равно выделение будет (N). Кроме того двусвязный список дает больший оверхед.
CS>О как. Ну глянь в исходники по ссылкам вверху. Покажи мне то место где "выделение будет (N)".
Там выделение с O(1) за счет оверхеда по памяти. Чудес не бывает, есть tradeoffs, где-то они уместны, а где-то нет.
CS>>>Основная проблема в unmanaged heap это проблема фрагментации. Но это другая история. G>>Основная проблема unmanaged heap в том что этот хип unmanaged. Единственное преимущество, которое потенциально можно получить, это использование оптимальной для задачи стратегии выделения и освобождения памяти.
CS>Ну дык и я о чем говорю? Есть задачи для которых non-managed heap оптимален и есть задачи для которых managed heap — самое оно.
Не бывает в общем случае оптимального unmanaged heap, можно сделать свой хип, оптимальный для конкретной задачи.
CS>Истина в том что ты должен иметь возможность выбирать оптимальный heap manager для конкретной подсистемы.
Да ну, 90% приложений вполне успешно будут работать с GC.
G>>>>Ниче что конкретная реализация heap в windows сосет на массовых выделениях-освобождениях памяти по сравнению с .NET GC? G>>>>Это еще refcounting никто там не занимался. G>>>>Ты такие наивные глупости говоришь.
CS>>> Я не один такие глупости говорю. Скажем разработчики Windows не стали писать систему на .NET. Хотя у них все инструменты есть для этого. G>>Снова наивные глупости. Цена переписывания во много раз больше выгод от этого.
CS>Тем не менее WP7 была переписана несмотря на цену. Но IE там кстати нативный.
Куда переписана? Внутри там Windows CE новой версии и .NET CF. Это для разработчиков API на XNA и SL.
Как раз для того чтобы каждый кто умеет программить на C# смог писать для WP7, они об этом в открытую говорят.
CS>>>А вопрос что лучше managed или non-managed heap он имеет ту же ценность что и "мальчик, ты кого больше любишь — маму или папу?" CS>>>Т.е. и то и то хорошо если употреблено по делу — а не квадратно-гнездовым образом. Silver bullets их таки нет, да. G>>Когда начинают говорить о refcounting как раз GC становится "по делу". CS>Одна из форм GC есть ref counting. Т.е. что ты имеешь ввиду?
Да, только в нем есть критические недостатки.
CS>>>>>У меня есть конкретные примеры. Sciter есть система в которой используется и детерминированый heap и managed (TIScript VM). Там где они нужны и оптимальны. G>>>>Докажи выделенное. CS>>>Что конкретно доказать осталось? G>>Оптимальность.
CS>Оптимальность для какой задачи?
Для того же дерева, dom или еще ченить.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
CS>>>Т.е. если у тебя есть скажем DOM tree в памяти то managed heap'у нужен space в два раза больше. G>>Ну это бред. Может у тебя пруфлинк есть, подтверждающий твои слова? C>Это известный практический результат. Хороший GC работает так же быстро, как и ручное управление памятью, но требует в 2-5 раз больше памяти.
В среднем — да, потому что освобождение позже происходит. Но "метрвые" объекты нас не интересуют, они могу даже в своп уходить и на работе приложения это не скажется. А вот для живых объектов выделяется столько памяти сколько нужно.
CS>>>Если же размер heap равен размеру этого самого DOM tree то каждая следующая аллокация будет приводить к полномоу GC. Т.е. O(N) операция. G>>Тоже бред. C>Ничуть. Сложность GC — это O(N), где N — это количество выживших объектов (в лучшем случае).
Я про выделенное.
CS>>>Что явно больше чем в C heap где аллокация стоит от O(1) до O(log(N)) (очень крайний случай). G>>Что такое C heap? Вот компилятор MS использует виндовый хип, который еще пару лет назад был очень даже O(N). GCC видел очень давно, но там тоже ,sk хип с асимптотикой O(N) C>Никогда он не был таким. Там всегда было амортизованное O(1).
Да ну?
CS>>>>>У меня есть конкретные примеры. Sciter есть система в которой используется и детерминированый heap и managed (TIScript VM). Там где они нужны и оптимальны. G>>>>Докажи выделенное. CS>>>Что конкретно доказать осталось? G>>Оптимальность. C>Практика...
Какая практика? Практика как раз показывает что в сложных системах GC рулит, а на unmanaged то утечки, то расстрелы, то тормоза.
Естественно это касается средних программистов, а не супер-гениев.
Здравствуйте, gandjustas, Вы писали:
C>>Это известный практический результат. Хороший GC работает так же быстро, как и ручное управление памятью, но требует в 2-5 раз больше памяти. G>В среднем — да, потому что освобождение позже происходит. Но "метрвые" объекты нас не интересуют, они могу даже в своп уходить и на работе приложения это не скажется. А вот для живых объектов выделяется столько памяти сколько нужно.
Не могут. Приложения с GC совершенно не дружат со свопом. Молодые поколения слишком "горячие" для свопа, а если засвопить старое поколоение, то первый же full scan убивает систему, да проверка обратных ссылкок из старшего поколения тоже не сахар.
Точнее, есть swap-friendly алгоритмы, но у них свои недостатки. В G1GC что-то на эту тему есть, надо почитать...
CS>>>>Если же размер heap равен размеру этого самого DOM tree то каждая следующая аллокация будет приводить к полномоу GC. Т.е. O(N) операция. G>>>Тоже бред. C>>Ничуть. Сложность GC — это O(N), где N — это количество выживших объектов (в лучшем случае). G>Я про выделенное.
Почему? Это вполне реальный вырожденный случай. Скажем, Java в таких случаях после пары минут работы падает с исключением, что максимальная доля времени GC превышена.
CS>>>>Что явно больше чем в C heap где аллокация стоит от O(1) до O(log(N)) (очень крайний случай). G>>>Что такое C heap? Вот компилятор MS использует виндовый хип, который еще пару лет назад был очень даже O(N). GCC видел очень давно, но там тоже ,sk хип с асимптотикой O(N) C>>Никогда он не был таким. Там всегда было амортизованное O(1). G>Да ну?
Ну да. Читай исходники, они рулез.
CS>>>>Что конкретно доказать осталось? G>>>Оптимальность. C>>Практика... G>Какая практика? Практика как раз показывает что в сложных системах GC рулит, а на unmanaged то утечки, то расстрелы, то тормоза.
Руки надо править, значит. GC хорош для сложных модульных приложений, где схема владения объектами неясна.
Здравствуйте, gandjustas, Вы писали:
g> CS>Вот тебе имплементация быстрого thread local allocator http://www.garret.ru/threadalloc/readme.html от Константина Книжника. g> CS>Там все просто и прозрачно. Можно посмотреть Doug Lee malloc. В целом работа malloc() и free() функций в C/C++ не зависит от количества аллоцированных объектов. Вернее если и зависит то весьма незанчительно. Во всяком случае далеко не O(N).
g> Если не O(N) тогда оверхед по памяти большой. Например на выделение блоков по 68 байт будут реально расходоваться блоки по 128.
Не гони. Никто не будет делать пулы с блоками дающими 50% оверхед. У дельфийского fastmm градация пулов для мелких (<= 156) блоков всего 8 байт, потом (<= 348) 16 байт, затем 32 байта и т.д. (но градация не в геометрической прогрессии), чем больше градация тем меньше пулов на этом промежутке. У fastmm всего 55 пулов, плюс 2 пула для средних и больших (> 256Kb) блоков. Я тебе уже как то говорил, что в работающем, нагруженном delphi-приложении эффективность расходования памяти составляет 95% (это мониторится средствами самого fastmm).
Здравствуйте, hattab, Вы писали:
H>Не гони. Никто не будет делать пулы с блоками дающими 50% оверхед. У дельфийского fastmm градация пулов для мелких (<= 156) блоков всего 8 байт, потом (<= 348) 16 байт, затем 32 байта и т.д. (но градация не в геометрической прогрессии), чем больше градация тем меньше пулов на этом промежутке. У fastmm всего 55 пулов, плюс 2 пула для средних и больших (> 256Kb) блоков. Я тебе уже как то говорил, что в работающем, нагруженном delphi-приложении эффективность расходования памяти составляет 95% (это мониторится средствами самого fastmm).
Мы делали на своем аллакаторе сбор статистики и по результатам прогонов на реальных данных корректировали размеры блоков и пулов, оверхед максимум 10% получался. Кстати на мелких объектах (4 — 16 байт) памяти кушалось меньше чем стандартным аллакатором.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
g>> CS>Вот тебе имплементация быстрого thread local allocator http://www.garret.ru/threadalloc/readme.html от Константина Книжника. g>> CS>Там все просто и прозрачно. Можно посмотреть Doug Lee malloc. В целом работа malloc() и free() функций в C/C++ не зависит от количества аллоцированных объектов. Вернее если и зависит то весьма незанчительно. Во всяком случае далеко не O(N).
g>> Если не O(N) тогда оверхед по памяти большой. Например на выделение блоков по 68 байт будут реально расходоваться блоки по 128.
H>Не гони. Никто не будет делать пулы с блоками дающими 50% оверхед. У дельфийского fastmm градация пулов для мелких (<= 156) блоков всего 8 байт, потом (<= 348) 16 байт, затем 32 байта и т.д. (но градация не в геометрической прогрессии), чем больше градация тем меньше пулов на этом промежутке. У fastmm всего 55 пулов, плюс 2 пула для средних и больших (> 256Kb) блоков. Я тебе уже как то говорил, что в работающем, нагруженном delphi-приложении эффективность расходования памяти составляет 95% (это мониторится средствами самого fastmm).
Здравствуйте, Sheridan, Вы писали:
S>Приветствую! S>Чтото я не понял что МС собирается с сильверлайтом сделать? Примораживают разработку в пользу хтмл5? S>Я просто в англицком не очень...
Так и есть. Флеш простудится на похоронах Сильверлайта.
Здравствуйте, Niemand, Вы писали:
VV>>Не понятно откуда вы это взяли. Написано англиским по белому. Сильверлайт никто не кидает, но в связи с выходом html5 сменился фокус на реально кроссплатформенную платформу ( ). А сильверлайт так и остается.
N>макрос "а Х так и остается" — один из любимых у майкрософта. Лично я утратил веру когда они выпустили бэту winFS, а потом сказали "а winFS так и остается, только войдет в другие проекты, а не будет самостоятельным продуктом". И ни гу-гу с тех времен. Вот и сильвер для веба "так и остается"
Из ВинФС к нам пришли FILESTREAM блобы в SQL 2008!
И по мелочевке в Win7 типа libraries.
Здравствуйте, c-smile, Вы писали:
CS>Но вот что интересно. Примерно на одном и том же железе iPhone (native code) как-то по ощущениям лучше работатет чем Android (Java). CS>В свете последних событий я так понимаю Oracle дожмет Google и последний будет вынужден перейти на Android на С или что-то близкое ему.
Здравствуйте, midcyber, Вы писали:
M>Только пацанам не говори, что у них в социальных сетях весь медиаконтент на флеше, ок?
Социальные сети от порнобаннеров не далеко ушли.
Здравствуйте, gandjustas, Вы писали:
G>Ниче что аллокация и освобождение памяти в unmanaged heap чаще всего тоже O(N)?
Опять ты гонишь пургу? В каком это промышленном unmanaged heap операции O(N)?
G>(правда там N разные)
Чего???
G>Ниче что конкретная реализация heap в windows сосет на массовых выделениях-освобождениях памяти по сравнению с .NET GC?
Ты смотри, уже научился хоть где то не писать фигню про generic аллокатор.
G>Ты такие наивные глупости говоришь.
В плане знаний об unmanaged ты ничуть не отстаёшь.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, gandjustas, Вы писали:
CS>>Что явно больше чем в C heap где аллокация стоит от O(1) до O(log(N)) (очень крайний случай). G>Что такое C heap? Вот компилятор MS использует виндовый хип, который еще пару лет назад был очень даже O(N). GCC видел очень давно, но там тоже ,sk хип с асимптотикой O(N)
Пару лет это 2 года.
Тот же LFH появился в WinXP, т.е. в 2002м году. Т.е. 8 лет назад уже в винде аллокация была на пулах.
CS>>Тебя обманули. Освобождение памяти в unmanaged heap это опреация O(1) — удалить элемент из одного двухсвязанного списка и поместить в другой (free blocks list). Если при этом еще исполняется объединение блоков то больше чем O(1). То же самое или близкое к тому и с выделением. G>Даже если использовать двусвязный список все равно выделение будет (N). Кроме того двусвязный список дает больший оверхед.
Иди учи алгоритмы. Или ты кроме тупого перебора никаких других алгоритмов выбора оптимального блока не знаешь?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, olegkr, Вы писали:
M>>Только пацанам не говори, что у них в социальных сетях весь медиаконтент на флеше, ок? O>Социальные сети от порнобаннеров не далеко ушли.
Ну тогда не говори, что "Флеш уже сдох везде". Не сдох, и в ближайшее время, похоже, не сдохнет. Смартклиенты, сильверлайты, вэпээфы и джава эфиксы приходят и уходят, в флеш-курилка жив, только простужается иногда на похоронах очередных "убиец флеша".
Здравствуйте, WolfHound, Вы писали:
CS>>Скажем если на Android кто-то сделает killer app использующий native code (там это возможно) то WP7 будет с этим соревноваться трудно. CS>>Т.е. пока managed код работает как клей между native functions — все OK. А как что-то серьёзное ... WH> Ты не путай интерпритаторы динамически типизированных скриптов и компилируемый код.
С появлением Tracing JIT компиляторов джаваскрипта разница уже не так очевидна, по крайней мере в плане производительности.
Вчера по ящику видел интервью Чубайса на фоне стенки с логотипом Роснано. Думал-думал, что же мне это логотип напоминает... Сегодня вспомнил! Это же сервелат
H>Вчера по ящику видел интервью Чубайса на фоне стенки с логотипом Роснано. Думал-думал, что же мне это логотип напоминает... Сегодня вспомнил! Это же сервелат
H>Смотрите сами, меня широко улыбнуло
H> H>
Я не Лебедев, но со всей ответственностью заявляю, что по сравнению с лого СЛ, логотип РН — беспросветное говно.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
