PS: оптимизация это безусловно полезно, но перед тем как ею заниматься, необходимо провести детальный анализ производительности: профилирование инструментальное(v-tune, xcode instruments,..) и/или ручное (расстановка замеров времени по коду).
И, да — не удаляйте неоптимизированные версии.
Коллеги, занимающиеся портированием на другие архитектуры/наборы инструкций скажут вам спасибо.
У меня был такой набор
— Ассемблер GENS4-51 (у когорого 51 символ в строке вместо дефолтных 32-х)
— Монитор/отладчик MONS4
Ну и, конечно же, The Complete Machine Code Tutor — обучающая программа по архитектуре и системе команд процессора Z80
Дизассемблировал заставки к играм и записывал карандашем в тетрадку код понравившихся эффектов.
Помимо спектрумовского асма в памяти жив легендарный Laser Basic — расширение для системного бейсика, вешающее свой хук на обработчик ошибок и расширяя таким образом синтаксис базового языка примитивами для работы с графикой (спрайты и т.п.)
Однако, если мы посмотрим на ассемблерный код, генерируемый несколькими разными компиляторами, то увидим, что x загружается при каждой итерации цикла.
По-моему тут все хорошо
Судя по объявлению foo — глобальная нестатическая ф-ция, т.е. мы не знаем что там происходит и не знаем «смоет» она регистры или нет (те, что можно не сохранять).
А «x» — локальная переменная, выделенная на стеке.
«x» передается в foo одним из аргументов (через стек или регистр).
Но при этом foo не обязана по возвращению восстановить это входное значение «x».
Поэтому, компилятор перестраховывается и делает повторную загрузку.
По поводу переменного тока и СВЧ в частности — возникает так называемый скин-эффект, когда плотность тока вытесняется на поверхность проводника.
По этой причине высокодобротные катушки индуктивности изготавливают из посеребренного провода, либо из лицендрата — многожильного провода.
А там, где токи/частоты сильно большие, в качестве проводников используют трубы.
Интересно. Эдакий аппаратный Karabiner для мака. И наоборот.
После долгой работы на маке, переходя на PC, начинаешь на автомате использовать command+c вместо ctr+c и т.п. А переопределить такие штуки глобальным хуком (на Win32) не всегда можно. Аппаратный транслятор в этом смысле имел бы преимущество.
Бывает, что одна организация покупает закрытый проект «в сорцах» у другой, а перед этим смотрит, что там внутри.
Других примеров из своей практики не могу привести.
Цели разные, например, в СПО лицензия нужна в том числе для того, чтобы код не растащили проприетарщики. Поэтому для закрытых коммерческих проектов приходится искать проекты с либеральными лицензиями типа BSD/MIT и т.п.
что будет, если я ее нарушу
Как минимум заработаете минус в карму.
Как максимум, если лицензия работает в рамках законодательства Вашего Государства, огребете люлей.
Лицензия вообще мало кого интересует – у 80% проектов с Github лицензия отсутствует
Сильно сказано.
80% — это, видимо, тонны Hello World'ов, портящих общую статистику.
Первое на что смотрю в заинтересовавшем меня проекте — лицензия.
Пока что не встречал ни одного проекта, несущего практическую ценность, без лицензии.
Мне больше нравится регистрить нативные методы в JNI_OnLoad
Отпадает необходимость в хардкорном именовании нативных методов.
По поводу stl — самая полная поддержка в LLVM libc++ Applicarion.mk
APP_STL := c++_static
APP_CPPFLAGS += -fexceptions
APP_CPPFLAGS += -frtti
Добавлю свои 5 копеек
Гении гугла во время миграции с Eclipse на IntelliJ IDEA похерили напрочь и без того тухлую поддержку NDK. Отлаженную систему сборки на основе Androig.mk (на которой сидит весь AOSP если что), заменили какой-то студенческой поделкой на базе неповоротливого gradle. В результате ниасилили сделать достойный аналог и убили то, что работало (работало в IDE, в консоли к счастью еще дышит). Но косяк, видимо, осознали и в новой версии обещали исправиться — вернуть Android.mk, а также добавить поддержку cmake. Выглядит очень заманчиво, но зная гугл, понимаю, что они снова могут все извратить.
Чего стоят новые самплы NDK, которые перенесли на github — это просто смешно смотреть, как они героически возводят костыли, чтобы поднять то, что раньше работало (сборка внешних зависимостей типа native app glue, cpu features и т.п.)
Тем не менее, стоит отдать должное Гуглу, они сделали все, чтобы зарплаты у нативных разработчиков под Андроид были высокими!
Да срать они хотели на поддержку NDK, при том что весь ведроид написан на кастрированном c++, а на яву торчат лишь вершки через jni прослойку.
Отвечу на свой вопрос сам
В Android Studio 2.2 preview анонсирована поддержка внешних систем сборки нативного кода: ndk-build и cmake.
Для этого в скрипте gradle необходимо указать путь до CMakeLists.txt, либо Android.mk
Прекрасная новость.
Надеюсь, что будет работать и для «сложных» проектов, состоящих из большого количества библиотек.
Нативная часть в Android обычно используется совместно с Java классом.
Логично предположить, что этот класс должен быть реализован в нативном модуле.
Или я ошибаюсь?
Если да, то он почему-то никаким образом не хочет импортироваться в главном модуле.
При этом зависимость от нативного модуля обозначена.
А если реализовать этот класс в отдельном модуле, с классическим плагином, то класс успешно импортируется.
— Стоит ли ожидать в ближайшее время улучшение поддержки NDK?
Понимаю, что вопрос не по Android N, а по Android Studio, просто наболело.
Лаконичные Android.mk зарыли в землю заменили автогенерацией средствами неуклюжего gradle, при этом «забыли» добавить поддержку внешних модулей и статических библиотек.
Более-менее вменяемая поддержка NDK есть только в экспериментальном плагине, который не совместим с дефолтным, что как бы намекает, что пользователи NDK — это «люди с ограниченными возможностями».
Было бы интересно знать, что об этом думают в особо приближенных к императору кругах.
ЕМНИП запрещено интерпретировать код, загруженный в обход аппстора. Если интерпретируемый код содержится в бандле приложения, то проблем быть не должно.
Если бы тормозило, то это проявлялось бы в виде провалов звука. Видимо дело в суммарной латентности всего стека звукового API — от уровня пользователя, до уровня драйвера конкретного железа. Если по ходу тракта стоят микшеры, ресемплеры, фильтры, и везде есть очереди, то получить задержку в десяток мс не так и сложно. А в андроиде audioflinger ЕМНИП через ipc binder получает на вход данные — еще один кандидат на добавленную задержку.
Однако если выполнить модификации в Media Server, HAL, в драйвере ALSA
Вот бы вся статья об этом была, с подробным разбором кишков андроида, с указанием тех мест, где ребята из гугла конкретно облажались с дизайном платформы и вся звуковая low-latency индустрия от этого теперь страдает.
PS: В NDK вполне вменяемый пример использования OpenSL ES и платформа x86 там ни чем особо не выделяется.
PS: оптимизация это безусловно полезно, но перед тем как ею заниматься, необходимо провести детальный анализ производительности: профилирование инструментальное(v-tune, xcode instruments,..) и/или ручное (расстановка замеров времени по коду).
И, да — не удаляйте неоптимизированные версии.
Коллеги, занимающиеся портированием на другие архитектуры/наборы инструкций скажут вам спасибо.
Браузерное гавно превращается…
Превращается браузерное гавно…
В нативное приложение на c/с++!!!
— Ассемблер GENS4-51 (у когорого 51 символ в строке вместо дефолтных 32-х)
— Монитор/отладчик MONS4
Ну и, конечно же, The Complete Machine Code Tutor — обучающая программа по архитектуре и системе команд процессора Z80
Дизассемблировал заставки к играм и записывал карандашем в тетрадку код понравившихся эффектов.
Помимо спектрумовского асма в памяти жив легендарный Laser Basic — расширение для системного бейсика, вешающее свой хук на обработчик ошибок и расширяя таким образом синтаксис базового языка примитивами для работы с графикой (спрайты и т.п.)
По-моему тут все хорошо
Судя по объявлению foo — глобальная нестатическая ф-ция, т.е. мы не знаем что там происходит и не знаем «смоет» она регистры или нет (те, что можно не сохранять).
А «x» — локальная переменная, выделенная на стеке.
«x» передается в foo одним из аргументов (через стек или регистр).
Но при этом foo не обязана по возвращению восстановить это входное значение «x».
Поэтому, компилятор перестраховывается и делает повторную загрузку.
По этой причине высокодобротные катушки индуктивности изготавливают из посеребренного провода, либо из лицендрата — многожильного провода.
А там, где токи/частоты сильно большие, в качестве проводников используют трубы.
После долгой работы на маке, переходя на PC, начинаешь на автомате использовать command+c вместо ctr+c и т.п. А переопределить такие штуки глобальным хуком (на Win32) не всегда можно. Аппаратный транслятор в этом смысле имел бы преимущество.
Других примеров из своей практики не могу привести.
Если законодательство позволяет, то обратиться в суд и по положительным результатам экспертизы исходного кода добиться выписывания люлей.
Очевидно ничего, кроме минуса в карму (Alwinner, превед)
Цели разные, например, в СПО лицензия нужна в том числе для того, чтобы код не растащили проприетарщики. Поэтому для закрытых коммерческих проектов приходится искать проекты с либеральными лицензиями типа BSD/MIT и т.п.
Как минимум заработаете минус в карму.
Как максимум, если лицензия работает в рамках законодательства Вашего Государства, огребете люлей.
Сильно сказано.
80% — это, видимо, тонны Hello World'ов, портящих общую статистику.
Первое на что смотрю в заинтересовавшем меня проекте — лицензия.
Пока что не встречал ни одного проекта, несущего практическую ценность, без лицензии.
Мне больше нравится регистрить нативные методы в JNI_OnLoad
Отпадает необходимость в хардкорном именовании нативных методов.
По поводу stl — самая полная поддержка в LLVM libc++
Applicarion.mk
APP_STL := c++_static
APP_CPPFLAGS += -fexceptions
APP_CPPFLAGS += -frtti
Добавлю свои 5 копеек
Гении гугла во время миграции с Eclipse на IntelliJ IDEA похерили напрочь и без того тухлую поддержку NDK. Отлаженную систему сборки на основе Androig.mk (на которой сидит весь AOSP если что), заменили какой-то студенческой поделкой на базе неповоротливого gradle. В результате ниасилили сделать достойный аналог и убили то, что работало (работало в IDE, в консоли к счастью еще дышит). Но косяк, видимо, осознали и в новой версии обещали исправиться — вернуть Android.mk, а также добавить поддержку cmake. Выглядит очень заманчиво, но зная гугл, понимаю, что они снова могут все извратить.
Чего стоят новые самплы NDK, которые перенесли на github — это просто смешно смотреть, как они героически возводят костыли, чтобы поднять то, что раньше работало (сборка внешних зависимостей типа native app glue, cpu features и т.п.)
Да срать они хотели на поддержку NDK, при том что весь ведроид написан на кастрированном c++, а на яву торчат лишь вершки через jni прослойку.
Дебаг, деплой, статический/динамический анализ, профилирование.
В Android Studio 2.2 preview анонсирована поддержка внешних систем сборки нативного кода: ndk-build и cmake.
Для этого в скрипте gradle необходимо указать путь до CMakeLists.txt, либо Android.mk
Прекрасная новость.
Надеюсь, что будет работать и для «сложных» проектов, состоящих из большого количества библиотек.
Логично предположить, что этот класс должен быть реализован в нативном модуле.
Или я ошибаюсь?
Если да, то он почему-то никаким образом не хочет импортироваться в главном модуле.
При этом зависимость от нативного модуля обозначена.
А если реализовать этот класс в отдельном модуле, с классическим плагином, то класс успешно импортируется.
Module: app
apply plugin: 'com.android.application' // Java only
...
dependencies {
compile project(path: ':libn')
compile project(path: ':libj')
...
}
Module:libn
apply plugin: 'com.android.model.library' // Native,Java
...
Module:libj
apply plugin: 'com.android.library' // Java only
...
Понимаю, что вопрос не по Android N, а по Android Studio, просто наболело.
Лаконичные Android.mk
зарыли в землюзаменили автогенерацией средствами неуклюжего gradle, при этом «забыли» добавить поддержку внешних модулей и статических библиотек.Более-менее вменяемая поддержка NDK есть только в экспериментальном плагине, который не совместим с дефолтным, что как бы намекает, что пользователи NDK — это «люди с ограниченными возможностями».
Было бы интересно знать, что об этом думают в особо приближенных к императору кругах.
Замечательно, а можно примерчик использования такой библиотеки в православном Android Studio?
Вот бы вся статья об этом была, с подробным разбором кишков андроида, с указанием тех мест, где ребята из гугла конкретно облажались с дизайном платформы и вся звуковая low-latency индустрия от этого теперь страдает.
PS: В NDK вполне вменяемый пример использования OpenSL ES и платформа x86 там ни чем особо не выделяется.