https://mobile.opennet.me/openforum/vsluhforumID3/96741.html После трёх лет разработки представлен (http://morepypy.blogspot.ru/2014/07/pypy-stm-first-interesting-release.html) первый официальный выпуск проекта PyPy-STM (http://pypy.readthedocs.org/en/latest/stm.html) (PyPy Software Transactional Memory), в рамках которого развивается реализация языка Python, способная распараллеливать выполнение разных потоков одного многопоточного приложения на нескольких ядрах CPU. Разработка PyPy-STM направлена на устранение одной из основных проблем СPython - наличие глобальной блокировки интерпретатора (GIL, global interpreter lock), не позволяющей обеспечить параллельное выполнение нескольких нитей кода на языке Python.<br><br><br>PyPy-STM основывается на кодовой базе PyPy, высокопроизводительной реализации языка Python, написанной на языке Python (используется статически типизированное подмножество RPython (http://doc.pypy.org/en/latest/coding-guide.html#id1), Restricted Python). Высокий уровень производительности достигается благодаря задействованию JIT-компилятора, на лету транслиру https://mobile.opennet.me/openforum/vsluhforumID3/96741.html#56 Mon, 27 Oct 2014 17:02:03 GMT А различие -- да, именно в неэффективной и устаревшей на сегодня ВМ и устаревшем же байт-коде. То есть именно об этом я и говорил.<br><br>&gt; А еще в <br>&gt; отличие от Java и С# python обладает динамической типизацией, и вы <br>&gt; не сможете определить размер памяти необходимый для работы потока, потому что <br>&gt; заранее вы не знаете тип данных.<br><br>Оппаньки. Такое даже комментировать сложно. То есть в Java так-таки всё известно? :-) Открою секрет: на момент создания объекта -- известно. Когда вы работаете с объектом через любой его интерфейс, точно так же ничего не известно. Да, это не настолько полная неизвестность, как в случае Python, но к выделению памяти проблема не имеет вообще никакого отношения.<br><br> https://mobile.opennet.me/openforum/vsluhforumID3/96741.html#55 Sun, 13 Jul 2014 16:06:25 GMT &gt;Имеется в виду распределение асинхронных обработчиков не на 1 реактор, а сразу на несколько. Это просто следующий логичный шаг повышения производительности в рамках одного процесса.<br><br>Gevent так и работает (from gevent.pool import Pool), в чём проблема с потоками? Тема так и не раскрыта. <br><br>https://sdiehl.github.io/gevent-tutorial/<br> https://mobile.opennet.me/openforum/vsluhforumID3/96741.html#54 Wed, 09 Jul 2014 07:34:24 GMT Есть данные по сравнению потребления оперативной памяти PyPy-STM и PyPy?<br> https://mobile.opennet.me/openforum/vsluhforumID3/96741.html#53 Wed, 09 Jul 2014 07:18:46 GMT Это может быть только ваши потребности такие, и ваши цифры, для других они другие.<br> https://mobile.opennet.me/openforum/vsluhforumID3/96741.html#52 Tue, 08 Jul 2014 18:58:57 GMT &gt; То есть второй проц добавляет 90% производительности, а четвёртый всего-лишь 18. Апроксимируя <br>&gt; получим 10% прирост на энный процессор. Вопрос: а накуя такое чудо? <br><br>А закон Амдала никуда не делся. Он, сцуко, вишь ты, фундаментальный. Оверхед в реальном мире на согласование работы камней был, есть и будет. А сферические кони только в вакууме живут.<br><br><br> https://mobile.opennet.me/openforum/vsluhforumID3/96741.html#50 Tue, 08 Jul 2014 17:08:31 GMT В нормальных операционных системах время создания процесса такое же как и потока.<br> https://mobile.opennet.me/openforum/vsluhforumID3/96741.html#49 Tue, 08 Jul 2014 15:48:55 GMT Имеется в виду распределение асинхронных обработчиков не на 1 реактор, а сразу на несколько. Это просто следующий логичный шаг повышения производительности в рамках одного процесса.<br><br>http://www.boost.org/doc/libs/1_54_0/doc/html/boost_asio/overview/core/threads.html<br> https://mobile.opennet.me/openforum/vsluhforumID3/96741.html#48 Tue, 08 Jul 2014 14:37:14 GMT &gt; И чем, скажите на милость, Python с трансляцией в байт-код и выполнением <br>&gt; виртуальной машиной отличается от Java или C# с трансляцией в байт-код <br>&gt; и выполнением виртуальной машиной же? Где принципиальная разница? <br><br>Отличие в байт-коде, и методах его трансляции. Они совсем разные. Байт-код питона всего лишь незначительно ускоряет загрузку программы в память и больше ничего. А еще "внезапно" большое количество модулей python написано на Си С++ Fortran и бог еще знает на чём python в этом смысле всеядный, и эти модули выполняются без всякой трансляции в байт-код, и да у них(бинарных модулей) есть механизм отключения GIL. А еще в отличие от Java и С# python обладает динамической типизацией, и вы не сможете определить размер памяти необходимый для работы потока, потому что заранее вы не знаете тип данных. <br><br> https://mobile.opennet.me/openforum/vsluhforumID3/96741.html#47 Tue, 08 Jul 2014 14:25:21 GMT &gt;&gt; Асинхронность вовсе не должна быть связана с однопоточным реактором, а если вы полагаете, что должна, то вы слишком много программировали на Win32 <br>&gt; Это что вы вот сейчас имели в виду?<br>&gt; Какие-то конкретные общеизвестные проблемы в overlapped IO или IOCP?<br><br>Он просто бредит.<br>