Параллельность в Fortress
2007-12-01 at 05:12 | Posted in devel, review, think | Leave a commentTags: concurrency, fortress, mpi, openmp
За последние пару месяцев дважды услышал о языке Fortress: один раз из интервью с Guy Steele на SE Radio и ещё раз из презентации человека из питерского Sun Microsystems. Это подтолкнуло меня почитать интересные моменты беты его спецификации. Об этих интересных моментах я коротко и расскажу.
Прежде всего, Fortress — язык программирования общего назначения, созданный в лабораториях Sun. Он объединяет в себе ряд свойтв функциональных и ОО-языков. По духу он близок к Haskell, Scala и т. п. Что отличает его от этих языков:
- Синтаксис, который нравится математикам (даже Haskell оставлен позади)
- Встроенная в язык модель распараллеливания
Параллелизм здесь имеется в виду нефункциональный, т. е. нужный исключительно для оптимизации. Используется общая память, а не передача сообщений (в духе OpenMP, а не MPI). Соответственно, программы предназначены для многоядерных и многопроцессорных систем, а не для кластеров и гридов.
Особенности же Fortress следующие: ко всем объектам привязана метаинформация о характеристиках их локальности по отношению друг к другу. На основе этой информации, а также структур данных из библиотек (типа векторов, различных матриц и т. д.), использующих её для распределения, и конструкций языка типа циклов и кортежей среда исполнения распараллеливает программу. Происходит это прозрачно для прикладного программиста, с учётом в run-time имеющихся ресурсов типа ядер, процессоров, характеристик локальности памяти. Вся нагрузка по распараллеливанию уходит с прикладного программиста (скажем «нет» прагмам OpenMP) на разработчика библиотек, а именно, структур данных, «умеющих» учесть метаинформацию для распределения данных по локальным фрагментам с целью их параллельной обработки.
Это был короткий рассказ о Fortress. Под конец несколько скептических слов. Сам проект не вышел за рамки исследования (причём выбыл из программы DARPA HPCS), язык и инструментарий разработчика являются сильно недобитыми. Хотя это язык общего назначения, особенности его таковы, что он пригодится только для узкого класса задач: математические вычисления на сильно-связанных параллельных системах. Его пытаются позиционировать как язык будущего для эффективного программирования n-ядерных процессоров в связи с тем, что n для большинства компьютеров будет расти. Однако большинству программ характерен параллелизм не данных, а задач, который лучше программировать явно (иногда и неявно для чистых функций). Есть мнение, что для этого лучше подходят модели типа Actors (вид Message Passing) и языки вроде Erlang и Scala.
Multi-threaded map() for Python
2007-09-05 at 04:39 | Posted in devel, lang:en, talk | 24 CommentsTags: concurrency, gil, python
The idea of multi-processing map()
for Python is quite nice. And what about multi-threaded one? Threads usually cause less overhead than processes. If a mapping function is quite side-effect free (even if it does some HTTP GETs — they are idempotent), you don’t rely on a parallel execution model you’ve selected. And when it isn’t, then such an approach is error-prone. I’ve implemented a very simple threaded exception-aware map()
using one thread per call. This is the basic usage scenario:
@measured
def single_threaded():
return [urlopen(url) for x in range(count)]
@measured
def multi_threaded():
return map(lambda x: urlopen(url), range(count))
ps_s = single_threaded()
ps_m = multi_threaded()
The results for url = "http://ya.ru/"
and count = 1000
:
single_threaded() is finished in 121.333 s
multi_threaded() is finished in 29.692 s
A multi-threaded map()
is rather useful, isn’t it?
P. S. The first exception in a map()
thread will be re-raised (with its traceback) in the main thread while others will be suppressed.
Blog at WordPress.com.
Entries and comments feeds.