"J.F." <j...@p...onet.pl> wrote in message
news:2dgiwzv7sbct$.j9yg212mfi9t$.dlg@40tude.net...
> Dnia Sat, 21 Feb 2015 10:46:44 +0100, Marek napisał(a):
>> On Sat, 21 Feb 2015 09:16:10 +0100, "J.F."
>>> i programy dzialaja "prosto z dysku" ?
>>
>> Skąd w ogóle taki pomysł??
>
> No wiesz, gdyby pamiec flash byla szybka i podpieta bezposrednio pod
> magistrale, to czemu nie ?
> Po co przepisywac do RAM ?
>
> Oczywiscie jeszcze pare rzeczy musi byc zapewnionych ...

No... np. brak konieczności kasowania całego sektora,
czyli chcesz z flash zrobić DRAM lub SRAM :-)

do góry

Dnia Sat, 21 Feb 2015 09:20:52 -0600, Pszemol napisał(a):
> "J.F." <j...@p...onet.pl> wrote in message
>>> Skąd w ogóle taki pomysł??
>>
>> No wiesz, gdyby pamiec flash byla szybka i podpieta bezposrednio pod
>> magistrale, to czemu nie ?
>> Po co przepisywac do RAM ?
>> Oczywiscie jeszcze pare rzeczy musi byc zapewnionych ...
>
> No... np. brak konieczności kasowania całego sektora,
> czyli chcesz z flash zrobić DRAM lub SRAM :-)

Nie, ja nie chce zastepowac RAM, ja chce dodatkowo podlaczyc pamiec
flash bezposrednio.

Procesor musi byc 64-bit, zeby wspolczesne "dyski" podlaczyc
bezposrednio, jakies tryby adresacji wzglednej pewnie by sie przydaly,
zeby program bez zmian mogl sie wykonywac spod adresu gdzie sie
przypadkiem znajdzie. Byc moze pamiec wirtualna.


J.

do góry

"J.F." <j...@p...onet.pl> wrote in message
news:wq2srfqqbeyx$.wx33oy7durdk.dlg@40tude.net...
> Dnia Sat, 21 Feb 2015 09:20:52 -0600, Pszemol napisał(a):
>> "J.F." <j...@p...onet.pl> wrote in message
>>>> Skąd w ogóle taki pomysł??
>>>
>>> No wiesz, gdyby pamiec flash byla szybka i podpieta bezposrednio pod
>>> magistrale, to czemu nie ?
>>> Po co przepisywac do RAM ?
>>> Oczywiscie jeszcze pare rzeczy musi byc zapewnionych ...
>>
>> No... np. brak konieczności kasowania całego sektora,
>> czyli chcesz z flash zrobić DRAM lub SRAM :-)
>
> Nie, ja nie chce zastepowac RAM, ja chce dodatkowo podlaczyc pamiec
> flash bezposrednio.
>
> Procesor musi byc 64-bit, zeby wspolczesne "dyski" podlaczyc
> bezposrednio, jakies tryby adresacji wzglednej pewnie by sie przydaly,
> zeby program bez zmian mogl sie wykonywac spod adresu gdzie sie
> przypadkiem znajdzie. Byc moze pamiec wirtualna.

Duże procesory 64-bitowe już od dawna nie są bezpośrednio
sprzęgane z pamięcią - oddzielone są od niej przez memory manager.

do góry

Dnia Sat, 21 Feb 2015 09:19:59 -0600, Pszemol napisał(a):
> "J.F." <j...@p...onet.pl> wrote in message
>>>> Sandisk sie chwali kartami 280MB/s ... nie wiem jak, ale to ponizej
>>>> 4ns/byte.
>>> No ale oblicz sobie jak się to ma do procesora taktowanego 1,6GHz?
>>
>> Ale to jakies 1/3 DDR2 DRAM. Nie wiem jak w srodku zorganizowane,
>> ale jakby spojrzec tylko na transfery, do oszczedniejszych procesorow
>> powinno wystarczyc, oczywiscie z wykorzystaniem ich szybkiego cache.
>> Najwyzej da sie kilka sztuk rownolegle :-)
>
> No ale Sandisk mówi o transferze strumieniowym a nie czasie
> zapisu jednego słowa 32-bitowego w losowym miejscu gdzie
> trzeba skasować cały sektor pamięci.
> Pamięć cache Ci tu niewiele pomoże - one pracują z DRAM
> i do pracy w DRAM są optymalizowane, nie z pamięcią flash.

Ale DRAM tez czas pierwszego dostepu maja dlugi, dopiero nastepne
slowa sa dostepne szybko. Cache z tego korzysta.

