On Thursday, December 3, 2015 at 5:45:16 PM UTC+1, witek wrote:
> zmienic algorytm.
Mam też pytanie. Powiedz mi: jeśli mam dane, które nie mieszczą się w
pamięci RAM, więc nie mogę ich do niej wczytać, to jak mam zmienić
algorytm, aby po tej zmianie się zmieściły?

Pozdrawiam

do góry

M.M. wrote:
> On Thursday, December 3, 2015 at 5:45:16 PM UTC+1, witek wrote:
>> M.M. wrote:
>>> On Thursday, December 3, 2015 at 4:21:31 PM UTC+1, witek wrote:
>>>> M.M. wrote:
>>>>> Generalnie wtedy kiedy chcemy oszczędzać pamięć
>>>>
>>>>
>>>> to chyba ostatnie z zastosowań jak się już komuś bardzo nudzi.
>>>
>>> To co innego może zrobić ktoś, komu dane nie mieszczą się w
>>> pamięci?
>>>
>>
>> zmienic algorytm.
>> po za tym w jaki sposob wielkosc danych ma sie do faktu do czego stosuje
>> sie pragma pack?
>
> #include <cstdio>
>
> struct X1 {
> int c;
> char a;
> };
>
>
> #pragma push
> #pragma pack(1)
> struct X2 {
> int c;
> char a;
> };
> #pragma pop
>
>
> int main(int argc, char *argv[])
> {
> static X1 x1[1000];
> static X2 x2[1000];
>
> printf("sizeof(x1)==%u\n" , (sizeof(x1) ) );
> printf("sizeof(x2)==%u\n" , (sizeof(x2) ) );
>
> return 0;
> }
>
> U mnie taki wynik:
> sizeof(x1)==8000
> sizeof(x2)==5000
>
> Pozdrawiam
>
>
>
>

odpowiedz nie na temat bo nie zrozumiales pytania.

do góry

M.M. wrote:
> On Thursday, December 3, 2015 at 5:45:16 PM UTC+1, witek wrote:
>> zmienic algorytm.
> Mam też pytanie. Powiedz mi: jeśli mam dane, które nie mieszczą się w
> pamięci RAM, więc nie mogę ich do niej wczytać, to jak mam zmienić
> algorytm, aby po tej zmianie się zmieściły?
>
> Pozdrawiam
>

a po co sie uparles, ze musisz miec wszystkie dane w pamieci?
Zmian algorytm na taki, ktory potrafi operować na części danych, takich,
ktore mieszczą się w pamięci, zamiast na całości.

w ostatecznosci zwieksz ilosc dostepnej pamieci.

do góry

On Thursday, December 3, 2015 at 6:40:32 PM UTC+1, witek wrote:
> M.M. wrote:
> > On Thursday, December 3, 2015 at 5:45:16 PM UTC+1, witek wrote:
> >> zmienic algorytm.
> > Mam też pytanie. Powiedz mi: jeśli mam dane, które nie mieszczą się w
> > pamięci RAM, więc nie mogę ich do niej wczytać, to jak mam zmienić
> > algorytm, aby po tej zmianie się zmieściły?
> >
> > Pozdrawiam
> >
>
> a po co sie uparles, ze musisz miec wszystkie dane w pamieci?
> Zmian algorytm na taki, ktory potrafi operować na części danych, takich,
> ktore mieszczą się w pamięci, zamiast na całości.
> w ostatecznosci zwieksz ilosc dostepnej pamieci.
Dziękuję za dobre rady.

do góry

