Форум РадиоКот

Андрей Бедов не, не убедил. Буду через линк делать. Пока залинкую папки Cache и Code Cache. Еще подумаю, наверно добавлю IndexedDB. Local Storage и Service Worker. При их стирании и последующем запуске браузера ничего критичного на происходит, а какое-то гавно там тоже копится. Главное чтоб куки не стирались, на остальное пох.

[uquote="MyxoMop",url="/forum/viewtopic.php?p=3914837#p3914837"]Чтоб кэш кидался на RAM диск и не убивал ресурс SSD, а бонусом еще и место на диске не засирается. Комп выключил - гавно исчезло.[/uquote]
Мечта!
Хотя лучше б этого говна вообще не было.
Странные вещи творит винда: содержимое оперативки кидает в файл подкачки - а файлы прогружает в оперативку - и всё это против желания юзеров и даже программистов!

всё это против желания юзеров и даже программистов!

Всё это пожелали именно программисты Microsoft, которые писали менеджер памяти для этой ОС.

Ну и ну-уу... ©

GPU RAM Drive

Use a portion of your Video Card's RAM to create a virtual RAM disk that is much faster than a regular HDD, with this open-source program

Скачал - и ведь работает! Пишу с работающего с него Хрома.

Спойлер

А я почему-то считал, что прямой доступ к видеопамяти имеет только драйвер видеокарты.

Использование памяти "форточками" - та ещё загадка... Имею 8 гигабайт ОЗУ, занято три, свободно... 240 мегабайт! Где остальное?!

As, занято кешем. Она освободится, как только понадобится приложению под невыгружаемые данные.
10ка кстати в своём диспетчере задач начала честно показывать отдельно, сколько реально используется. 7ка и более ранние вроде не показывали еще, надо было отдельными прогами смотреть.

As, остальное "на всякий случай" забито подгруженными кусками кода, которые (как считает Windows) "вдруг могут понадобиться". Типа, память в любом случае жрёт электричество - так зачем ей простаивать зря... Но при затребовании этой части ОЗУ реально работающими программами, весь этот "на-всякий-случайный" мусор безжалостно выгоняется из памяти ссаными тряпками.

А всё же, лет десять назад на фразу "мой браузер работает в видеокарте" - покрутили бы пальцем у виска.

Андрей Бедов, недавно читал, что игру Crysis целиком поставили на GPU RAM Drive и запустили оттуда )
Правда пока исходя из тестов на страничке автора GPU Ram Drive'а - скорость его ниже обычного SATA SSD за счет накладных расходов всяких.

[uquote="Андрей Бедов",url="/forum/viewtopic.php?p=3915000#p3915000"]А я почему-то считал, что прямой доступ к видеопамяти имеет только драйвер видеокарты.[/uquote]
Так может, он и сделан через драйвер видеокарты.

ТАМ НЕТ ПДП К ВИДЕОРАМ ТАМ ДОСТУП ЧЕРЕЗ 64К ОКНО ...
D ПРИНЦИПЕ ВЫ ЗРЯ УДИВЛЯЕТЕСЬ ЭТО извесно ДОСА но тогда мало кто этим ползовался
кроме спецкарточек реалтайм захвата

Тогда другая версия: это "работает" через "отображение памяти".
Когда видеопамять "отображается" в оперативку. То есть, используется оперативная память

Когда мелкомягкие изобретали свой директ икс - ещё не было видеокарт. Были видеоадаптеры.
Картинка просчитывалась процессором в оперативке - в которой выделялся видеобуфер - и отправлялась в видеоадаптер, который уже сканировал свои 64К памяти 60 раз в секунду для вывода через VGA.
Тогда уже был OpenGL c его клиент-серверной архитектурой - чтобы можно было вести просчёт на одном компьютере в локальной сети, а смотреть результат на другом.

А мелкомягкие решили так - а давайте запилим прямой доступ к памяти!
Ну как прямой... Нельзя просто так взять и позволить прикладному программисту лазить в системной памяти.
Нужно "запереть" буфер, нарисовать в нём что-то - и не забыть "отпереть", а то система-то ждёт!

Ну так вот. Сделали они свой прямой доступ.
А потом появились видеоускорители. Которые взяли работу по рисованию на себя. И видеобуфер переехал туда же.
И никакого прямого доступа к видеобуферу быть не могло.

