The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Представлен pypy-stm, интерпретатор Python с поддержкой расп..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Представлен pypy-stm, интерпретатор Python с поддержкой расп..."  +/
Сообщение от opennews (??) on 11-Май-12, 12:17 
Разработчики проекта PyPy представили (http://permalink.gmane.org/gmane.comp.python.pypy/10069) проект pypy-stm (PyPy Software Transactional Memory), в рамках которого проведена работа по избавлению от глобальной блокировки интерпретатора, мешающей обеспечению параллельного выполнения нескольких нитей кода на языке Python. В настоящее время представлена надстройка над PyPy c рабочей реализацией интерпретатора Python 2.7, поддерживающая одновременное исполнение нитей существующих многопоточных приложений на разных ядрах CPU. Кроме STM-надстройки над PyPy дополнительно ведётся работа (https://bitbucket.org/arigo/cpython-withatomic) по реализации поддержки STM для экспериментальной ветки СPython 3.3.

От проблем с глобальной блокировкой до настоящего времени был избавлен только проект Jython, который использовал для обеспечения параллельного выполнения особенности виртуальной машины JVM вкупе с привязкой локов к изменяемым встроенным типам. В PyPy, CPython и IronPython, глобальная блокировка присутствует (http://morepypy.blogspot.com/2011/06/global-interpreter-lock...), что существенно ограничивает производительность данных реализаций языка Python. Для решения указанной проблемы участники проекта PyPy решили перейти от традиционных блокировок к программной транзакционной памяти (http://ru.wikipedia.org/wiki/%D0%9F%D1%8...), в качестве механизма для обеспечения параллелизма. Данный механизм по своей сути напоминает методы изоляции изменений, используемые в СУБД для обеспечения целостности транзакций. Для желающих принять участие в тестировании проекта подготовлено подробное описание (https://bitbucket.org/pypy/pypy/raw/stm-thread/pypy/doc/stm.rst) используемых в pypy-stm методов управления параллелизмом.

В настоящее время подготовлена сборка для 32-разрядных Linux-систем (можно собрать (http://morepypy.blogspot.com/2012/04/stm-update-and-thanks-e...) и для x86-64). Отмечается, что разработка пока представляет собой демонстрационный прототип, который ещё не подвергался оптимизации и поэтому работает очень медленно. Pypy-stm отстаёт по производительности от PyPy в 2-5 раз, так как PyPy в режиме STM пока не совместим с реализацией JIT-компилятора и не поддерживает многие оптимизации. В настоящее время pypy-stm полностью совместим с содержащей глобальную блокировку версией PyPy, т.е. может быть использован для выполнения многопоточных приложений в качестве прозрачной замены PyPy. Дополнительно, в стандартный модуль thread добавлен низкоуровневый API "thread.atomic", позволяющий более тонко управлять выполнением многопоточных приложений на разных ядрах CPU. Со временем на базе данного низкоуровневого API планируется разработать высокоуровневый программный интерфейс, который можно будет использовать для распараллеливания изначально не многопоточных программ.

URL: http://morepypy.blogspot.com/2012/05/stm-update-back-to-thre...
Новость: http://www.opennet.dev/opennews/art.shtml?num=33817

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


5. "Представлен pypy-stm, интерпретатор Python с поддержкой расп..."  +/
Сообщение от ZeroOne (ok) on 11-Май-12, 12:48 
Интересная идея. Что ж, удачи им.
А реализацию многопоточности через С/С++ расширения либо через грядущую версию С с поддержкой этой самой многопоточности ещё не пробовали делать или же что-то пробовали, да получилось не очень? Кто-то знает? Если есть ссылки, буду рад.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

10. "Представлен pypy-stm, интерпретатор Python с поддержкой расп..."  +2 +/
Сообщение от жопка3 on 11-Май-12, 13:06 
А расскажите, пожалуйста, подробней про грядущую версию С с поддержкой многопоточности?
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

15. "Представлен pypy-stm, интерпретатор Python с поддержкой расп..."  –8 +/
Сообщение от Аноним (??) on 11-Май-12, 13:48 
Внезапно, многопоточность в Си поддерживается уже как минимум с 1995 года, если не раньше. Два слова: POSIX threads. Подробней: cc -lpthread my_multithreaded_program.c -o my_multithreaded_program
Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

16. "Представлен pypy-stm, интерпретатор Python с поддержкой расп..."  +/
Сообщение от Аноним (??) on 11-Май-12, 14:23 
>Внезапно, многопоточность в Си поддерживается уже как минимум с 1995 года

Бывает что ирония и сарказм не улавливается, но не настолько.

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

20. "Представлен pypy-stm, интерпретатор Python с поддержкой расп..."  +1 +/
Сообщение от Аноним (??) on 11-Май-12, 15:07 
>POSIX threads
>многопоточность в Си

pthread не являются частью стандарта С.

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

25. "Представлен pypy-stm, интерпретатор Python с поддержкой расп..."  +/
Сообщение от Аноним (??) on 11-Май-12, 16:13 
> pthread не являются частью стандарта С.

Ага, и еще 100500 либ не являются. Это не мешает ими пользоваться.

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

36. "Представлен pypy-stm, интерпретатор Python с поддержкой расп..."  +/
Сообщение от Аноним239 on 11-Май-12, 22:32 
Еще как мешает.
Что делать на платформах под которые есть компилятор С но нет pthread?

Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

42. "Представлен pypy-stm, интерпретатор Python с поддержкой расп..."  –1 +/
Сообщение от Аноним (??) on 12-Май-12, 09:14 
> Что делать на платформах под которые есть компилятор С но нет pthread?

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

Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

49. "Представлен pypy-stm, интерпретатор Python с поддержкой расп..."  +/
Сообщение от Аноним (??) on 12-Май-12, 14:40 
И читать стоит то на что вы отвечаете.
Иначе так и будете попадать впросак.
Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

58. "Представлен pypy-stm, интерпретатор Python с поддержкой расп..."  +/
Сообщение от Vasily Pupkin on 13-Май-12, 09:40 
О как. А шо там как там с posix threads в MSVC собирать?
Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

21. "Представлен pypy-stm, интерпретатор Python с поддержкой расп..."  +/
Сообщение от Аноним (??) on 11-Май-12, 15:09 
> А расскажите, пожалуйста, подробней про грядущую версию С с поддержкой многопоточности?

google c11 threads.h

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

30. "Представлен pypy-stm, интерпретатор Python с поддержкой расп..."  +1 +/
Сообщение от ZeroOne (ok) on 11-Май-12, 17:05 
Сам ещё об этом ничего не знаю. Знаю, что с выходом C11 активировалось обсуждение развития и в стандарте С. Тогда я про грядущую многопоточность и узнал.
Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

6. "Представлен pypy-stm, интерпретатор Python с поддержкой расп..."  –1 +/
Сообщение от Нанобот on 11-Май-12, 12:48 
что, не хватает питону одного ядра процессора, да?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

8. "Представлен pypy-stm, интерпретатор Python с поддержкой расп..."  +/
Сообщение от Аноним (??) on 11-Май-12, 13:02 
Теперь будет тормозить на всех ядрах одновременно!
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

9. "Представлен pypy-stm, интерпретатор Python с поддержкой расп..."  +/
Сообщение от Аноним (??) on 11-Май-12, 13:04 
Питон не умеет (нативно/эффективно) использовать более чем одно ядро в рамках одного процесса из-за родового проклятия (GIL). Треды есть, но они не решают этой проблемы. PyPy не первый кто заявляет о решении проблемы GIL, но похоже наиболее перспективный.
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

17. "Представлен pypy-stm, интерпретатор Python с поддержкой расп..."  +/
Сообщение от Аноним (??) on 11-Май-12, 14:33 
> Питон не умеет (нативно/эффективно) использовать более чем одно ядро в рамках одного
> процесса из-за родового проклятия (GIL).

Позволяет использовать сколько угодно ядер. http://docs.python.org/library/multiprocessing.html . GIL он не для этого. GIL это средство синхронизации потоков, работает так, что в отдельный момент времени исполняется только один поток, что с одной стороны сильно упрощает многопоточные приложения, а с другой стороны замедляет потоки сильно нагружающие камень, хотя другие ресурсы при этом не страдают.

> этой проблемы. PyPy не первый кто заявляет о решении проблемы GIL,
> но похоже наиболее перспективный.

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


Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

19. "Представлен pypy-stm, интерпретатор Python с поддержкой расп..."  +/
Сообщение от Аноним (??) on 11-Май-12, 14:58 
аноним не читатель, аноним писатель?

1) multiprocessing запускает отдельный _процесс_
2) PyPy _не_ первый

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

27. "Представлен pypy-stm, интерпретатор Python с поддержкой расп..."  +/
Сообщение от Аноним (??) on 11-Май-12, 16:16 
> 1) multiprocessing запускает отдельный _процесс_

А чо, треды оно не того? Бла, даже жабаскрипт уже умеет фоновые воркеры :)


Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