W dniu 2015-12-03 16:08, M.M. pisze:
> On Thursday, December 3, 2015 at 3:05:24 PM UTC+1, Tomasz Kaczanowski wrote:
>> W dniu 2015-12-03 15:00, M.M. pisze:
>>> On Thursday, December 3, 2015 at 2:34:00 PM UTC+1, Tomasz Kaczanowski wrote:
>>>> W dniu 2015-12-03 14:08, M.M. pisze:
>>>>> On Thursday, December 3, 2015 at 1:09:14 PM UTC+1, Tomasz Kaczanowski wrote:
>>>>>
>>>>>> i gdzieniegdzie będzie mały bum, bo *((int*)(buf+2)); może mieć zdziebko
>>>>>> inną zawartość, niż nam się wydaje,
>>>>>
>>>>> Nie rozumiem. W jakich sytuacjach może mieć inną zawartość? Na moje
>>>>> albo reprezentacja bitowa się zgadza, albo nie. Jeśli nie, to w
>>>>> ogóle nie można używać kopiowania bitów.
>>>>
>>>> Tam gdzie zmienne muszą mieć wyrównane adresy. O ile w przypadku
>>>> spakowanej struktury przy odczycie kompilator wykona za nas odpowiednie
>>>> operacje, to w takim przypadku, gdy rzutujesz dane spod adresu, mówisz
>>>> kompilatorowi "wiem co robię, nie wtrącaj się", a, że wynik może w takim
>>>> przypadku być inny, cóż...
>>>
>>> To przy operacji:
>>> *((int*)(buf+2))
>>> kompilator nie wygeneruje takiego samego kodu jak przy wypakowaniu
>>> inta przesuniętego o 2 bajty w strukturze? Myślałem że na danej
>>> platformie kompilator bezpiecznie przerzuci dane na wyrównany adres i
>>> dopiero potem zacznie operować na tych danych.
>>
>>
>> z doświadczenia wiem, że nie poprawne było dopiero
>>
>> int zmienna;
>> memcpy(zmienna, (buf+2), sizeof(int));
>
>
> Jeśli wcześniej było:
> memcpy( buf+2 ,&zmienna , sizeof(int) );
> To też nie widzę zagrożenia. Rozmawiamy rzecz jasna o zgodnym formacie
> na poziomie bitów.

Cały czas zakładam zgodność bitów i endianów, bo inaczej żadne z tych
nie byłoby prawidłowe.

> Gdy ktoś upakował dane przy pomocy memcpy, a potem odzyskuje przez:
> *((int*)(buf+2))
> to obawiam się, że nie zawsze zadziała, o ile się nie mylę, to zadziała
> tylko na bigendian.

Nie - to zadziała, tam, gdzie jedyne wyrównanie odnośnie adresów dla
zmiennych jest adres parzysty, a to nie musi być prawdą. Przykład
częściej wysypujący się, to jeśli pierwsza dana będzie char, a następna
int. Wtedy będzie nieparzysty adres i na większej ilości
systemów/sprzętów zadziała to nieprawidłowo. Endianowość może co
najwyżej zmniejszyć efekt w niektórych wypadkach, ale nie zagwarantuje
ogólnie poprawnego działania.

Oczywiście pomijam fakt, ze wszelkie struktury transportowe winno raczej
opisywać się przez int32_t itp, wtedy mamy przynajmniej wielkość
zagwarantowaną.


--
Kaczus
http://kaczus.ppa.pl

do góry

> Rozmawialiśmy o
> szczególikach, typu:
> 1) można się przejechać na big/lit endian
> 2) najpierw memcpy, potem operator rzutowania
> 3) różny padding w strukturach
> 4) różny rozmiar inta na różnych platformach lub wersjach programu.

Właśnie te szczególiki powodują, że te triki to złe rozwiązania.

> aktywne unikanie tego ryzyka zajmuje
> czas. Zobacz jak łatwo rypnąć się po poprawce pól w strukturze.

Jeśli problemem jest czas lub poprawki pól w strukturach (ale przecież protokół miał
być znany?), to taki kod można wygenerować. Po to są standardy w rodzaju ASN.1 i jemu
podobne. Albo nawet niestandardowe, ale poręczne wynalazki typu MessagePack.
Co do czasu - ogólnie, pisanie poprawnych programów może zająć więcej czasu, niż
niepoprawnych. Ale akurat poprawna obsługa protokołu sieciowego to jest jedno z tych
miejsc, gdzie oszczędność czasu na etapie kodowania się nie opłaca.

--
Maciej Sobczak * http://www.inspirel.com

do góry

On Friday, December 4, 2015 at 2:18:45 PM UTC+1, Maciej Sobczak wrote:
> > Rozmawialiśmy o
> > szczególikach, typu:
> > 1) można się przejechać na big/lit endian
> > 2) najpierw memcpy, potem operator rzutowania
> > 3) różny padding w strukturach
> > 4) różny rozmiar inta na różnych platformach lub wersjach programu.
>
> Właśnie te szczególiki powodują, że te triki to złe rozwiązania.

Mają swoje zalety. Gdy mam dużą strukturę, którą będę modyfikował w
przyszłości i gdy użyję:
write( &struct , sizeof(struct) , 1 )
to:
1) w jednej linii kodu zapisuję/odczytuję całą strukturę.
2) strukturę mogę dowolnie modyfikować, a zapis i odczyt zawsze
zadziała.


