| 1.5, ZeroOne (ok), 12:48, 11/05/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Интересная идея. Что ж, удачи им.
А реализацию многопоточности через С/С++ расширения либо через грядущую версию С с поддержкой этой самой многопоточности ещё не пробовали делать или же что-то пробовали, да получилось не очень? Кто-то знает? Если есть ссылки, буду рад.
| | |
| |
| 2.10, жопка3 (?), 13:06, 11/05/2012 [^] [^^] [^^^] [ответить]
| +2 +/– |
А расскажите, пожалуйста, подробней про грядущую версию С с поддержкой многопоточности?
| | |
| |
| 3.15, Аноним (-), 13:48, 11/05/2012 [^] [^^] [^^^] [ответить]
| –8 +/– |
Внезапно, многопоточность в Си поддерживается уже как минимум с 1995 года, если не раньше. Два слова: POSIX threads. Подробней: cc -lpthread my_multithreaded_program.c -o my_multithreaded_program
| | |
| |
| 4.16, Аноним (-), 14:23, 11/05/2012 [^] [^^] [^^^] [ответить]
| +/– | |
>Внезапно, многопоточность в Си поддерживается уже как минимум с 1995 года
Бывает что ирония и сарказм не улавливается, но не настолько.
| | |
| 4.20, Аноним (-), 15:07, 11/05/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
>POSIX threads
>многопоточность в Си
pthread не являются частью стандарта С.
| | |
| |
| 5.25, Аноним (-), 16:13, 11/05/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> pthread не являются частью стандарта С.
Ага, и еще 100500 либ не являются. Это не мешает ими пользоваться.
| | |
| |
| 6.36, Аноним239 (?), 22:32, 11/05/2012 [^] [^^] [^^^] [ответить]
| +/– |
Еще как мешает.
Что делать на платформах под которые есть компилятор С но нет pthread?
| | |
| |
| 7.42, Аноним (-), 09:14, 12/05/2012 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Что делать на платформах под которые есть компилятор С но нет pthread?
С таким же успехом, питона может и не быть на некоей платформе. Например на всякой эмбеддовке он не в почете за жрач ресурсов. И?
| | |
|
|
|
|
| 3.21, Аноним (-), 15:09, 11/05/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> А расскажите, пожалуйста, подробней про грядущую версию С с поддержкой многопоточности?
google c11 threads.h
| | |
| 3.30, ZeroOne (ok), 17:05, 11/05/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
Сам ещё об этом ничего не знаю. Знаю, что с выходом C11 активировалось обсуждение развития и в стандарте С. Тогда я про грядущую многопоточность и узнал.
| | |
|
|
| |
| 2.9, Аноним (-), 13:04, 11/05/2012 [^] [^^] [^^^] [ответить]
| +/– |
Питон не умеет (нативно/эффективно) использовать более чем одно ядро в рамках одного процесса из-за родового проклятия (GIL). Треды есть, но они не решают этой проблемы. PyPy не первый кто заявляет о решении проблемы GIL, но похоже наиболее перспективный.
| | |
| |
| 3.17, Аноним (-), 14:33, 11/05/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Питон не умеет (нативно/эффективно) использовать более чем одно ядро в рамках одного
> процесса из-за родового проклятия (GIL).
Позволяет использовать сколько угодно ядер. http://docs.python.org/library/multiprocessing.html . GIL он не для этого. GIL это средство синхронизации потоков, работает так, что в отдельный момент времени исполняется только один поток, что с одной стороны сильно упрощает многопоточные приложения, а с другой стороны замедляет потоки сильно нагружающие камень, хотя другие ресурсы при этом не страдают.
> этой проблемы. PyPy не первый кто заявляет о решении проблемы GIL,
> но похоже наиболее перспективный.
Какой же он первый Jython, IronPython умеют это с рождения.
| | |
| |
| 4.19, Аноним (-), 14:58, 11/05/2012 [^] [^^] [^^^] [ответить]
| +/– | |
аноним не читатель, аноним писатель?
1) multiprocessing запускает отдельный _процесс_
2) PyPy _не_ первый
| | |
| |
| 5.27, Аноним (-), 16:16, 11/05/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> 1) multiprocessing запускает отдельный _процесс_
А чо, треды оно не того? Бла, даже жабаскрипт уже умеет фоновые воркеры :)
| | |
| |
| 6.31, Аноним (-), 18:49, 11/05/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
Да умеет питон треды! Только по факту в конкретный промежуток времени работать может только один тред. Типа ухватил GIL и работает, а другие должны ждать. Другими словами в каждый конкретный момент времени занято может быть только ядро, сколько бы ни было тредов и ядер. Вопрос решается или форканьем или либами заточенными под мультипроцессорность.
| | |
| |
| 7.33, Аноним (-), 19:41, 11/05/2012 [^] [^^] [^^^] [ответить]
| +/– | |
>Только по факту в конкретный промежуток времени работать может только один тред.
Немаловажное замечание: в рамках одного процесса, а процессов может быть много.
| | |
| |
| 8.34, Аноним (-), 20:14, 11/05/2012 [^] [^^] [^^^] [ответить] | +/– | Конечно, может Но в питоне синхронизация тредов и процессов вещи очень сильно р... текст свёрнут, показать | | |
|
| 7.43, Аноним (-), 10:39, 12/05/2012 [^] [^^] [^^^] [ответить]
| –2 +/– |
> Да умеет питон треды! Только по факту в конкретный промежуток времени работать
> может только один тред.
Прямо времена Windows 3.0 вспоминаются... там тоже такая "многозадачность" была. Кто ухватил время проца, тот и в дамках. Пока не отдаст - остальные курят бамбук. Правда вот почему-то на такую схему были нарекания :)
| | |
| |
| 8.45, Аноним (-), 11:17, 12/05/2012 [^] [^^] [^^^] [ответить] | +/– | Вы сейчас продемонстрировали, что не понимаете разницу между задачей, процессо... текст свёрнут, показать | | |
|
|
|
|
|
|
| |
| 3.18, Нанобот (?), 14:36, 11/05/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
та я вообще такого не говорил.
но, раз уж ты затронул эту тему, то: сейчас задействовать все ядра достаточно сложно, нужно всякие там fork() использовать и т.п.
а вот в будущих версиях пи-пи (PyPy) для задействования всех ядер достаточно будет вызвать print 'hello, world'. ура великому языку питону!
| | |
| 3.22, Аноним (-), 15:12, 11/05/2012 [^] [^^] [^^^] [ответить]
| +3 +/– | |
> ты серьёзно считаешь, что питоном нельзя задействовать все ядра ?
Смотря какой длины питоном. Достаточно длинным питоном, да с размаху можно так ... по ядрам то... Мало не покажется!
| | |
|
|
| 1.39, Мяут (ok), 01:06, 12/05/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 А есть шанс, что PyPy станет мейнстримовым, как когда-то hotspot стал основной Java VM?
| | |
| 1.40, szh (ok), 01:07, 12/05/2012 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
 Они бы лучше python ускорили сам по себе, без распараллеливания. Он в 2 раза медленнее перл по моим замерам, хоть и меньше RAM ест.
