Opensource проект Ocelot (http://code.google.com/p/gpuocelot/) недавно выпустил (http://forums.nvidia.com/index.php?showtopic=153448) JIT-компилятор для CUDA-приложений (http://ru.wikipedia.org/wiki/CUDA), позволяющий выполнять одну и ту же программу как на графических процессорах NVIDIA, так и на x86 процессорах, выступая в роли альтернативы технологии OpenCL (http://ru.wikipedia.org/wiki/OpenCL). Компилятор переводит инструкции GPU в байткод LLVM (http://ru.wikipedia.org/wiki/Low_Level_Virtual_Machine), а затем генерирует собственный код для различных целевых архитектур. Компилятор был проверен более чем на 100 приложениях CUDA. Весь код системы доступен под лицензией BSD.
Предварительный список возможностей:-
Для x86-процессоров:
- Multi-Core выполнение. Выполнение частей CUDA-программ автоматически распределяется между всеми ядрами процессоров в системе.
- Динамическая оптимизация. Оптимизация программных частей по мере их выполнения.
- Поддержка всех особе...URL: http://forums.nvidia.com/index.php?showtopic=153448
Новость: http://www.opennet.me/opennews/art.shtml?num=24804
Зачем нам CUDA приложения на x86, на оборот давай!!!
Не знаю как устроены GPU и CUDA, возможно скажу глупость, но вот класснои логично бы было реализовать на уровне ядра ОС чтобы предназначенные для распределеиния вычислений современные ядра GPU виделись бы в системе вместе с ядрами CPU и на них можно было бы распараллеливать потоки обычных x86-программ...
Писатель-фантаст...
Как-то не видно для этого преград, почему фантаст то сразу. Другое дело что производительность будет на ахти. Отчасти эти виртуальные ядра будут реализованы софтверным путём, как и в сабже. То есть тоже всё будет генерироваться динамически, и того чего не достаёт в gpu - будет перекладываться на cpu. В общем этакая продвинутая qemu:)
Тут проблема скорее в другом, большинство x86 программ однопоточны и от того что в системе будет ещё пара сотен виртуальных ядер не будет ни типло ни холодно. А распарсить поток инструкций x86 так, чтобы раскидать выполнение одного потока на 100 gpu - почти невыполнимая задача.
> Тут проблема скорее в другом, большинство x86 программ однопоточныВы таки думаете это надолго?
Мне кажется игнорировать многоядерность и писать программы без распоточивания всё больше и больше будет становиться нелепостью и уделом нигилистов.
>> Тут проблема скорее в другом, большинство x86 программ однопоточны
>
>Вы таки думаете это надолго?да. не все алгоритмы можно распараллелить:) поэтому от сотни ядер - ни холодно, ни жарко:D
Учите матчасть !
http://ru.wikipedia.org/wiki/%D0%97%D0%B...
>Учите матчасть !
>http://ru.wikipedia.org/wiki/%D0%97%D0%B...А я знаю эту формулу, просто, видится мне, α достаточно часто достаточно мала.
>Учите матчасть !
>http://ru.wikipedia.org/wiki/%D0%97%D0%B...Эта Манала не учитывает сложности алгоритмов и их количество.
На комбайнах типа Roadrunner, Lomonosov или BlueGeen это да,
а вот дома на венде.... я бы вывел как 1 + ln(p),
А кого тут интересует венда?
Как бы она даже не имеет cpuaffinity и ее шедулер все заоптимизирует так что процесс будет постоянно скакать с ядра на ядро что убьет весь смысл более чем одного ядра для этой системы
>А кого тут интересует венда?
>Как бы она даже не имеет cpuaffinityТак хорошо знаете WinAPI?
SetProcessAffinityMask()
SetThreadAffinityMask().Кстати, в отличии от UNIXов, там любой чанег*, через Менеджер Задач,
может руками выставить процессу, хоть все, хоть одно ядро (процессор).[*] Чайнег с правами администратора.
А кто знает, что такое cpu affinity, все администраторы. :))>и ее шедулер все заоптимизирует
>так что процесс будет постоянно скакать с ядра на ядро что
>убьет весь смысл более чем одного ядра для этой системы
Larabi. хотя x86 команды для этого как-то кривоваты чтоли:)
>Писатель-фантаст...Larabee. опечатался.
Сделано уже нечто подобное, http://en.wikipedia.org/wiki/Grand_Central_Dispatch
> распараллеливать потоки обычных x86-программ...там даже некоторые типы вычислительных программ не ускоряются, что уж про потоки обычных программ.
>Зачем нам CUDA приложения на x86, на оборот давай!!!Это скорее к nvidia, это очень даже в их интересах. Пусть выпускают ion3, который будет выглядеть как материнка с tegra2, fermi, nand для прошивки, а в прошивке qemu, реализующий x86 поверх cuda, который будет работать поверх tegra и fermi:D
Хороший ответ интелю на их заморочки с лицензиями. Если что - а мы не при делах, это ведь arm платформа, x86 там программная:D
Хотя где-то это уже проходили...
>>Зачем нам CUDA приложения на x86, на оборот давай!!!
>
>Это скорее к nvidia, это очень даже в их интересах. Пусть выпускают
>ion3, который будет выглядеть как материнка с tegra2, fermi, nand для
>прошивки, а в прошивке qemu, реализующий x86 поверх cuda, который будет
>работать поверх tegra и fermi:D
>Хороший ответ интелю на их заморочки с лицензиями. Если что - а
>мы не при делах, это ведь arm платформа, x86 там программная:D
>
>Хотя где-то это уже проходили...ммм.Transmeta и Эльбрус.
>ммм.Transmeta и Эльбрус.Конечно, только успехи у них были отстойные, так что оставим вместо них ...
Это c каких пор у Эльбруса неправильные успехи? С Itanic не попутали?
С тех самых пор, как они прекрасно продаются на рынке, выстесняя amd и intel, в параллельной реальности разумеется. Успехи в синтетике мало кому интересно. Когда можно будет купить это чудо по сравнимой с интелями цене, и чтобы оно давало хотя бы сравнимую производительности - тогда и поговорим.
В этом смысле трансмета то хоть производили реальные чипы, которые было можно пощупать, хоть им и защитали слив.
>С тех самых пор, как они прекрасно продаются на рынке, выстесняя amd
>и intel, в параллельной реальности разумеется. Успехи в синтетике мало кому
>интересно. Когда можно будет купить это чудо по сравнимой с интелями
>цене, и чтобы оно давало хотя бы сравнимую производительности - тогда
>и поговорим.
>В этом смысле трансмета то хоть производили реальные чипы, которые было можно
>пощупать, хоть им и защитали слив.Чтобы меня не защитали за фанатика, объясню. Любая разработка имеет смысл, если её можно как-то применить. Рынку не нужны процессоры, которые будут быстрее корок в 10 раз, а стоить в 100 больше. Потому что легче купить 10 корок. Результаты эльбруса, также как и трансметы хороши в теории, и хороши в определённых задачах. Но их стоит рассматривать лишь тогда, когда оно будет стоить приемлемые деньги и давать приемлемую производительность во всех средних случаях. Хотя бы потому, что для числодробительства теперь уже есть gpu, и amd, и nvidia поддерживает opencl. И те кому надо что-то сильно посчитать - те выберут явно их, а не эльбрус, потому что сейчас это дешевле. И кстати эльбрусу довольно сложно будет потягаться с nvidia, amd на паралельных задачах, хотя бы потому что они под это изначально затачивались. Остаётся таки ниша - конкурировать с универсальными cpu. Вот поэтому надо подождать того момента, когда оно появится на полках за приемлемые деньги.
В данный момент ситуация такая, что если вы сделаете процессор ядро которого будет быстрее в 10 раз современных процессоров (при той же архитектуре), то его купят и за цену в 100 раз больше. Потому что это выйдет во многих случаях дешевле, чем пытаться распараллеливать алгоритмы (которые возможно вообще не могут быть распараллелены).
а теперь пускай сделает для OpenCL
Ну вот теперь будет чем проверить мифическую мощь cell:)
Проблема в том, что в GPU много-много процессоров...
Ребята молодцы! Ещё их программа может помочь не быть привязанным только к NVIDIA, например, при расчёте физики в играх. А где же одноядерные системы?! Обделили?
Gentoo - пора неспешно начинать копить на термоядерную видеокарту! :)
реальность далека, но тенденция очевидна ;)