19.05.2016 22:45
[#1]
Działanie pamięci FAST
Wytłumaczcie mi chłopaki na tzw. chłopski rozum, jak działa pamięć FAST, ale nie zawiłe szczegóły techniczne, tylko od strony praktycznej. Wiem, że jest znacznie szybsza niż CHIP, ale czegoś nie rozumiem. Skoro grafika i muzyka mogą być ładowane tylko i wyłącznie do CHIP-u i tylko on zajmuje się jej wyświetlaniem i odtwarzaniem (w postaci wykonywalnej, bo zakładam, że jako "surowe" dane można trzymać w tej szybkiej), to jakim sposobem posiadanie pamięci FAST przyśpiesza działanie niektórych gier, szczególnie tzw. fpsów jak np. Alien Breed 3D? Czy można przyśpieszyć wyświetlanie obiektów graficznych blittera (BOB-y w AMOS-ie) korzystając z FAST-u? Mam na myśli zwykłe pikselowane okienka 2D, jakieś obiekty typu domek, wagon, animacja z kilku klatek ruszającego się drzewa, etc.
19.05.2016 22:48
[#2]
Re: Działanie pamięci FAST
@Umpal, post #1
To proste: grafiki nie rysujesz piksel-po-pikselu, no chyba, że w DeluxePaint. Zanim taki piksel postawisz często gęsto musisz obliczyć go na podstawie innych danych, które musisz skądś odczytać (hint), a czasem nawet zmodyfikować dany piksel kilka razy zanim powstanie jego "ostateczna" wersja (hint hint). Jako, że pamięć Fast jest szybsza - masz gotową odpowiedź.
. Mimo wszystko dzięki 
19.05.2016 23:01
[#4]
Re: Działanie pamięci FAST
@Umpal, post #1
Przykładowo, jeśli mamy w Amidze pamięć FAST i załadujemy Workbench'a, to w pamięci CHIP zostaną umieszczone jedynie mapy bitowe jego aktualnego ekranu, a pozostałe dane (biblioteki, struktury systemowe) będą znajdowały się już w pamięci FAST, co ewidentnie przyspieszy dostęp do nich, a tym samym działanie samego systemu. Analogicznie można wytłumaczyć szybsze działanie gier, gdy korzystają one z pamięci FAST.
19.05.2016 23:23
[#6]
Re: Działanie pamięci FAST
@RomanWorkshop, post #4
Wiem, że przyśpieszenie odbywa się tylko wtedy, gdy procesor wykonuje operacje na pamięci FAST, to oczywiste. Twój przykład z bibliotekami jest łatwy do zrozumienia, a jak to jest w przypadku gier, co robi procesor np. we wspomnianym AB 3D? Jakiś konkretny przykład, jeśli możesz, bo o to tak naprawdę mi chodzi.
@Konradzie, wiedzę z linka posiadam, ale nie o taką informację mi chodziło.
@Konradzie, wiedzę z linka posiadam, ale nie o taką informację mi chodziło.
19.05.2016 23:24
[#7]
Re: Działanie pamięci FAST
@Umpal, post #1
jakim sposobem posiadanie pamięci FAST przyśpiesza działanie niektórych gier, szczególnie tzw. fpsów jak np. Alien Breed 3D?
A1200/CD32 - 1.34 MIPS
/ Dhrystones 1286
http://www.a1k.org/forum/attachment.php?attachmentid=4997&d=1213280993
A1200/CD32+FAST - 2.93 MIPS
/ Dhrystones 2807
http://www.a1k.org/forum/attachment.php?attachmentid=4996&d=1213280982
Amiga po prostu jest jest****owo zaprojektowana.
19.05.2016 23:35
[#8]
Re: Działanie pamięci FAST
@Umpal, post #1
Odpowiem najprosciej jak sie da. Gdy wykonywany program znajduje sie w pamieci FAST to procesor moze robic co chce, kiedy chce i jak chce. Jednym slowem "rzadzi na dzielni".
Gdyby ten sam program umiescic w pamieci CHIP (gdy nie ma FASTu) to procesor musi sie dzielic dostepem to tej pamieci z chpsetami. W odpowiednich momentach chipset mowi procesorowi: "idz na fajke bo teraz my musimy tu zrobic to i owo". Wiec procesor czeka bezczynnie na swoja kolej bo nie ma innego wyjscia.
Ostatnia aktualizacja: 19.05.2016 23:46:11 przez Phibrizzo
Gdyby ten sam program umiescic w pamieci CHIP (gdy nie ma FASTu) to procesor musi sie dzielic dostepem to tej pamieci z chpsetami. W odpowiednich momentach chipset mowi procesorowi: "idz na fajke bo teraz my musimy tu zrobic to i owo". Wiec procesor czeka bezczynnie na swoja kolej bo nie ma innego wyjscia.
Ostatnia aktualizacja: 19.05.2016 23:46:11 przez Phibrizzo
20.05.2016 04:42
[#11]
Re: Działanie pamięci FAST
@Umpal, post #1
Nazwa Fast to zagrywka marketingowa, bo ona niczego nie przyśpiesza. Z pamięci chip korzysta jednocześnie procesor, układ graficzny i dźwiękowy. W takim przypadku procesor czasem musi poczekać, w przypadku pamięci fast, procesor nie musi czekać i wykonuje program z pełną prędkością, w zasadzie to ona powinna się nazywać normal, a nie fast. Pamięć fast musi być obsługiwana przez własny kontroler i znajdować się na innej szynie (a przynajmniej być odizolowana buforami od chip), w przeciwnym wypadku otrzymamy pamięć slow tak jak w A500 do której nie ma dostępu, gdy jest używana pamięć chip.
Ostatnia aktualizacja: 20.05.2016 04:43:04 przez sanjyuubi
Ostatnia aktualizacja: 20.05.2016 04:43:04 przez sanjyuubi
20.05.2016 07:36
[#13]
Re: Działanie pamięci FAST
@] SKOLMAN_MWS ˇ agrEssOr [, post #10
Dokładnie. Mało kto zwraca uwagę na to, że Amiga była sprzedawana jako komputer, który nie działał z pełną możliwą prędkością, stąd tez mówi się właśnie, że pamięć fast "przyśpiesza". To trochę jakby powiedzieć, że zwolnienie hamulca ręcznego zwiększa moc silnika.
20.05.2016 08:46
[#15]
Re: Działanie pamięci FAST
@] SKOLMAN_MWS ˇ agrEssOr [, post #10
Atari ma 68030 i jeszcze słot na simma
Które atari z 030, TT czy Falcon miały standardowo slot simma?
Bo ja wiem tylko o slotach na simmy (krótkie) w serii STE, czyli procek 68000
Projektanci na starcie załatwili A1200 i CD32 najbardziej
Jestem tego samego zdania
20.05.2016 11:15
[#18]
Re: Działanie pamięci FAST
@] SKOLMAN_MWS ˇ agrEssOr [, post #16
Miałem na myśli Falcona i slot na pamięć. Nie wiem co tam jest za złącze ale słyszałem o adapterach na standardowe simmy.
Jest tam dedykowane złącze i wymagane jest dedykowana PCB.
Należy pamiętać o tym, że w A1200/A600 dzięki slotowi PCMCIA można było dołożyć pamięć fast w postaci karty SRAM.
W przypadku A1200 (większości kart SRAM) dawało fast porównywalny w kwestii szybkości do tego podłączanego przez slot rozszerzeń
20.05.2016 14:10
[#20]
Re: Działanie pamięci FAST
@ZbyniuR, post #19
pierwsze karty CF na własne oczy to dopiero w 21 wieku zobaczyłem
Co by nie powiedzieć, Commodore potrafiło też czasem trafić w technologie.
Parę lat po ich upadku PCMCIA już były bardzo popularne, pamięci, modemy, karty sieciowe, TV itp. w naszej biedniejszej części Europy nieco z poślizgiem.
Podobnie napęd CD w konsoli też wyprzedziło mainstream o parę lat.
Co do tematu, zawsze myślałem, że FASTRAM jest po prostu szybszą pamięcią ;)
.
20.05.2016 17:28
[#21]
Re: Działanie pamięci FAST
@ZbyniuR, post #19
To ja jakiś biedny i ze wsi byłem
Nie oceniam ludzi ze względu na pochodzenie ani zasobność kieszeni, ale zwróć proszę uwagę na to, że ja nie piałem o CF (tak, do portu PCMCIA można podłączyć coś więcej niż CF
) , tylko o pamięci typu SRAM, która można wykorzystać jako pamięć FAST w A1200/A600 20.05.2016 18:39
[#22]
Re: Działanie pamięci FAST
@rePeter, post #20
Co do tematu, zawsze myślałem, że FASTRAM jest po prostu szybszą pamięcią ;)
Idę o zakład, że nie tylko ty. Moje pytanie tylko z pozoru jest trywialne, ale w praktyce większość nie ma pojęcia, jak to działa, a już na pewno nie na tyle, żeby wyjaśnić to drugiej osobie
Skorzystam z okazji i zadam jeszcze jedno pytanie, tym razem skierowane do scenowych koderów. Jaką rolę odgrywa FAST w takim scenariuszu:
W demie kręci się na ekranie sześcian/torus/cokolwiek 3D, oteksturowane albo z jakimś efektem świetlnym na obiekcie. Na Amigach bez FAST-u ewidentnie chodzi wolniej, skacze, szarpie, etc., a z FAST-em nabiera płynności. To wszyscy znamy i od początku "rozumiemy". Tyle, że rozumienie u większości ogranicza się do "z fastem działa szyko, a bez - kiepsko". Skoro wszystkie operacje graficzne wykonuje CHIP, to jak to się dzieje, że taki obiekt kręci/rysuje się szybciej z FAST-em? Niechno ktoś pomoże w kolejnym olśnieniu, plis
20.05.2016 19:51
[#23]
Re: Działanie pamięci FAST
@rePeter, post #20
Co do tematu, zawsze myślałem, że FASTRAM jest po prostu szybszą pamięcią ;)
To kolejny błąd myślowy dobrze współpracujący z ideą FASTRAMU przy pomocy "chłopskiego rozumu", który brzmi logicznie na początku, a przestaje gdy się łyknie trochę wiedzy, szybsza pamięć nic nie daje w przypadku, gdy komputer już pracuje z pełną wydajnością, do A600 mógłbyś włożyć i DDR5 2GHz a i tak w sysinfo otrzymałbyś wynik 710.
Obecnie mamy czasy, gdzie procesor jest szybszy niż pamięć, więc dokładanie szybszych pamięci coś zmienia, jednak nie aż tak dużo z powodu dużych pamięci cache w procesorach.
20.05.2016 19:55
[#24]
Re: Działanie pamięci FAST
@Umpal, post #22
Sam kod programu uruchomionego z pamięci FAST, odczyt/zapis danych niezbędnych do wyświetlenia, np. obiektu graficznego oraz obliczenia związane, np. z jego ruchem są wykonywane szybciej na danych w pamięci FAST. Później tylko sam wynik, czyli gotowy i obliczony obraz jest zapisywany do pamięci ekranowej, czyli do CHIP'u. Jak już wcześniej wspomniano, procesor ma bezpośredni dostęp do pamięci FAST, nie ograniczany przez układ graficzny Amigi, dlatego odczyt/zapis pamięci FAST jest w praktyce szybszy, niż pamięci CHIP.
20.05.2016 20:09
[#25]
Re: Działanie pamięci FAST
@Umpal, post #22
Po pierwsze to nie CHIP rysuje obiekt, tylko ewentualnie blitter i copper korzystając z CHIPu, po drugie blitter i copper nie działają samodzielnie, coś musi nimi sterować i coś musi obliczyć dane do wygenerowania takiej klatki. Tym czymś jest procesor, a ten będzie stał w miejscu kiedy np. blitter będzie przenosił bloki danych, bo instrukcje i zmienne znajdują się w CHIPRAMie. Jak masz Fast, to program załaduje się do tej pamięci i tam będzie trzymał swoje zmienne, więc procesor nie będzie blokowany, bo ta pamięć jest dla niego zawsze dostępna.
Analogicznie, jeśli masz dwóch mechaników, którzy używają tego samego klucza, to jeden z nich zawsze musi czekać na drugiego gdy go potrzebuje. Gdyby posiadał swój własny klucz, to pracował by bez przerwy. Tak samo tutaj, procesor ma przerwy w działaniu z powodu współdzielenia pamięci, a FAST jest prywatną pamięcią do której nikt inny nie ma dostępu.
Analogicznie, jeśli masz dwóch mechaników, którzy używają tego samego klucza, to jeden z nich zawsze musi czekać na drugiego gdy go potrzebuje. Gdyby posiadał swój własny klucz, to pracował by bez przerwy. Tak samo tutaj, procesor ma przerwy w działaniu z powodu współdzielenia pamięci, a FAST jest prywatną pamięcią do której nikt inny nie ma dostępu.
20.05.2016 20:17
[#26]
Re: Działanie pamięci FAST
@Umpal, post #22
Spróbuję tak jak ja to rozumiem (chociaż nie jestem koderem), najwyżej ktoś mnie poprawi.
Po pierwsze pamięć chip w A1200 pracuje w tempie 14MHz niezależnie od tego jaką masz kartę turbo. A pamięć fast cyka tak jak turbo czyli 40MHz czy 50 czy ileś tam. O tym że do fastu dostęp ma tylko procek, a do chipu także układy specjalizowane które w dodatku mają wyższy priorytet, więc gdy procek chce coś czytać lub pisać w chip jednocześnie z jakimś innym układem to musi poczekać aż tamten zrobi swoje. Jak to już ktoś wspomniał.
Czyli im mniej razy procek musi sięgać do pamięci chip tym mniej razy przesyłane bajty będą stały w korku. ;)
Jeśli ekran ma np 16 kolorów to znaczy że na piksel przypadają 4 bity, ale każdy z nich jest w innym bajcie i to bynajmniej nie w sąsiednich. To się nazywa bitplany, bo w chunky te 4 bity byłyby w tym samym bajcie, a pozostałe 4 bity w tym bajcie dotyczyłyby następnego piksela.
Czyli żeby zmienić kolor 1go piksela trzeba odczytać 4 bajty, zmodyfikować w nim właściwy bit w każdym z nich i zapisać go z powrotem do pamięci ekranu. Więc to już 8 razy trzeba było zajrzeć do pamięci ekranu, a to dopiero 1 piksel. Teraz sobie policz ile masz wszystkich pikseli.
A jeśli tą operację przeprowadzimy na kopii ekranu w pamięci fast to te 8 razy zajrzeliśmy do komórki we fast, a po przetworzeniu tak 8 sąsiednich pikseli przerzucamy te 4 zmodyfikowane bajty do chipu, czyli na 8 pikseli zajrzeliśmy do chipu tylko 4 razy, zamiast (4 bajty * 8 pikseli * 2 bo odczyt i zapis) = aż 64 razy. No to chyba jest różnica prawda?
Oczywiście można by taką procedurę zoptymalizować i modyfikować na raz 8 sąsiednich pikseli, co zwalnia nas z odczytywania tych 4ech bajtów i to kilkukrotnie (by zachować niezmienione sąsiednie piksele w tych samych bajtach). W takiej sytuacji nie ważne czy mamy fast czy nie. Ale...
Sęk w tym że modyfikowanie pamięci ekranu musi być zsynchronizowane z odświeżaniem ekranu (żeby nic dziwnie nie migało), to jedna sprawa, a do tego procedury wyliczające kolor poszczególnych pikseli zależnie od położenia figur czy tekstur wymagają tysięcy operacji na pamięci zanim ustalimy jakie kolory mają mieć poszczególne piksele. No właśnie operacji na pamięci... Czy lepiej je wykonywać na fascie który jest jak puste lotnisko, czy lepiej na chipie który jest jak miasto w godzinach szczytu?
A wszystko to zanim zaczęliśmy modyfikować pamięć ekranu. - Oki, już wiemy jakie kolory mają mieć wszystkie piksele. Teraz trzeba numer koloru rozebrać na poszczególne bity i każdy wrzucić do innego bajta, pod właściwy bit. No i znowu czy lepiej to robić w chipie czy we fascie?
A gdy już mamy gotową całą następną klatkę to jeśli robiliśmy to w chipie, to wystarczy przełączyć adres pamięci który ma być teraz wyświetlony, natomiast gdy robiliśmy to we fascie musimy to teraz przerzucić do chipu. Czyli na tym etapie więcej roboty jak mamy fast, ale przypominam że zaoszczędziliśmy masę czasu na przygotowaniu tej klatki robiąc to we fascie zamiast w chipie. Mając fast jest to jedyny etap w którym musimy zaglądać do chipu, a nie mając fastu wszystkie inne etapy przygotowania kolejnej klatki robiliśmy na chipie. :)
Po pierwsze pamięć chip w A1200 pracuje w tempie 14MHz niezależnie od tego jaką masz kartę turbo. A pamięć fast cyka tak jak turbo czyli 40MHz czy 50 czy ileś tam. O tym że do fastu dostęp ma tylko procek, a do chipu także układy specjalizowane które w dodatku mają wyższy priorytet, więc gdy procek chce coś czytać lub pisać w chip jednocześnie z jakimś innym układem to musi poczekać aż tamten zrobi swoje. Jak to już ktoś wspomniał.
Czyli im mniej razy procek musi sięgać do pamięci chip tym mniej razy przesyłane bajty będą stały w korku. ;)
Jeśli ekran ma np 16 kolorów to znaczy że na piksel przypadają 4 bity, ale każdy z nich jest w innym bajcie i to bynajmniej nie w sąsiednich. To się nazywa bitplany, bo w chunky te 4 bity byłyby w tym samym bajcie, a pozostałe 4 bity w tym bajcie dotyczyłyby następnego piksela.
Czyli żeby zmienić kolor 1go piksela trzeba odczytać 4 bajty, zmodyfikować w nim właściwy bit w każdym z nich i zapisać go z powrotem do pamięci ekranu. Więc to już 8 razy trzeba było zajrzeć do pamięci ekranu, a to dopiero 1 piksel. Teraz sobie policz ile masz wszystkich pikseli.
A jeśli tą operację przeprowadzimy na kopii ekranu w pamięci fast to te 8 razy zajrzeliśmy do komórki we fast, a po przetworzeniu tak 8 sąsiednich pikseli przerzucamy te 4 zmodyfikowane bajty do chipu, czyli na 8 pikseli zajrzeliśmy do chipu tylko 4 razy, zamiast (4 bajty * 8 pikseli * 2 bo odczyt i zapis) = aż 64 razy. No to chyba jest różnica prawda?
Oczywiście można by taką procedurę zoptymalizować i modyfikować na raz 8 sąsiednich pikseli, co zwalnia nas z odczytywania tych 4ech bajtów i to kilkukrotnie (by zachować niezmienione sąsiednie piksele w tych samych bajtach). W takiej sytuacji nie ważne czy mamy fast czy nie. Ale...
Sęk w tym że modyfikowanie pamięci ekranu musi być zsynchronizowane z odświeżaniem ekranu (żeby nic dziwnie nie migało), to jedna sprawa, a do tego procedury wyliczające kolor poszczególnych pikseli zależnie od położenia figur czy tekstur wymagają tysięcy operacji na pamięci zanim ustalimy jakie kolory mają mieć poszczególne piksele. No właśnie operacji na pamięci... Czy lepiej je wykonywać na fascie który jest jak puste lotnisko, czy lepiej na chipie który jest jak miasto w godzinach szczytu?
A wszystko to zanim zaczęliśmy modyfikować pamięć ekranu. - Oki, już wiemy jakie kolory mają mieć wszystkie piksele. Teraz trzeba numer koloru rozebrać na poszczególne bity i każdy wrzucić do innego bajta, pod właściwy bit. No i znowu czy lepiej to robić w chipie czy we fascie?
A gdy już mamy gotową całą następną klatkę to jeśli robiliśmy to w chipie, to wystarczy przełączyć adres pamięci który ma być teraz wyświetlony, natomiast gdy robiliśmy to we fascie musimy to teraz przerzucić do chipu. Czyli na tym etapie więcej roboty jak mamy fast, ale przypominam że zaoszczędziliśmy masę czasu na przygotowaniu tej klatki robiąc to we fascie zamiast w chipie. Mając fast jest to jedyny etap w którym musimy zaglądać do chipu, a nie mając fastu wszystkie inne etapy przygotowania kolejnej klatki robiliśmy na chipie. :)
20.05.2016 20:18
[#27]
Re: Działanie pamięci FAST
@RomanWorkshop, post #24
Problem z moim zrozumieniem polega na tym, że ja zawsze programowałem za pomocą języków wysokiego poziomu (Basic, Visual Basic, C++, czy AMOS na Amidze). W nich programista nie musi się specjalnie przejmować, jak jest alokowana pamięć i z czego korzysta procesor, bo robi to za niego kompilator i później to, na czym ten program chodzi - generalnie dzieje się to automatycznie.
Ciężko (póki co) mi przychodzi głębsze zrozumienie tej kwestii na Amidze, bo domyślam się, że ma to ścisły związek z asemblerem, którego nigdy nie ogarniałem (z wyjątkiem banalnych i raczej przepisanych bez większego zrozumienia programików na C64 wieki temu).
Ogólną zasadę, czyli że program uruchomiony z pamięci FAST działa szybciej rozumiem, bo procesor nie czeka na swoją kolejkę. To jest jasne, ale to teoretyczna wiedza. Wciąż nie łapię co może przyśpieszać kręcenie sześcianu. Wektory, położenie w osiach, skalowanie, itp. wszystko to liczy tylko i wyłącznie procesor - oczywiste. Czy pisząc w asemblerze taką procedurę programista określa na jakiej pamięci procesor ma wykonywać obliczenia? Jeśli tak jest, to wszystko będzie dla mnie jasne. Jeśli używa się instrukcji, które są - bo ja wiem, z braku dostatecznej wiedzy napiszę "umiejscawiane" z wyboru piszącego program w pamięci FAST, to takie wyjaśnienie miałoby dla mnie całkowity sens.
Z góry dzięki za cierpliwość, ale od wczoraj nauczyłem się rzeczy, o jakich całe życie nie miałem pojęcia.
@Sanjy i szczególnie Zbyniu, dzięki za wyłożenie spray w ten sposób. Tego potrzebowałem. Domyślam się, że moje wnioski na końcu powyższego tekstu są prawidłowe(?)
Ostatnia aktualizacja: 20.05.2016 20:26:52 przez Umpal
Ciężko (póki co) mi przychodzi głębsze zrozumienie tej kwestii na Amidze, bo domyślam się, że ma to ścisły związek z asemblerem, którego nigdy nie ogarniałem (z wyjątkiem banalnych i raczej przepisanych bez większego zrozumienia programików na C64 wieki temu).
Ogólną zasadę, czyli że program uruchomiony z pamięci FAST działa szybciej rozumiem, bo procesor nie czeka na swoją kolejkę. To jest jasne, ale to teoretyczna wiedza. Wciąż nie łapię co może przyśpieszać kręcenie sześcianu. Wektory, położenie w osiach, skalowanie, itp. wszystko to liczy tylko i wyłącznie procesor - oczywiste. Czy pisząc w asemblerze taką procedurę programista określa na jakiej pamięci procesor ma wykonywać obliczenia? Jeśli tak jest, to wszystko będzie dla mnie jasne. Jeśli używa się instrukcji, które są - bo ja wiem, z braku dostatecznej wiedzy napiszę "umiejscawiane" z wyboru piszącego program w pamięci FAST, to takie wyjaśnienie miałoby dla mnie całkowity sens.
Z góry dzięki za cierpliwość, ale od wczoraj nauczyłem się rzeczy, o jakich całe życie nie miałem pojęcia.
@Sanjy i szczególnie Zbyniu, dzięki za wyłożenie spray w ten sposób. Tego potrzebowałem. Domyślam się, że moje wnioski na końcu powyższego tekstu są prawidłowe(?)
Ostatnia aktualizacja: 20.05.2016 20:26:52 przez Umpal
20.05.2016 20:32
[#28]
Re: Działanie pamięci FAST
@ZbyniuR, post #26
Po pierwsze pamięć chip w A1200 pracuje w tempie 14MHz niezależnie od tego jaką masz kartę turbo. A pamięć fast cyka tak jak turbo czyli 40MHz czy 50 czy ileś tam.
Tematem wątku jest, dlaczego pamięć fast sama w sobie przyśpiesza komputer, a nie dlaczego ona działa szybciej na akceleratorze niż pamięć CHIP.
20.05.2016 22:23
[#30]
Re: Działanie pamięci FAST
@Umpal, post #27
Programista przy rezerwowaniu pamięci funkcją biblioteczną AllocMem z biblioteki exec.library w Kickstarcie może wybrać, jaki jej rodzaj chce otrzymać. Może to być, np. tylko CHIP, tylko FAST lub pamięć dowolnego rodzaju. To system (Kickstart) umiejscawia automatycznie wszystkie uruchamiane programy (tak, jak dane systemowe) w pamięci FAST, jeśli jest dostępna.
Tak więc, programista podczas rezerwowania pamięci dla danych programu wybiera jej rodzaj. Najpierw może sprawdzić, czy pamięć FAST jest dostępna, a tylko jeśli jej nie ma, to wykorzysta inny rodzaj dostępnej pamięci (CHIP, SLOW). Tak to widzę.
Ostatnia aktualizacja: 20.05.2016 22:24:34 przez RomanWorkshop
Tak więc, programista podczas rezerwowania pamięci dla danych programu wybiera jej rodzaj. Najpierw może sprawdzić, czy pamięć FAST jest dostępna, a tylko jeśli jej nie ma, to wykorzysta inny rodzaj dostępnej pamięci (CHIP, SLOW). Tak to widzę.
Ostatnia aktualizacja: 20.05.2016 22:24:34 przez RomanWorkshop