0 1 2 3 4 ...13 14 15 16 17 ...28 29 30 31 32 33 34 35 36
Всъщност да, мога да го повторя на Windows. Има някакъв проблем точно с Windows-ката версия, интересното е, че във WINE работи нормално. Ще се опитам да дебъгна, но с Windows-a ми е малко сложно...
Малко модифицирах С-версията на Пайпа и при мен дава по-добри резултати сега. CPU:G1840/2.8Ghz
Оригинала
ds 99775 ol 100
0: 4 8968.431100 ms
1: 4 8069.468440 ms
2: 4 8980.419330 ms
3: 4 8979.220470 ms
4: 40 8971.888060 ms
5: 4 8069.415440 ms
6: 9 8972.812720 ms
7: 6 8971.225680 ms
8: 4 8969.875560 ms
9: 6 8073.109850 ms
С друга дистанс функция
ds 99775 ol 100
0: 4 4980.765750 ms
1: 4 4982.043070 ms
2: 4 4981.196810 ms
3: 4 4084.879320 ms
4: 40 4988.079010 ms
5: 4 4981.050080 ms
6: 9 4980.811110 ms
7: 6 4981.194600 ms
8: 4 4981.177410 ms
9: 6 4081.528070 ms
Има сорс и ехе за Windows
| File | Size | Uploaded | Downloads | MD5 hash |
|---|---|---|---|---|
| leven_c.zip | 3473691 bytes | 02.10.2020 | 143 | 705d5c682a30489ebbe2f9eb61673bdc |
В неговата версия липсват много оптимизации, дай един ръст сега
| File | Size | Uploaded | Downloads | MD5 hash |
|---|---|---|---|---|
| bender.zip | 3419182 bytes | 02.10.2020 | 155 | 3b5bb9dcc79573296ea2ec191d98989c |
Не би ли трябвало асмеблера да работи еднакво на всякъде ?
Ръст с авх2:
0|> Elapsed: 247; Distance: 4
1|> Elapsed: 239; Distance: 4
2|> Elapsed: 244; Distance: 4
3|> Elapsed: 157; Distance: 4
4|> Elapsed: 249; Distance: 40
5|> Elapsed: 201; Distance: 4
6|> Elapsed: 203; Distance: 9
7|> Elapsed: 231; Distance: 6
8|> Elapsed: 180; Distance: 4
9|> Elapsed: 211; Distance: 6
| File | Size | Uploaded | Downloads | MD5 hash |
|---|---|---|---|---|
| rust_avx.zip | 3419314 bytes | 02.10.2020 | 163 | 0af3d7d92064d8ad6fe8649d5e1b8d22 |
На Epyc-а:
# FASM
0: Dist: 4, Time: 575 ms
1: Dist: 4, Time: 540 ms
2: Dist: 4, Time: 530 ms
3: Dist: 4, Time: 14 ms
4: Dist: 40, Time: 407 ms
5: Dist: 4, Time: 181 ms
6: Dist: 9, Time: 257 ms
7: Dist: 6, Time: 305 ms
8: Dist: 4, Time: 93 ms
9: Dist: 6, Time: 273 ms
10: Dist: 58, Time: 330 ms
# Rust
0|> Elapsed: 537; Distance: 4
1|> Elapsed: 528; Distance: 4
2|> Elapsed: 525; Distance: 4
3|> Elapsed: 324; Distance: 4
4|> Elapsed: 372; Distance: 40
5|> Elapsed: 250; Distance: 4
6|> Elapsed: 244; Distance: 9
7|> Elapsed: 270; Distance: 6
8|> Elapsed: 220; Distance: 4
9|> Elapsed: 252; Distance: 6
10|> Elapsed: 288; Distance: 58
Асемблерската версия все още крашва на Интел-а.
Иначе сега се опитвам да направя GPU версията да използва SIMD (защото GPU-то има и такива инструкции :)
Много бавен този епик. Моя 5 годишен лаптоп вади по-малки времена.
Има ли 64 ядра? :)
Иначе на моя лаптоп:
0|> Elapsed: 184; Distance: 4
1|> Elapsed: 180; Distance: 4
2|> Elapsed: 179; Distance: 4
3|> Elapsed: 136; Distance: 4
4|> Elapsed: 185; Distance: 40
5|> Elapsed: 159; Distance: 4
6|> Elapsed: 162; Distance: 9
7|> Elapsed: 174; Distance: 6
8|> Elapsed: 143; Distance: 4
9|> Elapsed: 161; Distance: 6
10|> Elapsed: 183; Distance: 58
Това с векторизацията на теслата доста вероятно ще доведе до противоречив, вероятно по-лош резултат. Аз дори съм учуден че има вектори в кудата, в опенцл-а има защото е за различна железария - от процесори през FPGA до видеокарти, там някои платформи си имат реално хардуерни SIMD регистри отдолу. Нвидията няма (АМД имаха в по-старите архитектури, ма ги махнаха). Тоест от векторни операции няма да намажеш абсолютно нищо, просто защото компилатора ще ги сведе до n на броя скаларни, които ще подкара една след друга. Обаче в един частен случай има файда от това дори при това положение - при достъпването на памет. Това е защото хардуера позволява наведнъж да се чете повече памет, сега колко точно не помня, но определено е повече от един int на workitem. И тогава, от четенето от векторен буфер във векторна променлива има файда. От друга страна, това ще ти вдигне бройката регистри, които ползва кернела и съответно ще имаш по-ниско occupancy. Та като цяло дали ще намажеш или не е въпрос на експерименти.
Безспорно. Това си е бъг. Но ми е трудно да го дебъгвам, защото нямам Windows, а под Wine всичко работи нормално...
Я, колко сме в тоя клуб тука?
Рабин ИМА уиндоус (краден) и го ползва, да мълчи иззад козовръза
Опитвам се да използвам разните intrinsics като vminu4, не знам точно до какъв код ще доведат.
Харчи (виж prefix/radix trie) също както и непрекъснатото зареждане при всяко пускане на програмата, но Пайп-а не иска да разисква тоя въпрос, защото компенсира със смятането на гпу и неглижира проблема.
Какъв е проблема с паметта? Трай за примерния dataset ima 12 милиона nodes и отнема около 512 MB памет. И за какво непрекъснато зареждане става въпрос? Всеки път го изграждам в паметта.
Пробвах програмата на John с 256 (компютъра има 2 процессора * 64 ядра * 2 заради SMT) едновременни изпълнения да видя дали ще има някакво забавяне във времената. И да е имало, не беше забележимо.
Всеки път се чете от файл и се зарежда в дърво, при всяко стартиране - това е проблем. Идеята на дб-тата е да се зарежда само нужната информация, евентуално да се кешира. При само 512MB наистина са малко и все още не е проблем. Като стане GiB зареждането ще усетиш и забавяне. Какъв е точно по вид е трая? Валидация правиш ли?
0 1 2 3 4 ...13 14 15 16 17 ...28 29 30 31 32 33 34 35 36