synergie
Създадено на 29.09.2020, видяно: 1773 пъти. #13174
Нали се сещаш, че по добре клюкарка, отколкото сериен посерко. Буквално няма техническа тема дето да не си се осрал, което реално е ок, едва ли някои има очаквания конкретно към теб освен ти самият ;)
|
Създадено на 29.09.2020, видяно: 1773 пъти. #13175
Да, забавно е. Трябва да си поизчистя кода, да го направя да работи на много GPU-та и да видя за колко време ще се изпълни цялото нещо на две тесли.
Гледам, че франкенклъстъра има 20-ина нода с по 8 TITAN карти, но това е малко прекалено за тестване. :)
|
Създадено на 29.09.2020, видяно: 1772 пъти. #13177
Според кого е по-добре клюкарка? Според клюкарката? :)
Я, осралия всички технически теми, квичи отново. :)
synergie
Създадено на 29.09.2020, видяно: 1769 пъти. #13179
Айде Пипончо, със здраве от мен, до другата ти техническа тема в която неминуемо пак ще се осереш на базови СS концепции. Имай поне честта да се извиниш на Жони, той води доста културен и премерен разговор с теб.
|
Създадено на 29.09.2020, видяно: 1766 пъти. #13180
Я, клюкарката пак изквича нещо нечленоразделно. :)
johnfound
Създадено на 30.09.2020, видяно: 1734 пъти. #13204
Е, не държа чак толкова. Както се казва, "да разбереш, значи да простиш". Пайпа е ясен - живее в САЩ, а там бият през пръстите даже за намек за агресия и нетолерантност. Така че, там иска, не иска, а трябва да говори учтиво и да се подмазва на всички. Е, а в резултат, намира отдушник във форумите - иначе ще изперка съвсем за нула време и ще трябва като повечето американци да седи на антидепресанти... (Ако вече не е).
Абе зависи, аз съм игнорирал цял софт с УИ, дето смяташе някакви неща и ги експортваше в некви справки. С 2 SQL заявки. едната зареждаше данните, другата имаше имаше вложени селекти, групирания, джойнове(даже и един малък джойнт) и там каквото и изплюваше резултата за под 10 секунди в един csv. И това беше много несериозно и грубо от моя страна, защото друго си е цяла специализирана програма със всички салтанати там, bells and whistles и закачена една лелка да цъка по цял ден и да и изскачат прозорци със сложни таблици на екрана пред смаяния поглед на всички невежи, включая шефчето. Демек, ползваме софтуерен продукт и вършим тежка изчислителна и много важна работа от която никой друг не разбира освен въпросния ценен бабишкер.
Е те лелките ако можеха да се оправят, ние за какво сме? Аре, аз съм на дистрибутирани системи Ако на системите не им се налагаше да говорят, аз за какво съм им?
johnfound
Създадено на 30.09.2020, видяно: 1686 пъти. #13221
Още една итерация. Оказва се, че (поне на моите компютри) колкото по-прост и кратък е кодът, толкова по-бързо си работи.
Index - това е номерът на стринга в SetA (от 0), на който е намерена минималната дължина.
Отново атачвам компилираните файлове. Надявам се тоя път антивирусите да не мрънкат...
Освен това си завъдих и репозиторий, ако някой иска да се запознае с кода: Fossil repository
В кода, proc Levenstein е предишната имплементация с MMX и опит за паралелна обработка (не много ефективна при Левенщейн), а сегашният фаворит е proc Levenstein2.
Следващата стъпка ще е по аналогия - ако по-малкият код се изпълнява по-бързо, следва да се приеме, че и по-малките данни ще се изпълняват по-бързо. Следователно си струва да се опита с пакетирани данни - по 2 бита на символ. (Защото това са данни за ДНК, а при тях символите са само 4).
Само ми е интерсно как вади 157мс за ред 3 след като другите времена са почти двойни.
Искаш ли да имплементираш моя алгоритъм ?
pub fn levenshtein<'i, I, X>(a: &'i I, b: &'i I, max_distance: usize) -> usize
where
&'i I: IntoIterator<Item=X>,
X: PartialEq<X> + Copy
{
let a_len = a.into_iter().count();
let b_len = b.into_iter().count();
if a_len == 0 {
return b_len;
}
let mut a = a;
let mut b = b;
if a_len < b_len {
swap(&mut a, &mut b);
}
let mut cache: Vec<usize> = (1..min(a_len, b_len) + 1).collect();
let mut result = 0;
for (i, a_elem) in a.into_iter().enumerate() {
result = i + 1;
let mut distance_b = i;
let mut current_distance = i;
for (j, b_elem) in b.into_iter().enumerate() {
let distance_a = if a_elem == b_elem {
distance_b
} else {
distance_b + 1
};
distance_b = cache[j];
result = min(
result + 1,
min(distance_a, distance_b + 1),
);
cache[j] = result;
if result < current_distance {
current_distance = result;
}
}
if current_distance >= max_distance {
return max_distance;
}
}
result
}
johnfound
Създадено на 30.09.2020, видяно: 1675 пъти. #13226
Искаш ли да имплементираш моя алгоритъм ?
В смисъл? То разстоянието на Левенщайн се смята по точно един алгоритъм. Различават се начините на имплементация на този един алгоритъм.
Това твоето решение как да го пусна на Линукс? Интересно ми е на по-бавни процесори дали все още ще е по-бърз, или аз лошо поддържам съвременните процесори?
|
Създадено на 30.09.2020, видяно: 1661 пъти. #13231
ами само пускаш изпълнимия файл:
./playground
На твоя компютър не знам дали ще тръгне, защото е компилирано за моя, ако не тръгне или може да си го компилираш сам:
1. За да си свалиш ръст:
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
2. След което в папката със cargo.toml файла:
cargo run --release
Или ако не искаш да си го компилираш сам мога да го прекомпилирам за generic x86
Аз имам някакъв инсталиран rust, но получавам грешки:
error[E0432]: unresolved import `vec_vp_tree`
--> src/main.rs:11:5
|
11 | use vec_vp_tree::VpTree;
| ^^^^^^^^^^^ Maybe a missing `extern crate vec_vp_tree;`?
error[E0309]: the parameter type `S` may not live long enough
--> src/main.rs:92:52
|
92 | struct StringToBytesAdapter<'a, S: AsRef<str>>(&'a S);
| -- ^^^^^^
| |
| help: consider adding an explicit lifetime bound `S: 'a`...
|
note: ...so that the reference type `&'a S` does not outlive the data it points at
--> src/main.rs:92:52
|
92 | struct StringToBytesAdapter<'a, S: AsRef<str>>(&'a S);
| ^^^^^^
error: aborting due to 2 previous errors
много ти е стар ръста щом реве за extern crate, това не нужно от повече от година
rustup update stable
ПП: a tova s ВП дървото може да се изтрие - наистина прави много по-малко левенщайн операции при търсене, но за самото му конструиране отиват повече операции отколкото за брутфорса :(
|
Последно редактирано на 30.09.2020 от |, видяно: 1650 пъти. #13234
много ти е стар ръста щом реве за extern crate, това не нужно от повече от година
rustup update stable
ПП: a tova s ВП дървото може да се изтрие - наистина прави много по-малко левенщайн операции при търсене, но за самото му конструиране отиват повече операции отколкото за брутфорса :(
# Go (trie)
0: 4 2506 ms
1: 4 237 ms
2: 4 962 ms
3: 4 1254 ms
4: 40 2575 ms
5: 4 369 ms
6: 9 1651 ms
7: 6 1125 ms
8: 4 774 ms
9: 6 243 ms
10: 58 3739 ms
# C
0: 4 2014.568000 ms
1: 4 1894.743000 ms
2: 4 1949.750000 ms
3: 4 559.776000 ms
4: 40 1967.738000 ms
5: 4 1311.775000 ms
6: 9 1520.449000 ms
7: 6 1984.073000 ms
8: 4 960.098000 ms
9: 6 1565.859000 ms
10: 58 2415.516000 ms
# Go (bruteforce)
0: 4 3428 ms
1: 4 3329 ms
2: 4 3456 ms
3: 4 931 ms
4: 40 3434 ms
5: 4 2326 ms
6: 9 2588 ms
7: 6 3295 ms
8: 4 1777 ms
9: 6 2689 ms
10: 58 4301 ms
johnfound
Създадено на 30.09.2020, видяно: 1647 пъти. #13235
Или ако не искаш да си го компилираш сам мога да го прекомпилирам за generic x86
Оказа се, че си го имам компилаторът на rust (минус на рядкото преинсталиране - събират се странни неща на диска) и си го компилирах. (Оригиналният изпълним файл гърми при мене).
Но резултатите са различни (A4-1200 1GHz) от това, което е при тебе:
обаче е интересно как различните компилатори генерират различно оптимален код за различните процесор - според времената от bigbugex ръста е доста по-бърз от Ц и асм, докато при | Ц е малко по-бързо, a пък при теб АСМ :Д
За ред с номер 3 пак имаш невероятно малко време - 30 пъти по-бързо от ред 0.
|
Създадено на 30.09.2020, видяно: 1639 пъти. #13239
@пайп, Това на какъв компютър/CPU ? (Някъде назад май го беше писал..)