PyPy 1.7

С, С++ и Java тоже?)

для этого llvm есть

Еще как используется, вакансий довольно. Сходи например на http://python.org/community/jobs/ и http://python.org/about/success/

там есть 2 модуля - multiprocessing и threading. Нить является классом, там как бы нет явно вызовов pthread

Да я и не скрываю что не работал с питоном. Хочу еще раз посмотреть, что изменилось за последние 7 лет. Ява не универсальный язык, например, с графикой там все очень плохо.

Да мне это уже объяснили, я подозреваю, что если вместо одного 2 ядерного проца, я поставлю 2 четырехядерных, то на скорости программы на питоне это не повлияет, если писать ее в классическом стиле, как с использованием phtreads.

Там есть 2 модуля. В комменте в хэлпе к threading на сайте есть нужная инфа.

PyPy быстрее CPython? Как такое возможно? Подозрение одно: неистовый выстрел себе в ногу.

Хочу разливного редактора с шоколадом и роскошью.

> PyPy быстрее CPython? Как такое возможно?

Нативный код быстрее интерпретации байт-кода? Как такое возможно?

> PyPy быстрее CPython? Как такое возможно? Подозрение одно: неистовый выстрел себе в ногу.

из json'а выбрасывается итератор, который позволяет передавать данные, как о массиве. В результате у нас нет необходимости выделять и перевыделять данные под строки, можно обходится малыми объемами памяти, которые будут выделены без обращения к malloc. Это наиболее вероятно.

> Получается, что питон не очень то и нужен, гораздо продуктивней потратить время на изучения с++11.

Вы не выучите с такими знаниями. А быдлокод на С++ не нужен.

> А питон где-то вообще используется? А то вакансий хрен найдешь.

Что-то питонщиков мы еле еле нашли

>Получается, что потоков в смысле «системных потоков», так и не сделали. Тогда пригодность питона для веб вызывает большой скепсис, ведь решение получается немасштабирумым по определению.

Ага. Вы это FriendFeed расскажите которые были вынуждены запускать 4 nginx фронтенда и один Tornado бэкэнд. Ибо бэкэнд в холостую работал

> А питон где-то вообще используется? А то вакансий хрен найдешь.

Не в твоей унылой провинции. А так вообще - есть вакансии.

В гугле и яндексе - точно используется, помню как они в своё время искали программистов.

> Да мне это уже объяснили, я подозреваю, что если вместо одного 2 ядерного проца, я поставлю 2 четырехядерных, то на скорости программы на питоне это не повлияет, если писать ее в классическом стиле, как с использованием phtreads.

Где-то в сети проскакивали бенчмарки масштабируемости в случае с использованием pthreads и нескольких простых изолированных процессов в качестве альтернативы. Задача, как я помню, была не на загрузку CPU, а как в веб-сервере, т.е. огромное количество одновременно открытых но малоактивных соединений, постоянный вал вновь открываемых соединений с пиковой активностью.

Вот как-то так получалось, что если процессы форкнуть заранее, то решение и проще в отладке и проектировании и быстрее в работе получается.

А потоки - это для тех, кто ниасилил, как распределить нагрузку своими руками и надеется, что это сделает за него операционная система.

С какими такими знаниями? В С++ поддерка потоков включена в стандарт, это значит она будет на любой современной платформе, и стоит ли тогда тратить время на изучение недоделанных решений в питоне?

Получается, что потоков в смысле «системных потоков», так и не сделали. Тогда пригодность питона для веб вызывает большой скепсис, ведь решение получается немасштабирумым по определению.

Прафисианалы веба в треде, PHP надо срочно забиться под машину!

Мама, я хочу PyPy.... =) Что-то во все эти приросты туго вериться :/

>В С++ поддерка потоков включена в стандарт, это значит она будет на любой современной платформе

И давно в Линуксе появилась поддержка потоков на уровне ядра?

В С++ поддерка потоков включена в стандарт

Гм, и как давно? И сколько компиляторов об этом знает?

Мама, я хочу PyPy

Судя по аватарке, всё-таки KaKa. И даже наружу немножко вырвалось.

> С какими такими знаниями? В С++ поддерка потоков включена в стандарт

В интелекте, деточка, дело. В интеллекте. Если ты не можешь осилить питон и понять некоторые его «технологии» - то чего тебе делать в программировании.

> Что-то во все эти приросты туго вериться :/

Как раз в случае питон верю

> может компилировать сам себя
Где здесь была новость по JVM, написанную на JavaScript?

И давно в Линуксе появилась поддержка потоков на уровне ядра?

nptl-то? Сто лет как.

> И давно в Линуксе появилась поддержка потоков на уровне ядра?

Ой, я еще вроде тогда в школе учился

А кто тебе мешает создать пул спящих потоков и пробуждать их по мере поступления запросов?

что если вместо одного 2 ядерного проца, я поставлю 2 четырехядерных, то на скорости программы на питоне это не повлияет

если руки кривые то хоть на сях, хоть на яве пиши, не повлияет. А у меня несколько воркеров работает для утилизации всех процов в системе.

А кто тебе мешает создать пул спящих потоков и пробуждать их по мере поступления запросов?

Это решение для бедных, если пямяти мало. Всё-таки GIL не святым духом питается.

А ещё, вы либо используете multithreading, либо unittesting.

АТСЮДО выводы.

вы либо используете multithreading, либо unittesting.

