TCH (statz) | #1, Főfasz (10479) |
1870 | #5959 | ^ | Idézet | Thu, 02 Jan 2025 02:25:51 +01 |
188.143.*.* | *.pool.digikabel.hu |
Na, gyorsan át is írtam az RC2-őt C-be; itt az RC3 C változatának egyelőre alfája: http://oscomp.hu/depot/rc3.c Ezt most direkt backward compatibility-vel csináltam meg, azaz benne van az RC2 (és RC1) táblagenerátora is, meg ez a sima cserélgetős is és lehet választani. Fogtam egy ~4.3 MB-os fájlt, amiben az a sor van 65536x ismételve, hogy Egy kicsi kecske felment a hegyre. Le nem jött, mert döglött ló.A teszt abból állt, hogy 16 byte-os ablakmérettel (azaz 16 byte-onként generálta újra a táblát) eltitkosította mode1-gyel, majd vissza mode2-vel, aztán eltitkosította mode2-vel, majd vissza mode1-gyel és természetesen mind a négy buffert kimentette. És ezt eljátszottam mindkét táblagenerálási eljárással. Az eredmény: 2.448s volt az egyszer végigmenős és véletlenszerűen cserélgetős és 11.695s volt a régi, kizárósan-generált feltöltős. 4.77737-szer lassabb a régi. És az eltitkosított fájlok ugyanolyan katyvaszok voltak; nincs hatásfokban különbség. És ha levettem az ablakot 1 byte-ra, akkor 25.941s volt az új és 171.474s a régi. 6.61015-szörös különbség. Szerintem nem éri meg a régivel nyűglődni. (A véletlenszámok generálását a már linkelt - szintén threadsafe és crossplatform - véletlenszámgenerátorommal csináltam; ez nem eldöntött, hogy ezzel lesz-e, de még nem mondtad, hogy a véletlenszámokat hogyan akarod generálni; az OS-ek libc-jének beépített véletlenszámgenerátora csak ugyanazon OS/libc kombón fogja ugyanarra a seedre ugyanazt az eredményt adni: nem lesz hordozható a végeredmény. Még Linuxról-Linuxra sem, ha az egyiken glibc van, a másikon meg mondjuk musl. Akkor IMHO, már jobban járunk a psrand-dal; a glibc generátoránál jobb... :P) |