По теме из базы знаний
- Как сформировать команду проекта цифровизации ТОиР? Из "Отряда самоубийц" — в "команду мечты"
- Независимая разработка совместимых компонент на ORM 1С – миф или истина где-то в аннотациях Java?
- О чем думает специалист, или каким должен быть текст идеальной вакансии
- Мастер-класс «Строим команду мечты через people-management»
- Профессиональное мировоззрение учетного специалиста (ч.1). Наука или не наука?
Найденные решения
(19)
приехал...кроме оси еще нужно и неподъемное железо :
и еще фокус :
PG-Strom requires Linux operating system for x86_64 architecture,
and its distribution supported by CUDA Toolkit.
Our recommendation is Red Hat Enterprise Linux or CentOS version 8.x series.
GPU Direct SQL Execution (w/ HeteroDB driver) needs Red Hat Enterprise Linux or CentOS version 7.3/8.0 or newer.
GPU Direct SQL Execution (w/ NVIDIA driver; experimental) needs Red Hat Enterprise Linux or CentOS version 8.3 or newer, and Mellanox OFED (OpenFabrics Enterprise Distribution) driver.
приехал...кроме оси еще нужно и неподъемное железо :
и еще фокус :
PG-Strom requires Linux operating system for x86_64 architecture,
and its distribution supported by CUDA Toolkit.
Our recommendation is Red Hat Enterprise Linux or CentOS version 8.x series.
GPU Direct SQL Execution (w/ HeteroDB driver) needs Red Hat Enterprise Linux or CentOS version 7.3/8.0 or newer.
GPU Direct SQL Execution (w/ NVIDIA driver; experimental) needs Red Hat Enterprise Linux or CentOS version 8.3 or newer, and Mellanox OFED (OpenFabrics Enterprise Distribution) driver.
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)
Компания CacheQ, основанная двумя бывшими руководителями Xilinx и группой инженеров, обещает совершить революцию в мире разработки ПО. CacheQ Compiler Collection позволит компилировать проекты так, чтобы они выполнялись намного быстрее за счёт распараллеливания процесса. А изюминка в том, что, по словам создателей, нет необходимости массового ручного переписывания кода и использования особых библиотеках или сложных API для параллелизации.
Результаты впечатляют. На процессоре x86 с 12 ядрами прирост быстродействия в работе приложения составляет почти 500 % по сравнению с однопоточным выполнением и сборкой с помощью GCC. На процессоре M1 с восемью ядрами Arm — на 400 % быстрее традиционного «однопотока».
Компания CacheQ, основанная двумя бывшими руководителями Xilinx и группой инженеров, обещает совершить революцию в мире разработки ПО. CacheQ Compiler Collection позволит компилировать проекты так, чтобы они выполнялись намного быстрее за счёт распараллеливания процесса. А изюминка в том, что, по словам создателей, нет необходимости массового ручного переписывания кода и использования особых библиотеках или сложных API для параллелизации.
Результаты впечатляют. На процессоре x86 с 12 ядрами прирост быстродействия в работе приложения составляет почти 500 % по сравнению с однопоточным выполнением и сборкой с помощью GCC. На процессоре M1 с восемью ядрами Arm — на 400 % быстрее традиционного «однопотока».
ГПУ - это множественные процессоры, которые могут параллельно обработать достаточно большое количество данных. Для них нужна задача. Например, какая-нить множественная отработка Монте-Карло для предполагаемого денежного потока (ЦБ сейчас вот просит 30к тестов для бенчмарка от своих подопечных, а у них там по 20-200кк договоров - в том же СБЕРе, например).
Но для расчета себестоимости, например, достаточно и одного потока и кода на С. Я делал пример один расчета сложного, так вот на С с кешированием исторических данных даже один поток рассчитывал результат на несколько порядков быстрее, чем в 1С (также с кешированием). Все занимало секунды времени, а не часы, как на 1С. Да та же загрузка недействительных паспортов на С у меня занимает 2 секунды на ноутбуке, после чего проверка номера происходит за О(1), т.е. это быстрее, чем в самой быстрой базе данных, ибо нет миграции потока между источником и приемником - просто берутся данные из файла и на выходе файл с проблемными элементами. На все про все доли секунды (при 3кк паспортов).
Сама по себе база данных на ГПУ - это не совсем ясная штука. Если это именно данные в памяти графического адаптера (inmemory database), то надежность всего этого под большим вопросом. Если же это просто какой-то OLAP для того, чтобы крутить его так и этак - тут такие ресурсы и не нужны особо.
В общем важен сам конкретный кейс применения. То, что это можно сделать - вопросов нет, остается главный вопрос - зачем?
Но для расчета себестоимости, например, достаточно и одного потока и кода на С. Я делал пример один расчета сложного, так вот на С с кешированием исторических данных даже один поток рассчитывал результат на несколько порядков быстрее, чем в 1С (также с кешированием). Все занимало секунды времени, а не часы, как на 1С. Да та же загрузка недействительных паспортов на С у меня занимает 2 секунды на ноутбуке, после чего проверка номера происходит за О(1), т.е. это быстрее, чем в самой быстрой базе данных, ибо нет миграции потока между источником и приемником - просто берутся данные из файла и на выходе файл с проблемными элементами. На все про все доли секунды (при 3кк паспортов).
Сама по себе база данных на ГПУ - это не совсем ясная штука. Если это именно данные в памяти графического адаптера (inmemory database), то надежность всего этого под большим вопросом. Если же это просто какой-то OLAP для того, чтобы крутить его так и этак - тут такие ресурсы и не нужны особо.
В общем важен сам конкретный кейс применения. То, что это можно сделать - вопросов нет, остается главный вопрос - зачем?
(5)
Суть всего - это параллельность. Вот есть массив данных с хитрым отбором или условием соединения: поля не индексированы, может быть даже не по полю соединение, а по выражению, а там еще хитрая группировка с хитрыми агрегатами. Все эти операции прекрасно параллелятся, т.к. они могут работать независимо друг от друга. Например, есть список с сотней тысяч строк - он грузится в графический адаптер и там бьется на тыщу фрагментов по сотне строк. В итоге каждый поток по сотне строк фильтранул, по ним собрал агрегаты, соединил может быть с другим списком свою порцию. Чем больше процессоров - тем больше порций параллельно можно обработать. Вот и все преимущество.
PG-Strom
Its core features are GPU code generator that automatically generates GPU program according to the SQL commands and asynchronous parallel execution engine to run SQL workloads on GPU device. The latest version supports SCAN (evaluation of WHERE-clause), JOIN and GROUP BY workloads. In the case when GPU-processing has advantage, PG-Strom replaces the vanilla implementation of PostgreSQL and transparentlly works fr om users and applications.
Ну как бы пишут, что это на графических процессорах с тысячами ядер может ускорить некоторые сложносочиненные запросы. Ну и объясняют, что реализуются команды SCAN - фактически WH ERE, JOIN и GROUP BY - фильтрация, соединение и группировка. Больше ничего ГПУ в PG-Storm не делает.
Суть всего - это параллельность. Вот есть массив данных с хитрым отбором или условием соединения: поля не индексированы, может быть даже не по полю соединение, а по выражению, а там еще хитрая группировка с хитрыми агрегатами. Все эти операции прекрасно параллелятся, т.к. они могут работать независимо друг от друга. Например, есть список с сотней тысяч строк - он грузится в графический адаптер и там бьется на тыщу фрагментов по сотне строк. В итоге каждый поток по сотне строк фильтранул, по ним собрал агрегаты, соединил может быть с другим списком свою порцию. Чем больше процессоров - тем больше порций параллельно можно обработать. Вот и все преимущество.
(19)
приехал...кроме оси еще нужно и неподъемное железо :
и еще фокус :
PG-Strom requires Linux operating system for x86_64 architecture,
and its distribution supported by CUDA Toolkit.
Our recommendation is Red Hat Enterprise Linux or CentOS version 8.x series.
GPU Direct SQL Execution (w/ HeteroDB driver) needs Red Hat Enterprise Linux or CentOS version 7.3/8.0 or newer.
GPU Direct SQL Execution (w/ NVIDIA driver; experimental) needs Red Hat Enterprise Linux or CentOS version 8.3 or newer, and Mellanox OFED (OpenFabrics Enterprise Distribution) driver.
приехал...кроме оси еще нужно и неподъемное железо :
и еще фокус :
PG-Strom requires Linux operating system for x86_64 architecture,
and its distribution supported by CUDA Toolkit.
Our recommendation is Red Hat Enterprise Linux or CentOS version 8.x series.
GPU Direct SQL Execution (w/ HeteroDB driver) needs Red Hat Enterprise Linux or CentOS version 7.3/8.0 or newer.
GPU Direct SQL Execution (w/ NVIDIA driver; experimental) needs Red Hat Enterprise Linux or CentOS version 8.3 or newer, and Mellanox OFED (OpenFabrics Enterprise Distribution) driver.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот