Мобильный - Кодовое имя - Как это может быть быстрее, чем родной язык?

Question

Мобильный - Кодовое имя - Как это может быть быстрее, чем родной язык?

1

Контекст:

Начиная писать мобильное приложение для Android и ios.

Глядя на множество альтернатив. Не выдерживает html5/webview. В большинстве случаев это вяло. Я пробовал много демонстрационных приложений (phonegap/steroid..) и не чувствовал себя как дома. Не достаточно гладко.

Больше, некоторые игры идут: так никак. Я хочу развитие NATIVE.

Сам по себе объективный-c не является проблемой. Но если я могу создать приложение только с одной разработкой, с языком, который легко кодировать в (java), это звучит неплохо.

Вопрос:

CodenameOne заявляет о большей производительности, чем объектив-c, через java vm.

Возможно, они используют C api, но этот api в основном obj-c теперь.

Могут ли некоторые разработчики или даже разработчики сказать мне, действительно ли мне не нужно вводить код на родном языке iOS (obj-c) и получать лучшие результаты через java vm? мне кажется странным.

Larry 24 фев. 2015, в 10:33

Источник

0

Кодовое имя одной виртуальной машины iOS переводится как C, а не Objective-C. Уровень портирования состоит из Objective-C и C, но мы стараемся уменьшить количество Objective-C для производительности. Фактически, одна из самых больших проблем с производительностью, которую мы имеем в нашей новой виртуальной машине, - это фрагмент кода Objective-C в разделе кодирования символов ... (к вашему сведению, я написал большую часть кода в нашей новой виртуальной машине)
Shai Almog 25 фев. 2015, в 06:33
0

@ShaiAlmog: хорошо, вы делаете то, что я имел в виду, чтобы избежать obj-c. Это отличный Шай :)
Larry 25 фев. 2015, в 07:13

Теги:

java

ios

objective-c

mobile

native

2 ответа

1

Я ничего не знаю о CodenameOne, но об общем поведении Java-VM.
Обычно Java-программам требуется больше времени для запуска, из-за того, что промежуточный код байта Java должен быть скомпилирован перед выполнением. Однако во время исполнения виртуальная машина, однако, может выполнять оптимизацию времени выполнения, например, переупорядочивать кодовые блоки, чтобы лучше использовать кэширование CPU и т.д....
Поскольку виртуальная машина может выполнить этот шаг во время выполнения и, таким образом, обладает знаниями, статический компилятор не имеет возможности реально опережать даже оптимизированный код C в разы.
Более старый пример тестов реального мира, сравнивающих C и Java, можно найти для Jake2 (Quake2 портирован на Java).

Syren Baran 24 фев. 2015, в 08:09

0

Syren, этот тест ничего не показывает. У нас даже нет компилятора, версии и используемых флагов. "march = native" и профиль очень полезны, но не являются автоматическими, хотя здесь нет никакой языковой борьбы, но если java неизменно лучше, чем c, то запустите кодер c, он недостаточно знает язык / оптимизации.
Larry 24 фев. 2015, в 10:00
0

Я не ищу языковой бой. Я имел в виду часть о «У некоторых УБС или даже создатели могут сказать мне , если я действительно не должны кода в родной IOS языка (Obj-C) и получить лучшие результаты с помощью виртуальной машины Java? Кажется странным я . " Это не всегда странно. У виртуальной машины есть информация, которой нет у статического компилятора, и она может работать быстрее.
Syren Baran 24 фев. 2015, в 10:16
0

Мы полностью согласны с сыром :)
Larry 24 фев. 2015, в 10:17
0

К вашему сведению, одним из преимуществ Java является быстрое выделение памяти, которое выполняется намного быстрее, чем стандартный C malloc / free / calloc. Тот факт, что GC работает в фоновом режиме, позволяет лучше использовать многоядерные чипы, особенно с надлежащей параллельной виртуальной машиной. Это также значительно упрощает многопоточный код. Приложения Big C могут быть оптимизированы до смешного уровня (включая пользовательские реализации malloc), но этого недостаточно: ibm.com/developerworks/library/j-jtp09275 Одна из основных проблем в Java заключается в том, что большинство реализаций Java оптимизированы для серверов, не код клиента
Shai Almog 25 фев. 2015, в 06:30
0