31. "Представлен pypy-stm, интерпретатор Python с поддержкой расп..."  +1 +/
Сообщение от Аноним (??) on 11-Май-12, 18:49 
Да умеет питон треды! Только по факту в конкретный промежуток времени работать может только один тред. Типа ухватил GIL и работает, а другие должны ждать. Другими словами в каждый конкретный момент времени занято может быть только ядро, сколько бы ни было тредов и ядер. Вопрос решается или форканьем или либами заточенными под мультипроцессорность.
Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

33. "Представлен pypy-stm, интерпретатор Python с поддержкой расп..."  +/
Сообщение от Аноним (??) on 11-Май-12, 19:41 
>Только по факту в конкретный промежуток времени работать может только один тред.

Немаловажное замечание: в рамках одного процесса, а процессов может быть много.

Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

34. "Представлен pypy-stm, интерпретатор Python с поддержкой расп..."  +/
Сообщение от Аноним (??) on 11-Май-12, 20:14 
Конечно, может. Но в питоне синхронизация тредов и процессов вещи очень сильно разные по удобству.
Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

47. "Представлен pypy-stm, интерпретатор Python с поддержкой расп..."  +/
Сообщение от Аноним (??) on 12-Май-12, 11:27 
> Конечно, может. Но в питоне синхронизация тредов и процессов вещи очень сильно
> разные по удобству.

