You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the current Gluecodium architecture all output language generators work independently of each other. They all use a LIME model as an input, but this model does not change during the execution. So there is a theoretical possibility of executing the generators in parallel.
Presumably, there is no shared state between the different generators. This needs to be investigated. There is a shared state outside of the generators, which is a "cache" mechanism. There are different options for dealing with that: getting rid of the cache entirely (#904), making the cache thread-safe, or doing better decoupling of the generator runs and cache writes.
It is also unknown whether the parallelization would bring any performance benefit. This needs to be tested.
The text was updated successfully, but these errors were encountered:
In the current Gluecodium architecture all output language generators work independently of each other. They all use a LIME model as an input, but this model does not change during the execution. So there is a theoretical possibility of executing the generators in parallel.
Presumably, there is no shared state between the different generators. This needs to be investigated. There is a shared state outside of the generators, which is a "cache" mechanism. There are different options for dealing with that: getting rid of the cache entirely (#904), making the cache thread-safe, or doing better decoupling of the generator runs and cache writes.
It is also unknown whether the parallelization would bring any performance benefit. This needs to be tested.
The text was updated successfully, but these errors were encountered: