Astronomické fórum

Vyhrabal jsem z nudy starý notebook a na něm se mi (naštěstí!) projevila Martinova chyba. Je ve všech souborech už od přidání gamma korekce (nedostatečně obsáhlá podmínka volala vykreslovací funkci při startu ještě před načtením souboru, takže aplikace čekala na výsledek výpočtu, který se nikdy neprovede). Je ale s podivem, že se někomu objevila až teď.

Opravil jsem jak "ostrou" verzi přímo na stránkách, tak i tu novou experimentální.

Původní pro Linux x86_64
Původní pro Windows x86_64
Původní pro Windows x86
Původní pro Linux ARMv7
Původní pro Linux aarch64

Experimentální pro Linux x86_64
Experimentální pro Windows x86_64
Experimentální pro Windows x86
Experimentální pro Linux ARMv7
Experimentální pro Linux aarch64

Pro zajímavost... na RPi 3 trvá načtení 16Mpix 16bit snímku v původní aplikaci 5 vteřin (aarch64; 6,5 vteřiny na ARMv7) a v experimentální 1 vteřinu (aarch64 i ARMv7). Pětinásobné zrychlení.

Do budoucna ještě plánuji optimalizace, takže to možná ještě trochu zrychlím. Pak nejspíš původní verzi pošlu k ledu.

Paráda, už to chodí. A je to při načítání viditelně rychlejší, u mě minimálně tak 3x. Jen nechápu, proč to starší verze nedělala. A ta nová jen na některých strojích. Že by jiné načasování mezi jednotlivými vlákny ?

Všechno mi to přečetlo, až na jednu vyjímku, 32-bit fitsy - složeniny z více snímků, které vyplivne SharpCap při stackingu. Tady je ke stažení:

http://leteckaposta.cz/199913932

Už ho otevře správně.

Tohle je i pro ostatní, kdyby narazili na soubor, který nelze otevřít / je zobrazený špatně. Je to jen formát dat, se kterým jsem zatím nepracoval, tak jsem to nemohl naprogramovat (parametry BZERO a BSCALE výrazně mění význam dat).

Další vlna zrychlení načítání, na SSD a HDD zhruba 3× (u mne z 60 na 20 ms), na RPi3 2× (z karty, z 1000 na 500 ms). V obou případech s 16Mpix 16bit celočíselným FITem.

Experimentální pro Linux x86_64
Experimentální pro Windows x86_64
Experimentální pro Windows x86
Experimentální pro Linux ARMv7
Experimentální pro Linux aarch64

Psion píše:Vyzkouším pro Arm7, je fakt že na kameře Astrel to otevírání trvá se starou verzí 2950 ms.

Je to teď o poznání rychlejší?

Je, a sakra rychlejší. Předtím 16Mpix 16bit FISTy čtení okolo 130-140ms, nyní tak 30-40ms.
Kouzelníku

Ale zkolabuje to na těchhle FITS-ech uložených ze SW SIPS.

http://leteckaposta.cz/251829912

Nic to nezobrazí, jen to zatěžuje procesor.
Pokud přelezu s už naběhlou aplikací z jiného adresáře do adresáře který takové FITSy obsahuje, kousene se to taky.

U mě to problém nedělá.

Aha, tak už jsme doma. Já si neuvědomil, že v tom adresáři je přes 2700 souborů, takže trvá přes 10 sekund, než se naplní listbox se seznamem souborů.

Nikdy jsem nevydržel čekat a dal Ctrl+Alt+Del

Tomáš Grygarčík píše:Tohle je i pro ostatní, kdyby narazili na soubor, který nelze otevřít / je zobrazený špatně. Je to jen formát dat, se kterým jsem zatím nepracoval, tak jsem to nemohl naprogramovat (parametry BZERO a BSCALE výrazně mění význam dat).

Myslim ze BSCALE a BZERO sa mozu bezpecne ignorovat pretoze pre zobrazenie na obrazovke sa musi spravit skalovanie z 0-65535 na 0-255. Myslim si teda ze preskalovanie cez BSCALE a BZERO je mozne bezpecne ignorovat popripade ignorovat.

Ignorovat se mohou, pokud mají "výchozí hodnotu" (BScale 1, u BZero 0 anebo nula relativní k rozsahu - 16k, 32k, 2M apod.)

Tomáši, udělal jsem v Delphi vlastní velmi jednoduchý prohlížeč fitů , dostačující pro moje potřeby. Zpracovávám jen 16bit fit , ten co mi vyhodí Maxim DL z kamery. Stáhnul jsem si tvůj program a vyzkoušel .
Aby byly porovnatelné časy , tak jsem si vytvořil několik velkých fitů 93 MB 16 bit ( základní fit jsem zvětšil na 200% ).
Časy : u tebe 280 načtení, 70-150 přepočet, což je dohromady 350-430 msec. U mne celkové , první snímek 330 msec, pak další jen kolem 180 msec , což je cca 2x rychlejší . Pro načtení souboru používám jen klasickou funkci BlockRead . Testoval sem na notebooku HP OMEN i7 9750H 4,6GHz .
Neber jako kritiku, jen mne to velice udivilo ?? Nedokáži si to nijak vysvětlit , už jen z důvodů , že je to čtení z klasického plotnového HD a tam bývá rychlost čtení do 200MB/sec ? To by tady znamenalo čas kolem 500 msec ????
Pro ostatní odborniky IT , dokázal by to někto vysvětlit ?

astar píše:Pro ostatní odborniky IT , dokázal by to někto vysvětlit ?

Tak OS, disk a možná i některý lepší řadič data kešuje v paměti...
Nemá ten noťas SSD na kešování plotnového disku? Když jsem otevřel náhodný HP Omen:

Pevný disk: 512 GB SSD + 1 000 GB

Bohužel to nevím . Jak to zjistím? SSD mám, ale jen 256GB . Podle mne by se pak musela udělat ta keš i pro ten Tomášův program ,ne ?
Vytvořil jsem Ramdisk , tam dal ta data a časy byly stejné ???

Ak sa subor cital tak ho OS drzi v RAM cache. V Linux sa da prinutit aby tu cache vyprazdnil ale na windows neviem. Jeden sposob s neistym vysledkom je precitanie par GB suborov aby tieto vytlacily subory z cache.

Taky jsem již dřív zkusil číst data z Ram disku, samostatné soubory a tam mi vyšla rychlost čtení 5GB/sec.
Jak si OS vytvoří keš v paměti a jak velkou ? Aktuálně mám obsazeno 5,3GB a 18GB volných .
Ještě rozpitvám jednotlivé části programu co je jak rychlé .
Trochu to sem nepatří ,když tak prosím moderátora o případné přesunutí , děkuji.

Doplnění:
Rozpitval jsem jednotlivé části a nejpomalejší je vykreslování 130msec 1600*1000 pix , těch 50 msec je pak na to ostatní, načtení a přepočty . Ale přesto mi uniká jak je to s tím čtením z disku ?