@ShaiAlmog: спасибо, Шай. Разница в скорости выделения очень сильно зависит от утилизации . Хорошо продуманный c-код не выделяет так много, но перерабатывает, как это делает java. Одна из причин медленного запуска Java - именно выделение памяти.
Larry 25 фев. 2015, в 07:10
2

Одна из причин медленного запуска заключается в том, что JVM по умолчанию загружает 800 классов при запуске и инициализирует множество объектов (например, строк). Наша виртуальная машина не имеет классов, но вы получаете много статического инициализирующего кода (глобальные и т. Д.), Который инициализируется, что также требует некоторых мьютексов (для предотвращения одновременной инициализации), затем мы также инициализируем весь набор строк, используемых в приложении (в идеале это будет оптимизировано в будущем). Это не очень заметно на iPhone 4 (не S), поэтому мы пока оставим этот слайд. Здесь всегда есть место для оптимизации.
Shai Almog 25 фев. 2015, в 07:38
0

@ShaiAlmog: 100% согласились
Larry 25 фев. 2015, в 09:21

Показать ещё 5 комментариев

Ещё вопросы

Кодовое имя одной виртуальной машины iOS переводится как C, а не Objective-C. Уровень портирования состоит из Objective-C и C, но мы стараемся уменьшить количество Objective-C для производительности. Фактически, одна из самых больших проблем с производительностью, которую мы имеем в нашей новой виртуальной машине, - это фрагмент кода Objective-C в разделе кодирования символов ... (к вашему сведению, я написал большую часть кода в нашей новой виртуальной машине)
@ShaiAlmog: хорошо, вы делаете то, что я имел в виду, чтобы избежать obj-c. Это отличный Шай :)
Syren, этот тест ничего не показывает. У нас даже нет компилятора, версии и используемых флагов. "march = native" и профиль очень полезны, но не являются автоматическими, хотя здесь нет никакой языковой борьбы, но если java неизменно лучше, чем c, то запустите кодер c, он недостаточно знает язык / оптимизации.
Я не ищу языковой бой. Я имел в виду часть о «У некоторых УБС или даже создатели могут сказать мне , если я действительно не должны кода в родной IOS языка (Obj-C) и получить лучшие результаты с помощью виртуальной машины Java? Кажется странным я . " Это не всегда странно. У виртуальной машины есть информация, которой нет у статического компилятора, и она может работать быстрее.
К вашему сведению, одним из преимуществ Java является быстрое выделение памяти, которое выполняется намного быстрее, чем стандартный C malloc / free / calloc. Тот факт, что GC работает в фоновом режиме, позволяет лучше использовать многоядерные чипы, особенно с надлежащей параллельной виртуальной машиной. Это также значительно упрощает многопоточный код. Приложения Big C могут быть оптимизированы до смешного уровня (включая пользовательские реализации malloc), но этого недостаточно: ibm.com/developerworks/library/j-jtp09275 Одна из основных проблем в Java заключается в том, что большинство реализаций Java оптимизированы для серверов, не код клиента
@ShaiAlmog: спасибо, Шай. Разница в скорости выделения очень сильно зависит от утилизации . Хорошо продуманный c-код не выделяет так много, но перерабатывает, как это делает java. Одна из причин медленного запуска Java - именно выделение памяти.
Одна из причин медленного запуска заключается в том, что JVM по умолчанию загружает 800 классов при запуске и инициализирует множество объектов (например, строк). Наша виртуальная машина не имеет классов, но вы получаете много статического инициализирующего кода (глобальные и т. Д.), Который инициализируется, что также требует некоторых мьютексов (для предотвращения одновременной инициализации), затем мы также инициализируем весь набор строк, используемых в приложении (в идеале это будет оптимизировано в будущем). Это не очень заметно на iPhone 4 (не S), поэтому мы пока оставим этот слайд. Здесь всегда есть место для оптимизации.

Marko Topolnik · Accepted Answer · 2015-02-24T06-33-00.000Z

1

