Здравствуйте, Кэр, Вы писали:
Кэр>Здравствуйте, 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>Что конкретно доказать осталось?
Оптимальность.
Ты не путай интерпритаторы динамически типизированных скриптов и компилируемый код.
