<bgdev />free

Вход Регистрация

Задача НЕ за интервю
7

0 1 2 3 4 5 6 7 8 ....11 12 13 14 15 ....23 24 25 26 27 ....32 33 34 35 36
#12527 (ツ) |
Създадено на 25.09.2020, видяно: 1474 пъти.

На една от теслите на работа (V100) 32K стринга се сравняват за 2300 секунди, или нещо като 0.07 секунди на стринг. Трябва да си поиграя малко повече, струва ми се бавно...

Това е със сравнение на всеки стринг от колекция А с всеки стринг от колекция Б. Все още не съм подкарал дъ трай на GPU...

#12544 (ツ) gat3way
Създадено на 25.09.2020, видяно: 1462 пъти.

Много зависи колко са дълги тея стрингове. Ако са къси и могат да се набухат в локалната памет (у кудата това му викаха "споделена" памет май) или дори ако могат да се нашият в регистри, ще хвърчи и кърти. Обаче ако не става и са у глобалната като нищо накрая ще се окаже че CPU-то ги прави по-добре тея работи. Голема педерастия е достъпа до паметта у видеокартите, аз за global като чуя се изприщвам деба, ако патърна на достъп до паметта е подмолна работа при CPU-тата, при GPU-тата е поне с няколко порядъка по-подмолна работа.

#12545 (ツ) |
Създадено на 25.09.2020, видяно: 1455 пъти.
gat3way

Много зависи колко са дълги тея стрингове. Ако са къси и могат да се набухат в локалната памет (у кудата това му викаха "споделена" памет май) или дори ако могат да се нашият в регистри, ще хвърчи и кърти. Обаче ако не става и са у глобалната като нищо накрая ще се окаже че CPU-то ги прави по-добре тея работи. Голема педерастия е достъпа до паметта у видеокартите, аз за global като чуя се изприщвам деба, ако патърна на достъп до паметта е подмолна работа при CPU-тата, при GPU-тата е поне с няколко порядъка по-подмолна работа.

Да, нещата май са доста по-дивашки отколкото си мислех. Досега тествах с всичко в глобалната памет. Функцията за ЛевенщЕйн разстояние й трябва буфер и той вероятно е в локалната памет (статичен масив деклариран в глобалната функция).

Сега ще пробвам да пусна всички тредове в локстеп (със syncthreads), да местя всеки от стринговете от колекция А в споделената памет, да пускам тредовете да сравняват с него всеки неговия си стринг от колекция Б, syncthreads, rinse, repeat...

#12546 (ツ) gat3way
Създадено на 25.09.2020, видяно: 1450 пъти.

Е аз не знам, GPU kernel не съм писал от сигурно две години че и повече, те нещата там бързо се променят. Абе у кудата може ли като викаш кернел функцията, да й зададеш първоначално състояние на локалната памет? По същият начин по който и даваш аргументи или както примерно копираш памет от хоста в глобалната? Това в опенцл-а го нямаше и супер много ме дразнеше че не може да става.

#12547 (ツ) |
Създадено на 25.09.2020, видяно: 1447 пъти.
gat3way

Е аз не знам, GPU kernel не съм писал от сигурно две години че и повече, те нещата там бързо се променят. Абе у кудата може ли като викаш кернел функцията, да й зададеш първоначално състояние на локалната памет? По същият начин по който и даваш аргументи или както примерно копираш памет от хоста в глобалната? Това в опенцл-а го нямаше и супер много ме дразнеше че не може да става.

Мисля, че го няма, но аз не съм писал КУДА от повече от 10 години и всичко или се е променило или съм забравил. :)

#12548 (ツ) gat3way
Създадено на 25.09.2020, видяно: 1446 пъти.

Явно си е некакво хардуерно ограничение сигурно, жалко.

#12549 (ツ) Дърти Хари
Създадено на 25.09.2020, видяно: 1445 пъти.

Аз не съм спец за точно такъв проблем, но ми се струва че може да се опита с NoSQL,

примерно

https://blog.couchbase.com/fuzzy-matching/

ili

https://www.mongodb.com/blog/post/how-to-perform-fuzzy-matching-with-mongo-connector

#12552 (ツ) Унуфри
Създадено на 25.09.2020, видяно: 1431 пъти.
Дърти Хари

Аз не съм спец за точно такъв проблем, но ми се струва че може да се опита с NoSQL,

примерно

https://blog.couchbase.com/fuzzy-matching/

ili

https://www.mongodb.com/blog/post/how-to-perform-fuzzy-matching-with-mongo-connector

С монго ли се занимаваш?

#12554 (ツ) Дърти Хари
Създадено на 26.09.2020, видяно: 1425 пъти.
Унуфри
Дърти Хари

Аз не съм спец за точно такъв проблем, но ми се струва че може да се опита с 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 само съм чел.

#12555 (ツ) |
Последно редактирано на 26.09.2020 от |, видяно: 1417 пъти.

200 хиляди стринга за 1905 секунди, което е под 0.01 секунди за стринг. Getting there...

#12559 (ツ) johnfound
Създадено на 26.09.2020, видяно: 1396 пъти.
|

200 хиляди стринга за 1905 секунди, което е под 0.01 секунди за стринг. Getting there...

