• Любая интернет-компания обязана тайно изменить программный код по требованию властей
    0

    По закону он должен был внедрить сразу на сервер, какой пулл-реквест.


    Но тут сразу есть лазейка: как только что-то поменял, звонишь админу и говоришь: «срочно задеплой прод, меня попросили сделать то, о чем я не могу сказать». И новый код перетирается старым.

  • Любая интернет-компания обязана тайно изменить программный код по требованию властей
    +4

    Но чувака все равно посадят, он не выполнил требования

  • Настолько ли стар твой Windows?
    0

    Тот случай, когда по заголовку и первым трем абзацам совершенно непонятно о чем статья.

  • На новых MacBook невозможно загрузить Linux из-за чипа T2
    +2

    Но у эйра говенный экран, очнитесь )

  • На новых MacBook невозможно загрузить Linux из-за чипа T2
    +5
    У меня Macbook Air

    Ну и конечно Экран

    Но в эйрах до вчерашнего дня (старт продаж модели 2018 года) был говенный экран.

  • На новых MacBook невозможно загрузить Linux из-за чипа T2
    +2

    А он и не пытался оправдать убирание возможности кастома, повнимательнее. Он отвечал на вопрос «если яблоки такие плохие, почему их покупают?».

  • Как я создал меняющую настроения анимацию с помощью масок CSS
    +1

    Да не -o-, а -0-. Вы разве не слышали о браузере Нольпера?

  • Кротовые норы в JavaScript
    0

    wibuhu Добавили бы ремарку рядом с этим примером, что его нельзя использовать.

  • Быстрое размытие по Гауссу
    0

    И тем не менее

  • Работа с изображениями на Python
    +1

    Совершенно верно. Работает через апроксимацию серией бокс-фильтров. Народ и раньше догадывался, что несколько бокс-фильтров выдают результат, похожий на размытие по Гауссу. Но всё встало на места после работы немецких исследователей.

  • Работа с изображениями на Python
    +1

    У меня нет какой-то большой истории про безопасность, которую бы я мог рассказать. Да, уделяли, как иначе. Численно оценить это сложно. Таких глобальных уязвимостей, с исполнением кода, насколько я знаю, не было. Но понятно, что чем распространеннее библиотека, тем больше в ней ищут уязвимости. Pillow намного менее распространенна, чем тот же ImageMagick, так что есть два варианта, либо еще не нашли, либо их нет.

  • Работа с изображениями на Python
    0

    Из документации:


    cuda::resize(InputArray src, OutputArray dst, Size dsize, double fx=0, double fy=0, int interpolation=INTER_LINEAR, Stream& stream=Stream::Null())

    interpolation – Interpolation method. INTER_NEAREST, INTER_LINEAR and INTER_CUBIC are supported for now.

    Если INTER_CUBIC интерпретируется так же, как в самом cv::resize (то есть при уменьшении берется фиксированное ядро в окружности ближайшей точки), то такой ресайз (а точнее такое качество) никому не нужно. А более-менее приемлемого значения INTER_AREA тут нет.


    Понять, в чем проблема в ресайзе с фиксированным ядром, можно, например, прочитав соответствующую главу в моей недавней статье.

  • Как Discord каждый день изменяет размер 150 млн картинок с помощью Go и C++
    +1

    Привет, разработчик Pillow-SIMD с вами.


    Очень жаль, что я не видел ни оригинальную статью, ни перевод год назад. Нашел её несколько дней назад совершенно случайно. Ну что ж, тем интереснее посмотреть, что стало через год.


    lilliput работал не хуже или лучше, чем pillow-simd в тех задачах, которые нам нужны.

    Я проверил бенчмарки и пришел к неутешительным для компании Discord выводам:


    • За год производительность Pillow-SIMD только выросла
    • В тестах (а может быть и в продакшене) были использованы более качественные и затратные фильтры, чем удовлетворяли компанию Discord
    • В тест, будто намеренно, вставлены лишние операции для Pillow-SIMD, которые не только впустую тратят время, но и изменяют изображение так, чтобы его было сложнее кодировать (добавляют альфаканал)
    • За год производительность Lilliput при работе в webp сильно деградировала. Это заметил не только я
    • Конкретно этот кейс (кроп+ресайз) можно еще больше оптимизировать в Pillow-SIMD, получив в итоге скорость для джипегов на 77% быстрее, чем у Лилипута
    • Мало относится к бенчмарку, но все же: В Pillow-SIMD есть возможность загружать джипеги сразу меньшего размера, чем они есть в файле. Это может очень сильно экономить память и время. В OpenCV такой возможности нет

    Все неточности и странности в бенмарке я поправил и оформил в виде пулреквестов. Ну а чтобы самим все не собирать, вы можете сразу воспользоваться моей починенной версией.


    Media Proxy требовал на 60% меньше серверных инстансов для обработки такого же количества запросов, что и Image Proxy, выполняя эти запросы в гораздо меньшие разбросы времени.

    Скорее всего дело было в циклических ссылках, которые не давали изображениям вовремя освобождаться, синхронной работой с сетью и всем остальном, что не любит питон, но что при желании можно победить.


    Что в итоге: компания Discord написала собственную библиотеку и поддерживает свой форк OpenCV, чтобы это всё работало хуже, чем если бы они просто поправили пару строчек на Питоне.


    Но в общем-то по бенчмарку видно, что компания была больше заинтересована не в работоспособности, а в том, чтобы все переписать на модном го и до сих пор ловить баги, портящие изображения.

  • Ядра процессора или что такое SMP и с чем его едят
    0
    Может ещё расскажете, как на sleep 60 влияет увеличение количества ядер?

    Давайте расскажу. Никак. Но как это опровергает утверждение «чем больше ядер — тем мощнее процессор»?

  • Ядра процессора или что такое SMP и с чем его едят
    +1
    Там ещё про много чего нет ни слова.

    Откуда вы знаете, вы же дальше не читали.


    Так что «По вашему утверждению», при добавлении ядер ЛЮБОЙ софт будет лучше работать?

    Как вы это придумали? Там же написано «тем мощнее будет процессор», а не «любой софт будет лучше работать». Софт и при увеличении частоты не всегла лучше работает, sleep 60 вообще пофиг на мощность ваших ядер.

  • Ядра процессора или что такое SMP и с чем его едят
    0
    В общем случае ПРИ ПРОЧИХ РАВНЫХ я лично предпочту Тактовая частота х2, чем Количество ядер х2.

    Нет, подождите. Про частоту там ни слова. По вашему утверждению «перестал читать после „чем больше — тем мощнее процессор“» вы предпочтёте количество ядер х1, чем количество ядер х2.

  • Ядра процессора или что такое SMP и с чем его едят
    +1

    А как правильно? Чем больше ядер, тем немощнее?

  • Root хуже Михалкова
    0

    Вы написали комментарий под статьей. Похвально )

  • Обновление до Windows 1809 (иногда) уничтожает все файлы в профиле
    0

    Думал вы скажете, почему будет меньший износ ячеек от внутреннего сжатия по сравнению с внешним. Тут опять же, сжатие на уровне ОС ничем не хуже. Все еще не понятно, за что TonyLorencio и Googlist его так не любят.

  • Обновление до Windows 1809 (иногда) уничтожает все файлы в профиле
    0

    За счет чего?

  • Обновление до Windows 1809 (иногда) уничтожает все файлы в профиле
    0

    Как вы себе представляете сжатие в дисках? Даже если бы это было так, допустим, на диск записали два гигабайта, он сжал это в два раза, записал только один. Как он сообщит системе, что еще один гигабайт остался свободен? А если не сообщит, то какая разница, что он там внутри себя делает, пусть хоть в интернет пишет, какая разница, если с точки зрения пользователя это ничего не меняет?


    двойное сжатие не даст єффекта.

    Верно, как и одинарное на стороне диска не дает никакого эффекта, разве что возможно чуть более быстрая записи. Так этот эффект будет и при сжатии на стороне операционной системы. При таком раскладе разумно выключить именно сжатие на стороне диска, а не на стороне операционной системы.

  • Обновление до Windows 1809 (иногда) уничтожает все файлы в профиле
    0

    Так как тут много пользователей виндуса, не могу придумать лучшего места, чтобы спросить.


    Несколько дней назад объявили или не объявили о выходе Edge 18. Я не могу найти информации ни как на него обновиться, ни когда он точно выходит. Гугл подсовывает лендинги майкрософта и статьи без конкретики. Уже достало, четно говоря, искать хоть какую-то инормацию. Кто-то может объяснить, как можно сейчас поставить Edge 18 на виртуалку или когда это будет возможно?

  • Обновление до Windows 1809 (иногда) уничтожает все файлы в профиле
    0
    а затем включают сжатие, чтобы места больше было

    Какие у вас проблемы со сжатием? Почему выделили курсивом, считаете это странным, использовать сжатие чтобы сжимать?

  • Ускорение кода на Python средствами самого языка
    0

    img это объект изображения в библиотеке Pillow. img.load() возвращает объект доступа к пикселям. Странно, конечно, что автор об этом ничего не сказал.

  • Ускорение кода на Python средствами самого языка
    0
    Просто если pix = [[1, 2], [3, 4]]

    Так pix это не список, это то что возвращает img.load().

  • Быстрый ресайз джипегов на видеокарте
    0

    Я ничего не продаю. Pillow-SIMD и libjpeg-turbo совершенно бесплатны в том числе для коммерческого использования.

  • Как сэкономить память на вкладках браузера, но не потерять их содержимое. Опыт команды Яндекс.Браузера
    0

    Да, приводит, потому что есть такая штука как дисктовый кеш в оперативной памяти. Даже при достаточной сильной загруженности памяти, ОС все равно старается держать его в районе 20%. Например сейчас у меня на маке он 1,3 Гб из 8, хотя запущено много чего и свободной памяти явно нет. А на винде он сейчас вообще 4,5 Гб из 8, потому что не особо много что запущено.


    И вот винда имеет свойство иногда решить (если процессами давно никто не пользуется), что приложения можно бы уже скинуть в своп, а освободившее место занять дисковым кешем.

  • Как сэкономить память на вкладках браузера, но не потерять их содержимое. Опыт команды Яндекс.Браузера
    0

    Не могу пояснить, не понимаю, что вы спросили.

  • Быстрый ресайз джипегов на видеокарте
    +2
    Так сделайте измерения на 72 виртуальных CPU и покажите результат.

    А вы мне что? )


    Ну ладно, раз вы так вежливо попросили, сделаю несколько более приближенный к реальности тест.


    Во-первых я сделал в репозитории pillow-perf ветку fastvideo-competition, в которой переписан тест full_cycle, чтобы максимально соответствовать тому, что делаете вы. Там 4 тесткейса:


    • Load+save — только загрузка и сохранение jpeg.
    • +resize — добавляется ресайз посередине. По большей части два этих кейса просто прогревают CPU, чтобы успел выключиться TurboBoost, про который вы упоминали
    • +sharp — добавляется шарп. Это основной тесткейс, результаты которого нас интересуют
    • +sharp — еще один тест, который дублирует предыдущий, чтобы когда какой-то процесс заканчивал работу, нагрузка на CPU не падала и результат не искажался

    Тесты запускаются командой ./pillow-perf/testsuite/run.py full_cycle -s 1920x1080 -n 1024 и никак иначе, без параметра -s во-первых будут неправильно считаться мегапиксели в секунду, во-вторых я поставил там assert ) Результаты будут выводиться для медианного запуска из 1024 попыток.


    Теперь, где будем запускать. Ваше предложение запускать «на 72 виртуальных CPU» очень заманчиво, но не выглядит разумным. Запуская кучу инстансов помельче вы получаете отказоустойчивость и лучшую гранулярность (очень маловероятно, что вам нужно обрабатывать ровно 1500 картинок в секунду, ни больше, ни меньше). Впрочем, жестить и запускать 36 машин тоже не стоит. Я остановился на одном инстансе c5.2xlarge с 8 виртуальными и 4 физическими ядрами. Думаю, не нужно доказывать, что два запущенных рядом одинаковых инстанса будут работать ровно в два раза быстрее, чем один. А 9 ровно в 9 раз быстрее, что по цене и производительности в точности равно одному c5.18xlarge инстансу.


    Всего будет 6 тестов: один поток, 4 потока, 8 потоков и всё еще раз, но с libjpeg-turbo 2.0.


    Многопоток будет запускаться такой командой:


    time (./run.py full_cycle -s 1920x1080 -n 1024 &\
          ./run.py full_cycle -s 1920x1080 -n 1024 &\
          ./run.py full_cycle -s 1920x1080 -n 1024 &\
          ./run.py full_cycle -s 1920x1080 -n 1024 &\
          wait)

    Ладно, поехали.


    Один поток, libjpeg-turbo 1.4.2


    $ time ./run.py full_cycle -s 1920x1080 -n 1024
    
    Full cycle 1920×1080 RGB image
        Load+save           0.02544 s    81.51 Mpx/s
        +resize             0.02222 s    93.33 Mpx/s
        +sharp              0.02335 s    88.81 Mpx/s
        +sharp              0.02335 s    88.80 Mpx/s
    
    real    1m36.680s
    user    1m36.228s
    sys     0m1.004s

    Получается 0.02335 s на процессинг одной картинки. Моя оценка была, напомню, 0.0224 s. Дальше в секундах измерять не имеет смысла, буду писать фрупут в мегапикселях и в операциях в секунду. Ну и не буду писать результаты остальных тестов, чтобы экономить место.


    4 потока, libjpeg-turbo 1.4.2


        +sharp              0.02317 s    89.49 Mpx/s
        +sharp              0.02352 s    88.16 Mpx/s
        +sharp              0.02354 s    88.09 Mpx/s
        +sharp              0.02356 s    88.00 Mpx/s
    real    1m37.357s
    user    6m25.228s
    sys     0m2.800s

    1/0.02317 + 1/0.02352 + 1/0.02354 + 1/0.02356 = 171 операция в секунду
    89.49 + 88.16 + 88.09 + 88.00 = 353 Mpx/s


    Проверяем: 353/1920/1080*10**6 = 171. Сходится, как ни странно )


    8 потоков, libjpeg-turbo 1.4.2


        +sharp              0.03690 s    56.19 Mpx/s
        +sharp              0.03690 s    56.19 Mpx/s
        +sharp              0.03805 s    54.50 Mpx/s
        +sharp              0.03803 s    54.53 Mpx/s
        +sharp              0.03806 s    54.48 Mpx/s
        +sharp              0.03802 s    54.53 Mpx/s
        +sharp              0.03810 s    54.43 Mpx/s
        +sharp              0.03811 s    54.42 Mpx/s
    real    2m36.108s
    user   20m31.172s
    sys     0m6.672s

    439 Mpx/s, 212 запусков в секунду.


    Один поток, libjpeg-turbo 2.0


    $ time ./run.py full_cycle -s 1920x1080 -n 1024
    
    Full cycle 1920×1080 RGB image
        Load+save           0.02120 s    97.81 Mpx/s
        +resize             0.01968 s   105.37 Mpx/s
        +sharp              0.02063 s   100.53 Mpx/s
        +sharp              0.02057 s   100.79 Mpx/s
    
    real    1m24.265s
    user    1m23.808s
    sys     0m0.912s

    Полный вывод, чтобы просто сравнить с libjpeg-turbo 1.4.2.


    4 потока, libjpeg-turbo 2.0


        +sharp              0.02049 s   101.20 Mpx/s
        +sharp              0.02079 s    99.74 Mpx/s
        +sharp              0.02085 s    99.45 Mpx/s
        +sharp              0.02118 s    97.91 Mpx/s
    real    1m25.715s
    user    5m36.984s
    sys     0m2.768s

    398 Mpx/s, 192 запусков в секунду.


    8 потоков, libjpeg-turbo 2.0


        +sharp              0.03201 s    64.77 Mpx/s
        +sharp              0.03203 s    64.74 Mpx/s
        +sharp              0.03246 s    63.88 Mpx/s
        +sharp              0.03246 s    63.88 Mpx/s
        +sharp              0.03303 s    62.77 Mpx/s
        +sharp              0.03303 s    62.77 Mpx/s
        +sharp              0.03296 s    62.91 Mpx/s
        +sharp              0.03295 s    62.92 Mpx/s
    real    2m10.901s
    user   17m12.692s
    sys     0m5.824s

    508 Mpx/s, 245 запусков в секунду.


    Ну и сводная табличка:


    |             | MPx/s | Op/s c5.2xlarge | Op/s c5.18xlarge |
    |-------------|-------|-----------------|------------------|
    | 1c, lib 1.4 | 89    | 43              | -                |
    | 4c, lib 1.4 | 353   | 171             | 1539             |
    | 8c, lib 1.4 | 439   | 212             | 1908             |
    | 1c, lib 2.0 | 101   | 48              | -                |
    | 4c, lib 2.0 | 398   | 192             | 1728             |
    | 8c, lib 2.0 | 508   | 245             | 2205             |

    Спасибо за подсказку с тредами, я был уверен, что это бесполезная фигня )

  • Быстрый ресайз джипегов на видеокарте
    +2
    Джипег не является беспотерьным алгоритмом именно из-за этих округлений

    Очень странно такое слышать от людей, занимавшихся разработкой кодека джипег. Джипег не является беспотерьным алгоритмом вообще не из-за округлений )

  • Быстрый ресайз джипегов на видеокарте
    +1
    36 виртуальных ядер (18 реальных) — это отлично.

    У c5.18xlarge инстансов 72 виртуальных ядра, 36 реальных. Так что умножение на 36 является пессимистичным в моих расчетах.


    В данном случае Tesla V100 — не оптимальный вариант. Оптимальный по цене вариант можно выбрать для заданного набора параметров задачи.

    Тут уж извините, вы сами выбрали что применить для данной задачи.


    Когда делают ресайз 2560->320, то таким образом явно улучшают результат для CPU.

    Я не понимаю, при чем тут 2560→320. Результаты для ресайза 2560→2048 и 2560→320 — это те цифры, которые были у меня на руках без дополнительных бенчмарков. Я их довольно грубо экстраполировал до 2048→1024, но не думаю, что моя оценка имеет точность меньше ±25%.


    Интересно, сколько получается на CPU?

    Будет что-то близкое к результату 2560→2048.


    Пользователь запросто может прислать картинку на 8 или 12 МПикс, а сохранять её в таком виде не стоит.

    Стоит или не стоит — зависит от задачи, тут уже не разработчику библиотек решать.

  • Быстрый ресайз джипегов на видеокарте
    0

    Тут оказывается вышла libjpeg-turbo 2.0, я потестил, можно накинуть еще 15% к скорости распаковки и запаковки. А так как это самая дорогая операция, мы получаем уже не 44, а 48 операций в секунду на ядро, или 1722 операции в секунду за те же деньги.

  • Быстрый ресайз джипегов на видеокарте
    +1

    Однако же в libjpeg-turbo все операции выполняются в целых числах: https://libjpeg-turbo.org/About/SIMDCoverage

  • Быстрый ресайз джипегов на видеокарте
    +1

    Давайте вместе посчитаем. Возьмем для примера цены AWS EC2:


    p3.2xlarge инстанс имеет на борту одну NVIDIA Tesla V100 GPU и стоит $3.06 в час.
    Столько же стоит c5.18xlarge инстанс на новых процессорах Intel c 36 ядрами.


    Сравнивать буду с одной из самых быстрых бесплатных библиотек для обработки изображений Pillow-SIMD.


    На странице бенчмарков пока что нет результатов c5 инстансов, поэтому возьмем результаты для c4. Уверяю, что c5 работают не медленнее.


    Сразу выпишу интересующие нас операции:


    Jpeg load speed = 181 Mpx/s
    Lanczos resize speed = 300 Mpx/s
    Sharp filter speed = 524 Mpx/s
    Jpeg save speed = 166 Mpx/s

    Скорости ресайза именно в два раза нет (потому что при уменьшении в кратное количество раз всегда можно считерить и сделать быстрее, так что для бенмарков такие значения лучше не брать), есть результаты для уменьшения в 1,25 раз (238 Mpx/s) и результаты для уменьшения в 8 раз (658 Mpx/s). Мне лень сейчас делать бенчмарк, поэтому я «на глазок» взял 300 Mpx/s.


    Все результаты приведены для одного ядра.


    Сравнивать будем на 2K разрешении, так как это разрешение показало значительно более хорошие результату на Tesla V100.


    Jpeg load time = 1920*1080 / 10**6 / 181 = 0.0115 s
    Lanczos resize time = 1920*1080 / 10**6 / 300 = 0.0069 s
    Sharp filter time = 960*540 / 10**6 / 524 = 0.001 s
    Jpeg save time = 960*540 / 10**6 / 166 = 0.003 s
    Total speed = 1 / (0.0115 + 0.0069 + 0.001 + 0.003) = 44 op/s

    Итого, 44 операции в секунду на одном ядре. Или 44×36 = 1584 операции в секунду на процессоре за ту же цену.


    Плюс практически пропорциональное увеличение производительности при уменьшении входного разрешения (как вы видите, для видеокарты при переходе от 2К к 1К производительность практически не растет). Плюс отсутствует необходимость проставлять рестарт-маркеры или иным образом модифицировать исходный контент. Плюс большая гибкость в выборе и добавлении других операций (не требуется перекомпиляция) или форматов. Плюс возможность разрабатывать и тестировать на обычном рабочем ПК или ноутбуке.


    Минус только в задержке. В случае обработки на CPU одно изображение все равно будет ресайзится минимум за 23 мс, тогда как на GPU этот показатель от 1,1 до 1,5 мс.

  • Быстрый ресайз джипегов на видеокарте
    +1
    В оффлайне с помощью ImageMagick, OpenCV или аналогичного софта, сохраняем цветовой профиль

    Забавно, что вы упоминаете OpenCV, потому что в ней нет вообще никакой возможности получить цветовой профиль. OpenCV — это библиотека компьютерного зрения, а не работы с зоопарком графических форматов.


    затем утилитой jpegtran добавляем рестарт-маркеры с заданным фиксированным интервалом.

    Интересно было бы узнать оптимальный интервал, хотя бы для конкретно вашего декодера.

  • Как сэкономить память на вкладках браузера, но не потерять их содержимое. Опыт команды Яндекс.Браузера
    0

    Вы как будто рассматриваете не реализацию гибернации в реальном мире, где уже есть подкачка и планировщик (откровенно не очень хорошего качества), а рассказываете, как было бы классно, если бы приложение работало в идеальных условиях, где кроме браузера ничего не запущено, а подкачки нет. У вас подкачки нет, хорошо, вы конечно очень важный пользователь для Яндекс.Браузера, но сомневаюсь, что эту фичу делали для вас одного.


    ОС как раз не знает — предполагает.

    ОС как раз точно знает, какие страницы использовались в последнее время.


    В уже приведенном примере — для меня какая-то вкладка в браузере — всегда горячие данные. я хочу их в любой произвольный момент времени в памяти, а не в свопе

    И в чем отличие от гибернации? Что будет держать вашу любимую вкладку в памяти при гибернации?


    Простите? Если это моё приложение и весь код — тоже мой, я точно знаю какой код какие данные использует и зачем.

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


    Что ж тогда при её использовании максимум на 50% в своп что-то валится?

    Это элементарное логическое утверждение. Из того, что А является причиной для B никак не следует, что других причин у В быть не может. Я уже говорил, что в виндусе дисковые операции активно вытесняют память приложений в своп.


    Да, я в курсе про мантру «выгрузить всё что редко используется и отдать память кэшу» — но я этого не хочу

    Да еще раз, никто сейчас с вами не обсуждает релизацию подкачки в винде и линуксе. Это вообще не тема статьи и не во власти разработчиков браузера. Им уже дан сверху этот механизм, который как-то работает и им нужно в этих условиях что-то сделать полезное. Ваш прекрасный выдуманный мир, где вы собственноручно решаете какой процесс нужно выгрузить, я рассматривать не хочу.


    Потому что я могу поставить на вкладке метку «не трогать»

    Что-то я видимо невнимательно прочитал статью, что не заметил там никаких меток. Опять какой-то придуманный мир?

  • Как сэкономить память на вкладках браузера, но не потерять их содержимое. Опыт команды Яндекс.Браузера
    0
    ОС не имеет понятия о том что является горячими или холодными данными для приложения

    ОС как раз знает по факту, какие данные являются горячими. А приложение может лишь предполагать, потому что приложения большие и сложные и то что ваш код не использует какие-то данные, не значит что их не использует какой-то другой код.


    простой факт длительного неиспользования или редкого использования (пусть даже с элементами эвристики или даже AI) — вовсе не показатель того что память можно выгружать (это зависит от задачи).

    Верно. Показатель того, что память можно выгружать — наличие виртуальной памяти и подкачки. А показатель того, что память нужно выгружать — нехватка памяти. Что именно выгружать — вопрос алгоритмов ОС. Тут все просто — либо мы хотим многозадачности и тогда нужна подкачка и выгружать можно всё что угодно. Либо мы хотим сами управлять, что выгружать, тогда наш выбор однозадачность. Но что-то я не слышал, чтобы яндекс-браузер можно было загрузить в однозадачном режиме вместо ОС.


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

    А гибернация знает заранее? )

  • Как сэкономить память на вкладках браузера, но не потерять их содержимое. Опыт команды Яндекс.Браузера
    0

    Каким образом контролируемое поведение в отрыве от всего остального может помочь? Вы можете например на бумажке карандашом исполнять процессорные инструкции, будете иметь 100% контроль над выполнением, но ускорения программы вы этим конечно же не добьетесь.

  • Как сэкономить память на вкладках браузера, но не потерять их содержимое. Опыт команды Яндекс.Браузера
    0

    Жаль, что мое вопросы выше остались без ответа (

  • Как сэкономить память на вкладках браузера, но не потерять их содержимое. Опыт команды Яндекс.Браузера
    0

    Вы несёте бред. Подкачка — это стандартный механизм всех ОС начиная с windows 3.1. Именно благодаря подкачке стала возможна истинная многозадачность и сильно упростилась разработка приложений, т.к. каждому приложению больше не нужно писать свой менеджер памяти. Память теперь условно бесконечная.


    Ну а то, что вы её отключили — так это ваше дело. Вы может ещё половину экрана закроете картоном и будете кричать, что разработчики совсем обленились, не оптимизируют программы, чтобы на половине экрана были доступны все функции?