Android портирован на C#

    В разгар битвы между Oracle и Google за право использовать Java/Dalvik в системе Android, компания Xamarin представила альтернативу — более производительную и энергоэффективную версию Android на С#. Тесты производительности говорят сами за себя.



    В отличие от Sun и языка Java, компания Microsoft направила C# и .NET VM для стандартизации в ECMA, система защищена от патентных исков строгими требованиями ISO, а также обязательством Microsoft.

    Mono — это open source реализация фреймворка .NET, которая позволяет писать приложения на языке C# для Android и iOS. С момента основания компании Xamarin в июле прошлого года, разработчики Mono думали над её развитием для платформ Android и iOS и над тем, как сделать приложения ещё быстрее и энергоэффективнее. Они пришли к выводу, что проблема — в виртуальной машине Dalvik, которая имеет ряд ограничений, свойственных Java, и поверх неё приложения в любом случае будут работать неэффективно. В итоге появилась идея взять и переписать весь исходный код операционной системы Android на C#. Так появился проект XobotOS.

    Автоматическую конвертацию более миллиона строк Java-кода Android 2.x провели с помощью улучшенной версии Sharpen.



    XobotOS на github
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 294
    • +49
      Еще бы Google заинтересовалась этой новостью.
      • +13
        Я думаю большие компании просто не могут пропустить мимо внимания это. Если все же пропустят без рассмотрения, то таких ответственных людей надо увольнять.
        • +2
          Я вообще не понимаю зачем там этот Davlic, точнее так, почему нельзя писать программы без него, сейчас у некоторых он нужен только для того что бы загрузить so файлы и передать им управление, а так же взаимодействовать с GPS, камерой, сетью. Выкиньте все это дерьмище и дайте нормальные с++ либы, вся эта Java постоянно мешается только.
          • +9
            Dalvic дает очень важное преимущество, которое для широкого класса приложений превосходит минусы — приложение будет работать на любой архитектуре. И, предположительно, использовать всю мощь.
            • +7
              Гугл контроллирует средства разработки и они бы могли решить проблему архитектур очень просто:

              1. Сишка уже сейчас может компиляться под разные архитектуры прозрачно для разработчика.
              2. Всё это дело уже сейчас пакуется в APK с разными бинариками.
              3. Сделать более умный маркет, который при аплоуде приложения сделает несколько версий APK под разные платформы.
              4. Слать юзерам только нужную версию APK без лишних бинариков.

              Вуаля, всё работает прозрачно и для программеров и для пользователей. Осталось только реализовать шаги 3 и 4.
              • +6
                Как ни крути — это фрагментация.
                • –2
                  С таким подходом ява тоже фрагментация — VM-то разная под разные платформы. Но программер её не видит. Сборку он тоже видеть не будет. Работает и жорошо.
                  • 0
                    Но в случае с C++ именно програмеру придется собирать все это дело под разные платформы. Да и тестировать сложнее будет.
                    • 0
                      Смысл в том, чтобы не собирать отдельно. Сделать это гуглу не проблема, о чём я и говорю. А тестировать и так надо под кучу девайсов, ничего не поменяется. С каждым годом девайсов и различий всё больше и больше, дополнительные архитектуры погоду не сделают.
                      • 0
                        Вы не поняли собеседника. Он предлагает, чтобы разработчик грузил исходный код, а Гугл сам тестировал его на совместимость и компилировал/собирал под разные платформы для последующей раздачи в Маркете/Play.
                        • +1
                          Сборку проекта под несколько архитектур увы не всегда можно автоматизировать. Да и представьте насколько увеличится стоимость разработки.
                          • 0
                            Google nacl + llvm с вами несогласен.
                            • +1
                              От того что они не согласны стоимость разработки на C/C++ не уменьшается, количество разработчиков не увеличивается, и необходимость танцев с бубном при некоторых обстоятельствах это не устраняет.

                              p.s. К слову, а причем тут Google nacl? Насколько я знаю это способ ускорить работу бизнес логики для WEB приложений. Не каждое приложение под андроид можно реализовать через него. Или я не прав?
                              • 0
                                Angry Birds там взлетает, причем для любых 32битных осей.
                                Про стоимость разработки это все мифы, проблема не имеет однозначного решения.
                    • 0
                      getjar.com это решил давно, правда, за счёт разработчика.
                    • +5
                      Что характерно, Маркет уже вполне умеет работать с несколькими APK под разные девайсы и версии ОС.
                      • 0
                        DEX-файл в APK является платформонезависимым, а вот зависимыми от платформы могут быть библиотеки в папке lib, внутри APK. К примеру, APK SetCPU содержит в папке lib три подпапки под разные архитектуры — две под разные вариации ARM и одна под x86. Android Terminal Emulator содержит по умолчанию библиотеку для ARM, но есть старая версия ATE для MIPS. В результате я на своем Ainol Novo7 Paladin путем замены оригинальной библиотеки ARM на старую от MIPS получил работающую без Magic Code последнюю версию ATE.
                        • 0
                          Спасибо, я в курсе как внутри устроены APK :) Раньше Гугл предлагал пихать все в один APК, независимо от целевого девайса, но с относительно недавних пор можно загружать несколько APK одного приложения под разные целевые платформы. Например, чтобы уменьшить их размер, нe поставляя библиотеки под все платформы, a только нужные. Или, например, выгружать версию с ActionBarSherlock под старые версии Android, а для Honeycomb и выше сделать нативный интерфейс на Holo.
                      • 0
                        Как я понимаю проблему: в С юзер может взять либу которая отлично работает на его архитектуре, процессоре и не факт что эта либа будет работать на устройствах с другой архитектурой. Куча неопытных юзеров выкладывает кучу таких програм на маркет и мы видем в интернете статьи о том что андройд — самая глючная система.
                        В Java'е пользователь может не думать о совместимости либ вообще. Так же не должен думать о памяти. Ну вы думаю вы и сами знаете/слышали о преимущкествах J перед C.

                        И я бы не сказал что ВСЕ пакуется с бинарниками. Бинарники используются только для узких мест. Чаще всего это оттестированные либы общего пользования. Для не узких мест джавы вполне хватает.
                      • –1
                        так а кто мешает использовать это преимущество? в винде программы на яве тоже работают и для этого не нужен обязательный для всех приложений слой на яве.
                        • +1
                          >>И, предположительно, использовать всю мощь.
                          Т.е. Dalvic как-то сам распараллелит ваши приложения и векторизует код под NEON?
                          • 0
                            Именно поэтому я и написал — предположительно.
                            Так как в этом случае все на совести вирт. машины — допустим появилась новая инструкция, которая за такт делает то, что раньше делали несколько команд.

                            Тем более, я слышал что такое могут делать некоторые компиляторы для С++, а это значит что при желании это вполне скоро появится и на вирт. машинах.
                            • 0
                              Хотя, в данном контексте было бы правильнее слово «потенциально».
                              • –1
                                >> я слышал что такое могут делать некоторые компиляторы для С++
                                Максимум что они могут делать это смешить детей в песочницах
                                • +2
                                  >Coding in ASM since 1993
                                  На этом закончим наш спор.
                                  • 0
                                    Кстати, говоря о неспособности Dalvic в данном вопросе, я не это обобщаю все VM, которые-могут-быть-написаны.
                                    Потенциально VM предоставляет больше свободы для параллелизации и оптимизации чем статический компилятор.
                                    Осталось дело за малым — создать такую VM =)
                                • 0
                                  Оптимизация такого рода предполагает знание допустимых латентностей зависимых задач и смены представления данных на более подходящий формат, после чего уже выбирается подходящий алгоритм. Низкоуровневые языки типа «C» не позволяют передать данную информацию при написании кода.

                                  Тупая векторизация простейших циклов много где есть конечно, но это не интересно.
                                  Компиляторов C/C++, которые делают трансформацию данных (для начала), насколько я знаю, нет.
                            • +5
                              Скажите вот… почему в громких заявлениях приложения на Java используют всю мощь, иногда даже быстрее C приложений, а в итоге имеет то что имеем — тормоза UI, дерганные прокрутки длинных списков, да и вообще общее впечатление от UI — как задумчивая коробка автомат
                              • +3
                                Некоторые оправдывают это «честным» режимом прорисовки, де iOS и Windows Phone рисуют гуй в отдельном потоке с максимальным приоритетом, а в андройде не так.
                                • –1
                                  Потому что на старых версиях андройда UI рисовался софтварно, в отличии от той же iOS, где это делается через OpenGL.
                                  • 0
                                    Как раз простенькую картинку быстрее софтварно отрисовать, чем гонять туда сюда и кучу раз контекст переключать… OpenGL нужен чтобы что-то более сложное рендерить, чем список с элементами.
                                    А вот рендеринг элементов списка в отдельном потоке это куда более важная вещь!
                                    • +1
                                      если честно, всегда считал, что рисовать гуй в одном потоке с приложением, которое должно че-то в бэкграунде делать, — это моветон.

                                      Ну, например рендерить раскрывающийся список с подгрузкой в него элементов по ходу листания.
                                      • –1
                                        Обычно в приложении всегда только один активный поток рендерит интерфейс, а остальные в background режиме подгружают данные для рендеринга.
                                        Но в реальности обычно все в одном потоке и происходит и все настольные приложения написаны именно так!
                                      • 0
                                        OpenGL нужен чтобы что-то более сложное рендерить, чем список с элементами.


                                        В конечно счете вам нужно рендерить кучу векторных примитивов. Именно по этому в том же WPF UI рисуется через DirectX.
                                        • 0
                                          В конечном итоге вам придется рендерить кучу текста и выводить кучу текстур и уже заниматься с ними весельем типа масштабирования, tiling'а и т.д.
                                          • +3
                                            Этим занимается UI фреймворк, а не конечный программист.
                                    • +1
                                      Я не в курсе на чем написаны встроенные приложения на Windows Phone, если на C# то они вполне себе быстро работают.
                                      • –4
                                        Да, на нём. а работают шустро потому что нет фрагментации и жесткие ограничения платформы.
                                        /Cap_off
                                        • +3
                                          На C++. Используется Silverlight for Windows Embedded.
                                          Вот только странно то, что один и тот же текст, нарисованный одним и тем же шрифтом, сглаживается по разному на нормальном сильверлайте и вышеуказанном.
                                        • +1
                                          в тестах была не джава, оракловская джава и даливик в плане оптимизаций это совершенно разные вещи. Я не знаю причин почему их нет в далвике, но примерно те же технологии используются в тестах с моно которые вы увидели, поэтому если бы в тестах сравнивали оракловскую java и далвик разница была бы так же существенна. Возможно это енергопотребление, память еще что-то не знаю. Тест очень синтетический. Использует коллекции дотнета. Не сильно бы я ему верил.
                                      • +15
                                        Ключевое слово у «некоторых». Как не крути, а писать на java/c# быстрее и проще, чем на С/С++. К нативному коду обращаются когда возникают проблемы производительности, которые другими путями не решить.
                                        • +1
                                          Или когда есть уже написанный нативный код и охота его просто портировать? Что в разы проще, чем всё опять по новой под жабу, C#, HTML5+JS переписывать, нет?
                                          А llvm вполне способен генерить универсальные бинарники.
                                          • +1
                                            Или когда есть уже написанный нативный код и охота его просто портировать?


                                            Такой момент, конечно, имеет место быть, но как он относится к изначальному вопросу о том, почему бы не отказаться от java\C# в реализации userland в пользу нативных библиотек?
                                            • 0
                                              Чтобы было проще портироваться дальше?
                                              • 0
                                                Портирование это слишком частный и узкий случай, чтобы ради него принимать столь масштабное решение. Если мы отбросим игры, то оставшийся софт всеравно нужно писать отдельно под каждую платформу в соответствии с ее правилами разработки приложений, от UI до взаимодействия с системой.
                                                • 0
                                                  Меня такой подход ну совсем не устраивает. Тем более, что большая часть любого ПО таки платформонезависима априори. А гуй уж хрен с ним, сделаю в соответствии с HIGом.
                                                  • +3
                                                    Тем более, что большая часть любого ПО таки платформонезависима априори

                                                    Где это вы такое априори нашли? Даже не говоря об интеграции с системой, вот например у меня есть приложение календарь, типа iCalc. У меня половина приложения, если не большая это его UI и его логика со всякими спецэффектами.
                                                    Меня такой подход ну совсем не устраивает.

                                                    Ну когда у вас будет своя платформа, вы сможете забить на финансовую выгоду и делать как вам нравится.
                                                    А гуй уж хрен с ним, сделаю в соответствии
                                                    Вы как-то преуменьшает сложность, важность и объем работы для реализации хорошего GUI для мобильной платформы.
                                        • +4
                                          Думаю это давать не надо… С С++ куча проблем по сути дела есть только один нормальный способ распространять С++ программы — исходниками. И каждый у себя запустит gcc и получит рабочую версию, а если что-то не линкуется подправит и все равно получит работающую версию…
                                          Компилировать под разные платформы еще то удовольствие и в конце концов получается, что на 1-5 телефонах все равно не работает! Причем падает сразу все приложение, а не по частям, как в Java (ClassNotFoundException).

                                          Мне кажется Google осознал эту проблему и продвигает C язык с трансляцией в LLVM. Вот это правильно! И то что они делают в Chrome тоже правильно. А верить, что все телефоны будут писать одинаковые API к драйверам — глупо и Google их не заставит, поэтому высокоуровневое API (на другом языке) не мешает, а помогает, так как стандартизирует…
                                          • НЛО прилетело и опубликовало эту надпись здесь
                                            • 0
                                              Это другого уровня проблема и проблема говнокодеров не должна причинять неудобств нормальным программистам.
                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                • 0
                                                  Я вообще считаю, что лучше бы Java была клеем для нативных модулей, а приложения собирались из этих кирпичиков.
                                                  Но увы, в результате я лучше на плюсах все продолжу писать, чем связываться со всей этой кухней.
                                                • +1
                                                  «Проблемы негров шерифа не волнуют»(с)

                                                  Говнокодер или нет, когда разработчик не парится над менеджментом памяти, а сразу в бой — разрабатывать бизнес-логику, время и/или стоимость разработки неплохо сокращаются. В managed языках и вообще языках высокого уровня есть смысл. В том числе и в попытке пресечь выстрелы в ногу у разработчиков, у которых недостаточно опыта/времени/денег.

                                                  • 0
                                                    Речь идет о том, как уменьшить стоимость разработки и следовательно уменьшить стоимость приложений, что сделает платформу более популярной. Ваш путь предполагаю наличие более опытных и дорогих кадров при том же результате для конечного пользователя, что экономически не выгодно.
                                          • +59
                                            Не могу я верить в такой отрыв без анализа причин этого отрыва.

                                            • +4
                                              Исходники бенчмарка как я понимаю лежат здесь: github.com/zanew/MonovsDalvik
                                              Я их не запускал, но думаю вы можете это сделать без проблем.
                                              • +9
                                                Я конечно их открыл и одним глазом посмотрел.
                                                Причина отрыва по прежнему не ясна :-)
                                                • +5
                                                  Пишут, что за счёт наличия «структур» (Value types) и за счёт другой реализации темплейтных (generic) функций.
                                                  • +1
                                                    Кстати, да. Когда писал одну простую игрушку под Андроид, в логике компьютерного игрока для дерева состояний очень не хватало возможности положить в стек состояние игровой доски — на структурах это делалось бы влет и думаю сильно ускорило бы размышления компьютера.
                                                  • –33
                                                    «Я ничего не понял, но не верю в производительность C#»
                                                    • 0
                                                      Я Вас огорчу, сам по себе C# имеет нулевую производительность, он при компиляции преобразуется в промежуточные данные, с которыми уже работает «виртуальная машина», так что надо говорить так: «я ничего не понял, но думаю что VM JAVA должна работать быстрей чем VM Mono»
                                                      • +6
                                                        Ну, быстрей — не быстрей, но не в 8 же раз медленне JVM чем VM Mono. Странно это как-то и подозрительно.
                                                        • +5
                                                          Так это смотря на что смотреть, в данном случае, на сколько я понял, противоставляли дотнетовские структуры джавовским классам (в джаве нет структур?), а структуры работают в разы быстрей, и благодаря этому приложение в целом работает быстрей. При разработке можно очень много маленьких классов заменить на структуры, и это даст значительный прирост производительности (до 8 раз в идеале).
                                                          • –2
                                                            В джаве нет структур.
                                                            Но, насколько я понимаю, тест не был строго ориентирован на противопоставление структур объектам/классам.
                                                            • +5
                                                              Именно, и на этом весь выигрыш в данном случае =) А еще там оракл не будет наезжать.
                                                              • +1
                                                                Mono and Dalvik: structs and Generics.
                                                                • –1
                                                                  Ах да, на заголовок графика то я и не обратил внимания. Спасибо.
                                                            • +3
                                                              В VM Mono другая работа со строчками, другой GC, есть структуры и по-другому сделаны дженерики.
                                                              • 0
                                                                А как влияют дженерики?
                                                                • +1
                                                                  В .NET они поддерживаются нормально в JIT, в яве сделаны через костыли для работы в VM тех времён, когда их в языке ещё не было.
                                                                  • +1
                                                                    Чем отличаются я в курсе. Непонятно, как это отличие влияет на производительность.
                                                                    • +4
                                                                      new ArrayList().add(1); // боксинг
                                                                      • –1
                                                                        Вы опоздали, уважаемый, и даже не ответили по сути на вопрос (в вашем коде и дженериков-то нет).
                                                                        Вы, подозреваю, в курсе, что такой код будет на этапе компиляции заменён на .add(new Integer(1));

                                                                        Но проблема, как уже докопались в соседней ветке, не в этом, а в том, что get() на List вернёт Object, который надо будет привести обратно к Integer. Результат: затраты на cast.
                                                                        • +1
                                                                          Вам про это как раз и намекал ControlFlow
                                                                          • –1
                                                                            Может он на это намекал, а может на overhead при создании враппера к int — к чему вообще намёки?
                                                                            Не лучше ли написать прямо, а не обиняками, и сэкономить время всем читающим.
                                                                  • +4
                                                                    Я не уверен насчет последних версий джавы, но когда я в свое время интересовался, разница была в том, что в джаве на уровне байт-кода никаких дженериков не было, вместо этого объекты с типом типизации превращались в object, а в нужных местах проставлялся каст. В шарпе дженерики реализованы на уровне CLR, так что нет оверхеда с кастом туда обратно. Как я понимаю(возможно ошибочно) особенно это актуально для типизации через value type, т.к. на касте с обджектом мы получаем постоянное боксирование.
                                                                    • 0
                                                                      > на уровне байт-кода никаких дженериков не было
                                                                      Так и сейчас, ничего не изменилось. Но как именно это влияет не производительность?

                                                                      > особенно это актуально для типизации через value type,
                                                                      > т.к. на касте с обджектом мы получаем постоянное боксирование
                                                                      Боксирование в Java грубо говоря происходит не в рантайме.
                                                                      Value types в джава — только примитивы. Дженерики на примитивы не распространяются.
                                                                      • +2
                                                                        Дженерики на примитивы не распространяются.


                                                                        Т.е. List в джаве написать нельзя?

                                                                        Но как именно это влияет не производительность?


                                                                        Операция каста и динамических проверок процессорного времени не отнимают?
                                                                        • –2
                                                                          > Т.е. List в джаве написать нельзя?
                                                                          List не может содержать примитивы, только Object.

                                                                          > Операция каста и динамических проверок процессорного времени не отнимают?
                                                                          Интересно, что у вас «каст» и «данимические проверки» как отдельные вещи (-;
                                                                          Отнимают, конечно, но так ли много?
                                                                          • 0
                                                                            Отнимают, конечно, но так ли много?

                                                                            В цикле сложения всех элементов списка они займут 95% времени.
                                                                            • +2
                                                                              Ваш вопрос изначально был в том «как влияют», а не насколько. Численную оценку надо устанавливать экспериментально, будет здорово если вы проведете такое измерение и опубликуете результаты.
                                                                              • +3
                                                                                Вы похоже недооцениваете этот «каст». На самом деле это означает следующее — в массиве у вас хранится не само число, а ссылка на него. Это уже двойное потребление памяти. А если еще представить что у вас какие то элементы удаляются, а какие то добавляются, то вы получаете в управляемой куче большое кол-во недоступных объектов, на уничтожение которых сборщику мусора приходится тратить дополнительное время.
                                                                                В случае же с дженериками .Net'a компилируются классы для каждого значимого типа в отдельности — т.е. все выделения памяти происходят на стеке, и вы экономите очень большое кол-во времени на сборках мусора и дополнительной работе с памятью.
                                                                                • 0
                                                                                  > в массиве у вас хранится не само число, а ссылка на него
                                                                                  В массивах в Java какраз можно держать примитивы.
                                                                                  Речь шла о List, и не обязательно List врапперов для примитивов, а любой List, с сылками на сложные объекты например — не врапперы для примитивов.

                                                                                  > В случае же с дженериками .Net'a…
                                                                                  >… все выделения памяти происходят на стеке
                                                                                  Для коллекций примитивов и структур? Ну, с структурами вопросов особо и не было.
                                                                                  • 0
                                                                                    Если я правильно понял, то в C#
                                                                                    List fooList;
                                                                                    это нечто похожее на шаблоны в плюсах, то есть, VM знает о том, что это новый тип List а в Java
                                                                                    List превращается в
                                                                                    List
                                                                                    • 0
                                                                                      Чертов парсер
                                                                                      List<Foo> fooList;
                                                                                      

                                                                                      и
                                                                                      List<Object> fooList;
                                                                                      


                                                                                      соответственно
                                                                                      • 0
                                                                                        >Речь шла о List
                                                                                        Простите, оговорился. Конечно же я имел ввиду List. Просто в C# между ними нету такой великой разницы — и то и то класс, но у масивов есть поддержка состороны синтаксиса языка.
                                                                                        Да в шарпе это подобие шаблонам, за исключением того, что там строгий контроль типов на уровне самого шаблона, а не при его использовании. За счет этого есть и минусы (меньшая гибкость) и плюсы (кроме самого контроля типов еще и уменьшение объема кода после компиляции — для каждого ссылочного типа генерируется только 1 реализация класса и т.д.)
                                                                                      • 0
                                                                                        Дженерики с аргументами типов, являющимися ссылочными типами, работают аналогично джавовым (единственное отличие в этом месте — отсутствие type erasure). А вот дженерики с аргументами типов, являющимися value types — работают без боксинга, в отличие от джавовых аналогов.

                                                                                        Итого, есть 2 отличия в дженериках: type erasure и поддержка value-types. Первое на производительность не влияет, а вот второе — влияет.
                                                                                        • 0
                                                                                          Там ещё много всяких тонкостей. Например дотнетовские дженерики специально не поддерживают ковариантность входных аргументов, и поэтому избегают дорогих проверок в рантайме (в отличии от джавы).
                                                                                          • +1
                                                                                            Почему не поддерживают? Просто она там особенным образом реализована. Или что именно имеется в виду?
                                                                                            • 0
                                                                                              Они её поддерживают начиная с версии фрейворка 4.0 :) До этого она была только для массивов, а теперь появилась возможность при создании обобщенной коллекции задать это в явном виде.
                                                                                              • 0
                                                                                                Вот вот. Ну просто я поэтому и удивляюсь, когда говорят, что там что-то не поддерживается.
                                                                  • +3
                                                                    Ничего удивительного, .net машины часто превосходят машины java по производельности на синтетических тестах.

                                                                    А на мобильных устройствах думаю вариантов оптимизаций еще предостаточно.
                                                                    Но это просто отлично! Вполне возможно это подтолкнет Google оптимизировать свою машину.

                                                                    Интересно, когда появятся .net сборки доступные для широких масс…
                                                                • +10
                                                                  Вообще тот график где показывает отрыв очень хитрый. В Mono реализация на более лёгких структурах вместо объектов.
                                                                  • 0
                                                                    А что мешало в Java это сделать на структурах и аллоцировать их на стеке?
                                                                    • +7
                                                                      То, что в джава нет структур.
                                                                      • –1
                                                                        А что мешает их добавить? Хотя бы как расширение для Dalvik'а.
                                                                        • +11
                                                                          То, что это уже будет переJava-недоC#.
                                                                          • +2
                                                                            Добавит их значило бы создать свой язык на основа Java. Туда еще очень много чего можно было бы добавить, но, как я понимаю, политика гугла как раз заключалась в том, чтобы поддержать java стандарт, а не создавать новый язык. К тому же надо еще посчитать, что дешевле — править виртуальную машину, IDE и компилятор или просто подставить mono vm и запустить старые приложения через IKVM.
                                                                      • +2
                                                                        В этом весь смысл статьи, что в дотнете есть инструменты, позволяющие писать более быстрый код, относительно жавы в целом и андроида в частности.
                                                                        «C# went from being a slightly better Java to be light-years ahead. „(с)
                                                                      • +3
                                                                        Ещё они обращение к графике поменяли: убрав лишнее звено (Java) реализовав через P/Invoke
                                                                        • 0
                                                                          То есть еще и P/Invoke можно оптимизировать за счет ручного маршалинга?
                                                                      • +2
                                                                        Расскажите несведущему, где такие архитектурные ограничения Dalvik, которые решит Mono?
                                                                        • +34
                                                                          Дотнетный рантайм эффективнее явовского по скорости by-design. Это даже тесты IKVM показывают.
                                                                          • +2
                                                                            А можно по-подробнее?
                                                                            Я ничего лучше этого не видел. При этом у них результаты для разных реализаций в рамках одного языка зачастую отличаются в десять раз. Тем не менее есть серьезные подозрения, что дело не в Java «by-design», а в Google «by-hands».
                                                                            • 0
                                                                              Код, а так же версию и опции моновского рантайма я там не увидел. Прозреваю, что это было Mono 2.6 с профилем для десктопов.
                                                                              • 0
                                                                                Вот лог запуска одной из бенчмарк, там видны версия и опции (точнее, их отсутствие):
                                                                                shootout.alioth.debian.org/u32/program.php?test=binarytrees&lang=csharp&id=2#log
                                                                                • +16
                                                                                  Ну замечательно. Использовали моновский компилер C# первого поколения, который не обновлялся сто лет уже, Boehm GC, вместо которого уже давно рекомендуют использовать SGen, и не использовали никаких флагов, включающих оптимизации JIT. Зато яву запустили в серверном режиме.
                                                                                  Q. E. D.
                                                                                  • +1
                                                                                    А напишите, с какими параметрами надо компилировать/запускать, хочется самому потестить.
                                                                                    • +5
                                                                                      Для начала тест следует хотя бы привести к корректному состоянию, ибо сейчас он что для явы, что для Mono считает попугаев, т. к. замеряет в т. ч. загрузку рантайма, библиотек и время работы JIT, что в нормальном приложении происходит один раз на старте. Сейчас если включить в Mono AOT-кэш сборок (устанавливается в переменной окружения MONO_AOT_CACHE, dll-ки компилируются в машинный код один раз, нативные бинарники лежат в ~/.mono/aot-cache), то тест покажет совершенно иные результаты, но они всё равно будут некорректны. По-хорошему же надо вынести весь код теста в функцию, прогнать её один раз, после чего вызвать снова и уже тогда считать затраченное время.

                                                                                      А вообще компилить следует gmcs (а лучше компилятором от MS), использовать параметры -O=all --gc=sgen, в идеале ещё и само Mono собрать с поддержкой LLVM, тогда, соответственно, добавить параметр --llvm. Ну вот как-то так.
                                                                            • +1
                                                                              Ну дайте ссылки хотя бы на эти тесты, и расскажите что именно там эффективнее.
                                                                              Я не могу в куче мусора найти что-нибудь вменяемое пока.
                                                                              • +2
                                                                                Вообще-то, Dalvik — не JVM, у него совершенно иная архитектура.
                                                                              • +8
                                                                                Из моего опыта написания игрушек — Java имеет одно очень важное ограничение by design.
                                                                                Там нет структур (struct в C#), тоесть обьектов, память для которых выделяется в стеке и которые передаются by value.
                                                                                В играх это супер критично — Vector, Matrix, Color — все часто создаваемые и удаляемые обьекты создаються на стеке чтоб избежать генерации мусора.
                                                                                • +2
                                                                                  кстати о struct. Вот сравнение использования структур и классов для C#:
                                                                                  www.dotnetperls.com/struct
                                                                                  • +1
                                                                                    Да. Цифры говорят сами за себя.
                                                                                    Что намного важнее со struct — не скорость в абстрактных тестах, а то что они при создании-удалении не фрагментируют кучу. А GarbageCollector хоть быстрый и умный, но при полном проходе он приостанавливает выполнение программы, а в играх регулярное зависание даже на 50мс будет очень заметно.
                                                                                    • +5
                                                                                      Не только это. Если у нас есть вектор структур, они будут иметь пространственную когерентность в памяти в отличии от классов и соответственно будут превентивно попадать в кэш-линию, что дает очень ощутимую разницу при большом размере вектора.
                                                                                  • +1
                                                                                    Думаю RenderScript решит эти проблемы и может быть будет быстрее, чем Mono ;)
                                                                                    • +4
                                                                                      Эти проблемы решает Android NDK, только вместе с этим убивает простоту и удобство использования современного managed языка.
                                                                              • +7
                                                                                Google на это не пойдет
                                                                                • +7
                                                                                  А зря, особенно если Oracle создаст прецедент.
                                                                                  • 0
                                                                                    Хотя, опять же, если Oracle выиграет, поверх новой виртуальной машины они Dalvic, для совместимости с существующими приложениями не смогут поставить.
                                                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                                                      • +1
                                                                                        Код на яве можно через IKVM перекомпилять в дотнетные dll-ки, делов-то.
                                                                                        • НЛО прилетело и опубликовало эту надпись здесь
                                                                                          • 0
                                                                                            Если Оракл таки засудит гугловцев, то придётся.
                                                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                                                              • 0
                                                                                                Ну есть же ещё J#. При наличии явовских библиотек классов из IKVM никаких проблем с переходом на CLR быть не должно.
                                                                                                • 0
                                                                                                  Ну, блин, J# забросили еще в 2007-м. Ему до C# как до луны теперь.
                                                                                                  • –1
                                                                                                    Ну J# до C# всё же ближе чем яве.
                                                                                                    • 0
                                                                                                      Хммм, интересный вопрос. Наверное, ближе к CLR, чисто технически, но Ява-то развивалась все эти годы, так что — по уровню, пожалуй, нет.
                                                                                                • +7
                                                                                                  процесс миграции между C# и Java не такой уж затратный по времени. Это не Питон <--> Руби.

                                                                                                  Но чтобы сменить парадигму, нужна очень веская причина. Для Гугла. И претензии Оракла здесь ни при чем. Судиться — это удел юристов, а не программистов.

                                                                                                  Веских причин может быть две: 1) архитектурная; 2) политическая.
                                                                                                  В случае 1) недостаточно просто «конвертнуть» код и подивиться недюжинной экономии ресурсов.
                                                                                                  Нужны:
                                                                                                  — тщательное тестирование работоспособности всех компонентов системы,
                                                                                                  — проверка безопасности такой системы,
                                                                                                  — создание и длительное нагрузочное/повседневное тестирование рабочих прототипов,
                                                                                                  — подробное прогнозирование возможных финансовых потерь своих/разработчиков сторонних приложений, оценка затрат сторонних разработчиков на переход с одной платформы на другую;
                                                                                                  — подготовка средств разработки и тестирования ПО/
                                                                                                  — и так далее.

                                                                                                  Если в результате выполнения всех этих пунктов окажется (теоретически), что компания+разработчики+пользователи приобретут за МИНИМУМОМ временных-финансовых затрат РЕАЛЬНЫЙ профит (компании), упрощение разработки/тестирования (разработчикам), счастье (пользователям),
                                                                                                  тогда да, можно говорить о том, что такой переход оправдан.

                                                                                                  2) политическая — это решение сверху (например, что маловерятно, под давлением внешних факторов), которое всё равно приведет к необходимости всего, что было в пункте 1).

                                                                                                  В любом случае, в масштабах экосистемы андроида невозможно такой переход осуществить за один день, поэтому наверное разработчики Хобота и указали, что «разработка рассматривается как исследовательский проект, не претендующий развитие в виде нового продукта.»
                                                                                          • –1
                                                                                            Почему не надо? На моно есть кошерный F#, кодить на котором несравненно большее удовольствие, чем на унылой жабке.
                                                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                • 0
                                                                                                  > Серьезно хотите, чтобы SDK крупной мобильной платформы перевели на функциональный язык программирования?

                                                                                                  Почему такое странное неприятие функциональщины? Все от этого только выиграют.

                                                                                                  > Почему не на Lisp тогда уж?

                                                                                                  А Лисп по большей части не функциональный.
                                                                                          • 0
                                                                                            Почему? Купят их с потрохами и переведут андроид на моно. Это, конечно, крутой поворот, но всякое может быть.
                                                                                            • 0
                                                                                              Подавятся покупать :)
                                                                                              • –1
                                                                                                Скорее купят, и продадут.
                                                                                                • 0
                                                                                                  Та не. Именно что подавятся. Гугл не настолько крупен чтобы купить оракл, если верить волфрамАльфа
                                                                                                  www.wolframalpha.com/input/?i=google+oracle
                                                                                                  • +4
                                                                                                    я имел в виду xamarin, конечно же =)
                                                                                                    • +1
                                                                                                      Тогда я неправильно понял :)
                                                                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                                                            • +1
                                                                                              Кстати ещё в блоге у них написано, что уже до 4.0 проапгрейделись
                                                                                              • +2
                                                                                                а как же приложения? сообщество не захочет переучиваться на С#, приложение не станут переписывать
                                                                                                • +4
                                                                                                  Как я понимаю, нативные (C++) и так будут работать. Java будут можно через Sharpen перегнать.
                                                                                                  • +1
                                                                                                    А я так понимаю что они (нативные) таки отвалятся. Там же все через JNI сделано. Нет Java машины — нет JNI. К сожалению не в курсе позволяет .NET VM добавлять к .NET классам нативный код.
                                                                                                    • 0
                                                                                                      1) в C# есть P/Invoke
                                                                                                      2) JNI при запуске под IKVM работает, т. е. реализация для CLR уже есть.
                                                                                                      • 0
                                                                                                        То что что-то есть это хорошо. Правда надо почитать какое оно и насколько удобно (тут кстати JNI плохой пример для подражания)

                                                                                                        По второму пункту как-то не очень понял. Вы заявляете что уже собранная библиотека будет без проблем работать? Как-то с трудом верится, учитывая что JNI учитывает специфику Java VM которой в .NET VM просто не будет.
                                                                                                        • 0
                                                                                                          P/Invoke позволяет работать с любой библиотекой на С (не С++, с ним сложнее всё). По поводу JNI, новость о поддержке в IKVM была ещё 2004-ом году. Вообще говоря они позиционируют IKVM помимо всего прочего как drop-in replacement.
                                                                                                          • 0
                                                                                                            Почитал про технологию тут. Не обнаружил там как из нативного кода обладая ссылкой на объект в VM дернуть его метод. Если ткнете носом, буду благодарен.
                                                                                                            • 0
                                                                                                              P/Invoke даёт возможность передавать неуправляемому коду делегат. Т. е. для сишного кода это выглядит как обычный указатель на функцию, который потом CLR разворачивает в нужный вызов.
                                                                                                              • 0
                                                                                                                Это ни разу не то же самое. Для справки JNI это не только вызов нативного кода из VM но и

                                                                                                                — Возможность вызвать любой метод и получить любое свойство у VM объекта
                                                                                                                — Прикрепить или изменит налету реализацию у любого метода Vm объекта, оформленного специальным образом
                                                                                                                — Вообще полностью описать класс в нативном коде и VM будет этим описанием пользоваться, реализация класса же будет в нативной библиотеке

                                                                                                                И поверье в приложениях для Android все это активно используется. Я клоню к тому что нативные библиотеки все= придется переписывать для совместимости с этим чудом.
                                                                                                                • +2
                                                                                                                  IKVM — не транслятор явы в шарп, это ява-машина на базе CLR, которая реализует в т. ч. JNI. О чём спорить, возьмите да попробуйте запустить.
                                                                                                              • 0
                                                                                                                Ну ещё следует понимать, что в CLR есть возможность нормально работать с памятью вручную. В шарпе это выражено как ключевое слово unsafe, внутри блока которого этот управляемый язык превращается, фактически, в обычный C, спокойно перемалывающий указатели, имея при этом доступ к управляемой среде.
                                                                                                                • 0
                                                                                                                  Если я правильно Вас понял, то стоит смотреть на эту статью, чтобы вызывать Managed-методы из неуправляемого кода…
                                                                                                                  Я сам экспериментировал с этим (в частности на iPhone) и это вполне себе работает. Думаю и на андроиде и на других платформах это будет работать аналогично.
                                                                                                      • +9
                                                                                                        между Java и C# перерывчик небольшой
                                                                                                        • +1
                                                                                                          Яву компилять в .NET никогда не было проблемой. Кроме того гугол может сделать транслятор из Dalvik byte code в CIL.
                                                                                                          • +3
                                                                                                            Так пускай бы родными было два языка. Я бы вот с удовольствием писал под Android на C#, была бы недорогая возможность делать это…
                                                                                                            • +1
                                                                                                              $400 не так уж и много…
                                                                                                              • –1
                                                                                                                Это в 2 раза дешевле студии в конце концов.
                                                                                                                • 0
                                                                                                                  Если писать ПО для маркета — нормально. А если для себя поковырять и сделать пару приблуд — как-то жалко :)
                                                                                                                  • 0
                                                                                                                    Для себя можно и через эмулятор ковырять. А приблуды сделайте open source и договоритесь с Мигелем об бесплатной лицензии.
                                                                                                                    • 0
                                                                                                                      Так зачем мне это в эмуляторе? Хочется на своём телефоне использовать.
                                                                                                                      Насчёт лицензии для Open Source видел только чьё-то предложение на uservoice.com выдавать лицензии открытым проектам. Но сам Xamarin вроде как на это ещё не отреагировал.
                                                                                                                      • 0
                                                                                                                        Спишитесь с Мигелем по поводу получения, не думаю, что он пошлёт лесом. Он один из основателей GNOME в конце концов.
                                                                                                                • 0
                                                                                                                  И такая возможность есть. Бесплатно. Но только для владельцев устройств от Sony. (На моём самсунге не взлетело). Всё что для этого надо — это http://www.playstation.com/pss/developer/openbeta/index_e.html. Там конечно много-много-много-много ограничений, но посмотреть как сони переточили монодевелоп под виту и андроид довольно познавательно.
                                                                                                              • +25
                                                                                                                Xamarin уже давно сделал платформу Monodroid, для запуска C# программ на Android устройствах. В том случае это была очередная надстройка над ОС Android, сейчас же они пошли дальше и сделали свою версию ОС. Молодцы чуваки.
                                                                                                                • +1
                                                                                                                  Ну и самое главное — стоимость: Enterprise ($999.00)
                                                                                                                  Enterprise Priority ($2,499.00)
                                                                                                                  Professional ($399.00)
                                                                                                                  Professional Upgrade ($249.00)
                                                                                                                  Enterprise Upgrade ($599.00)
                                                                                                                  Enterprise Priority Upgrade ($1,499.00)
                                                                                                                  • +4
                                                                                                                    Это вы про MonoDroid, наверное, который позволяет писать на C# приложения для оригинального Android?
                                                                                                                    • 0
                                                                                                                      Да-да, не заметил про ОС… Извиняюсь :)
                                                                                                                      • +30
                                                                                                                        Возникает единственный вопрос: откуда у Мигеля столько времени?? Мне кажется иногда что он живет в каком-то своем параллельном мире, где время течет раза в 4 медленнее и иногда мержит изменения в наш
                                                                                                                        • +5
                                                                                                                          Перевод Java -> C# был машинным — они допилил Sharpen и использовали его для перевода. Ализар по какой-то причине выкинул половину блог-поста и перевел только пару предложений.
                                                                                                                          • +44
                                                                                                                            Видимо в той половине не было желтизны
                                                                                                                            • НЛО прилетело и опубликовало эту надпись здесь