>>>>> Otóż to. I teraz pytanie za 10 punktów: Android uruchamia
>>>>> takiego klienta facebooka czy google+ wprost z pamięci masowej
>>>>> czy jednak przepisuje go przed uruchomieniem, jak pecet, do RAMu?
>>>>
>>>> Android. Klient jest w Javie/Dalviku, trzeba go zaladowac z technika
>>>> JIT ... i dobrze, bo Flash moze nie byc podpiety pod magistrale.
>>>>
>>>> Moglby sie tak Linux wykonywac, biblioteki maszyny wirtulnej ...
>>>
>>> No to sami już wiecie czemu takie skomplikowane tematy z pamięcią macie.
>>
>> Czemu ?
>> Myslisz ze w Apple wyglada to inaczej, flash podpiety pod magistrale,
>> i programy dzialaja "prosto z dysku" ?
>
> Skąd to wnioskujesz? Ja pisałem o Dalviku.

No to czemu ten przytyk ?
Dalvik czy Apple - na razie i tak program jest z "dysku" ladowany i
problemy z partycjami te same.

J.

do góry

Dnia Sat, 21 Feb 2015 15:08:54 +0100, Marek napisał(a):
> On Sat, 21 Feb 2015 11:45:27 +0100, "J.F."
>> No wiesz, gdyby pamiec flash byla szybka i podpieta bezposrednio pod
>> magistrale, to czemu nie ?
>> Po co przepisywac do RAM ?
>
> Jeśli flash stanie się w przeszłości tak samo szybki jak ram i będzie
> miał nieograniczoną liczbę zapisów to stanie się po prostu ramem
> nieulotnym, wtedy pogadamy.

Ja nie chce zastepowac RAM - ja tylko chce uruchamiac programy
bezposrednio z pamieci flash, bedacej jednoczesnie "dyskiem".

> Ale problem z implementacja modelu "one memory" (bez kopiowania) nie
> jest w wolnym nośniku jakim jest flash ale w zarządzaniu i
> dystrybucji binariów.
> Aktualnie używane architektury cpu oraz kerneli nie wspierają takich
> pomysłów.
> Warstwa abstrakcji pomiędzy fs gdzie są binarki a (wirtualną)
> przestrzenią adresową cpu byłaby niepotrzebnym overkillem.

Nie wspieraja, bo zawsze byl prawdziwy dysk, i nie bylo innej
mozliwosci.
A ten overkill .. na oko to standardowa implementacja pamieci
wirtualnej powinna sobie poradzic.

> Zachowanie swobodnej i prostej wymiany binarek jako plików w fs (jak
> jest teraz) byłoby bardzo tudne w takiej implementacji. Szybciej i
> prościej jest ładować binarki (najczęściej tylko potrzebne ich
> fragmenty) do osobnej pamięci (ram) i tam nimi zarządzać.

Ale, pomijajac predkosc, po co je ladowac, jesli one tam juz sa ?

> Jest dziesiątki powodów, dla których kernel musi mieć procesy w
> "osobnej" pamięci (co implikuje kopiowanie z miejsca gdzie binarka
> "jest" jako kod a gdzie ma być "uruchamiana"). Stronicowanie, wymiana
> stron z swapem, prostrze (gdy są w ram) zarządzanie ochroną stron
> itd, itp. To co opisujesz bliskie jest arch. harvardzkiej,, która
> nadaje się do mikrokontrolera ale nie do implementacji współczesnego
> kernela ze wszystkimi szykanami.

Jestes pewien ? Unix sobie raczej zdaje sprawe ze jest obszar danych i
kodu. I tego kodu nie ma co kopiowac miedzy procesami, jesli jest taki
sam.
Swap ? Po *** zrzucac ram z kodem na dysk, jesli ten kod jest w kazdej
chwili dostepny w przestrzenii adresowej. Zreszta nawet klasycznie nie
ma go co zapisywac na dysk, skoro on juz jest tam zapisany.


J.

do góry

On Sun, 22 Feb 2015 15:18:35 +0100, "J.F."
<j...@p...onet.pl> wrote:
> Jestes pewien ? Unix sobie raczej zdaje sprawe ze jest obszar
danych i
> kodu. I tego kodu nie ma co kopiowac miedzy procesami, jesli jest
taki
> sam.

Tak. Nigdzie nie napisałem , że takie kopiowanie ma miejsce w
przypadku stron współdzielonych z shared libs.

> Swap ? Po *** zrzucac ram z kodem na dysk, jesli ten kod jest w
kazdej
> chwili dostepny w przestrzenii adresowej.

To co jest w binarce na dysku nie zawsze jest tym samym co ma jest
wykonywane (1:1) Kod w binarce np. może być skompresowany,
polimorficzny itp.
Filozofujesz na temat architektury, która na razie nie istnieje,
musisz uwierzyć na słowo, że żaden z rozwijanych obecmie kerneli
unixowych nie jest w stanie wesprzeć* to co wymyśliłeś.


> Zreszta nawet klasycznie nie
> ma go co zapisywac na dysk, skoro on juz jest tam zapisany.

Wiesz jak jest realizowane stronicowanie (paging) czy znowu tak tak
gdybasz?


* - bez globalnego przebudowania zarządzania pamięcią.

--
Marek

do góry