W dniu 2010-02-19 10:37, Jacek Czerwinski pisze:
> Michal Schulz pisze:
>
>>
>> Nawet biorac pod uwage takie rzeczy rozwiazanie autora watku jest
>> nieekonomiczne :) Pomysl o tej calej masie konwersji
>> FloatToStr(StrToFloat() + StrToFloat()). Toz to paskudnie niewydajne
>> jest :)
>>
> i pieprzy zaokrągleniami, ale 'prawdziwy programista' itd...
>

moje uwagi były ogólne a nie dokładnie odnosiły się do tego przykładu

pozdr
Qbab

do góry

Qbab pisze:
> W dniu 2010-02-18 23:16, Michoo pisze:
>> Qbab pisze:
>>> Pamiętam czasy gdy upychanie kodu wynikało z konieczności, czasem
>>> upychało się dwie zmienne w jednym bajcie bo z góry wiedziało się ile
>>> bitów zajmą maksymalnie. Ale tego nie zrozumie nikt kto nie startował
>>> w czasach gdy komputery miały mniej niż 64 kilobajty pamięci :)
>> Nie przesadzasz trochę? Niedawno pisałem na ATiny2313, który ma 128
>> bajtów ramu. W C++. Z klasami.
>>
>
> chyba nie przesadzam, bo obstawiam że nie robiłeś na tym jakiegoś
> skomplikowanego dema z grafiką wektorową, muzyką itp. a o takie rzeczy
> mi chodziło. Wrzuć sobie na youtube i poszukaj dem z 8 bitowców, albo
> choć rzuć okiem na pecetową produkcję z cyklu intro 64kb
>
> http://www.youtube.com/watch?v=tCMo-bJQC8A

Co do 7Heaven to nie jestem pewien, ale to demo mialo z deka wiecej niz
64kb... Musiałbym poszperać po starych dyskach.

Zreszta tworzenie czegoś takiego na obecnych maszynach nie jest żadnym
wyczynem. Na 8bitowcach to się zgodze, na takim XL/XE w asm nie bylo
nawet mnozenia czy dzielenia sprzetowego... Tak to dopiero byla sztuka
zrobic coś podobnego. Tak komputer mial 64KB, ale czesc tego byla zajeta
przez system, pamiec ekranu itd itp. I te poszatkowane czesci pamieci
trzeba bylo uzywac.

pozdrawiam,
Przemek O.

--
www.soft-system.pl

do góry

Przemyslaw Osmanski <p...@s...soft-system.tnij.pl> wrote:

> > chyba nie przesadzam, bo obstawiam że nie robiłeś na tym jakiegoś
> > skomplikowanego dema z grafiką wektorową, muzyką itp. a o takie rzeczy
> > mi chodziło. Wrzuć sobie na youtube i poszukaj dem z 8 bitowców, albo
> > choć rzuć okiem na pecetową produkcję z cyklu intro 64kb
> >
> > http://www.youtube.com/watch?v=tCMo-bJQC8A
>
> Co do 7Heaven to nie jestem pewien, ale to demo mialo z deka wiecej niz
> 64kb... Musiałbym poszperać po starych dyskach.

Na pewno 64kB: http://www.pouet.net/prod.php?which=5

do góry

On 18 Lut, 10:20, Qbab <b...@p...onet.pl> wrote:
> W dniu 2010-02-11 08:57, Wojciech "Spook" Sura pisze:
>
> > Bastion wrote:
> >> Kolego, ja tak nie pisze tylko przedstawiam rozwiazanie pewnego
> >> problemu. Laskawie pochyl glowe i zastanow sie jak w 5 linijkach kodu
> >> lepiej mozna zwizualizowac rozwiazanie. Czekam na kod...
>
> > Zacznijmy od tego, że nawet nie zabierałbym się do projektowania aplikacji
> > myśląc panicznie, żeby zmieścić się w n linijkach. Płacisz podatek od każdej
> > napisanej linii kodu? Jeśli radość sprawia Ci upychanie programu w
> > niewielkiej przestrzeni, to raczej wyślij Twój pomysł na IOCCC niż chwal się
> > na grupach.
>
> Pamiętam czasy gdy upychanie kodu wynikało z konieczności, czasem
> upychało się dwie zmienne w jednym bajcie bo z góry wiedziało się ile
> bitów zajmą maksymalnie. Ale tego nie zrozumie nikt kto nie startował w
> czasach gdy komputery miały mniej niż 64 kilobajty pamięci :)

Koniecznosc upychania danych w bity jest caly czas akualna. Oczywiscie
tylko tam, gdzie wazna jest wydajnosc. Propoponuje zmierzenie czasu
wykonania tego kodu dla roznych wielkosci S. Parametr N zostaje taki
sam, wiec ilosc operacji nie ulega zmianie, zmianie ulega tylko
rozmiar
danych. Duze S oznacza dane nie upakowane, male S oznacza dane
upakowane do malej tablicy.

#define N (1<<30)
#define S (1024)

static double tab[S];

