Ebbol bazinagy flame lesz hogy biztos direkt elszartam, meg azt nem ugy kellett volna, blabla:
Csak gyors teszt volt es komplex megoldast valasztottam, mert ez inkabb elofordul mint egy "statikus benchmark". Azonos input (jelen pillanatban 0-tol 10m-ig tarto szamok) illetve egy teljesen random 64bit-es szam, nem minden hashmap, ennel sokkal komplikaltabb az adatszerkezet es a feloldas is. A feloldas tobb szintu, a teljes menete a 64 bites szammal kezdodik, majd 3 melysegben a rangelt szamok.
Azonos eselyel indultak a versenyzok (multithread kornyezetben, 16 magon), a c++ eseteben ez ertelemszeruen azt jelentette, hogy a lookup-oknal mutexeket kellett hasznalnom ami jelentosen rontotta a teljesitmenyt. Az input specialis, ezt c++ eseten nem tudtam kihasznalni mivel sem a vector, sem a hash map-et nem birizgaltam, a sajat c megoldasomban jelentos memoria megtakaritasokat tudtam igy veghezvinni.
5 perc futas volt mindkettonek engedve, az eredmenyeket ez alapjan atlagoltam, az input file-om 500 mega volt
Vegeredmeny: c++ / sajat c
Memoria: 14gb / 380mb
Sebesseg (query/sec): 117e / 392m
Biztos tudtam volna fentebb tornaszni a c++ kodot sebessegben, illetve memoriaban lefele, de igazabol csak a standard cuccok hasznalataval max ha 20-30%-ot nyerek a jelenlegi tempon.
Az elkeszitesi ido kozel azonos volt, ez koszonheto annak hogy az elmult 4-5 honapban masszivan c-vel foglalkoztam csak
Konkluzio: ha a sebesseg fontos, ugy is magadnak implementalsz, itt a c szerintem elonyben tud kijonni a c++-al szemben. Ha nem fontos a sebesseg, akkor az ember ugy is ujra hasznositja korabbi kodjait, nem kell mindent feltalalni ujra, masreszt egy egyszeru map-et 1-2 perc alatt osszedob az ember, az ido nagy reszet fejlesztes kozben meg nem az ilyen kodok gyartasa teszi ki, hanem az adott problema megoldasa es az utkereses
// Happy debugging, suckers
#define true (rand() > 10)