0 1 2 3 4 ...8 9 10 11 12 ...19 20 21 22 23 ...27 28 29 30 31 32 33 34 35 36
Не съм, пропуснах около 60-100 коментара в тази тема, tl;dr
Да. Директно в админ акаунта на уй-ндовусчето.
Асемблера е безопасен за пускане, а и Джонката е комунист до мозъка на кокалите си - такива работи като спам и фишинг ги мрази и в червата и едва ли ще ги прави някога.
Пуснах некъв сорс на предната страница. При мене C версията на | и тая на C# на моя скромен комп вървят горе-долу на равно на драг рейсинга. C-то го компилирах с GCC 4.9.2 64-bit с набримчени оптимизации за скорост.
Немам под ръка друго. Идва ми с DevC++ 5.11 lol
В неговия имаше и бъг който според джони сваля 500мс от реалното време(на компютъра на джони). Та може и C# версията ти да е по бърза реално.
Обаче на C# колко по- малко когнитивно комплексити има откъм език и колко по- описателно е какво прави. Сега се сетих какво не ми харесваше в C/C++ 
ОК. Мисля, че най-най-сериозните проблеми ги открих. Сега работи значително по-бързо.
Атачвам архив с компилирани файлове за Windows и Linux. По косвени признаци съдя, че ще е по-бърза от на Пайпа C решението за CPU.
Който ми има достатъчно доверие да го тества на бързи машини - поствайте резултатите, поне за 10 реда. Сега би трябвало да има отчетлива разлика между бързи и бавни процесори.
На моята бавна машина (А4-1200, 1GHz) резултатите са такива:
0: Dist: 4, Time: 14877 ms
1: Dist: 4, Time: 13662 ms
2: Dist: 4, Time: 14246 ms
3: Dist: 4, Time: 470 ms
4: Dist: 40, Time: 15095 ms
5: Dist: 4, Time: 7793 ms
6: Dist: 9, Time: 12332 ms
7: Dist: 6, Time: 14435 ms
8: Dist: 4, Time: 4393 ms
9: Dist: 6, Time: 12699 ms
А на "бързата" (Pentium N3540 2.16GHz) са примерно такива:
0: Dist: 4, Time: 8588 ms
1: Dist: 4, Time: 7957 ms
2: Dist: 4, Time: 8223 ms
3: Dist: 4, Time: 260 ms
4: Dist: 40, Time: 8604 ms
5: Dist: 4, Time: 4499 ms
6: Dist: 9, Time: 7122 ms
7: Dist: 6, Time: 8251 ms
8: Dist: 4, Time: 2516 ms
9: Dist: 6, Time: 7319 ms
П.П. Махам прикаченият файл. По-нататък в темата има по-нова версия.
Бахти издухалия 2700U къде имам...
0: Dist: 4, Time: 6359 ms
1: Dist: 4, Time: 5954 ms
2: Dist: 4, Time: 5781 ms
3: Dist: 4, Time: 187 ms
4: Dist: 40, Time: 6032 ms
5: Dist: 4, Time: 3187 ms
6: Dist: 9, Time: 5078 ms
7: Dist: 6, Time: 5844 ms
8: Dist: 4, Time: 1828 ms
9: Dist: 6, Time: 5469 ms
Рънвам в един тред. Това не може ли да се раздели на порции според броя ядра? Само питам 
Как са в сравнение със C програмата? Резултатите, които пусна от нея (нещо като 12 секунди) за бавния или бързия компютър бяха? Странни са тези големи разлики в изпълнението за различните стрингове.
И последно, какъв беше проблемът с кода ти вчера? Кои инструкции не работеха както очакваше?
Това за i5-4570 3.20GHz, май е серия K ама джама не казва
Dictionary (SetA) length: 99775
0: Dist: 4, Time: 6344 ms
1: Dist: 4, Time: 5813 ms
2: Dist: 4, Time: 5875 ms
3: Dist: 4, Time: 187 ms
4: Dist: 40, Time: 6172 ms
5: Dist: 4, Time: 3250 ms
6: Dist: 9, Time: 5141 ms
7: Dist: 6, Time: 5953 ms
8: Dist: 4, Time: 1812 ms
9: Dist: 6, Time: 5422 ms
Тези разлики във времената са ми много съмнителни
12-те секунди бяха на "бързият процесор" (N3540). А иначе, големият проблем се оказа с xchg r/mem (пък и r/r) която се оказа, че има гигантска латентност и във вътрешния цикъл скапваше времето тотално.
Разликите в изпълнението са заради максималното разстояние - ако вече е намерено разстояние 4, то няма смисъл да завършваш стринговете с по-голямо разстояние.
Разбира се, имаше (и все още има) и други - по-ситни проблеми - реда на изпълнение и кешовете например - с тях изобщо не съм започвал да се занимавам.
На AMD A4-1200 1GHz:
0 elapsed (ms)/dist:73123/4
1 elapsed (ms)/dist:65817/4
2 elapsed (ms)/dist:66064/4
3 elapsed (ms)/dist:66250/4
4 elapsed (ms)/dist:66252/40
5 elapsed (ms)/dist:66034/4
6 elapsed (ms)/dist:65950/9
7 elapsed (ms)/dist:74194/6
8 elapsed (ms)/dist:71947/4
9 elapsed (ms)/dist:71321/6
10 elapsed (ms)/dist:67221/58
11 elapsed (ms)/dist:67792/6
12 elapsed (ms)/dist:67728/7
13 elapsed (ms)/dist:68043/4
14 elapsed (ms)/dist:71919/4
15 elapsed (ms)/dist:75342/7
Пускам го с mono под Линукс. Надявам се, че е коректно.
Може, но за тези програми няма нужда да се прави, защото нас ни интересува един стринг за колко ще се обработи. А ако трябва да обработваме много стрингове, разбира се ще се разделят на групи и за всяка група ще се пусне отделна нишка.
Никога не съм харесвал xchg, освен ако не е cmpxchg с lock префикс.
Вярно, забравих да имплементирам това в C версията. Прикачвам нова версия... Разбира се, трябва да се компилира с О3.
| File | Size | Uploaded | Downloads | MD5 hash |
|---|---|---|---|---|
| match.c | 2746 bytes | 29.09.2020 | 160 | f56b8ef982c5f1c4d40ef097ee710fa2 |
По принцип би трябвало да мерим и това, защото memory bandwidth-а (и кешовете) са ограничени и в един момент тредовете ще започнат да се настъпват. Но всички имплементации използващи NxM сравнявания ще имат подобни проблеми. При tries ще е по-различно и там трябва да се сравнява.
Така, разбира се е по-добре (Pentium N3540, 2.16GHz):
ds 99775 ol 100
0: 4 10817.139030 ms
1: 4 10192.065867 ms
2: 4 10527.143604 ms
3: 4 2746.656449 ms
4: 41 10911.672099 ms
5: 4 7023.080065 ms
6: 9 7600.627068 ms
7: 6 9963.960899 ms
8: 4 5012.648890 ms
9: 6 8086.559660 ms
0 1 2 3 4 ...8 9 10 11 12 ...19 20 21 22 23 ...27 28 29 30 31 32 33 34 35 36