Можно ли ускорить расчёты?

Я не дизайнер, я не программист, я не инженер, я просто любитель возится с компьютерами, зарегился и написал сюда только для того, что бы моя работа не пропала зря и возможно ещё кому-нибудь помогла.
Началось всё с того, что друг попросил меня прокачать и без того не слабый компьютер с мощным процессором Intel Core i7-3770K и 16 гигами оперативной памяти, для того, что бы ускорить расчёты в некой программе DIALux evo Версия 5.1.0.12411.(некоторые расчёты могут происходить по часу с лишним), собирался купить твердотельный диск. Так как внятной информации о самой программе и принципе её работы я от него не получил, пришлось скачать самому, установить на собственный компьютер и провести серию экспериментов для того, что бы решить в какую сторону следует прокачивать комп. Ниже приведу описание эксперментов с выводами и рекомендациями. Для тех кто далёк от компьютерных заморочек и непонятны некоторые аспекты, для разъяснений рекомендую воспользоваться поисковиками безкрайнего интернета.
МОй компьютер тоже имеет не слабый по нынешним меркам процессор Intel Core i7-3770 и 16 гигов оперативы, но я использую 86х Win7, а невидимую более 3,2 гб память(почти 13гб) превратил в виртуальный винчестер и перекинул тудя временные папки и подкачку, так же подтверждаю, что этот виртуальный винчестер в десятки раз быстрее любого твердотельного диска, хотя и сам физический твердотельный диск в системе имеется. Для экспериментов я создал некий, неизменяемый в последствии, абстрактный проект из произвольно расположеных объектов и светильников, с относительно малым временем обработки для уменьшения времени на проведение тестов. После большинства замеров перезагружал систему, что бы уменьшить погрешность системного кэширования.

ПРограмма мучает винт в трёх местах:
1) Исполняемая папка (статична, но увеличивается в размерах по мере добавления новых моделей, текстур и объектов, легко перемещается в любое место и работает без установки оттуда)
2) Времянка (мусорная папка TEMP, растёт по мере обработки и расчётов, обнуляется сама как только закрыт проект и программа)
3) Обращение к Винде (фоновое, служебных или парралельных программ, возможно библиотеки DX или другие)

Время запуска программы и открытие проекта в расчёт не беру, учитывается только время от начала старта расчётов, до появления окончательной картинки с разгрузкой проца.
Видеокарта в программе практически не работает, её производительностью можно пренебречь.
ПРоцессор работает весьма странно, похоже что большую часть времени он перекладывает информацию с винта в память, из памяти в подкачку из подкачки снова в память, что-то во времянку, что-то из времянки, но в большинстве ядра простаивают в лёгкой 5-20% общей нагрузке, при этом одно из ядер загружено на 50-85% когда другие почти спят или только 2 ядра работают по 40%, используются в большинстве расчётов только 4 физических ядра, а 4 логических напрягаются крайне редко. Конечно бывают моменты 90-100% нагрузки всех ядер, но бывает это крайне редко и длится очень недолго.

Прога на винте, времянка на винте (классический компьютер)
03:26(мин:сек)
03:20

Прога на винте, времянка в памяти. (программно усовершенствованный классический компьютер)
03:13
03:15

ПРога на твёрдотельнике, времянка в памяти.(компьютер с твердотельником программно усовершенствованный)
03:15
03:17

Прога в памяти, времянка в памяти. (компьютер с ооочень быстрым твердотельником)
03:16
03:16

ПРога в памяти, времянка в памяти, винда на твердотельнике (быстрее только компьютер весь обвешаный дико скоростными твердотельниками, физический винт практически не подаёт признаков жизни, всё работает в памяти или твердотельности)
03:15
03:14

Погрешность измерений +/- 1 сек.

Выводы напрашиваются сами: Как мы видим, от файловой системы (преимущство в которой даёт твёрдотельник) программа почти не зависима, на лицо простейшая неоптимизация программы под многоядерники и работу с многопоточностью, то есть разгон проца, разгон памяти, увеличение количества ядер - прироста в скорости не обеспечат. Прирост появится только с новой, более оптимизированной на многопоточность версией программы.
Получить лёгкое ускорение можно простыми манипуляциями с переносом временной и исполняемой папки в оперативную память. Использование же твердотельника лишь ускорит запуск самой программы и виндовса с приложениями, но в длительных расчётах даст лёгкое ускорение только в том случае, если мусорная папка и подкачка останутся на твёрдом диске, что общепризнанно не рекомендуется для продления жизни твердотельника, в противном случае сдохнет раньше времени от износа ячеек, что кажется не является гарантийным случаем.
По теоретическим расчётам это "лёгкое ускорение" будет примерно равно 3 минутам на 1 час расчётов, что явно не оправдывает покупку твердотельника 128гб за 5 штук.


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

2 одновременно (1 на винте, 1 в памяти, времянка в памяти)
03:28 (для сравнения 1 выполняется в памяти за 3:15)
визуально процессор загружен 4 физических ядра в сумме(4потока) на 40-50%, винт почти не работает.

3 одновременно (1 на винте, 2 в памяти, времянка в памяти)
04:03
визуально процессор работает уже в 6 потоков, хотя загружены по 60-70% только 4 из них. Винт по прежнему отдыхает. Во времянке мусор от программы увеличился трёхкратно, следовательно количество обращений к физическому винчстеру на обычном компьютере тоже ощутимо вырастет. Увеличение времени могу объяснить тем, что в самый последний момент расчётов обычно около 5-10 секунд идёт 100% загрузка процессора по всем потокам, что вызывает задержку в остальных расчётах и соответсвенно остальные расчёты тормозят финальную стадию, от того и время синхронной обработки вырастает по экспоненте. Закономерно предположить, что если финальные стадии не совпадут, то время выполнения будет чуть меньше.

