А какой у вас компьютер?

[MyxoMop]

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

[murzistor]

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

[NStorm]

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

Всё это пожелали именно программисты 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

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

Спойлер

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

[As]

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

[NStorm]

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

[Андрей Бедов]

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

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

[NStorm]

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

[murzistor]

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

[musor]

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

[murzistor]

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

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

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

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

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

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

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

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

[NStorm]

[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 на гитхабе).

[Андрей Бедов]

Спойлер

[Maykill]

https://s00.yaplakal.com/pics/pics_orig ... 552991.jpg

[Андрей Бедов]

[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

.

[musor]

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

[Андрей Бедов]

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

[As]

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

[Андрей Бедов]

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

======

Спойлер

[Upgrader]

Спойлер

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