Лучший ответ

Цитата прямо со страницы, с которой вы связались:

Небольшой отказ от ответственности заключается в том, что тест Objective-C немного тяжел в вызовах метода/сообщения, которые уклоняются от эталона в нашу пользу. Вызов метода в Codename Один, естественно, намного быстрее, чем эквивалентный код Objective-C из-за семантики этого языка.

Разве это не объясняет, что именно вы спросили? Objective-C имеет архитектуру, из-за которой динамическая диспетчеризация не может быть оптимизирована, тогда как архитектура Java допускает такие вещи, как мономорфный сайт вызова и даже полный метод вложения. Тест, который в значительной степени фокусируется именно на этом аспекте, будет искажать результаты в пользу JVM, но на производительность реальных приложений почти никогда не доминируют затраты на отправку методов.

Marko Topolnik 24 фев. 2015, в 06:33

0

Благодарю. Я прочитал (и понял) это предложение :) Но как мог цель-c в дизайне Apple не быть настолько оптимизированной? в этом случае зачем вообще беспокоиться о кодировании в нативной цели c, если некоторые другие языки могут превзойти исходный язык, который должен быть оптимизирован на платформе?
Larry 24 фев. 2015, в 09:39
0

Вы решили сосредоточиться на неправильных аспектах: Apple не видела необходимости оптимизировать Objective-C способами, которые не имеют отношения к производительности приложений. Вы хотите потрудиться над кодированием на родном языке, чтобы получить хорошую производительность от своего приложения , а не отобранных отдельно тестов, потому что он использует один узкий механизм, именно тот, который альтернативная платформа оптимизирует лучше.
Marko Topolnik 24 фев. 2015, в 09:46
0

Так что никакой магии: target-c на ios и java на android, верно?
Larry 24 фев. 2015, в 09:53
0

Вы всегда можете попробовать это, но обычно не родные альтернативы терпят неудачу по той или иной практической причине. Обратите внимание, что на iOS также есть Swift, и Apple явно видит в этом путь.
Marko Topolnik 24 фев. 2015, в 09:58
0

Вы определенно правы, но мне нужно поддерживать iOS 6 тоже .. :)
Larry 24 фев. 2015, в 10:01
0

Я согласен с тем, что в некоторых случаях происходит сбой на неродном языке, но Codename One предназначен для обеспечения полного доступа к нативному (к вашему сведению, я являюсь соучредителем Codename One). Objective-C имеет несколько проблем, которые замедляют его, включая синхронный подсчет ссылок и медленную отправку сообщений, обе из которых очень медленные. Первое все еще верно для SWIFT, я не уверен насчет второго. ARC улучшил подсчет ссылок, но тот факт, что вам нужен подсчет ссылок, чтобы быть потокобезопасным, действительно замедляет работу. Если нативное приложение написано на 100% C без использования функций Objective C, оно потенциально будет быстрее.
Shai Almog 25 фев. 2015, в 06:27
0

@ShaiAlmog: это действительно большая работа. Отлично сработано
Larry 25 фев. 2015, в 07:11
0

@ShaiAlmog Во всяком случае, я хотел бы избежать небезопасных указателей Objective-C и «автоматического» подсчета ссылок (где только подсчет является автоматическим, и мне все еще приходится вручную кодировать циклы ссылок и другие проблемы RC). Objective-C - это синтаксический и семантический набор концепций Smalltalk поверх простого C. Однако мне не приходилось думать о производительности, как о том, что необходимо исправить на iOS. Большая часть кода приложения не требует больших вычислительных ресурсов, и все интенсивные вещи выполняются в библиотеке платформы (которая, естественно, очень оптимизирована).
Marko Topolnik 25 фев. 2015, в 08:08
1

Я полностью согласен с Марко. Цель упомянутого выше теста в основном состоит в том, чтобы показать, что наш Java-порт "конкурентоспособен" с нативным с точки зрения производительности. Приложения для iOS гладкие, потому что библиотеки (базовая анимация и т. д.) смехотворно хорошо оптимизированы для GPU.
Shai Almog 25 фев. 2015, в 17:05

Показать ещё 7 комментариев