The Caml run-time system is not reentrant: at any time, at most one thread
can be executing Caml code or C code that uses the Caml run-time system.
Technically, this is enforced by a "master lock" that any thread must hold
while executing such code.
это ставит крест на очень многих возможных применениях
Да, с параллелизмом на уровне потоков там туго. Сборщик мусора, работающий в многопоточной программе, намного сложнее и тормознее, поэтому авторы сознательно оставили его однопоточным, а параллелить предлагают на уровне обменивающихся сообщениями процессов, считая shared memory parallelism вообще тупиковой ветвью. Есть проект многопоточного GC для окамла — oc4mc, он вроде работает, но действительно заметно медленнее.
Эта ситуация с потоками — одна из причин, почему я еще не везде отказался от С++ в пользу окамла.
DM>Да, с параллелизмом на уровне потоков там туго. Сборщик мусора, работающий в многопоточной программе, намного сложнее и тормознее, поэтому авторы сознательно оставили его однопоточным, а параллелить предлагают на уровне обменивающихся сообщениями процессов, считая shared memory parallelism вообще тупиковой ветвью. Есть проект многопоточного GC для окамла — oc4mc, он вроде работает, но действительно заметно медленнее.
DM>Эта ситуация с потоками — одна из причин, почему я еще не везде отказался от С++ в пользу окамла.
Я правильно понял, что в окамле точно такой же GIL как в питоне?
Здравствуйте, D. Mon, Вы писали:
DM>Да, с параллелизмом на уровне потоков там туго. Сборщик мусора, работающий в многопоточной программе, намного сложнее и тормознее, поэтому авторы сознательно оставили его однопоточным, а параллелить предлагают на уровне обменивающихся сообщениями процессов, считая shared memory parallelism вообще тупиковой ветвью. Есть проект многопоточного GC для окамла — oc4mc, он вроде работает, но действительно заметно медленнее.
DM>Эта ситуация с потоками — одна из причин, почему я еще не везде отказался от С++ в пользу окамла.
Я давно к нему (OCaml-у) присматривался, но так и не решился его использовать. Как я понял, у тебя богатый опыт использования OCaml, если не трудно, не ответишь на пару вопросов?
— ты пишешь все приложение целиком ан OCaml, или только какую-то часть? Если часть, как организуешь взаимодействие?
— компилятор умеет генерировать нативный код для ARM процессоров? можно ли использовать OCaml на мобильных платформах?
— как обстоят дела с поддержкой 64 битных систем?
Здравствуйте, Temoto, Вы писали:
T>Я правильно понял, что в окамле точно такой же GIL как в питоне?
Я не знаю подробностей про питоний, но в целом похоже. Можно иметь много окамловых потоков, но они будут работать не одновременно, а как на одноядерной машине. Из окамла можно вызвать код на Си, в котором использовать много потоков. Если они не лезут в кучу окамла, то они могут работать параллельно окамловскому коду.
T>>Я правильно понял, что в окамле точно такой же GIL как в питоне?
DM>Я не знаю подробностей про питоний, но в целом похоже. Можно иметь много окамловых потоков, но они будут работать не одновременно, а как на одноядерной машине. Из окамла можно вызвать код на Си, в котором использовать много потоков. Если они не лезут в кучу окамла, то они могут работать параллельно окамловскому коду.
Точно такой же.
Спасибо, вы открыли мне глаза. Кошмар, ужас, разочарование.
У меня опыт сравнительно долгий, но не шибко богатый (в плане платформ и библиотек).
KP>- ты пишешь все приложение целиком ан OCaml, или только какую-то часть? Если часть, как организуешь взаимодействие?
Целиком, кое-какие мелочи иногда дописываются на С и линкуются.
KP>- компилятор умеет генерировать нативный код для ARM процессоров? можно ли использовать OCaml на мобильных платформах?
На линуксах и маках — отлично. Кодогенератор для 64 бит лучше 32-битного, и нет таких дурацких ограничений на размер массивов и строк. Для винды 64-битная версия вроде как есть, но на официальном сайте нет бинарников, а самостоятельно собрать редкая птица сможет. Я пользуюсь 32-битной.
А можно зайти с другой стороны. Например иметь несколько Сишных потока из которых обращаться к различным инстансам Окамла, но в рамках одного процесса?
Здравствуйте, kaa.python, Вы писали:
KP>А можно зайти с другой стороны. Например иметь несколько Сишных потока из которых обращаться к различным инстансам Окамла, но в рамках одного процесса?
Это надо, чтобы у каждого была своя куча и те части рантайма, которые сейчас не reentrant. Непросто это. Но можете попробовать.
Re[5]: OCaml - язык общего назначения?
От:
Аноним
Дата:
18.08.11 20:51
Оценка:
Здравствуйте, kaa.python, Вы писали:
KP>А можно зайти с другой стороны. Например иметь несколько Сишных потока из которых обращаться к различным инстансам Окамла, но в рамках одного процесса?
а смысл? тогда окамловые вещи будут полностью изолированы друг от друга, и не смогут коммуницировать кроме как через С-код. даже если такое сделать, то будет очень много проблем склеивания
KP>>А можно зайти с другой стороны. Например иметь несколько Сишных потока из которых обращаться к различным инстансам Окамла, но в рамках одного процесса?
А>а смысл?
Смысл в том, что однопоточные приложения, на данный момент, практически бесполезны. Макимум какая-то консольная утилита, и то не факт.
А> тогда окамловые вещи будут полностью изолированы друг от друга, и не смогут коммуницировать кроме как через С-код. даже если такое сделать, то будет очень много проблем склеивания
Изолированность не проблема. Любая задача довольно просто может быть разбита на подзадачи, которые уже и будут выполняться паралельно. А вот что делать с монолитным приложением, которое не в состоянии выполнить задачу в отдельном потоке. Практически бесполезно это
Здравствуйте, kaa.python, Вы писали:
KP>Изолированность не проблема.
Тогда можно разделить на несколько параллельных процессов, что и предлагают авторы языка. В Хроме вон так сделали и очень гордятся результатом.
KP> Любая задача довольно просто может быть разбита на подзадачи, которые уже и будут выполняться паралельно. А вот что делать с монолитным приложением, которое не в состоянии выполнить задачу в отдельном потоке. Практически бесполезно это
Задачу-то можно выполнить в отдельном потоке, просто не так быстро. Но если задача не числомолотилка, а ввод-вывод, то разница с "настоящим" параллельным потоком вряд ли будет заметна при правильном подходе.
Для однопоточных программ тоже немало применений есть. Например, я делал на окамле интерактивный анализатор логов с веб-интерфейсом. Не представляю, где бы мне там пригодились параллельные потоки (с диска читать лучше последовательно, а пользователь один, и много запросов сразу не посылает). Еще делал компилятор, он и без потоков очень быстрый получился.
Здравствуйте, D. Mon, Вы писали:
DM>Здравствуйте, kaa.python, Вы писали:
KP>>Изолированность не проблема.
DM>Тогда можно разделить на несколько параллельных процессов, что и предлагают авторы языка. В Хроме вон так сделали и очень гордятся результатом.
В Хроме, кроме того, каждый процесс запускает потоки для различных фоновых операций. Куда ж без этого?
DM>Задачу-то можно выполнить в отдельном потоке, просто не так быстро. Но если задача не числомолотилка, а ввод-вывод, то разница с "настоящим" параллельным потоком вряд ли будет заметна при правильном подходе.
Сейчас идет тенденция к увеличению количества процессоров. Зачем же целенаправленно вводить какие-то ограничения и усложнять самому себе жизнь?
DM>Для однопоточных программ тоже немало применений есть. Например, я делал на окамле интерактивный анализатор логов с веб-интерфейсом. Не представляю, где бы мне там пригодились параллельные потоки (с диска читать лучше последовательно, а пользователь один, и много запросов сразу не посылает). Еще делал компилятор, он и без потоков очень быстрый получился.
Там бы они пригодились для раздельного чтения и анализа. Пользователей может быть больше чем 1. Хотя в приведенном тобой случае одного потока достаточно, согласен.
Т.е. да, для рядя задач одного потока хватает. Просто для моих задач наличие возможности запустить фоновую операцию критично. На столько критично.
Re[9]: OCaml - язык общего назначения?
От:
Аноним
Дата:
20.08.11 07:21
Оценка:
Здравствуйте, kaa.python, Вы писали:
KP>Т.е. да, для рядя задач одного потока хватает. Просто для моих задач наличие возможности запустить фоновую операцию критично. На столько критично.
пока я вижу только один выход — если ест что-то ресурсоемкое (или просто длинное) фоновое, то можно запускать в отдельно окамловском потоке, который будет дергать С-callback, в котором будет сначала освобождаться gil, а только потом выполняться та самая ресурсоемкая задача.
честно говоря, не ожидал — тут столько лет разговоры были о окамле, как о полноценной замене С++, а когда руки дошли повозиться — получите, распишитесь
Re[10]: OCaml - язык общего назначения?
От:
Аноним
Дата:
22.08.11 10:50
Оценка:
Здравствуйте, Аноним, Вы писали:
А>честно говоря, не ожидал — тут столько лет разговоры были о окамле, как о полноценной замене С++, а когда руки дошли повозиться — получите, распишитесь
А можно поинтересоваться — на кой вообще нужна shared memory concurrency? Проблем мало, хочется по-комсомольски, стоя в гамаке?
Здравствуйте, Аноним, Вы писали:
А> А можно поинтересоваться — на кой вообще нужна shared memory concurrency? Проблем мало, хочется по-комсомольски, стоя в гамаке?
Мне вот нужна, чтобы при обработке видео можно было разделить картинку на части и обрабатывать их параллельно. Причем для каждого куска нужны исходные данные не только из него самого, но и из других. Как прикажете это делать без shared memory?
KP>Смысл в том, что однопоточные приложения, на данный момент, практически бесполезны. Макимум какая-то консольная утилита, и то не факт.
На OCaml можно писать многопоточные приложения, но при этом фактически будет использоваться только одно ядро процессора. С потоками никаких
проблем при этом нет, есть только проблемы с реальным одновременным выполнением на нескольких ядрах/процессорах.
А>> тогда окамловые вещи будут полностью изолированы друг от друга, и не смогут коммуницировать кроме как через С-код. даже если такое сделать, то будет очень много проблем склеивания
KP>Изолированность не проблема. Любая задача довольно просто может быть разбита на подзадачи, которые уже и будут выполняться паралельно. А вот что делать с монолитным приложением, которое не в состоянии выполнить задачу в отдельном потоке. Практически бесполезно это
Если в потоках нет тяжелых вычислений то никаких проблем, иначе получим тормоза (по сравнению скажем с аналогом на C++) на многоядерных машинах.
