Ez tetszik:) Bar baromi regen volt, megis mintha remlene, hogy a szabaly a szeleken is illeszkedest kert. Aztan tevedhetek. (Ertsd: ha ugy volt, akkor nem kibovitette, hanem szukitette a szabalyokat, aminek a kirakas megfelel.)
Befértem a 3x3-as részletek véletlenszerű azonosításával 0...3,6*10^11 tartományba, ami 42GB-os adatblokkokat jelent. Ez még mindig messze van a szekvenciális azonosítás <12GB-os blokkjaitól, de ezzel már lehet játszogatni. Kicsi trükkel 36GB is elég lehet... alakul. :)
Legközelebb akkor próbálkozom, ha lesz legalább 200GB RAM-om.
Oda már be tudok pakolni két 2^40 bites táblát némi trükközéssel (mROT transzfer vagy 256GB+).
Kb. 1000-szeres gyorsulás érhető el a táblák közti átjárásnál, de minimális kombó átlapolással számolni kell (0,1% alatt tartható 5x5C, 4x3MClue0 esetén is).
Szia! Szinte már senki nem foglalkozik az EternityII-vel, még a legnagyobb fórum (Yahoo/Eternity_two) is régen kihalt. Az általam ír kód assemblyben készült és kb. ötven alkalommal írtam meg újra és újra. :) Ugyanis mikor az aktuális ötletről kiderült, hogy halott ügy, akkor kidobtam az egészet a kukába. Aztán mikor elég új ötlet gyűlt össze, akkor újraírtam, ugyanis kb. 20 sor a hot spot, az meg a fejemben van. Jelenleg már hónapok óta nem programoztam a témával kapcsolatban. Persze állandóan jönnek újabb és újabb ötletek, de azokról mindig kiderül még a tervezési fázisban, hogy nem elég hatékonyak. Egyébként szívesen segítek, de a "netről letölthető program" kategóriában nem tudok. Olyanokat sosem próbáltam.
Én magam is foglalkoztam a problémával. Még 2010-ben írtam c-ben egy programot, ami backtrack nélkül brute force-olt viszonylag gyenge 35.000 másodpercenkénti próbálkozással. Középről indulva spirálba helyezte fel az elemeket, amíg tudta. Utána kezdte elölről. Kb 5 perc alatt 100 elemet tud így felrakni.
A kérdésem az lenne, hogy melyik a legjobb netről letölthető program, amit tudnék futtatni? Esetleg van még olyan project, ami számítógépek között elosztva dolgozik? (BOINC)
Fekete Ákos: a te megoldásod mennyire "open source"?
Egy kis szemléltető ábra, hogy a két szomszédos szín (2*5 bit) helyetti két szomszédos puzzle+orientáció (2*10 bit) adatra való átállás milyen hatással volt a "sötét zónára".
Az első esetben kb. 115 MB adattal dolgozik a kereső, a másodikban 17GB.
Szerintem logikus a következő lépés, megpróbálkozok a két szomszédos négyes (2*40 bit) kombinációval.
Az adatokkal persze trükközni kell, de előzetes számítások alapján elegendő lehet 128GB RAM.
Sikerült további 10%-kal növelni a lerakási sebességet. Ráadásul mindezt úgy értem el, hogy a soron következő pozícióba lerakható puzzle kiválasztása szigorúbb feltételekkel szűrt listából történik. Ez a feleslegesen bejárandó zsákutcák számát csökkenti, ami szintén sebességnövelő tényező. Megspóroltam az index tábla olvasást, cserébe 4GB memóriát esznek az adatok. Alakul... :D
