dez#57
Jó vicc, ez természetesen alapvetően nem az SPE-knek való feladat, mi a csudáért kellene rájuk erőltetni? Ott van a PPE ilyesmire!
Tehát semmi értelme nem lenne ezt SPE-vel csinálni (hacsak nem valami elég bonyi művelet zajlana az a tömb elemei között, ami által arra menne el az idő nagyobb része).
Továbbá, ha már SPE-k, akkor az összeset bevetném, nem mellesleg kihasználva az összesen 2MB-nyi belső memóriát... De most maradjunk 1db-nál. Nem állok most neki igazán alaposan átgondolni, és főleg lekódolni csak a kedvedért, de pl. így lehetne csinálni:
1. 5 részre osztom a 256KB-ot. 2x64KB a1 és a2 buffer, 64KB b buffer, 32KB c buffer, a maradékban a program terpeszkedhet.
2. Főciklusban beolvasgatom az a többöt 2x64KB-os blokkokban a1 és a2 bufferbe, olyan variációkban, hogy mindegyik 64KB-os blokk "találkozzon" egymással 1x.
3. Minden ilyen variációban végigmegyek a b tömbbön 64KB-os blokkokban (b buffer), és kikeresem belőle azokat a párokat, amik éppen a1 és a2 bufferben vannak.
4. Közben a c tömbből is beolvasom a b tömbből beolvasott blokknak megfelelő blokkot (ha már írtam korábban oda), és ide írkálom a párok összegeit.
Nos, a b és c tömbökön többször kell végigmenni, de a "pároztatás" már viszonylag gyorsan megy a belső gyors ramban. Hogy pontosan hányszor kell végigmenni a b és c tömbökön blokkonként, most pontosan nem tudnám megmondani, ki kellene számolni, de pl. messze nem 64x64, mert elég, ha két a-s blokk egyszer találkozik, ennek a mintájára: 4 blokk -> 1-2, 1-3, 1-4, 2-3, 2-4, 3-4. (Cserébe számld ki nekem, hány variáció lesz a mi példánkban! :) )
ps. átlagos procin viszonylag gyorsan fut az az egy soros c kód is, de azon is lehetne optimizálni...