|
2.2, bav (ok), 11:52, 07/07/2014 [^] [^^] [^^^] [ответить]
| +9 +/– |
… а GIL до сих пор мешает кому угодно, только не питонистам.
| |
|
|
|
5.30, Аноним (-), 22:46, 07/07/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
Юнит-тесты доказывают лишь невменяемость некоторых программистов, ибо отнимают кучу времени и сил, препятствуют дальнейшей разработки и рефакторингу кодовой базы, при том что обеспечивают надёжность лишь в типовых ситуациях.
| |
|
6.40, МММ (??), 07:38, 08/07/2014 [^] [^^] [^^^] [ответить]
| +2 +/– |
> Юнит-тесты доказывают лишь невменяемость некоторых программистов, ибо отнимают кучу времени
> и сил, препятствуют дальнейшей разработки и рефакторингу кодовой базы, при том
> что обеспечивают надёжность лишь в типовых ситуациях.
И как ты будешь рефакторинг делать без тестов? Тесты это такая штука, которая позволяет формализовать требования к задаче еще до написания кода и это серьезно экономит время, тесты пишутся легко, во время написания тестов программист думает о том как решить задачу которую описывает тест,
тесты позволяют использовать нормальный DevOps с CI, автоматическим тестированием и деплоем и позволяют по несколько раз в день выкатывать новые версии продукта, тесты позволяют спокойно спать ночью, а не фиксить "внезапно" возникшие проблемы на продакшине.
| |
|
|
|
3.8, Аноним (-), 14:54, 07/07/2014 [^] [^^] [^^^] [ответить]
| +/– |
Например, для web-разработки GIL не является узким местом, так как проблема решается запуском нескольких экземпляров обработчиков запросов.
| |
|
4.13, Аноним (-), 18:07, 07/07/2014 [^] [^^] [^^^] [ответить]
| +3 +/– |
У веб разработчиков узким обычно вообще является другое место.
| |
4.20, Филипп Филиппович (ok), 19:54, 07/07/2014 [^] [^^] [^^^] [ответить]
| +/– |
Если под веб-разработкой понимать сайтописательство, то несомненно. Там всё решается специфичной средой выполнения. Если же говорить о сетевом коде вообще (Twisted, gevent и т.п.), то картина меняется. Там GIL и использование разных изобретений вместо простых потоков очень мешает.
| |
|
5.23, МММ (??), 20:42, 07/07/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Если под веб-разработкой понимать сайтописательство, то несомненно. Там всё решается специфичной
> средой выполнения. Если же говорить о сетевом коде вообще (Twisted, gevent
> и т.п.), то картина меняется. Там GIL и использование разных изобретений
> вместо простых потоков очень мешает.
И каким местом в асинхронных фреймворках мешает GIL.
| |
|
6.33, Филипп Филиппович (ok), 23:42, 07/07/2014 [^] [^^] [^^^] [ответить]
| +/– |
Вот именно тем и мешает, что вместо нормальных потоков городится чёрт знает что, работающее в итоге в одном. Что в Twisted, что гринлеты в gevent параллелятся очень специфическим образом. Иногда это нормально. Иногда это большая головная боль, и нужна возможность использовать нормальные потоки ОС, способные эффективно выполняться на разных ядрах и параллелиться без явного использования логики сопрограмм или патчей к половине стандартной библиотеки.
Нормальный архитектурный паттерн полноценного асинхронного фреймворка с реакторами всегда предполагает потоки. Достаточно вспомнить boost::asio. Реактор -- самое базовое понятие, но именно из-за GIL в асинхронных фреймворках реактор реализован не так, как обычно, а через одно место. Да, красиво, да, остроумно, но всё равно криво.
| |
|
7.37, МММ (??), 07:12, 08/07/2014 [^] [^^] [^^^] [ответить]
| +/– |
>Вот именно тем и мешает, что вместо нормальных потоков городится чёрт знает что, работающее в итоге в одном. Что в Twisted, что гринлеты в gevent параллелятся очень специфическим образом. Иногда это нормально. Иногда это большая головная боль, и нужна возможность использовать нормальные потоки ОС, способные эффективно выполняться на разных ядрах и параллелиться без явного использования логики сопрограмм или патчей к половине стандартной библиотеки.
В асинхронных фреймворках ничего не параллелится, на то они и асинхронные. Весь смысл существования асинхронной парадигмы в передаче управления другой задаче(функции), если выполняемая задача(функция) попала под блокировку, никаких потоков для этого не нужно, процесс имеет один поток.
| |
|
|
9.46, МММ (??), 18:25, 08/07/2014 [^] [^^] [^^^] [ответить] | +/– | Во-во прочти-ка сам Какие блин отличия, внутри все те же, внезапно libev libe... текст свёрнут, показать | |
|
|
11.55, MM M (?), 20:06, 13/07/2014 [^] [^^] [^^^] [ответить] | +/– | Gevent так и работает from gevent pool import Pool , в чём проблема с потоками ... текст свёрнут, показать | |
|
|
|
|
|
|
5.27, bav (ok), 20:59, 07/07/2014 [^] [^^] [^^^] [ответить]
| +/– |
> Там GIL и использование разных изобретений вместо простых потоков очень мешает.
Внезапно, GIL сделан как раз с целью обеспечить работу простых потоков.
| |
|
6.34, Филипп Филиппович (ok), 23:45, 07/07/2014 [^] [^^] [^^^] [ответить]
| +/– |
>> Там GIL и использование разных изобретений вместо простых потоков очень мешает.
> Внезапно, GIL сделан как раз с целью обеспечить работу простых потоков.
Бездну понимания прозреваю в словах ваших я. Это один из существующих способов. Очень простой. Довольно эффективный на одноядерных машинах. Но сейчас уже совершенно устаревший именно из-за направления развития современных процессоров в последние 10 лет.
| |
|
7.38, МММ (??), 07:16, 08/07/2014 [^] [^^] [^^^] [ответить]
| +/– |
>>> Там GIL и использование разных изобретений вместо простых потоков очень мешает.
>> Внезапно, GIL сделан как раз с целью обеспечить работу простых потоков.
> Бездну понимания прозреваю в словах ваших я. Это один из существующих способов.
> Очень простой. Довольно эффективный на одноядерных машинах. Но сейчас уже совершенно
> устаревший именно из-за направления развития современных процессоров в последние 10 лет.
А других для интерпретируемых языков методов нет, точнее есть форк интерпретатора, но он менее эффективный. А для многопроцессорных систем логичнее использовать процессы.
| |
|
|
9.45, МММ (??), 18:19, 08/07/2014 [^] [^^] [^^^] [ответить] | +/– | Программа написанная на интерпретируемом языке не может выполняться отдельно без... текст свёрнут, показать | |
9.48, МММ (??), 18:37, 08/07/2014 [^] [^^] [^^^] [ответить] | +/– | Отличие в байт-коде, и методах его трансляции Они совсем разные Байт-код питон... текст свёрнут, показать | |
|
|
|
|
|
|
|
2.12, Аноним (-), 18:04, 07/07/2014 [^] [^^] [^^^] [ответить]
| –2 +/– |
> шёл 2014 год...
А питонисты зарубались с рубистами из соседней новости: кто больше версий не совместимого с самим собой шита выкатить сумеет?! Рубисты накручивали версию, питонисты задолбавшись крутить версию, выпускали несовместимые между собой недопилки.
| |
2.28, МММ (??), 20:59, 07/07/2014 [^] [^^] [^^^] [ответить]
| +/– |
> шёл 2014 год...
Да всё банально. Потоки используют для экономии памяти и времени на создание процесса. При этом получают проблемы с единой областью памяти, т.е. данные могут теряться вследсвии перезаписи в одно и тоже место памяти разными потоками и в тоже время получают плюсы за счет простоты передачи данных между потоками -- так как память общая и данные общие. То есть многопоточное программирование это довольно трудная задача, в скриптовых/интерпретированных языках не решаемая в принципе. По этому или GIL как в python/ruby или форк интерпретатора как в lua/perl и т.п., во-втором случае выигрыша по сравнению с фоком процесса никакого а трахаться с памятью всё равно придется. Так что GIL был есть и всегда будет.
| |
|
3.31, Аноним (-), 22:49, 07/07/2014 [^] [^^] [^^^] [ответить]
| +/– |
Тем более что в современном мире параллельность означает наличие многих машин, а не четырёхядерного процика, упирающегося в частоту оперативы.
| |
3.50, Аноним (-), 21:08, 08/07/2014 [^] [^^] [^^^] [ответить]
| +/– |
В нормальных операционных системах время создания процесса такое же как и потока.
| |
|
|
1.5, anonim66666 (?), 13:55, 07/07/2014 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
если нужно что то быстро обсчитать(очень тяжелое), то проще и быстрее заиспользовать pyopencl. он в разы(на порядки, если на gpu) быстрее, чем на многопоточном python.
| |
|
2.15, Аноним (-), 18:09, 07/07/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
> pyopencl.
Учитывая что в opencl пишут на специфичном подвиде C, питон там вообще лишний элемент пейзажа.
| |
|
3.22, МММ (??), 20:39, 07/07/2014 [^] [^^] [^^^] [ответить]
| +/– |
>> pyopencl.
> Учитывая что в opencl пишут на специфичном подвиде C, питон там вообще
> лишний элемент пейзажа.
А в pyopencl пишут таки на обычном питоне.
| |
|
2.18, Антоним (?), 19:50, 07/07/2014 [^] [^^] [^^^] [ответить]
| +/– |
Не каждую задачу можно ускорить, запустив на GPU. К тому же требует модификации кода.
| |
|
|
2.16, Аноним (-), 18:11, 07/07/2014 [^] [^^] [^^^] [ответить]
| –3 +/– |
> считаем Mandelbrot Set на gpu за 41ms, а не за 9 сек
> и даже не за 23 ...
Только GPU вообще питон выполнять не умеет, а opencl к питону весьма слабо относится. В порядке извращения конечно можно и из питона дергать, но писать на 2 кардинально разных ЯП - не то чтобы сильно удобно.
| |
|
1.9, Аноним (-), 15:46, 07/07/2014 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
> При выполнении однопоточных программ наблюдается заметное отставание от PyPy на 20% - 300%
не нужно.
| |
1.10, Аноним (-), 15:50, 07/07/2014 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
>Для решения проблемы с распараллеливанием на многоядержных системах в PyPy-STM осуществлён переход от традиционных блокировок к программной транзакционной памяти, в качестве механизма для обеспечения параллелизма.
Это круто. А как они проверяют отсутствие побочных эффектов внутри транзакций? Это более-менее годно смогли только в Haskell запилить.
| |
|
2.19, Антоним (?), 19:52, 07/07/2014 [^] [^^] [^^^] [ответить]
| +/– |
Аппаратные реализации тоже неплохо работают. Подробностей реализации, конечно же, нет, но Intel сообщали, что используют протоколы когерентности кэша для транзакций. Задачи схожи.
| |
|
1.11, Anonymus (?), 17:04, 07/07/2014 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
То есть второй проц добавляет 90% производительности, а четвёртый всего-лишь 18. Апроксимируя получим 10% прирост на энный процессор. Вопрос: а накуя такое чудо?
| |
|
2.14, Аноним (-), 18:08, 07/07/2014 [^] [^^] [^^^] [ответить]
| +/– |
> То есть второй проц добавляет 90% производительности, а четвёртый всего-лишь 18.
Вот такая вот хреновая многопроцессорность...
| |
2.17, bav (ok), 18:50, 07/07/2014 [^] [^^] [^^^] [ответить]
| +2 +/– |
> Вопрос: а накуя такое чудо?
Это только прототип. Места для оптимизаций там еще много. А вообще это важная веха — наконец (!) реализация без GIL начинает масштабироваться.
| |
|
|
4.26, bav (ok), 20:54, 07/07/2014 [^] [^^] [^^^] [ответить]
| +/– |
> STM в случае топика в принципе не масштабируется
В новости написано обратное. И прогресс с предыдущей попытки налицо.
| |
|
5.32, all_glory_to_the_hypnotoad (ok), 23:04, 07/07/2014 [^] [^^] [^^^] [ответить]
| +/– |
Мало ли что там написано и какими надеждами живут разработчики PyPy-STM, фундаментальные проблемы всё равно остаются и решить они их не смогут.
| |
|
6.36, chinarulezzz (ok), 02:06, 08/07/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
расскажи о фундаментальных проблемах а еще лучше на здоровенную книжку линк, или скажи что всем и так это всё известно, и на форумах не раз обсуждалось :D
| |
|
|
|
|
2.52, Аноним (-), 22:58, 08/07/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
> То есть второй проц добавляет 90% производительности, а четвёртый всего-лишь 18. Апроксимируя
> получим 10% прирост на энный процессор. Вопрос: а накуя такое чудо?
А закон Амдала никуда не делся. Он, сцуко, вишь ты, фундаментальный. Оверхед в реальном мире на согласование работы камней был, есть и будет. А сферические кони только в вакууме живут.
| |
|
1.24, all_glory_to_the_hypnotoad (ok), 20:46, 07/07/2014 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
> При выполнении однопоточных программ наблюдается заметное отставание от PyPy на 20% - 300%, но уже при запуске многопоточной программы на двух ядрах CPU PyPy-STM начинает опережать PyPy, при увеличении числа вовлечённых в выполнение ядер CPU разрыв увеличивается.
молодцы, заоптимизировали 20 % потенциальных юз-кейсов и угробили остальные 80 %. Кому оно такое нужно.
| |
|
2.53, Аноним рус (?), 11:18, 09/07/2014 [^] [^^] [^^^] [ответить]
| +/– |
Это может быть только ваши потребности такие, и ваши цифры, для других они другие.
| |
|
|