А OpenGL с клиент-серверной архитектурой оказался наоборот удачным для связки процессор-видеокарта.
Мелкомягкие потом долго DirectX допиливали... Игры делали на OpenGL в те годы.

Потом в OpenGL внедрили эту "фичу" из DirectX - по запиранию буфера. Которое тут нафиг не нужно.
В чём суть.
В OpenGL программист отдаёт команду - загрузить в память устройства (видеопамять) то-то и то-то.
В DirectX (и в OpenGL через "фичу") надо "запереть" буфер. Указав флаг - предполагается ли чтение из "запертого" буфера

(В это время в оперативке создаётся буфер. Если предполагается, что будет чтение - то туда надо достать инфу из видеопамяти - а этот обратный поток данных менее оптимизирован, чем прямой.)
Потом, вместо явной отправки инфы в видеопамять, программист кидает инфу в буфер.
Потом командует: Сезам, откройся... ой, буфер, отопрись!
(Тут содержимое буфера копируется из оперативки в видеопамять.)
В этот момент может произойти ошибка.
Если, например, юзер сменит разрешение экрана - то данные поломаются.
И программисту придётся повторить всю процедуру.

(То, что я написал в скобках, в руководствах не пишут напрямую, но это очевидно из тех же руководств.)

[uquote="murzistor",url="/forum/viewtopic.php?p=3915312#p3915312"]Тогда другая версия: это "работает" через "отображение памяти".
Когда видеопамять "отображается" в оперативку. То есть, используется оперативная память [/uquote]
Нет. В чем проблема заглянуть в исходник? Он же небольшой и довольно-таки очевидный: https://github.com/prsyahmi/GpuRamDrive ... mDrive.cpp
Метод GPURamDrive::GpuAllocateRam(). Используется CUDA API или OpenCL API. Функции cuMemAlloc() и clCreateBuffer() соотв. Весь дальнейший доступ также через CUDA/OpenCL, а соотв. через драйвер. Отсюда и скорость ниже, даже чем у обычной RAM получается (об это пишет автор проекта в README на гитхабе).

Спойлер

[uquote="korob",url="/forum/viewtopic.php?p=3908755#p3908755"]

Андрей Бедов писал(а):Смущает то, что данное положение дел не нравится LinPack-у, Prime95, и OCCT.

Это именно те тесты которые экстремально дрочат нагружают память. Так что это не повод для смущения, это намёк. [/uquote]Как всегда, в очередной раз korob прав.
Решил всё же прозондировать вопрос поглубже, и вот что выяснилось.
При снижении множителя процессора с 9х до 6х при неизменно разогнанной шине памяти - ошибки в тестах никуда не исчезают. Вывод - дело не в процессоре.
Пошёл дальше. В итоге выяснилось, что косячит материнка. Она принципиально не умеет в CL6 при разгоне шины памяти. Оставляет CL5, даже если в BIOS принудительно выставить 6-6-6-18. Она зараза оставляет 5-6-6-18 (по показаниям AIDA64).
А у планок памяти, согласно их SPD, при частоте 800 МГц должно быть CL6.

Вобщем, нашёл абсолютно стабильное сочетание: шина 320 (1280), память ровно 800 при CL5. Думаю даже это круто, так как память при 800 не глючит при CL5. А вот на 834 - уже ошибка. Скорость обмена памяти увеличилась на 1+ Гб/сек.

1066-667: 1280-800:
Read: 6273 Read: 7403
Write: 4677 Write: 5622
Copy: 4790 Copy: 5649

.

ну чо сказать act верно тока добавить стабилности можно подняф питание памяти

Не помогает увеличение напряжения. Ни на памяти, ни на Северном мосту. Видимо просто уже достигнут частотный потенциал при данных задержках.
Пусть работает так. Жарить комплектуху не хочу. У i945 Северный мост и так горячий, пришлось даже вешать вентилятор на него. Странно что АСУС не повесила с завода, хотя даже распайку под колодку "NB_FAN" на плате сделала.

...Скуки ради, встроенными средствами "форточек" просмотрел обращения к SSD... Вся запись прёт от браузера!!! Форточки вообще практически ничего на диск не пишут...

Папку кэша хромоподобного браузера можно переназначить куда угодно, дописав в ярлыке. Я писал там выше ключ.

======

Спойлер

Спойлер

Что это за дичь?