Това са си 10мс или 10000мкс. Една препоръка от мене - мери времето в "мс" или даже "мкс". Веднага осъзнаваш колко ти са бавни програмите.

#12560 (ツ) Delegate
Последно редактирано на 26.09.2020 от Delegate, видяно: 1389 пъти.

На прав път ли съм ?

#12561 (ツ) johnfound
Последно редактирано на 26.09.2020 от johnfound, видяно: 1385 пъти.
Delegate

На прав път ли съм ?

Не. Трябва на всеки Б-стринг да изчисляваш дистанцията до всеки стринг от А и да намираш минималната дистанция.

#12562 (ツ) Delegate
Създадено на 26.09.2020, видяно: 1378 пъти.

Мда, ще трябва да се пишат някакви по-засукани SQL кодове..

#12591 (ツ) |
Създадено на 26.09.2020, видяно: 1359 пъти.
johnfound
|

200 хиляди стринга за 1905 секунди, което е под 0.01 секунди за стринг. Getting there...

Това са си 10мс или 10000мкс. Една препоръка от мене - мери времето в "мс" или даже "мкс". Веднага осъзнаваш колко ти са бавни програмите.

Хехехе, това е изказването на деня. Не е ли по-добре да меря в пикосекунди? :)

Ако меря в години няма ли да осъзная колко са ми бавни програмите? :)

#12597 (ツ) johnfound
Създадено на 26.09.2020, видяно: 1356 пъти.
|

Хехехе, това е изказването на деня. Не е ли по-добре да меря в пикосекунди? :)

Съвременните процесори имат машинен цикъл от порядъка на 250..300пс. Така че, не, няма смисъл. За програмите, които ти можеш да напишеш микросекундите са добре. Даже и леко излишни – но все пак ще смятаме, че постепенно ще се научиш да пишеш и по-бързи програми.

#12598 (ツ) |
Последно редактирано на 26.09.2020 от |, видяно: 1354 пъти.
johnfound
|

Хехехе, това е изказването на деня. Не е ли по-добре да меря в пикосекунди? :)

Съвременните процесори имат машинен цикъл от порядъка на 250..300пс. Така че, не, няма смисъл. За програмите, които ти можеш да напишеш микросекундите са добре. Даже и леко излишни – но все пак ще смятаме, че постепенно ще се научиш да пишеш и по-бързи програми.

Абе, смешник, пак ли се опитваш да ме учиш как да програмирам? :) Вчера ме учи на английски, днес на програмиране, а? :)

Хайде да ти ги видим твоите програми колко са бързи. Нещо се покри, а? :)

#12605 (ツ) johnfound
Създадено на 26.09.2020, видяно: 1343 пъти.
|

Хайде да ти ги видим твоите програми колко са бързи. Нещо се покри, а? :)

Ъ? В смисъл, покрих? Някъде да съм казал, че ще ти пиша програмата? Смятам, че достатъчно често съм доказвал, че пиша бързи програми. Точно сега нямам време за още един уъркшоп.

А виж, ти си който пише програми дето се изпълняват по една седмица на топ машина. За което е и тази тема.

Мислех си, че си тук за съвет как да си усъвършенстваш програмистките скилове. Затова се опитвам да помогна. Ако една седмица те устройва – ОК, айм файн ...

#12606 (ツ) |
Последно редактирано на 26.09.2020 от |, видяно: 1337 пъти.
johnfound
|

Хайде да ти ги видим твоите програми колко са бързи. Нещо се покри, а? :)

Ъ? В смисъл, покрих? Някъде да съм казал, че ще ти пиша програмата? Смятам, че достатъчно често съм доказвал, че пиша бързи програми. Точно сега нямам време за още един уъркшоп.

А виж, ти си който пише програми дето се изпълняват по една седмица на топ машина. За което е и тази тема.

Мислех си, че си тук за съвет как да си усъвършенстваш програмистките скилове. Затова се опитвам да помогна. Ако една седмица те устройва – ОК, айм файн ...

Виж сега, ти може да можеш да си пишеш разни смешни играчки които се изпълняват за милисекунди, но реалните програми работят седмици. Знам, ти като изключителен програмист, никога не си виждал такава, и кой знае защо не програмираш професионално. :)

Съветът, който видях от теб е "използвай sqlite", който е толкова невероятно смешен, че дори и Рабин не посмя да каже нещо подобно.

Та, по-леко с жалката си арогантност, особено когато НЕ МОЖЕШ да я подкрепиш с ФАКТИ. :)

#12612 (ツ) Delegate
Създадено на 26.09.2020, видяно: 1325 пъти.
johnfound
Delegate

На прав път ли съм ?

Не. Трябва на всеки Б-стринг да изчисляваш дистанцията до всеки стринг от А и да намираш минималната дистанция.

Ако това върши работа, рънва на средния ми лаптоп за 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.

0 1 2 3 4 5 6 7 8 ....11 12 13 14 15 ....23 24 25 26 27 ....32 33 34 35 36

Задача НЕ за интервю
7

AsmBB v3.0 (check-in: a316dab8b98d07d9); SQLite v3.42.0 (check-in: 831d0fb2836b71c9);
©2016..2023 John Found; Licensed under EUPL. Powered by Assembly language Created with Fresh IDE