LINUX.ORG.RU

Релиз PoCL 1.0

 ,


0

1

Представлен выпуск PoCL 1.0 - портабельной реализации стандарта OpenCL.

Исходный код распространяется по лицензии MIT.

Есть поддержка платформ: X86_64, MIPS32, ARM v7, AMD HSA APUs и различных специализированных TTA-процессоров c архитектурой VLIW.

Поддерживаются ICD-драйверы. Присутствуют back-end'ы для работы через CPU, ASIP (TCE/TTA), GPU на базе архитектуры HSA и GPU. Реализация компилятора ядер OpenCL построена на базе LLVM, а в качестве front-end'а OpenCL C используется Clang.

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

  • улучшена поддержка инструкций;
  • бэкенд, который использует CPU, базируется на спецификации OpenCL 1.2 и поддерживает отдельные элементов стандарта OpenCL 2.0;
  • добавлена поддержка CUDA для GPU NVIDIA;
  • выполнена оптимизация производительности на многоядерных системах;
  • появилась возможность использования выпусков LLVM/Clang 4.0 и 5.0;
  • различные незначительные улучшения.

>>> Анонс релиза



Проверено: Shaman007 ()

Представлен выпуск портативного компьютерного языка PoCL 1.0, который развивает стандарт OpenCL.

Pocl is a portable open source (MIT-licensed) implementation of the OpenCL standard (1.2 >with some 2.0 features supported). In addition to producing an easily portable open-source OpenCL implementation, another major goal of this project is improving performance >portability of OpenCL programs with the kernel compiler and the task runtime, reducing the need for target-dependent manual optimizations.

Т.е. в первую очередь стандарт он все-таки реализует, а не развивает.

Недавно хотел одну свою программку распараллелить на видеокарты - стал смотреть в сторону CUDA и OpenCL. С одной стороны вроде прикольно, что OpenCL открытый стандарт и работает на куче архитектур. С другой стороны, есть подозрение, что в своей основной нише - в вычислениях на суперкомпьютерах, где каждый процент скорости и производительности на счету - OpenCL всегда будет проигрывать КУДЕ просто из-за своей неспецифичности. В-общем, непонятно, зачем так гнаться за универсальностью.

anonymous ()
Ответ на: комментарий от Napilnik

Своего компилятора нет, обёртка...

pocl uses Clang as an OpenCL C frontend and LLVM for kernel compiler implementation, and as a portability layer.

Похоже, что есть. Т.е. clang для разбора сишного кода в опенцл-ядрах и llvm для реализации компилятора.

anonymous ()
Ответ на: комментарий от anonymous

Разве llvm само по себе есть хорошо? При переносе кода на другую платформу нужно учитывать ОС специфичные фичи, а здесь кто-то сделал их за тебя - не улучшишь. Кроме того, llvm написан на плюсах, и с большой вероятностью, обёртки к нему превратятся в ещё один визуалбейсик или 1С, только с другим синтаксисом.

Napilnik ★★★★★ ()
Ответ на: комментарий от pftBest

Вот именно что все - что одному проекту хорошо, то для другого ошибка сегментации. И опять же, чтобы поправить язык А, надо хорошо знать язык Б.

Napilnik ★★★★★ ()
Последнее исправление: Napilnik (всего исправлений: 1)
Ответ на: комментарий от pftBest

И причем тут типы строк к LLVM?

Строки необходимо реализовать на глубинном уровне, с менеджером памяти пошаманить. А на глубинном уровне в данном случае оказывается - что?

LLVM работает только с промежуточным представлением, а там никаких строк уже нет.

И значит строки придётся придумывать исходя их возможностей LLVM.

Napilnik ★★★★★ ()
Ответ на: комментарий от Napilnik

Еще раз спрошу причем тут строки? человек сказал что редактировал LLVM, а ты ему предлагаешь поменять синтаксис языка. LLVM этим не занимается, он ничего не знает про objective C.

Если хочешь добавить новые строки в objective C, то менять нужно в первую очередь фронтенд (clang) а трогать LLVM скорее всего не нужно будет совсем.

pftBest ★★★ ()
Ответ на: комментарий от pftBest

Еще раз спрошу причем тут строки? человек сказал что редактировал LLVM

Он не просто вдруг сказал, а отвечал на предыдущее сообщение.

Если хочешь добавить новые строки в objective C, то менять нужно в первую очередь фронтенд (clang) а трогать LLVM скорее всего не нужно будет совсем.

Если так всё хорошо, то почему gcc для x86_64-linux генерирует код напрямую, а не через LLVM? Да и для оффтопа мингв почему генерирует код не через него?

Napilnik ★★★★★ ()
Ответ на: комментарий от Napilnik

Если так всё хорошо, то почему gcc для x86_64-linux генерирует код напрямую, а не через LLVM? Да и для оффтопа мингв почему генерирует код не через него?

Потому что gcc на 20 лет старше llvm. А вот clang как раз использует llvm для генерации машинного кода (да и вообще является частью llvm).

anonymous ()
Ответ на: комментарий от Napilnik

почему gcc для x86_64-linux генерирует код напрямую

Потому что это было давно и не правда. gcc 3.4 еще генерил код напрямую, но начиная с версии 4.0 (2005 год), gcc тоже использует промежуточное представление, называется GIMPLE.

pftBest ★★★ ()
Ответ на: комментарий от anonymous

да и вообще является частью llvm

Скорее наоборот, llvm можно собрать и использовать без clang, но clang нельзя собрать без llvm, значит llvm часть clang.

А вообще да, они оба в составе LLVM Project

pftBest ★★★ ()
Ответ на: комментарий от Napilnik

Вот! Своё использует, а не чужое.

ну и что? а эпл на айфонах тоже свою операционную систему использует а не андроид, как все, ну и что? это никак не означает что iOS лучше чем android или наоборот.

pftBest ★★★ ()
Ответ на: комментарий от pftBest

ну и что?

И то, что в своём коде легко контролировать кодовую базу. К примеру, обратится некто к хозяевам ЛЛВМ: привет, я тут новый бейсик изобрёл, на вашей ЛЛВМ работает, только вам нужно в свою программу мои патчи принять, от которых от сиськи плюсы отвалятся и шланг лопнет, спасибо за понимание. Думаешь, прокатит?

а эпл на айфонах тоже свою операционную систему использует а не андроид, как все, ну и что?

И то, что раз своя ОС уже есть, то на чужие хотелки можно класть увесисты болт.

Napilnik ★★★★★ ()