0 1 2 3 4 5 6 7 8 ...11 12 13 14 15 ...23 24 25 26 27 ...32 33 34 35 36
На една от теслите на работа (V100) 32K стринга се сравняват за 2300 секунди, или нещо като 0.07 секунди на стринг. Трябва да си поиграя малко повече, струва ми се бавно...
Това е със сравнение на всеки стринг от колекция А с всеки стринг от колекция Б. Все още не съм подкарал дъ трай на GPU...
Много зависи колко са дълги тея стрингове. Ако са къси и могат да се набухат в локалната памет (у кудата това му викаха "споделена" памет май) или дори ако могат да се нашият в регистри, ще хвърчи и кърти. Обаче ако не става и са у глобалната като нищо накрая ще се окаже че CPU-то ги прави по-добре тея работи. Голема педерастия е достъпа до паметта у видеокартите, аз за global като чуя се изприщвам деба, ако патърна на достъп до паметта е подмолна работа при CPU-тата, при GPU-тата е поне с няколко порядъка по-подмолна работа.
Да, нещата май са доста по-дивашки отколкото си мислех. Досега тествах с всичко в глобалната памет. Функцията за ЛевенщЕйн разстояние й трябва буфер и той вероятно е в локалната памет (статичен масив деклариран в глобалната функция).
Сега ще пробвам да пусна всички тредове в локстеп (със syncthreads), да местя всеки от стринговете от колекция А в споделената памет, да пускам тредовете да сравняват с него всеки неговия си стринг от колекция Б, syncthreads, rinse, repeat...
Е аз не знам, GPU kernel не съм писал от сигурно две години че и повече, те нещата там бързо се променят. Абе у кудата може ли като викаш кернел функцията, да й зададеш първоначално състояние на локалната памет? По същият начин по който и даваш аргументи или както примерно копираш памет от хоста в глобалната? Това в опенцл-а го нямаше и супер много ме дразнеше че не може да става.
Мисля, че го няма, но аз не съм писал КУДА от повече от 10 години и всичко или се е променило или съм забравил. :)
Явно си е некакво хардуерно ограничение сигурно, жалко.
Аз не съм спец за точно такъв проблем, но ми се струва че може да се опита с NoSQL,
примерно
https://blog.couchbase.com/fuzzy-matching/
ili
https://www.mongodb.com/blog/post/how-to-perform-fuzzy-matching-with-mongo-connector
Не, Андроид и iOS, бакенд C# и MSSQL, жаба скрипт за някои фронт-енд и цялата архитектура на фирмата минава през мен.
Сравнително малка фирмичка за северно-американските мащаби, но засега плащат горе долу добре.
За NoSQL само съм чел.
200 хиляди стринга за 1905 секунди, което е под 0.01 секунди за стринг. Getting there...
Това са си 10мс или 10000мкс. Една препоръка от мене - мери времето в "мс" или даже "мкс". Веднага осъзнаваш колко ти са бавни програмите.
На прав път ли съм ?
Не. Трябва на всеки Б-стринг да изчисляваш дистанцията до всеки стринг от А и да намираш минималната дистанция.
Мда, ще трябва да се пишат някакви по-засукани SQL кодове..
Хехехе, това е изказването на деня. Не е ли по-добре да меря в пикосекунди? :)
Ако меря в години няма ли да осъзная колко са ми бавни програмите? :)
Съвременните процесори имат машинен цикъл от порядъка на 250..300пс. Така че, не, няма смисъл. За програмите, които ти можеш да напишеш микросекундите са добре. Даже и леко излишни – но все пак ще смятаме, че постепенно ще се научиш да пишеш и по-бързи програми.
Абе, смешник, пак ли се опитваш да ме учиш как да програмирам? :) Вчера ме учи на английски, днес на програмиране, а? :)
Хайде да ти ги видим твоите програми колко са бързи. Нещо се покри, а? :)
Ъ? В смисъл, покрих? Някъде да съм казал, че ще ти пиша програмата? Смятам, че достатъчно често съм доказвал, че пиша бързи програми. Точно сега нямам време за още един уъркшоп.
А виж, ти си който пише програми дето се изпълняват по една седмица на топ машина. За което е и тази тема.
Мислех си, че си тук за съвет как да си усъвършенстваш програмистките скилове. Затова се опитвам да помогна. Ако една седмица те устройва – ОК, айм файн ...
Виж сега, ти може да можеш да си пишеш разни смешни играчки които се изпълняват за милисекунди, но реалните програми работят седмици. Знам, ти като изключителен програмист, никога не си виждал такава, и кой знае защо не програмираш професионално. :)
Съветът, който видях от теб е "използвай sqlite", който е толкова невероятно смешен, че дори и Рабин не посмя да каже нещо подобно.
Та, по-леко с жалката си арогантност, особено когато НЕ МОЖЕШ да я подкрепиш с ФАКТИ. :)
Ако това върши работа, рънва на средния ми лаптоп за 26 минути на postgreSQL 13 за 100К срещу 100 стринга без индекси, докато си слушам музичка и си браузвам. Някой спец да избаца по-оптимален вариант да го тествам.
SELECT "Bstring", MIN("dist") FROM
(
SELECT n1."Bstring",n2."Astring", levenshtein_less_equal(n1."Bstring",n2."Astring",100) as dist
FROM (SELECT "Bstring" FROM public."Leven") n1 ,
public."Leven" n2
) n3 GROUP BY "Bstring"
0 1 2 3 4 5 6 7 8 ...11 12 13 14 15 ...23 24 25 26 27 ...32 33 34 35 36