<bgdev />free

Вход Регистрация

Задача НЕ за интервю
7

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
#13034 (ツ) Courvoisier
Създадено на 29.09.2020, видяно: 1423 пъти.
Delegate

А на Джони изпълнихте екзето, а ? rofl

Не съм, пропуснах около 60-100 коментара в тази тема, tl;dr

#13036 (ツ) synergie
Създадено на 29.09.2020, видяно: 1421 пъти.
Delegate

А на Джони изпълнихте екзето, а ? rofl

Да. Директно в админ акаунта на уй-ндовусчето.

#13038 (ツ) Golden Gega
Създадено на 29.09.2020, видяно: 1407 пъти.

Асемблера е безопасен за пускане, а и Джонката е комунист до мозъка на кокалите си - такива работи като спам и фишинг ги мрази и в червата и едва ли ще ги прави някога.

#13039 (ツ) Delegate
Създадено на 29.09.2020, видяно: 1407 пъти.

Пуснах некъв сорс на предната страница. При мене C версията на | и тая на C# на моя скромен комп вървят горе-долу на равно на драг рейсинга. C-то го компилирах с GCC 4.9.2 64-bit с набримчени оптимизации за скорост.

#13040 (ツ) ФейкПрофил
Създадено на 29.09.2020, видяно: 1405 пъти.

това гцц от миналия век бре

#13041 (ツ) Delegate
Създадено на 29.09.2020, видяно: 1404 пъти.

Немам под ръка друго. Идва ми с DevC++ 5.11 lol

#13043 (ツ) synergie
Създадено на 29.09.2020, видяно: 1394 пъти.
Delegate

Пуснах некъв сорс на предната страница. При мене C версията на | и тая на C# на моя скромен комп вървят горе-долу на равно на драг рейсинга. C-то го компилирах с GCC 4.9.2 64-bit с набримчени оптимизации за скорост.

В неговия имаше и бъг който според джони сваля 500мс от реалното време(на компютъра на джони). Та може и C# версията ти да е по бърза реално.

#13064 (ツ) Courvoisier
Създадено на 29.09.2020, видяно: 1379 пъти.

Обаче на C# колко по- малко когнитивно комплексити има откъм език и колко по- описателно е какво прави. Сега се сетих какво не ми харесваше в C/C++ rofl

#13071 (ツ) johnfound
Последно редактирано на 30.09.2020 от johnfound, видяно: 1375 пъти.

ОК. Мисля, че най-най-сериозните проблеми ги открих. Сега работи значително по-бързо.

Атачвам архив с компилирани файлове за 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

П.П. Махам прикаченият файл. По-нататък в темата има по-нова версия.

#13073 (ツ) Courvoisier
Последно редактирано на 29.09.2020 от Courvoisier, видяно: 1370 пъти.

Бахти издухалия 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

Рънвам в един тред. Това не може ли да се раздели на порции според броя ядра? Само питам :-)

#13076 (ツ) |
Последно редактирано на 29.09.2020 от |, видяно: 1366 пъти.
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 секунди) за бавния или бързия компютър бяха? Странни са тези големи разлики в изпълнението за различните стрингове.

И последно, какъв беше проблемът с кода ти вчера? Кои инструкции не работеха както очакваше?

#13078 (ツ) |
Създадено на 29.09.2020, видяно: 1356 пъти.
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

Рънвам в един тред. Това не може ли да се раздели на порции според броя ядра? Само питам :-)

Не сме стигнали до многото ядра още. :)

#13079 (ツ) Golden Gega
Създадено на 29.09.2020, видяно: 1353 пъти.

Това за 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
#13081 (ツ) ФейкПрофил
Създадено на 29.09.2020, видяно: 1350 пъти.

Тези разлики във времената са ми много съмнителни

#13083 (ツ) johnfound
Създадено на 29.09.2020, видяно: 1348 пъти.
|
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, то няма смисъл да завършваш стринговете с по-голямо разстояние.

Разбира се, имаше (и все още има) и други - по-ситни проблеми - реда на изпълнение и кешовете например - с тях изобщо не съм започвал да се занимавам.

#13084 (ツ) johnfound
Последно редактирано на 29.09.2020 от johnfound, видяно: 1340 пъти.
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 под Линукс. Надявам се, че е коректно.

#13087 (ツ) johnfound
Създадено на 29.09.2020, видяно: 1332 пъти.
Courvoisier

Рънвам в един тред. Това не може ли да се раздели на порции според броя ядра? Само питам :-)

Може, но за тези програми няма нужда да се прави, защото нас ни интересува един стринг за колко ще се обработи. А ако трябва да обработваме много стрингове, разбира се ще се разделят на групи и за всяка група ще се пусне отделна нишка.

#13088 (ツ) |
Създадено на 29.09.2020, видяно: 1331 пъти.
johnfound

12-те секунди бяха на "бързият процесор" (N3540). А иначе, големият проблем се оказа с xchg r/mem (пък и r/r) която се оказа, че има гигантска латентност и във вътрешния цикъл скапваше времето тотално.

Никога не съм харесвал xchg, освен ако не е cmpxchg с lock префикс.

johnfound

Разликите в изпълнението са заради максималното разстояние - ако вече е намерено разстояние 4, то няма смисъл да завършваш стринговете с по-голямо разстояние.

Вярно, забравих да имплементирам това в C версията. Прикачвам нова версия... Разбира се, трябва да се компилира с О3.

Attached files:
FileSizeUploadedDownloadsMD5 hash
match.c2746 bytes29.09.2020123f56b8ef982c5f1c4d40ef097ee710fa2
#13090 (ツ) |
Създадено на 29.09.2020, видяно: 1329 пъти.
johnfound
Courvoisier

Рънвам в един тред. Това не може ли да се раздели на порции според броя ядра? Само питам :-)

Може, но за тези програми няма нужда да се прави, защото нас ни интересува един стринг за колко ще се обработи. А ако трябва да обработваме много стрингове, разбира се ще се разделят на групи и за всяка група ще се пусне отделна нишка.

По принцип би трябвало да мерим и това, защото memory bandwidth-а (и кешовете) са ограничени и в един момент тредовете ще започнат да се настъпват. Но всички имплементации използващи NxM сравнявания ще имат подобни проблеми. При tries ще е по-различно и там трябва да се сравнява.

#13091 (ツ) johnfound
Последно редактирано на 29.09.2020 от johnfound, видяно: 1328 пъти.
|

Вярно, забравих да имплементирам това в 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
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

Задача НЕ за интервю
7

AsmBB v3.0 (check-in: a316dab8b98d07d9); SQLite v3.42.0 (check-in: 831d0fb2836b71c9);
©2016..2023 John Found; Licensed under EUPL. Powered by Assembly language Created with Fresh IDE