Многие задачи все равно не распаралелить толком по ядрам, или это слишком геморно-дорого.
| | |
| |
| 2.46, Аноним (-), 11:24, 12/05/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Они бы лучше python ускорили сам по себе, без распараллеливания. Он в
> 2 раза медленнее перл по моим замерам, хоть и меньше RAM
> ест.
Я таки думаю, что в ваших замерах были либо многочисленные операции ввода/вывода и python был версии меньше 2.5, либо регулярки сравнивали.
> Многие задачи все равно не распаралелить толком по ядрам, или это слишком
> геморно-дорого.
И всё-таки большинство задач можно распараллелить.
| | |
| |
| 3.48, szh (ok), 12:31, 12/05/2012 [^] [^^] [^^^] [ответить]
| +/– | |
python 2.6.5, perl 5.10.1, ubuntu 10.04
1) обсчет по большому графу - массивы/словари(хэши)
2) регуляные выражения - совсем плохо
3) при рекурсии в 50000 python падал. Perl выдавал лишь warning. Pypy упал еще быстрее.
только как числодробилка python опередил perl.
| | |
| |
| 4.50, Аноним (-), 14:48, 12/05/2012 [^] [^^] [^^^] [ответить]
| +/– |
О боже.
- Вась, а топор оказывается быстрее лома.
- А как ты проверял?
- Красил стены. За два часа ломом смог покрасить пол метра, а топором - полтора!
Но дальше больше - потолок побелить ломом не получается вообще, а топором можно, только подкидывать приходится постоянно.
- Спасибо, что сказал! Теперь только топор. Не знаешь, какой лучший способ ловить рыбу топором?
| | |
| |
| 5.51, szh (ok), 17:30, 12/05/2012 [^] [^^] [^^^] [ответить]
| +/– |
perl и python это два топора у которых одно и то же предназначение, рубить одни и те же дрова.
| | |
|
| 4.52, Аноним (-), 23:25, 12/05/2012 [^] [^^] [^^^] [ответить]
| +/– |
>python 2.6.5, perl 5.10.1, ubuntu 10.04
>1) обсчет по большому графу - массивы/словари(хэши)
Это как? Что за алгоритм?
>2) регуляные выражения - совсем плохо
Плохо что?
>3) при рекурсии в 50000 python падал. Perl выдавал лишь warning. Pypy упал еще быстрее.
Рекурсии чего?
>только как числодробилка python опередил perl.
Вы путаетесь в показаниях, пару постов вы писали противоположное.
| | |
| |
| 5.54, szh (ok), 01:48, 13/05/2012 [^] [^^] [^^^] [ответить]
| +/– |
>>1) обсчет по большому графу - массивы/словари(хэши)
> Это как? Что за алгоритм?
создающий массивы и добавляющий в них данные
>>2) регуляные выражения - совсем плохо
> Плохо что?
Совсем медленно. Хуже чем в 2 раза медленнее чем perl. И помимо этого неудобный синтаксис, слишком много лишних действий по сравнению с perl. вот смотрите http://snowplow.org/martin/rebench/
>> 3) при рекурсии в 50000 python падал. Perl выдавал лишь warning. Pypy упал еще быстрее.
> Рекурсии чего?
Функция вызывает сама себя. Не забудьте sys.setrecursionlimit(10000000) в python, а то он из коробки много отказывается поддержать.
>>только как числодробилка python опередил perl.
> Вы путаетесь в показаниях, пару постов вы писали противоположное
Вы думаете если я утверждаю что python тормоз, то я не признаю что он в чем-то быстрей, если он там действительно быстрей ?
| | |
| |
| 6.60, Аноним (-), 08:22, 14/05/2012 [^] [^^] [^^^] [ответить] | +/– | Как это относится к графам Я понимаю например нахождение оптимального пути в гр... большой текст свёрнут, показать | | |
|
|
|
|
|
| 1.41, evgeny_t (ok), 02:06, 12/05/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 мда транзакции вместо локов ) что то новое, чторошо что они не пишут ядро linux )
| | |
| |
| 2.44, Аноним (-), 10:42, 12/05/2012 [^] [^^] [^^^] [ответить]
| +/– |
А вы уверены, что транзакции это хуже локов с архитектурной точки зрения и точки зрения быстродействия?
| | |
| |
| 3.53, Аноним (-), 23:27, 12/05/2012 [^] [^^] [^^^] [ответить]
| +/– |
> А вы уверены, что транзакции это хуже локов с архитектурной точки зрения
> и точки зрения быстродействия?
Транзакции памяти кушать будут больше, быстродействие возможно будет больше.
| | |
| |
| 4.59, etw (ok), 11:43, 13/05/2012 [^] [^^] [^^^] [ответить]
| +/– |
 STM зачастую медленнее хорошо написанных явных блокировок, особенно, при небольшом числе процессоров/ядер, т.к. при работе с общей памятью накладные расходы на ведение лога и коммиты никуда не исчезают
| | |
|
| 3.55, evgeny_t (ok), 07:54, 13/05/2012 [^] [^^] [^^^] [ответить]
| +/– |
транзакции не панацея, и имеют свои проблемы
дедлоки, конфликты при оптимистических транзакциях.
нет не уверен, но как показывает практика (java с#) нормальное решение это локи.
но возможно 0.0001% они откроют новую веху в построении паралельных програм )
| | |
| |
| |
| 5.57, evgeny_t (ok), 08:04, 13/05/2012 [^] [^^] [^^^] [ответить]
| +/– |
да же с++ есть локи )
то есть нормально когда у тебя есть локи, а потом можно и всё остальное придумывать.
Походу питону ещё долго жить с глобальной блокировкой. )
| | |
|
|
|
|
|