void init() {
for( int i=0 ; i<S ; i++ )
tab[i] = rand() % 16 - rand() % 16;
}

double test( ) {
double sum = 0;
int x = 0;
for( int i=0 ; i<N ; i++ ) {
x = (x + rand()) % S;
sum += tab[x];
}
return sum;
}

int main( int argc , char *argv[] ) {
srand(time(NULL));
init();
printf("sum = %lf\ntime = %u\n",test(),(unsigned int)clock());
return 0;
}

Pozdrawiam

do góry

Mariusz Marszałkowski pisze:
> On 18 Lut, 10:20, Qbab <b...@p...onet.pl> wrote:
>> W dniu 2010-02-11 08:57, Wojciech "Spook" Sura pisze:
>>
>>> Bastion wrote:
>>>> Kolego, ja tak nie pisze tylko przedstawiam rozwiazanie pewnego
>>>> problemu. Laskawie pochyl glowe i zastanow sie jak w 5 linijkach kodu
>>>> lepiej mozna zwizualizowac rozwiazanie. Czekam na kod...
>>> Zacznijmy od tego, że nawet nie zabierałbym się do projektowania aplikacji
>>> myśląc panicznie, żeby zmieścić się w n linijkach. Płacisz podatek od każdej
>>> napisanej linii kodu? Jeśli radość sprawia Ci upychanie programu w
>>> niewielkiej przestrzeni, to raczej wyślij Twój pomysł na IOCCC niż chwal się
>>> na grupach.
>> Pamiętam czasy gdy upychanie kodu wynikało z konieczności, czasem
>> upychało się dwie zmienne w jednym bajcie bo z góry wiedziało się ile
>> bitów zajmą maksymalnie. Ale tego nie zrozumie nikt kto nie startował w
>> czasach gdy komputery miały mniej niż 64 kilobajty pamięci :)
>
> Koniecznosc upychania danych w bity jest caly czas akualna. Oczywiscie
> tylko tam, gdzie wazna jest wydajnosc. Propoponuje zmierzenie czasu
> wykonania tego kodu dla roznych wielkosci S. Parametr N zostaje taki
> sam, wiec ilosc operacji nie ulega zmianie, zmianie ulega tylko
> rozmiar
> danych. Duze S oznacza dane nie upakowane, male S oznacza dane
> upakowane do malej tablicy.

Tu czytasz dane i to w najgorszy możliwy sposób - dostęp losowy. Odwrócę
kota ogonem - na 8 Xeonach:
$time ./kolo_siebie
real 0m16.903s
user 1m52.579s
sys 0m0.188s
$ time ./oddalone
real 0m1.955s
user 0m7.848s
sys 0m0.000s

To jest dokładnie ten sam kod, ale w jednym wypadku dane upakowane i
false-sharing daje o sobie znać, w drugim nie.


--
Pozdrawiam
Michoo

do góry

On 19 Lut, 22:48, Michoo <m...@v...pl> wrote:
> Mariusz Marszałkowski pisze:
>
>
>
> > On 18 Lut, 10:20, Qbab <b...@p...onet.pl> wrote:
> >> W dniu 2010-02-11 08:57, Wojciech "Spook" Sura pisze:
>
> >>> Bastion wrote:
> >>>> Kolego, ja tak nie pisze tylko przedstawiam rozwiazanie pewnego
> >>>> problemu. Laskawie pochyl glowe i zastanow sie jak w 5 linijkach kodu
> >>>> lepiej mozna zwizualizowac rozwiazanie. Czekam na kod...
> >>> Zacznijmy od tego, że nawet nie zabierałbym się do projektowania aplikacji
> >>> myśląc panicznie, żeby zmieścić się w n linijkach. Płacisz podatek od każdej
> >>> napisanej linii kodu? Jeśli radość sprawia Ci upychanie programu w
> >>> niewielkiej przestrzeni, to raczej wyślij Twój pomysł na IOCCC niż chwal się
> >>> na grupach.
> >> Pamiętam czasy gdy upychanie kodu wynikało z konieczności, czasem
> >> upychało się dwie zmienne w jednym bajcie bo z góry wiedziało się ile
> >> bitów zajmą maksymalnie. Ale tego nie zrozumie nikt kto nie startował w
> >> czasach gdy komputery miały mniej niż 64 kilobajty pamięci :)
>
> > Koniecznosc upychania danych w bity jest caly czas akualna. Oczywiscie
> > tylko tam, gdzie wazna jest wydajnosc. Propoponuje zmierzenie czasu
> > wykonania tego kodu dla roznych wielkosci S. Parametr N zostaje taki
> > sam, wiec ilosc operacji nie ulega zmianie, zmianie ulega tylko
> > rozmiar
> > danych. Duze S oznacza dane nie upakowane, male S oznacza dane
> > upakowane do malej tablicy.
>
> Tu czytasz dane i to w najgorszy możliwy sposób - dostęp losowy. Odwrócę
> kota ogonem - na 8 Xeonach:
> $time ./kolo_siebie
> real    0m16.903s
> user    1m52.579s
> sys     0m0.188s
> $ time ./oddalone
> real    0m1.955s
> user    0m7.848s
> sys     0m0.000s
>
> To jest dokładnie ten sam kod, ale w jednym wypadku dane upakowane i
> false-sharing daje o sobie znać, w drugim nie.

