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