Андроид + C# = love?
02.05.2012
|
Ночной Смотрящий |
Интересная новость:
http://blog.xamarin.com/2012/05/01/android-in-c-sharp/
Вкратце: товарищи их Xamarin выкинули из андроида Dalvik и весь жабий код портанули на C#. Ну и вкрячили в андроид вместо далвика моно. Полученный перформанс некоторых структур данных:
Let the Combat begin?
http://blog.xamarin.com/2012/05/01/android-in-c-sharp/
Вкратце: товарищи их Xamarin выкинули из андроида Dalvik и весь жабий код портанули на C#. Ну и вкрячили в андроид вместо далвика моно. Полученный перформанс некоторых структур данных:
Let the Combat begin?
02.05.2012 105 комментариев |
НС>Вкратце: товарищи их Xamarin выкинули из андроида Dalvik и весь жабий код портанули на C#. Ну и вкрячили в андроид вместо далвика моно. Полученный перформанс некоторых структур данных:
НС>Let the Combat begin?
Не, какой combat? Они сравнивают с Dalvik'овым кодом, который был оптимизирован на быстрый запуск, небольшое потребление по памяти и низкий оверхед сбощика мусора.
Тогда как Mono до сих пор использует консервативный GC. Epic fail.
C>Тогда как Mono до сих пор использует консервативный GC.
SGen вроде как довольно давно доступен
C> Epic fail.
Ну так напиши свой тест и продемонстрируй крутость Далвика, делов то.
C>>Тогда как Mono до сих пор использует консервативный GC.
НС>SGen вроде как довольно давно доступен
Он полуконсервативен. Стековые карты для нативных потоков не строятся, к примеру.
C>> Epic fail.
НС>Ну так напиши свой тест и продемонстрируй крутость Далвика, делов то.
Так он не для скорости создавался.
C>Он полуконсервативен. Стековые карты для нативных потоков не строятся, к примеру.
MONO_GC_PARAMS=stack-mark=precise
C>>> Epic fail.
НС>>Ну так напиши свой тест и продемонстрируй крутость Далвика, делов то.
C>Так он не для скорости создавался.
Ага, и не для экономии батарейки.
C>>Он полуконсервативен. Стековые карты для нативных потоков не строятся, к примеру.
НС>MONO_GC_PARAMS=stack-mark=precise
Пофиг. Нативные фреймы — всё равно консервативные. В результате, тучи pinned-объектов.
НС>>>Ну так напиши свой тест и продемонстрируй крутость Далвика, делов то.
C>>Так он не для скорости создавался.
НС>Ага, и не для экономии батарейки.
Да ну? Именно для этого. Ну и ещё для быстрого запуска.
C>Да ну? Именно для этого. Ну и ещё для быстрого запуска.
Видишь ли какое дело — со стороны Xamarin хоть какие то тесты есть, а с твоей одни пустые слова. Так что я пока лучше им поверю.
C>>Да ну? Именно для этого. Ну и ещё для быстрого запуска.
НС>Видишь ли какое дело — со стороны Xamarin хоть какие то тесты есть, а с твоей одни пустые слова. Так что я пока лучше им поверю.
О чём? О том что Dalvik — это не самая быстрая реализация JVM?
Так с этим никто не спорит — до версии 2.1 он был чистым интерпретатором. В версии 2.2 его JIT занимал 100Кб кода и примерно столько же RAM ( http://android-developers.blogspot.com/2010/05/dalvik-jit.html ).
Скажем, Java SE embedded типично в 2-3 раза быстрее Dalvik'а:
https://blogs.oracle.com/javaseembedded/entry/how_does_android_22s_performance_stack_up_against_java_se_embedded при том, что сама SE Embedded — тот ещё тормоз.
C>>> Epic fail.
НС>>Ну так напиши свой тест и продемонстрируй крутость Далвика, делов то.
C>Так он не для скорости создавался.
Ну то есть в мобайле он и нахрен не упал.
НС>>>Ну так напиши свой тест и продемонстрируй крутость Далвика, делов то.
C>>Так он не для скорости создавался.
I>Ну то есть в мобайле он и нахрен не упал.
Как раз для мобайла. Так как скорость можно достичь и нативным кодом, когда это нужно. Для Дэлвика была важна скорость запуска и экономия памяти.
C>Как раз для мобайла. Так как скорость можно достичь и нативным кодом, когда это нужно. Для Дэлвика была важна скорость запуска и экономия памяти.
ИМХО нативный код в андроиде это не от хорошей жизни, а вынужденная мера. Тормозной далвик вынудил гугл выпустить костыль в виде NDK. Который как раз (цитирую wiki) "рекомендуется использовать для разработки участков кода критичных к скорости."
C>>Как раз для мобайла. Так как скорость можно достичь и нативным кодом, когда это нужно. Для Дэлвика была важна скорость запуска и экономия памяти.
S>ИМХО нативный код в андроиде это не от хорошей жизни, а вынужденная мера. Тормозной далвик вынудил гугл выпустить костыль в виде NDK. Который как раз (цитирую wiki) "рекомендуется использовать для разработки участков кода критичных к скорости."
Ага. Именно поэтому Скайп на WP7 использует секретные нативные API MS.
Гугл вполне логично решил использовать Яву в качестве клеевого языка, а не заниматься ерундой.
C>Не, какой combat? Они сравнивают с Dalvik'овым кодом, который был оптимизирован на быстрый запуск, небольшое потребление по памяти и низкий оверхед сбощика мусора.
C>Тогда как Mono до сих пор использует консервативный GC. Epic fail.
ну конечно, про любимую жабу ничего плохого сказать невозможно. только вот потребление памяти на деле такое же как потребление батареи, а что было до 2.2 так вообще — свят-свят-свят
о_О>ну конечно, про любимую жабу
оракл с вами сурово не согласен и подаст в суд за называние андройда жабой.
D>Здравствуйте, о_О, Вы писали:
о_О>>ну конечно, про любимую жабу
D>оракл с вами сурово не согласен и подаст в суд за называние андройда жабой.
Ох, что же мне делать?! Снимаю штаны и начинаю бегать.
C>>Не, какой combat? Они сравнивают с Dalvik'овым кодом, который был оптимизирован на быстрый запуск, небольшое потребление по памяти и низкий оверхед сбощика мусора.
C>>Тогда как Mono до сих пор использует консервативный GC. Epic fail.
о_О>ну конечно, про любимую жабу ничего плохого сказать невозможно.
Можно. Но по сути.
о_О>только вот потребление памяти на деле такое же как потребление батареи, а что было до 2.2 так вообще — свят-свят-свят
Что за сказки? Первый Андроидный телефон имел 64Мб полной памяти. У моновских товарищей туда бы и система не поместилась даже.
C>Тогда как Mono до сих пор использует консервативный GC. Epic fail.
Точный так и не появился?
C>>Тогда как Mono до сих пор использует консервативный GC. Epic fail.
P>Точный так и не появился?
Нет. Тогда это оказалось нереально из-за гигантского количества кода, написанного в рассчёте на консервативный GC. Я пообщался с их командой и им это было на тот момент неинтересно — у них были другие приоритеты.
Потом до них дошло, что консервный GC — не очень хорошая идея, особенно в больших приложениях. И они начали постепенное переписывание груд нативного кода на точный GC, но этот проект не завершён до сих пор.
НС>Вкратце: товарищи их Xamarin выкинули из андроида Dalvik и весь жабий код портанули на C#. Ну и вкрячили в андроид вместо далвика моно. Полученный перформанс некоторых структур данных:
НС>...
НС>Let the Combat begin?
Не, комбат не нужен — на картинке и так понятно, при каких обстоятельствах один рантайм
лучше другого. Я когда-то писал "порт" LINQ to Objects на Java без методов расширения,
но с fluent interface с помощью врапперов (во!), но этот ужасный боксинг примитивов
и джавишные дженерики... А так, конечно же, весьма и весьма круто.
НС>Вкратце: товарищи их Xamarin выкинули из андроида Dalvik и весь жабий код портанули на C#. Ну и вкрячили в андроид вместо далвика моно. Полученный перформанс некоторых структур данных:
НС>http://tirania.org/s/71de890b.png
Imho товарищи из Xamarin хорошо начали как pet project, теперь они нанимают народ и делают провокационные заявления. Подозреваю, что денег нанимать народ им привалило не с продаж, а от Балмера- потроллить Брина. Закончить они имеют все шансы как Flex для iPhone- ведь яблочники забанили сначала жаву, потом flex. Забанить mono.touch в следующей версии iOS им раз плюнуть.
НС>Let the Combat begin?
Лучше бы они выпустили конвертор андроидного apk в пакет для винфона с полной трансляцией p-кода и без жирного рантайма оберток.
AG>Здравствуйте Ночной Смотрящий, Вы писали:
НС>>Вкратце: товарищи их Xamarin выкинули из андроида Dalvik и весь жабий код портанули на C#. Ну и вкрячили в андроид вместо далвика моно. Полученный перформанс некоторых структур данных:
НС>>http://tirania.org/s/71de890b.png
AG>Imho товарищи из Xamarin хорошо начали как pet project, теперь они нанимают народ и делают провокационные заявления. Подозреваю, что денег нанимать народ им привалило не с продаж, а от Балмера- потроллить Брина. Закончить они имеют все шансы как Flex для iPhone- ведь яблочники забанили сначала жаву, потом flex. Забанить mono.touch в следующей версии iOS им раз плюнуть.
НС>>Let the Combat begin?
AG>Лучше бы они выпустили конвертор андроидного apk в пакет для винфона с полной трансляцией p-кода и без жирного рантайма оберток.
Про забаненность флекса можно поподробнее?
Вроде всё ставится, игры типа машинариума в магазине верхние строчки недавно имели и всё такое.
AG> Да, я не знал. Думал что Flex уже похоронили. Это еще один аргумент за то, для C# на андроиде ниши нет. Хотя на жаве лепить формы для андроида мне показалось проще, чем с flex и с javafx 2 (писал на обоих под десктоп).
Вах, дарагой, фикси, однако, клиента...
H>Вах, дарагой, фикси, однако, клиента...
[offtop] Да уж. Это от плохой связи случается. Попробую выискивать собственное сообщение в полученных перед повторной попыткой отправки.
AG>Да, я не знал. Думал что Flex уже похоронили. Это еще один аргумент за то, для C# на андроиде ниши нет. Хотя на жаве лепить формы для андроида мне показалось проще, чем с flex и с javafx 2 (писал на обоих под десктоп).
У флекса в ноябре был существенный апдейт, где появился ряд привычных для iOS контролов (callout, splitview) и возможность сборки .ipa прямо в винде.
AG> Это еще один аргумент за то, для C# на андроиде ниши нет
Даже такой монстр мобильной разработки, как i-Free нишу ему вполне нашёл:
"Причем, DAL и BL можно брать и без изменений копировать в Android и Windows Phone 7 версии, а это около 50% исходного кода!"
http://habrahabr.ru/post/132725/
AG>Imho товарищи из Xamarin хорошо начали как pet project, теперь они нанимают народ и делают провокационные заявления. Подозреваю, что денег нанимать народ им привалило не с продаж, а от Балмера- потроллить Брина. Закончить они имеют все шансы как Flex для iPhone- ведь яблочники забанили сначала жаву, потом flex. Забанить mono.touch в следующей версии iOS им раз плюнуть.
Осталось только понять, при чем здесь iOS.
НС>
Подобные тесты ещё лучше пройдут в Андроиде, будучи написаны на C/C++, который замечательно интерфейсит с далвиковыми приложениями. Одна беда, зависимость от процессора, но пока в основном у Андроидов ARM. Опыты с Intel Atom как-то ещё не получили большого коммерческого успеха.
Что, впрочем, все разработчики, которым от Андроида надо скорость, и делают.
AVX>Подобные тесты ещё лучше пройдут в Андроиде, будучи написаны на C/C++, который замечательно интерфейсит с далвиковыми приложениями. Одна беда, зависимость от процессора, но пока в основном у Андроидов ARM. Опыты с Intel Atom как-то ещё не получили большого коммерческого успеха.
Так можно паковать несколько нативных библиотек, Андроид сам выберет под нужную архитектуру.
Буду знать... упустил момент, при том, поучаствова в тех библиотеках...
AVX>Подобные тесты ещё лучше пройдут в Андроиде, будучи написаны на C/C++, который замечательно интерфейсит с далвиковыми приложениями.
Осталось переписать на С/С++ весь жабий код самого андроида, да так чтобы оно в итоге глючило хотя бы не больше обычного.
AVX> Одна беда, зависимость от процессора
И от некоторых деталей архитектуры конкретного аппарата тоже.
Ай, да ну. Вот это им делать не нужно... это сильная сторона Андроида, а не слабая.
НС>>Осталось переписать на С/С++ весь жабий код самого андроида, да так чтобы оно в итоге глючило хотя бы не больше обычного.
AVX>Ай, да ну. Вот это им делать не нужно... это сильная сторона Андроида, а не слабая.
Что именно сильная сторона? Тормоза Далвика?
Это юношеский максимализм.
Не надо джавную часть там переделывать, она создана для более лёгкого прикладного программирования.
В конце концов, большую часть времени приложение просто ждёт события, и большой разницы нет, это вовсе не интенсивное использования процессора. Это UI, и тем Android и хорош, что UI программируем на Java.
Где надо C, там будет C.
НС>>Что именно сильная сторона? Тормоза Далвика?
AVX>Это юношеский максимализм.
AVX>Не надо джавную часть там переделывать, она создана для более лёгкого прикладного программирования.
AVX>В конце концов, большую часть времени приложение просто ждёт события, и большой разницы нет, это вовсе не интенсивное использования процессора.
Видимо не всё так просто, раз имеет место существенно большее энергопотребление платформы в целом.
AVX>Это UI, и тем Android и хорош, что UI программируем на Java.
Вот не надо нам про UI, это далеко не самая сильная сторона Андроида Тут как раз всё очень печально.
AVX>Где надо C, там будет C.
Это капитальный промах. Связывает по руками и ногам наследием софта, привязанным к определённой архитектуре. И напрочь закрывает перспективы будущих оптимизаций.
S>Видимо не всё так просто, раз имеет место существенно большее энергопотребление платформы в целом.
О, задели почти любимую тему про Андроид. Это же не про UI, который, как и кошек, неправильно некоторые готовят.
И так, что же по вашему приводит к "существенно большему" энергопотреблению платформы в целом? Относительно чего замеряли? Вопрос риторический.
Отвечу, перевод процессора в малоактивное состояние завязан на несколько хардверных подсистем, которые должны позволить процессору поспать. И недостатки в имплементации драйверов устройств и хардверных библиотек ведут к тому, что нет правильно синхронизации между (не)активностью устройств и (не)активностью процессора. Устройства для Андроида поставляются в основном thrid-party, ни Гуглем, ни производителем телефона, а чаще третьей организацией, которая имплментирует библиотеки и драйверы для своего устройства, как бог на душу положит. Вопрос интеграции с устройствами, скажем с GPS. Скажем, про Apple достоверно известно, что интеграцией устройств в свои телефоны они занимаются сами, получая от хардверщиков собственно железо и спеки. А, скажем, Samsung работает совершенно не так, ему устройства и поставлются, и интегрируются "третьими партиями". Не спрашивайте, откуда мне известны эти детали.
AVX>>Где надо C, там будет C.
S>Это капитальный промах. Связывает по руками и ногам наследием софта, привязанным к определённой архитектуре. И напрочь закрывает перспективы будущих оптимизаций.
Портирование в исходниках никто не отменял.
НС>>Что именно сильная сторона? Тормоза Далвика?
AVX>Это юношеский максимализм.
Это вопрос.
AVX>Не надо джавную часть там переделывать, она создана для более лёгкого прикладного программирования.
C#/Mono не менее легок в программировании, а скорее более. Т.е. ни на какие жертвы в плане удобства при его применении идти не надо.
НС>Интересная новость:
НС>http://blog.xamarin.com/2012/05/01/android-in-c-sharp/
НС>Вкратце: товарищи их Xamarin выкинули из андроида Dalvik и весь жабий код портанули на C#. Ну и вкрячили в андроид вместо далвика моно. Полученный перформанс некоторых структур данных:
НС>[img_]http://tirania.org/s/71de890b.png[/img]
НС>Let the Combat begin?
Остается вопрос скорости и плавности отрисовки UI, скорость запуска, и тормоза GC. Я, честно говоря, не знаю, какие результаты по этим параметрам, но для ведроида это гораздо более важные параметры, чем результаты числодробилок(а отсутствие ошеломляющих результатов по этим параметрам заставляет задуматься).
Ах, да, энергопотребление еще забыл.
ЗЫ как-бы, ничего не мешает вкорячить моно рядышком с далвиком, и юзать для определенных задач.
E__>Остается вопрос скорости и плавности отрисовки UI, скорость запуска, и тормоза GC.
Остаются. Но, имхо, вряд ли на редкость убогий Далвик хоть в чем то заметно выигрывает.
E__> Я, честно говоря, не знаю, какие результаты по этим параметрам, но для ведроида это гораздо более важные параметры, чем результаты числодробилок
Это не числодробилки, это демонстрация тех преимуществ, которые дают CLR наличие в нем пользовательских value-типов и нерукожопых дженериков. В самых базовых алгоритмах, совсем не числодробильных, а очень даже типовых для common-задач программирования. В плане GC там вообще разница многопорядочная будет — value-типы того, GC не нагружают, в отличие от жабьих боксов.
E__>Ах, да, энергопотребление еще забыл.
Ага, и в плане энергопотребления тоже Моно явно лучше далвика.
E__>ЗЫ как-бы, ничего не мешает вкорячить моно рядышком с далвиком, и юзать для определенных задач.
Речь о коде самого Андроида. А вкорячить рядышком давно можно.
E__>>Остается вопрос скорости и плавности отрисовки UI, скорость запуска, и тормоза GC.
НС>Остаются. Но, имхо, вряд ли на редкость убогий Далвик хоть в чем то заметно выигрывает.
Ну, положа руку на сердце, мне далвик тоже не сильно понравился. Но я сильно глубоко не исследовал(увы, времени просто не было, хотя вопрос интересен), а поверхностные знания могут быть недостоверны. Почему гугл не использовал наработки той же опен-жвм(или как там оно зовется), а стал писать свою имплементацию — тайна великая есть. Ну, для меня, по крайней мере(я прямо говорю, что не знаю нюансов, потому не нужно кидаться говняшками).
E__>> Я, честно говоря, не знаю, какие результаты по этим параметрам, но для ведроида это гораздо более важные параметры, чем результаты числодробилок
НС>Это не числодробилки, это демонстрация тех преимуществ, которые дают CLR наличие в нем пользовательских value-типов и нерукожопых дженериков. В самых базовых алгоритмах, совсем не числодробильных, а очень даже типовых для common-задач программирования. В плане GC там вообще разница многопорядочная будет — value-типы того, GC не нагружают, в отличие от жабьих боксов.
Увы. Это действительно фэйл. Но — "так исторически сложилось" — жаба постарше будет, а ее основная ниша, сервера, с трудом воспримет обратную несовместимость на уровне байткода. Хотя можно было бы придумать решение поизящнее.
E__>>Ах, да, энергопотребление еще забыл.
НС>Ага, и в плане энергопотребления тоже Моно явно лучше далвика.
Не могу ни подтвердить, ни возразить — нет инфы.
E__>>ЗЫ как-бы, ничего не мешает вкорячить моно рядышком с далвиком, и юзать для определенных задач.
НС>Речь о коде самого Андроида. А вкорячить рядышком давно можно.
Да хоть на си(++), если уж припрет(а можно и на асме для конкретного девайса, вопрос в необходимости и цене).
Дело в том, что ведроид, пусть даже со своими недостатками — таки взлетел, и занял определенную нишу. Спорить с этим бессмысленно. А как дальше пойдет — хз. Я вообще вот симбиан юзаю. За то, что звонки работают всегда и беспрекословно(и пофигу на подвисшие приложения, пофигу на то, что даже в "режим ожидания" выйти не получается — входящий будет принят в 100% случаев), но для девайс нужен больше как телефон, и это мой выбор. А, да, будильник будет работать еще неделю без подзарядки телефона, даже если включить его нормальным образом не выходит(т.е. батарея села).
E__>Почему гугл не использовал наработки той же опен-жвм(или как там оно зовется), а стал писать свою имплементацию — тайна великая есть. Ну, для меня, по крайней мере(я прямо говорю, что не знаю нюансов, потому не нужно кидаться говняшками).
Для справки — гугл купил Android Inc. в 2005, а сан открыла исходники явы в 2006 (вроде бы, но точно не раньше). Черт его знает сколько из того, что было у Android Inc. на момент покупки, осталось в андроиде при релизе, но видимо что-то осталось. Кроме того, есть мнение, что гугл не хочет иметь дела с OpenJDK из-за того, что тот открыт под GPL.