Треды синхронизируют механизм GIL, а процессы руками.

Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

43. "Представлен pypy-stm, интерпретатор Python с поддержкой расп..."  –3 +/
Сообщение от Аноним (??) on 12-Май-12, 10:39 
> Да умеет питон треды! Только по факту в конкретный промежуток времени работать
> может только один тред.

Прямо времена Windows 3.0 вспоминаются... там тоже такая "многозадачность" была. Кто ухватил время проца, тот и в дамках. Пока не отдаст - остальные курят бамбук. Правда вот почему-то на такую схему были нарекания :)

Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

45. "Представлен pypy-stm, интерпретатор Python с поддержкой расп..."  +/
Сообщение от Аноним (??) on 12-Май-12, 11:17 
>Прямо времена Windows 3.0 вспоминаются... там тоже такая "многозадачность" была

Вы сейчас продемонстрировали, что  не понимаете  разницу между задачей, процессом и потоком.

Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

12. "Представлен pypy-stm, интерпретатор Python с поддержкой расп..."  +1 +/
Сообщение от spanasik email(ok) on 11-Май-12, 13:13 
ты серьёзно считаешь, что питоном нельзя задействовать все ядра ?
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

18. "Представлен pypy-stm, интерпретатор Python с поддержкой расп..."  +1 +/
Сообщение от Нанобот on 11-Май-12, 14:36 
та я вообще такого не говорил.
но, раз уж ты затронул эту тему, то: сейчас задействовать все ядра достаточно сложно, нужно всякие там fork() использовать и т.п.
а вот в будущих версиях пи-пи (PyPy) для задействования всех ядер достаточно будет вызвать print 'hello, world'. ура великому языку питону!
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

