juz tu kiedys bylo wspominane, ale moge dodac
pare uwag na ten temat:

dokladnie nie kojarze jak to jest ale z grubsza
pod winda jest tak ze pamiec 'z punktu widzenia'
procesu jest pamiecia wirtualna (ciagly zakres
od zera w gore, nie wiem jak daleko ale powiedzmy
do 2GB) ktora sprzetowo jest 'mapowana' na pamiec
realna

powiedzmy ze 12 bitow z koncowki adresu jest
przekladane bezposrednio a wyzsze bity sa
translatowane przez tablice w ktorej mozna
ustawic dowolne zamapowanie

Zarazem denerwuje mnie ze mozna robic takie
niezwykle duzo dajace sztuczki a nie znane mi sa
reguly ktore okreslaja jakie sztuczki mozna robic -
nie konicznie przypuszczalbym np ze mozna cos
takiego tak zupelnie bezstratnie zrobic a tu prosze

pomysl pokusza sie jednak o rozszerzenie (o co
zachaczal nawet ostatnio jeden z grupowiczow (MS)
w jednym poscie pare tygodni temu - wspominam bo pamietam)

chodzi o to ze gdyby zerwac z obecnymi 'liniowymi'
(czy jak je nazwac) wskaznikami, i dac procesowi
do dyspozycji wskazniki w dwuczlonowej np postaci np
b:x to wykorzystujac podobne machanizmy przemapowywania
pamieci do obecnych mozna by miec do dyspozycji
mechanizmy resizowania tablic o prawie zerowym koszcie

ogolnie najprosciej by bylo by kazy malloc zwracal
unikalny identyfikator b (b od base) do kawalka pamieci
po ktorym mozna by adresowac przez x - to jak jest teraz
by odzielne alokowane kawalki ramu lezaly sekwencyjnie w jednym
kawale pamieci (i zabranialy sobie sie rozszerzac w tloku)
jest nikomu niepotrzebne, b moze zwrocic unikalny identyfikator
a x moze byc juz mapowane normalnie; dosyc proste a naprawde
potezny enhacement bo zmieniloby to cala algorytmike i wiele
rzeczy

w szczegolnosci rozwiazaloby mi pewne smutki z reallokiem w c2 ;-)

general kenobi












--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

> procesu jest pamiecia wirtualna (ciagly zakres
> od zera w gore, nie wiem jak daleko ale powiedzmy
> do 2GB)

konkretnie ta watpliwosc dotyczy tego czy proces (ktory
powiedzmy potencjalnie mozliwosc adresowania 2GB
wirtualnej pamieci albo i wiecej) mimo ze sam zuzywa
tylko np jedynie pierwszych 10 MB, moze adresowac
komorke np o adresie miliard czy tez moze ale
wczesniej musi ta pamiec sobie 'zaalokowac'
(i tez dwie opcje czy moze sobie zaalokowac np
tylko komorki w okolicach adresu miliard a nizszych nie
czy tez musi alokowac po kolei az zaalokuje caly gigabajt)



--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

W dniu 2011-11-10 12:09, fir pisze:
> ogolnie najprosciej by bylo by kazy malloc zwracal
> unikalny identyfikator b (b od base) do kawalka pamieci
> po ktorym mozna by adresowac przez x - to jak jest teraz
> by odzielne alokowane kawalki ramu lezaly sekwencyjnie w jednym
> kawale pamieci (i zabranialy sobie sie rozszerzac w tloku)
> jest nikomu niepotrzebne, b moze zwrocic unikalny identyfikator
> a x moze byc juz mapowane normalnie; dosyc proste a naprawde
> potezny enhacement bo zmieniloby to cala algorytmike i wiele
> rzeczy

Z punktu widzenia programisty ideałem jest ciągły obszar pamięci i
koniec tematu. Starym programistom do dziś segmentacja jawi się jako
koszmar. Realloc jest ci do niczego potrzebny. Rozwiąż sobie rosnące
tablice w inny sposób.

artur

do góry

> Starym programistom do dziś segmentacja jawi się jako
> koszmar.

dlaczego konkretnie? nie calkiem to pamietam, pamietam
ze jesli chodzi o PC/640KB faktycznie bylo to b brzydkie,
ale bylo to tez cos innego, segmenty i offsety byly
przemieszane w jednym obszarze, tutajbylo by y zupelnie
niezaleznych pul, z punktu widzenia programu w c nie
zmienilo by sie zawiele wskazniki mialyby troche inną
arytmetyke czy tez raczej byly by 'dwa'; mz z czasem sie
to raczej przyjmie bo korzysci sa duze






--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

<f...@g...pl> napisał(a):

> > Starym programistom do dziś segmentacja jawi się jako
> > koszmar.
>
> dlaczego konkretnie? nie calkiem to pamietam, pamietam
> ze jesli chodzi o PC/640KB faktycznie bylo to b brzydkie,
> ale bylo to tez cos innego, segmenty i offsety byly
> przemieszane w jednym obszarze, tutajbylo by y zupelnie
> niezaleznych pul, z punktu widzenia programu w c nie
> zmienilo by sie zawiele wskazniki mialyby troche inną
> arytmetyke czy tez raczej byly by 'dwa'; mz z czasem sie
> to raczej przyjmie bo korzysci sa duze
>
>
w sumie to i obecnie mozna by miec szybkie realloki korzystajac
z tego rze virtualna przestrzen adresowa jest duza, trzebaby
w mallocu podawac dwie liczby alokowany ram i rezerwe, np

char* data = malloc(2 000, 1 000 000);

