Комментарии 77
В чем можно быть уверенным: вопросов о покупке мощного процессора или мощной видеокарты за имеющиеся деньги станет меньше — можно будет говорить прямо о производительности APU.
Какие есть предположения о разработке: умные VM, перебрасывающие исполнение кода с одного ядра на другое (runtime не компиляция, можно просто проверить где быстрее). Особые компиляторы или изменения в старых, позволяющие исполнение кода на разных физических архитектурах (тут вспоминается Intel'овский компилятор, который создает две версии скомпилированного кода — для новых и старых архитектур), с последующей передачей полномочий по выбору нужного на уровень ОС.
И да, сообщество Gentoo будет в полном восторге!
Какие есть предположения о разработке: умные VM, перебрасывающие исполнение кода с одного ядра на другое (runtime не компиляция, можно просто проверить где быстрее). Особые компиляторы или изменения в старых, позволяющие исполнение кода на разных физических архитектурах (тут вспоминается Intel'овский компилятор, который создает две версии скомпилированного кода — для новых и старых архитектур), с последующей передачей полномочий по выбору нужного на уровень ОС.
И да, сообщество Gentoo будет в полном восторге!
>Какие есть предположения о разработке: умные VM, перебрасывающие исполнение кода с одного ядра на другое (runtime не компиляция, можно просто проверить где быстрее).
Не уверен, что такое очень легко сделать и будет оно очень эффективно. Таки всё-равно придется пересматривать подход к программированию.
Не уверен, что такое очень легко сделать и будет оно очень эффективно. Таки всё-равно придется пересматривать подход к программированию.
Я даже больше скажу: я уверен, что это будет очень нелегко сделать.
Но представьте, у вас есть CLR/JVM приложение, которое работает в 50 потоков. Доступны 100 ядер CPU и 100 ядер GPU. Почему бы не запустить по 25 потоков на каждый тип ядра, а потом по результатам перевести все на один тип ядра? Это вполне реализуемо, а значит этим кто-нибудь может воспользоваться.
При этом можно воспользоваться чем-то вроде CUDA, и спокойно перейти в новую эру с комплексом решений из нынешней.
Но представьте, у вас есть CLR/JVM приложение, которое работает в 50 потоков. Доступны 100 ядер CPU и 100 ядер GPU. Почему бы не запустить по 25 потоков на каждый тип ядра, а потом по результатам перевести все на один тип ядра? Это вполне реализуемо, а значит этим кто-нибудь может воспользоваться.
При этом можно воспользоваться чем-то вроде CUDA, и спокойно перейти в новую эру с комплексом решений из нынешней.
Начал писать комментарий и получился пост — habrahabr.ru/blogs/personal/108752/. Насчёт умных VM — согласен, но ещё очень много чего можно сделать на уровне архитектуры чипов.
НЛО прилетело и опубликовало эту надпись здесь
//Вообще, по мнению AMD, число ядер x86 нельзя увеличивать бесконечно
не совсем понял какое мнение по этому вопросу у Интел и почему приводится ссылка на мнение АМД (опять же непонятно — приводится как на авторитетное или нет).
:)
не совсем понял какое мнение по этому вопросу у Интел и почему приводится ссылка на мнение АМД (опять же непонятно — приводится как на авторитетное или нет).
:)
Это вообще-то даже не AMD придумали, это вытекает банально из архитектуры процессоров и свойств полупроводников.
В 2х словах: есть собственно время на вычисление, а есть время на загрузку исходных данных в процессор, на выгрузку результата и есть время на синхронизацию полученных результатов.
Так вот последнее время растет как n^2 от количества ядер и в один момент становится решающим, поэтому (условно) 64 ядерная x86 система может быть даже медленнее 16 ядерной при параллельных вычислениях.
В 2х словах: есть собственно время на вычисление, а есть время на загрузку исходных данных в процессор, на выгрузку результата и есть время на синхронизацию полученных результатов.
Так вот последнее время растет как n^2 от количества ядер и в один момент становится решающим, поэтому (условно) 64 ядерная x86 система может быть даже медленнее 16 ядерной при параллельных вычислениях.
>Между тем коллегам по бизнесу идея понравилась, и скоро в их процессорах тоже обоснуются графические ядра.
Этой идее сто лет в обед, и начали ее продвигать отнюдь не Intel, а совсем даже «коллеги по бизнесу» сразу после приобретения ATI.
Этой идее сто лет в обед, и начали ее продвигать отнюдь не Intel, а совсем даже «коллеги по бизнесу» сразу после приобретения ATI.
Хорошо-хорошо. Давайте лучше по основной теме поговорим :)
Ну, вы бы статью-то поправили. Вам же на ошибку указывают.
Мне кажется есть существенная разница между концептуальными моделями и их реальным воплощением. Atom, Core i3/i5 с графическим ядром доступны в магазинах уже сегодня. APU появятся там в следующем году.
Так это же не процессор-процессор, а SoC для встраиваемых систем. Разработка National Semiconductor десятилетней давности, не получившая особого развития. Ну серьезно — не стоит проводить параллели с современными процессорами.
И давайте поговорим про союз CPU c GPU сегодня, а не про дела давно минувших дней.
И давайте поговорим про союз CPU c GPU сегодня, а не про дела давно минувших дней.
Кроме технологической, принципиальная разница в чём? Вы уверены, что размещение на одном кристалле достаточно для получения какого-то выигрыша?
Да и, в любом случае, о чём речь? Устройства AMD на одном кристалле всё равно были представлены в 2007-м году, на выставке.
Так что некорректно говорить «между тем коллегам по бизнесу идея понравилась, и скоро в их процессорах тоже обоснуются графические ядра».
Так что некорректно говорить «между тем коллегам по бизнесу идея понравилась, и скоро в их процессорах тоже обоснуются графические ядра».
Странная «попсовая» подача поста. Такая осторожная статья для тинейджеров — «как бы не перегрузить». Не бойтесь, грузите! Больше фактов, больше материала. И уберите пожалуйста «якания» типа «я уже писал не раз». Правильно так: «подробности вы можете прочитать в статье <ссылка>».
Что касается сути вопроса, то выигрыш от многоядерности процессоров мы получаем независимо от оптимизации отдельных программ: в целом ОС работает быстрее за счёт распараллеливания программ (процессов) в целом, отзывчивость повышается и параллельное выполнение нескольких задач на компьютере — это уже не pain.
Точно также будет и с доступными вычислительными ресурсами графического ядра: каким программам оно будет нужно — те и возьмут. Проблемы тут нет, есть лишь интересные и заманчивые возможности.
За тему спасибо.
Успехов в творчестве.
PS: Почитаю память «КТ» пустой строкой молчания: "".
Что касается сути вопроса, то выигрыш от многоядерности процессоров мы получаем независимо от оптимизации отдельных программ: в целом ОС работает быстрее за счёт распараллеливания программ (процессов) в целом, отзывчивость повышается и параллельное выполнение нескольких задач на компьютере — это уже не pain.
Точно также будет и с доступными вычислительными ресурсами графического ядра: каким программам оно будет нужно — те и возьмут. Проблемы тут нет, есть лишь интересные и заманчивые возможности.
За тему спасибо.
Успехов в творчестве.
PS: Почитаю память «КТ» пустой строкой молчания: "".
Спасибо за мудрые советы и полное отсутствие «попсы» в комменте :)
>> выигрыш от многоядерности процессоров мы получаем независимо от оптимизации отдельных программ: в целом ОС работает быстрее за счёт распараллеливания программ (процессов) в целом
В идеале хотелось бы получить от системы максимум, а не просто избавится от pain. Согласитесь, звучит странновато: от части проблем избавились, и на том спасибо.
Полагаю, что Сергей как раз хотел спросить буквально следующее: какое ПО с неоднородными вычислениями вы используете? У меня, например, нет такого софта. А у вас?
В идеале хотелось бы получить от системы максимум, а не просто избавится от pain. Согласитесь, звучит странновато: от части проблем избавились, и на том спасибо.
Полагаю, что Сергей как раз хотел спросить буквально следующее: какое ПО с неоднородными вычислениями вы используете? У меня, например, нет такого софта. А у вас?
А у вас какая Windows? Если Vista или 7, то там GPU вполне себе активно используется для рендеринга ерунды всякой. Кроме того, Photoshop уже GPU использует, Flash тоже. Некоторые кодеки из набора ffmpeg. Числогрызные задачи вполне себе хорошо укладываются на GPU.
осторожней с вопросами «какая у вас windows»… она ведь не у всех…
Ну… А чем Linux какой-нибудь отличается? Там тоже многое умеет цепляться к GPU. Cairo, MPlayer, GiMP. Шахматы даже есть, которые CUDA используют. Но для обычных потребителей это, конечно, рендеринг всяко разный и обработка изображений. Вообще, это сильно немаловажная задача, потому что, например, когда мы пишем текст в Libreoffice каком-нибудь, то все эти буквочки, картиночки и прочее растеризуются из векторной формы. Тут GPU тоже уместен, как раз Cairo пытается его этим грузить.
Я про некорректность такого вопроса. Просто странно такую формулировку встретить на хабре. Естественно в nix тоже много чего к gpu цепляется, и open cl, и cuda там тоже есть.
>> Кроме того, Photoshop уже GPU использует
Это, скажем так, весьма распространненый миф.
Это, скажем так, весьма распространненый миф.
Почему миф? для масштабирования очень похоже что использует, для скрола тоже. Думаю, что для всяких поворотов тоже использует. Может быть не CUDA, а просто обычный opengl, но использует. По крайней мере, симптомы подходят=)
Пруфлинк?
Что пруфлинк? Вы последним фотошопом пользовались? В настройках есть галочка «использовать аппаратное ускорение», попробуйте ее снять, заметите ощутимую разницу в скорости, скажем, масштабирования (просто ctrl +-). А если будете использовать на компьютере без нужных драйверов, то с включенным ускорением будет нереально тормозить. Проверять на изображениях от 1000 пикселей по каждой стороне. На глаз заметно очень хорошо.
Ну так и читаем, в первом же абзаце: Photoshop CS5 still does not support any native CUDA-accelerated functions.
Перевод: «Photoshop CS5 до сих пор НЕ использует никаких функций, основанных на CUDA».
Что касается плагинов, то это какбы не совсем фотошоп, согласны? Это плагины к нему.
Будьте добры, если есть другие сведения — пруфлинк на сайт Adobe с описанием, что же именно в CS5 ускоряется.
Перевод: «Photoshop CS5 до сих пор НЕ использует никаких функций, основанных на CUDA».
Что касается плагинов, то это какбы не совсем фотошоп, согласны? Это плагины к нему.
Будьте добры, если есть другие сведения — пруфлинк на сайт Adobe с описанием, что же именно в CS5 ускоряется.
А то, что я вам написал, вас уже не устраивает: «Может быть не CUDA, а просто обычный opengl, но использует.»
GPU это не только CUDA, но и старый добрый рендер текстур.
GPU это не только CUDA, но и старый добрый рендер текстур.
Аргумент, но как заметили выше — отрисовка шрифтов в Windows тоже средставми видюхи делается, следовательно можно с полной уверенностью утверждать, что Windows Notepad — приложение, использующее CPGPU вычисления на полную катушку. Бинго!
В данном случае, использует windows, но вообще видюху оно использует на ура, попробуйте поскролить даже текст простой в блокноте если не будет никакого ускорения;)
Photoshop просто использует видео более серьезно, чем windows, используется не спрайтовое ускорение, а текстурное (извините, терминологию не знаю, думаю, понятно, что я хотел сказать). Это не максимум, что может дать видео, тем не менее ускоряет работу довольно неплохо по сравнению с предыдущей версией. Думаю, что cs6 будет уже с cuda и фильтры тоже будут ускоряться нативно.
Photoshop просто использует видео более серьезно, чем windows, используется не спрайтовое ускорение, а текстурное (извините, терминологию не знаю, думаю, понятно, что я хотел сказать). Это не максимум, что может дать видео, тем не менее ускоряет работу довольно неплохо по сравнению с предыдущей версией. Думаю, что cs6 будет уже с cuda и фильтры тоже будут ускоряться нативно.
Эээ. Почему миф? У nVIDIA можно плагин для ускорения. Вроде ускоряет вполне себе существенно.
Пруфлинк?
Ну да, ну да… На это я и намекаю. Если читать повнимательнее, то не очень уж впечатляющий список, да?
kb2.adobe.com/cps/405/kb405745.html
kb2.adobe.com/cps/405/kb405745.html
Ну… А почему возникают сомнения на тему, что это не 'только начало'? Вроде, особых проблем у графических фильтров при переезде на GPU не должно быть. Это же свёртки, в основном, что как раз укладывается на GPU очень хорошо. И писать из даже проще, чем аналогичное для CPU — один уровень вложенности циклов уходит и не надо раскидывать вручную всё по ядрам.
Никаких сомнений ;)
Вы подумали, что раз я работаю в Intel, значит должен быть против GPU. Как раз наоборот — я целиком за! Я просто пытаюсь раскрутить вас на приктические рассуждения. Почему это «только начало» уже как третий год, если «особых проблем у графических фильтров при переезде на GPU не должно быть»?
Примеры с физиками и математиками прекрасны, но меня интересуют примеры GPU _вычислений_ в _массовых_ продуктах. Ускорение отрисовки курсора мыши и прокрутки в Notepad не в счет.
Вы подумали, что раз я работаю в Intel, значит должен быть против GPU. Как раз наоборот — я целиком за! Я просто пытаюсь раскрутить вас на приктические рассуждения. Почему это «только начало» уже как третий год, если «особых проблем у графических фильтров при переезде на GPU не должно быть»?
Примеры с физиками и математиками прекрасны, но меня интересуют примеры GPU _вычислений_ в _массовых_ продуктах. Ускорение отрисовки курсора мыши и прокрутки в Notepad не в счет.
> Примеры с физиками и математиками прекрасны, но меня интересуют примеры GPU _вычислений_ в _массовых_ продуктах.
А зачем тянуть в массовые продукты?
Думаю, GPU проявят себя на новом витке технологий пользовательских интерфейсов: обсчёт 3D, голоса, AI и т.п. — просто индустрия ещё только начала переход к этому новому поколения алгоритмов и подходов.
> Ускорение отрисовки курсора мыши и прокрутки в Notepad не в счет.
Почему же?
Это важно.
А зачем тянуть в массовые продукты?
Думаю, GPU проявят себя на новом витке технологий пользовательских интерфейсов: обсчёт 3D, голоса, AI и т.п. — просто индустрия ещё только начала переход к этому новому поколения алгоритмов и подходов.
> Ускорение отрисовки курсора мыши и прокрутки в Notepad не в счет.
Почему же?
Это важно.
Ну. Откуда мне знать? В Adobe, например, уже очень долго не могут почему-то сделать 64-битовую версию Flash. Почему? Мистическая загадка эта.
Кроме того, я ж совсем не намекаю, что кто-то против. Просто спрашиваю, откуда сомнения.
Про массового пользователя… Хм. Массовому пользователю вообще хватает мощностей какого-нибудь Samsung Galaxy S. Ему, в общем-то, объективно, Core i7 совсем не нужен.
Мощности же нужны именно тем, кто занимается расчётами (игры вот, кстати, тоже счётные задачи, и на GPU тоже считаются, PhysX там всякий (таких игр много), DirectX 11 (тоже появляются)).
Не понятно, каких именно примеров Вы хотите? ПРосто так на GPU, конечно, никто ничего переписывать не будет, потому что это время и труд программистов. Если программа хорошо работает на x86, то никто и не почешется. ICQ на GPU портировать не будут.
Но есть куча программ, требующих производительности. Всякие там конструкторы, решатели, рендереры и прочее. В них вполне GPU приживаются, обеспечивая их мощностью. MATLAB, например. Оно массовое? Вроде, да, ведь, распространённое и востребованное. CUBLAS его ускоряет? — Да, в десятки раз. 3D Max? Тоже, вроде.
Эмс… Вот. Короче, нужно определиться, что есть такое массовость. Продукт, у которого сколько пользователей?
Кроме того, я ж совсем не намекаю, что кто-то против. Просто спрашиваю, откуда сомнения.
Про массового пользователя… Хм. Массовому пользователю вообще хватает мощностей какого-нибудь Samsung Galaxy S. Ему, в общем-то, объективно, Core i7 совсем не нужен.
Мощности же нужны именно тем, кто занимается расчётами (игры вот, кстати, тоже счётные задачи, и на GPU тоже считаются, PhysX там всякий (таких игр много), DirectX 11 (тоже появляются)).
Не понятно, каких именно примеров Вы хотите? ПРосто так на GPU, конечно, никто ничего переписывать не будет, потому что это время и труд программистов. Если программа хорошо работает на x86, то никто и не почешется. ICQ на GPU портировать не будут.
Но есть куча программ, требующих производительности. Всякие там конструкторы, решатели, рендереры и прочее. В них вполне GPU приживаются, обеспечивая их мощностью. MATLAB, например. Оно массовое? Вроде, да, ведь, распространённое и востребованное. CUBLAS его ускоряет? — Да, в десятки раз. 3D Max? Тоже, вроде.
Эмс… Вот. Короче, нужно определиться, что есть такое массовость. Продукт, у которого сколько пользователей?
то Вы пруфлинки требуете, то Вам пруфлинки невкусные… может пора уже согласиться, что таки да, использование есть.
ведь нельзя сказать, что не используют.
да, в будущем использовать будут шире.
но тем не менее, по факту — GPU используется.
ведь нельзя сказать, что не используют.
да, в будущем использовать будут шире.
но тем не менее, по факту — GPU используется.
> Согласитесь, звучит странновато: от части проблем избавились, и на том спасибо.
Ну так это уже хорошо и является таки достижением, разве нет?
> Полагаю, что Сергей как раз хотел спросить буквально следующее: какое ПО с неоднородными вычислениями вы используете?
Так бы и спросил.
Как пользователь я об этом не думаю специально. Если какой-то софт использует — то и хорошо.
> У меня, например, нет такого софта. А у вас?
Естественно, нет. А когда появился DirectX, у вас тоже сразу куча игрушек возникла? А когда появилось вообще 3D-ускорение, оно тоже было «не востребованно»? Дайте разработчикам время и позвольте им самим решить, где именно им нужны эти возможности.
Правильный вопрос должен быть адресован именно разработчикам: а где именно вы хотели бы и собираетесь использовать новые возможности?
Ну так это уже хорошо и является таки достижением, разве нет?
> Полагаю, что Сергей как раз хотел спросить буквально следующее: какое ПО с неоднородными вычислениями вы используете?
Так бы и спросил.
Как пользователь я об этом не думаю специально. Если какой-то софт использует — то и хорошо.
> У меня, например, нет такого софта. А у вас?
Естественно, нет. А когда появился DirectX, у вас тоже сразу куча игрушек возникла? А когда появилось вообще 3D-ускорение, оно тоже было «не востребованно»? Дайте разработчикам время и позвольте им самим решить, где именно им нужны эти возможности.
Правильный вопрос должен быть адресован именно разработчикам: а где именно вы хотели бы и собираетесь использовать новые возможности?
Все правильно говорите. Вероятно, Сергей полагал, что на Хабре как раз и есть такие разработчики, или, по крайней мере, продвинутые пользователи которые «думают специально». Очевидно, Сергей ошибся. Людям свойственно ошибаться ;).
Прошу не передёргивать.
Я ответил только за себя, а не за весь Хабр и всех пользователей.
Лично мне, как веб-программисту, не критично использование GPU, в игрушки тоже не играю, в фотошопе не работаю — вот я и не слежу за использованием GPU — лично я.
Тон и подача статьи призваны «вселить тревогу», обозначить какое-то противостояние, выпятить несуществующую проблему. Автор пытается передать своё страдание по поводу ненужности или нереализованности потенциала GPU.
Я же всего лишь пытаюсь переформулировать обозначенную тему в позитивном ключе: тут куча интересных задач и возможностей. И я уверен, что такие гибридные PU сделают нашу жизнь лучше.
Я ответил только за себя, а не за весь Хабр и всех пользователей.
Лично мне, как веб-программисту, не критично использование GPU, в игрушки тоже не играю, в фотошопе не работаю — вот я и не слежу за использованием GPU — лично я.
Тон и подача статьи призваны «вселить тревогу», обозначить какое-то противостояние, выпятить несуществующую проблему. Автор пытается передать своё страдание по поводу ненужности или нереализованности потенциала GPU.
Я же всего лишь пытаюсь переформулировать обозначенную тему в позитивном ключе: тут куча интересных задач и возможностей. И я уверен, что такие гибридные PU сделают нашу жизнь лучше.
>> И я уверен, что такие гибридные PU сделают нашу жизнь лучше.
Так и я уверен. Вопрос не в этом, вопрос насколько лучше, как быстро, и чего нам всем это будет стоить. Потому что проблема стоимости и сложности перехода существует, и это — факт.
Так и я уверен. Вопрос не в этом, вопрос насколько лучше, как быстро, и чего нам всем это будет стоить. Потому что проблема стоимости и сложности перехода существует, и это — факт.
проблема «стоимость» решаешься от «что готов заплатить пользователь», «цена площади процессора», «цена часа работы программиста», «объем работ программиста».
но в первую очередь всё упирается в первый пункт.
и пока пользователь не готов платить больше — GPGPU будет стоить столько же, потому как его будут пытаться впихнуть в ту же площадь процессора.
да и работа программиста… ну вы же понимаете, что тут «запас» огромен — прибыли боьлших софтверных компаний огромны, затраты на копирование продукта — 0. так что новый виндовс, фотошоп итд с обновленной и улучшенной поддержкой GPGPU будет стоить столько же.
но в первую очередь всё упирается в первый пункт.
и пока пользователь не готов платить больше — GPGPU будет стоить столько же, потому как его будут пытаться впихнуть в ту же площадь процессора.
да и работа программиста… ну вы же понимаете, что тут «запас» огромен — прибыли боьлших софтверных компаний огромны, затраты на копирование продукта — 0. так что новый виндовс, фотошоп итд с обновленной и улучшенной поддержкой GPGPU будет стоить столько же.
Не могу понять ваших доводов.
Что убудет? Что вы потеряете с появлением APU? Что станет дороже?
APU либо не будут дороже вообще, либо будут дороже незначительно. И уж точно APU будет стоить меньше, чем CPU+GPU. Так что тут только выигрыш.
Что за стоимость для разработчиков? А какова стоимость HTML5? Rails3? Вы можете не использовать эти технологии и работать по старинке. Также и с APU: работайте как с обычным CPU, если вашим приложениям не требуется большего. Но вот если использование GPU может дать выигрыш в вашем приложение, то ваши конкуренты ждать не будут и быстро освоят новые возможности. В этом смысле опять же в первую очередь выигрывают пользователи и динамичные эффективные разработчики — за счёт нового витка конкуренции.
Проблемы тут только для вымирающих динозавров.
Что убудет? Что вы потеряете с появлением APU? Что станет дороже?
APU либо не будут дороже вообще, либо будут дороже незначительно. И уж точно APU будет стоить меньше, чем CPU+GPU. Так что тут только выигрыш.
Что за стоимость для разработчиков? А какова стоимость HTML5? Rails3? Вы можете не использовать эти технологии и работать по старинке. Также и с APU: работайте как с обычным CPU, если вашим приложениям не требуется большего. Но вот если использование GPU может дать выигрыш в вашем приложение, то ваши конкуренты ждать не будут и быстро освоят новые возможности. В этом смысле опять же в первую очередь выигрывают пользователи и динамичные эффективные разработчики — за счёт нового витка конкуренции.
Проблемы тут только для вымирающих динозавров.
Физики активно считают на CUDA. Там проблем с точностью нет… Ну. И они идут на это, потому что вместо суток, скажем, их программы выполняются десятки минут. Там хорошо всё параллелится, векторизуется и всё такое прочее. При чём они CUDA любят, ибо она им даёт такую производительность, что количество переходит в качество — удаётся получать принципиально новые результаты.
Вот. Как-то так. И программировать не так уж и сложно. Хотя, конечно, OpenCL не для слабонервных. Но по сравнению с OpenMP вполне себе на одном уровне сложности.
Вот. Как-то так. И программировать не так уж и сложно. Хотя, конечно, OpenCL не для слабонервных. Но по сравнению с OpenMP вполне себе на одном уровне сложности.
А вообще. Есть такой Game-Developer по фамилии Olik. Как-то он недавно рассуждал на тему, GPU vs. CPU и сообщил, что в идеале бы хотелось видеть миграцию возможностей GPU в архитектуру CPU. Потому что, на самом же деле, что такое GPU — это такой ОЧЕНЬ широкий SIMD с гипертредингом (в терминологии Intel), и тайловым scatter-gather доступом к памяти.
Собственно… Насколько сложно это всё включить в CPU? Вот каким должен быть правильный вопрос в блоге Intel. И вообще, на самом деле очень интересно, чем же закончиалсь эпопея с Larrabee. Точнее, мы же все знаем, что вроде как пока от него отказались, но Intel могла бы и интригующих технических деталей подкинуть.
Собственно… Насколько сложно это всё включить в CPU? Вот каким должен быть правильный вопрос в блоге Intel. И вообще, на самом деле очень интересно, чем же закончиалсь эпопея с Larrabee. Точнее, мы же все знаем, что вроде как пока от него отказались, но Intel могла бы и интригующих технических деталей подкинуть.
НЛО прилетело и опубликовало эту надпись здесь
Верно, но сейчас все сильно сложнее. Иначе как объяснить тот факт, что OpenCL пока еще экзотика, нет?
НЛО прилетело и опубликовало эту надпись здесь
Sisal и Occam всё же не из той оперы, IMHO. Они достаточно ограничены по своим возможностям и экзотичны по синтаксису. Последний вообще, если я правильно понимаю, разрабатывался для транспьютеров.
OpenCL же (сам язык) — это просто Си. Плюс библиотека, которая позволяет этот Си загружать на видеокарту и связывать с ним буферы. Я бы сказал, что по сравнению, скажем, с работой с DLL тут всё не на много сложнее.
Компилятор, к счастью (угу, именно так, потому что иначе это уже было бы нечто сродни Skynet), в этом разобраться не в состоянии. Потому что у GPU модель программирования другая. А может я и не прав.
Вот с другой стороны: а почему OpenCL сделали таким похожим на Си? Может быть, как раз кто-то и планирует потом в компиляторы для Си добавить нечто подобное OpenMP только для работы с GPU? И, скажем, если компиляторы уже сейчас умеют генерировать эффективный SIMD-код, разворачивая циклы, то они, теоретически, и для GPU могли бы теми же самыми алгоритмами воспользоваться. Там просто ширина SIMD намного больше.
Но если с ребра посмотреть, а зачем? Зачем так сильно усложнять компилятор, который начнёт вносить всякие косяки в существующий код (с выравниванием указателей ух какие проблемы будут, они даже с нынешним SSE есть, и программировать 'как и раньше' не выёдет уж точно, язык останется, но под идиомами уже совсем другой смысл будет), если уже сейчас можно этим самым OpenCL воспользоваться из Python, при чём в достаточно удобной форме. Чем вот люди, занимающиеся мат-моделированием активно и занимаются.
OpenCL же (сам язык) — это просто Си. Плюс библиотека, которая позволяет этот Си загружать на видеокарту и связывать с ним буферы. Я бы сказал, что по сравнению, скажем, с работой с DLL тут всё не на много сложнее.
Компилятор, к счастью (угу, именно так, потому что иначе это уже было бы нечто сродни Skynet), в этом разобраться не в состоянии. Потому что у GPU модель программирования другая. А может я и не прав.
Вот с другой стороны: а почему OpenCL сделали таким похожим на Си? Может быть, как раз кто-то и планирует потом в компиляторы для Си добавить нечто подобное OpenMP только для работы с GPU? И, скажем, если компиляторы уже сейчас умеют генерировать эффективный SIMD-код, разворачивая циклы, то они, теоретически, и для GPU могли бы теми же самыми алгоритмами воспользоваться. Там просто ширина SIMD намного больше.
Но если с ребра посмотреть, а зачем? Зачем так сильно усложнять компилятор, который начнёт вносить всякие косяки в существующий код (с выравниванием указателей ух какие проблемы будут, они даже с нынешним SSE есть, и программировать 'как и раньше' не выёдет уж точно, язык останется, но под идиомами уже совсем другой смысл будет), если уже сейчас можно этим самым OpenCL воспользоваться из Python, при чём в достаточно удобной форме. Чем вот люди, занимающиеся мат-моделированием активно и занимаются.
Зачем спорить, я как раз об этом и говорю. Почему сейчас сложнее? Да потому что по сравнению с 80387, вычисления на GPU на данный момент слабо стандартизованы (хотя я и не эксперт, но точно о как минимум двух различных подходах, ага) а OpenCL задумавался как нечто универсальное. А как мы знаем из истории, обратная сторона универсальности — сложность.
Иными словами боюсь, что «подключить библиотеку» будет не так просто.
Иными словами боюсь, что «подключить библиотеку» будет не так просто.
AESNI появились в core i3/i5 32-нм и в Gulftown. А у VIA AES-инструкции появились не в Nano, а раньше. В С7 они точно были.
а можно немножко подробнее, что за графические ядра добавила Intel в процессоры? возможности? в какие именно ядра. тд.
хотя бы ссылку. потому как я не в курсе, а интересно.
хотя бы ссылку. потому как я не в курсе, а интересно.
Ну, в Sandy Bridge не стоит ожидать много от GPU, ато нестоит ожидать вовсе ничего. И если рассматривать это как шаг к существенной помощи от GPU, то это скорее такой мааленький шажок на пути к этому. Ибо, если мне не изменяет склероз, в Sandy Bridge GPU поддерживает DX10.1
Чего же ожидать от такого ядра? какой помощи?
И возникают вопросы:
1)DirectCompute да, нет, сильный ли профит будет.
2)OpenCL? (сомневаюсь)
3)CUDA? (очень сомневаюсь)
Что-то подсказывает мне, что бОльший шаг будет сделан не ранее Ivy Bridge.
Чего же ожидать от такого ядра? какой помощи?
И возникают вопросы:
1)DirectCompute да, нет, сильный ли профит будет.
2)OpenCL? (сомневаюсь)
3)CUDA? (очень сомневаюсь)
Что-то подсказывает мне, что бОльший шаг будет сделан не ранее Ivy Bridge.
Как мне не нравится, когда вроде бы умные люди ведуться на маркетинговый Turbo Boost.
Это не «увеличение», это уменьшение для снижения энергии во время простоя. И уменьшение во время больших нагрузок, чтобы не было выхода за пределы TDP. Всё. А то что маркетологи придумали называть это как «саморазгон» так это уже оставим на их совести.
Это не «увеличение», это уменьшение для снижения энергии во время простоя. И уменьшение во время больших нагрузок, чтобы не было выхода за пределы TDP. Всё. А то что маркетологи придумали называть это как «саморазгон» так это уже оставим на их совести.
Нужно активнее делать эту интеграцию.
При помощи CUDA я уже сегодня вижу плюсы от таких вот переездов.
Если учесть, что довольно скоро интел перейдет на 22 нано процесс и с учетом того, что мощности аля гигагерцы, уже не поднимаются практически — то выход однозначен — увеличение кол-ва ядер.
Но и это тоже не выход.
Выход — это интеграция GPU/CPU — и как можно быстрее.
При помощи CUDA я уже сегодня вижу плюсы от таких вот переездов.
Если учесть, что довольно скоро интел перейдет на 22 нано процесс и с учетом того, что мощности аля гигагерцы, уже не поднимаются практически — то выход однозначен — увеличение кол-ва ядер.
Но и это тоже не выход.
Выход — это интеграция GPU/CPU — и как можно быстрее.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
GPU в помощь?