4 одновременно (1 на винте и 3 в памяти, времянка в памяти)
04:06
Вот, теперь точно видно что все 8 потоков пашут... правда общая нагрузка проца не превышает 50% до последней стадии, на которой выпал неприятный сюрприз - третья программа прекратила расчёты выдав ошибку. Разобравшись, выяснилось, что тупо закончилась память в оперативке и файле подкачки(система 86х). Закрываем пару ёмких приложений, увеличиваем подкачку до максималки 4096мб(подкачка сидит в памяти). Хотя возможно ограничения файловой системы FAT32 виртуального винчестера не позволяют нарастить размер файла более 4 гигов.
04:55
памяти впритык хватает, но увы, 4-ая программа тупо вылетела с ошибкой, дальнейшие эксперименты на 86х битной системе не возможны.

5 одновременно - вылет системы и повально работающих прог после сообщения "закончилась свободная память"

4 поочерёдно с задержкой запуска в 20 сек (все 4 и времянка в памяти)
06:35
Памяти хватает, загрузка процессора 60%, под конец около минуты на 100%, но всё завершилось нормально, без ошибок и вылетов.

Вывод: Можно производить параллельные расчёты различных проектов при достаточном количестве памяти и подкачки, 4-5 на 86х разрядной системе и думаю 8-9 на 64х битной системе, при условии наличия мощного процессора. Вот тут уже размер и скорость оперативной памяти, увеличение частоты и количества ядер процессора, в комплексе с ускорением файловой системы (любым из способов) может дать более реальный прирост ОБЩЕЙ производительности, ЧЕМ при одиночном выполнении, но опять же с оговоркой, что длительность выполения увеличивается экспоненциально возрастанию числа палалельных расчётов. Во время расчётов даже 3-х задач компьютер довольно таки отзывчив и позволяет выполнять стороннюю деятельность в виде работы антивируса, офисных приложений, интернет-сёрфинга, паралелльной работы с очередным проектом, но во время звершения расчёта проекта идёт 100% нагрузка практически парализующая компьютер и она длится тем дольше, чем больше проектов в этот момент расчитывается, тут уже может всё капитально подвиснуть на какое то время. Вот уж действительно стоящая задачка для 6-ти и 8-ми ядерных процессоров с количеством потоков более 12 штук...

Если подойти с умом, то работа с конкретным проектом явно ускорится, если её параллельно разрабатывать в нескольких версиях. Например пока рассчитывается одно положение объектов или тип светильников, можно не терять времени и передвинуть объекты установить другие светильники вновь запустить на обработку, потом не дожидаясь переключиться на совсем другой проект с вновь подошедшим клиентом и так далее... При этом, если один из проектов завершится с ошибкой, то другие не пострадают и продолжат выполнятся. Кстати, если требования проги к ресурсам на столько минимальны, то вообще можно и другие компы в помещении напрячь на расчёты, хотя бы по паре проектов на комп.
NB: Если рабочая папка программы под завязку нагружена различными базами, текстурами, 3Д объектами(чего пока нет у моёго знакомого), то пожалуй в процессе работы (до запуска расчётов) действительно может пригодится твердотельный диск или виртуальный винчестер в памяти, однако, я уверен, что на длительность самого расчёта это почти не повлияет.

24 Декабрь 2012 в 22:13
Как ни странно, но история получила продолжение и теперь я тестирую уже другую версию DIALux 4.10. Конфиг системы тот же, разве что снова пришлось стряпать тестовый проект, т.к. проекты разных версий этих программ не совместимы. Принцип работы файловой системы я уловить не смог, да и особого различия в скорости работы с винчестера или в виртуальной памяти мною замечено не было, потому твердотельность компьютера не обсуждаю.

После непродолжительного общения с приложением меня осенило, эта проклятая примитивная прога использует всего 1 поток для вычислений, а разбивает нагрузку по ядрам сама винда, потому при работе ни один поток ни когда не загружен на 100%. Сразу напрашивается целых 2 вывода: 1) Крутые многоядерники с кучей потоков на хрен не нужны. 2) Надо как то ускорить один единственный поток вычислений. Похоже, я ошибался, когда заявлял ранее о том, что разгон процессора и памяти бесполезны. Проводим десяток экспериментов с различными частотами процессора и памяти, дабы опровергнуть или подтвердить это утверждение.
Так как оверлокингом я не увлекаюсь, то ограничусь автоматическим разгоном в биосе от Asus, а для замедления частоты процессора просто отключу режим Turbo. Частоту памяти меняю вручную.

память замедленна до 1333 среднее время расчёта
04:37 (мин:сек)

обычная частота 1600
04:35

память разогнана до 1866
04:31 похоже криво разогналась или всё же зависимость скорости расчётов от частоты памяти минимальна.

понижение частоты процессора до 3,5
05:10

В норме для моёго процессора 3,9
04:35

повышенная частота 4.2
04:20

Вот оно. Наконец, хоть какой-то имеющий смысл результат. То есть, чем быстрее процессор, тем быстрее получим результат, однако с маленькой оговоркой, предположить реальное ускорение на очень больших частотах весьма затруднительно, т.к. зависимость может оказаться не линейной. Однако это ещё не всё, в результате экспериментов выяснилась одна любопытная особенность. Оказывается(в моём понимании) многозадачность и многоядерность для Win7 это понятия условные, так как даже при незначительной нагрузке процессора сторонними программами длительность расчёта значительно возрастала. Похоже виновата сама винда, которая распределяет нагрузку между ядрами равномерно, т.е. от действующего на момент расчётов ядра отхватывается часть ресурсов на выполнение сторонних задач, хотя другие ядра с сторонними задачами могут справиться самостоятельно. Повышение приоритета процесса DIALux.exe результата не дало, осталось попробовать включать и отключать "лишние" программы.

открыто много приложений среднее время расчёта
04:48

мало приложений
04:35

закрыты все сторонние приложения и убиты все лишние задачи
04:29

Ещё один хороший результат исследования. Попробуем их объединить:

повышенная частота процессора 4,2 память замедленна с 1600 до 1333, закрыты все приложения
04:14

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

повышенная частота процессора 4,2 память замедленна с 1600 до 1333, закрыты все приложения и убиты все лишние задачи
04:10

