`joblib` does not evaluate individuals in-place

[MorrisNein]

Currently, individuals in OptHistory designed to be uncopyable and share the same object by unique uid. Evaluation made parallel by joblib returns a list of new implicitly copied individuals and breaks this conception (here).

According to the comment on Stack Overflow, this can be solved by the two following ways:

1. use threading instead of multiprocessing;
2. use shared memory (more complicated solution).

This bug does not break optimization process, but threatens OptHistory consistency, thus must be resolved.

[gkirgizov]

Пожалуй, еcть решение проще: можно в параллельные процеccы отправлять не индивидов, а графы. Тогда индивиды не будут копироватьcя

[MorrisNein]

Пожалуй, еcть решение проще: можно в параллельные процеccы отправлять не индивидов, а графы. Тогда индивиды не будут копироватьcя

Да, но это, на мой взгляд, криво с точки зрения возвращаемых значений. Например, в текущей реализации придётся возвращать что-то вроде List[Tuple[Graph, Fitness, Dict[str, Any]]] (последнее для метаданных). А если захотим что-то ещё изменять в индивиде, то придётся снова менять возвращаемые типы.

[valer1435]

Могу предложить немного костыльный вариант: можно сначала посчитать на скопированных индивидах фитнес, а потом найти им соответствие в исходном списке и там уже inplace заменять фитнес

[gkirgizov]

Да, но это, на мой взгляд, криво с точки зрения возвращаемых значений.

Ок, согласен. А насколько самой OptHistory нужно полагаться именно на id объекта индивида, откуда такая необходимость? Почему нельзя полагаться на uid ? Ведь по логике uid это как раз уникальный id.

[gkirgizov]

Думаю, будет проще работать с классом индивида, если ему чуть смягчить инвариант: мы гарантируем не уникальность объекта, а уникальность данных в соотвествии с uid. то есть если возникают копии -- то мы уверены, что они идентичны. тогда можно не париться насчет этих вещей.

Иначе сложновато следить за этим в случае многопроцессрной оптимизации. Выходит, индивидов нельзя перекидывать в подпроцессы без действительно веских причин

[gkirgizov]

Могу предложить немного костыльный вариант

Пожалуй, костыли оправданы для каких-нибудь срочных фиксов. А эта проблемка скорее указывает на нестыковку где-то в дизайне, и это может потом где-то еще вылезти.

[nicl-nno]

Рабочая история нам нужна достаточно оперативно (для визуализаций), поэтому и хотфикс будет уместен.

[MorrisNein]

Думаю, будет проще работать с классом индивида, если ему чуть смягчить инвариант: мы гарантируем не уникальность объекта, а уникальность данных в соотвествии с uid. то есть если возникают копии -- то мы уверены, что они идентичны. тогда можно не париться насчет этих вещей.

@gkirgizov, я правильно понимаю, что это аргумент в сторону нашей ранней идеи индивида как прокси-класса на генофонд? Так навскидку не назову других способов это обеспечить.