Добрый день!
Python не поддерживает мультиядерные процессоры?

Кратко:
Программа-органайзер вики WikidPad 2.1 тормозит: ввод текста с задержками.
Найденное решение: Если в BIOS отключить Hyper threading и все ядра, кроме одного, ввод текста без тормозов.


Программа WikidPad написана на Python.
http://wikidpad.sourceforge.net/ - здесь бинарникик и исходные тексты.
Формат файлов - plain text.
Кодировка UTF-8 без BOM.
Тормоза при вводе текста проявляются на больших текстах со множеством заголовков, например 17000 строк.

Ставил WikidPad 2.1 отсюда:
http://www.getdeb.net/updates/Ubuntu/12.10/?q=wikidpad
Везде Ubuntu 14.04 64-хразрядная.
Везде python 2.7.6, python3 3.4 (но он не используется WikidPad 2.1, насколько понял).

Пробовал также запуск из исходников python wikidpad.

Три компьютера.
2 с SSD, один из них с процессором Intel Core i3, второй с AMD-450.
Ноутбук с процессором Intel Core i3, HDD.
Ноутбук Dell 500 с процессором Intel Celeron 550.

Вот на этом ноутбуке ввод текста в записи WikidPad идет без задержек,
а на компьютерах с более мощными процессорами, но с тем же ПО,
после ввода 2-3 слова заметное торможение.
То же с обработкой текста - выделением, копированием и т.п.

В top процесс python на ноутбуке Dell 500 % CPU не поднимается выше 88%,
на других, помощнее машинах в процессе ввода в top ~110-112%.
Это в строчке процесса python.

Что это может быть?
И как победить?


(“Гуглил” python slowly, писал в группу WikidPad - не помогло).



Из переписки в группе поддержки:

——– Перенаправленное сообщение ——–
Тема: Re: WikidPad works slowly in Ubuntu 14.04
Дата: Fri, 12 Sep 2014 08:47:27 +1200
От: ‘Graham Harris’ graham@harris.net.nz <wikidPad@yahoogroups.com>
Отвечать: wikidPad@yahoogroups.com
Кому: wikidPad@yahoogroups.com



I have begun to think that WikidPad is being slowed down by running on a
multi-CPU machine.

Python has poor multi-cpu support and some sources suggest that it can
even be slowed down in some cases. I suspect WikidPad is one of those
cases.

I could test the theory by running WikidPad in a virtual machine that can
see only 1 CPU, and comparing performance with the same WikidPad running
outside the VM, where it has 4 CPUs. I haven't got round to doing that
yet.

Graham

On Thu, September 11, 2014 23:58, RB wrote:
> Ross,
>
>
> I tried to run a version of 2.3.beta12 - the same problem.
> Slows down as you type.
> Tried to rebuild the database.
> In redesigning often happens at the end of an error "NOT NULL constraint
> failed:
> wikiwordmatchterms.matchtermnormcase . Instead of trying to use GadFly
> SQL.
> It did not help.
> So this problem and for version WikidPad 2.3.
> Once managed to rebuild the database, which was faster than typing, but
> then again entering slowed. It is strange that the old Dell laptop 500 no
> such problem. Maybe it has something to do with the processors?
>
>
> Who that will advise?
>
>

multithreading - Python threading unexpectedly slower - Stack Overflow
http://stackoverflow.com/questions/3121109/python-threading-unexpectedly-slower
Python has the GIL. Python bytecode will only be executed by a single processor at a time. Only certain C modules (which don't manage Python state) will be able to run concurrently.
The Python GIL has a huge overhead in locking the state between threads. There are fixes for this in newer versions or in development branches - which at the very least should make multi-threaded CPU bound code as fast as single threaded code.

python - Running simulation with hyperthreading doubles runtime - Stack Overflow
http://stackoverflow.com/questions/8416370/running-simulation-with-hyperthreading-doubles-runtime
I use a simulation written in python/numpy/cython. Since i need to average over many simulation runs i use the multiprocessing module to run all the individual simulation runs in batches.

At the office i have an i7-920 workstation with HT. At home i have an i5-560 without. I thought i could run twice as many instances of the simulation in each batch in the office and cut my running time in half. Surprisingly, the run time of each individual instance was doubled compared to the time it take on my home workstation. That it, running 3 simulation instances in parallel at home would take, say 8 minutes, while running 6 instances at the office take about 15 minutes. Using ‘cat /proc/cpuinfo’ i verified ‘siblings’ = 8 and ‘cpu cores’ = 4, so HT is enabled.

I am not aware of any “conservation of total runtime” law (though from s scientific point of view it could quite interesting ), and hopping someone here might shed some light on this conundrum.

———————————————————————————————————————


Что-нибудь посоветуете?
Как “ускорить” WikidPad на многоядерном процессоре?

Python-Python
почитайте что такое GIL, модули threads, multiprocessing. В инете КУЧА информации потому что пережевывается, наверное, с первых серьезных лет жизни Питона.

JOHN_16
почитайте

JOHN_16, спасибо за “тыканье носом”, но реальной помощи я не дождался.
Почему таки сработала команда:
И WikidPad перестала тормозить?

Что-нибудь можно поменять в коде, чтобы каждый раз после запуска не смотреть pid и не запускать taskset?
В чем причина торможения?

(По совету:



——– Перенаправленное сообщение ——–
Тема: Re: WikidPad works slowly in Ubuntu 14.04
Дата: Fri, 12 Sep 2014 22:58:12 +0200
От: Michael Butscher mbutscher@gmx.de <wikidPad@yahoogroups.com>
Отвечать: wikidPad@yahoogroups.com
Кому: wikidPad@yahoogroups.com



On 12.09.2014 10:55, RB radiobox@mtu-net.ru wrote:
> Graham,
>
> I disable the BIOS all the processor cores Intel Core i3 except one and Hyper-threading.
> WikidPad stopped braking.
> But at the same time slightly reduced speed of your computer.

I'm not a Linux expert but running WikidPad using the “taskset” command should
help:

http://manpages.ubuntu.com/manpages/trusty/man1/taskset.1.html

With taskset you can assign a process to one (or more) particular CPU core(s).

Michael
)

сделать кастомный скрипт для запуска?
taskset -c 0 mycommand
?

alrusdi,
спасибо!
Да, можно записать в ~ алиас для команды wikidpad

Я пока запускаю так из истории sh:

Формат
Удобнее и нагляднее, спасибо за совет!

Работает ощутимо быстрее, небо и земля, улитка и кенгуру.
И не надо отключать ядра и HT, искусственно обрезать производительность компьютера.

Интересно еще поискать способ изменить строку запуска по клику на значок в Unity.
Но это уже оффтопик, относящийся к Linux/Ubuntu.

Вот что действительно интересно, почему это несложную (проблема в ее функции редактора - ввод текста) программу на Python клинит на современных процессорах?
Два ядра - и тормоза.
Можно ли как-нибудь поправить текст, может, в инициализации?

Вот сообщение по этой проблеме из wikidPad@yahoogroups.com:

——– Перенаправленное сообщение ——–
Тема: Re: WikidPad works slowly in Ubuntu 14.04
Дата: Mon, 15 Sep 2014 18:21:33 +0100
От: Ross xkjq@ymail.com <wikidPad@yahoogroups.com>
Отвечать: wikidPad@yahoogroups.com
Кому: wikidPad@yahoogroups.com



Glad to see this finally get solved.

Seems that it is a bit of a known problem on certain system/os
combinations (particularly with hyperthreading)

https://www.mirantis.com/blog/improve-performance-python-programs-restricting-single-cpu/
http://stackoverflow.com/questions/990102/python-global-interpreter-lock-gil-workaround-on-multi-core-systems-using-task
http://www.rfk.id.au/blog/entry/a-gil-adventure-threading2/

It would certainly be interesting to see if the same problem happens
with python3 (apparently the GIL has been somewhat improved) or if using
multiprocessing would be feasible - unfortunately, having started a new
job recently, I don't have much time to devote to WikidPad at the moment.

Ross

On 15/09/14 17:00, Michael Butscher mbutscher@gmx.de wrote:
> On 15.09.2014 11:05, Graham graham@harris.net.nz wrote:
>
>> kudos, Michael. For “I'm not a Linux expert but” you did good!
>
> I just knew the key term “CPU affinity” for that function which helped searching.
>
>
>
> Michael
>
>
> ————————————
> Posted by: Michael Butscher <mbutscher@gmx.de>
> ————————————
>
>
> ————————————
>
> Yahoo Groups Links
>
>
>

__._,_.___
——————————————————————————————–
Posted by: Ross <xkjq@ymail.com>
———————————

Причина в “клинче” процессов Python на нескольких процессорах.

Кто-нибудь прокомментирует?
Возможны ли какие изменения в коде или так и запускать командой taskset?