32. "Представлен pypy-stm, интерпретатор Python с поддержкой расп..."  –1 +/
Сообщение от anonymous (??) on 11-Май-12, 18:58 
http://docs.python.org/library/multiprocessing.html не надо явно никакой форк вызывать. Но если хочется руками - всегда можно.
Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

22. "Представлен pypy-stm, интерпретатор Python с поддержкой расп..."  +4 +/
Сообщение от Аноним (??) on 11-Май-12, 15:12 
> ты серьёзно считаешь, что питоном нельзя задействовать все ядра ?

Смотря какой длины питоном. Достаточно длинным питоном, да с размаху можно так ... по ядрам то... Мало не покажется!


Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

39. "Представлен pypy-stm, интерпретатор Python с поддержкой расп..."  +/
Сообщение от Мяут (ok) on 12-Май-12, 01:06 
А есть шанс, что PyPy станет мейнстримовым, как когда-то hotspot стал основной Java VM?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

40. "интерпретатор Python"  –1 +/
Сообщение от szh (ok) on 12-Май-12, 01:07 
Они бы лучше python ускорили сам по себе, без распараллеливания. Он в 2 раза медленнее перл по моим замерам, хоть и меньше RAM ест.

Многие задачи все равно не распаралелить толком по ядрам, или это слишком геморно-дорого.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

46. "интерпретатор Python"  +1 +/
Сообщение от Аноним (??) on 12-Май-12, 11:24 
> Они бы лучше python ускорили сам по себе, без распараллеливания. Он в
> 2 раза медленнее перл по моим замерам, хоть и меньше RAM
> ест.

Я таки думаю, что в ваших замерах были либо многочисленные операции ввода/вывода и python был версии меньше 2.5, либо регулярки сравнивали.

> Многие задачи все равно не распаралелить толком по ядрам, или это слишком
> геморно-дорого.

И всё-таки большинство задач можно распараллелить.

Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

48. "интерпретатор Python"  +/
Сообщение от szh (ok) on 12-Май-12, 12:31 
python 2.6.5, perl 5.10.1, ubuntu 10.04

1) обсчет по большому графу -  массивы/словари(хэши)
2) регуляные выражения - совсем плохо

3) при рекурсии в 50000 python падал. Perl выдавал лишь warning. Pypy упал еще быстрее.

только как числодробилка python опередил perl.

Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

50. "интерпретатор Python"  +/
Сообщение от Аноним (??) on 12-Май-12, 14:48 
О боже.
- Вась, а топор оказывается быстрее лома.
- А как ты проверял?
- Красил стены. За два часа ломом смог покрасить пол метра, а топором - полтора!
Но дальше больше - потолок побелить ломом не получается вообще, а топором можно, только подкидывать приходится постоянно.
- Спасибо, что сказал! Теперь только топор. Не знаешь, какой лучший способ ловить рыбу топором?

Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

51. "интерпретатор Python"  +/
Сообщение от szh (ok) on 12-Май-12, 17:30 
perl и python это два топора у которых одно и то же предназначение, рубить одни и те же дрова.
Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

52. "интерпретатор Python"  +/
Сообщение от Аноним (??) on 12-Май-12, 23:25 
>python 2.6.5, perl 5.10.1, ubuntu 10.04
>1) обсчет по большому графу -  массивы/словари(хэши)

Это как? Что за алгоритм?

>2) регуляные выражения - совсем плохо

Плохо что?

>3) при рекурсии в 50000 python падал. Perl выдавал лишь warning. Pypy упал еще быстрее.

Рекурсии чего?

>только как числодробилка python опередил perl.

Вы путаетесь в показаниях, пару постов вы писали противоположное.

Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

54. "интерпретатор Python"  +/
Сообщение от szh (ok) on 13-Май-12, 01:48 
>>1) обсчет по большому графу -  массивы/словари(хэши)
> Это как? Что за алгоритм?

создающий массивы и добавляющий в них данные


>>2) регуляные выражения - совсем плохо
> Плохо что?