Намекаешь на какие-то проблемы?

Я могу ошибаться, но по моим представлением складывается такая ситуация, если в каждый момент времени интерпретатор питона работает в одном и только одном потоке, то остальные должны быть остановлены. А теперь представь, что интерпретатор начал исполнение долгоиграющего запроса к базе, все остальные 1000 потоков тупо заблокированы, возникает вопрос о какой маштабируемости тут может идти речь?

В среднем на тестовом пакете, прирост производительности PyPy 1,7 составляет около 30%, по сравнению с PyPy 1,6

Если склероз не врёт, то с каждым релизом PyPy он всё быстрее и быстрее своих предыдущих версий на 30-50%% и каждый раз обгоняет CPython. Скоро вообще ракета будет. Про обгон своих же расширений на Си можно сказать только что-то странное с писателями или с интерфейсом этих самых расширений.

worker - это отдельный процесс в смысле процесса ОС?

> А теперь представь, что интерпретатор начал исполнение долгоиграющего запроса к базе, все остальные 1000 потоков тупо заблокированы

twisted + defer, гринлеты и тд

обгон может быть получен за счет другого принципа реализации

А как в современном питоне дела с мультипоточными приложениями?

В CPython - так себе, несколько кор не загрузить. В PyPy - так же, как в CPython, хотя Риго пилит реализацию с STM.

Не разбираетесь, не пишите. Есть с версии 2.6 и 3.0 модуль multiprocessing, позволяющий параллелить код с помощью процессов. Там есть очень удобные вещи типа Pool с автоматическим управлением распределением потоков.

>>> А как в современном питоне дела с мультипоточными приложениями?

В CPython - так себе, несколько кор не загрузить. В PyPy - так же, как в CPython, хотя Риго пилит реализацию с STM.

Не разбираетесь, не пишите. Есть с версии 2.6 и 3.0 модуль multiprocessing

Не умеешь читать - не пиши ответов. Речь шла о многопоточности. Multiprocessing - это не многопоточность.

если в каждый момент времени интерпретатор питона работает в одном и только одном потоке

Yeah.

А теперь представь, что интерпретатор начал исполнение долгоиграющего запроса к базе, все остальные 1000 потоков тупо заблокированы

Nope. man select.

Multiprocessing - это не многопоточность.

Объясните мне, чем вам не угодил multiprocessing? Почему это не многопоточность. Вот я пишу вычислялки на Питоне и numpy, они у меня легко кушают все 8 ядер на узле кластера и получают соответствующий прирост производительности ~6 раз. А вы мне глаза открыли, что, оказывается, это не многопоточность.

У меня ощущение, что эти гринлеты - это какие-то костыли. Задам очень простой вопрос сколько гринлетов можно исполнять параллельно на потоках ОС?

Задам очень простой вопрос сколько гринлетов можно исполнять параллельно на потоках ОС?

Этот вопрос от незнания матчасти. И вызывает лишь улыбку.

> Объясните мне, чем вам не угодил multiprocessing?

Да с чего ты взял, что он мне не угодил? Меня спросили о многопоточности, я ответил о многопоточности.

А вы мне глаза открыли, что, оказывается, это не многопоточность.

Вот честно - мне безразличны твои заблуждения. Ты обвинил меня в некомпетентности и зачем-то приплел multiprocessing к разговору о многопоточности. Я указал, что multiprocessing к многопоточности отношения не имеет. Знал ты это или нет - меня не интересует.

ехал Python через Python
...

> Объясните мне, чем вам не угодил multiprocessing?

Лишняя память, это раз. Невозможность разделять адрессное пространство - это два.

Вот мы пишем сервер, который грузит в память около 3 Гб данных. Так на все 24 ядра на машиен сколько надо памяти?

> У меня ощущение, что эти гринлеты - это какие-то костыли.

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

Истинная параллельность - это сложная реализация и подводные камни. Хотя ее не хватает. Все эти технологии важны к месту.

Процесс с 1 потоком выполняется на 1 ядре. Несколько потоков могут выполняться одновременно на нескольких ядрах. Хрен ли тут разводить бодягу? Планировщик ядра работает именно с потоками. Проблема питона в том, что в каждый момент времени исполняется только один поток операционной системы, на котором работает интерпретатор.

Я указал, что multiprocessing к многопоточности отношения не имеет.

Это есть неверное суждение, либо вы используете специфичную терминологию. Multiprocessing повторяет функциональность threading почти полностью, использую процессы вместо потоков. Разницы, собственно, 2: необщая память и накладные расходы на создание процесса несколько выше. Но функционально это практически то же, поскольку механизмы обмена данными, запуска, завершения, управления те же с точки зрения программиста на Питоне. Более того, можно даже получить общий доступ к переменным, для это есть специальные конструкции, кроме того, создание потока можно сделать внутри класса, тогда доступ к его полям и методам будет общий (только нельзя использовать Pool).

Поэтому я считаю, что вы совершенно напрасно вводите людей в заблуждение, утверждая, что одновременной многопоточности в Питоне нет.

Проблема питона в том, что в каждый момент времени исполняется только один поток операционной системы, на котором работает интерпретатор.

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

Хватит тупить, причем так жестко.

А ты не улыбайся, а просто цифру назови. Я думаю что сделано по мотивам т.н. green threads, что по сути является эмуляцией, где планировщик исполняется в том же потоке.