Релиз PoCL 1.0

Представлен выпуск портативного компьютерного языка 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 всегда будет проигрывать КУДЕ просто из-за своей неспецифичности. В-общем, непонятно, зачем так гнаться за универсальностью.

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

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

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

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

портабельной переносимой же?

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

а здесь кто-то сделал их за тебя - не улучшишь

Если можешь улучшить, отправляешь патч в llvm и все в плюсе.

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

чтобы поправить язык А, надо хорошо знать язык Б

А вот и нет, я добавлял в llvm фичи для objective C, абсолютно не зная при этом objective c =)

GPU на базе архитектуры HSA и GPU.

И что же это за архитектура такая GPU?

А ты что-нибудь системное в objective c добавь. Например новый тип строк, не состоящий из базовых переменных, которого там нет.

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

на опеннете было больше понятно из новости на чем это можно запускать

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

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

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

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

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

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

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

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

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

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

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

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

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

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

но начиная с версии 4.0 (2005 год), gcc тоже использует промежуточное представление, называется GIMPLE

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

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

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

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

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

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

ну и что?

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

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

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