crimea-karro


[Главная страница]
[Добавить в избранное]

Страницы: [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17]

Facebook открыл код платформы Detectron для распознавания объектов на фотографиях

Группа исследователей искусственного интеллекта из компании Facebook открыла исходные тексты платформы Detectron с реализацией набора алгоритмов для распознавания и классификации объектов на фотографиях. Проект реализован на языке Python с использованием фреймворка глубинного машинного обучения Caffe2 и распространяется под лицензией Apache 2.0. Для загрузки подготовлена большая коллекция наборов данных и более 70 натренированных готовых моделей для решения различных типов задач компьютерного зрения. Модели поставляются под свободной лицензией CC BY-SA 3.0.

В рамках платформы Detectron предложены реализации наиболее перспективных подходов по построению нейронных сетей и систем машинного обучения, нацеленных на выделение объектов на изображениях. Например, авторы алгоритма Mask R-CNN в прошлом году стали обладателями премии Марра, вручаемой комитетом IEEE за выдающиеся достижения в области компьютерного зрения. В итоге удалось подготовить высокопроизводительную и гибкую систему для высококачественного определения объектов, для разработчиков ПО предоставляющую средства для быстрой интеграции данной функциональности в свои проекты, а для исследователей машинного обучения - для проведения экспериментов и создания реализаций новых алгоритмов.

В текущем виде Detectron предлагает шесть алгоритмов распознавания изображений (Mask R-CNN, RetinaNet, Faster R-CNN, RPN, Fast R-CNN и R-FCN), разработанных различными академическими коллективами исследователей. Для организации машинного обучения поддерживается развёртывание четырёх типов нейронных сетей: ResNeXt{50,101,152}, ResNet{50,101,152}, Feature Pyramid Networks (на базе ResNet/ResNeXt) и VGG16, но дополнительные типы могут быть легко добавлены, благодаря модульной архитектуре платформы. Решения на базе Detectron уже используются Facebook в некоторых проектах по сегментации изображений и построению систем дополненной реальности.

Источник: http://www.opennet.ru/opennews/art.shtml?num=47950

Линус Торвальдс жестко раскритиковал связанные с микрокодом патчи Intel

Разработчики из компании Intel предложили для включения в ядро Linux серию патчей для блокирования второго варианта уязвимости Spectre (CVE-2017-5715). Патчи Intel позиционируются в качестве альтернативы патчам retpoline. По мнению Intel предлагаемое решение будет эффективно на процессорах Skylake и более новых, на которых не исключается появление вариантов атаки Spectre, которую не смогут закрыть патчи retpoline. При этом на старых процессорах по сравнению с retpoline решение Intel обеспечивает заметное снижение производительности, но в будущих моделях CPU влияние на производительность обещают сделать минимальным.

Патчи Intel базируются на использовании представленной в обновлении микрокода функциональности IBRS (Indirect Branch Restricted Speculation), позволяющей разрешать и запрещать спекулятивное выполнение инструкций. В предложенном патче IBRS применяется для адаптивного включения/выключения спекулятивного выполнения косвенных переходов во время обработки прерываний, системных вызовов, переключений контекста между процессами и между виртуальными машинами. В отличие от retpoline патч Intel для всестороннего обхода Spectre не требует изменений компонентов в пространстве пользователя при включении "полного" режима работы (IBRS_ALL), активирующего применение IBRS в userspace.

В ответ на предложение включить данный патч в ядро Линус Торвальдс вышел из себя и назвал патч Intel "полным и абсолютным мусором" (complete and utter garbage), а предпринятый метод значительно хуже, чем грязный хак. Появление IBRS указывает на то, что Intel не планирует грамотного решения проблемы со спекулятивным выполнением косвенных переходов. По впечатлению Торвальдса возникает ощущение, что Intel создаёт видимость работы во избежание судебных исков и прежде всего пытается решить свои юридические проблемы, что совсем не способствует созданию технически грамотных и качественных технологий и исправлений. Судя по всему, даже сама компания Intel не воспринимает предложенный режим защиты IBRS_ALL всерьёз, так как негативное влияние на производительность столь высоко, что он отключен по умолчанию, чтобы не портить результаты тестов.

