» » Параллельное программирование » Страница 11

 

Altera + OpenCL: программируем под FPGA без знания VHDL/Verilog

Автор: admin от 8-11-2015, 13:17, посмотрело: 1611

Altera + OpenCL: программируем под FPGA без знания VHDL/Verilog

Всем привет!

Altera SDK for OpenCL — это набор библиотек и приложений, который позволяет компилировать код, написанный на OpenCL, в прошивку для ПЛИС фирмы Altera. Это даёт возможность программисту использовать FPGA как ускоритель высокопроизводительных вычислений без знания HDL-языков, а писать на том, что он привык, когда это делает под GPU.

Я поигрался с этим инструментом на простом примере и хочу об этом вам рассказать.

План:

  • Пару слов об FPGA

  • На чём запускать?

  • Процесс разработки (workflow)

  • OpenCL BSP

  • Компилируем кернел

  • … и запускаем

  • Заключение


Добро пожаловать под кат! Осторожно, будут картинки!

Категория: Программирование

 

Pony — убийца...?

Автор: admin от 31-10-2015, 03:17, посмотрело: 817

Всем известны такие прогрессивные новички в программировании, как — «Go, Rust, Nim, Crystal» и, все они очень круты в своих определенных областях.

К примеру:

  • Go был рожден, как супер простой и промышленный язык для быстрого решения поставленных задач с идеями, которые всем прекрасны известны, но некоторые из них прибиты к другим языкам гвоздями (На 5мм).

  • Второй наш оппонент — это Rust, победитель по жизни, но из-за своей сложной жизни в развитии он стал для сообщества, как будущая и модная замена C++. Для меня его судьба пока не понятна, так как с зелеными потоками и IO под них там пока туго, то я его ставлю на место в ряд с C для микроконтроллеров, драйверов и операционных систем.

  • Crystal… Прямо и четко говорю, что это супер производительный клон Ruby. Больше сказать нечего, весь он пропитан его духом.

  • Nim (Он же Нимушка или Нимрод) и его похожесть на скриптовые языки создают ему особую атмосферу, однако внутри он достаточно сложный организм и для меня сия сущность, как Haxe с такими же ощущениями при программировании на нем.



  • А Pony — это моя любимая и маленькая поняшка. С виду и по названию языка можно лихо пройти мимо… В общем, приглашаю вас под капот статьи.

    Категория: Программирование

     

    Планировщик Go

    Автор: admin от 21-10-2015, 18:43, посмотрело: 401

    Преамбула от переводчика: Это достаточно вольный перевод пусть и не самой свежей (июнь 2013 года), но доходчивой публикации о новом планировщике параллельных ветвей исполнения в Go. Достоинством этой заметки есть то, что в ней совершенно просто, «на пальцах» описывается новый механизм планирования для ознакомления. Тем же, кого не устраивает объяснение «на пальцах» и кто хотел бы обстоятельного изложения, рекомендую Scheduling Multithreaded Computations by Work Stealing — 29 страниц изложения со строгим и сложным математическим аппаратом для анализа производительности, 48 позиций библиографии.

    Введение


    Одной из наибольших новинок в Go 1.1 стал новый диспетчер, спроектированный Дмитрием Вьюковым (Dmitry Vyukov). Новый планировщик дал настолько разительное увеличение производительности для параллельных программ без изменений кода, что я решил написать что-нибудь об этом.

    Категория: Программирование

     

    Параллельное выполнение задач и синхронизация с условными переменными в shell

    Автор: admin от 14-10-2015, 01:31, посмотрело: 1304

    Как синхронизировать параллельные шелл-процессы, используя named pipes (FIFO-файлы) в качестве условных переменных. Как организовать параллельное выполнения зависимых задач в топологическом порядке с минимумом средств: POSIX shell, mkfifo, POSIX kernel. Как параллельный запуск ускорит загрузку встраиваемых систем и *BSD (rc-этап FreeBSD с 27 до 7 секунд) или старт приложений в пользовательских контейнерах Docker, LXC и jail. Как это повышает аптайм в отказоустойчивых кластерах Jet9.

    Категория: Программирование, Системное администрирование, Linux

     

    Async/await и механизм реализации в C# 5.0

    Автор: admin от 9-10-2015, 20:55, посмотрело: 548

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


    Механизм async реализован в компиляторе C# при поддержке со стороны библиотек базовых классов .NET. В саму исполняющую среду не пришлось вносить никаких изменений. Это означает, что ключевое слово await реализовано путем преобразования к виду, который мы могли бы написать и сами в предыдущих версиях C#. Для изучения генерируемого кода можно воспользоваться декомпилятором .NET Reflector или ILSpy. Это не только интересно, но и полезно для отладки, анализа производительности и других видов диагностики асинхронного кода.
    Подробности

    Категория: Программирование

     

    Реплицируемый объект. Часть 1: Введение

    Автор: admin от 23-09-2015, 09:51, посмотрело: 370

    Предисловие. Данная публикация является авторским переводом собственной статьи. Поэтому если вы найдёте ошибку в переводе, то вполне может оказаться, что ошибка, на самом деле, в оригинальной статье.

    Аннотация



  • Есть страдание.

  • Есть причина страдания.

  • Есть прекращение страдания.

  • Есть путь, ведущий к избавлению от страданий.


  • 4 благородные истины буддизма

    Настоящая статья содержит описание раннего прототипа, который вводит понятие реплицируемого объекта (replicated object) или сокращённо replob. Такой объект является дальнейшим переосмыслением борьбы со сложностью кода, возникающего при программировании распределённых систем. Replob устраняет зависимость от стороннего сервиса и реализует согласованное изменение любых пользовательских объектов, представляющих соответствующие данные и функциональность. Эта идея основана на использовании выразительности языка C++ и объектно-ориентированного подхода, что позволяет использовать сложную логику внутри распределённых транзакций. Это позволяет значительно упростить разработку отказоустойчивых приложений и сервисов. Последующие статьи будут более детально объяснять развиваемый подход.

    Введение


    ПРЕДУПРЕЖДЕНИЕ. Почти все методы, указанные в статье, содержат грязные хаки памяти и ненормальное использование языка C++. Так что, если вы не толерантны к таким извращениям, пожалуйста, не читайте эту статью.

    На текущий момент, тематика, связанная с распределёнными системами, является одной из самых интересных, и привлекают большое количество людей, включая разработчиков и учёных. Популярность объясняется просто: мы должны создавать надежные отказоустойчивые системы, которые обеспечивают безопасную среду для выполнения различных операций и для хранения данных.

    Категория: Программирование

     

    Вебинар: Основы распараллеливания С/С++ программ при помощи OpenMP

    Автор: admin от 22-09-2015, 14:49, посмотрело: 437

    Вебинар: Основы распараллеливания С/С++ программ при помощи OpenMP

    Приветствую Хабр!

    Наша команда FlyElephant продолжает проведение вебинаров и я хочу пригласить всех 28 сентября в 17.00 на вебинар, на котором мы рассмотрим основы распараллеливания С/С++ программ при помощи OpenMP, познакомимся с функционалом FlyElephant и освоим на примерах принципы работы с платформой. Поговорим о программе бета-тестирования и новом функционале, который будет доступен в ближайшее время.

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

    Зарегистрироваться на вебинар можно здесь.

    Категория: Программирование, Веб-разработка

     

    Intel Threading Building Blocks 4.4 – что нового?

    Автор: admin от 22-09-2015, 09:23, посмотрело: 442

    Недавно вышло большое обновление Intel Parallel Studio XE 2016, и вместе с ним Intel Threading Building Blocks 4.4. В новой версии появилось несколько интересных дополнений:

    • Глобальный контроль для управления ресурсами, в первую очередь, количеством рабочих потоков.

    • Новые типы узлов Flow Graph: composite_node и async_node. Кроме того, во Flow Graph была улучшена функциональность сброса (reset).

    • Больше фишек из С++11 для лучшей производительности.


    Intel Threading Building Blocks 4.4 – что нового?

    Категория: Программирование

     

    Python 3.5; async/await

    Автор: admin от 18-09-2015, 16:43, посмотрело: 955

    Тихо и незаметно (с), вышел Python версии 3.5! И, безусловно, одно из самых интересных нововведений релиза является новый синтаксис определения сопрограмм с помощью ключевых слов async/await, далее в статье об этом.

    Поверхностный просмотр «PEP 0492 — Coroutines with async and await syntax» по началу оставил у меня вопрос «Зачем это надо». Сопрограммы удовлетворительно реализуются на расширенных генераторах и на первый взгляд может показаться, что все свелось к замене yield from на await, а декоратора, создающего сопрограмму на async. Сюда можно добавить и возникающее ощущение, что все это сделано исключительно для использования с модулем asyncio.

    Но это, конечно же, не так, тема глубже и интереснее.

    Категория: Программирование

     

    Оптимизация быстродействия динамического выделения памяти в многопоточной библиотеке

    Автор: admin от 18-09-2015, 13:13, посмотрело: 440

    Оптимизация быстродействия динамического выделения памяти в многопоточной библиотеке

    Предисловие


    Данная статья выросла из проблемы, которую мне относительно недавно пришлось решить: скорость кода, предназначенного для работы одновременно в нескольких потоках, резко упала после очередного расширения функционала, но только на Windows XP/2003. С помощью Process Explorer я выяснил, что в большинство моментов времени исполняется только 1 поток, остальные находятся в ожидании, причём TID активного потока постоянно меняется. На лицо явная конкуренция за ресурс, и этим ресурсом оказалась куча по умолчанию (default heap). Новый код активно использует динамическое выделение/высвобождение памяти (копирование строк, копирование/модификация STL контейнеров большого размера), что собственно и привело к возникновению данной проблемы.

    Немного теории


    Как известно, аллокатор по умолчанию (default allocator) для STL контейнеров и std::basic_string (std::allocator) выделяет память из кучи по умолчанию, а операции выделения/высвобождения памяти в ней являются блокирующими (косвенное подтверждение). Исходя из этого, при частых вызовах HeapAlloc/HeapFree мы рискуем намертво заблокировать кучу для других потоков. Собственно это и произошло в моём случае.

    Категория: Программирование, Веб-разработка, Windows