realnie zaalokowane byloby 2000 bajtow (czyli jedna strona 4k)
ale przestrzen adresowa za tym az do 1 000 000 bylaby
zarezerwowana, tym samym realloki az do 1 000 000 byly by
bardzo tanie (chcialo by sie powiedziec instant ale nie jestem
pewien jakie operacje tam trzeba wykonywac aby dodac (czy jak
oni chyba mowia 'zakomitowac' dodatkowe strony w ramie)

np realokowanie data z 2k do 60k to 'zakomitowanie' 15 stron
- czy jest to szybka operacja ? ktos wie dokladnie?

powinno to byc zrobione by bylo szybkie - raczej da sie to
zrobic i wtedy nie trzeba sie martwic realloki i rozciagliwe
tablice - jest to mozliwe



--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

On 11-11-2011 08:48, f...@g...pl wrote:
> <f...@g...pl> napisał(a):
>
>>> Starym programistom do dziś segmentacja jawi się jako
>>> koszmar.
>>
>> dlaczego konkretnie? nie calkiem to pamietam, pamietam
>> ze jesli chodzi o PC/640KB faktycznie bylo to b brzydkie,
>> ale bylo to tez cos innego, segmenty i offsety byly
>> przemieszane w jednym obszarze, tutajbylo by y zupelnie
>> niezaleznych pul, z punktu widzenia programu w c nie
>> zmienilo by sie zawiele wskazniki mialyby troche inną
>> arytmetyke czy tez raczej byly by 'dwa'; mz z czasem sie
>> to raczej przyjmie bo korzysci sa duze
>>
>>
> w sumie to i obecnie mozna by miec szybkie realloki korzystajac
> z tego rze virtualna przestrzen adresowa jest duza, trzebaby
> w mallocu podawac dwie liczby alokowany ram i rezerwe, np
>
> char* data = malloc(2 000, 1 000 000);
>
> realnie zaalokowane byloby 2000 bajtow (czyli jedna strona 4k)
Ciekawi mnie bardzo skad Ci sie wzielo ze strona 4k ma 2000 bajtow ?

> ale przestrzen adresowa za tym az do 1 000 000 bylaby
> zarezerwowana, tym samym realloki az do 1 000 000 byly by
No i po to jest programista, aby w/w implementowal tak gdzie jest taka
potrzeba. Bo przewaznie nie ma.

> bardzo tanie (chcialo by sie powiedziec instant ale nie jestem
> pewien jakie operacje tam trzeba wykonywac aby dodac (czy jak
> oni chyba mowia 'zakomitowac' dodatkowe strony w ramie)
>
> np realokowanie data z 2k do 60k to 'zakomitowanie' 15 stron
> - czy jest to szybka operacja ? ktos wie dokladnie?
>
> powinno to byc zrobione by bylo szybkie - raczej da sie to
> zrobic i wtedy nie trzeba sie martwic realloki i rozciagliwe
> tablice - jest to mozliwe
>
Tak dokladnie dziala stos na windows.


Pozdrawiam

Marek

do góry

Marek Borowski <m...@b...com> napisał(a):

> On 11-11-2011 08:48, f...@g...pl wrote:
> > <f...@g...pl> napisał(a):
> >
> >>> Starym programistom do dziś segmentacja jawi się jako
> >>> koszmar.
> >>
> >> dlaczego konkretnie? nie calkiem to pamietam, pamietam
> >> ze jesli chodzi o PC/640KB faktycznie bylo to b brzydkie,
> >> ale bylo to tez cos innego, segmenty i offsety byly
> >> przemieszane w jednym obszarze, tutajbylo by y zupelnie
> >> niezaleznych pul, z punktu widzenia programu w c nie
> >> zmienilo by sie zawiele wskazniki mialyby troche inną
> >> arytmetyke czy tez raczej byly by 'dwa'; mz z czasem sie
> >> to raczej przyjmie bo korzysci sa duze
> >>
> >>
> > w sumie to i obecnie mozna by miec szybkie realloki korzystajac
> > z tego rze virtualna przestrzen adresowa jest duza, trzebaby
> > w mallocu podawac dwie liczby alokowany ram i rezerwe, np
> >
> > char* data = malloc(2 000, 1 000 000);
> >
> > realnie zaalokowane byloby 2000 bajtow (czyli jedna strona 4k)
> Ciekawi mnie bardzo skad Ci sie wzielo ze strona 4k ma 2000 bajtow ?
>
> > ale przestrzen adresowa za tym az do 1 000 000 bylaby
> > zarezerwowana, tym samym realloki az do 1 000 000 byly by
> No i po to jest programista, aby w/w implementowal tak gdzie jest taka
> potrzeba. Bo przewaznie nie ma.
>
> > bardzo tanie (chcialo by sie powiedziec instant ale nie jestem
> > pewien jakie operacje tam trzeba wykonywac aby dodac (czy jak
> > oni chyba mowia 'zakomitowac' dodatkowe strony w ramie)
> >
> > np realokowanie data z 2k do 60k to 'zakomitowanie' 15 stron
> > - czy jest to szybka operacja ? ktos wie dokladnie?
> >
> > powinno to byc zrobione by bylo szybkie - raczej da sie to
> > zrobic i wtedy nie trzeba sie martwic realloki i rozciagliwe
> > tablice - jest to mozliwe
> >
> Tak dokladnie dziala stos na windows.
>

to powinno byc zrobione dla mallokow ("malloc(data, rezerwa)")
i postepujace realloki powinny byc zrobione szybko (chyba daloby
sie zrobic bo to wymaga tylko malego przygrzebania w tym
translatorze adresu ) np rzedu okolo 1 mikrosekundy - a obawiam
sie ze nie jest zrobione a wielka szkoda





--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry