Comments 27
объясните нубу, почему цпу не делают на тех же технологиях, что и гпу. Какие у гпу недостатки в сравнении с цпу?
GPU создан, чтобы выполнять простые операции над большим объемом однотипных данных (преобразовать пиксели на экране, вершины в сцене). Если операции сложные, а данных немного, то GPU будет проигрывать CPU, и наоборот.
Вывод кратко — CPU и GPU созданы для разных задач и пытаться впихнуть все функции в один чип — это как пытаться создать продукт, решающий все проблемы, который нужен всем и который купят все :)
CPU создан для выполнения программ общего назначения. Архитектура CPU много сложнее архитектуры GPU — так как CPU должен эффективно быстро обрабатывать любой код общего назначения — с ветвлениями, переходами, сбросами конвейера, переключениями между контекстами и прочее. Чтобы всё это делать быстро и хорошо используется куча оптимизаций типа выполнение инструкций не по порядку (Out of Order execution), предсказание переходов, поддержка когерентности кэшей, поддержка балансирования загрузки исполнительных портов, переименование регистров и прочее.
GPU — это сугубо High-Performance арифметика, массивно-параллельный сопроцессор, специально созданный для обработки массивных последовательностей входных данных (изначально графики — пиксели, вершины, цвета), теперь — любые массивно сериализуемые данные.
GPU никогда не сможет выполнять программу общего назначения (тем более так же эффективно, как это делает CPU). С другой стороны, CPU не нужно быть молотилкой, усложняя ещё больше свою архитектуру. Добавление массивного параллелизма в процессор общего назначения — тяжелая задача, которая приведёт к замедлению общей производительности. Гораздо правильнее вынести тяжёлые вычисления на сопроцессор, не нагружая основную архитектуру.
CPU создан для выполнения программ общего назначения. Архитектура CPU много сложнее архитектуры GPU — так как CPU должен эффективно быстро обрабатывать любой код общего назначения — с ветвлениями, переходами, сбросами конвейера, переключениями между контекстами и прочее. Чтобы всё это делать быстро и хорошо используется куча оптимизаций типа выполнение инструкций не по порядку (Out of Order execution), предсказание переходов, поддержка когерентности кэшей, поддержка балансирования загрузки исполнительных портов, переименование регистров и прочее.
GPU — это сугубо High-Performance арифметика, массивно-параллельный сопроцессор, специально созданный для обработки массивных последовательностей входных данных (изначально графики — пиксели, вершины, цвета), теперь — любые массивно сериализуемые данные.
GPU никогда не сможет выполнять программу общего назначения (тем более так же эффективно, как это делает CPU). С другой стороны, CPU не нужно быть молотилкой, усложняя ещё больше свою архитектуру. Добавление массивного параллелизма в процессор общего назначения — тяжелая задача, которая приведёт к замедлению общей производительности. Гораздо правильнее вынести тяжёлые вычисления на сопроцессор, не нагружая основную архитектуру.
Есть встроенные графические процессоры типа Intel HD Graphics. Хотя физически GPU и CPU там отдельно, но всё-равно грань размывается — один комбинированный чип. Наверное в такой архитектуре можно все числодробительные вещи вынести в GPU, а CPU упростить. Интересно, можно ли вообще всю арифметику вынести в GPU...
Кстати, а ведь раньше были FPU (математические сопроцессоры). Сначала они были отдельно, а потом их интегрировали в CPU.
Кстати, а ведь раньше были FPU (математические сопроцессоры). Сначала они были отдельно, а потом их интегрировали в CPU.
Так же для GPU не столь важна обратная совместимость как для CPU, если ничего не путаю.
Почему не на тех же? На тех же. Но у CPU есть ещё задачи по взаимодействию с более медленными устройствами вокруг, обслуживанию операционной системы и много что другое, что не нужно делать более специализированному GPU.
и возможно ли управлять этим в веб-пространстве
Думаю можно это использовать в распознавании картинок. В других же web аспектах, cpu не является узким местом. Обычно это жесткий диск.
Я имел в виду весьма простые вещи — стоит ли всю анимацию делать с помощью CSS, надеясь, что под капотом он передает все на обработку GPU?
Not all CSS property changes on elements can be handled directly in the GPU. Only the following properties are supported:
transform
opacity
filter
transform
opacity
filter
Анимацию невозможно делать на GPU, т.е. возможно, но очень специфическую. Например пламя с помощью движение текстур и смешивания масок. В играх юзер интерфейс рисуется так же как и в браузере — на GPU, за исключением эффектов: свечение например или анимированный фон. Для браузеров есть webgl, но применять его к разметке нельзя, только к opengl объектам. Посмотри css фильтры в IE, они на GPU вроде работают.
Ну тут не только css…
У меня был юз-кейс.
Нужен был data-grid на html5 (в узко-специализированную админ-панель):
1) 40+ строк * 20+ столбцов
2) нетормозящая прокрутка
3) мгновенная отрисовка
4) динамическая подгрузка данных с сервиса
Все готовые решения жутко тормозили.
Стал копать где «узкое горлышко» — выяснилось:
1) создание DOM на каждую строчку. Решилось lazy-созданием, и перемещением (а не удалением/пересозданием) строчек за границой видимости.
2) отрисовка 800+ div'ов с данными. GPU в помощь.
Хром умеет композитить 3d слои при наличии GPU (гугл: GPU Accelerated Compositing in Chrome)
Написал свой дата-грид, использующий это свойство — решил все задачи.
Если в 2х словах, то в хроме:
1) запихнуть кусок DOM'а в слой: css свойство transform: translate3d(0, 0, 0);
2) посмотреть границы 3d-слоев: chrome developer tools -> rendering -> show layer borders
У меня был юз-кейс.
Нужен был data-grid на html5 (в узко-специализированную админ-панель):
1) 40+ строк * 20+ столбцов
2) нетормозящая прокрутка
3) мгновенная отрисовка
4) динамическая подгрузка данных с сервиса
Все готовые решения жутко тормозили.
Стал копать где «узкое горлышко» — выяснилось:
1) создание DOM на каждую строчку. Решилось lazy-созданием, и перемещением (а не удалением/пересозданием) строчек за границой видимости.
2) отрисовка 800+ div'ов с данными. GPU в помощь.
Хром умеет композитить 3d слои при наличии GPU (гугл: GPU Accelerated Compositing in Chrome)
Написал свой дата-грид, использующий это свойство — решил все задачи.
Если в 2х словах, то в хроме:
1) запихнуть кусок DOM'а в слой: css свойство transform: translate3d(0, 0, 0);
2) посмотреть границы 3d-слоев: chrome developer tools -> rendering -> show layer borders
Ну про слои знаю.
Где почитать подробнее (желательно на русском или с примерами), как заставить хром
Ты просто каждую строчку вынес в отдельный слой?
Если обычно DOM рисует CPU, то если вынести в слой 3d трансформацией — то будет этот участок отрисовывать GPU? Непонятно совсем.
Загуглил «GPU Accelerated Compositing in Chrome» — весьма мало понятного о том, как это работает (пишут, как включить).
Где почитать подробнее (желательно на русском или с примерами), как заставить хром
композитить 3d слои при наличии GPU
Ты просто каждую строчку вынес в отдельный слой?
Если обычно DOM рисует CPU, то если вынести в слой 3d трансформацией — то будет этот участок отрисовывать GPU? Непонятно совсем.
Загуглил «GPU Accelerated Compositing in Chrome» — весьма мало понятного о том, как это работает (пишут, как включить).
Где почитать (тем более не русском), не знаю — делал это 3+ года назад — путем проб и ошибок.
Тогда информации было еще меньше — т.к. кросс-браузерность, неустоявшиеся спеки и т.д — никто в продакшен не брал.
На мой взгляд, инструментов в хроме вполне достаточно, чтобы понять где затык.
Timeline в хроме вполне наглядно всё показывает.
Да — вынес каждую строчку в слой.
Перефразируя «на пальцах»:
свойство translate3d(0, 0, 0) — а ля галочка «запихни это в слой».
слой (при статичном содержании) рендерится (лейаутится, рисуется) на CPU 1 раз — читай, растровое изображение/текстура.
при последующих перерисовках (например, прокрутка, или что-то другое) слои композитятся на GPU.
если ничего не путаю, кто-то из родителей тоже должен быть слоем.
«chrome developer tools -> rendering -> show layer borders» обводит каждый слой.
Каждая строчка = отдельный слой => profit.
Мой data-grid за эти 3 года править не пришлось — всё работает.
P.S. А вот flexbox уже раза 4 ломали…
Тогда информации было еще меньше — т.к. кросс-браузерность, неустоявшиеся спеки и т.д — никто в продакшен не брал.
На мой взгляд, инструментов в хроме вполне достаточно, чтобы понять где затык.
Timeline в хроме вполне наглядно всё показывает.
Да — вынес каждую строчку в слой.
Перефразируя «на пальцах»:
свойство translate3d(0, 0, 0) — а ля галочка «запихни это в слой».
слой (при статичном содержании) рендерится (лейаутится, рисуется) на CPU 1 раз — читай, растровое изображение/текстура.
при последующих перерисовках (например, прокрутка, или что-то другое) слои композитятся на GPU.
если ничего не путаю, кто-то из родителей тоже должен быть слоем.
«chrome developer tools -> rendering -> show layer borders» обводит каждый слой.
Каждая строчка = отдельный слой => profit.
Мой data-grid за эти 3 года править не пришлось — всё работает.
P.S. А вот flexbox уже раза 4 ломали…
Хотелось бы увидеть демку.
Я вот пробовал 20 тысяч строк с 10 колонками сразу загружать в виде таблицы, и затем фильтровать в поиске — жутко медленно, причём первичная отрисовка таблицы браузером занимала десятки секунд, дальнейшая фильтрация уже была быстрее. Интересно как это ускорить.
Я вот пробовал 20 тысяч строк с 10 колонками сразу загружать в виде таблицы, и затем фильтровать в поиске — жутко медленно, причём первичная отрисовка таблицы браузером занимала десятки секунд, дальнейшая фильтрация уже была быстрее. Интересно как это ускорить.
Статья 2011 года и в ней, например, нет никаких данных по использованию математических сопроцессоров вместо GPU — типа Intel Xeon Phi.
Эти сопроцессоры (63+1 ядро у текущей версии Intel Xeon Phi) позволяют НЕ писать отдельный код для GPU и использовать гораздо более сложные операции. Вопрос о сравнении производительности этих решений (а также сопровождения таковых программных комплексов) еще открыт :) Борьба продолжается.
Эти сопроцессоры (63+1 ядро у текущей версии Intel Xeon Phi) позволяют НЕ писать отдельный код для GPU и использовать гораздо более сложные операции. Вопрос о сравнении производительности этих решений (а также сопровождения таковых программных комплексов) еще открыт :) Борьба продолжается.
Антон, ремарка про 2011 год есть в начале статьи, но мы следим за Phi и в планах есть написание статьи на эту тему. FPGA vs Phi, как-то так.
А расскажите поподробней, что из себя представляет программирования под этот Intel Xion Phi. Я правильно понимаю, что на низком уровне просто предоставляютя дополнительные SIMD инструкции, которые обрабатывают уже не 4, а 64 числа в параллели?
И ещё, я так понимаю, что Xion Phi пока производится только для суперкомпьютеров? Т.е. попробовать его у себя дома или, скажем, на сервере в Амазоне пока невозможно?
И ещё, я так понимаю, что Xion Phi пока производится только для суперкомпьютеров? Т.е. попробовать его у себя дома или, скажем, на сервере в Амазоне пока невозможно?
Под Xeon Phi можно программировать по разному. Например, Intel Math Kernel Library поддерживает эту плату и сама решает какие инструкции туда отправить. Также, можно вручную загрузить (offload) данные для обработки на эту плату и заставить ее что-то делать. При программировании (например C++ или Fortran) просто указывается что загрузить, а обработка осуществляется стандартными функциями и процедурами, никаких новых команд учить не нужно (прямое отличие от GPU). Преимущество — в том, что на плате 63+1 ядро, в отличии от 4-8 на стандартном процессоре. Ближайшее сравнение — использование OpenMP инструкций при помощи pragma-выражений.
Можно также посмотреть туториал TACC (Texas Advanced Computing Center) по программированию с использованием Intel Xeon Phi. Он большой — но можно просто полистать примеры.
https://portal.tacc.utexas.edu/-/programming-the-xeon-phi-xsede-
https://portal.tacc.utexas.edu/-/programming-the-xeon-phi-xsede-
Sign up to leave a comment.
GPU vs CPU: Почему для анализа финансовых данных применяют графические процессоры