> > aktywne unikanie tego ryzyka zajmuje
> > czas. Zobacz jak łatwo rypnąć się po poprawce pól w strukturze.
>
> Jeśli problemem jest czas lub poprawki pól w strukturach (ale przecież protokół
miał być znany?), to taki kod można wygenerować. Po to są standardy w rodzaju ASN.1 i
jemu podobne. Albo nawet niestandardowe, ale poręczne wynalazki typu MessagePack.
> Co do czasu - ogólnie, pisanie poprawnych programów może zająć więcej czasu, niż
niepoprawnych. Ale akurat poprawna obsługa protokołu sieciowego to jest jedno z tych
miejsc, gdzie oszczędność czasu na etapie kodowania się nie opłaca.

Zgodzę się z Tobą, ale tylko w przypadku bardzo dużych aplikacji. W mały i w
średnich programach to co proponujesz moim zdaniem jest przerostem
formy nad treścią.

Pozdrawiam

do góry

W dniu 2015-12-04 21:26, M.M. pisze:
> On Friday, December 4, 2015 at 2:18:45 PM UTC+1, Maciej Sobczak wrote:
>>> Rozmawialiśmy o
>>> szczególikach, typu:
>>> 1) można się przejechać na big/lit endian
>>> 2) najpierw memcpy, potem operator rzutowania
>>> 3) różny padding w strukturach
>>> 4) różny rozmiar inta na różnych platformach lub wersjach programu.
>>
>> Właśnie te szczególiki powodują, że te triki to złe rozwiązania.
>
> Mają swoje zalety. Gdy mam dużą strukturę, którą będę modyfikował w
> przyszłości i gdy użyję:
> write(&struct , sizeof(struct) , 1 )
> to:
> 1) w jednej linii kodu zapisuję/odczytuję całą strukturę.
> 2) strukturę mogę dowolnie modyfikować, a zapis i odczyt zawsze
> zadziała.

Zapis działa zawsze, odczyt - zależnie, czy odczytujemy ten co przed
chwilą zapisaliśmy, czy może kompilowany wcześniej... Oczywiście ma
swoje zalety i jest stosowany, ale jednak do stwierdzenia "zawsze
działa" podchodziłbym jednak z pewną ostrożnością :)


--
Kaczus
http://kaczus.ppa.pl

do góry

On Monday, December 7, 2015 at 10:14:16 AM UTC+1, Tomasz Kaczanowski wrote:
> W dniu 2015-12-04 21:26, M.M. pisze:
> > On Friday, December 4, 2015 at 2:18:45 PM UTC+1, Maciej Sobczak wrote:
> >>> Rozmawialiśmy o
> >>> szczególikach, typu:
> >>> 1) można się przejechać na big/lit endian
> >>> 2) najpierw memcpy, potem operator rzutowania
> >>> 3) różny padding w strukturach
> >>> 4) różny rozmiar inta na różnych platformach lub wersjach programu.
> >>
> >> Właśnie te szczególiki powodują, że te triki to złe rozwiązania.
> >
> > Mają swoje zalety. Gdy mam dużą strukturę, którą będę modyfikował w
> > przyszłości i gdy użyję:
> > write(&struct , sizeof(struct) , 1 )
> > to:
> > 1) w jednej linii kodu zapisuję/odczytuję całą strukturę.
> > 2) strukturę mogę dowolnie modyfikować, a zapis i odczyt zawsze
> > zadziała.
>
> Zapis działa zawsze, odczyt - zależnie, czy odczytujemy ten co przed
> chwilą zapisaliśmy, czy może kompilowany wcześniej... Oczywiście ma
> swoje zalety i jest stosowany, ale jednak do stwierdzenia "zawsze
> działa" podchodziłbym jednak z pewną ostrożnością :)

Wyraziłem się dwuznacznie. Chodziło o to, że ten wiersz zadziała zawsze:
write( &strukt , sizeof(strukt) , file );
Pozdrawiam

do góry

> Wyraziłem się dwuznacznie. Chodziło o to, że ten wiersz zadziała zawsze:
> write( &strukt , sizeof(strukt) , file );

Ale nie płacą nam za zapisy, tylko za odczyty (to było w dowcipie o backupach). :-)

U mnie też jest jeden wiersz:

serialize(&struct, file);

Nawet krócej. I wiem, że nie jestem zależny od pierdyliona rzeczy, nad którymi mogę
nie mieć kontroli (endiany, opcje kompilatora, itd.).

--
Maciej Sobczak * http://www.inspirel.com

do góry