Linking machine
Nie wiem czy nie piszę tego sam do siebie ale chciałem wyjaśnić parę rzeczy po wielomiesięcznych testach.
Gdzieś tu Nitro użył sformułowania "niby najszybszy loader wegiego" i mówił to w odniesieniu do loadera z flydecruncherem. Tak więc to, że można osiągnąć wysoki bitrate przy flydekompresji nie dowodzi niczego poza błędnym odczytaniem faktów. Otóż ja mogę sobie stworzyć MÓJ ABSTRAKCYJNY OBRAZEK i będzie to tylko literka "A" - jak nietrudno się domyśleć obrazek będzie ciągiem zer z wyłączeniem 8 bajtów reprezentujących literę "A" Przypuszczam, że jego skompresowana wersja zajmie mniej jak 200 bajtów czyli jeden blok gdzie faktycznie po dekompresji takiego "obrazka" dane zajmą 8KB. Zważywszy fakt, że obrazki mogą się różnie upakowywać lepiej i gorzej - korzystanie z takich statystyk i podpieranie się nimi wydaje się być co najmniej naciągane. Nawet się boję policzyć "wirtualną" prędkość ładowania danych "mojego" obrazka.
Testy moje wykazały największą wydajność w przypadku użycia właśnie nie któregoś z loaderów bongo ale deterministycznej wersji loadera ILTC czy DT zamieszczonego w trackmolinkerze 1.2. I mamy tutaj wielki problem, ponieważ ściera się tu nasze wygodnictwo z koniecznością kombinowania. Owszem - ten loader nie jest tak komfortowy w użyciu jak bongowe bo ma swoje słabe punkty jak $d011, sprajty, możliwość opóźnienia IRQ o 8 linii czy trochę więcej nawet. Tym nie mniej twierdzę, że dobry i nieleniwy koder jest w stanie bez większego wysiłku stworzyć dla niego optymalne warunki do ładowania i NIC SIĘ NIE STANIE jeżeli weźmie się pod uwagę fakt, że w niespełna 3.5 sekundy jest on w stanie dograć 80 bloków. Tak więc stworzenie "odpowiednich warunków" dla tego loadera i zachowanie płynności w demie jest możliwe co skull udowodnił w Dream Travel gdzie jeszcze prosiłem go "przytnij więcej rastra dla loadera bo efekt za szybko przelatuje" (chodziło o ten kubek). I prędkość tego loadera jest z całą pewnością porównywalna do loadera lft z flygcrdecode.
Teoria - "cudowności" flydecrunchingu - jest tu do ugrania właśnie trochę i wszystko tak naprawdę zależy od tego jakie są dane dogrywane. Jest ten moment, kiedy stacja odczytuje dane z dyskietki (załóżmy nawet, że flygcr) i to rzeczywiście chwilę trwa bo jak można policzyć 0.2 sec /21 da nam około pół ramki w praktyce więcej, bo jeszcze dochodzi czas częściowej konwersji do nybbli GCR - tak więc mamy ponad pół ramki i idealnie byłoby gdyby w tym czasie C64 nie oczekiwał bezczynnie tylko dekompresował uprzednio wgrany blok danych. I to jest idealna sytuacja jakkolwiek TEORETYCZNA. Ponieważ zachodzi tu pewien fenomen nazwałbym go "wytrącania sektorów z kolejki" w momencie, gdy dekompresja trwa dłużej niż ten "czas bezczynności" zaczynają "uciekać sektory z kolejki". Innymi słowy - przy dobrych warunkach bongoloader odczyta ścieżkę z przeplotem 6 co daje około 1.2 sekundy - jeśli nie będą się nakładały na to opóźnienia z C64. Ale w przypadku tych opóźnień, spowodowanych tym, że dekompresja ostatniego bloku danych zajęła więcej niż "idle time" sektory nie będą odczytywane w tej kolejności i tworzy się "loteria" taka, że zostaną odczytane w takiej kolejności na jaką pozwolą opóźnienia generowane przez C64. Wówczas odczyt danych ze ścieżki nie potrwa 1.2 sec ale np 1.5 sec. Bardzo dobrze widać to w demach do bongo gdzie w początkowej fazie dane są dekompresowane (mowa o testach "długiego" pliku będącym dokładnie tym samym co part2 ILTC) migusiem a w końcowej ze znacznym opóźnieniem. Suma sumarum najlepsze wyniki dały testy loadera z trackmolinkera i osobnym decruncherem. Może nie są to uzyski kolosalne bo rzędu 10% ale gwoli ścisłości TAK JEST.
Dziękuję za uwagę - tak sobie zatrolowałem
Gdzieś tu Nitro użył sformułowania "niby najszybszy loader wegiego" i mówił to w odniesieniu do loadera z flydecruncherem. Tak więc to, że można osiągnąć wysoki bitrate przy flydekompresji nie dowodzi niczego poza błędnym odczytaniem faktów. Otóż ja mogę sobie stworzyć MÓJ ABSTRAKCYJNY OBRAZEK i będzie to tylko literka "A" - jak nietrudno się domyśleć obrazek będzie ciągiem zer z wyłączeniem 8 bajtów reprezentujących literę "A" Przypuszczam, że jego skompresowana wersja zajmie mniej jak 200 bajtów czyli jeden blok gdzie faktycznie po dekompresji takiego "obrazka" dane zajmą 8KB. Zważywszy fakt, że obrazki mogą się różnie upakowywać lepiej i gorzej - korzystanie z takich statystyk i podpieranie się nimi wydaje się być co najmniej naciągane. Nawet się boję policzyć "wirtualną" prędkość ładowania danych "mojego" obrazka.
Testy moje wykazały największą wydajność w przypadku użycia właśnie nie któregoś z loaderów bongo ale deterministycznej wersji loadera ILTC czy DT zamieszczonego w trackmolinkerze 1.2. I mamy tutaj wielki problem, ponieważ ściera się tu nasze wygodnictwo z koniecznością kombinowania. Owszem - ten loader nie jest tak komfortowy w użyciu jak bongowe bo ma swoje słabe punkty jak $d011, sprajty, możliwość opóźnienia IRQ o 8 linii czy trochę więcej nawet. Tym nie mniej twierdzę, że dobry i nieleniwy koder jest w stanie bez większego wysiłku stworzyć dla niego optymalne warunki do ładowania i NIC SIĘ NIE STANIE jeżeli weźmie się pod uwagę fakt, że w niespełna 3.5 sekundy jest on w stanie dograć 80 bloków. Tak więc stworzenie "odpowiednich warunków" dla tego loadera i zachowanie płynności w demie jest możliwe co skull udowodnił w Dream Travel gdzie jeszcze prosiłem go "przytnij więcej rastra dla loadera bo efekt za szybko przelatuje" (chodziło o ten kubek). I prędkość tego loadera jest z całą pewnością porównywalna do loadera lft z flygcrdecode.
Teoria - "cudowności" flydecrunchingu - jest tu do ugrania właśnie trochę i wszystko tak naprawdę zależy od tego jakie są dane dogrywane. Jest ten moment, kiedy stacja odczytuje dane z dyskietki (załóżmy nawet, że flygcr) i to rzeczywiście chwilę trwa bo jak można policzyć 0.2 sec /21 da nam około pół ramki w praktyce więcej, bo jeszcze dochodzi czas częściowej konwersji do nybbli GCR - tak więc mamy ponad pół ramki i idealnie byłoby gdyby w tym czasie C64 nie oczekiwał bezczynnie tylko dekompresował uprzednio wgrany blok danych. I to jest idealna sytuacja jakkolwiek TEORETYCZNA. Ponieważ zachodzi tu pewien fenomen nazwałbym go "wytrącania sektorów z kolejki" w momencie, gdy dekompresja trwa dłużej niż ten "czas bezczynności" zaczynają "uciekać sektory z kolejki". Innymi słowy - przy dobrych warunkach bongoloader odczyta ścieżkę z przeplotem 6 co daje około 1.2 sekundy - jeśli nie będą się nakładały na to opóźnienia z C64. Ale w przypadku tych opóźnień, spowodowanych tym, że dekompresja ostatniego bloku danych zajęła więcej niż "idle time" sektory nie będą odczytywane w tej kolejności i tworzy się "loteria" taka, że zostaną odczytane w takiej kolejności na jaką pozwolą opóźnienia generowane przez C64. Wówczas odczyt danych ze ścieżki nie potrwa 1.2 sec ale np 1.5 sec. Bardzo dobrze widać to w demach do bongo gdzie w początkowej fazie dane są dekompresowane (mowa o testach "długiego" pliku będącym dokładnie tym samym co part2 ILTC) migusiem a w końcowej ze znacznym opóźnieniem. Suma sumarum najlepsze wyniki dały testy loadera z trackmolinkera i osobnym decruncherem. Może nie są to uzyski kolosalne bo rzędu 10% ale gwoli ścisłości TAK JEST.
Dziękuję za uwagę - tak sobie zatrolowałem
-
Sebaloz/Lepsi.De
- Posty: 3962
- Rejestracja: 14 wrz 2008, 00:02
determinizm
"ścisła zależność zdarzeń, zjawisk lub działań od określonych warunków"
Jak dla mnie jest niesłychana zależność pomiędzy wcześniejszą znajomością (lub nie) kolejności zapisanych sektorów co pozwala (lub nie) zrezygnować ze scanningu - ale ja to głupi jestem i nikt mnie nie chce zrozumieć
nawet sam wielki G
edit:
I chyba muszę się rozwinąć bo użyłem skrótu myślowego -
zjawiskiem jest prędkość odczytu danych z dyskietki (ze scaninngiem lub bez)
warunkiem - znajomość (bądź nieznajomość) kolejności zapisywanych sektorów
"ścisła zależność zdarzeń, zjawisk lub działań od określonych warunków"
Jak dla mnie jest niesłychana zależność pomiędzy wcześniejszą znajomością (lub nie) kolejności zapisanych sektorów co pozwala (lub nie) zrezygnować ze scanningu - ale ja to głupi jestem i nikt mnie nie chce zrozumieć
nawet sam wielki Gedit:
I chyba muszę się rozwinąć bo użyłem skrótu myślowego -
zjawiskiem jest prędkość odczytu danych z dyskietki (ze scaninngiem lub bez)
warunkiem - znajomość (bądź nieznajomość) kolejności zapisywanych sektorów