Nie wiem czy rozumiem, ten sam kod w wielu watkach?

Chcialem przypomniec troche inny fakt, a mianowicie ze
tej szybkiej pamieci w nowoczesnych komputerach nadal jest znacznie
mniej niz pamieci w ogole. Jesli algorytm nie dobiera sie do danych
sekwencyjnie, to caly czas najlepiej upakowac wszystkie dane tak,
aby zmiescily sie w niezbyt duzej pamieci cache.

W przypadku przetwarzania wieloprocesorowego sprawa komplikuje sie
jeszcze bardziej. Idealnie jesli kazdy watek moze miec swoja lokalna
kopie
danych, ale to nie jest zawsze mozliwe.

Pozdrawiam

do góry

Mariusz Marszałkowski pisze:
> On 19 Lut, 22:48, Michoo <m...@v...pl> wrote:

>> To jest dokładnie ten sam kod, ale w jednym wypadku dane upakowane i
>> false-sharing daje o sobie znać, w drugim nie.
>
> Nie wiem czy rozumiem, ten sam kod w wielu watkach?
8 wątków. W pierwszym przypadku trzymające swoje zmienne 'lokalne' w
globalnej tablicy o rozmiarze 8 a w drugim - na stosie.

>
> Chcialem przypomniec troche inny fakt, a mianowicie ze
> tej szybkiej pamieci w nowoczesnych komputerach nadal jest znacznie
> mniej niz pamieci w ogole. Jesli algorytm nie dobiera sie do danych
> sekwencyjnie, to caly czas najlepiej upakowac wszystkie dane tak,
> aby zmiescily sie w niezbyt duzej pamieci cache.
Zgadza się. Tylko sytuacja w której potrzebujemy dostęp losowy i dane
się mieszczą w cache nie jest specjalnie częsta... No i czasami lepiej
po prostu przeorganizować dane tak, żeby się dało je w pipeline użyć.
>
> W przypadku przetwarzania wieloprocesorowego sprawa komplikuje sie
> jeszcze bardziej. Idealnie jesli kazdy watek moze miec swoja lokalna
> kopie
> danych, ale to nie jest zawsze mozliwe.

Czyli właśnie rezygnujemy z oszczędzania pamięci na rzecz wydajności.


--
Pozdrawiam
Michoo

do góry

Użytkownik "Michoo" <m...@v...pl> napisał w wiadomości
news:hlf6va$78u$1@news.onet.pl...

> Mogłeś napisać "Jestem kiepskim programistą a będą mi płacić w kolejnych n
miesiącach 4k*(1.1)^n, możecie mi zazdrościć" - byłoby
> to tylko żałosne, ale ty wrzuciłeś bardzo kiepski kod, a jak cię zjechano za jego
jakość próbowałeś się nieudolnie bronić
> pogrążając jeszcze bardziej - tak zachowujących się ludzi określa się często mianem
wioskowych głupków.

E, widze ze grupa (w tym watku) uwarza mnie za
- masona
- malolata
- pseudo programiste
- neofite w programowaniu
- chwali piete
- czlowieka ktory bierze dragi (tudzierz triggery:))

Odpowiadam HURTEM:
Pierwszy kod w tym watku prawidlowo opisywal rzecywistosc.

do góry

Użytkownik "Jędrzej Dudkiewicz" <j...@g...com> napisał w wiadomości
news:hl0kss$u05$1@news.onet.pl...

> Konkrety? Czyli co? Chodzi mi o to, że używasz narzędzi pomyślanych do jednego celu
do osiągnięcia innego celu. I to używasz
> narzędzia gorszego niż dostępne.

Ciekawe pytanie.
Uwazam, ze nie powinno sie popadac w blad (fiksacji funkcjonalnej),
ktory zdaje sie popelniasz.
Srodowisko programowania moze byc np. sprawnym kalkulatorem.

do góry

Użytkownik "Jędrzej Dudkiewicz" <j...@g...com> napisał w wiadomości
news:hl410i$pb7$2@news.onet.pl...
> Bastion pisze:
>> Użytkownik "Jędrzej Dudkiewicz" <j...@g...com> napisał w
wiadomości news:hl0kss$u05$1@news.onet.pl...
>>
>>>> Podaj konrety.
>>> Konkrety? Czyli co? Chodzi mi o to, że używasz narzędzi pomyślanych do jednego
celu do osiągnięcia innego celu. I to używasz
>>> narzędzia gorszego niż dostępne.
>> Podaj konkrety
>
> Konkretnie, to używasz warstwy prezentacji do przechowywania danych i dokonujesz
zbędnych konwersji.

Panowie, poczytajcie o fiksacji funkcjonalnej.

do góry