Delegate А на Джони изпълнихте екзето, а ?
![]()
Не съм, пропуснах около 60-100 коментара в тази тема, tl;dr
Delegate А на Джони изпълнихте екзето, а ?
![]()
Не съм, пропуснах около 60-100 коментара в тази тема, tl;dr
Delegate А на Джони изпълнихте екзето, а ?
![]()
Да. Директно в админ акаунта на уй-ндовусчето.
Асемблера е безопасен за пускане, а и Джонката е комунист до мозъка на кокалите си - такива работи като спам и фишинг ги мрази и в червата и едва ли ще ги прави някога.
Пуснах некъв сорс на предната страница. При мене C версията на | и тая на C# на моя скромен комп вървят горе-долу на равно на драг рейсинга. C-то го компилирах с GCC 4.9.2 64-bit с набримчени оптимизации за скорост.
това гцц от миналия век бре
Немам под ръка друго. Идва ми с DevC++ 5.11 lol
Delegate Пуснах некъв сорс на предната страница. При мене C версията на | и тая на C# на моя скромен комп вървят горе-долу на равно на драг рейсинга. C-то го компилирах с GCC 4.9.2 64-bit с набримчени оптимизации за скорост.
В неговия имаше и бъг който според джони сваля 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
Рънвам в един тред. Това не може ли да се раздели на порции според броя ядра? Само питам
johnfound ОК. Мисля, че най-най-сериозните проблеми ги открих. Сега работи значително по-бързо.
Атачвам архив с компилирани файлове за 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
Как са в сравнение със C програмата? Резултатите, които пусна от нея (нещо като 12 секунди) за бавния или бързия компютър бяха? Странни са тези големи разлики в изпълнението за различните стрингове.
И последно, какъв беше проблемът с кода ти вчера? Кои инструкции не работеха както очакваше?
Courvoisier Бахти издухалия 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
Рънвам в един тред. Това не може ли да се раздели на порции според броя ядра? Само питам
![]()
Не сме стигнали до многото ядра още. :)
Това за 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
Тези разлики във времената са ми много съмнителни
| johnfound ОК. Мисля, че най-най-сериозните проблеми ги открих. Сега работи значително по-бързо.
Атачвам архив с компилирани файлове за 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
Как са в сравнение със C програмата? Резултатите, които пусна от нея (нещо като 12 секунди) за бавния или бързия компютър бяха? Странни са тези големи разлики в изпълнението за различните стрингове.
И последно, какъв беше проблемът с кода ти вчера? Кои инструкции не работеха както очакваше?
12-те секунди бяха на "бързият процесор" (N3540). А иначе, големият проблем се оказа с xchg r/mem
(пък и r/r) която се оказа, че има гигантска латентност и във вътрешния цикъл скапваше времето тотално.
Разликите в изпълнението са заради максималното разстояние - ако вече е намерено разстояние 4, то няма смисъл да завършваш стринговете с по-голямо разстояние.
Разбира се, имаше (и все още има) и други - по-ситни проблеми - реда на изпълнение и кешовете например - с тях изобщо не съм започвал да се занимавам.
Delegate Някой, ако иска да тества C# версия (exe)
На 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 под Линукс. Надявам се, че е коректно.
Courvoisier Рънвам в един тред. Това не може ли да се раздели на порции според броя ядра? Само питам
![]()
Може, но за тези програми няма нужда да се прави, защото нас ни интересува един стринг за колко ще се обработи. А ако трябва да обработваме много стрингове, разбира се ще се разделят на групи и за всяка група ще се пусне отделна нишка.
johnfound 12-те секунди бяха на "бързият процесор" (N3540). А иначе, големият проблем се оказа с
xchg r/mem
(пък и r/r) която се оказа, че има гигантска латентност и във вътрешния цикъл скапваше времето тотално.
Никога не съм харесвал xchg, освен ако не е cmpxchg с lock префикс.
johnfound Разликите в изпълнението са заради максималното разстояние - ако вече е намерено разстояние 4, то няма смисъл да завършваш стринговете с по-голямо разстояние.
Вярно, забравих да имплементирам това в C версията. Прикачвам нова версия... Разбира се, трябва да се компилира с О3.
johnfound Courvoisier Рънвам в един тред. Това не може ли да се раздели на порции според броя ядра? Само питам
![]()
Може, но за тези програми няма нужда да се прави, защото нас ни интересува един стринг за колко ще се обработи. А ако трябва да обработваме много стрингове, разбира се ще се разделят на групи и за всяка група ще се пусне отделна нишка.
По принцип би трябвало да мерим и това, защото memory bandwidth-а (и кешовете) са ограничени и в един момент тредовете ще започнат да се настъпват. Но всички имплементации използващи NxM сравнявания ще имат подобни проблеми. При tries ще е по-различно и там трябва да се сравнява.
| Вярно, забравих да имплементирам това в C версията. Прикачвам нова версия... Разбира се, трябва да се компилира с
О3.
Така, разбира се е по-добре (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