Cytat: Agbar w 16 Marzec 2016, 22:57
Nie wiem, czy sesef opublikował kod źródłowy swojej wersji. Powinien, bo enigma jest licencjonowana GNU GPLv2 i wymaga publikacji kodu źródłowego. Jestem ciekawy jakie zmiany wprowadził, z tego co widziałem w zdekompilowanym kodzie musiał znaleźć inne podejście. Właściwie tylko szybko rzuciłem okiem na ten plik i wolałbym nie tracić czasu na reverse engineering. Wydaje mi się, że sesef "żyje" na BOINC Polish National Team. Jeżeli ktoś z Was mógłby go tam zagadnąć, będę wdzięczny.
Obie wersje, które się pojawiły bazują na kombinacji ustawieniami Intel Compiler-a, sam kod nie był zmieniany poza drobiazgami, które umożliwiły kompilację pod win. Intel Compiler bardzo dobrze potrafi optymalizować dostęp do pamięci stąd tak dobre wyniki niezależnie od tego czy liczymy na obciążonym czy nie komputerze. Natomiast optymalizacja samego kodu jest porównywalna z innymi kompilatorami czy to gcc czy vcc i z doświadczenia najlepiej zawsze wychodził pisany z palca kod na intrinsics-ach.
Starsza wersja (v 1.x) była kompilowana z tego co pamiętam ICC z 2008 albo 2010 i tutaj nie mam pewności czy coś jeszcze się nie zmieniło bo kod wsadowy dostałem od TJM-a. Kod raczej nie do odzyskania, chyba że jakaś kopia ostała się na którymś z HDD w szafie.
Nowsza wersja (v 2.0) kompilowana ICC 2013 albo 2014 tutaj standardowy kod modyfikowany tylko na potrzeby poprawnej kompilacji.
===============================================
Swego czasu prowadziłem trochę testów z nadzieją na AVX-512 w Skylake i dostęp do instrukcji vpermw (_mm512_permutexvar_epi16), która szacunkowo powinna przyspieszyć obliczanie score o 15-20% i dodatkowo odciążyć cache.
Robiłem też testy z instrukcjami gather. W tym przypadku dla Haswella jest 5-15% wolniej niż dla standardowego kodu natomiast przy Skylake oba rozwiązania są porównywalne.
Największą bolączką tej wersji algorytmu jest losowy dostęp do cache z dość sporą ilością błędnych trafień oraz mielenie prawie tych samych danych przy każdym kolejnym score. Dane wejściowe między dwoma wywołaniami funkcji score zmieniają się w niewielkim stopniu a i tak całościowy wynik jest liczony od początku (w sporej części przy obu wywołaniach odwołania pójdą do tych samych miejsc w pamięci w lookup_table.
Na szybko przejrzałem Twoje zmiany i kod bez poważnych przeróbek Intel Compilerem się nie skompiluje więc nawet nie mam co kombinować, a z braku czasu nie będę miał kiedy go dostosować (największym problemem jest brak obsługi __attribute__ ((vector_size(16))), tutaj trzeba by albo przerabiać kod albo napisać obsługę wszystkich potrzebnych operatorów dla używanych typów + wykorzystać standardowe __m128i/__m256i). Ze względu na taki charakter kodu przypuszczam, że pod windowsem całość kompilujesz przy pomocy mingw?
btw.
Sprawdzanie czy dana wersja liczy poprawnie bazując tylko na wyniku walidacji jest trochę błędne bo walidator potrafi przepuścić nawet błędnie policzone próbki. Tutaj lepszym rozwiązaniem byłoby z przeliczonych próbek mając startowego seed-a przeliczyć te wu ponownie niemodyfikowanym kodem.