И так, подытожим всё, что удалось узнать: Для ускорения работы программы нам НЕ НУЖЕН комп с навороченным многоядерным процессором, уймой гигабайт памяти, производительной твердотельной дисковой системой и мощной игровой видеокартой. Более предпочтительным получается конфигурация с изначально скоростным и в последствии хорошо разогнанным двух-четырёх поточным процессором(i3, i5; X2, Х3), свежий(не загаженный различными программами) виндовс и желательное использование этого компьютера только под программу DIALux или отключение всего прочего софта на время расчётов.

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

Leo-EX, спасибо Вам огромное за такие тесты. Полезное дело делаете.

Leo-EX, а вы не могли бы повторить тест в новой версии, Dialux Evo. Немцы говорили, что там уже поддерживается многопоточность )

Тестирую новые версии программы.

DIALux EVO 2.2
Увы, прошлый тестовый проект не сохранён, начинаю стряпать заново, ворочаю около 300 простых геометрических объёктов, ляпаю примерно 350 светильников, запускаю расчёты и ... Вылазит сообщение "Недостаточно свободной памяти, что бы выполнить расчёт"... Опа, приехали, 3 Гб оперативной памяти на х86 Win 7 съедается в момент. Вот это огорчение, при всём притом, что в рекомендуемых системных требованиях "2GB RAM minimum", в более старой версии таких проблем не возникало. Пожалуй, будет не лишним переход на х64 да и 16 гигов оперативной памяти окажутся вовсе не роскошью, а необходимостью. Уменьшил количество объёктов до 200, но добавил светильников до 400. Памяти хватает, можно тестировать дальше. Немного удивил тот факт, что во время создания проекта ожила видеокарта, вот только работает она не слишком интенсивно, где-то на уровне 30% мощности и то, если очень активно вращать картинку. В расчётах по-прежнему участвует только центральный процессор, потому заморачиваться покупкой мощной игровой карты для Диалюкса точно не советую.
Ещё раз извиняюсь, что утверждал в начале статьи, будто скорость процессора значения не имеет. Впоследствии я сам же опроверг собственное утверждение при тесте DIALux 4.10, потому эксперименты с разгоном я повторять не стану.
Теперь будем проверять оптимизированность программы под многоядерные процессоры. Появилась у меня одна идея, которую я тут же опробовал в действии. В диспетчере задач Win 7 приложениям можно «Задать соответствие…» с какими ядрами(потоками) нужно работать, а какие не использовать. Выяснилось, что при запуске расчётов появляется исполняемый файл Dialux.CalcExtProc.exe, который нагружает процессор примерно на 60% времени от расчётов, после чего он выгружается, далее расчёты проводятся файлом DIALux.exe. Я отключаю по очереди ядра для упомянутых процессов и засекаю, сколько времени потребуется на обсчёт тестовой задачи. Опытным путём установлено, что оба файла большую часть времени нагружают примерно 2 ядра, т.е. если оставить им одно ядро, то время выполнения задачи увеличивается в 2 раза, а при доступности двух ядер решение задачи лишь на несколько секунд дольше, чем когда доступы все 4 ядра и 8 потоков. К сожалению, сказать сколько потоков задействовала предыдущая DIALux evo Версия 5.1.0.12411 я сейчас не могу, но для новой версии программы трёх и четырёх ядерные процессоры явно будут желательнее, нежели двух или совсем одноядерники. Хоть программа и задействует только 2 потока, но не забываем про нужды системы и дополнительное программное обеспечение, которое тоже съедает часть ресурсов процессора.
Работа файловой системы сильно смахивает на описанную в самом начале старую версию. Запуск программы из виртуального диска в памяти приятно ускоряет в 2 раза старт программы и открытие проекта, но сокращает сами расчёты только на 1-2 секунды. Покупка твердотельника по-прежнему не оправданна, потому как реальный прирост скорости расчётов почти незаметный, но подкачка и временные файлы износят дорогостоящий диск весьма быстро.
Фишка с многократным запуском программы и параллельным обсчётом замечательно работает. Моя система, описанная в самом начале, вполне комфортно справилась с тремя обсчитывающими клонами, однако, при попытке четырёхкратного запуска две программы сообщают "Недостаточно свободной памяти, что бы закончить расчёт". Ещё один довод в пользу х64 системы с 8Гб и более оперативной памяти. Не забываем, что для параллельного обсчёта нескольких копий программ действительно понадобится многоядерный процессор из расчёта по 2 потока на каждую запущенную DIALux EVO, а к итогу прибавить 1 поток под нужды системы.
PS. На 64-х битной системе я программу не тестировал, потому объём реально требуемой оперативной памяти лишь предполагаю. Касаемо всего остального, думаю будет работать аналогично х86. Так же не могу утверждать со 100% вероятностью, что дешёвая видеокарта начального уровня позволит обеспечить комфортную работу с очень большим проектом(например модель освещения крупного города), за неимением в моём распоряжении таковых.

DIALux 4.11.0.3
Создаю произвольный проект и начинаю изучать. Расчёт делаю повышенной точности, учитывая все объёкты. Работа программы с виртуального винчестера прироста скорости не обеспечила, значит твердотельник по-прежнему излишен. Около 80% времени расчёты выполняются процессом DLXRadical.exe окончательные вычисления приходятся на DIALux.exe. Прогоняю тест на 8 потоках, засекаю время, потом на 1 ядре для обоих исполняемых файлов - время расчётов увеличилось на пару секунд, затем на двух ядрах - время такое же, как и на полном процессоре. Вывод неутешителен, на лицо прежняя однопоточность вычислений, для работы программы будет вполне достаточно двухядерного процессора. Если возник вопрос, что выбрать - четырёхядерник с частотой 3.0 GHz или двухядерник 3.8 GHz, то для текущей версии программы желательнее делать выбор в пользу последнего. Пробую тестовый проект в 3D проекции с просчитанным освещением подвигать средней кнопкой мыши - картинка двигается скачками. Это не означает слабость видеокарты, это 3D реализация в DIALux хромает. В подтверждение, nvidiaInspector показывает всего лишь 50% загруженность графического процессора, всё же остальное время, включая расчёты, видеокарта блаженно спит. Пожалуй, и для этой версии Диалюкса покупка топовой игровой видеокарты равносильно убиванию маленького паучка большой кувалдой. Фокусы с клонированием по-прежнему невозможны - при попытках параллельного запуска нас переключает на основное окно программы с текущим проектом... А теперь внимание! Хорошая новость - на меня снова снизошло озарение. Если нельзя клонировать программу, то ни кто не мешает нам клонировать компьютер! Использую бесплатный Oracle VM VirtualBox, устанавливаю нетребовательную ХР, выделяю ей одно ядро и 512 мб памяти(можно и больше), делаю ей доступ к сетевой папке с проектами и спокойно обсчитываю 2 проекта одновременно, один на реальной, а второй на виртуальной системе. «Виртуальный» Диалюкс почти не тормозит, позволяет не только считать, но и относительно комфортно редактировать проект. Чем больше ядер с оперативной памятью имеет компьютер, тем больше виртуальных ХР`шек можно открыть и работать одновременно с большим числом проектов или с различными вариациями одного творения. Главное не запутаться в окнах и проектах, но ни кто не мешает вам подключить дополнительные мониторы к компьютеру для удобства отображения клонов. Вот тут уже и память лишняя перестаёт быть таковой и крутой многоядерник начинает кипеть, честно отрабатывая вложенные в него средства.

Подведём итоги.
На мой "не дизайнерский" взгляд изменения в основном коснулись исправления ошибок и оптимизации внешнего интерфейса программы. DIALux EVO работает в 2 потока(жаль у старой для сравнения не измерил), жрёт много памяти, но реже вылетает с ошибкой и будто бы получила поддержку 64х битных систем. Простой DIALux, не смотря на внешнюю красивую "шкурку", по-прежнему прячет под ней старый однопоточный алгоритм расчётов. Будем надеяться, что создатели программы пойдут на встречу пользователям и оптимизируют расчёты под многоядерные процессоры, или даже обратят взор в сторону вычислений при помощи видеокарт, например используя ядра CUDA. Страшно подумать, сколько чашек кофе выпито по всему миру в ожидании того, как даже самые мощные компьютеры по часу переваривают на холостом ходу относительно не сложные расчёты больших проектов.

Комментарии, вопросы, критика и предложения приветствуются.

Спасибо большое за проделанную работу. Статья оказалась очень полезной. В данный момент как раз стоит такая проблема. Считаю очень большие проекты. Расчет занимает около 1,5 часа. После последнего обновления до версии DIALux 4.12. Скорость работы только упала и повылезало целая куча глюков.

Вы не тестировали эту версию?

Пока я, на досуге, не спеша, тестировал DIALux EVO 3.0, уже выпустили аж две версии 3.1 и 3.2. Повторять тесты на новой версии я уже не стал, только проверил работу программы в общих чертах и ни каких явных различий от версии 3.0 не нашёл, даже график нагрузки процессора один в один такой же(видать только пару мелких багов исправили). По сему, можно считать, что эта публикация равноценна для DIALux EVO 3.0 - 3.2, а может даже и последующих 3.3, 3.4…


Особенности работы файловой системы и зависимость от скорости носителей информации.

Один расчёт проекта размером 550 кб записал на системный винт в корневой каталог файл $LogFile 350мб и столько же по пути c:UsersПользовательAppDataLocalDIALGmbHDIALuxDIALuxProjectTempDXjc3heoalProjectResults в виде кучки временных файлов (Файлов: 89; папок: 25), которые удаляются при закрытии проекта. В сумме около 700мб за единственный пятиминутный обсчёт маленького проекта! Для обычного винчестера это означает лишь интенсивную нагрузку, но для твердотельного диска режим такой эксплуатации равносилен смертельному приговору. В данном случае, единственным выходом для ускорения файловой системы (при явной необходимости) будет покупка винчестера Western Digital VelociRaptor. Такие скоростные винчестеры имеют достаточно большой размер, приспособлены к интенсивным нагрузкам, надёжны в плане долговечности(сохранности информации) и при этом работают примерно на 25-30% шустрее обычных винчестеров, рекомендуемых под системные диски. Стоимость данной экзотики примерно в 2 раза выше обычного винчестера такого же объёма, но при этом в 3-4 раза дешевле твердотельных дисков и способны выдержать очень длительную интенсивную нагрузку без оглядки на количество записанной информации.

Время запуска программы и открытия проекта, от двойного клика по иконке, до появления изображения проекта: Винчестер 18 сек., SSD 15 сек., Виртуальный диск в памяти 13 сек. Время обсчёта проекта одинаковое для всех носителей информации.

Разница в скорости запуска конечно есть, но она не настолько критична (с моей точки зрения), как часто приводят в пример запуск фотошопа с кучей библиотек, когда время загрузки программы на обычном винте от 30 сек. может сократиться до 3 сек. на твердотельнике. С одной оговоркой, моя программа диалюкс чистая, без текстур, светильников и прочих объектов, а проект весьма прост и мал по размерам, т.е. профессионально "загаженная" программа и проекты весящие по сотне мегабайт будут открываться куда дольше, чем на более скоростных носителях. О нецелесообразности использования SSD я написал выше, виртуальные винчестеры из ОЗУ это слишком специфическое малораспространённое явление, мне осталось лишь упомянуть гибридные диски SSHD, которые имеют кэш из твердотельной памяти. Настольными версиями на момент написания являются модели 3.5" Жесткий диск Seagate Desktop SSHD 8Gb ST1000DX001 и 3.5" Жесткий диск Seagate Desktop SSHD 8Gb ST2000DX001. У таких винчестеров весьма быстрая загрузка Windows и быстрый запуск программы, но загрузка постоянно изменяющегося проекта, а так же работа с временной папкой DIALuxProjectTemp будет происходить со скоростью обычного винчестера, потому как гибридный винчестер кэширует в твердотельный буфер только часточитаемые неизменяемые файлы. Не так давно появилась информация, что SSHD ещё и запись кэшируют, но подробностей пока нет. Напоминаю, что явный прирост скорости расчётов файловый носитель не даст, посему средства лучше потратить на более мощный процессор или дополнительную оперативную память. Ну, а ежели совсем припрёт, компьютер долго загружается, программы медленно запускаются, диалюкс отягощённый громадной базой текстур и светильников заставляет лампочку винчестера беспрестанно мигать и постоянно слышится характерный стрёкот харда, то освободите системный винчестер хотя бы на четверть и выполните его дефрагментацию.

Раз уж было упомянуто кэширование, то могу поделиться маленьким секретом. Есть некая программа eBoostr, которая специализируется именно на кэшировании файлов. Так вот, если её правильно настроить(добавить исключения типов файлов и папок), да ещё и прикупить под кэш флешку USB 3.0(лучше в металлическом корпусе от перегрева) хотя бы на 8Гб(16 выгоднее), то даже без всякой дефрагментации у компьютера с обычным винчестером ощутимо повышается отзывчивость, уменьшается время загрузки системы и запуска программ(по мере кэширования). От себя могу порекомендовать Flash Silicon Power Marvel M01 USB 3.0 (8 или 16Gb, но не 32! - дохнут часто; форматируем в NTFS). В своём классе это конечно не самая быстрая флешка, но она однозначно шустрее флешек версии 2.0, даже в одноимённом разъёме. Она имеет металлический корпус, благодаря чему может работать круглосуточно, ну и цена не слишком кусается.


Оперативная память.

В программе явно чувствуется желание разработчиков усиленно пересадить всех пользователей на 64х битные системы и забыть о 32х(86х) версиях, причём делается это вполне недвусмысленно. При попытке обсчитать проект со множеством светильников и объектов, на начальной стадии предварительного расчёта вылазит сообщение программы о недостатке памяти, хотя на этот момент свободной памяти более гигабайта и у Windows в запасе есть весьма ощутимый резерв в виде файла подкачки. Убрав пару лишних объектов и светильников, мы получаем уменьшенный примерно на 90% от исходного проект, при расчёте которого размер свободной оперативной памяти не уменьшается ниже 800мб, а файл подкачки практически не задействуется, оставаясь такого же размера, хотя имеет полное право при необходимости вырасти ещё на несколько гигабайт. Вывод один, проблема нехватки памяти создателями программы явно притянута за уши, но как следствие, на 32х битных версиях вы теперь сможете сделать разве что проект освещения туалетной комнаты или в лучшем случае маленького офисного помещения на трёх человек. О более крупных проектах, без смены системы и программы на 64х версии, можете забыть. Ещё одним доказательством моей правоты является то, что при параллельном запуске из разных папок двух диалюксов и обсчёта одного и того же (слегка уменьшенного) проекта, видно, как активно начинает разбухать файл подкачки, как заканчивается свободная оперативная память, но при этом ни одна из копий программы не ругается на нехватку оперативной памяти. Получается слегка комичная ситуация, что на 32х битных системах из-за «нехватки» памяти, мы не можем обсчитать освещение большой комнаты с кучей объектов и светильников, за то можем произвести параллельный обсчёт десятка туалетов превосходящих в сумме по количеству объектов и светильников большую комнату в 2-3 раза... Парадокс...


Процессор. ЯдраПотоки. Частоты.

Итак, с дисками и памятью мы разобрались, переходим к самому интересному, к процессору.
Как и в предыдущей версии программы, общий расчёт выполняется двумя исполнительными файлами. Опытным путём, через диспетчер задач, было установлено, что сначала запускается Dialux.CalcExtProc.exe и рывками нагружает все доступные ядра процессора, после чего он пропадает и в работу вступает DIALux_x86.exe, заканчивая обсчёт(подготовку результатов) всего в один поток, который прыгает по ядрам отображая их малую скачкообразную активность. Получается, что главный вопрос ускорения вычисления программы теперь разбивается на две половинки, соответствуя двум вычислительным стадиям. Что бы наглядно понять, как это работает на разных процессорах, я поочерёдно отключал в биосе гипертрейдинг своёго процессора i7 и уменьшал количество доступных ядер, чем условно превращал свой i7 в другие процессоры или делал его на них примерно похожим(хотя кто-то может с этим сравнением и не согласиться). Для тех, кто не в курсе, что такое гипертрейдинг, то упрощённо, это разбиение физического ядра процессора на два логических, что позволяет более эффективно обсчитать несколько потоков, нежели обсчёт выполнялся бы на одном ядре. Пример - Если принять производительность одного физического ядра за 100%, то задействовав ГТ производительность каждого из двух логических ядер будет около 75%, что в сумме даст 150% производительности для физического ядра (% прироста зависит от индивидуальности программы). Частота процессора и памяти не изменялась, т.е. частота всех упоминаемых процессоров принимается как некая общая константа. Секундомером замерялась на глаз общая продолжительность первой стадии и общая длительность расчёта, а вторая стадия получалась путём вычитания первого результата из общего итога. К большому сожалению, у меня нет возможности погонять тесты на процессорах AMD, поэтому их производительность я предполагаю условно, ссылаясь на общепризнанный факт, что в большинстве приложений и игр, при одинаковых количествах ядер с частотами, конкурирующие процессоры выдают различный результат, по которому продукция AMD значительно уступает Intel.

1) 1 ядро 2 потока гипертрейдинг включен
(примерный аналог старого двухядерного процессора Intel Core 2 Duo или трёхядерник AMD)
07:55 (04:14) - 3:41
Общее (Dialux.CalcExtProc.exe) - DIALux_x86.exe, мин:сек

2) 2 ядра 4 потока ГТ вкл
(аналог Intel Core i3 или шестиядерник AMD)
05:44 (02:41) - 3:03

3) 3 ядра 6 потоков ГТ вкл
(Intel Core i5 или восьмиядерный AMD)
05:13 (02:10) - 3:03

4) 4 ядра 8 потоков ГТ вкл
(полноценный Intel Core i7)
05:06 (2:00) - 3:06

5) 1 ядро 1 поток ГТ выкл
(старый одноядерный процессор Pentium или двухядерник AMD)
09:17 (06:00) - 3:17

6) 2 ядра 2 потока ГТ выкл
(Intel Pentium последних поколений или четырёхядерный AMD)
06:10 (03:06) - 3:03

7) 3 ядра 3 потока ГТ выкл
(Intel Core i3 или шестиядерник AMD)
05:28 (02:22) - 3:06

8) 4 ядра 4 потока ГТ выкл
(Intel Core i5 или восьмиядерный AMD)
05:13 (02:06) - 3:07

Время выполнения первой стадии расчётов уменьшается при добавлении количества ядер, но при этом заметный рост производительности наблюдается только до примера №2(с ГТ) включительно и примера №7(без ГТ), далее рост есть, но уже не такой значительный. Практически одинаковое время длительности второй стадии расчётов говорит об однопоточности. Увеличенное время в примерах №1 и №5 объясняется тем, что процессу диалюкса пришлось конкурировать за вычислительные мощности единственного физического ядра с другими приложениями и компонентами системы. Кстати, в этих же примерах хорошо видно, как два виртуальных ядра гипертрейдинга быстрее обслуживают первую стадию расчётов нежели одно физическое ядро, однако заметно проигрывают в однопоточной второй стадии. Вывод - гипертрейдинг замечательно работает и отключать его не нужно. Т.е. если в некоторых старых компьютерных играх 2005-2010-х годов отключение гипертрейдинга у процессоров Intel приводило к возрастанию ФПС(это хорошо), то в диалюксе польза от наличия ГТ налицо. Тут мы явно видим, как в первой стадии расчётов при одном физическом ядре в примере №1 заметно уменьшилось общее время обсчёта благодаря гипертрейдингу, по сравнению с примером №5 или похожий результат с примерами №2 и №6. А в случае примеров №3 и №8 общий результат почти идентичен, не смотря на разницу между процессорами в одно физическое ядро.

Жаль, что не могу выложить снимок экрана для наглядности, но ежели посмотреть на суммарный график нагрузки процессора в первой стадии расчёта, то видно, как скачет нагрузка эквивалентно числу потоков. Примерно 50% времени интервалами идёт полная нагрузка в 7-8 потоков, около 10% приходится на 5-6 потоков и 40% 1-2 потока. Вторая стадия стабильно ползёт в один поток.

Проверял идею с попыткой ручной оптимизации потоков при использовании программы CPU Control. Суть работы данной программы - это возможность привязать конкретные процессы к избранным ядрам процессора, т.е. весь мусор с антивирусом, браузером и прочей вспомогательной шелухой садим на одни ядра, а процессам диалюкса предоставляем в монопольное пользование другие. Несмотря на различные вариации и комбинации, идея с треском провалилась, т.к. время выполнения расчётов наоборот увеличилось. Конкретных цифр не предоставляю, верьте на слово. Правда оговорюсь, что если у вас по стечению обстоятельств установлена старушка Win XP и есть хотя бы 2 ядра, то возможно прок от этой программы будет.

Близимся к концу. Игры с частотами оставлены на десерт, как самое перспективное направление.
В связи с тем, что множитель моего i7 заблокирован, то тесты с различными частотами я решил провести на стареньким двухядерном Intel Core 2 Duo. Частоты памяти старался не изменять и вот что получилось.

Частота процессора - общее время
1.6 - 25:54 (1554сек)

2.0 - 19:51 (1191сек)

2.4 - 16:42 (1002сек)

3.2 - 12:49 (769сек)

Если попытаться из этих данных построить график, то зависимость не совсем линейная, хотя и близка к ней. По графику приблизительно видно, что для сокращения решения гипотетической задачи длительностью в 1 час, хотя бы до 20 минут, двухядерный процессор надо разогнать в 2,5-3 раза от исходной частоты. Т.е. при стартовой частоте 2.6 разгон должен пробить потолок около 7 ГГц, а на таких частотах избранные процессоры(один из тысячи) как правило работают только у профессиональных оверлокеров, под жидким азотом, весьма не долго и с ошибками. Ежели использовать стабильный разгон удачного процессора, на воздухе с гигантским башенным кулером на трубках, то в самом лучшем случае достижимы всего лишь 4,4-4,6 ГГц при которых эта задача выполнится минут за 35. Как ни крути, даже если вы обладатель удачного процессора, заменив систему охлаждения и разогнав процессор, вы всё равно не решите часовую задачу за 5 минут, максимум сократите время расчёта на одну треть. Так что разгон процессора хоть и даёт самые ощутимые дивиденды, среди прочих ухищрений для диалюкса, но увы, прирост не такой большой как хотелось бы, да и оверлокерство всё же удел избранных.


Выводы по DIALux EVO 3.0 - 3.2.

Начинаем массовый перевод дизайнеров на 64х битные системы и докупаем оперативную память. Забываем про SSD и поглядываем на VelociRaptor или 3,5`` SSHD . Процессор теперь желателен как минимум четырёхпоточный, больше ядер – быстрее первая половина расчёта, со второй половиной пока всё очень кисло, однопоточно. Немного балуемся разгоном, эффект ускорения присутствует. Будьте осторожнее с программами-оптимизаторами, есть большой риск получить обратный эффект. Помним про фишку с многократным запуском программы и параллельным обсчётом. Продолжаем ждать от авторов программы чудес многопоточности, особенно во второй половине вычислений.


PS. Благодарю за внимание. Надеюсь, что вам было интересно и познавательно читать мою любительскую белиберду. На этом месте, к моему большому сожалению, я заканчиваю серию тестов программы DIALux EVO. Почему? Во первых, тесты с описанием отнимают много свободного времени, во вторых, переходить на 64х битные версии Windows я пока не собираюсь, в третьих, начало эры многопоточных вычислений в DIALux EVO уже положено, в четвёртых, наверняка найдутся такие же любители возиться с компьютерами, кто воспользуется накопленным мною опытом с предложенными способами тестирования, и продолжат начатое дело на благо всего светодизайнерского сообщества.

PS/2. Буквально перед публикацией мне всё таки подвернулся комп на 64х битной 7ке с установленным двухядерником АМД(A6-6400K), работающий на на чуть более высокой частоте, чем мой процессор. При беглом взгляде особых отличий в работе программы на 64х битной системе мною отмечено не было, однако, результаты работы процессора в тестовом проекте не могут быть проигнорированы.
14:37 (05:04) – 09:33 (сравнить с примерами №1, 5, 6)
Два ядра и два потока, а такой плохой результат. Пожалуй, мы в очередной раз на практике убедились в превосходстве архитектуры процессоров Интел над АМД. Единственным маломальским плюсом можно отметить, что за счёт двухядерности первая стадия расчёта выполняется быстрее, чем у одноядерного Интела, но дальше сплошные минусы. Уже во второй однопоточной стадии расчётов процессор АМД проигрывает почти с трёхкратным отставанием. Мало того, он сдаёт позиции даже старому процессору Intel Core 2 Duo, работающему на более низкой частоте и памяти DDR2. Так что к Выводам я добавляю следующий пункт: «Для ускорения расчётов в программе DIALux EVO более желательно использование процессоров фирмы Intel».

04 Июнь 2014 в 13:14
Если кому-то интересно, то вот вам использованный в исследовании тестовый проект для обсчёта. Можете сравнить свой результат с моими.

04 Июнь 2014 в 13:17
Если кому-то интересно, то вот вам использованный в исследовании тестовый проект для обсчёта. Можете сравнить свой результат с моими.

04 Июнь 2014 в 13:20
Если кому-то интересно, то вот вам использованный в исследовании тестовый проект для обсчёта. Можете сравнить свой результат с моими.

04 Июнь 2014 в 13:23
Если кому-то интересно, то вот вам использованный в исследовании тестовый проект для обсчёта. Можете сравнить свой результат с моими.

04 Июнь 2014 в 13:29
Если кому-то интересно, то вот вам использованный в исследовании тестовый проект для обсчёта. Можете сравнить свой результат с моими.

04 Июнь 2014 в 16:14
Упорно не хочет выкладывать файл :(((

19 Июнь 2014 в 23:41
Изучаю и тестирую DIALux 4.12.0.1, прошу не путать с DIALux EVO. Чем они отличаются в дизайнерском плане, понятия не имею, но с точки зрения использования вычислительных мощностей компьютера, DIALux (без EVO) застрял где-то в начале славной эпохи WinXP. Но обо всём по порядку.

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

Файловая система.
Информации на винчестер при запуске и расчётах почти не записано, по крайней мере из 9 мб файлов как минимум 5 мб можно честно списать на деятельность виндовс и сторонних программ. В мусорной папке TEMP активность конечно наблюдается, но исчисляется она десятками килобайт. Деятельность винчестера почти незаметна, лишь лёгкие хаотичные подмигивания лампочки и практически нулевая активность на графике интенсивности использования. При закрытии программы мусор из временной папки самоуничтожается. Очень скромные показатели, я бы даже сказал подозрительно скромные. Похоже, что основная работа проделывается в оперативной памяти практически без участия винчестера, что благоприятствует использованию твердотельного диска, если на то возникнет желание. Хотя, явной необходимости в SSD я по-прежнему не вижу, т.к. время обсчёта не меняется, независимо от нахождения папки программы на разных носителях информации, разве что запуск программы с открытием проекта заметно ускоряется. Варианты различных скоростных файловых носителей, а также способы повышения отзывчивости винчестера описаны выше.

Оперативная память.
Проект весом 2,2 мб скушал при запуске около 200 мб оперативки и ещё столько же при расчётах, что можно считать весьма неплохим результатом, по сравнению с прожорливостью DIALux EVO. Однако, пусть лучше бы нещадно жрал оперативку, но при этом работал многопоточно и шустро. Мечты, мечты…

Видеокарта
По сравнению с предыдущей тестируемой версией, произвольные, интенсивные движения проекта с готовым освещением не вызывает ни каких затруднений, даже на встроенной в процессор видеокарте. Всё поворачивается и перемещается в пространстве относительно плавно, почти без рывков. Если верить утилитке nvidiaInspector, то дискретная видеокарта не слишком напрягается, показывая в пике нагрузку графического чипа около 50%. Тут ставлю авторам программы явный плюс, хорошо отшлифовали этот момент. Вопрос, нужна ли диалюксу производительная видеокарта с большим объёмом памяти оставляю открытым, по причине относительной убогости моего проекта. Макет освещения мегаполиса, с кучей объектов и текстур, наверняка будет запинаться на хиленькой встроенной видюхе, но применимо к вопросу ускорения расчётов, от крутости видеокарты толку нет. Добавлю, что рывки всё же наблюдал, но только в случаях, когда частота процессора была ниже отметки 2,0 ГГц, значит всё снова упирается в процессор.

Программные хитрости.
Клонирование программы не катит. Множим виртуальные компьютеры при помощи VirtualBox или подобных ему программ, тем более что требования к ресурсам системы у DIALux`а весьма демократичны. Подробности можно посмотреть в предыдущих обзорах.

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

Процессор.
Примерно 99% расчётов выполняется файлом DLXRadical.exe.
1 ядро 1 поток ГТ выкл. 05:29
2 ядра 2 потока ГТ выкл. 04:57
3 ядра 3 потока ГТ выкл. 05:01
4 ядра 4 потока ГТ выкл. 05:07
1 ядро 2 потока ГТ вкл. 05:09
2 ядра 4 потока ГТ вкл. 04:56
3 ядра 6 потоков ГТ вкл. 05:01
4 ядра 8 потоков ГТ вкл. 05:06
Да, да, всё снова очень грустно и скучно ползёт в один поток. По причине конкуренции системы и приложений за единственное вычислительное ядро, одного потока процессора для однопоточной задачи слегка недостаточно. Гипертрейдинг работает, пример с одним двухпоточным ядром тому доказательство, а в других случаях он хотя бы не мешает. В принципе и так всё понятно, так что можно было ограничиться тестами в 2 потока, но факт, что в два потока задача обсчитывается немного быстрее, чем при полноценном восьмипоточном процессоре, заставил провести весь диапазон тестов. Наблюдается закономерность лёгкого удлинения времени вычисления при явном избытке свободных потоков. Чем это объяснить я не знаю, практической пользы для ускорения наверное тоже ни какой, но ежели закономерность верна, то вполне возможно мы увидим заметное увеличение длительности расчётов при использовании каких-нибудь серверных очень многопоточных процессоров.
Тесты с различными частотами на стареньким двухядерном Intel Core 2 Duo.
Частота процессора - общее время
1.6 - 21:00 (1260сек)
2.0 - 16:40 (1000сек)
2.4 - 14:25 (865сек)
3.2 - 10:28 (628сек)
На низких частотах расчёт нестабилен, велик разброс результатов, посему указано среднее время нескольких замеров. Чем это вызвано, не знаю, то ли в расчётах присутствует элемент случайности, то ли системные процессы вносят погрешность. В любом случае, если попытаться построить график, то он почти повторяет контуры графика производительности в DIALux EVO. Если время выполнения задачи уменьшается кратно увеличению частоты процессора, то для уменьшения времени расчёта часовой задачи, хотя бы до 30 минут, процессор частотой 3,5 ГГц требуется разогнать до недостижимых на воздухе 7 ГГц(60:30х3,5). Соответственно, для сокращения однопоточных расчётов до 5 минут нужен процессор работающий на частоте аж 42 ГГц(60:5х3,5), что сейчас звучит как фантастика. Надеюсь, я не ошибся в расчётах, заранее извиняюсь, если это так.
Ранее упомянутый комп на 64х битной 7ке с установленным двухядерником АМД(A6-6400K), тоже смог поучаствовать в исследовании и выдал вот такой результат - 09:35. Отставание в скорости расчётов от нового процессора Intel хоть и не такое явное, как в DIALux EVO, но всё равно бросается в глаза. Есть малая доля вероятности, что красные процессоры в расчётах не на много хуже голубых, но доступа к флагманским многоядерным моделям AMD для проверки у меня нет. Касаемо самой 64х битной системы Win7, то на неё похоже установилась 32х(86х) битная версия DIALux, которая вроде как вполне неплохо там себя чувствует и работает без нареканий.

Выводы по DIALux 4.12.0.1 (возможно применимы к последующим версиям DIALux 4.12.X.Y).
Есть много лишних денег - можете брать SSD, вот только скорости расчётов это не прибавит. Покупка дополнительных планок памяти и топовой видеокарты в море погоды тоже не сделает. Лучше прикупите несколько мониторов и осваивайте работу с виртуальными компьютерами, т.к. ждать обсчёта единственного проекта в один поток на одном компьютере придётся ооочень долго, а так вы хотя бы задействуете лишнюю память и бесполезные дополнительные ядра на другие проекты. Ну, а если вы ни куда не торопитесь или ваш бюджет ограничен, то двухядерный процессор Intel с частотой более 3,0 ГГц со встроенной видеокартой, вполне комфортно выполнит ту же самую работу, что и более навороченный собрат, затратив на расчёты немного больше времени.
Для ускорения вычислений используйте компьютеры на платформе Intel, немного разгоните процессор, отключите ненужные приложения и перестаньте пить много кофе :))).

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

Если кому-то интересно, то выкладываю использованные в исследовании тестовые проекты для обсчёта. Можете попробовать сделать замер времени выполнения расчётов на своём компьютере и сравнить с представленными результатами. Наверное, даже будет весьма полезно, если вы здесь же опубликуете свои результаты, с указанием версии программы DIALux или DIALux EVO, не забыв написать модель процессора и рабочую частоту. По желанию можно ещё указать используемую версию Windows, размер и частоту оперативной памяти, видеокарту, но главное не забыть про время расчёта, версию программы, модель процессора и частоту, особенно если он разогнан.

Например:
DIALux 4.12.0.1, Время 10:09, Intel Core 2 Quad Q9500 2.83 GHz.
Или
Программа DIALux EVO 3.0, время 05:06, процессор Intel Core i7-3770 3.4GHz(до 3.9 ГГц в режиме Turbo Boost), Win7(x32), память 3Гб(1600MHz), видеокарта GTX 750Ti 2Gb, системный диск SSD Plextor PX-256M5S.
Или
DIALux 4.12.0.1, время 10:28, Intel Core Duo E6750 2.66 (разогнан до 3.2 ГГц), память 3Гб (800МГц)

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

https://yadi.sk/d/Sssz_TgFUKTTu

Версия 5.3.3.18310
evo3.3 - F59B8D4
OpenGL / 64 бита / Расчетное ядро: 64 бита standalone
Support ID: cd50eccd74b4634ce3283608f1f4f62a

Что касаемо компьютера:
CPU: i7 2600 3.4GHz до 3.7 ГГц в режиме Turbo Boost
RAM: 16Gb
HDD: 2x500Gb в Raid0
GPU: GTS 450 4Gb
Операционная система: Windows 7 x64

Скачал тест и провел его в evo3.3 - F59B8D4 с момента запуска расчета до его окончания прошло: 3 мин. 5 сек.

DIALux 4.12.0.1, Расчет проводился повышенной точности, Время 05:41

Компьютер, ноут HP ProoBook 4540s:
CPU: Intel Core i5-2450M CPU @ 2.50GHz Sandy Bridge Socket 988B rPGA (0x4)
Video: Intel HD Graphics 3000 memory 1.797Gb
Memory Size: 4 GBytes
Channels: Single
Memory Frequency: 798.1 MHz (1:6)
HDD: Seagate Spinpoint M8 ST750LM022 (HN-M750MBB) 750 Гб
Операционная система: Windows 8.1 x64

Скачал тест и провел его DIALux 4.12.0.1, Расчет стандарт, Время 03:51