Common Lisp - 100% загрузка процессора навсегда после завершения многопоточных вычислений? - PullRequest
Новая
       82

Common Lisp - 100% загрузка процессора навсегда после завершения многопоточных вычислений?

0 голосов
/ 10 апреля 2020

ОБНОВЛЕНИЕ

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

Вопрос в следующем: Предполагается ли, что SBCL загружает 100% ЦП после запуска программы, независимо от того, что вы сделали хорошо или плохо? И , это вы, ребята, видели раньше? - Т.е. известная ошибка?

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

Извините за с первого раза не ясно:)

-----

Ошибка?

У меня иногда возникают проблемы с использованием Lisp при длительной работе 100% CPU времени после запуска программ.

Обновление: сейчас оно использовало 100% ЦП в течение 40 минут после завершения программы.

Среда: SBCL, rowwell, emacs + SLIME

У меня вопрос, если это известная ошибка в Common Lisp, о которой я не знаю и может быть связана с G C?

Context

Это не первый раз что это происходит "случайно", но случается так, что более вычислительные программы, которые занимают много памяти, в конечном итоге используют 100% в течение длительного времени (в данном случае 40 минут) после завершения программы.

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

Я не думаю, что для SBCL нормально тратить 40 минут после запуска программы с использованием 100% ЦП. Боюсь, это может быть связано с какой-то ошибкой в ​​G C?

Затем я профилировал программу в SLIME:

enter image description here

, и программа была очень медленной (выполнение ~ 20 минут) и много сделала распределений, затем изменил одну строку, и теперь требуется 2 секунды для запуска, просто потому, что я всегда форматировал строку отладки в пустой поток (таким образом генерируя новые строковые представления списка с 100k целыми числами при каждом вызове):

enter image description here

(https://github.com/AlbertoEAF/advent_of_code_2019/commit/b37797df772c12c2d409b1c3356cf5b690c8f928)

Это не моя точка зрения, хотя. Несмотря на то, что этот случай крайне некорректен, задача, которую я выполняю, очень проста, и поэтому используемая программа не имеет значения, проблема заключается в нестабильности платформы в сценарии ios, где используется устойчивая тяжелые вычисления и распределение. Есть ли сообщения о таких проблемах с SLIME / SBCL или о каких-то других вещах, о которых я не знаю?

Спасибо!

1 Ответ

2 голосов
/ 14 апреля 2020

Причина, по которой ваше изменение повышает производительность, заключается в том, что debug-stream равно NIL.

В старом коде вы оцениваете: 

(format nil ...)

Когда вы задаете nil в качестве потока для форматирования он печатает в строку, поэтому вы выполняете работу по форматированию и выделяете большую строку, которую выбрасываете.

В новом коде вы делаете: 

(when nil ...)

Что стоит примерно 0 .

Обратите внимание, что nil не означает ничего не делать, когда вы передаете его format. В общем, если вы хотите ничего не делать, вы должны ничего не делать вместо вызова функций, которые что-то делают.

...