Разница радикальная. Когда мы говорим что процесс вкладки лежит в свопе, значит есть нехватка памяти и WorkingSet этого процесса сжат, страницы выгружены на диск. При переходе в эту вкладку и пробуждении потоков им требуются страницы, которые лежат в свопе. ОС потребуется сжать WorkingSet других процессов, чтобы освободить RAM, куда загрузить страницы из свопа. Т.е. потребуется сначала сохранить в своп «не нужные» страницы, а потом загрузить «нужные». И таких страниц в 5-10 раз больше чем нужно для сохранения в режиме Hibernate.
Таким образом с Hibernate нужно прочитать с диска объем X данных и при этом в системе достаточно свободной памяти, WorkingSet других процессов не сжимается. А в обычном случае это запись X*10 + чтение X*10. Т.е. дисковой активности в 10-20(!) раз больше. Пользователи с медленными жесткими дисками это очень хорошо заметят.
Все правильно говорите. Можно сделать лучше.
Я же просто продемонстрировал что даже скопировав код, не углубляясь в тонкости GPU, можно получить ускорение по времени в 10 раз.
Сложность алгоритма O(n^4). И эта теория отлично согласуется с практикой, увеличение N в 2 раза увеличивает время в 16 раз.
Если взять лучшее время 12.8 секунд для CPU #2 на размере N=1500, то увеличение N в 4 раза увеличит время в 256 раз, до 54,5 минуты.
Т.е. примерно за час на CPU можно посчитать для N=6000.
По прагматичным причинам в первую очередь. Например потому что браузер, в котором вы читаете это сообщение, написан на с++, и переписать его на Rust стоит миллионов человеко-дней, что довольно долго и ну очень дорого.
Еще были модули расчетов, которые считали древней фортрановой библиотекой. И эта библиотека была с багом, и проезжала через раз по памяти. По этому расчет делался через отдельный процесс, данные в который передавались и забирались через memory-mapped file. Эдакая схема изолированный процессов как в chromium, только для бедных.
Вот в этом и была самая веселая часть — графика была на C#+WPF. Все это экспортировалось через COM. А дельфи — это основное приложение, грузило COM-библиотеку, и управляло всем.
Т.е. на скриншотах видно, что приложение — VCL, а внутри живет окно, на котором рисует WPF.
Не совсем.
Некоторое время работает, но потом кончается память и студия крашится. Особенно если запускать браузер под отладкой.
Если не пишу код, а отлаживаю, то автокомплит не сильно нужен, и я загружаю из солюшена только несколько запускаемых проектов с помощью расширения funnel visualstudiogallery.msdn.microsoft.com/5396fa4a-d638-471b-ac3d-671ccd2ea369
В этом случае все точки останова ставятся, отладка полностью работает, и студия работает достаточно стабильно, по крайней мере падений из-за кончившейся памяти нет.
Поставил ReSharper C++, попытался открыть chrome.sln, содержащий чуть более тысячи под-проектов. Это был текущий мастер хромиума www.chromium.org. Не взлетело. Студия подвисла, видимо решарпер сканирует проекты (Intellicense заранее выключил). Решил подождать, было очень интересно справится или нет. Через час студия упала, скорее всего из-за нехватки памяти. Попробовал еще 2 раза, результат неизменный — падает когда кончается адресное пространство. Очень жаль.
На 4ый запуск в студия перестала так зависать и появилась возможность работать. При этом показывается прогресс сканирования файлов (Updating source files) примерно на половине. Открыл файл, решарпер показывает иконку Analisis will start shortly. Уже 15 минут.
Вообще это боль, что студия не может стабильно работать с такими большими проектами. Встроенный intellisence более-менее справляется, но и ему памяти не хватает, сначала отваливается показ переменных в отладчике, а еще чуть погодя студия крашится.
Здесь все понятно — против лома нет приема. i7 перемолотил i5 вчистую.
А вот для меня не понятно, из-за чего такая разница в результатах, да частота ниже (но не в 2 раза), да кэш меньше. Не ужели тест на столько кэш-зависмый?
Если в Linux запросить выделение большого блока памяти с помощью malloc(), то вместо того, чтобы выделить память в куче, стандартная библиотека C задействует механизм анонимного отображения. Слово «большой», в данном случае, означает величину в байтах большую, чем значение константы MMAP_THRESHOLD. По умолчанию, это величина равна 128 кБ, и может контролироваться через вызов mallopt().
Столкнулся с несколько другим поведением. Программа выделяла много памяти блоками по несколько мегабайт. В процессер работы, если блок становился маловат он удалялся, а вместо него выделялся чуть большего размера. В windows все работало как надо, а в ubuntu конце концов заканчивалась вся оперативная память (все 32 гигабайта). Дело было в фрагментации адресного пространства и в том что системе не возвращаются «свободные» сегменты адресов, они остаются замапленными на физическую память. Переделал выделение памяти на анонимный mmap, тогда все нормализовалось.
Помогает, переключается, но видеорежим не поддерживается монитором, или как-то криво поддерживается что ничего не видно, по экрану бегут полосы. Точнее видно когда печатаешь, что символы воодятся, можно даже залогиниться, но надо же будет прочитать что-то, а буквы то расплываются по всему экрану!
> Казалось бы что такого — 2 видеокарты Nvidia(680 и 560), 2 монитора. Но установка драйверов тот еще квест. Для установки драйвера надо остановить сервис lightdm.
Да, инструкцию я прочитал, и сделать то как там написано легко. Но мешало именно то, что восхваляемая консоль не работала — я просто не видел что там пишется в мешанине линий. А квест заключался именно в том чтобы заставить кончоль отображаться нормально.
большинство пользователей не хотят и не будут разбираться в устройстве ОС и что-то делать руками. Они просто пойдут и поставят ОС, которая имеет нужный функционал и не требует особых телодвижений, пускай и за деньги.
Таким образом с Hibernate нужно прочитать с диска объем X данных и при этом в системе достаточно свободной памяти, WorkingSet других процессов не сжимается. А в обычном случае это запись X*10 + чтение X*10. Т.е. дисковой активности в 10-20(!) раз больше. Пользователи с медленными жесткими дисками это очень хорошо заметят.
Я же просто продемонстрировал что даже скопировав код, не углубляясь в тонкости GPU, можно получить ускорение по времени в 10 раз.
Если взять лучшее время 12.8 секунд для CPU #2 на размере N=1500, то увеличение N в 4 раза увеличит время в 256 раз, до 54,5 минуты.
Т.е. примерно за час на CPU можно посчитать для N=6000.
Вот в этом и была самая веселая часть — графика была на C#+WPF. Все это экспортировалось через COM. А дельфи — это основное приложение, грузило COM-библиотеку, и управляло всем.
Т.е. на скриншотах видно, что приложение — VCL, а внутри живет окно, на котором рисует WPF.
Некоторое время работает, но потом кончается память и студия крашится. Особенно если запускать браузер под отладкой.
Если не пишу код, а отлаживаю, то автокомплит не сильно нужен, и я загружаю из солюшена только несколько запускаемых проектов с помощью расширения funnel visualstudiogallery.msdn.microsoft.com/5396fa4a-d638-471b-ac3d-671ccd2ea369
В этом случае все точки останова ставятся, отладка полностью работает, и студия работает достаточно стабильно, по крайней мере падений из-за кончившейся памяти нет.
На 4ый запуск в студия перестала так зависать и появилась возможность работать. При этом показывается прогресс сканирования файлов (Updating source files) примерно на половине. Открыл файл, решарпер показывает иконку Analisis will start shortly. Уже 15 минут.
Вообще это боль, что студия не может стабильно работать с такими большими проектами. Встроенный intellisence более-менее справляется, но и ему памяти не хватает, сначала отваливается показ переменных в отладчике, а еще чуть погодя студия крашится.
А вот для меня не понятно, из-за чего такая разница в результатах, да частота ниже (но не в 2 раза), да кэш меньше. Не ужели тест на столько кэш-зависмый?
Столкнулся с несколько другим поведением. Программа выделяла много памяти блоками по несколько мегабайт. В процессер работы, если блок становился маловат он удалялся, а вместо него выделялся чуть большего размера. В windows все работало как надо, а в ubuntu конце концов заканчивалась вся оперативная память (все 32 гигабайта). Дело было в фрагментации адресного пространства и в том что системе не возвращаются «свободные» сегменты адресов, они остаются замапленными на физическую память. Переделал выделение памяти на анонимный mmap, тогда все нормализовалось.
Да, инструкцию я прочитал, и сделать то как там написано легко. Но мешало именно то, что восхваляемая консоль не работала — я просто не видел что там пишется в мешанине линий. А квест заключался именно в том чтобы заставить кончоль отображаться нормально.
А разве это плохо?