The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

В рамках проекта CUDA grep обеспечено использование GPU для ускорения регулярных выражений

02.06.2013 22:49

Представлен вариант утилиты Grep и связанной с ним реализации регулярных выражений, отличающихся задействованием CUDA для распараллеливания операций и их выноса на плечи GPU. Код утилиты и библиотеки регулярных выражений распространяется под лицензией MIT.

В зависимости от особенностей обрабатываемых данных CUDA grep демонстрирует в 2-10 раз более высокую производительность по сравнению с обычным grep. По сравнению с движком регулярных выражений Perl заявлено о достижении ускорения в 68 раз, но, судя по всему, подобный результат получен из-за ошибок (/^$line$/ вместо /^$re$/) и неверной логики организации циклов (перечитывание файла данных для каждого регулярного выражения) в тестовом файле (представленный на GitHub тестовый файл вообще неработоспособен, но возможно при тестировании использовался исправленный на уровне синтаксиса вариант, но сохранивший логические ошибки).

  1. Главная ссылка к новости (https://news.ycombinator.com/i...)
  2. OpenNews: beagrep - индексируемый вариант grep, перебирающий 2 Гб кода за 2 секунды
  3. OpenNews: Новая версия утилиты Grep 2.11
  4. OpenNews: В рамках проекта Glark развивается альтернатива Grep
  5. OpenNews: Компания Google открыла исходные тексты библиотеки регулярных выражений RE2
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/37076-grep
Ключевые слова: grep, regex, cuda, gpu
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (124) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Владимир Z (?), 23:37, 02/06/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Ага еще бы CUDA была под лицензией MIT и поддерживалась разными вендорами без отчислений или разрешений.
     
     
  • 2.7, Аноним (-), 00:22, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Пардон, те кто выбирает MIT/BSD/Apache очень любят стелиться под тех кто выбирает EULA.
     
     
  • 3.18, Куяврик (?), 01:53, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    а вот те, кто бред подобный пишут почему-то не любят лечиться
     
     
  • 4.41, Tav (ok), 15:00, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Почему бред? Выбор пермиссив лицензии часто аргументируют прагматичностью и дружественностью бизнесу.
     
     
  • 5.57, Аноним (-), 17:00, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Почему бред? Выбор пермиссив лицензии часто аргументируют прагматичностью и дружественностью бизнесу.

    Дружественность к бизнесу - недружественность к пользователям, и наоборот.
    Интересы пользователей и бизнеса конфликтуют, и разработчик имеет полное право выбрать, кому кого он помогает озалупить.

     
  • 5.96, Аноним (-), 01:03, 04/06/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > дружественностью бизнесу.

    Дружественность к блобмэйкеру означает что те кто в это вляпывался - залетают на вендорлок. Такой пермиссивный весь из себя...

     
     
  • 6.101, YetAnotherOnanym (ok), 01:15, 04/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Если автор выкатывает лицензию, которая позволяет использовать его результаты в закрытых продуктах - с чего тут возникает вендорлок?
     
     
  • 7.113, Аноним (-), 01:38, 04/06/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Если автор выкатывает лицензию, которая позволяет использовать его результаты в закрытых
    > продуктах - с чего тут возникает вендорлок?

    С проприетарного вендора, вестимо.

     
  • 4.95, Аноним (-), 01:02, 04/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > а вот те, кто бред подобный пишут почему-то не любят лечиться

    Тем не менее, факты - штука упрямая.

     

  • 1.2, metaldoctor (?), 23:39, 02/06/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Хотеть!!!
    Я хочу видяху с акселлерацией перла. Наконец-то появилась причина покупки новой видеокарты!
     
     
  • 2.3, Аноним (-), 23:45, 02/06/2013 [^] [^^] [^^^] [ответить]  
  • +25 +/
    Наконец то появится отмазка для покупки крутой видеокарты
     
     
  • 3.53, Аноним (-), 16:57, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > Наконец то появится отмазка для покупки крутой видеокарты

    А что, биткоины не катят?

     
     
  • 4.114, metaldoctor (?), 01:44, 04/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Нафиг биткоины, хочу ГРЕП!!!!! И много-много перла
     
  • 2.5, YetAnotherOnanym (ok), 00:04, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Перл там только для сравнения, и, кстати, ничего не сказано о том, какой именно скрипт выполнялся при замере производительности, включают ли полученные 0.8 секунды время на компиляцию скрипта. Как-то странно читать, что перл в 30 раз медленнее простого грепа.
    Кстати, да, ожидаем малолетних аналитеков, предрекающих скорый "перлукапец".
     
     
  • 3.19, angra (ok), 04:04, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Как-то странно читать, что перл в 30 раз медленнее простого грепа.

    Не то слово. Простейший тест
    $ time grep -c '"[0-9]\+"' some.csv
    20952

    real 0m0.764s
    user 0m0.759s
    sys 0m0.006s

    time perl -ne '$i++ if /"[0-9]+"/;END {print "$i\n"}' some.csv
    20952

    real 0m0.085s
    user 0m0.079s
    sys 0m0.006s

    Так что не в 30, а в 10 и не медленнее, а быстрее.

     
     
  • 4.26, Xaionaro (ok), 09:07, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Измерять нужно на намного б[b]о[/b]льших временах. И вывод нужно перенаправить в /dev/stdout для чистоты эксперимента.

    Попробуйте some.csv увеличить раз в 100 для начала.

     
     
  • 5.77, angra (ok), 18:36, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Это просто сделает преимущество в скорости запуска grep по сравнению с perl еще ... большой текст свёрнут, показать
     
  • 5.89, Khariton (?), 21:02, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    файл new.csv 2.5мб

    time grep -c '"[0-9]\+"' new.csv
    0

    real    0m0.764s
    user    0m0.752s
    sys     0m0.000s

    time grep -Pc '"[0-9]\+"' new.csv
    0

    real    0m0.096s
    user    0m0.092s
    sys     0m0.000s

     
  • 4.35, rain87 (?), 12:26, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • –3 +/
    не хочу тебя огорчать, но в твоём примере перл "быстрее", потому что some.csv закешировался в памяти после первого обращения к нему грепом
     
     
  • 5.55, Аноним (-), 16:58, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > не хочу тебя огорчать, но в твоём примере перл "быстрее", потому что
    > some.csv закешировался в памяти после первого обращения к нему грепом

    Можно запустить в обратном порядке - перл все равно будет быстрее. Это такое опережающее кэширование, да?

     
     
  • 6.61, rain87 (?), 17:14, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +5 +/
    вообще да, поторопился я, извиняюсь

    rain87@rain87-laptop:/tmp/csv$ time grep -c '"[0-9]\+"' cbp11co.txt
    2151507

    real 0m7.095s
    user 0m7.052s
    sys 0m0.036s
    rain87@rain87-laptop:/tmp/csv$ time perl -ne '$i++ if /"[0-9]+"/;END {print "$i\n"}' cbp11co.txt
    2151507

    real 0m1.183s
    user 0m1.152s
    sys 0m0.032s
    rain87@rain87-laptop:/tmp/csv$ ls -lh cbp11co.txt
    -rw-r--r-- 1 rain87 rain87 173M марта 11 15:12 cbp11co.txt

    перл всегда быстрее, в каком порядке ни запускай + фс в памяти, так что никакое кеширование не влияет

     
  • 2.8, pavlinux (ok), 00:23, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Я хочу видяху с акселлерацией перла.

    http://nvidia.com/

     
     
  • 3.11, Карбофос (ok), 00:50, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    а вижуал-васик поддерживает? o_O
     
     
  • 4.17, AnonuS (?), 01:27, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Пока просто васик, но проект очень быстро развивается.
     
     
  • 5.56, Аноним (-), 16:59, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Пока просто васик, но проект очень быстро развивается.

    А как насчет паскаля?

     
     
  • 6.78, anonymous (??), 19:01, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    не, сначала Lisp, наработки уже есть
     
  • 2.33, Аноним (-), 10:53, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Чернила для пятого класса, глобус Украины и видеокарту с ускорением Перла.
     
  • 2.119, Нанобот (?), 09:46, 04/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    даёшь видяху с аппаратным ускорением пэхопэ!
     

  • 1.4, amorphine (?), 23:51, 02/06/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Как перепаять слот для процессора в pci-e?
     
     
  • 2.10, Карбофос (ok), 00:46, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    это кувалдой нужно
     
     
  • 3.12, Аноним (-), 00:52, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > это кувалдой нужно

    Да ладно, у интеля есть Xeon Phi или как там его. Как вы и хотели - добавочный проц в PCI-E. Правда сдается мне что цена/производительность там явно не как у ширпотребного GPU...

     
     
  • 4.127, Аноним (-), 21:17, 05/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    от 1400 usd
     

  • 1.6, imprtat (ok), 00:18, 03/06/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Следующим на очереди будет хардварный греп?
     
     
  • 2.9, Аноним (-), 00:39, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Следующим на очереди будет хардварный греп?

    Ну а что, запилят FPGA версию и потом ASIC :)

     
     
  • 3.13, Аноним (-), 00:55, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Слудующим этапом, это когда в свойствай процессора будет mmx,mmx4,grep =)
     
     
  • 4.62, Cuernud (?), 17:20, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Слудующим этапом, это когда в свойствай процессора будет mmx,mmx4,grep =)

    Только не grep, а pcre.

     
     
  • 5.64, Michael Shigorin (ok), 17:27, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Слудующим этапом, это когда в свойствай процессора будет mmx,mmx4,grep =)
    > Только не grep, а pcre.

    Представил:

    $ grep pcre /proc/cpuinfo

    -- и круг замкнулся...

    :)

     
  • 2.45, arisu (ok), 16:09, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Следующим на очереди будет хардварный греп?

    ну, межделмаш же делала хардварный акселератор для парзинга xml. так что уже не новаторство.

     
     
  • 3.97, Аноним (-), 01:07, 04/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > ну, межделмаш же делала хардварный акселератор для парзинга xml. так что уже
    > не новаторство.

    Ну да, сначала можно усложнить себе задачу, выбрав идиoтский формат, а потом пытаться изобрести бритву для своего кактуса.

    Вон OSMщики например возлюбили бинарные форматы. Потому что 250Гбайт XML - это жосска. Это требует адово время на парсинг, жрет уйму места на винте и почему-то никак не редактируется ширпотребными редакторами :)

     
     
  • 4.116, Vkni (ok), 06:41, 04/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Вон OSMщики например возлюбили бинарные форматы. Потому что 250Гбайт XML - это
    > жосска. Это требует адово время на парсинг, жрет уйму места на
    > винте и почему-то никак не редактируется ширпотребными редакторами :)

    В бинарном формате нет ничего плохого, если к нему имеется достаточное кол-во отлаженных инструментов. В конце-концов, банальный .txt файл тоже на определенном уровне абсолютно бинарен, просто для его чтения и редактирования есть тысячи программ.

    А к systemd'шникам претензия одна - они формат сделают, а потом его изменят, наплевав на окружающих. И пойдете вы с бинарными логами Солнцем палимый прямо на ЙУХ.

     
  • 2.47, pavlinux (ok), 16:25, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Хардварный grep (с)

    cmp rax, rbx

     
  • 2.88, Andrey Mitrofanov (?), 20:28, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Следующим на очереди будет хардварный греп?

    Учёные В Гугле лет десять тому сделали _параллельный  grep, который быстрее _кеша_ любого _современного_ процессора.

    Мечтайте дальше!

     

  • 1.14, Xasd (ok), 00:56, 03/06/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    > Код утилиты и библиотеки регулярных выражений распространяется под лицензией MIT.

    что за такая мода -- делать скрипты под свободной лцензией, но при этом которые требуют несвободные инструменты (в данном случае CUDA)

     
     
  • 2.48, pavlinux (ok), 16:28, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >> Код утилиты и библиотеки регулярных выражений распространяется под лицензией MIT.
    > что за такая мода -- делать скрипты под свободной лцензией, но при
    > этом которые требуют несвободные инструменты (в данном случае CUDA)

    Скрипты - это кухня для софта! (Я)

     
     
  • 3.59, Аноним (-), 17:03, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Скрипты - это кухня для софта! (Я)

    В смысле, скрипты используются для сборки нормального ПО?

     
     
  • 4.76, pavlinux (ok), 18:35, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это в смысле берешь
    50 гр. ls
    25 гр. cat
    40 гр. grep
    100 гр. sed
    100 гр. awk
    заправляешь printf, column, sort и uniq по вкусу.
    для эстетов можно приготовить с dialog или screen
     
     
  • 5.80, Аноним (-), 19:15, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    У нас таким свинок кормят.

    А для человеческой пищи как-то больше идут функции из libc.

     
     
  • 6.94, pavlinux (ok), 00:55, 04/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > У нас таким свинок кормят.
    > А для человеческой пищи как-то больше идут функции из libc.

    Гурманы, ёптя. Вы под каждый случай перепиcываете свой софт на glibc?

     
     
  • 7.105, Аноним (-), 01:27, 04/06/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Если думать перед тем, как писать - такой проблемы не будет.
    Или думать - это тоже гурманство?
     
     
  • 8.118, еще один аноним (?), 09:30, 04/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Не ошибается только тот, кто ничего не делает Человеку свойственно ошибаться, а... текст свёрнут, показать
     
  • 8.122, pavlinux (ok), 18:40, 04/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Сколько у Вас уйдет время на приготовление, например перла и, хотя бы 1 того, ч... текст свёрнут, показать
     
  • 7.125, arisu (ok), 05:25, 05/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >> У нас таким свинок кормят.
    >> А для человеческой пищи как-то больше идут функции из libc.
    > Гурманы, ёптя. Вы под каждый случай перепиcываете свой софт на glibc?

    нет, он вообще никакой софт не пишет. потому что вантуз черепа.

     
  • 5.99, Аноним (-), 01:11, 04/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Это в смысле берешь
    > 50 гр. ls
    > 25 гр. cat
    > 40 гр. grep
    > 100 гр. sed
    > 100 гр. awk
    > заправляешь printf, column, sort и uniq по вкусу.
    > для эстетов можно приготовить с dialog или screen

    И получаешь более 300 гр какой-то буиты :)

     
  • 2.91, vle (ok), 00:19, 04/06/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    это дает тебе возможность переписать скрипты под другие
    инструменты, например, свободные. Почему нет, собственно?
     
     
  • 3.120, ананим (?), 09:57, 04/06/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    а тем временем emerge =dev-util/nvidia-cuda-toolkit-5.5.11
    "NVIDIA doesn't provide direct download links yet. If you're a"
    "registered developer, then please download ${ARCHIVE} from"
    "https://developer.nvidia.com/rdp/cuda-55-release-candidate-installers"
     
     
  • 4.123, pavlinux (ok), 18:50, 04/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > а тем временем emerge =dev-util/nvidia-cuda-toolkit-5.5.11
    >  "NVIDIA doesn't provide direct download links yet. If you're a"
    >  "registered developer, then please download ${ARCHIVE} from"
    >  "https://developer.nvidia.com/rdp/cuda-55-release-candidate-installers"

    http://developer.download.nvidia.com/assets/cuda/secure/CUDA55/RC/cuda-5.5.11

     

  • 1.15, Аноним (-), 01:03, 03/06/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    PCRE ./configure ... --with-jit

    http://sljit.sourceforge.net/pcre.html

     
     
  • 2.16, Аноним (-), 01:05, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    http://nginx.org/ru/docs/ngx_core_module.html#pcre_jit
     

  • 1.20, inferrna (ok), 05:51, 03/06/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Пока что это дорого и бессмысленно. Гонять данные в память видеокарты и обратно только для того, чтобы сравнить одно целое с другим целым, это есть немного смешно. С другой стороны, выбор CUDA как бы намекает, что жирафы в плане вычислений ни на что другое не годятся.
     
  • 1.22, Evgueni (?), 07:18, 03/06/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Наконец-то что-то полезное для повседневной жизни стали производить. Жаль, что не OpenCL. Главное, чтобы не нашлось редиски, которая занялась бы патентованием подобных алгоритмов.
     
  • 1.23, AlexAT (ok), 07:21, 03/06/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Перенос таких вещей на матричные процессоры имеет только один смысл: когда надо одновременно посчитать сотни и тысячи таких грепов по разным блокам данных. В остальных случаях - баловство и мазохизм. Судя по "бенчам" - именно этим и занимаются.
     
     
  • 2.34, Аноним (-), 10:56, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Ну, в общем, СУБД заняты примерно подсчетом сотен и тысяч грепов как раз.
     
     
  • 3.36, AlexAT (ok), 12:41, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Ну, в общем, СУБД заняты примерно подсчетом сотен и тысяч грепов как
    > раз.

    СУБД заняты не грепом, а поиском в индексах. В основном. Это на видео передать можно, но эффект вряд ли будет большим, с учетом разнородности запросов. Хотя - СУБД СУБД рознь.

     
  • 3.50, Аноним (-), 16:52, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Ну, в общем, СУБД заняты примерно подсчетом сотен и тысяч грепов как раз.

    Если СУБД занимается грепами - бить надо архитектора базы, жестоко и беспощадно.
    grep/regexp - это костыль, заменяющий SQL в тех ситуациях, когда информация не структурирована (т.е. представлена не в виде таблиц с типизированными полями, а в виде текстовой каши). Как и положено костылю, он практически во всех отношениях проигрывает нормальному решению - и по скорости, и по надежности, и по гибкости, и по прозрачности. Но иногда выбора просто нет.

     
  • 2.92, vle (ok), 00:40, 04/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Перенос таких вещей на матричные процессоры имеет только один смысл: когда надо
    > одновременно посчитать сотни и тысячи таких грепов по разным блокам данных.
    > В остальных случаях - баловство и мазохизм.

    Нет. В случае использования NFA для регулярного выражения,
    распараллеливание может иметь смысл, особенно если
    автомат вмещается во внутриблочную память, она маленькая,
    но быстрая.

     
     
  • 3.117, AlexAT (ok), 07:17, 04/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Нет. В случае использования NFA для регулярного выражения,
    > распараллеливание может иметь смысл, особенно если
    > автомат вмещается во внутриблочную память, она маленькая,
    > но быстрая.

    Повторюсь - баловство и мазохизм. Вариантов применения также вижу только один: считать простенький греп по десятку гигов данных. Но за это можно руки отрывать сразу, за кривую организацию системы.

    Может пригодиться в массовом параллельном обсчете грепов, например, для реалтаймовой фильтрации контента (DPI) - но это относится к моему посту выше - когда надо посчитать параллельно тысячу грепов :)

     
     
  • 4.121, vle (ok), 13:02, 04/06/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> Нет. В случае использования NFA для регулярного выражения,
    >> распараллеливание может иметь смысл, особенно если
    >> автомат вмещается во внутриблочную память, она маленькая,
    >> но быстрая.
    > Повторюсь - баловство и мазохизм. Вариантов применения также вижу только один: считать
    > простенький греп по десятку гигов данных.
    > Но за это можно руки
    > отрывать сразу, за кривую организацию системы.

    Не надо этого фанатизма. Вполне типичная задача
    для тех, кто занимается обработкой текста. С помощью банального
    grep-like поиска можно найти то, что потом обрабатывается более детально.
    Спроси у Яндекса, зачем они писали свой PIRE, у них другой пример.

     
     
  • 5.124, AlexAT (ok), 21:45, 04/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Спроси у Яндекса, зачем они писали свой PIRE, у них другой пример.

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

     

  • 1.24, Vkni (ok), 08:35, 03/06/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Объясните пожалуйста, как можно сравнивать скорость "cuda-grepa" и "обычного grepa", когда они выполняются на разных устройствах - CPU и GPU? Обычно ведь две сравниваемые программы выполняются на одном и том же устройстве.

    Тут, казалось бы, какую пару CPU/GPU возьмешь, так и будет.

     
     
  • 2.27, Sergey722 (ok), 09:34, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >как можно сравнивать скорость "cuda-grepa" и "обычного grepa"

    Запускаешь "cuda-grep", засекаешь время.
    Запускаешь "обычный grep", засекаешь время.
    Сравниваешь.
    >когда они выполняются на разных устройствах

    Вы правы, это осложняет сравнение, но не означает, что оно вовсе не возможно.
    И может быть любым, начиная от "круто, мои терабайтные логи парсятся всего за полгода!" и заканчивая какими-то более менее объективными показателями типа "цена устройства/компа"*"время работы".

     
     
  • 3.28, Vkni (ok), 09:37, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Запускаешь "cuda-grep", засекаешь время. Запускаешь "обычный grep", засекаешь время. Сравниваешь.

    А смысл такого сравнения? У кого-то ведь топовая NVidia, а у кого-то - 5-ти летней давности. В то же время, процессоры примерно одинаковы.

     
     
  • 4.46, arisu (ok), 16:11, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > В то же время, процессоры примерно одинаковы.

    у меня — пятилетней давности, например.

     
     
  • 5.71, Vkni (ok), 17:56, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    У меня тоже - T9500, его индекс производительности (Windows) - 6.2. В общем, не жалуюсь. :-)

    И я не думаю, что grep на нем гоняется сильно медленнее, чем на мобильном i3.

     
     
  • 6.100, Аноним (-), 01:14, 04/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Ну как бы греп бывает нужен и для того чтобы спарсить 20 Гб логов. Правда, по нормальному такой лог лучше писать в индексированную базу, но...
     
     
  • 7.115, Vkni (ok), 06:37, 04/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну как бы греп бывает нужен и для того чтобы спарсить 20
    > Гб логов. Правда, по нормальному такой лог лучше писать в индексированную
    > базу, но...

    Если у вас столько логов, то либо вы некоторое время ждете на машинке типа моей, либо у вас десктоп (это примерно 4 раза производительности по сравнению с моей машинкой). А переход с одного мобильного ЦП на другой мобильный столько не даст.


     
  • 2.66, Аноним (-), 17:32, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    забавляют подобные "анализы": для рекламы выбирают подходящий тест и проводят его на разных устройствах, которые или несравнимы ни по стоимости, ни по теоретической мощи
     
     
  • 3.112, Аноним (-), 01:36, 04/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > забавляют подобные "анализы": для рекламы выбирают подходящий тест и проводят его на
    > разных устройствах, которые или несравнимы ни по стоимости, ни по теоретической
    > мощи

    А потом публикуют его на форониксе.

     

  • 1.25, Аноним (-), 09:04, 03/06/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Скоро так всё СПО переедет в видеокарту.
    Будет работать там и показывать фигу микромягким.
    :)
     
     
  • 2.30, Аноним (-), 10:07, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Да вы упоролись. Видеокарты НЕ предназначены для задач общего назначения (посмотрел бы, как бы вы писали в файл непосредственно с GPU). Поэтому на всём, что не может сильно параллелиться (тысячи потоков хотя бы) и не является вычислениями, они сливают процессорам по полной.
     
     
  • 3.31, 80е (?), 10:11, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > Да вы упоролись. Видеокарты НЕ предназначены для задач общего назначения (посмотрел бы,
    > как бы вы писали в файл непосредственно с GPU). Поэтому на
    > всём, что не может сильно параллелиться (тысячи потоков хотя бы) и
    > не является вычислениями, они сливают процессорам по полной.

    TESLA предназначена.

     
     
  • 4.51, Аноним (-), 16:54, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >> Да вы упоролись. Видеокарты НЕ предназначены для задач общего назначения
    > TESLA предназначена.

    Нет.

     
  • 4.67, Аноним (-), 17:33, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > TESLA предназначена.

    о! ещё один альтернативно-мыслящий отметился

     
  • 4.102, Аноним (-), 01:17, 04/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > TESLA предназначена.

    Ага, ЩАЗ. У видеркарт очень слабое управление flow control. Поэтому они хороши только для того что массово и более-менее линейно молотит впараллель большой поток данных. Ну то-есть похоже на обработку сцены в графическом пайплайне, для чего оно изначально создавалось. Это наследие вполне заметно до сих пор. Оно молотит большие объемы данных, но быстрый разворот в другую сторону там не предусмотрен. Так что как general purpose или управляющий процессор - видеокарта вообще ни о чем. Вот как скоростной акселератор дополняющий системный проц - это да.


    Хотя интель вон сделал Xeon Phi, но это как бы и не видеокарта особо, а просто относительно параллелящийся акселератор, достаточно самодостаточный для того чтобы забутявить на себе отдельную копию пингвина.

     
  • 3.32, Аноним (-), 10:12, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Упоролись не мы, а те упыри, которые любят придавать оборудованию несвойственные ему функции. :)
     
  • 3.73, www2 (??), 18:28, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Да ладно, процессоры общего назначения тоже не предназначены много для чего, но в них всё равно напихали всяких mmx, 3dnow, sse, sse2, sse3, sse4 и т.п. Потом героически сражаются с тем, как эти макроинструкции странслировать в микрокод, который будет обрабатывать RISC-ядро, по возможности задействуя все свои компоненты, могущие работать параллельно.

    Много однотипных и повторяющихся операций, даже если каждая из них на графической карте выполняется менее эффективно, чем на процессоре общего назначения, всё равно могут выигрывать просто за счёт количества параллельно обрабатываемых данных.

    Обработка звука со всякими фильтрами и преобразованиями Фурье, какой-нибудь табличный процессор, греп по тексту, перебор паролей в поисках подходящего хэша, что-нибудь-ещё-придумайте-сами...

     
     
  • 4.103, Аноним (-), 01:26, 04/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Уточним, там скорее группа RISC-подобных выполняющих элементов, так что это чем-... большой текст свёрнут, показать
     

  • 1.37, Kodir (ok), 12:53, 03/06/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Допустим в каких-то задачах multi-core-grep и имеет смысл, но на типичной машине админа локалхоста стоит один-два харда, скорость работы с которыми достаточна для однопоточного grep'а. Если распараллеливать греп, то и данные тоже нужно подавать на оба! И вот тут встаёт вопрос о диске - понравится ли ему прыгать головками туды-сюды?
     
  • 1.38, Аноним (-), 13:26, 03/06/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Для таких вещей я бы использовал Сопроцессор от Intel под названием Xeon Phi (Knights Corner)

    http://www.intel.com/content/www/us/en/processors/xeon/xeon-phi-architecture-

     
     
  • 2.104, Аноним (-), 01:27, 04/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Для таких вещей я бы использовал Сопроцессор от Intel

    Сдается мне, что видеокарты элементарно дешевле.

     

  • 1.39, Аноним (-), 14:03, 03/06/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Вообще по дурацки все ето смотрится,
    аппаратные ускорители отнюдь не новинка.

    Для универсальности нужно просто на материнки добавить fpga, а в ось софт для взаимодействия заливки прошивки итд...
    Надо будет работать архиватором надо кодеком ну или grep
    постепенно наберется архив прошивок и в софте появится поддержка...

     
     
  • 2.106, Аноним (-), 01:28, 04/06/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Для универсальности нужно просто на материнки добавить fpga, а в ось софт
    > для взаимодействия заливки прошивки итд...

    Ну вот GPU чем-то таким и оказались - параллельная числокрушилка с возможностью вливать в нее код.

     

  • 1.42, Led (ok), 15:02, 03/06/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    Всё логично: CPU, FPU, а теперь ещё и GPU (grep processor unit). Ждём SPU (для sed) и другие xPU.
     
     
  • 2.49, Аноним (-), 16:47, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Чем только люди не страдают, лишь бы нормально архитектуру не продумывать.
     
     
  • 3.54, Аноним (-), 16:58, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    бред, регулярки ресурсоемкие
     
     
  • 4.58, Аноним (-), 17:01, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > бред, регулярки ресурсоемкие

    При правильной архитектуре регулярки не нужны. Максимум strcmp.

     
     
  • 5.69, Аноним (-), 17:42, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >> бред, регулярки ресурсоемкие
    > При правильной архитектуре регулярки не нужны. Максимум strcmp.

    ты про if ?

     
     
  • 6.70, Аноним (-), 17:49, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Про реализацию логики работы с данными вообще.
     
     
  • 7.79, Аноним (-), 19:14, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Вот вот, но тут этого не понимают, тут любят гнобить systemd за бинарные логи.
     
     
  • 8.81, Аноним (-), 19:19, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Да что systemd Даже обычные текстовые логи бинарной файловой системе, и без дра... текст свёрнут, показать
     
     
  • 9.82, Аноним (-), 19:22, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Разумеется, драйвер такой ФС должен быть написан на bash, с использованием grep,... текст свёрнут, показать
     
     
  • 10.84, AlexAT (ok), 19:45, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Поздно, дотнет уже изобрели ... текст свёрнут, показать
     
     
  • 11.85, Аноним (-), 20:09, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Но юниксвейную ФС пока не создали Так что еще не поздно ... текст свёрнут, показать
     
     
  • 12.98, Led (ok), 01:11, 04/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    man fuse... текст свёрнут, показать
     
     
  • 13.109, Аноним (-), 01:31, 04/06/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    В юзерспейсе - не спортивно Надо, чтобы в ядре И само ядро на bash, разумеется... текст свёрнут, показать
     
  • 10.86, Пингвино (ok), 20:12, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Админы будут ссать кипятком от счастья ... текст свёрнут, показать
     
     
  • 11.87, Аноним (-), 20:22, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А виндyзятники и прочие поттерингофилы - корчиться в муках ... текст свёрнут, показать
     
  • 8.83, Аноним (-), 19:45, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Тогда надо и все основные СУБД запретить, за злостное надругательство над unix-w... текст свёрнут, показать
     
  • 4.126, arisu (ok), 05:27, 05/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > бред, регулярки ресурсоемкие

    а не надо бэктрекерные использовать.

     

  • 1.43, Аноним (-), 15:55, 03/06/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    О, так скоро и скриптовые языки ускорят :)
     
     
  • 2.44, Аноним (-), 15:57, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А вообще, пока на открытых драйверах работать не будет - вывод очевиден "Не нужно"
     
  • 2.52, Аноним (-), 16:57, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > О, так скоро и скриптовые языки ускорят :)

    На редкость бессмысленное занятие. Для скриптовых языков скорость не играет никакой роли.

     
  • 2.107, Аноним (-), 01:29, 04/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > О, так скоро и скриптовые языки ускорят :)

    Не, конечно можно сначала создать себе проблемы а потом героически с ними воевать. Но это называется донкихотством...

     
     
  • 3.111, Аноним (-), 01:34, 04/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Не, конечно можно сначала создать себе проблемы а потом героически с ними
    > воевать. Но это называется донкихотством...

    Это называется unix way.

     

  • 1.60, Аноним (-), 17:12, 03/06/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Крайне показательный пример того факта, что узкозаточенные технологии, типа обработки на GPU сложно хоть как-то задействовать за пределами их основной области применения.

    Развитие IT уперлось в тупик кремниевой технологии. Для дальнейшего развития нужно либо менять технологию производства электроники, либо саму концепцию программирования.

     
     
  • 2.68, Michael Shigorin (ok), 17:34, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Развитие IT уперлось в тупик кремниевой технологии. Для дальнейшего развития нужно либо
    > менять технологию производства электроники, либо саму концепцию программирования.

    http://ftp.linux.kiev.ua/pub/conference/peers/pereslavl/2013/video/algebraic-
    http://ftp.linux.kiev.ua/pub/conference/peers/pereslavl/2013/pereslavl-winter (с. 12--14)

     
     
  • 3.90, nagual (ok), 23:26, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> Развитие IT уперлось в тупик кремниевой технологии. Для дальнейшего развития нужно либо
    >> менять технологию производства электроники, либо саму концепцию программирования.
    > http://ftp.linux.kiev.ua/pub/conference/peers/pereslavl/2013/video/algebraic-
    > http://ftp.linux.kiev.ua/pub/conference/peers/pereslavl/2013/pereslavl-winter
    > (с. 12--14)

    Чудо которое они рекламируют в свободно доступе есть или можно переносить в раздел "спам" ?

     
  • 3.93, vle (ok), 00:48, 04/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > http://ftp.linux.kiev.ua/pub/conference/peers/pereslavl/2013/pereslavl-winter с. 12--14)

    бла-бла-бла

     

  • 1.63, Аноним (-), 17:21, 03/06/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    странно что не в 10 раз медленнее
     
     
  • 2.75, Аноним (-), 18:32, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > странно что не в 10 раз медленнее

    задержка по идее должна расти, верю если много регулярок слать то быстрее
    но не атомарно быстрее
    Latency PCI

     

  • 1.65, Клим (?), 17:28, 03/06/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    теперь греп без иксов работать не будет?
     
     
  • 2.72, Vkni (ok), 17:58, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > теперь греп без иксов работать не будет?

    Без Wayland и systemd!!!

     
     
  • 3.74, Аноним (-), 18:29, 03/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Ничего страшного, Марк защитит свободу пользователей, и выпустит версию grep, привязанную к истинно свободным Unity, Mir и Upstart, а не к насильственно пропихнутым редхатоподелкам!
     
     
  • 4.108, Аноним (-), 01:31, 04/06/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Довольно тонко :)
     
     
  • 5.110, Аноним (-), 01:32, 04/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Довольно тонко :)

    Космонавт всегда был тонким ценителем свободы.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру