W dniu czwartek, 28 marca 2013 23:55:08 UTC+1 użytkownik bartekltg napisał:
> W dniu 2013-03-28 21:50, Michoo pisze:
>
>
>
> >
>
> > W znanych mi implementacjach tak - jest automat zjadający wejście i
>
> > wypluwający wyjście (pobierając/zapisując kolejne rekordy ze stosu)
>
> > (hmmm, ciekawe, czy printf jest turing complete ;) ).
>
>
>
> To nie linuksowy edytor tekstu;-)
>
>
>
>
>
> >>
>
> >>> No chyba, ze extreme: jak po linuxem to można użyć czystego read albo
>
> >>> jeszcze lepiej mmap
>
> >>
>
> >> W przykładzie który widziałem (właśnie z takich konkursików)
>
> >> gość użył fgets + bufor + własne przerabianie na liczby.
>
> >
>
> > Na potyczkach używałem kiedyś atoi - jest dostatecznie szybkie. fgets ma
>
> > jedną dodatkową wartwę po drodze do read.
>
>
>
>
>
> O jakim dokładnie read mówisz? w stdio nic takiego nie widzę.
>
>
>
>
>
> >> U nas tablica mieszająca i tak pewnie zasłoniłaby swoim czasem
>
> >> działania szczegóły wczytywania.
>
> >
>
> > Dla takich problemów dobra funkcja mieszająca to taka, która działa
>
> > możliwie liniowo. Zrobiłbym wektor wskaźników na funkcję do wykrywania
>
> > końca linii i lookup do robienia to_lower - w takiej konfiguracji
>
> > czytanie bajt-po-bajcie kontra czytanie blokami da duuużą różnicę.
>
>
>
> "wektor wskaźników do wykrywania końca linii"?
>
>
>
>
>
> >>> Trzeba zrobić szybkie lower/upper (pewnie lookup table, nieduże w
>
> >>> sumie).
>
> >>
>
> >> O zapomnialem o tym. Tablica na 256 elementów to nie problem,
>
> >
>
> > O ile wejście jest 8-bit/znak - wtedy użyłbym w sumie jumptable.
>
>
>
> Nie wyjdzie z grubsza na to samo? A 256 bajtów pewnie ładnie
>
> się blisko procesora zmieści.
>
>
>
>
>
> >> a dzieki temu za darmo mamy utożsamienie wszystkich białych
>
> >> znaków, interpunkcji etc.
>
> >
>
> > 256*4/8bajty na wskaźnik całkiem nieźle rezyduje w cache. O ile tylko
>
> > jumptable nie zepsuje za bardzo pipeline to powinna wymiatać.
>
>
>
> Nadal nie widzę przewagi. Może nie wiem, co dokładnie masz na myśli.
>
>
>
>
>
> > Tak w ogóle teraz mnie deadline ścigają ale za jakieś 2 tygodnie to może
>
> > skrobnę programik - będzie można zrobić konkurs ;)
>
>
>
> Można zrobić. Teraz święta, a 2 tygodnie to i pewnie firowy
>
> konkurs minie. Tylko skoro potępiłeś maszynkę, trzeba będzie
>
> jakoś to sprawiedliwie mierzyć;)
>
>
>
> Jakiś zestaw ebooków się znajdzie;)
>

co do czytania z pliku to mysle ze mozna to
olać bo (jak mysle) czas odczytania tego z dysku
wlasnie bedzie zapewne wiekszy (?) niz czas wykonania
samej kalkulacji

jaki jest 'zamortyzowany' ;) koszt odczytania
jednego bajta/kilobajta/megabajta z dysku ?
dla megabajta (powiedzmy ze ksiazka wejsciowa)
to byloby pewnie rzedu (uwaga grube oszacowanie
bo nie bardzo wiem;) z 1/50 sekundy (= 20 ms)
pewnie w praktyce - ten rozruch glowicy itp
to powodowaloby ze jest to wiecej 50-100, 200 ms?

jesli 200 ms to same obliczenia mz powinny trwac mniej niz tyle (bo ja bym ozacowal
ze te obliczenia
powinny sie chyba wyrobic pod 50 ms - ale tez zgrubne oszacowanie )