|
Създадено на 25.09.2020, видяно: 1758 пъти. #12527
На една от теслите на работа (V100) 32K стринга се сравняват за 2300 секунди, или нещо като 0.07 секунди на стринг. Трябва да си поиграя малко повече, струва ми се бавно...
Това е със сравнение на всеки стринг от колекция А с всеки стринг от колекция Б. Все още не съм подкарал дъ трай на GPU...
gat3way
Създадено на 25.09.2020, видяно: 1746 пъти. #12544
Много зависи колко са дълги тея стрингове. Ако са къси и могат да се набухат в локалната памет (у кудата това му викаха "споделена" памет май) или дори ако могат да се нашият в регистри, ще хвърчи и кърти. Обаче ако не става и са у глобалната като нищо накрая ще се окаже че CPU-то ги прави по-добре тея работи. Голема педерастия е достъпа до паметта у видеокартите, аз за global като чуя се изприщвам деба, ако патърна на достъп до паметта е подмолна работа при CPU-тата, при GPU-тата е поне с няколко порядъка по-подмолна работа.
|
Създадено на 25.09.2020, видяно: 1739 пъти. #12545
Да, нещата май са доста по-дивашки отколкото си мислех. Досега тествах с всичко в глобалната памет. Функцията за ЛевенщЕйн разстояние й трябва буфер и той вероятно е в локалната памет (статичен масив деклариран в глобалната функция).
Сега ще пробвам да пусна всички тредове в локстеп (със syncthreads), да местя всеки от стринговете от колекция А в споделената памет, да пускам тредовете да сравняват с него всеки неговия си стринг от колекция Б, syncthreads, rinse, repeat...
gat3way
Създадено на 25.09.2020, видяно: 1734 пъти. #12546
Е аз не знам, GPU kernel не съм писал от сигурно две години че и повече, те нещата там бързо се променят. Абе у кудата може ли като викаш кернел функцията, да й зададеш първоначално състояние на локалната памет? По същият начин по който и даваш аргументи или както примерно копираш памет от хоста в глобалната? Това в опенцл-а го нямаше и супер много ме дразнеше че не може да става.
|
Създадено на 25.09.2020, видяно: 1731 пъти. #12547
Мисля, че го няма, но аз не съм писал КУДА от повече от 10 години и всичко или се е променило или съм забравил. :)
gat3way
Създадено на 25.09.2020, видяно: 1730 пъти. #12548
Явно си е некакво хардуерно ограничение сигурно, жалко.
ДъртиХари
Създадено на 25.09.2020, видяно: 1729 пъти. #12549
Аз не съм спец за точно такъв проблем, но ми се струва че може да се опита с NoSQL,
Не. Трябва на всеки Б-стринг да изчисляваш дистанцията до всеки стринг от А и да намираш минималната дистанция.
Delegate
Създадено на 26.09.2020, видяно: 1662 пъти. #12562
Мда, ще трябва да се пишат някакви по-засукани SQL кодове..
|
Създадено на 26.09.2020, видяно: 1643 пъти. #12591
200 хиляди стринга за 1905 секунди, което е под 0.01 секунди за стринг. Getting there...
Това са си 10мс или 10000мкс. Една препоръка от мене - мери времето в "мс" или даже "мкс". Веднага осъзнаваш колко ти са бавни програмите.
Хехехе, това е изказването на деня. Не е ли по-добре да меря в пикосекунди? :)
Ако меря в години няма ли да осъзная колко са ми бавни програмите? :)
johnfound
Създадено на 26.09.2020, видяно: 1640 пъти. #12597
Хехехе, това е изказването на деня. Не е ли по-добре да меря в пикосекунди? :)
Съвременните процесори имат машинен цикъл от порядъка на 250..300пс. Така че, не, няма смисъл. За програмите, които ти можеш да напишеш микросекундите са добре. Даже и леко излишни – но все пак ще смятаме, че постепенно ще се научиш да пишеш и по-бързи програми.
|
Последно редактирано на 26.09.2020 от |, видяно: 1638 пъти. #12598
Хехехе, това е изказването на деня. Не е ли по-добре да меря в пикосекунди? :)
Съвременните процесори имат машинен цикъл от порядъка на 250..300пс. Така че, не, няма смисъл. За програмите, които ти можеш да напишеш микросекундите са добре. Даже и леко излишни – но все пак ще смятаме, че постепенно ще се научиш да пишеш и по-бързи програми.
Абе, смешник, пак ли се опитваш да ме учиш как да програмирам? :) Вчера ме учи на английски, днес на програмиране, а? :)
Хайде да ти ги видим твоите програми колко са бързи. Нещо се покри, а? :)
johnfound
Създадено на 26.09.2020, видяно: 1627 пъти. #12605
Хайде да ти ги видим твоите програми колко са бързи. Нещо се покри, а? :)
Ъ? В смисъл, покрих? Някъде да съм казал, че ще ти пиша програмата? Смятам, че достатъчно често съм доказвал, че пиша бързи програми. Точно сега нямам време за още един уъркшоп.
А виж, ти си който пише програми дето се изпълняват по една седмица на топ машина. За което е и тази тема.
Мислех си, че си тук за съвет как да си усъвършенстваш програмистките скилове. Затова се опитвам да помогна. Ако една седмица те устройва – ОК, айм файн ...
|
Последно редактирано на 26.09.2020 от |, видяно: 1621 пъти. #12606
Хайде да ти ги видим твоите програми колко са бързи. Нещо се покри, а? :)
Ъ? В смисъл, покрих? Някъде да съм казал, че ще ти пиша програмата? Смятам, че достатъчно често съм доказвал, че пиша бързи програми. Точно сега нямам време за още един уъркшоп.
А виж, ти си който пише програми дето се изпълняват по една седмица на топ машина. За което е и тази тема.
Мислех си, че си тук за съвет как да си усъвършенстваш програмистките скилове. Затова се опитвам да помогна. Ако една седмица те устройва – ОК, айм файн ...
Виж сега, ти може да можеш да си пишеш разни смешни играчки които се изпълняват за милисекунди, но реалните програми работят седмици. Знам, ти като изключителен програмист, никога не си виждал такава, и кой знае защо не програмираш професионално. :)
Съветът, който видях от теб е "използвай sqlite", който е толкова невероятно смешен, че дори и Рабин не посмя да каже нещо подобно.
Та, по-леко с жалката си арогантност, особено когато НЕ МОЖЕШ да я подкрепиш с ФАКТИ. :)
Delegate
Създадено на 26.09.2020, видяно: 1609 пъти. #12612
На прав път ли съм ?
Не. Трябва на всеки Б-стринг да изчисляваш дистанцията до всеки стринг от А и да намираш минималната дистанция.
Ако това върши работа, рънва на средния ми лаптоп за 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"
Successfully run. Total query runtime: 26 min 7 secs.
101 rows affected.