Comments 294
Еще бы Google заинтересовалась этой новостью.
Я думаю большие компании просто не могут пропустить мимо внимания это. Если все же пропустят без рассмотрения, то таких ответственных людей надо увольнять.
Я вообще не понимаю зачем там этот Davlic, точнее так, почему нельзя писать программы без него, сейчас у некоторых он нужен только для того что бы загрузить so файлы и передать им управление, а так же взаимодействовать с GPS, камерой, сетью. Выкиньте все это дерьмище и дайте нормальные с++ либы, вся эта Java постоянно мешается только.
Dalvic дает очень важное преимущество, которое для широкого класса приложений превосходит минусы — приложение будет работать на любой архитектуре. И, предположительно, использовать всю мощь.
Гугл контроллирует средства разработки и они бы могли решить проблему архитектур очень просто:
1. Сишка уже сейчас может компиляться под разные архитектуры прозрачно для разработчика.
2. Всё это дело уже сейчас пакуется в APK с разными бинариками.
3. Сделать более умный маркет, который при аплоуде приложения сделает несколько версий APK под разные платформы.
4. Слать юзерам только нужную версию APK без лишних бинариков.
Вуаля, всё работает прозрачно и для программеров и для пользователей. Осталось только реализовать шаги 3 и 4.
1. Сишка уже сейчас может компиляться под разные архитектуры прозрачно для разработчика.
2. Всё это дело уже сейчас пакуется в APK с разными бинариками.
3. Сделать более умный маркет, который при аплоуде приложения сделает несколько версий APK под разные платформы.
4. Слать юзерам только нужную версию APK без лишних бинариков.
Вуаля, всё работает прозрачно и для программеров и для пользователей. Осталось только реализовать шаги 3 и 4.
Как ни крути — это фрагментация.
С таким подходом ява тоже фрагментация — VM-то разная под разные платформы. Но программер её не видит. Сборку он тоже видеть не будет. Работает и жорошо.
Но в случае с C++ именно програмеру придется собирать все это дело под разные платформы. Да и тестировать сложнее будет.
Смысл в том, чтобы не собирать отдельно. Сделать это гуглу не проблема, о чём я и говорю. А тестировать и так надо под кучу девайсов, ничего не поменяется. С каждым годом девайсов и различий всё больше и больше, дополнительные архитектуры погоду не сделают.
Вы не поняли собеседника. Он предлагает, чтобы разработчик грузил исходный код, а Гугл сам тестировал его на совместимость и компилировал/собирал под разные платформы для последующей раздачи в Маркете/Play.
Сборку проекта под несколько архитектур увы не всегда можно автоматизировать. Да и представьте насколько увеличится стоимость разработки.
Google nacl + llvm с вами несогласен.
От того что они не согласны стоимость разработки на C/C++ не уменьшается, количество разработчиков не увеличивается, и необходимость танцев с бубном при некоторых обстоятельствах это не устраняет.
p.s. К слову, а причем тут Google nacl? Насколько я знаю это способ ускорить работу бизнес логики для WEB приложений. Не каждое приложение под андроид можно реализовать через него. Или я не прав?
p.s. К слову, а причем тут Google nacl? Насколько я знаю это способ ускорить работу бизнес логики для WEB приложений. Не каждое приложение под андроид можно реализовать через него. Или я не прав?
getjar.com это решил давно, правда, за счёт разработчика.
Что характерно, Маркет уже вполне умеет работать с несколькими APK под разные девайсы и версии ОС.
DEX-файл в APK является платформонезависимым, а вот зависимыми от платформы могут быть библиотеки в папке lib, внутри APK. К примеру, APK SetCPU содержит в папке lib три подпапки под разные архитектуры — две под разные вариации ARM и одна под x86. Android Terminal Emulator содержит по умолчанию библиотеку для ARM, но есть старая версия ATE для MIPS. В результате я на своем Ainol Novo7 Paladin путем замены оригинальной библиотеки ARM на старую от MIPS получил работающую без Magic Code последнюю версию ATE.
Спасибо, я в курсе как внутри устроены APK :) Раньше Гугл предлагал пихать все в один APК, независимо от целевого девайса, но с относительно недавних пор можно загружать несколько APK одного приложения под разные целевые платформы. Например, чтобы уменьшить их размер, нe поставляя библиотеки под все платформы, a только нужные. Или, например, выгружать версию с ActionBarSherlock под старые версии Android, а для Honeycomb и выше сделать нативный интерфейс на Holo.
Как я понимаю проблему: в С юзер может взять либу которая отлично работает на его архитектуре, процессоре и не факт что эта либа будет работать на устройствах с другой архитектурой. Куча неопытных юзеров выкладывает кучу таких програм на маркет и мы видем в интернете статьи о том что андройд — самая глючная система.
В Java'е пользователь может не думать о совместимости либ вообще. Так же не должен думать о памяти. Ну вы думаю вы и сами знаете/слышали о преимущкествах J перед C.
И я бы не сказал что ВСЕ пакуется с бинарниками. Бинарники используются только для узких мест. Чаще всего это оттестированные либы общего пользования. Для не узких мест джавы вполне хватает.
В Java'е пользователь может не думать о совместимости либ вообще. Так же не должен думать о памяти. Ну вы думаю вы и сами знаете/слышали о преимущкествах J перед C.
И я бы не сказал что ВСЕ пакуется с бинарниками. Бинарники используются только для узких мест. Чаще всего это оттестированные либы общего пользования. Для не узких мест джавы вполне хватает.
так а кто мешает использовать это преимущество? в винде программы на яве тоже работают и для этого не нужен обязательный для всех приложений слой на яве.
>>И, предположительно, использовать всю мощь.
Т.е. Dalvic как-то сам распараллелит ваши приложения и векторизует код под NEON?
Т.е. Dalvic как-то сам распараллелит ваши приложения и векторизует код под NEON?
Именно поэтому я и написал — предположительно.
Так как в этом случае все на совести вирт. машины — допустим появилась новая инструкция, которая за такт делает то, что раньше делали несколько команд.
Тем более, я слышал что такое могут делать некоторые компиляторы для С++, а это значит что при желании это вполне скоро появится и на вирт. машинах.
Так как в этом случае все на совести вирт. машины — допустим появилась новая инструкция, которая за такт делает то, что раньше делали несколько команд.
Тем более, я слышал что такое могут делать некоторые компиляторы для С++, а это значит что при желании это вполне скоро появится и на вирт. машинах.
Хотя, в данном контексте было бы правильнее слово «потенциально».
>> я слышал что такое могут делать некоторые компиляторы для С++
Максимум что они могут делать это смешить детей в песочницах
Максимум что они могут делать это смешить детей в песочницах
>Coding in ASM since 1993
На этом закончим наш спор.
На этом закончим наш спор.
Оптимизация такого рода предполагает знание допустимых латентностей зависимых задач и смены представления данных на более подходящий формат, после чего уже выбирается подходящий алгоритм. Низкоуровневые языки типа «C» не позволяют передать данную информацию при написании кода.
Тупая векторизация простейших циклов много где есть конечно, но это не интересно.
Компиляторов C/C++, которые делают трансформацию данных (для начала), насколько я знаю, нет.
Тупая векторизация простейших циклов много где есть конечно, но это не интересно.
Компиляторов C/C++, которые делают трансформацию данных (для начала), насколько я знаю, нет.
Скажите вот… почему в громких заявлениях приложения на Java используют всю мощь, иногда даже быстрее C приложений, а в итоге имеет то что имеем — тормоза UI, дерганные прокрутки длинных списков, да и вообще общее впечатление от UI — как задумчивая коробка автомат
Некоторые оправдывают это «честным» режимом прорисовки, де iOS и Windows Phone рисуют гуй в отдельном потоке с максимальным приоритетом, а в андройде не так.
Потому что на старых версиях андройда UI рисовался софтварно, в отличии от той же iOS, где это делается через OpenGL.
Как раз простенькую картинку быстрее софтварно отрисовать, чем гонять туда сюда и кучу раз контекст переключать… OpenGL нужен чтобы что-то более сложное рендерить, чем список с элементами.
А вот рендеринг элементов списка в отдельном потоке это куда более важная вещь!
А вот рендеринг элементов списка в отдельном потоке это куда более важная вещь!
Я не в курсе на чем написаны встроенные приложения на Windows Phone, если на C# то они вполне себе быстро работают.
Да, на нём. а работают шустро потому что нет фрагментации и жесткие ограничения платформы.
/Cap_off
/Cap_off
На C++. Используется Silverlight for Windows Embedded.
Вот только странно то, что один и тот же текст, нарисованный одним и тем же шрифтом, сглаживается по разному на нормальном сильверлайте и вышеуказанном.
Вот только странно то, что один и тот же текст, нарисованный одним и тем же шрифтом, сглаживается по разному на нормальном сильверлайте и вышеуказанном.
в тестах была не джава, оракловская джава и даливик в плане оптимизаций это совершенно разные вещи. Я не знаю причин почему их нет в далвике, но примерно те же технологии используются в тестах с моно которые вы увидели, поэтому если бы в тестах сравнивали оракловскую java и далвик разница была бы так же существенна. Возможно это енергопотребление, память еще что-то не знаю. Тест очень синтетический. Использует коллекции дотнета. Не сильно бы я ему верил.
Ключевое слово у «некоторых». Как не крути, а писать на java/c# быстрее и проще, чем на С/С++. К нативному коду обращаются когда возникают проблемы производительности, которые другими путями не решить.
Или когда есть уже написанный нативный код и охота его просто портировать? Что в разы проще, чем всё опять по новой под жабу, C#, HTML5+JS переписывать, нет?
А llvm вполне способен генерить универсальные бинарники.
А llvm вполне способен генерить универсальные бинарники.
Или когда есть уже написанный нативный код и охота его просто портировать?
Такой момент, конечно, имеет место быть, но как он относится к изначальному вопросу о том, почему бы не отказаться от java\C# в реализации userland в пользу нативных библиотек?
Чтобы было проще портироваться дальше?
Портирование это слишком частный и узкий случай, чтобы ради него принимать столь масштабное решение. Если мы отбросим игры, то оставшийся софт всеравно нужно писать отдельно под каждую платформу в соответствии с ее правилами разработки приложений, от UI до взаимодействия с системой.
Меня такой подход ну совсем не устраивает. Тем более, что большая часть любого ПО таки платформонезависима априори. А гуй уж хрен с ним, сделаю в соответствии с HIGом.
Тем более, что большая часть любого ПО таки платформонезависима априори
Где это вы такое априори нашли? Даже не говоря об интеграции с системой, вот например у меня есть приложение календарь, типа iCalc. У меня половина приложения, если не большая это его UI и его логика со всякими спецэффектами.
Меня такой подход ну совсем не устраивает.
Ну когда у вас будет своя платформа, вы сможете забить на финансовую выгоду и делать как вам нравится.
А гуй уж хрен с ним, сделаю в соответствииВы как-то преуменьшает сложность, важность и объем работы для реализации хорошего GUI для мобильной платформы.
Думаю это давать не надо… С С++ куча проблем по сути дела есть только один нормальный способ распространять С++ программы — исходниками. И каждый у себя запустит gcc и получит рабочую версию, а если что-то не линкуется подправит и все равно получит работающую версию…
Компилировать под разные платформы еще то удовольствие и в конце концов получается, что на 1-5 телефонах все равно не работает! Причем падает сразу все приложение, а не по частям, как в Java (ClassNotFoundException).
Мне кажется Google осознал эту проблему и продвигает C язык с трансляцией в LLVM. Вот это правильно! И то что они делают в Chrome тоже правильно. А верить, что все телефоны будут писать одинаковые API к драйверам — глупо и Google их не заставит, поэтому высокоуровневое API (на другом языке) не мешает, а помогает, так как стандартизирует…
Компилировать под разные платформы еще то удовольствие и в конце концов получается, что на 1-5 телефонах все равно не работает! Причем падает сразу все приложение, а не по частям, как в Java (ClassNotFoundException).
Мне кажется Google осознал эту проблему и продвигает C язык с трансляцией в LLVM. Вот это правильно! И то что они делают в Chrome тоже правильно. А верить, что все телефоны будут писать одинаковые API к драйверам — глупо и Google их не заставит, поэтому высокоуровневое API (на другом языке) не мешает, а помогает, так как стандартизирует…
Это другого уровня проблема и проблема говнокодеров не должна причинять неудобств нормальным программистам.
«Проблемы негров шерифа не волнуют»(с)
Говнокодер или нет, когда разработчик не парится над менеджментом памяти, а сразу в бой — разрабатывать бизнес-логику, время и/или стоимость разработки неплохо сокращаются. В managed языках и вообще языках высокого уровня есть смысл. В том числе и в попытке пресечь выстрелы в ногу у разработчиков, у которых недостаточно опыта/времени/денег.
Говнокодер или нет, когда разработчик не парится над менеджментом памяти, а сразу в бой — разрабатывать бизнес-логику, время и/или стоимость разработки неплохо сокращаются. В managed языках и вообще языках высокого уровня есть смысл. В том числе и в попытке пресечь выстрелы в ногу у разработчиков, у которых недостаточно опыта/времени/денег.
Речь идет о том, как уменьшить стоимость разработки и следовательно уменьшить стоимость приложений, что сделает платформу более популярной. Ваш путь предполагаю наличие более опытных и дорогих кадров при том же результате для конечного пользователя, что экономически не выгодно.
Не могу я верить в такой отрыв без анализа причин этого отрыва.
Я конечно их открыл и одним глазом посмотрел.
Причина отрыва по прежнему не ясна :-)
Причина отрыва по прежнему не ясна :-)
Пишут, что за счёт наличия «структур» (Value types) и за счёт другой реализации темплейтных (generic) функций.
«Я ничего не понял, но не верю в производительность C#»
Я Вас огорчу, сам по себе C# имеет нулевую производительность, он при компиляции преобразуется в промежуточные данные, с которыми уже работает «виртуальная машина», так что надо говорить так: «я ничего не понял, но думаю что VM JAVA должна работать быстрей чем VM Mono»
Ну, быстрей — не быстрей, но не в 8 же раз медленне JVM чем VM Mono. Странно это как-то и подозрительно.
Так это смотря на что смотреть, в данном случае, на сколько я понял, противоставляли дотнетовские структуры джавовским классам (в джаве нет структур?), а структуры работают в разы быстрей, и благодаря этому приложение в целом работает быстрей. При разработке можно очень много маленьких классов заменить на структуры, и это даст значительный прирост производительности (до 8 раз в идеале).
В VM Mono другая работа со строчками, другой GC, есть структуры и по-другому сделаны дженерики.
А как влияют дженерики?
В .NET они поддерживаются нормально в JIT, в яве сделаны через костыли для работы в VM тех времён, когда их в языке ещё не было.
Чем отличаются я в курсе. Непонятно, как это отличие влияет на производительность.
new ArrayList().add(1); // боксинг
Вы опоздали, уважаемый, и даже не ответили по сути на вопрос (в вашем коде и дженериков-то нет).
Вы, подозреваю, в курсе, что такой код будет на этапе компиляции заменён на .add(new Integer(1));
Но проблема, как уже докопались в соседней ветке, не в этом, а в том, что get() на List вернёт Object, который надо будет привести обратно к Integer. Результат: затраты на cast.
Вы, подозреваю, в курсе, что такой код будет на этапе компиляции заменён на .add(new Integer(1));
Но проблема, как уже докопались в соседней ветке, не в этом, а в том, что get() на List вернёт Object, который надо будет привести обратно к Integer. Результат: затраты на cast.
Вам про это как раз и намекал ControlFlow
Я не уверен насчет последних версий джавы, но когда я в свое время интересовался, разница была в том, что в джаве на уровне байт-кода никаких дженериков не было, вместо этого объекты с типом типизации превращались в object, а в нужных местах проставлялся каст. В шарпе дженерики реализованы на уровне CLR, так что нет оверхеда с кастом туда обратно. Как я понимаю(возможно ошибочно) особенно это актуально для типизации через value type, т.к. на касте с обджектом мы получаем постоянное боксирование.
> на уровне байт-кода никаких дженериков не было
Так и сейчас, ничего не изменилось. Но как именно это влияет не производительность?
> особенно это актуально для типизации через value type,
> т.к. на касте с обджектом мы получаем постоянное боксирование
Боксирование в Java грубо говоря происходит не в рантайме.
Value types в джава — только примитивы. Дженерики на примитивы не распространяются.
Так и сейчас, ничего не изменилось. Но как именно это влияет не производительность?
> особенно это актуально для типизации через value type,
> т.к. на касте с обджектом мы получаем постоянное боксирование
Боксирование в Java грубо говоря происходит не в рантайме.
Value types в джава — только примитивы. Дженерики на примитивы не распространяются.
Дженерики на примитивы не распространяются.
Т.е. List в джаве написать нельзя?
Но как именно это влияет не производительность?
Операция каста и динамических проверок процессорного времени не отнимают?
> Т.е. List в джаве написать нельзя?
List не может содержать примитивы, только Object.
> Операция каста и динамических проверок процессорного времени не отнимают?
Интересно, что у вас «каст» и «данимические проверки» как отдельные вещи (-;
Отнимают, конечно, но так ли много?
List не может содержать примитивы, только Object.
> Операция каста и динамических проверок процессорного времени не отнимают?
Интересно, что у вас «каст» и «данимические проверки» как отдельные вещи (-;
Отнимают, конечно, но так ли много?
Отнимают, конечно, но так ли много?
В цикле сложения всех элементов списка они займут 95% времени.
Ваш вопрос изначально был в том «как влияют», а не насколько. Численную оценку надо устанавливать экспериментально, будет здорово если вы проведете такое измерение и опубликуете результаты.
Вы похоже недооцениваете этот «каст». На самом деле это означает следующее — в массиве у вас хранится не само число, а ссылка на него. Это уже двойное потребление памяти. А если еще представить что у вас какие то элементы удаляются, а какие то добавляются, то вы получаете в управляемой куче большое кол-во недоступных объектов, на уничтожение которых сборщику мусора приходится тратить дополнительное время.
В случае же с дженериками .Net'a компилируются классы для каждого значимого типа в отдельности — т.е. все выделения памяти происходят на стеке, и вы экономите очень большое кол-во времени на сборках мусора и дополнительной работе с памятью.
В случае же с дженериками .Net'a компилируются классы для каждого значимого типа в отдельности — т.е. все выделения памяти происходят на стеке, и вы экономите очень большое кол-во времени на сборках мусора и дополнительной работе с памятью.
> в массиве у вас хранится не само число, а ссылка на него
В массивах в Java какраз можно держать примитивы.
Речь шла о List, и не обязательно List врапперов для примитивов, а любой List, с сылками на сложные объекты например — не врапперы для примитивов.
> В случае же с дженериками .Net'a…
>… все выделения памяти происходят на стеке
Для коллекций примитивов и структур? Ну, с структурами вопросов особо и не было.
В массивах в Java какраз можно держать примитивы.
Речь шла о List, и не обязательно List врапперов для примитивов, а любой List, с сылками на сложные объекты например — не врапперы для примитивов.
> В случае же с дженериками .Net'a…
>… все выделения памяти происходят на стеке
Для коллекций примитивов и структур? Ну, с структурами вопросов особо и не было.
Если я правильно понял, то в C#
List fooList;
это нечто похожее на шаблоны в плюсах, то есть, VM знает о том, что это новый тип List а в Java
List превращается в
List
List fooList;
это нечто похожее на шаблоны в плюсах, то есть, VM знает о том, что это новый тип List а в Java
List превращается в
List
Чертов парсер
и
соответственно
List<Foo> fooList;
и
List<Object> fooList;
соответственно
>Речь шла о List
Простите, оговорился. Конечно же я имел ввиду List. Просто в C# между ними нету такой великой разницы — и то и то класс, но у масивов есть поддержка состороны синтаксиса языка.
Да в шарпе это подобие шаблонам, за исключением того, что там строгий контроль типов на уровне самого шаблона, а не при его использовании. За счет этого есть и минусы (меньшая гибкость) и плюсы (кроме самого контроля типов еще и уменьшение объема кода после компиляции — для каждого ссылочного типа генерируется только 1 реализация класса и т.д.)
Простите, оговорился. Конечно же я имел ввиду List. Просто в C# между ними нету такой великой разницы — и то и то класс, но у масивов есть поддержка состороны синтаксиса языка.
Да в шарпе это подобие шаблонам, за исключением того, что там строгий контроль типов на уровне самого шаблона, а не при его использовании. За счет этого есть и минусы (меньшая гибкость) и плюсы (кроме самого контроля типов еще и уменьшение объема кода после компиляции — для каждого ссылочного типа генерируется только 1 реализация класса и т.д.)
Дженерики с аргументами типов, являющимися ссылочными типами, работают аналогично джавовым (единственное отличие в этом месте — отсутствие type erasure). А вот дженерики с аргументами типов, являющимися value types — работают без боксинга, в отличие от джавовых аналогов.
Итого, есть 2 отличия в дженериках: type erasure и поддержка value-types. Первое на производительность не влияет, а вот второе — влияет.
Итого, есть 2 отличия в дженериках: type erasure и поддержка value-types. Первое на производительность не влияет, а вот второе — влияет.
Почему не поддерживают? Просто она там особенным образом реализована. Или что именно имеется в виду?
Ничего удивительного, .net машины часто превосходят машины java по производельности на синтетических тестах.
А на мобильных устройствах думаю вариантов оптимизаций еще предостаточно.
Но это просто отлично! Вполне возможно это подтолкнет Google оптимизировать свою машину.
Интересно, когда появятся .net сборки доступные для широких масс…
А на мобильных устройствах думаю вариантов оптимизаций еще предостаточно.
Но это просто отлично! Вполне возможно это подтолкнет Google оптимизировать свою машину.
Интересно, когда появятся .net сборки доступные для широких масс…
Вообще тот график где показывает отрыв очень хитрый. В Mono реализация на более лёгких структурах вместо объектов.
А что мешало в Java это сделать на структурах и аллоцировать их на стеке?
То, что в джава нет структур.
А что мешает их добавить? Хотя бы как расширение для Dalvik'а.
То, что это уже будет переJava-недоC#.
Добавит их значило бы создать свой язык на основа Java. Туда еще очень много чего можно было бы добавить, но, как я понимаю, политика гугла как раз заключалась в том, чтобы поддержать java стандарт, а не создавать новый язык. К тому же надо еще посчитать, что дешевле — править виртуальную машину, IDE и компилятор или просто подставить mono vm и запустить старые приложения через IKVM.
В этом весь смысл статьи, что в дотнете есть инструменты, позволяющие писать более быстрый код, относительно жавы в целом и андроида в частности.
«C# went from being a slightly better Java to be light-years ahead. „(с)
«C# went from being a slightly better Java to be light-years ahead. „(с)
Ещё они обращение к графике поменяли: убрав лишнее звено (Java) реализовав через P/Invoke
Расскажите несведущему, где такие архитектурные ограничения Dalvik, которые решит Mono?
Дотнетный рантайм эффективнее явовского по скорости by-design. Это даже тесты IKVM показывают.
А можно по-подробнее?
Я ничего лучше этого не видел. При этом у них результаты для разных реализаций в рамках одного языка зачастую отличаются в десять раз. Тем не менее есть серьезные подозрения, что дело не в Java «by-design», а в Google «by-hands».
Я ничего лучше этого не видел. При этом у них результаты для разных реализаций в рамках одного языка зачастую отличаются в десять раз. Тем не менее есть серьезные подозрения, что дело не в Java «by-design», а в Google «by-hands».
Код, а так же версию и опции моновского рантайма я там не увидел. Прозреваю, что это было Mono 2.6 с профилем для десктопов.
Вот лог запуска одной из бенчмарк, там видны версия и опции (точнее, их отсутствие):
shootout.alioth.debian.org/u32/program.php?test=binarytrees&lang=csharp&id=2#log
shootout.alioth.debian.org/u32/program.php?test=binarytrees&lang=csharp&id=2#log
Ну замечательно. Использовали моновский компилер C# первого поколения, который не обновлялся сто лет уже, Boehm GC, вместо которого уже давно рекомендуют использовать SGen, и не использовали никаких флагов, включающих оптимизации JIT. Зато яву запустили в серверном режиме.
Q. E. D.
Q. E. D.
А напишите, с какими параметрами надо компилировать/запускать, хочется самому потестить.
Для начала тест следует хотя бы привести к корректному состоянию, ибо сейчас он что для явы, что для Mono считает попугаев, т. к. замеряет в т. ч. загрузку рантайма, библиотек и время работы JIT, что в нормальном приложении происходит один раз на старте. Сейчас если включить в Mono AOT-кэш сборок (устанавливается в переменной окружения MONO_AOT_CACHE, dll-ки компилируются в машинный код один раз, нативные бинарники лежат в ~/.mono/aot-cache), то тест покажет совершенно иные результаты, но они всё равно будут некорректны. По-хорошему же надо вынести весь код теста в функцию, прогнать её один раз, после чего вызвать снова и уже тогда считать затраченное время.
А вообще компилить следует gmcs (а лучше компилятором от MS), использовать параметры -O=all --gc=sgen, в идеале ещё и само Mono собрать с поддержкой LLVM, тогда, соответственно, добавить параметр --llvm. Ну вот как-то так.
А вообще компилить следует gmcs (а лучше компилятором от MS), использовать параметры -O=all --gc=sgen, в идеале ещё и само Mono собрать с поддержкой LLVM, тогда, соответственно, добавить параметр --llvm. Ну вот как-то так.
Ну дайте ссылки хотя бы на эти тесты, и расскажите что именно там эффективнее.
Я не могу в куче мусора найти что-нибудь вменяемое пока.
Я не могу в куче мусора найти что-нибудь вменяемое пока.
Вообще-то, Dalvik — не JVM, у него совершенно иная архитектура.
Из моего опыта написания игрушек — Java имеет одно очень важное ограничение by design.
Там нет структур (struct в C#), тоесть обьектов, память для которых выделяется в стеке и которые передаются by value.
В играх это супер критично — Vector, Matrix, Color — все часто создаваемые и удаляемые обьекты создаються на стеке чтоб избежать генерации мусора.
Там нет структур (struct в C#), тоесть обьектов, память для которых выделяется в стеке и которые передаются by value.
В играх это супер критично — Vector, Matrix, Color — все часто создаваемые и удаляемые обьекты создаються на стеке чтоб избежать генерации мусора.
Да. Цифры говорят сами за себя.
Что намного важнее со struct — не скорость в абстрактных тестах, а то что они при создании-удалении не фрагментируют кучу. А GarbageCollector хоть быстрый и умный, но при полном проходе он приостанавливает выполнение программы, а в играх регулярное зависание даже на 50мс будет очень заметно.
Что намного важнее со struct — не скорость в абстрактных тестах, а то что они при создании-удалении не фрагментируют кучу. А GarbageCollector хоть быстрый и умный, но при полном проходе он приостанавливает выполнение программы, а в играх регулярное зависание даже на 50мс будет очень заметно.
Думаю RenderScript решит эти проблемы и может быть будет быстрее, чем Mono ;)
Google на это не пойдет
А зря, особенно если Oracle создаст прецедент.
Хотя, опять же, если Oracle выиграет, поверх новой виртуальной машины они Dalvic, для совместимости с существующими приложениями не смогут поставить.
Код на яве можно через IKVM перекомпилять в дотнетные dll-ки, делов-то.
Почему не надо? На моно есть кошерный F#, кодить на котором несравненно большее удовольствие, чем на унылой жабке.
Почему? Купят их с потрохами и переведут андроид на моно. Это, конечно, крутой поворот, но всякое может быть.
Подавятся покупать :)
Скорее купят, и продадут.
Та не. Именно что подавятся. Гугл не настолько крупен чтобы купить оракл, если верить волфрамАльфа
www.wolframalpha.com/input/?i=google+oracle
www.wolframalpha.com/input/?i=google+oracle
Кстати ещё в блоге у них написано, что уже до 4.0 проапгрейделись
а как же приложения? сообщество не захочет переучиваться на С#, приложение не станут переписывать
Как я понимаю, нативные (C++) и так будут работать. Java будут можно через Sharpen перегнать.
А я так понимаю что они (нативные) таки отвалятся. Там же все через JNI сделано. Нет Java машины — нет JNI. К сожалению не в курсе позволяет .NET VM добавлять к .NET классам нативный код.
1) в C# есть P/Invoke
2) JNI при запуске под IKVM работает, т. е. реализация для CLR уже есть.
2) JNI при запуске под IKVM работает, т. е. реализация для CLR уже есть.
То что что-то есть это хорошо. Правда надо почитать какое оно и насколько удобно (тут кстати JNI плохой пример для подражания)
По второму пункту как-то не очень понял. Вы заявляете что уже собранная библиотека будет без проблем работать? Как-то с трудом верится, учитывая что JNI учитывает специфику Java VM которой в .NET VM просто не будет.
По второму пункту как-то не очень понял. Вы заявляете что уже собранная библиотека будет без проблем работать? Как-то с трудом верится, учитывая что JNI учитывает специфику Java VM которой в .NET VM просто не будет.
P/Invoke позволяет работать с любой библиотекой на С (не С++, с ним сложнее всё). По поводу JNI, новость о поддержке в IKVM была ещё 2004-ом году. Вообще говоря они позиционируют IKVM помимо всего прочего как drop-in replacement.
Почитал про технологию тут. Не обнаружил там как из нативного кода обладая ссылкой на объект в VM дернуть его метод. Если ткнете носом, буду благодарен.
P/Invoke даёт возможность передавать неуправляемому коду делегат. Т. е. для сишного кода это выглядит как обычный указатель на функцию, который потом CLR разворачивает в нужный вызов.
Это ни разу не то же самое. Для справки JNI это не только вызов нативного кода из VM но и
— Возможность вызвать любой метод и получить любое свойство у VM объекта
— Прикрепить или изменит налету реализацию у любого метода Vm объекта, оформленного специальным образом
— Вообще полностью описать класс в нативном коде и VM будет этим описанием пользоваться, реализация класса же будет в нативной библиотеке
И поверье в приложениях для Android все это активно используется. Я клоню к тому что нативные библиотеки все= придется переписывать для совместимости с этим чудом.
— Возможность вызвать любой метод и получить любое свойство у VM объекта
— Прикрепить или изменит налету реализацию у любого метода Vm объекта, оформленного специальным образом
— Вообще полностью описать класс в нативном коде и VM будет этим описанием пользоваться, реализация класса же будет в нативной библиотеке
И поверье в приложениях для Android все это активно используется. Я клоню к тому что нативные библиотеки все= придется переписывать для совместимости с этим чудом.
Ну ещё следует понимать, что в CLR есть возможность нормально работать с памятью вручную. В шарпе это выражено как ключевое слово unsafe, внутри блока которого этот управляемый язык превращается, фактически, в обычный C, спокойно перемалывающий указатели, имея при этом доступ к управляемой среде.
Если я правильно Вас понял, то стоит смотреть на эту статью, чтобы вызывать Managed-методы из неуправляемого кода…
Я сам экспериментировал с этим (в частности на iPhone) и это вполне себе работает. Думаю и на андроиде и на других платформах это будет работать аналогично.
Я сам экспериментировал с этим (в частности на iPhone) и это вполне себе работает. Думаю и на андроиде и на других платформах это будет работать аналогично.
Яву компилять в .NET никогда не было проблемой. Кроме того гугол может сделать транслятор из Dalvik byte code в CIL.
Так пускай бы родными было два языка. Я бы вот с удовольствием писал под Android на C#, была бы недорогая возможность делать это…
$400 не так уж и много…
Это в 2 раза дешевле студии в конце концов.
Если писать ПО для маркета — нормально. А если для себя поковырять и сделать пару приблуд — как-то жалко :)
Для себя можно и через эмулятор ковырять. А приблуды сделайте open source и договоритесь с Мигелем об бесплатной лицензии.
Так зачем мне это в эмуляторе? Хочется на своём телефоне использовать.
Насчёт лицензии для Open Source видел только чьё-то предложение на uservoice.com выдавать лицензии открытым проектам. Но сам Xamarin вроде как на это ещё не отреагировал.
Насчёт лицензии для Open Source видел только чьё-то предложение на uservoice.com выдавать лицензии открытым проектам. Но сам Xamarin вроде как на это ещё не отреагировал.
И такая возможность есть. Бесплатно. Но только для владельцев устройств от Sony. (На моём самсунге не взлетело). Всё что для этого надо — это http://www.playstation.com/pss/developer/openbeta/index_e.html. Там конечно много-много-много-много ограничений, но посмотреть как сони переточили монодевелоп под виту и андроид довольно познавательно.
Xamarin уже давно сделал платформу Monodroid, для запуска C# программ на Android устройствах. В том случае это была очередная надстройка над ОС Android, сейчас же они пошли дальше и сделали свою версию ОС. Молодцы чуваки.
Ну и самое главное — стоимость: 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)
Enterprise Priority ($2,499.00)
Professional ($399.00)
Professional Upgrade ($249.00)
Enterprise Upgrade ($599.00)
Enterprise Priority Upgrade ($1,499.00)
Это вы про MonoDroid, наверное, который позволяет писать на C# приложения для оригинального Android?
Да-да, не заметил про ОС… Извиняюсь :)
Возникает единственный вопрос: откуда у Мигеля столько времени?? Мне кажется иногда что он живет в каком-то своем параллельном мире, где время течет раза в 4 медленнее и иногда мержит изменения в наш
Перевод Java -> C# был машинным — они допилил Sharpen и использовали его для перевода. Ализар по какой-то причине выкинул половину блог-поста и перевел только пару предложений.
Тогда уж в параллельном мире время течёт раз в десять быстрее, чем в нашем :)
Ну там же Мигель — не единственный разработчик… и, насколько мне известно, они все время расширяют свой штат сотрудников…
<irony>Однако, компания Xamarin — знатные тролли :)</irony>
Увы, без поддержки Google этот проект скорее всего обречён только побеждать в подобных тестах, но не более того.
Увы, без поддержки Google этот проект скорее всего обречён только побеждать в подобных тестах, но не более того.
Для Xamarin этот проект более исследовательский чем коммерческий. В ходе его написания они как минуим:
1) Улучшили Sharpen
2) Вытащили работу с графикой, до этого графика в MonoDroid шла через яву, теперь напрямую.
1) Улучшили Sharpen
2) Вытащили работу с графикой, до этого графика в MonoDroid шла через яву, теперь напрямую.
Если Google решит платить патентным ораклам и не поддержит этот проект, то я надеюсь его поддержит кто-нибудь другой, вроде Barnes & Nobles/Amazon/Samsung/HTC/Microsoft или может даже Яндекс. Даёшь Яндекс-фоны в массы! :)
Учитывая такую огромную разницу в производительности, как на графике, возможно стоит сделать теперь наоборот — поставить Java DalvikVM поверх Mono. Может он будет работать даже быстрее, чем в оригинале. Так достигнется и скорость Mono, и совместимость Java. Разве нет?
Может я что-то недопонимаю, но «Android на C#» звучит так, будто ОС написана на этом языке. Наверное, лучше «Android с поддержкой C#» или «Android с C# вместо Java».
В оригинале, кстати: «porting Android 4.0 from Java/Dalvik to C#»
В оригинале, кстати: «porting Android 4.0 from Java/Dalvik to C#»
One crazy idea that the team had at that dinner was to translate Android’s source code to C#
Всё, что поверх ядра, я полагаю, они переписали на C#.
Уверен, что нет. Там миллионы строк кода. Может автоматически транслировали — э то да, но точно не «переписали».
Всё так и есть и об этом написано как на офсайте в оригинальной статье, так и в этом топике.
Но, я думаю, что без «допиливания» не обошлось.
Но, я думаю, что без «допиливания» не обошлось.
Автоматическую конвертацию более миллиона строк Java-кода Android 2.x провели с помощью улучшенной версии Sharpen.
Java Translation via Sharpen
Android’s core codebase contains over a million lines of Java code, and we knew we wanted to be able to stay up to date with new releases of Android — in fact, we started with the Android 2.x source code back in 2011, and then upgraded XobotOS to Android 4.0 when Google open sourced Ice Cream Sandwich earlier this year. So for us, the only reasonable option was to do a machine translation of Java to C#, building and maintaining any necessary tools along the way.
The tool we used as a starting point is called Sharpen. Sharpen is famous for helping people such as Frank Krueger port a Java applet to an award-winning iPad app in two months.
We matured Sharpen a lot, and the result is a much-improved Java-to-C# translation tool for everyone. We are releasing this new version of Sharpen today along with the code for XobotOS and we hope that many more people will benefit from it and contribute to it.
Поддержка C# это MonoDroid, она давно есть и используется. Тут же говорят именно про Android ICS который работает без java на Mono.
> Может я что-то недопонимаю, но «Android на C#» звучит так, будто ОС написана на этом языке.
Так и есть.
> Может я что-то недопонимаю, но «Android на C#» звучит так, будто ОС написана на этом языке.
Так и есть.
Ага linux kernel тоже на C# переписали.
причем здесь ядро? или оно по вашему на java написано?
я гляжу, для особо одаренных придется расставлять тег <sarcasm>
«Пейсатель» выше говорить что:
Так вот Dalvik VM это ни разу не ОС Android
ОС Android есть кастомный дистр на ядре Linux которое написано на С
и еще различные libc и прочие binutils, которые также написаны на C и C++.
Так что говорить о том что Android переписали на C# как минимум неккоректно,
а в целом просто тупо.
«Пейсатель» выше говорить что:
> Может я что-то недопонимаю, но «Android на C#» звучит так, будто ОС написана на этом языке.
Так и есть.
Так вот Dalvik VM это ни разу не ОС Android
ОС Android есть кастомный дистр на ядре Linux которое написано на С
и еще различные libc и прочие binutils, которые также написаны на C и C++.
Так что говорить о том что Android переписали на C# как минимум неккоректно,
а в целом просто тупо.
Так вот Dalvik VM это ни разу не ОС Android
Так они и не Dalvik переписали на c#. Он взяли Java часть андроида (большая часть userland'a, если вообще не вся за исключением пары библиотек типа bionic, ssl, webkit, ogl, и еще пары частей) и заменил ее на Mono. В данном контексте Andoroid означает Android Runtime. А весь UI крутится как раз в этом рантайме.
Так как никто не мешает взять FreeBSD ядро, написать драйвера и заменить весь userland на фряшный и никто не заметит изменений (ну кроме резкого повышения производительности и то, что телефон теперь 2 дня работает без зарядки, а не 2 часа, ну и пары сердечный приступов на лоре)
Они _всю_ _java_ заменили на _c#_, а _dalvik_ на то, что там в их modo.
Ничего удивительного. Если, например, почитать историю создания IronPython здесь, то там есть такое
I first learned about the CLR by reading countless reports on the web that said it was a terrible platform for dynamic languages in general and for Python in particular. IronPython started life as a series of quick prototypes to help me understand how this platform could be so bad. My plan was to prototype for a couple of weeks and then write a pithy paper titled, “Why the CLR is a terrible platform for dynamic languages.” This plan was turned upside down when the prototypes turned out to run very well—generally quite a bit faster than the standard C-based Python implementation.
Извиняюсь за нубский вопрос, а нельзя каким-нибудь «Sharpen'ом» гнать в компилируемый язык? Тогда будет работать еще быстрее.
гнать в компилируемый языкТОЛСТО
В 2012 году еще остались люди, которые считают, что IL-код интерпретируется?
Поправка: компилируемый в нативный код, а не в байт-код. Не дописал малость.
Вас минусуют за то, что вы не знаете, что IL just-in-time, а в Mono даже ahead-of-time компилируется в нативный код, оптимизированный под архитектуру, на которой он выполняется.
Натравите NGen/Mono AOT и будет сразу на диске сборка в нативном коде. Собственно говоря все либы самого фреймворка им и обрабатываются при установке.
Тссссс… Из-за них у нас хорошие зарплаты…
Странно, что график в посте показывает такие синтетические характеристики.
Было бы интересно поглядеть, например, на результаты прогона каких-нибудь живых бенчмарков или узнать как изменилось время загрузки системы.
Было бы интересно поглядеть, например, на результаты прогона каких-нибудь живых бенчмарков или узнать как изменилось время загрузки системы.
Я сервер майнкрафта ванильный (bukkit работать отказался) запускал под Mono с использованием IKVM. Жрало памяти процентов на 20 меньше, а нагрузка на CPU сократилась на 20-25%, не говоря уже о более редких подвисаниях сервера из-за необходимости запуска GC. Mono 2.10.8, опции запуска --gc=sgen -O=all.
Надеюсь, теперь андройдом можно будет пользоваться два дня!
Ну вот когда начнут на телефоны это ставить, тогда да, возможно.
Мой Mozart дня 4 держит зарядку в среднем. Это примерно 30-40 минут игры в день во что нибудь (метро), 3-5 звонков (5-7 минут) + мелочи типа погоды, почты и всяких там напоминаний. 3G включаю только когда в инет ползу, в остальное время просто edge. Я понимаю что это не активное пользование, но 4 дня это тоже не мало. Сколько протянет устройство на андройд при аналогичном использовании, с таким же экраном, производительностью и дохленьким аккумулятором?
Кстати, по началу больше 1 дня не выдерживал, потом постепенно разошелся. Уж не знаю из-за того что я им начал пользоваться реже, или же все таки поначалу он был дохлее.
Кстати, по началу больше 1 дня не выдерживал, потом постепенно разошелся. Уж не знаю из-за того что я им начал пользоваться реже, или же все таки поначалу он был дохлее.
Нда… такое бывает, большие компании принимают изначально неверные стратегические решения.
Правда может производительность их волновала меньше, чем финансовые риски, успешность судов против Микрософта возможно была бы ниже, чем против Оракла. Хотя вот ксамаринов еще не задушили, несмотря на коммерциализацию «чужих идей».
Правда может производительность их волновала меньше, чем финансовые риски, успешность судов против Микрософта возможно была бы ниже, чем против Оракла. Хотя вот ксамаринов еще не задушили, несмотря на коммерциализацию «чужих идей».
Ну, Википедия говорит: «платформа Mono была официально признана реализацией .NET на Unix-подобных операционных системах», так что с этим проблем не наблюдается.
а андроид на mono — мечта сишарписта =)
а андроид на mono — мечта сишарписта =)
Вообще-то Mono — это свободная система и если бы вы внимательно читали, то увидели, что Microsoft стандартизировал язык ECMA. Кстати недавно они и ASP.NET открыли для свободного доступа.
Microsoft поддерживает Mono, даже код донейтят время от времени.
Unlike Sun with Java, Microsoft submitted C# and the .NET VM for standardization to ECMA and saw those standards graduated all the way to ISO strong patent commitments. The .NET framework is also covered by Microsoft’s legally binding community promise.
Чудеса конечно, Microsoft перестала быть корпорацией зла.
Чудеса конечно, Microsoft перестала быть корпорацией зла.
Чтобы что-то признали стандартом, необходимо как минимуму 2 независимых реализации. Mono появился именно так, это всё хитрый план =) Ну а потом то что осталось подхватили энтузиасты и пилят параллельно, MS даже помогает.
А о чём график вообще? Там написано times in seconds. Это что значит? Левые числа — это что такое? Просто если это «раз в секунду», то Dalvik рвёт Mono как тузик грелку.
не раз в секунду, а время в секундах :)
Вообще, TiGR прав в том смысле, что здесь использовано множественное число существительного «time», которое можно перевести либо «разы», либо «времена». Если «разы», то должно быть "per seconds", если «времена» — то какие? Что они имели в виду? Я прочитал оригинал и всё равно не понял, почему они использовали «times» вместо «time». Только по восторгу по отношению к графику можно предположить, что это просто опечатка.
Одного меня смутило «Mono — это open source реализация фреймворка .NET, которая позволяет писать приложения на языке C# для Android и iOS.»?
Хотел бы добавить, для конечного пользователя приложений, написанных с использованием Mono Runtime, существует один недостаток. С каждым приложений связывается статически Mono Runtime, а это 4,4 М на данный момент, и если он будет иметь например n приложений, написанных с использованием Mono, то количество потерянной памяти на устройстве будет (n-1)*4.4. Я к сожалению не знаю используются ли механизмы map инга файлов в процессе запуска приложений или другие механизмы расшаривающие работу Mono Runtime, но если они не используются, то тогда и в оперативке память будет таким же образом расходоваться.
Для нормального совместного использования оперативки все либы фреймворка:
а) должны быть в GAC
б) по ним должен был пройтись AOT-компилятор, создав к ним нативные .so-шки
а) должны быть в GAC
б) по ним должен был пройтись AOT-компилятор, создав к ним нативные .so-шки
AOT создаст ооочень большие проблемы на слабых моделях, которых у аднройда большая часть сегмента. Я думаю лучшей альтернативой может стать кэширующий JIT компилятор. Результаты JIT компиляции должны сохраняться между перезапусками программы, это даст тот же эффект, что и AOT, но с некоторым запозданием и без излишней нагрузки на процессор.
AOT создаст ооочень большие проблемы на слабых моделях, которых у аднройда большая часть сегментаКаким образом? Какая разница, генерит код JIT в рантайме или при установке фреймворка?
Он не знает, что такое АОТ и забанили в гугле.
Я не про фрейморк, а про приложение. При первом запуске AOT вызовет батхерт у пользователя слабых устройств. А стандартные библиотеки ядра и так поставляются в бинарниках их не нужно компилить вообще. А если фреймворк является частью приложения, а не ядра, то ситуация аналогична. Такое возможно если поставлять фрейморки в виде бандлов к системе, но тут появляются вопросы о совместимости библиотек разных версий… Ну короче, опять каша и даже еще большая, чем есть сейчас. Не думаю, что андройд разрабатывают люди глупее вас.
Из оракла, да в микрософт вляпаться? Ява вообще открыта под опенсорс лицензией, однако это не становится автоматической защитой от патентных исков. Был бы патент, а иск придумают. Я думаю, что гуглы уже не рады, что связались с явой (хотя сами виноваты, что не захотели договориться с SUN за смешные деньги, когда была такая возможность), и от с# они будут держаться подальше.
На C# и CLR есть стандарт ECMA, не позволяющий троллить использующих их реализации. Покажите мне такой стандарт для Java и JVM.
Было бы что отсуживать, а патенты найдутся. А широкий жест со стороны микрософта это да, кмк они действительно уже давно не такая уж и корпорация зла. Опять же возможно, что популяризация и универсализация языка/платформы им более выгодна, чем доходы от патентных исков.
Кстати, сдается мне под вин8 на рынке мобильных устройств и приложений с# будет таким же мейнстримовым языком как Java под андроид и привлекать нужно не только потребителей, но и разработчиков, а патентные войны наверное этому не способствуют.
ЗЫ огромное непаханое поле мобильных устройств и приложений. Не терпится увидеть как будет протекать микрософтовская экспансия.
Кстати, сдается мне под вин8 на рынке мобильных устройств и приложений с# будет таким же мейнстримовым языком как Java под андроид и привлекать нужно не только потребителей, но и разработчиков, а патентные войны наверное этому не способствуют.
ЗЫ огромное непаханое поле мобильных устройств и приложений. Не терпится увидеть как будет протекать микрософтовская экспансия.
С того, что можно отсудить с андройда, мелкомягкие и так имеют отчисления. А с реализаций стандартизированного языка и рантайма стрясти ничего нельзя.
К самому языку нет, но могут прицепиться, например, к реализации конкретных классов.
Имхо свинья грязи найдет. Если не ошибаюсь, этому и посвящены последние серии мыльной оперы бодания с Ораклом — авторство каких то конкретных кусков кода.
Имхо свинья грязи найдет. Если не ошибаюсь, этому и посвящены последние серии мыльной оперы бодания с Ораклом — авторство каких то конкретных кусков кода.
Авторство какихто кусков кода — лишь малая часть айсберга. Кстати кажется на Хабре была статья/ссылка обьяссняющая весь сыр-бор Гугла и Оракла. Главные притензии — 1) Гугл не полностью поддерживает стандарт Java, 2) Гугл за свою реализацию джавы должен был сделать лицензионные отчисления Сану но так и не сделал этого (не договорились).
Советую поискать, почитать.
Советую поискать, почитать.
По ссылке выше, я вижу, что мелкомягкие не только пообещали не трогать реализации дотнета, но своё обещание ещё стандартом на все критичные части подкрепили. Оракл никому ничего не обещает, ещё и название Java требует лицензировать, и вообще ведёт себя нехорошо. Стандарта, который я просил показать, по вашей ссылке я так и не увидел. К чему она была в ответе на мой комментарий?
> пообещали не трогать реализации дотнета
Смотрите выше про договор с Novell.
> на все критичные части подкрепили
BCL — не критичная часть?
> Стандарта, который я просил показать, по вашей ссылке я так и не увидел
Потому что именно такого стандарта, у Майкрософт на CLI+CIL, нет. И, соответственно, никто вам не покажет ничего другого.
Смотрите выше про договор с Novell.
> на все критичные части подкрепили
BCL — не критичная часть?
> Стандарта, который я просил показать, по вашей ссылке я так и не увидел
Потому что именно такого стандарта, у Майкрософт на CLI+CIL, нет. И, соответственно, никто вам не покажет ничего другого.
BCL — не критичная часть?Вас в гугле забанили? BCL стандартизирована в ECMA 335 и ISO/IEC 23271:2006. Список стандартизированных неймспейсов можно увидеть тут.
Всего-навсего цитирую вики:
«The .NET platform as a whole has not been standardized. International standards organizations Ecma International and ISO/IEC define the standard for the .NET executable environment (known as the Common Language Infrastructure, or CLI), and .NET executable format (known as Common Intermediate Language, or CIL), but excluding most of the foundation classes (the Base Class Library, or BCL).»
«The .NET platform as a whole has not been standardized. International standards organizations Ecma International and ISO/IEC define the standard for the .NET executable environment (known as the Common Language Infrastructure, or CLI), and .NET executable format (known as Common Intermediate Language, or CIL), but excluding most of the foundation classes (the Base Class Library, or BCL).»
А лучше даже абзацем выше: en.wikipedia.org/wiki/Comparison_of_the_Java_and_.Net_platforms#Standardization
To date, no part of Java has been standardized by Ecma International, ISO/IEC, ANSI, or any other third-party standards organizationТак где стандарт-то? Зачем вы в меня этими ссылками кидаетесь? Надеетесь, что английский плохо знаю и читать не буду?
> Так где стандарт-то?
Повторюсь: именно такого стандарта, у Майкрософт на CLI+CIL, нет. И, соответственно, никто вам не покажет ничего другого.
> Зачем вы в меня этими ссылками кидаетесь?
Вы задали вопрос о сравнении открытости Java и C#/.NET — вот вам ответ. Или вам «стандарт или нчего»?
Ну, тогда ничего.
> Надеетесь, что английский плохо знаю и читать не буду?
Чего? Давайте параноить не будем.
Повторюсь: именно такого стандарта, у Майкрософт на CLI+CIL, нет. И, соответственно, никто вам не покажет ничего другого.
> Зачем вы в меня этими ссылками кидаетесь?
Вы задали вопрос о сравнении открытости Java и C#/.NET — вот вам ответ. Или вам «стандарт или нчего»?
Ну, тогда ничего.
> Надеетесь, что английский плохо знаю и читать не буду?
Чего? Давайте параноить не будем.
Да вы же упоротый. Большая часть BCL стандартизирована в ECMA 335 и ISO/IEC 23271:2006, я это уже. CLR стандартизирована. C# стандартизирован. В яве не стандартизировано ничего.
Повторю
> Или вам «стандарт или нчего»? Ну, тогда ничего.
Но не всё в ECMA стандарт упирается.
Я вижу вам фанатично требуется доказать, что .NET — открытая платформа, и Mono тому подтверждение, а JCP, сторонние JVM (IBM, JRockit), OpenJDK и т.д. ничего не стоят. Ну что ж, это ваша точка зрения — имеете на неё полное право.
Т.к. в «благодарность» за ответ на ваш вопрос вы решили мне нахамить, на сим общение наше прекращается.
> Или вам «стандарт или нчего»? Ну, тогда ничего.
Но не всё в ECMA стандарт упирается.
Я вижу вам фанатично требуется доказать, что .NET — открытая платформа, и Mono тому подтверждение, а JCP, сторонние JVM (IBM, JRockit), OpenJDK и т.д. ничего не стоят. Ну что ж, это ваша точка зрения — имеете на неё полное право.
Т.к. в «благодарность» за ответ на ваш вопрос вы решили мне нахамить, на сим общение наше прекращается.
Вон, гугл тоже так думали когда Dalvik создавали.
Кроме гугла есть еще IBM, Azul (Zing JVM), BEA (хотя их Оракл купил). Это «не считается», угу? (-:
Да и Андроид пока-что никуда не делся.
Да и Андроид пока-что никуда не делся.
Одного (точнее второго) прецедента достаточно, чтобы не захотеть связываться с Java.
Неверный ход мыслей, ибо Oracle как никто другой _не_ заинтересован в загнивании Java.
Ну и вас послушать так Макйкрософт патентным троллингом просто никогда-никогда не занимался…
Ну и вас послушать так Макйкрософт патентным троллингом просто никогда-никогда не занимался…
Ага, поэтому Sun отжали деньги у Microsoft в свое время, а Oracle сейчас хочет отжать деньги у гугла.
> Ну и вас послушать так Макйкрософт патентным троллингом просто никогда-никогда не занимался…
Между Oracle и MS я выберу MS.
> Ну и вас послушать так Макйкрософт патентным троллингом просто никогда-никогда не занимался…
Между Oracle и MS я выберу MS.
> Ага, поэтому Sun отжали деньги у Microsoft в свое время
Именно потому, что Макрософт хотели добить Java своей проприетарщиной.
> Между Oracle и MS я выберу MS.
Интересно почему?
Хотя выбор ваш.
Я тоже не очень счастлив что Sun в своё время не купила IBM например, но и конец света для Java пока-что не предвидится.
Именно потому, что Макрософт хотели добить Java своей проприетарщиной.
> Между Oracle и MS я выберу MS.
Интересно почему?
Хотя выбор ваш.
Я тоже не очень счастлив что Sun в своё время не купила IBM например, но и конец света для Java пока-что не предвидится.
> Именно потому, что Макрософт хотели добить Java своей проприетарщиной.
Гуглу вон своя опенсорщина не особо помогла.
> Интересно почему?
Сегодня, MS ведет себя намного цивильнее чем ORACLE. И вообщем вызывает в основном позитивные эмоции (если не пользоваться их Windows конечно).
IBM тоже сегодня цивильнее Oracle.
Гуглу вон своя опенсорщина не особо помогла.
> Интересно почему?
Сегодня, MS ведет себя намного цивильнее чем ORACLE. И вообщем вызывает в основном позитивные эмоции (если не пользоваться их Windows конечно).
IBM тоже сегодня цивильнее Oracle.
> Сегодня, MS ведет себя намного цивильнее чем ORACLE
А вот и M$
www.linux.org.ru/news/android/7773391
«Американская комиссия по международной торговле (ITC) наложила запрет в связи с нарушением в ОС Android американского патента № 6370566 от 10 апреля 1998 года, описывающий механизм обмена назначенными встречами в календаре. В течение 60 дней, пока запрет будет рассматриваться Президентом Соединённых Штатов, на каждое ввезённое устройство будет налагаться штраф в 33 цента. Если запрет будет утверждён, то Motorola будет обязана либо устранить нарушение патента, либо получить лицензию на Android у Microsoft, которая стоит от 5 до 15 долларов за устройство в зависимости от их количества и дополнительных соглашений с Microsoft.»
А вот и M$
www.linux.org.ru/news/android/7773391
«Американская комиссия по международной торговле (ITC) наложила запрет в связи с нарушением в ОС Android американского патента № 6370566 от 10 апреля 1998 года, описывающий механизм обмена назначенными встречами в календаре. В течение 60 дней, пока запрет будет рассматриваться Президентом Соединённых Штатов, на каждое ввезённое устройство будет налагаться штраф в 33 цента. Если запрет будет утверждён, то Motorola будет обязана либо устранить нарушение патента, либо получить лицензию на Android у Microsoft, которая стоит от 5 до 15 долларов за устройство в зависимости от их количества и дополнительных соглашений с Microsoft.»
>Между Oracle и MS я выберу MS.
Черт возьми, как мир то меняется… .NET не такой огороженный как Java, а MS запускает сервера на Linux…
Черт возьми, как мир то меняется… .NET не такой огороженный как Java, а MS запускает сервера на Linux…
>Вон, гугл тоже так думали когда Dalvik создавали.
насколько я помню в гугле Dalvik не создавали, а купили его с потрахами, изначально это была не гугловская разработка. Могу в чем-то ошибаться, влом щас копаться в нете.
насколько я помню в гугле Dalvik не создавали, а купили его с потрахами, изначально это была не гугловская разработка. Могу в чем-то ошибаться, влом щас копаться в нете.
Язык java постоянно меняется поэтому стандарты не нужны. Для свободного использования патентов и кодов есть OpenJDK. И насколько я знаю официальное разрешение Мс на моно распространяется не на весь технологический стек .NET иными словами, шаг в сторону и патентный иск готов. И в мире линуксов моно уже давно предали за это анафеме. Они в реализации моно залезли в закрытые патенты микрософ… Ну а напоминать, что микрософт один из крупнейших патентных троллей не нужно?
Кстати, а какая версия CLR описана в стандартах? У дотнета появилось уже четыре несовместимые между собой версии виртуальной машины.
Кстати, а какая версия CLR описана в стандартах? У дотнета появилось уже четыре несовместимые между собой версии виртуальной машины.
Есть достаточно профанский вопрос… Разве нельзя изменить реализацию, например, Dalvik'а таким образом, чтобы примитивные явовские типы стали value-типами, а коллекции стали нормальными, а не кастуемыми? На крайний случай, можно заменить цепь сборки Андроид-приложений и дополнить байт-код, старые приложения конечно придется пересобрать для поддержки новых фич и иметь по 2 версии APK, но ведь тоже вариант.
Перечитал все комментарии и кое-чего не понял (ткните носом если пропустил).
По идее можно переписать VM с Java на C#, тогда Google избавится от патентного тролинга от Oracle, а сами приложения по прежнему писать на Java (к ним то Oracle не докопается), т.е. не придется переписывать уже существующие приложения.
По идее можно переписать VM с Java на C#, тогда Google избавится от патентного тролинга от Oracle, а сами приложения по прежнему писать на Java (к ним то Oracle не докопается), т.е. не придется переписывать уже существующие приложения.
Что же, в очередной раз убедился, что гуевая платформа в Андроиде убога by design.
В оригинале информации больше: blog.xamarin.com/2012/05/01/android-in-c-sharp/
> система защищена от патентных исков строгими требованиями ISO, а также обещанием Microsoft.
Не-не-не, на это мы уже не купимся. Sun вон тоже много чего обещала…
Не-не-не, на это мы уже не купимся. Sun вон тоже много чего обещала…
У МС юридическое обещание.
Alizar добавил ссылку, так гораздо лучше; но пройдя по ней, я не увидел ничего «юридического», кроме языка формулировок. Это именно обещание, не имеющее какой-либо юридической силы. Если в Microsoft сменится руководство, это обещание вполне может быть пересмотрено.
Кроме того, там явно говорится, что обещание не распространяется на случай, когда им самим придется защищаться от нападок кого-то вроде Oracle. И тогда уж иски могу полететь во все стороны (ведь тех кто поменьше, Oracle может просто купить).
Кроме того, там явно говорится, что обещание не распространяется на случай, когда им самим придется защищаться от нападок кого-то вроде Oracle. И тогда уж иски могу полететь во все стороны (ведь тех кто поменьше, Oracle может просто купить).
Ну Sun всегда была не такой уж и крупной конторкой, взлетевшей и упавшей на буме доткомов, а вот MS ни банкротство, ни поглощение ну никак не грозят.
Ничто не вечно под луной.
Пока что MS отдала в «общественное достояние» язык, CLR и часть BCL. Без условий и отчислений. Oracle не отдала ничего и судится с гуглем. Из двух зол я выберу то, которое маленькое, и даёт при этом больше печенек. То биж MS.
Я тоже. Мы по-моему о разном говорим. Вы о своих личных симпатиях, а я лишь ответил на ваше «MS ни банкротство, ни поглощение ну никак не грозят».
И еще, насчет «отдала в общественное достояние», вы либо заблуждаетесь, либо путаетесь в терминах. Эти спецификации покрыты множеством патентов, в целях защиты. MS может пустить их в ход, если кто-то попытается ее потроллить какими-то другими патентами. А нам всем дала обещание не пускать их в ход в других случаях. Например, если кто-то напишет на C# конкурента Visual Studio или IE и отхватит у MS кусок рынка.
Это не «общественное достояние»
И еще, насчет «отдала в общественное достояние», вы либо заблуждаетесь, либо путаетесь в терминах. Эти спецификации покрыты множеством патентов, в целях защиты. MS может пустить их в ход, если кто-то попытается ее потроллить какими-то другими патентами. А нам всем дала обещание не пускать их в ход в других случаях. Например, если кто-то напишет на C# конкурента Visual Studio или IE и отхватит у MS кусок рынка.
Это не «общественное достояние»
Обещание MS это как не мое вам обещание, оно как бы обязываются его соблюдать.
XobotOS
Какое-то сильно русское название.
Вот еще бы сделали порт Minecraft на C# и о яве можно забыть :)
Дотнетчики, объясните мне пожайлуста, почему тот же Magic Tune, написанный на .NET, на win7 i7-860 грузится по 5 секунд и даже закрывается по 2с, а в некоторых случаях и по 15с?
Sign up to leave a comment.
Android портирован на C#