Тем временем, в запланированный на следующий понедельник выпуск ядра Linux 4.15 войдут свежие наработки по блокированию атак Meltdown и Spectre. Для противодействия атаке Meltdown (CVE-2017-5754) на системах x86 с процессорами Intel (процессоры AMD данной атаке не подвержены) добавлена технология PTI (Page Table Isolation), обеспечивающая разделение таблиц страниц памяти ядра и пространства пользователя при переключении контекста во время системного вызова. Для процессоров PowerPC для защиты от Meltdown добавлен код на основе применения инструкции RFI (Return from Interrupt) для сброса кэша L1-D.

Для блокирования эксплуатации второго варианта уязвимости Spectre (CVE-2017-5715) добавлен механизм retpoline, основанный на применении специальной последовательности инструкций, исключающей вовлечение механизма спекулятивного выполнения для косвенных переходов (для работы защиты также требуется сборка модифицированной версией GCC с поддержкой режима "-mindirect-branch=thunk-extern"). Включение средств для обеспечения защиты от первого варианта атаки Spectre (CVE-2017-5753) и кода для блокирования Meltdown на процессорах ARM отложено до выпуска 4.16.

Так как механизмы защиты приводят к снижению производительности, предусмотрены опции для их отключения, которые могут применяться на системах с минимальным риском атаки, например на однопользовательских рабочих станциях. Для отключения PTI во время загрузки ядру можно передать опцию pti=off, а для отключения retpoline - опцию "spectre_v2=off". В состав ядра также добавлен диагностический вызов в sysfs для быстрого определения степени устранения уязвимостей Meltdown и Spectre, который привязан к директории /sys/devices/system/cpu/vulnerabilities/:

     $ grep . /sys/devices/system/cpu/vulnerabilities/*     /sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI     /sys/devices/system/cpu/vulnerabilities/spectre_v1:Vulnerable     /sys/devices/system/cpu/vulnerabilities/spectre_v2:Vulnerable: Minimal generic SM retpoline  

Дополнение: Компания Intel сообщила об определении причин проблем с перезагрузками на системах с CPU Broadwell и Haswell после установки нового микрокода. В настоящее время подготовлен начальный вариант обновлённого микрокода, который проходит тестирование среди OEM-производителей. После завершения тестирования будет предложено общедоступное обновление. До выхода данного обновления не рекомендуется использовать выпущенную в начале января версию микрокода.

Источник: http://www.opennet.ru/opennews/art.shtml?num=47948

Выпуск Minibase, минимального статически собранного окружения Linux

Доступен первый стабильный релиз проекта Minibase, в рамках которого развивается пользовательское окружение на базе ядра Linux, позволяющее получить рабочую загрузочную систему с минимально возможным набором самодостаточных компонентов. Минимальный размер окружения составляет 19 Мб. Поддерживается сборка для архитектур x86_64, arm, arm64 и rv64. Система может быть загружена как в QEMU, так и на реальном оборудовании. Наработки проекта написаны на языке Си и распространяются под лицензией GPLv3.

В базовую поставку входит ядро Linux (3MB), набор модулей ядра (6MB ), набор прошивок для беспроводных чипов (9MB) и подборка статически собранных утилит (650KB), таких как cat, ls, du, df, systime, sync, dmesg, switchroot, pstree, elfinfo, lsdri, modprobe и mount. Большинство из утилит специально написаны для Minibase и не основываются на коде штатных утилит. Все исполняемые файлы в базовом окружении собраны статически - применение стандартной Си-библиотеки (libc) не обязательно, но для обеспечения запуска дополнительных динамически собранных приложений (например, X.org) предусмотрена возможность использования библиотеки musl.

В состав также входят инструменты для поиска и подключения шифрованных или нешифрованных разделов (passblk, findblk, dektool, dmcrypt), базовые процессы системы инициализации (init, super, reboot, svctl), урезанный вариант udevd и syslogd, инструменты для монтирования (mountd, pmount), утилита для запуска привилегированных процессов (sudo), система мультиплексирования терминалов (vtmux), простая интерактивная командная оболочка (cmd), утилиты для настройки сетевых интерфейсов (ifmon с поддержкой DHCP, ip4cfg, ip4info), конфигуратор беспроводной сети (wsupp, wpa_supplicant). Опционально поддерживается установка SSH-сервера/клиента dropbear (200KB), командного интерпретатора dash (100KB) и графического стека (27MB), который может включать X.Org-сервер или композитный сервер Weston (Wayland).

По своим задачам окружение Minibase во многом напоминает Busybox и сопоставимо с ним по размеру. Ключевое отличие заключается в том, что Busybox оформлен в виде единого исполняемого файла, а Minibase позиционируется как набор статически собранных исполняемых файлов. При этом Minibase не ставит перед собой цель обеспечения совместимости с инструментарием POSIX или GNU и в большей степени нацелен на поставку специфичных для Linux сервисов (KMS VT, сетевые утилиты, шифрование диска). Minibase также не требует libc для сборки - за счёт прямого обращения к системным вызовам пакет самодостаточен, для его сборки достаточно компилятора и компоновщика. Для выполнения привилегированных операций в Minibase не используется suid-бит или capabilities, вместо этого осуществляется обращение к специальному привилегированному сервису через IPC.

Источник: http://www.opennet.ru/opennews/art.shtml?num=47944

Доступен WineD3D для Windows, предоставляющий поддержку DirectX 11 через OpenGL

В рамках проекта WineD3D For Windows подготовлена обвязка для запуска в Windows реализации DirectX 1-11 на базе OpenGL и наработок проекта Wine. В качестве реализации OpenGL в том числе может применяться порт Mesa для Windows.

Несмотря на то, что в Windows имеется встроенная поддержка DirectX, использование WineD3D может быть полезным для улучшения обратной совместимости со старыми играми (например, в Windows 8 прекращена поддержка режимов с 16-разрядной глубиной цветности). Ещё одной областью применения проекта является эмулирование неподдерживаемых версий DirectX и портирование DirectX-приложений на OpenGL без переписывания кода отрисовки.

Дополнительно можно отметить второй выпуск проекта DXVK, нацеленного на создание реализации DXGI и Direct3D 11 поверх API Vulkan для предоставления возможности запуска 3D-приложений в Linux при помощи Wine. Новая версия примечательна доведением поддержки D3D11 до возможности запуска игры NieR: Automata и обеспечением начальной поддержки тестовых наборов Unigine Heaven и Unigine Valley. Из пока отсутствующих возможностей упоминается поддержка тесселяции, потокового вывода и запросов через Queries API.

После доведения проекта до полнофункционального состояния, DXVK сможет использоваться в качестве основанной на Vulkan альтернативы для предоставляемой в Wine реализации D3D11, работающей поверх OpenGL. При этом разработчиками Wine уже развивается собственный проект vkd3d по реализации Direct3D 12 поверх API Vulkan.



Источник: http://www.opennet.ru/opennews/art.shtml?num=47943

Проекты по созданию компиляторов из Java в JavaScript и исполняемые файлы

В рамках проекта TeaVM развивается компилятор, позволяющий компилировать Java-байткод в JavaScript и WebAssembly для последующего выполнения в браузере. Ключевым отличием от проекта GWT (Google Web Toolkit) является то, что TeaVM выполняет трансляцию на уровне байткода (может компилировать файлы *.class или *.jar), без привязки к исходным текстам на языке Java, что позволяет компилировать проекты на языках Kotlin и Scala. Код TeaVM распространяется под лицензией Apache 2.0.

Основной целью TeaVM является предоставление средств по созданию web-приложений для разработчиков знакомых с Java, унификации платформы для разработки (фронтэнд на базе те же технологий, что и бэкенд) или при необходимости задействования в web-приложении уже имеющегося кода на Java. TeaVM по возможности сохраняет оригинальную структуру методов, выдавая читаемый и понятный JavaScript. Для разработки одностраничных web-приложений на Java, Kotlin или Scala предлагается web-фреймворк Flavour, похожий на Angular, но базирующийся на идиомах Java, а не JavaScript.

Для ускорения выполнения результирующего кода и сокращения его размера применяется изощрённый оптимизатор, который способен выполнять девиртуализацию виртуальных вызовов в статические вызовы функций, исключать неиспользуемый код, повторно использовать одну и ту же локальную переменную для хранения значений нескольких переменных, использовать сокращённые имена методов. Важной особенностью является поддержка преобразования в JavaScript многопоточного кода, который разворачивается в линейное представление с эмуляцией нескольких логических потоков в одном физическом потоке.

Также можно отметить фреймворк Substrate VM, позволяющий выполнить компиляцию Java-приложений в форму самодостаточных исполняемых файлов или разделяемых библиотек (ELF-64 или 64-bit Mach-O). В Substrate VM применяется полноценная AOT-компиляция (Ahead-of-Time) без симуляции через запуск байткода в виртуальной машине. Фреймворк распространяется под лицензией GPLv2 и развивается компанией Oracle в рамках проекта Graal по разработке нового JIT-компилятора и runtime для JVM.

Источник: http://www.opennet.ru/opennews/art.shtml?num=47940

В рамках проекта NeoPG развивается форк GnuPG 2

Маркус Бринкман (Marcus Brinkmann), немецкий математик, известный своим участием в разработке GNU/Hurd, основал форк инструментария GnuPG (GNU Privacy Guard), предоставляющего совместимые со стандартом OpenPGP (RFC-4880) инструменты для шифрования данных, работы с электронными подписями, управления ключами и доступа к публичным хранилищам ключей. Новый проект получил название NeoPG и позиционируется в качестве современной замены GnuPG 2.

GnuPG критикуется как излишне раздутый проект: 490 тысяч строк кода на языке Си, около 400 опций, два парсера OpenPGP, свой HTTP-клиент и DNS-резолвер. Привязка к стандарту OpenPGP тянет за собой необходимость поддержки многих устаревших алгоритмов, потерявших актуальность в современных условиях (MD5, IDEA, DSA, 3DES, SHA-1, 64-разрядные ключи). Первичной задачей NeoPG называется проведение чистки кода и его адаптации для упрощения дальнейшей разработки, в том числе предоставление расширяемого стабильного API для разработчиков приложений.

Для достижения поставленной цели было решено удалить всю неактуальную функциональность, а для исключения некоторых видов ошибок и упрощения дальнейшей разработки перевести кодовую базу с языка Cи на C++11. Для упрощения интеграции с другими проектами весь новый код поставляется под разрешительной лицензией BSD вместо GPLv3. Предложен новый интерфейс командной строки, в котором произведено объединение входящих в GnuPG разрозненных утилит (gpg, gpgsm, gpgconf, gpgv, gpgtar и т.п.) в единый исполняемый файл neopg с оформлением субкоманд в стиле Git и поддержкой цветного вывода. В рамках команды "neopg gpg2" реализована прослойка для обеспечения совместимости с GnuPG 2.

За три месяца разработки NeoPG удалено 240 тысяч строк кода, добавлено около двух тысяч строк, прекращена поддержка 120 опций командной строки, осуществлён переход на систему сборки cmake. Вместо собственной реализации криптографических функций (Libgcrypt), задействована библиотека Botan, написанная на C++11 и поставляемая под лицензией BSD. Часть встроенных возможностей заменена на libcurl и SQLite. Вся базовая функциональность выделена в отдельную библиотеку libneopg, которую можно использовать в приложениях. Поверх libneopg реализована обвязка с CLI-интерфейсом.

В NeoPG также решено отказаться от запуска длительно работающих фоновых процессов gpg-agent, dirmngr (Directory Manager) и scdaemon (Smart Card Daemon). Вместо фоновых процессов обеспечен запуск одноразовых вспомогательных helper-процессов, которые завершают работу сразу после выполнения задания. В будущем планируется интегрировать функциональность данных helper-процессов в библиотеку libneopg и вообще избавиться от необходимости запуска дополнительных процессов.

Источник: http://www.opennet.ru/opennews/art.shtml?num=47936

Выпуск распределенной системы управления исходными текстами Git 2.16.0

Подготовлен выпуск распределенной системы управления исходными текстами Git 2.16.0. Git является одной из самых популярных, надёжных и высокопроизводительных систем управления версиями, предоставляющей гибкие средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток. Для обеспечения целостности истории и устойчивости к изменениям задним числом используются неявное хеширование всей предыдущей истории в каждом коммите, также возможно удостоверение цифровыми подписями разработчиков отдельных тегов и коммитов. По сравнению с прошлым выпуском в новую версию принято 509 изменений, подготовленных при участии 91 разработчика, из которых 26 впервые приняли своё участие в разработке.

Основные изменения:



Источник: http://www.opennet.ru/opennews/art.shtml?num=47935

Стабильный релиз Wine 3.0

После года разработки и 23 экспериментальных версий представлен стабильный релиз открытой реализации Win32 API - Wine 3.0, который вобрал в себя более 6000 изменений. Из ключевых достижений новой версии отмечается поддержка Direct3D 10 и 11, реализация обособленного потока обработки команд Direct3D, графический драйвер для платформы Android, улучшенная поддержка DirectWrite и Direct2D. Из возможностей, которые отложены до следующей значительной ветки, упоминаются поддержка Direct3D 12, Vulkan и реализация Direct3D через OpenGL ES на платформе Android.

В Wine подтверждена полноценная работа 4580 программ для Windows, еще 3907 программ прекрасно работают при дополнительных настройках и внешних DLL. У 3301 программ наблюдаются небольшие проблемы в работе, которые не мешают использованию основных функций приложений.

Ключевые новшества Wine 3.0:



Источник: http://www.opennet.ru/opennews/art.shtml?num=47934

В Firefox 58 появится новый двухуровневый компилятор

Разработчики Mozilla сообщили о включении в состав Firefox 58, релиз которого ожидается на следующей неделе, нового компилятора, который обеспечивает компиляцию промежуточного кода WebAssembly в 10-15 раз быстрее, чем используемый до этого оптимизирующий компилятор.

На типовой рабочей станции скорость компиляции кода WebAssembly достигает 30-60 Мб в секунду, а на мобильном устройстве 8 Мб в секунду, что быстрее, чем пропускная способность большинства сетей. Особенностью нового компилятора является возможность компиляции кода по мере его загрузки. В сочетании с высокой скоростью компиляции данная особенность позволяет получать готовый код почти сразу после окончания загрузки, так как большая часть кода успевает скомпилироваться во время загрузки кода.

Потребность в компиляции по мере загрузки возникла при появлении WebAssembly, так как для обычного JavaScript операции парсинга требуют заметных ресурсов, а псевдокод WebAssembly значительно проще для декодирования и компактнее (требует передачи меньшего объёма по сети для реализации аналогичной функциональности). Ранее параллельно с загрузкой JavaScript осуществлялся парсинг, который выполнялся в параллельном потоке и формировал готовый для компиляции код к моменту окончания загрузки JavaScript, но компиляция производилась после завершения разбора.

В WebAssembly готовность для компиляции наступает значительно раньше, а фазы декодирования и компиляции могут быть разделены на отдельные потоки и выполняться параллельно. Более того, компиляция может завершиться даже раньше окончания загрузки файла wasm, так как секция с кодом в модуле расположена раньше секции с данными, и псевдокод успевает скомпилироваться ещё когда секция данных продолжает загружаться.

Суть двухуровневого компилятора заключается в наличии двух фаз: baseline, в которой приоритет отдаётся скорости компиляции в ущерб качеству оптимизации, и оптимизирующей фазы, которая выполняется достаточно медленно, но выдаёт хорошо оптимизированный код. В частности, baseline-компиляция выполняется в 10-15 раз быстрее, но генерирует код, работающий примерно в два раза медленнее.

В процессе компиляции вначале применяется baseline-стадия, которая быстро формирует готовый для исполнения код. Далее данный код запускается, а параллельно начинает работать оптимизирующая стадия компилятора, которая формирует улучшенный и более быстрый вариант кода, который после готовности заменяет собой предложенный на первой стадии код.

Для WebAssembly и JavaScript метод вызова оптимизирующей стадии сильно отличается. Для JavaScript вторая стадия запускается спустя какое-то время после начала выполнения кода, лишь после того как накопится определённая статистика о характере выполнения и типах данных. В WebAssembly вся необходимая информация уже имеется в псевдокоде, поэтому нет смысла затягивать с выполнением второй фазы, и, как следствие, оптимизированный код быстрее замещает собой первоначальный черновой код.

Компиляция на второй стадии выполняется в отдельном потоке, параллельно с работой кода web-приложения. Для ускорения данной стадии в новом движке Firefox осуществляется распараллеливание на уровне компиляции отдельных функций, которое позволяет разнести компиляцию на несколько потоков и задействовать все простаивающие ядра CPU. Для ещё большего ускорения работы компилятора планируется добавить систему кэширования, которая при повторном выполнении wasm-файлов позволит сразу использовать уже ранее скомпилированный и сохранённый в кэше машинный код. В Firefox 58 функциональность будет ограничена поддержкой кэширования байткода для JavaScript (ускоряет загрузку Facebook на 12%, Twitter на 5.4%, сайтов Google на 4.9%), а кэширование итогового машинного кода будет реализовано в одном из дальнейших выпусков.



Источник: http://www.opennet.ru/opennews/art.shtml?num=47930

Google переводит рабочие станции инженеров с Goobuntu (Ubuntu) на gLinux (Debian)

Компания Google переводит внутренние рабочие станции технического персонала на новый дистрибутив gLinux, основанный на Debian Testing и использующий модель непрерывной доставки обновлений (rolling). Ранее на протяжении многих лет в Google применялся дистрибутив Goobuntu, развиваемый на базе LTS-выпусков Ubuntu. Для перехода с Goobuntu на gLinux разработан специальный инструментарий, позволяющий провести прозрачную миграцию рабочих станций.

Напомним, что Goobuntu представлял собой сборку Ubuntu, в которую были добавлены инструменты, используемые разработчиками в Google, а также компоненты для интеграции с внутренним сетевым окружением. Все домашние директории пользователей монтировались с централизованного файлового сервера, что позволяло получить доступ к своему окружению независимо от используемого компьютера. Сборка Goobuntu формировалась в рамках участия Google в программе Ubuntu Advantage Program, подразумевающей получение коммерческой поддержки от компании Canonical. Переход на Debian приведёт к более тесному сотрудничеству с сообществом, а использование ветки Testing даёт повод ожидать от Google подключения к участию в процессах тестирования и контроля качества Debian.

Источник: http://www.opennet.ru/opennews/art.shtml?num=47929 Новости | Севастополь| Crimea-Karro

Страницы: [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17]

crimea-karro.ru