W dniu piątek, 29 marca 2013 11:41:56 UTC+1 użytkownik firr kenobi napisał:
> 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 )

w zasadzie to mozna tez tego nie olewac tylko
wtedy zrobi sie to ew konkurs na optymalizowanie
operacji wczytywania pliku z dysku - tez bardzo
ciekawa sprawa, w zasadzie to dla mnie wlasnie
nawet ciekawsze tyle ze nie znam sie na tym