The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Native Client портирован для архитектур ARM и x86-64

19.03.2010 17:26

Разработчики компании Google сообщили о портировании для архитектур ARM и x86-64 платформы Native Client, позволяющей выполнять в окне web-браузера обычные бинарные приложения, ограниченные в специальном изолированном окружении. Тестирование производительности показало, что собранные с использованием Native Client приложения выполняются в виртуальном окружении внутри браузера всего на 3% медленнее по сравнению с производительностью работы немодифицированных версий тех же программ.

Портирование для архитектуры ARM интересно прежде всего открывающейся возможностью использования Native Client на смартфонах и портативных ПК, особенно построенных на основе недружелюбных для запуска бинарных исполняемых файлов мобильных платформ, таких как Palm webOS и Google Android. В настоящее время ведется работа по использованию для сборки программ для Native Client системы LLVM, что позволит разработчикам создавать универсальные приложения, без пересборки работающие на всех поддерживаемых аппаратных архитектурах (программа будет поставляться в виде байткода, который будет транслироваться на лету в машинный код целевой платформы средствами LLVM).

Изначально, в отличии от похожих проектов, инструкции при работе программы в Native Client не преобразовались в байткод виртуальной машины, а выполняются как есть, с максимально возможной производительностью (потеря производительности не более 5%). Безопасность в Native Client достигается через изоляцию системных вызовов и прерываний - разрешено выполнение 46 системных вызовов, остальное либо запрещено, либо эмулируется специальным runtime-кодом. Сетевые и дисковые функции, а также операции для работы с памятью, обрабатываются специальной подсистемой. Обращение за пределы дозволенных областей памяти блокируются через задействования системы обработки исключений CPU.

С точки зрения разработчика окружение Native Client выглядит как небольшая операционная система со своим, основанным на GCC, инструментарием для кросс-компиляции, частичной поддержкой POSIX и базовым мультимедийным API, который можно использовать для работы с аудио и видео, обрабатываться события от мыши и клавиатуры. Также доступен ряд свойственных web-приложениям функций, таких как загрузка внешней страницы. В этом плане Native Client позволяет организовать выполнение тех же функций, что может обычное web-приложение на JavaScript. Клиентская часть Native Client состоит из универсального плагина, который поддерживает браузеры Firefox, Safari, Opera и Google Chrome на платформах Linux, Mac OS X и Windows.

  1. Главная ссылка к новости (http://blog.chromium.org/2010/...)
  2. OpenNews: Библиотека Qt портирована для работы внутри web-браузера
  3. OpenNews: Компания Google представила победителей соревнования по взлому Native Client
  4. OpenNews: Работа по интеграции языка Python в web-браузеры
  5. OpenNews: Компания Google выпустила средство для выполнения бинарных программ в браузере
Лицензия: CC-BY
Тип: К сведению
Ключевые слова: NativeClient, llvm, gcc, browser, virtual, chroot
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (26) Ajax | 1 уровень | Линейный | Раскрыть всё | RSS
  • 1.1, Аноним (-), 17:35, 19/03/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Конечно напоминает систему в системе, но интересно как там дела с 3Д ускорением и работой с сетью.
     
     
  • 2.3, Аноним (-), 17:46, 19/03/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >и работой с сетью.

    ага, троян или спамилка в окне браузера это будет новое слово в технике :)

     
     
  • 3.14, szh (ok), 23:51, 19/03/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    не знаешь - не гы-гыкай
     
     
  • 4.21, минона (?), 04:41, 20/03/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    последнее отбираешь
     

  • 1.2, Zenitur (?), 17:35, 19/03/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Кто-нибудь ещё сомневается в том, что светлое будущее наступило? Весь функционал бесплатно, и без зависимости от далёкого заокеанского сервера и его пинга...
    А бывают ли мощные компьютеры с процессорами ARM?
     
     
  • 2.4, Warhead Wardick (?), 17:53, 19/03/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Ты в самом деле или прикалываешься? Тебе ActiveX(Tm) но от Google(Tm) пихают (ага тот самый зонд) - а он "светлое бу!"

    Самый популярный плаг у лисы - NoScript. Жто для жабаскрипта то, а тут натив бегать будет.

     
     
  • 3.5, минона (?), 18:03, 19/03/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    активикс также похож нативклиент, как гконф на реестр.
    1. у активикса не было никаких ограничений в системе - если уж вы его запустили, то он может всё тоже, что и обычная программа.
    2. активикс работал только в ие. и только на виндах. и только на x86.

    ps:
    в связи с этой новостью (а именно байт-код llvm) нативклиент можно сравнивать с java applet.

     
  • 2.9, User294 (ok), 20:08, 19/03/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Кто-нибудь ещё сомневается в том, что светлое будущее наступило?

    Да, чую я что pwnage явой и активиксами не закончится - благодаря гугле массово иметь будут и других :)

    >Весь функционал бесплатно, и без зависимости от далёкого заокеанского
    >сервера и его пинга...

    Не хотите с таким же энтузиазмом проверить на своей шкуре что будет если наступить в раскрытый канализационный люк? А то знаете, не все йогурты одинаково полезны. И нативный код в браузере - гм... MS и активиксы мы помним, спасибо. И число дыр в них. Там вон яву то ссыкотно запускать - вечно ее песочницу обходят как дважды два. А вы предлагаете нативный код. Сами запускайте. А лучше просто повесьте у сеья ssh и скажите нам рутовый пароль. То же самое но с меньшими мучениями для всех сторон процесса.

    >А бывают ли мощные компьютеры с процессорами ARM?

    Это в браузере то? oO

     
     
  • 3.15, szh (ok), 23:57, 19/03/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > А вы предлагаете нативный код. Сами запускайте.

    запустим. Только это не нативный код, а псевдонативный код в целях безопасности.

     
     
  • 4.18, Canada (?), 02:29, 20/03/2010 [^] [^^] [^^^] [ответить]  
  • +/
    "инструкции при работе программы в Native Client не преобразовались в байткод виртуальной машины, а выполняются как есть, с максимально возможной производительностью"

    Для ... хммм ... для медленных - повторяю :)

     
     
  • 5.19, минона (?), 04:33, 20/03/2010 [^] [^^] [^^^] [ответить]  
  • +/
    ещё для более медленных:
    >С точки зрения разработчика окружение Native Client выглядит как небольшая операционная система со своим, основанным на GCC, инструментарием для кросс-компиляции, частичной поддержкой POSIX и базовым мультимедийным API, который можно использовать для работы с аудио и видео, обрабатываться события от мыши и клавиатуры

    я бы тут изменил s/С точки зрения разработчика/С точки зрения разрабатываемого приложения/
    и это не имеет никакого отношения к байт-коду llvm. который всё-равно станет точно таким же "нативным", но в момент выполнения. т.е. будет более тормозным, но не более.

     
  • 4.23, User294 (ok), 09:43, 20/03/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >а псевдонативный код в целях безопасности.

    Видели мы это в яве уже. Стремнее запускать разве что нативные бинарники скачанные из интернета.

     

  • 1.8, Tav (ok), 19:32, 19/03/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Чем эта теперь-по-сути-виртуальная-машина лучше/хуже JVM, в применении к задаче "безопасно и эффективно выполнять приложение в браузере на стороне клиента".
     
     
  • 2.12, szh (ok), 22:20, 19/03/2010 [^] [^^] [^^^] [ответить]  
  • +/
    imho
    1 быстрее
    2 эффективнее к использованию RAM

    P.S. Использование существующих С/C++ библиотек.

     
     
  • 3.13, Tav (ok), 22:36, 19/03/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Боюсь, что не все так просто и производительность может сильно зависеть от конкретного приложения.

    Вот тут довольно подробно разобран вопрос производительности Java vs C в разных случаях:
    http://blogs.azulsystems.com/cliff/2009/09/java-vs-c-performance-again.html

    Что касается NC, полагаю что производительность будет зависеть от того, какие системные вызовы использует приложение и как часто.

    Что касается библиотек, для JVM тоже много полезных библиотек и очень богатое стандартное API.

     
     
  • 4.20, минона (?), 04:39, 20/03/2010 [^] [^^] [^^^] [ответить]  
  • +/
    уже больше 10 лет читаю подобные статьи, но java как была тормозом жрущим память и проц, так и осталась.
    писать под неё проще. и всё.
    где бы с ней не сталкивался (а писал не мало - от апплетов, до ынтырпрайс жаба бинс) везде траблы. при чём порой на ровном месте.
     
  • 4.25, User294 (ok), 10:52, 20/03/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Вот тут довольно подробно разобран вопрос производительности Java vs C в разных
    >случаях:

    Здравый смысл подсказывает что всяческие рантайм проверки оптом и когда надо, и когда нафиг не впилось + возможность городить зубодробильные конструкции "одной левой" и не грея мозг резонно приводят к тормозам и жрачу памяти. И вообще, хороший софт (потребляющий мало ресурсов, предсказуемо, стабильно и безглючно работающий) - пишется по принципу KISS. Ява от этого принципа жутко далека - это огроменный монструозный рантайм, провоцирующий на юзеж наворотов без особого понимания последствий этого. Результат - предсказуем. Чисто теоретически, на яве можно написать вполне сносную программу (кроме случаев интенсивных вычислений и работы с памятью где рантайм проверки с поводом и без сажают все в разы). Чисто практически - проще найти снег в пустыне Сахара нежели нормальную программу на яве.

     
     
  • 5.29, Tav (ok), 17:46, 20/03/2010 [^] [^^] [^^^] [ответить]  
  • +/
    "Огроменный монструозный рантайм" — это большое количество библиотек (API) включенных в стандартный дистрибутив. Сама виртуальная машина устроена относительно просто (тем более, что она проектировалась с учетом работы на встраиваемых устройствах).

    Что касается рантайм проверок, при оптимизации JIT удаляет проверки, которые не могут быть нарушены. У JIT, кстати, больше возможностей для оптимизации, чем у AOT компиляторов, поскольку есть возможность использовать информацию о работе программы, полученную во время выполнения (в статье есть пример).

    Вы бы по ссылке все-таки сходили, там не написано, что Java всегда быстрее или не хуже, чем C (и я этого не утверждал), там разобраны разные случаи.

     
  • 5.30, mr_gfd (?), 00:15, 21/03/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >>Вот тут довольно подробно разобран вопрос производительности Java vs C в разных
    >>случаях:
    >
    >Здравый смысл подсказывает

    <skipped/>

    Здравый смысл не заменит опыт. Приложение аппликухе рознь.

     

  • 1.11, Аноним (-), 20:44, 19/03/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Тестирование производительности показало, что собранные с использованием Native Client
    > приложения выполняются в виртуальном окружении внутри браузера всего на 3% медленнее по сравнению
    > с производительностью работы немодифицированных версий тех же программ.

    Конечно, на 3% медленее, на 6 ядерном Оптероне, при 2.8GHz c 8Gb РАМы,  чем на 400Mhz арме :)

     
  • 1.22, Aleksey (??), 09:13, 20/03/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Остается открытым только один вопрос. Нафига в этой цепочке браузер?
     
     
  • 2.24, XoRe (ok), 10:40, 20/03/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Остается открытым только один вопрос. Нафига в этой цепочке браузер?

    Браузер - это теперь считай операционная система)

    Из википедии:
    -----------------
    Операцио́нная систе́ма, ОС (англ. operating system) — базовый набор функций, обеспечивающий управление аппаратными средствами компьютера.

    ОС позволяет абстрагироваться от деталей реализации аппаратного обеспечения, предоставляя разработчикам программного обеспечения минимально необходимый набор функций. С точки зрения обычных пользователей компьютерной техники ОС включает в себя и программы пользовательского интерфейса.
    -----------------

    Программное обеспечение тут - сайты и скрипты/виджеты.
    А нормальная ОС (*nix, *bsd, *solaris, *windows) - это что-то типа биоса теперь =)

     
     
  • 3.26, User294 (ok), 11:04, 20/03/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Нет уж, бутявиться с интернета и предоставлять свои данные на обработку кому-то-там где-то там - очень на любителя. Гугл это конечно круто, но если им на некие места наступят CIA, FBI и прочие милые конторы - они сдадут ваши данные как миленькие.Так что имхо лучше не создавать такой соблазн нежели потом расхлебывать последствия.
     
     
  • 4.27, Zenitur (?), 13:16, 20/03/2010 [^] [^^] [^^^] [ответить]  
  • +/
    А ты предоставляй себе свои данные, и своему серверу... Я тоже противник высказанной выше мысли и всегда любил дистрибутивы Linux за то, что у них нет интеграции с Интернетом, в отличие от Windows. Соединишься - лампочки на модеме сразу мигают... Свои странички открывать проблемно с медленным соединением в первые минуты. Хотя автоматические обновления отключены, из программ установлены лишь фиксы безопаности и антивирус. А Linux использует Интернет только если я у него попрошу. Всегда.
     
  • 4.28, минона (?), 13:33, 20/03/2010 [^] [^^] [^^^] [ответить]  
  • +/
    ну тут уж каждый сам себе злостный буратино -хочешь запускай, хочешь нет.
    но я вот о чём думаю, как бы мы не старались, всё равно подобные веб-приложения будут.
    и уж если выбирать меньшее из зол, то этот мне нравится больше, чем например силверлайты и их ночные кошмары мунлайты.
     

  • 1.32, JL2001 (ok), 10:51, 02/04/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >программа будет поставляться в виде байткода, который будет транслироваться на лету в машинный код целевой платформы средствами LLVM

    чем это отличается от жава ? почему LLVM даёт 3% потерть а про жаву кричат что в три раза медленнее ?

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру