Исправление DRVTiny, (текущая версия) :
Часто не так уж накладно форкать задачи-воркеры, а не потоки. IPC SharedMemory никто не отменял, да и чем плох подход, при котором каждый процесс пишет свой результат вычислений независимо от остальных? Т.е. ИМХО нужно всё-таки стараться делать так, чтобы не приходилось вообще ничего блокировать, ибо ИМХО любая блокировка делает локальный кусок кода фактически не параллельным, а последовательным, вынуждая процессы/треды становится «в очередь» за ресурсом.
Возможно, самая правильная концепция - это отложенная сборка результата вычислений, когда последовательно взаимодействующие системы одинаково и отдают части результата через параллельные процессы/потоки - и принимают эти результаты, трансформируя как-то по-своему - тоже параллельные процессы/потоки. Нужно по возможности избегать точек синхронизации, точек «сборки», откладывая это всё до последнего момента или не собирая результат воедино никогда, если это возможно.
Проект финансировала DARPA, ей хотелось, чтобы простые вояки могли накодить простой скриптец, если припечет,
Удивительно, но не зная ничего об истории Питона, я всегда считал, что это язык для солдафонов - именно так воспринимается его синтаксис: ортогональный, негибкий, лаконично-отрывистый. Теперь понятно, откуда это взялось.
Исправление DRVTiny, :
Часто не так уж накладно форкать задачи-воркеры, а не потоки. IPC SharedMemory никто не отменял, да и чем плох подход, при котором каждый процесс пишет свой результат вычислений независимо от остальных? Т.е. ИМХО нужно всё-таки стараться делать так, чтобы не приходилось вообще ничего блокировать, ибо ИМХО любая блокировка делает локальный кусок кода фактически не параллельным, а последовательным, вынуждая процессы/треды становится «в очередь» за ресурсом.
Возможно, самая правильная концепция - это отложенная сборка результата вычислений, когда последовательно взаимодействующие системы одинаково и отдают части результата через параллельные процессы/потоки - и принимают эти результаты, трансформируя как-то по-своему - тоже параллельные процессы/потоки. Нужно по возможности избегать точек синхронизации, точек «сборки», откладывая это всё до последнего момента или не собирая результат воедино никогда, если это возможно.
Исходная версия DRVTiny, :
Часто не так уж накладно задачи-воркеры, а не потоки. IPC SharedMemory никто не отменял, да и чем плох подход, при котором каждый процесс пишет свой результат вычислений независимо от остальных? Т.е. ИМХО нужно всё-таки стараться делать так, чтобы не приходилось вообще ничего блокировать, ибо ИМХО любая блокировка делает локальный кусок кода фактически не параллельным, а последовательным, вынуждая процессы/треды становится «в очередь» за ресурсом.
Возможно, самая правильная концепция - это отложенная сборка результата вычислений, когда последовательно взаимодействующие системы одинаково и отдают части результата через параллельные процессы/потоки - и принимают эти результаты, трансформируя как-то по-своему - тоже параллельные процессы/потоки. Нужно по возможности избегать точек синхронизации, точек «сборки», откладывая это всё до последнего момента или не собирая результат воедино никогда, если это возможно.