Совсем медленно. Хуже чем в 2 раза медленнее чем perl. И помимо этого неудобный синтаксис, слишком много лишних действий по сравнению с perl. вот смотрите http://snowplow.org/martin/rebench/

>> 3) при рекурсии в 50000 python падал. Perl выдавал лишь warning. Pypy упал еще быстрее.
> Рекурсии чего?

Функция вызывает сама себя. Не забудьте sys.setrecursionlimit(10000000) в python, а то он из коробки много отказывается поддержать.

>>только как числодробилка python опередил perl.
> Вы путаетесь в показаниях, пару постов вы писали противоположное

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

Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

60. "интерпретатор Python"  +/
Сообщение от Аноним (??) on 14-Май-12, 08:22 
>создающий массивы и добавляющий в них данные

Как это относится к графам? Я понимаю например нахождение оптимального пути в графе между элементами или нахождение наименьшего/наибольшего элемента. По работе с массивами numpy порвет всех. Заинтриговали, где код?

>Совсем медленно. Хуже чем в 2 раза медленнее чем perl. И помимо этого неудобный синтаксис, слишком много лишних действий по сравнению с perl. вот смотрите http://snowplow.org/martin/rebench/

Вас 2006 год в статье не смущает? С тех пор всё сильно изменилось. Помимо re есть и другие библиотеки.
http://code.google.com/p/re2/
https://github.com/dprokoptsev/pire
http://pypi.python.org/pypi?%3Aaction=search&term=regul...

>Функция вызывает сама себя.

Я в курсе что такое рекурсия, вы функцию покажите.

Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

41. "Представлен pypy-stm, интерпретатор Python с поддержкой расп..."  +/
Сообщение от evgeny_t (ok) on 12-Май-12, 02:06 
мда транзакции вместо локов ) что то новое, чторошо что они не пишут ядро linux )
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

44. "Представлен pypy-stm, интерпретатор Python с поддержкой расп..."  +/
Сообщение от Аноним (??) on 12-Май-12, 10:42 
А вы уверены, что транзакции это хуже локов с архитектурной точки зрения и точки зрения быстродействия?
Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

53. "Представлен pypy-stm, интерпретатор Python с поддержкой расп..."  +/
Сообщение от Аноним (??) on 12-Май-12, 23:27 
> А вы уверены, что транзакции это хуже локов с архитектурной точки зрения
> и точки зрения быстродействия?

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

Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

59. "Представлен pypy-stm, интерпретатор Python с поддержкой расп..."  +/
Сообщение от etw (ok) on 13-Май-12, 11:43 
STM зачастую медленнее хорошо написанных явных блокировок, особенно, при небольшом числе процессоров/ядер, т.к. при работе с общей памятью накладные расходы на ведение лога и коммиты никуда не исчезают
Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

55. "Представлен pypy-stm, интерпретатор Python с поддержкой расп..."  +/
Сообщение от evgeny_t (ok) on 13-Май-12, 07:54 
транзакции не панацея, и имеют свои проблемы
дедлоки, конфликты при оптимистических транзакциях.

нет не уверен, но как показывает практика (java с#) нормальное решение это локи.
но возможно 0.0001% они откроют новую веху в построении паралельных програм )


Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

56. "Представлен pypy-stm, интерпретатор Python с поддержкой расп..."  +/
Сообщение от evgeny_t (ok) on 13-Май-12, 07:56 
включая бесконечное зацикливание которе ещё никто не разрешил )
Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

57. "Представлен pypy-stm, интерпретатор Python с поддержкой расп..."  +/
Сообщение от evgeny_t (ok) on 13-Май-12, 08:04 
да же с++ есть локи )
то есть нормально когда у тебя есть локи, а потом можно и всё остальное придумывать.

Походу питону ещё долго жить с глобальной блокировкой. )

Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

61. "Представлен pypy-stm, интерпретатор Python с поддержкой расп..."  +/
Сообщение от Аноним (??) on 14-Май-12, 09:10 
А чем "это" лучше Clojure?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру